[LAD] Re: [LAU] Thinkpad R60 for Audio Update - Firewire Conflicts with Audio

[Lee Revell]

On 4/10/07, Pieter Palmers <pieterp at joow.be> wrote:
> Florian Schmidt wrote:
> > On Tuesday 10 April 2007, Pieter Palmers wrote:
> >
> >> The IRQ handler 'vectors' are called by the hardware, and these call the
> >> IRQ handler functions registered in the kernel. Ingo's patch makes these
> >> handler functions run in separate threads that are scheduled at a
> >> certain priority. These IRQ handler functions then determine what module
> >> the IRQ is for/from, and run the IRQ handler for that module, at the
> >> same priority as it was scheduled itself.
> >>
> >> What I propose is that the IRQ handler priority can be set for each
> >> module irq handler, instead of for each 'global' irq handler.
> >
> > Yes, that would be nice. I'm pretty sure Ingo thought of this before himself.
> me too actually ;)
>
> > I suspect practical reasons [i.e. too much work] for this not being
> > implemented. Am i right, Ingo [CC'ed]?
>
> I don't think it's that much work, but there might be caveats that are
> not really apparent on first sight. If this isn't the case, I might try
> and cook up a patch that can trigger the open source process.

I don't think this would help - with threaded interrupts the kernel
masks the irq then schedules the handler thread which runs the
registered handlers in sequence, one of which will acks and unmask it.
 The kernel does not know which device generated the interrupt nor is
there a generic mechanism to ack an irq - only the drivers knows how
to do this.  So priortizing the handlers for different devices on the
same line buys you nothing - if the firewire hardware interrupts, no
other irqs on that line can be serviced until the firewire ISR has run
and acked the IRQ.

Excessively shared interrupts are a legacy hardware problem, you'll
never solve it in software.  The solution is APIC and MSI and the
like.

There is a potential for microoptimization: currently when a shared
IRQ is raised the kernel runs all the registered handlers in the order
they were registered (aka driver load order).  So it's possible for
another driver on the same IRQ to delay the handling of time critical
IRQs if it takes a long time for the ISR to determine whether it's
device generated this interrupt.  This could be improved by extending
the meaning of SA_INTERRUPT flag to insert this handler at the head of
the chain.

Lee