> -----Original Message----- > From: David Brownell [mailto:[email protected]] > Sent: Wednesday, February 11, 2009 5:46 PM > To: Narnakaje, Snehaprabha > Cc: [email protected] > Subject: Re: [PATCH] NET: dm9000 ethernet on dm355: fix NETDEV WATCHDOG > timeout issue > > 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.
You are right. I have not fully understood why it fixes the issue. > > > > 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? I had tried to change the dm9000 IRQ resource to falling edge (instead of rising edge), but that didn't help. Sneha > > - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
