We have recently identified a bug in the original Cirrus supplied Linux
kernel patches regarding high numbered IRQs. There is a NR_IRQS #define
in include/asm-arm/arch-ep93xx/irqs.h that is something like 59 or 60
when it should be 64. The request_irq() call does a check for <= NR_IRQS
or some such and will return error for the high number GPIO IRQ. I have
no idea why Cirrus coded the kernel to make 59 the highest numbered IRQ,
the VIC interrupt controller on all their CPUs has precisely 64.
//Jesse Off
On Tue, 19 Apr 2005, Andy Gryc wrote:
>
> Hi all,
>
> I'm writing a device driver to be triggered off one of the GPIO port b
> (DIO 4, specifically) interrupts. The problem is when I get to calling
> request_irq with the GPIOINT interrupt (59), I get back -22. I
> interpret that as "EINVAL"--i.e. the value is out of range?
>
> It certainly isn't because that IRQ is already taken: if I dump
> /proc/interrupts, I've got 4 for the timer, 39 for the Ethernet, and 52
> for the UART, but nothing else.
>
> Am I doing something wrong, or is this kernel not designed to handle
> irqs higher than 52? If that's the case, that's really bad; it
> basically means I can't write my device driver unless I get a new
> kernel. :-(
>
> --Andy Gryc
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>
>
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|