On Fri, May 09, 2003 at 05:34:17PM +0000, Kent Borg wrote:
> On Thu, May 08, 2003 at 02:14:26PM -0700, Dale Farnsworth wrote:
> > Create and register a board-specific interrupt driver. Assign it
> > a range of irqs (non-conflicting with the main interrupt driver).
> > When called with an irq outside its range, the board-specific driver
> > routines forward the call to the main driver.
>
> Cool, cool...
>
> > The board-specific driver does a request_irq at init time for the
> > one main irq it is multiplexing.
>
> What does my handler on the main irq do? Perhaps nothing?
Nothing. You make sure that get_irq never returns that irq, so
the handler won't be called.
> I am figuring I supply my own get_irq call, and it returns one of this
> new interrupt range, or if none, calls the previous get_irq. If I
> never let the main irq number come back, my handler on the main irq
> never gets called, right? If so, why am calling request_irq in the
> first place?
To enable (unmask) the main irq. I think you're right, it's better
to not call request_irq and just enable the irq directly.
> To keep the system from puking on spurious interrupts?
> (But if I answer the get_irq, and if I never answer the main irq
> number, how would it know?)
I'd call the main get_irq before checking for interrupt in my range.
my_get_irq() {
int irq = main_get_irq();
if (irq != my_irq)
return irq;
/* find which irq in my range cascaded into my_irq */
irq = find_cascaded_irq();
return irq;
}
-Dale
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
