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-   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

Reply via email to