Re: [Xenomai-help] keyboard interrupt

[Harco Kuppens <h.kuppens@domain.hid>]

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

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.
Who however gives this 'end-of-IRQ' signal? linux or the pipeline?
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?



> 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

please help me out this world of confusion :)

cheers
Harco
> Jan
>
>   


[-- Attachment #2: Type: text/html, Size: 3372 bytes --]