[Xenomai-core] Activation of IRQ handler in the Linux domain

[Xenomai-core] Activation of IRQ handler in the Linux domain

[ROSSIER Daniel]

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

Hello,

 

I'm doing a small RT application using the I2C driver from Linux. 

At a certain time, when the task is activated and data are written to
the I2C bus,

the driver waits for a IRQ that confirmed the data have been sent out.
The write function

actually polls a variable state until a timeout or a state change
occurring on reception of that IRQ (done by the handler).

 

However, since driver functions are called from the Xenomai domain, the
IRQ handler is not processed

at the reception since the hander belongs to the Linux domain. It ends
up with a timeout 

during the write.

 

I implemented a local ISR within the Xenomai application, but the
propagation of IRQ is not performed

while the task is running. Is there a way to tell Adeos to forward the
IRQ to the Linux domain with no delay

so that the Linux handler can be called? or do I need to re-implement
the ISR in the Xenomai application?

 

Thanks for any hints.

 

Daniel

 


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

Re: [Xenomai-core] Activation of IRQ handler in the Linux domain

[Philippe Gerum]

On Mon, 2007-09-03 at 14:11 +0200, ROSSIER Daniel wrote:
> Hello,
> 
>  
> 
> I'm doing a small RT application using the I2C driver from Linux. 
> 
> At a certain time, when the task is activated and data are written to
> the I2C bus,
> 
> the driver waits for a IRQ that confirmed the data have been sent out.
> The write function
> 
> actually polls a variable state until a timeout or a state change
> occurring on reception of that IRQ (done by the handler).
> 
>  
> 
> However, since driver functions are called from the Xenomai domain,
> the IRQ handler is not processed
> 
> at the reception since the hander belongs to the Linux domain. It ends
> up with a timeout 
> 
> during the write.
> 
>  
> 
> I implemented a local ISR within the Xenomai application, but the
> propagation of IRQ is not performed
> 
> while the task is running.

Which is expected. All the pipeline abstraction relies on the very
fundamental assumption that domains run by priority order, which in turn
means that a high priority domain must run until all the pending work is
processed, and a Xenomai task in a runnable state represents some
pending work for the Xenomai domain. Make your Xenomai task sleep on
some synchronization object (likely a RTDM one) for synchronizing with
the code which signals the wakeup condition, and the pending IRQ will
flow down to Linux as expected. Busy waiting for such condition is a
dead end here.

>  Is there a way to tell Adeos to forward the IRQ to the Linux domain
> with no delay
> 
> so that the Linux handler can be called? or do I need to re-implement
> the ISR in the Xenomai application?
> 

Your code cannot be on both side of the same fence. Either you want a
real-time guarantee for interrupt delivery and task dispatching and you
need a Xenomai ISR to process IRQs to wake-up some Xenomai task; or, you
don't need any guarantee, but still want Linux to process the i2c IRQs
just for the purpose of recycling some vanilla code, and in such a case,
you need to make the Linux IRQ handler wake up the Xenomai task. In the
latter case, the Xenomai task (in primary RT mode) must sleep at some
point waiting for the wake up event, there is no sideways possible here.
You may call rt_sem_v() or sem_post(), or a rtdm object signaling
routines from a Linux context to wake up a real-time sleeper.

>  
> 
> Thanks for any hints.
> 
>  
> 
> Daniel
> 
>  
> 
> 
> _______________________________________________
> Xenomai-core mailing list
> Xenomai-core@domain.hid
> https://mail.gna.org/listinfo/xenomai-core
-- 
Philippe.

[Xenomai-core] RE : Activation of IRQ handler in the Linux domain

[ROSSIER Daniel]

>On Mon, 2007-09-03 at 14:11 +0200, ROSSIER Daniel wrote:
>> Hello,
>>
>>
>>
>> I'm doing a small RT application using the I2C driver from Linux.
>>
>> At a certain time, when the task is activated and data are written to
>> the I2C bus,
>>
>> the driver waits for a IRQ that confirmed the data have been sent out.
>> The write function
>>
>> actually polls a variable state until a timeout or a state change
>> occurring on reception of that IRQ (done by the handler).
>>
>>
>>
>> However, since driver functions are called from the Xenomai domain,
>> the IRQ handler is not processed
>>
>> at the reception since the hander belongs to the Linux domain. It ends
>> up with a timeout
>>
>> during the write.
>>
>>
>>
>> I implemented a local ISR within the Xenomai application, but the
>> propagation of IRQ is not performed
>>
>> while the task is running.
>
>Which is expected. All the pipeline abstraction relies on the very
>fundamental assumption that domains run by priority order, which in turn
>means that a high priority domain must run until all the pending work is
>processed, and a Xenomai task in a runnable state represents some
>pending work for the Xenomai domain. Make your Xenomai task sleep on
>some synchronization object (likely a RTDM one) for synchronizing with
>the code which signals the wakeup condition, and the pending IRQ will
>flow down to Linux as expected. Busy waiting for such condition is a
>dead end here.

