On Fri, 2006-08-04 at 08:10 +0200, 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...
> 

Provided that every IRQ notification goes through __ipipe_grab_irq,
including the GPIO_2_x one, then you just need to check for irq ==
GPIO_2_x in the latter routine and proceed to the demultiplexing only in
this case. No?

> [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?
> 
>  Detlef
> 
-- 
Philippe.



_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to