On Thu, 2006-12-07 at 00:03 +0100, Jan Kiszka wrote:
> Philippe Gerum wrote:
> > Not for x86, ipipe_ack is always valid, and __ipipe_ack_irq() which
> > calls it is arch-dependent, so we are safe. Controlling the irq_chip
> lapic_chip?

This was missing from the last patch, since it introduces unconditional

+ .ipipe_ack = lapic_noop_lapic

> Moreover, calling [ipipe_]ack is flow type specific. So you would also
> have to install a no-op handler for fasteoi chips e.g. Given that
> ioapic_chip seems to be used for both edge-triggered and fast irqs, your
> previous version looks better.

Actually, the general problem is that __ipipe_ack_irq() is not currently
flow type specific, albeit it should be. You need this routine to be
flow type aware to properly handle the primary ack/eoi cycle, and this
does not depend on the location where PIC routine calls have been voided
(i.e. generic or arch-dep/irq_chip section).

What we need is a set of companion routines to handle_<flowtype>_irq(),
each of which implementing the required acknowledge code, precisely the
one which has been removed or nop'ed from the original flow handlers.
__set_irq_handler() would then install a magic pointer in the IRQ
descriptor, calling back the right acknowledge code. The very inelegant
thing about that is that we would have to somehow select a companion
handler based on the known values of regular flow handler pointers, but
unless we patch all calls sites of set_irq_chip_and_handler*(), I don't
see another way to do it right now. The flow would look like this:

__ipipe_handle_irq -> irq_desc[irq].ipipe_acknowledge(irq) ->

I will work on that in a few days.


> > This issue goes beyond the quick hack of masking recurring IRQs, and
> > IIRC, we discussed it briefly on this list some months ago. This is what
> > would bring a significant improvement wrt determinism.
> As long as we do not fall back behind previous characteristics of
> I-pipe, I see no problem with addressing this in an even smarter way
> later. Is this patch equivalent, e.g. to 1.5's behaviour?

Talking about edge IRQs, where recurring hits are specifically handled
by the regular Linux code, I see no difference. 2.6.17-1.5 used to let
the ->end() handlers deal with such issue, which it usually did by _not_
unmasking the interrupt channel upon recurring IRQ detection, whilst
2.6.19-1.6 detects this situation directly from the generic handling
code, then refrains from unmasking the source under the same condition.

> Jan

Xenomai-core mailing list

Reply via email to