[Xenomai] Question about IPIPE_IRQF_NOSYNC

[Xenomai] Question about IPIPE_IRQF_NOSYNC

[Tim Niemeyer]

Hi

I'm using Xenomai 2.6.1 with linux 3.4.14 (with latest 'for-core-3.4'
Adeos) on an omap3 board.

While hunting a gpio-irq latency i tried to understand the adeos chained
interrupt code. I'm currently stuck at ipipe_handle_demuxed_irq()
because i didn't understand the IPIPE_IRQF_NOSYNC-Flag:

static inline void ipipe_handle_demuxed_irq(unsigned int cascade_irq)
{
..
__ipipe_dispatch_irq(cascade_irq, IPIPE_IRQF_NOSYNC);
..
}

Maybe someone can give me hint or point me to the right documentation,
so that i can better understand the code for __ipipe_dispatch_irq() ?

-- 
Tim Niemeyer

Corscience GmbH & Co. KG
Henkestr. 91
D-91052 Erlangen
Germany

e-mail: tim.niemeyer@corscience.de
Internet: www.corscience.de

Re: [Xenomai] Question about IPIPE_IRQF_NOSYNC

[Philippe Gerum]

On 12/14/2012 04:33 PM, Tim Niemeyer wrote:
> Hi
>
> I'm using Xenomai 2.6.1 with linux 3.4.14 (with latest 'for-core-3.4'
> Adeos) on an omap3 board.
>
> While hunting a gpio-irq latency i tried to understand the adeos chained
> interrupt code. I'm currently stuck at ipipe_handle_demuxed_irq()
> because i didn't understand the IPIPE_IRQF_NOSYNC-Flag:
>
> static inline void ipipe_handle_demuxed_irq(unsigned int cascade_irq)
> {
> ..
> __ipipe_dispatch_irq(cascade_irq, IPIPE_IRQF_NOSYNC);
> ..
> }
>

This means "mark the interrupt as pending, but do not attempt to run the 
handler". Normally, __ipipe_dispatch_irq would eventually check and 
figure out that some interrupt is pending, and provided the context 
allows, it would run the handlers for each interrupt flagged as such, by 
calling __ipipe_sync_pipeline.

> Maybe someone can give me hint or point me to the right documentation,
> so that i can better understand the code for __ipipe_dispatch_irq() ?
>


-- 
Philippe.

Re: [Xenomai] Question about IPIPE_IRQF_NOSYNC

[Gilles Chanteperdrix]

On 12/14/2012 04:33 PM, Tim Niemeyer wrote:

> Hi
> 
> I'm using Xenomai 2.6.1 with linux 3.4.14 (with latest 'for-core-3.4'
> Adeos) on an omap3 board.


The latest Adeos is the core-3.4 branch from the git.denx.de/ipipe.git
repository, not the 'for-core-3.4' branch from the
git.xenomai.org/ipipe-gch.git.

Anyway, you can not use Xenomai 2.6.1 with linux 3.4, you also have to
use xenomai from its git repository git.xenomai.og/xenomai-2.6.git

> 
> While hunting a gpio-irq latency i tried to understand the adeos chained


How high a latency are we talking about?

Anyway, the way we track down this kind of issues is the I-pipe tracer.
http://www.xenomai.org/index.php/I-pipe:Tracer

You will have to trigger the freeze yourself if you find a too high latency.

-- 
                                                                Gilles.

Re: [Xenomai] Question about IPIPE_IRQF_NOSYNC

[Tim Niemeyer]

Am Samstag, den 15.12.2012, 13:04 +0100 schrieb Gilles Chanteperdrix:
> The latest Adeos is the core-3.4 branch from the git.denx.de/ipipe.git
> repository, not the 'for-core-3.4' branch from the
> git.xenomai.org/ipipe-gch.git.
Ah, thanks for clearing up.

> Anyway, you can not use Xenomai 2.6.1 with linux 3.4, you also have to
> use xenomai from its git repository git.xenomai.og/xenomai-2.6.git
It's working here fine. Why do you expect, that Xenomai 2.6.1 and linux
3.4 won't work together?

