Re: [Xenomai-core] [PATCH] Shared irqs v.6

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

Jeroen Van den Keybus wrote:
>>> I mean that the support of shared interrupts for ISA boards
>> (edge-triggered
>>> stuff) is a kind of emulation to overcome the shortcommings of the
>> initial
>>> design on the hardware level. The hardware was just not supposed to
>> support
>>> shared interrupt channels. So, let's keep it a bit aside from another
>> code
>>> :o)
>> Unfortunately, this crappy hardware is still quite common in the
>> embedded domain.
> 
> 
> If I've understood correctly, the only reason for having this support is to
> avoid - after discovering an interrupting UART - that the IRQ line remains
> high upon exit, which would cause the 8259 not to issue the CPU IRQ for that
> line anymore ?

Yep.

> 
> The proposed solution is therefore to traverse the entire list of
> UARTs connected to that IRQ line and make sure none of them was interrupting
> in two consecutive passes (by checking their status registers). That would
> mean the IRQ line must be deasserted and the 8259 will properly detect any
> newly arriving interrupts, since the 8259 has been acknowledged before
> handling the interrupt.

Yep.

> 
> 1. Wouldn't it be more efficient to make this a compile-time option, instead
> of burdening the nucleus with it ?

You need this feature per-IRQ as there will always be also usual
level-triggered IRQs on your system. What Dmitry is now heading for is a
runtime selection of the fitting IRQ trampoline at nucleus level.

> 2. Would it be an option, in the embedded boards Jan is speaking of, to put
> the 8259 in level sensitive mode ? Some of the boards I know don't actually
> have this selection logic for the built-in interrupt sources such as the
> timer and the IDE I/F and it therefore only applies to the ISA bus.

Might be an option, but I'm not THAT deep into it to asses all possible
pitfalls of such an approach. Has anyone ever tried this in reality?

> 3. Beware of UARTs that cause interrupts and have a problem that causes them
> to spuriously return 'all green' upon reading of the IIR register. I have
> dealt with an integrated ('Super I/O') card with that problem before. The
> only solution was to look at LSR and check THRE as well, even when no TX
> interrupt was seemingly present. Must be a logic race.

Yes, there is always the risk of running onto such hardware. Luckily, we
haven't "found" any of it on our systems so far (once you picked
reasonable hardware, you should stay with it - just like we do :) ).

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]