Re: [Xenomai-help] keyboard interrupt

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

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

Harco Kuppens wrote:
> Hi Jan,
> 
> Thank you for your answer! But I still have some things I do not really
> understand.
> 
> In Life with Adeos 
> <http://www.xenomai.org/documentation/branches/v2.3.x/pdf/Life-with-Adeos-rev-B.pdf>
> I read :
> 
>    The stage of the pipeline occupied by any given domain can be
>    stalled, which means that
>    the next incoming interrupt will not be delivered to the domain's
>    handler, and will be
>    prevented from flowing down to the lowest priority domain(s) in the
>    same move. While a
>    stage is stalled, pending interrupts accumulate in the domain's
>    interrupt log, and
>    eventually get played when the stage is unstalled, by an internal
>    operation called
>    synchronization.
> 
> 
> and further on :
> 
>    When a domain has finished processing all the pending interrupts it
>    has received, it then
>    calls a special Adeos service which yields the CPU to the next
>    domain down the pipeline,
>    so the latter can process in turn the pending events it has been
>    notified of, and this cycle
>    continues down to the lowest priority domain of the pipeline.
> 
> 
> So from reading this I would suspect that multiple IRQs could be
> buffered (= interrupt log) between Xenomai and Linux so that Xenomai can
> finish it realtime jobs. Only when xenomai is done with its jobs the
> IRQs from the buffer are passed  to Linux
> But from your answer I suspect that it only holds for different IRQs,
> and when an IRQ X is on the pipeline not another newer IRQ X can over
> the pipeline until the first one is dealed with.
> Thus when the 'end-of-IRQ' signal is given.

Yes. For correct handling of shared IRQs, _all_ associate IRQ handlers
must have been executed before the EOI can be sent. The reason is this:

For level-triggered IRQs, all hardware devices that may have raised the
IRQ line must be checked and told to lower it again before sending EOI.
Otherwise the IRQ will immediately be triggered again and you end up in
an endless loop, bricking your box.

For edge-triggered IRQs, there problem is different. Here the shared IRQ
handling algorithm is to consult all handler in a loop until they all
reported "not for me" in a row. If you fail to do this, you risk loosing
IRQs. Consider IRQ source A and B. Now an IRQ is raised by B. First, the
handler for A will be called. It return "not for me". Now it happens
that A also raised the IRQ right at this time. If you now simply log the
IRQ for later handling by B and send the EOI, you take away the chance
for handle A to react on the IRQ. At best you create latency, at worst A
will never send an IRQ again...

[Hope someone feels motivated to move this explanation to our FAQ in the
wiki...]

> Who however gives this 'end-of-IRQ' signal? linux or the pipeline?

The last domain in the pipeline that listens to the IRQ.

> What exactly is this 'end-of-IRQ'  signal? Because interrupt are
> virtualized in the pipeline I would suspect  this is something used in
> the pipeline?

See above, this is a hardware dependency.

> 
>> IRQ sharing between deterministic and non-deterministic code (here:
>> Xenomai and vanilla Linux) will never work, that's an inherent design
>> issue, nothing Xenomai or ipipe-specific.
>>
>>   
> with inherent design, I would guess you mean the intel hardware design I
> suppose?
> but than I would suspect that the 'end-of-IRQ' signal is something in
> the hardware

The issue is architecture-independent, see above.

HTH,
Jan


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