Detlef Vollmann wrote:
> Gilles Chanteperdrix wrote:
> > Philippe Gerum wrote:
> > > 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 was also my first idea. But after a bit of musing on that
> idea, I'm not really sure that this is the best way to go.
> We're talking here about more than 100 bits that have to be tested
> one after the other (on PXA270, it's 116, though the actual code
> checks 126 bits), and even on a fast CPU this takes some time.
>
> So I've thought about a way to register a GPIO-IRQ into I-pipe
> that gets checked directly under I-pipe, while all other GPIOs
> are only checked and handled in the domain that handles the
> original multiplexing IRQ.
> But I have to admit that I have no idea how to implement that...
Maybe a reasonable alternative would be to use fls in order to find the
set bits in the mask ? This way, if the masks are sparse, which they
should be, we will skip a lot of checks.
>
> [snip]
> > +++ linux-2.6.16.5-tcl1-ipipe/arch/arm/mach-pxa/irq.c 2006-08-03
> > 19:04:52.000000000 +0200
>
> > +#ifdef CONFIG_IPIPE
> > +void __ipipe_mach_demux_irq(unsigned irq, struct pt_regs *regs)
>
> > + __ipipe_handle_irq(irq, regs);
> Just to check: this only marks the interrupt, but not actually
> handles it, doesn't it?
This handles it if the current or higher domains have a registered
handler and are not stalled.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core
