> -----Original Message----- > From: David Brownell [mailto:[email protected]] > Sent: Wednesday, February 11, 2009 7:29 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: > > > > > > 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. > > You might try making it use the dedicated GPIO1 IRQ instead > of going through the GPIO controller. In that case, specify > it as a level IRQ (I think). If that works, it'll indicate > some kind of problem in the GPIO IRQ chaining. > > Thing is, I've never seen those IRQs work. I think it may > have had something to do with having the IRQ for that bank > of GPIOs enabled. There was never enough incentive to chase > down whatever problem it was ... at least, for me!
Yes, I have also tried to use the dedicated GPIO1 IRQ (45, instead of 65) and no interrupts come to dm9000 driver in this case. > > - Dave _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