I'm using 'for-core-3.4' branch from git.xenomai.org/ipipe-gch.git with
Linux 3.4.14. I just build a big diff from 'for-core-3.4' against 3.4.6
and applied this on my 3.4.14. Then i took all the kernel-src files and
Kconfig changes from xenomai-2.6.1.tar.bz2 and build again a patch.
I use simple patches as they are easier for me to maintain in ptxdist.

> > While hunting a gpio-irq latency i tried to understand the adeos chained
> 
> How high a latency are we talking about?
The latency was about ~11µs. I then found out, that the cpu clock wasn't
the full 600MHz. I changed this and now the gpio-irq latency is about
~7µs. In contrast, the timer-irq latency is less than 3µs.
But when i use IPIPE_IRQF_NOSYNC the gpio-irq latency rises to ~14µs.
But on the other hand the switch between gpio-irq and timer-irq is
faster with IRQF_NOSYNC. It takes ~3µs and without IRQF_NOSYNC is takes
~7µs.

> Anyway, the way we track down this kind of issues is the I-pipe tracer.
> http://www.xenomai.org/index.php/I-pipe:Tracer
> 
> You will have to trigger the freeze yourself if you find a too high latency.
It's a great tool. I played a bit with the tracer, but 11µs is very
short, so it's difficult.

-- 
Tim Niemeyer

Corscience GmbH & Co. KG
Henkestr. 91
D-91052 Erlangen
Germany

e-mail: tim.niemeyer@corscience.de
Internet: www.corscience.de

Re: [Xenomai] Question about IPIPE_IRQF_NOSYNC

[Gilles Chanteperdrix]

On 12/17/2012 09:14 AM, Tim Niemeyer wrote:
> Am Samstag, den 15.12.2012, 13:04 +0100 schrieb Gilles Chanteperdrix:
>> The latest Adeos is the core-3.4 branch from the git.denx.de/ipipe.git
>> repository, not the 'for-core-3.4' branch from the
>> git.xenomai.org/ipipe-gch.git.
> Ah, thanks for clearing up.
>
>> Anyway, you can not use Xenomai 2.6.1 with linux 3.4, you also have to
>> use xenomai from its git repository git.xenomai.og/xenomai-2.6.git
> It's working here fine. Why do you expect, that Xenomai 2.6.1 and linux
> 3.4 won't work together?

You could run into subtle bugs, but the only things which were fixed 
probably only mattered if you enable the posix select syscall, and on 
ARM multi-processor machines. So, if it compiles, it should run...
However, with the current xenomai git, you can build both kernel and 
user-space in thumb mode and get lower latencies.

>
> I'm using 'for-core-3.4' branch from git.xenomai.org/ipipe-gch.git with
> Linux 3.4.14. I just build a big diff from 'for-core-3.4' against 3.4.6
> and applied this on my 3.4.14. Then i took all the kernel-src files and
> Kconfig changes from xenomai-2.6.1.tar.bz2 and build again a patch.
> I use simple patches as they are easier for me to maintain in ptxdist.
>
>>> While hunting a gpio-irq latency i tried to understand the adeos chained
>>
>> How high a latency are we talking about?
> The latency was about ~11µs. I then found out, that the cpu clock wasn't
> the full 600MHz. I changed this and now the gpio-irq latency is about
> ~7µs. In contrast, the timer-irq latency is less than 3µs.
> But when i use IPIPE_IRQF_NOSYNC the gpio-irq latency rises to ~14µs.
> But on the other hand the switch between gpio-irq and timer-irq is
> faster with IRQF_NOSYNC. It takes ~3µs and without IRQF_NOSYNC is takes
> ~7µs.

Yes IRQF_NOSYNC adds a bit to the latency, but the "immediate 
dispatching" may leave the parent irq line masked for a whole 
multiplexed gpio bank, and induce latencies in the millisecond range. 
After several iteration, the current solutions seems the simplest which 
actually work. Demultiplexed GPIO already have a high latency anyway 
(and I doubt you really get a 3us, 7us or 11us latency on an omap, under 
load, you probably get something more like 20 or 30us).


-- 
					    Gilles.