Re: [RFC trollpatch 1/1] genirq: Remove the fits all and nothing

Thomas Gleixner
2010-09-27T18:01:26Z

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1661 bytes --]

On Mon, 27 Sep 2010, Tony Luck wrote:

> On Wed, Sep 8, 2010 at 11:14 AM, Thomas Gleixner <tglx@linutronix.de> wrote:
> >  The following architectures are still using __do_IRQ():
> >
> >  alpha, cris, ia64, h8300, m32r, m68knommu, parisc, um
>
> Thomas,
>
> I (belatedly) took a look at fixing ia64 ... but I've run into a small snag.
> The __do_IRQ() routine makes a call to:
>
> desc->chip->end(irq);
>
> while neither of the "handle_level_irq()" nor "handle_edge_irq()"
> functions do this.
>
> On ia64 iosapic_end_level_irq() call iosapic_eoi() for me. Without it
> my system hangs during boot (with some driver timeout complaining
> about dropped interrupts).
>
> Is the omission of desc->chip->end(irq); deliberate? In which case
> I need to find another place to call iosapic_eoi(). Or is it accidental?

No, it's deliberate. The solution is to use the correct flow handler
for your device. We have currently several flow handlers implemented:

handle_level_irq
{
if (chip->mask_ack)
chip->mask_ack()
else {
chip->mask();
if (chip->ack)
chip->ack();
}

....

chip->unmask();
}

handle_edge_irq
{
chip->ack()

...
}

handle_simple_irq
{
...
}

handle_fasteoi_irq
{
...
chip->eoi();
}

handle_percpu_irq
{
if (chip->ack)
chip->ack();

if (chip->eoi)
chip->eoi();
}

Note, that handle_percpu_irq does not take the irq_desc->lock.

So the trick is to select the matching handler and have separate irq
chip implementations if necessary.

Hope that helps.

Thanks,

tglx