From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <48D2184F.3000009@domain.hid> Date: Thu, 18 Sep 2008 10:58:55 +0200 From: Harco Kuppens MIME-Version: 1.0 References: <48CE8CE7.6030209@domain.hid> <48D177B1.7000009@domain.hid> In-Reply-To: <48D177B1.7000009@domain.hid> Content-Type: multipart/alternative; boundary="------------070504010208070101030906" Subject: Re: [Xenomai-help] keyboard interrupt List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jan Kiszka Cc: xenomai@xenomai.org This is a multi-part message in MIME format. --------------070504010208070101030906 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Jan, Thank you for your answer! But I still have some things I do not really understand. In Life with Adeos 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 > > --------------070504010208070101030906 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Jan,

Thank you for your answer! But I still have some things I do not really understand.

In Life with Adeos  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

--------------070504010208070101030906--