Thread (4 messages) flat view 4 messages, 2 authors, 2006-02-10

Re: mv-linux: Problem to implement custom driver interrupt handling

From: Andrei Konovalov <hidden>
Date: 2006-02-10 19:22:19

Eckart Göhler wrote:
Andrei Konovalov wrote:
 > Hi,
 >
 > In the Linux driver you should not access the interrupt controller
 > directly.
 > The relevant XIntc_* calls are done by arch/ppc/syslib/xilinx_pic.c 
code.
 > E.g. the particular interrupt is unmasked when one calls request_irq().
 >
 > Few more comments below.


Hi,

Thanks a lot. Actually I inserted the low-level code below after 
request_irq() did not work. The note about xilinx_pic.c code (that is 
located in my implementation in arch/ppc/kernel/xilinx_pic.c) lead me to 
Correct. arch/ppc/syslib/xilinx_pic.c is the 2.6 kernel case.
the problem origin that should be reported here for the community (which 
I presume already know the very fact):
The interrupt numbering generated by the EDK is opposite to the one used 
by linux, i.e. interrupt number 4 reported in EDK-generated 
xparameters.h/xparameters_ml300.h becomes 31-4 = 27 when using request_irq.
Yes, this is true for 2.4 kernels.

In 2.6 the "natural" irq numbering is used.
I.e. for irq number of 4 (as per xparameters.h) one should pass
to request_irq()
    31-4 = 27 if using 2.4 kernel
and
   4 if using 2.6 kernel.

Thanks,
Andrei
Therefore the handler was not called because he was attached to the 
wrong interrupt, and also was not able to reset the interrupt pending 
flag, that must be done as you noted below.

cheers

eckart
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help