On Thu, 2006-08-03 at 15:18 +0200, Gilles Chanteperdrix wrote:
> Bart Jonkers wrote:
>  > > Here is a new version of the ipipe-sa1100-pxa patch that unmaks
>  > > interrupts at the end of the demux handlers, and that attempt to fix the
>  > > gettimeoffset issue. I have run 20 minutes (time for OSCR to wrap) 
> latency
>  > > with a test program verifying that time returned by gettimeofday is
>  > > never going backward.
>  > > 
>  > > The patch and the test program are attached, it would be nice if you
>  > > could test them.
>  > I have tested the patch and ran the test program.
>  > The test program give no problems.
>  > 
>  > The interrupt problem in Linux is also solved. But I have another one.
>  > I have created a small real-time kernel module which uses the native
>  > interface to handle an GPIO interrupt. The problem is that Xenomai
>  > doesn't see the interrupt. When I use GPIO0 (which doesn't use the
>  > chained handler) to receive the interrupt everything works as it should.
>  > 
>  > So it seems to be that xenomai have a problem with the chained handler.
>  > Does someone have an idea to solve this problem?
> The problem is that the demux handler is a root domain handler, and
> directly call the cascaded interrupts root domain handlers through
> desc_handle_irq, whereas in order for the I-pipe to intercept the
> interrupt for any domain, the demux handler should be run for any
> domain, and invoke __ipipe_grab_irq, __ipipe_handle_irq or
> ipipe_trigger_irq so that the cascaded interrupts are pipelined.
> So, there are two possible fixes:
> - either fix the I-pipe patch so that the demux handler is invoked when
>   the multiplexed interrupt is received for any domain, and triggers
>   interrupts through ipipe_trigger_irq;

Fixing the I-pipe is the way to go, definitely. If I understand this
correctly, the best way to handle the demux case is to implement an
I-pipe variant of the demultiplexing code currently available in
pxa_gpio_demux_handler(), which would be called from __ipipe_grab_irq()
when processing the multiplexed interrupt channel.

The I-pipe-specific demux code would then log the decoded IRQ by a call
to __ipipe_handle_irq() instead of running the root handler directly
(i.e. desc_handle_irq), which would in turn preserve the ability to
"wire" GPIO interrupts and also handle IRQ stickiness issues.

This would resemble what we are doing right now on the powerpc arch,
pulling the received IRQ number from a request to the machine-dependent
layer. I'd see no issue in duplicating such handling since this is a
rather short piece of invariant, hw-specific code which would not depend
on Linux internals, but rather on the I-pipe's.

> - or you may fix the issue locally by registering a demux handler in
>   Xenomai domain through ipipe_virtualize_irq_from, and in this demux
>   handler only clear the interrupt you want and call ipipe_trigger_irq 
>   for them, and ipipe_propagate_irq the multiplexing interrupt to let
>   other irqs be handled in the root domain.
> Philippe, is there a way to tell the I-ipipe that an interrupt handler
> should be executed for any domain?

Nope, there is no interrupt handlers implicitely shared among domains in

>  Is this what a "wired" handler is?

A wired interrupt handler is specifically associated to the domain which
is know to always lead the pipeline, so that certain assumptions which
we rely on to speed up the interrupt delivery are always true.


Xenomai-core mailing list

Reply via email to