Ok, I totally agree. I've tried to use a rtdm_event object which I've
declared in the Linux driver side. Then, the write function is called from a RT task,
then it calls rtdm_event_wait() at a certain point, and the i2c ISR performs a rtdm_event_signal()
to wake up the RT task. However, I got a kernel crash when rtdm_event_wait() is called.


The i2c driver is statically linked in the kernel (zImage), but I'm not sure 
if I'm right declaring a rtdm object in the kernel directly. Can you confirm?

Another point where I'm not sure: does a call to rtdm_event_signal() suspend the execution
of the linux ISR, or will the ISR terminate properly before yielding to the RT task?
Because it might complicate the work between the (partially finished, without unmasked IRQ) handler
and the RT task...

Thanks in advance for the clarification.

>
>>  Is there a way to tell Adeos to forward the IRQ to the Linux domain
>> with no delay
>>
>> so that the Linux handler can be called? or do I need to re-implement
>> the ISR in the Xenomai application?
>>
>
>Your code cannot be on both side of the same fence. Either you want a
>real-time guarantee for interrupt delivery and task dispatching and you
>need a Xenomai ISR to process IRQs to wake-up some Xenomai task; or, you
>don't need any guarantee, but still want Linux to process the i2c IRQs
>just for the purpose of recycling some vanilla code, and in such a case,
>you need to make the Linux IRQ handler wake up the Xenomai task. In the
>latter case, the Xenomai task (in primary RT mode) must sleep at some
>point waiting for the wake up event, there is no sideways possible here.
>You may call rt_sem_v() or sem_post(), or a rtdm object signaling
>routines from a Linux context to wake up a real-time sleeper.
>
>>
>>
>> Thanks for any hints.
>>
>>
>>
>> Daniel
>>
>>
>>
>>
>> _______________________________________________
>> Xenomai-core mailing list
>> Xenomai-core@domain.hid
>> https://mail.gna.org/listinfo/xenomai-core
>--
>Philippe.
>

Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux domain

[Philippe Gerum]

On Mon, 2007-09-03 at 19:58 +0200, ROSSIER Daniel wrote:
> >On Mon, 2007-09-03 at 14:11 +0200, ROSSIER Daniel wrote:
> >> Hello,
> >>
> >>
> >>
> >> I'm doing a small RT application using the I2C driver from Linux.
> >>
> >> At a certain time, when the task is activated and data are written to
> >> the I2C bus,
> >>
> >> the driver waits for a IRQ that confirmed the data have been sent out.
> >> The write function
> >>
> >> actually polls a variable state until a timeout or a state change
> >> occurring on reception of that IRQ (done by the handler).
> >>
> >>
> >>
> >> However, since driver functions are called from the Xenomai domain,
> >> the IRQ handler is not processed
> >>
> >> at the reception since the hander belongs to the Linux domain. It ends
> >> up with a timeout
> >>
> >> during the write.
> >>
> >>
> >>
> >> I implemented a local ISR within the Xenomai application, but the
> >> propagation of IRQ is not performed
> >>
> >> while the task is running.
> >
> >Which is expected. All the pipeline abstraction relies on the very
> >fundamental assumption that domains run by priority order, which in turn
> >means that a high priority domain must run until all the pending work is
> >processed, and a Xenomai task in a runnable state represents some
> >pending work for the Xenomai domain. Make your Xenomai task sleep on
> >some synchronization object (likely a RTDM one) for synchronizing with
> >the code which signals the wakeup condition, and the pending IRQ will
> >flow down to Linux as expected. Busy waiting for such condition is a
> >dead end here.
> 
> Ok, I totally agree. I've tried to use a rtdm_event object which I've
> declared in the Linux driver side. Then, the write function is called from a RT task,
> then it calls rtdm_event_wait() at a certain point, and the i2c ISR performs a rtdm_event_signal()
> to wake up the RT task. However, I got a kernel crash when rtdm_event_wait() is called.
> 

Make sure to test the return of rtdm_event_wait() in your loop. Maybe
its fails and returns with some error code you don't detect, causing an
infinite tight loop.

> 
> The i2c driver is statically linked in the kernel (zImage), but I'm not sure 
> if I'm right declaring a rtdm object in the kernel directly. Can you confirm?
> 

If you want to keep the i2c driver statically bound to the kernel, you
don't have any other choice than defining the RTDM object the same way,
except by using some hairy indirect reference to such object via a
pointer, which would be uselessly complex in any case.

> Another point where I'm not sure: does a call to rtdm_event_signal() suspend the execution
> of the linux ISR,

Yes, at least if the RT task is pending on the object at the time it is
signaled. Your RT task has higher priority than the Linux kernel running
one of its ISRs.

