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
