On Wednesday 11 February 2009, Narnakaje, Snehaprabha wrote: > > > So what's the particular problem? Something with how > > GPIO interrupts are being processed? I could believe > > that ... they've not been stressed much before, and such > > low-level code can hide subtle issues for a long time. > > We were trying to see why we need this additional dm9000 > specific disable/enable interrupts in the xmit function. > It seems like dm9000 ethernet controller being used on > other boards does not require this. The difference is with > the usage of GPIO based interrupt for dm9000, on DM355.
That still doesn't help me understand what's going on. I'm guessing you don't quite know yet either, but this tweak seems to be a good clue. > Ideally spin_lock_irqsave is supposed to disable interrupts > locally. Does it mean GPIO1 interrupt or does it mean dm9000 > hardware interrupt. Neither. It clears the CPU's IRQ-enable bit ... not the GPIO bank 0 IRQ enable, and not the dm9000-internal enable. While that IRQ is being processed, I seem to recall that the bank 0 IRQ is masked in the toplevel DaVinci IRQ controller; as well as the CPU's IRQ-enable bit. Is there maybe a level vs edge triggering issue? - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