>  or will the ISR terminate properly before yielding to the RT task?

No. The Linux ISR will be preempted immediately by posting the object.

> Because it might complicate the work between the (partially finished, without unmasked IRQ) handler
> and the RT task...
> 

It's complicated because the design you are trying to implement has a
flaw: you want to make a high priority task synchronize on a low
priority event. Maybe you should consider moving the i2c interrupt
handler as a Xenomai ISR. What prevents you from doing that?

> Thanks in advance for the clarification.
> 
> >
> >>  Is there a way to tell Adeos to forward the IRQ to the Linux domain
> >> with no delay
> >>
> >> so that the Linux handler can be called? or do I need to re-implement
> >> the ISR in the Xenomai application?
> >>
> >
> >Your code cannot be on both side of the same fence. Either you want a
> >real-time guarantee for interrupt delivery and task dispatching and you
> >need a Xenomai ISR to process IRQs to wake-up some Xenomai task; or, you
> >don't need any guarantee, but still want Linux to process the i2c IRQs
> >just for the purpose of recycling some vanilla code, and in such a case,
> >you need to make the Linux IRQ handler wake up the Xenomai task. In the
> >latter case, the Xenomai task (in primary RT mode) must sleep at some
> >point waiting for the wake up event, there is no sideways possible here.
> >You may call rt_sem_v() or sem_post(), or a rtdm object signaling
> >routines from a Linux context to wake up a real-time sleeper.
> >
> >>
> >>
> >> Thanks for any hints.
> >>
> >>
> >>
> >> Daniel
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> Xenomai-core mailing list
> >> Xenomai-core@domain.hid
> >> https://mail.gna.org/listinfo/xenomai-core
> >--
> >Philippe.
> >
> 
-- 
Philippe.

Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux domain

[Jan Kiszka]

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

Hi Daniel,

[Some add-ons to what Philippe already pointed out:]

ROSSIER Daniel wrote:
> ...
> Ok, I totally agree. I've tried to use a rtdm_event object which I've
> declared in the Linux driver side. Then, the write function is called from a RT task,

That sounds error-prone: Is "write" only called from RT context? Does it
have to synchronise with functions running in non-RT context, and is
this synchronisation done in a RT-safe manner (rtdm_lock_...)? You may
check this offline - or online with CONFIG_IPIPE_DEBUG_CONTEXT.

> then it calls rtdm_event_wait() at a certain point, and the i2c ISR performs a rtdm_event_signal()
> to wake up the RT task. However, I got a kernel crash when rtdm_event_wait() is called.

Sometimes it is helpful to analyse what the crash says precisely, e.g.
at which line of code (during which memory access) the crash happens.
Also, debugging options may help to catch some potential root bug earlier.

In general, I also smell a bit too much hacking and too less designing
here... ;)

Jan


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

Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux domain

[ROSSIER Daniel]

Hi Jan and Philippe,

I decided to move the ISR into the RT domain and everything works well.
Thanks for your suggestions.

Actually, we've our i.MX21 board with some i2c devices (namely leds and
buttons), and I wanted
to make some example of applications using the i2c in the Xenomai
domain. However, the way how the "official"
i2c driver is coded is maybe not optimal since there is this polling on
a state variable (transfer complete) which is updated
by the ISR. My wish was to touch the driver as few as possible.

Daniel

>-----Original Message-----
>From: jan.kiszka@domain.hid [mailto:jan.kiszka@domain.hid]
>Sent: lundi 3 septembre 2007 23:37
>To: ROSSIER Daniel
>Cc: rpm@xenomai.org; xenomai-core
>Subject: Re: [Xenomai-core] RE : Activation of IRQ handler in the Linux
>domain
>
>Hi Daniel,
>
>[Some add-ons to what Philippe already pointed out:]
>
>ROSSIER Daniel wrote:
>> ...
>> Ok, I totally agree. I've tried to use a rtdm_event object which I've
>> declared in the Linux driver side. Then, the write function is called
>> from a RT task,
>
>That sounds error-prone: Is "write" only called from RT context? Does
it
>have to synchronise with functions running in non-RT context, and is
>this synchronisation done in a RT-safe manner (rtdm_lock_...)? You may
>check this offline - or online with CONFIG_IPIPE_DEBUG_CONTEXT.
>
>> then it calls rtdm_event_wait() at a certain point, and the i2c ISR
>> performs a rtdm_event_signal() to wake up the RT task. However, I got
>a kernel crash when rtdm_event_wait() is called.
>
>Sometimes it is helpful to analyse what the crash says precisely, e.g.
>at which line of code (during which memory access) the crash happens.
>Also, debugging options may help to catch some potential root bug
>earlier.
>
>In general, I also smell a bit too much hacking and too less designing
>here... ;)
>
>Jan