On Mon, 2007-05-14 at 13:12 +0200, Benjamin Zores wrote:
> Philippe Gerum wrote:
> > FWIW, I've almost finished an I-pipe port over 2.6.21 also using the
> > arch/powerpc tree. It relies on the genirq layer which makes things way
> > more comfortable, and which does not require to redefine particular ack
> > routines but rather keep the original irqchip handlers.
> That's pretty cool !
> Well, using the genirq layer is definitely the way to go but, as stated,
> my patch was a port based adeos-1.5 which was kinda old.
> > This should get better when the I-pipe/powerpc development is merged
> > into the main git repo here, which should happen in a reasonable future:
> > http://www.denx.de/cgi-bin/gitweb.cgi?p=ipipe-2.6.git;a=summary
> Well, I'm waiting for that too.
> Most of embedded devels still relies on ppc arch instead of powerpc
> and I hope this situation will change soon.
> > Note: you are mixing my [and Karim's words] from the orginal Abstract
> > with your words from the new Disclaimer, making the "we" clauses rather
> > confusing. It should be more of a README.alcatel-lucent file than a
> > README.adeos one.
> I can do so.
> > I had a look at this patch, and I see two issues, one of which can't be
> > solved easily unless you make your code use the genirq layer (see
> > x86-1.7 series and beyond), the other one is simple to fix.
> I know.
> That's why I said my patch is working but the implementation isn't as
> nice as I'd like it to be.
> > Calling mask_ack in __ipipe_ack works for edge/level IRQs, but would not
> > be applicable to transparent controllers only requiring the software to
> > send eoi, or per-cpu IRQ flows involving mask+eoi for instance.
> > Basically, this code works because it assumes that all IRQs are somehow
> > managed in level mode thus preventing the interrupt flood, but this may
> > not be always the case. Working with the vanilla genirq layer solves
> > this.
> I however won't have more time allowed
> to update the patch to use genirq layer.
> > The other issue is an old bug of mine for this port, specifically we
> > need to call irq_enter()/irq_exit() for virtual interrupts too;
> > otherwise, softirqs triggered by virtual ones might be delayed until the
> > next hw interrupt comes in. Something like this would do:
> > [...]
> Is this patch tested ?
Yes, in my patchset though. Your IRQ handler may still require a valid
cookie value, typically a pointer to some register frame
(__ipipe_tick_regs + cpuid); you could try to replace the NULL value
passed to virq handlers from my patch by the same value passed to root
> It seems not to work, segfaulting kernel.
> I-pipe 1.5-01: pipeline enabled.
> Unable to handle kernel paging request for data at address 0x00000084
> Faulting instruction address: 0xc001c874
If the suggestion above does not work, I guess that objdump on the
kernel image is your friend then, at least to locate the offending
Oops: Kernel access of bad area, sig: 11 [#1]
> I can update the patch but I won't be able to switch to genirq layer.
> So it's up to you to decide whether this patch gets commited or just lay
> down on mailing lists archives.
> Hoping to see your 2.6.21 patch soon ;-)
Xenomai-core mailing list