Re: [Xenomai-core] Timer IRQ propagation

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

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

ROSSIER Daniel wrote:
> Just to stimulate some discussions, I tried to bring some pieces of
> answers.
> 
> 
> -----Original Message----- From: xenomai-core-bounces@domain.hid on
> behalf of ROSSIER Daniel Sent: Fri 3/24/2006 4:38 PM To:
> xenomai@xenomai.org Subject: [Xenomai-core] Timer IRQ propagation
> 
> 
> 
> Hi,
> 
> 
> 
> We have some doubts about how the things work between i-pipe &
> xenomai regarding the timer.
> 
> 
> 
> 1-  First, when Xenomai is registered, the 10ms timer of Linux is
> stolen by the Xenomai domain. How
> 
> is the 10ms timer preserved? is it registered as a timer by the pod ?
> 
> 
> 
>> Ok, silly question: the 10ms timer (or 1ms timer) is managed by
>> Linux directly with its own list of timers; this doesn't affect
>> Xenomai's timer list.

Under Xenomai, there is the host timer (nkpod-htimer) representing the
Linux timer interrupt - with lowest prio and only propagated when the RT
domain allows it.

> 
> 2-       When a timer IRQ is received, we understood that the IRQ is
> ack'd and masked by handle_irq() and sent to the domains through
> walk_pipeline() including Linux; but we have some doubts about that
> since the timer ISR of Linux first acknowledges the interrupt, and it
> seems that it acknowledges physically (hw ack); we expected that the
> acknowledgement would be a virtual ack in the Linux domain since the
> ack has been made previously by handle_irq(). In our case (ARM arch),
> the ack actually corresponds to a mask and therefore the timer IRQ is
> masked by Linux once it gets,  and we then suspect some loss of timer
> interrupts.
> 
> have we understood correctly the mechanism? Any idea about this
> behaviour? Is it normal?
> 
> 
>> Still unclear to me; the ack would be done in the timer ISR;
>> however in the (ARM) patch we have, ipipe performs a hardware ack;
>> I've seen in the x86 patch that adeos makes nothing within
>> __ipipe_ack_system_irq(). I guess the last behaviour is correct,
>> isn't it?
> 

That's something the ARM people here can better comment on. I would only
say that physically ack'ing the shared timer IRQ twice or masking it
under Linux would be a bug - if it actually happens this way.

Jan


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