Re: [Xenomai-help] keyboard interrupt

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

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

Jan Kiszka wrote:
>> Thus what does 'acknowledege' exactly mean?
>>     
>
> That the CPU confirms the interrupt controller that it picked up a
> specific IRQ event. Depending on the IRQ type, this triggers various
> activities in the interrupt controller. For some IRQ types, this can
> also be a nop.
>
> Note that the APIC is only one of the countless interrupt controllers in
> this universe, implementing only a few of the possible IRQ types. The
> universe is large, so a lot of very strange interrupt controllers
> exist... ;)
> (You may want to study vanilla Linux genirq code, how it handles all the
> IRQ types - ipipe is a special case, not immediately revealing the hw
> requirements behind it.)
>   
ok,  there is no single answer but it depends on the much differing 
hardware. It is good to keep that  in mind in the future!
 I shall try to look at the genirq code, will also be a good exercise to 
understand the linux kernel code in more detail.

but although the interrupt controller hardware can differ in general the 
following conclusion keeps :

    When you forward the IRQ to Linux, you repy on Linux for
    dealing with the periphery (acking the IRQ there) and the final
    end-of-IRQ signal.

    The shared IRQ handling algorithm is to consult all handlers in a
    loop until they all reported "not for me" in a row.

    Thus for correct handling of shared IRQs, _all_ associate IRQ
    handlers, also
    those in Linux, must have been executed before the EOI can be sent.

    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.
    (because the handling of the linux interrupt, is in fact executing
    code with none-realtime priority, which will delay the realtime
    system in a unpredicatable way!)


Thanks for all help,
Harco
> Jan
>
>   


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