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... [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 -- Detlef Vollmann vollmann engineering gmbh Linux and C++ for Embedded Systems http://www.vollmann.ch/ Linux for PXA270 Colibri module: http://www.vollmann.ch/en/colibri/ _______________________________________________ Xenomai-core mailing list Xenomai-core@gna.org https://mail.gna.org/listinfo/xenomai-core
