Kevin, I had removed the set_irq_type from the board file and was trying it in the dm9000 driver.
Here is a little history on using the direct IRQ for the dm9000. When working with the 2.6.10 kernel and the DM6443 I configured the GPIOs directly and found that the bank interrupt always had to be enabled in order to utilize the direct IRQ. I confirmed this on the DM355 today by disabling the Bank0 interrupt in the BINTEN register while the dm9000 was running. It stopped working. /proc/interrupts showed no change in the number of interrupts for IRQ 45 and after a few seconds I saw the NETDEV_WATCHDOG timeout. I then re-enabled the Bank0 interrupt and the network started working again. When I was using the bank IRQ and not the direct IRQ with the dm9000 I was able to get it partially working. It would work properly on a network with little traffic and would fail on a heavily loaded network. The failure was interesting in that pinging from the DM355 would get a response while pinging to the DM355 would not. However, if I pinged to and from the DM355 at the same time then I would get a response to both. Telnet behaved in the same manner where I could not telnet to the DM355 unless I was doing something at the same time from the DM355. This lead me to believe there was an interrupt problem and perhaps that interrupts were being missed. Looking at a DM355 EVM running a 2.6.18 kernel I found that it did not exhibit the problem. I noticed that IRQ 45 (direct IRQ) was being used rather than the bank interrupt. I also noticed that the number of interrupts in /proc/interrupts was significantly higher than what I was seeing with the 2.6.28 kernel under the same conditions. Tom W. -----Original Message----- From: Kevin Hilman [mailto:[email protected]] Sent: Friday, May 01, 2009 9:32 AM To: Tom Wheeler Cc: Narnakaje, Snehaprabha; David Brownell; [email protected] Subject: Re: DM355 and DM9000 Ethernet > I did have to add this after the request irq in the dm9000.c driver. If /proc/ > interrupts shows no interrupts for irq 45 then this is most likely the problem. > > #ifdef CONFIG_ARCH_DAVINCI > /* set irq type to rising edge */ > davinci_writel(1 << 1, DAVINCI_GPIO_BASE + 0x24); > #endif That is the equivalent of the set_irq_type() you added in the board file. You should only need one of the two. Either way, doing this is what enables the banked interrupt in addition to the direct IRQ already enabled by the request_irq() causing there to be two interrupts fired and handled for each dm9000 interrupt. In debugging this, I've noticed that only using the banked IRQ along with some strategically placed printk's also gets things working without the direct IRQ. This suggests there's a timing problem or race someplace that needs flushing out. Kevin > > > > -----Original Message----- > From: Narnakaje, Snehaprabha [mailto:[email protected]] > Sent: Thu 4/30/2009 8:39 PM > To: Tom Wheeler; David Brownell > Cc: [email protected] > Subject: RE: DM355 and DM9000 Ethernet > > Tom, > > Are you sure there are no other changes you needed to do to get dm9000 ethernet > working? > > After doing these changes, I do not even get the link. > > Thanks > Sneha > > ________________________________ > From: [email protected] [ > mailto:[email protected]] On Behalf Of Tom > Wheeler > Sent: Thursday, April 09, 2009 6:21 PM > To: David Brownell > Cc: [email protected] > Subject: RE: DM355 and DM9000 Ethernet > > > Enabling LOCKDEP and applying the dm9000 IRQ handler bugfix were insufficient > to correct the problems that I was seeing. This is a patch against the 2.6.28 > rc8 kernel which configures the "direct" GPIO IRQ for use with the dm9000. The > dm9000 driver did not need any changes. /proc/interrupts shows irq 45, AINTC, > eth0. > > diff -uNrp mach-davinci.orig/board-dm355-evm.c mach-davinci/board-dm355-evm.c > --- mach-davinci.orig/board-dm355-evm.c 2009-04-09 16:01:53.000000000 -0600 > +++ mach-davinci/board-dm355-evm.c 2009-04-09 16:08:47.000000000 -0600 > @@ -19,6 +19,7 @@ > #include <linux/mtd/onenand_regs.h> > #include <linux/i2c.h> > #include <linux/io.h> > +#include <linux/irq.h> > #include <linux/gpio.h> > > #include <asm/setup.h> > @@ -32,7 +33,9 @@ > #include <mach/common.h> > #include <mach/board.h> > #include <mach/emac.h> > +#include <mach/gpio.h> > #include <mach/i2c.h> > +#include <mach/irqs.h> > #include <mach/serial.h> > > #define DAVINCI_ASYNC_EMIF_CONTROL_BASE 0x01e10000 > @@ -149,6 +152,8 @@ static struct resource dm355evm_dm9000_r > .end = 0x04014003, > .flags = IORESOURCE_MEM, > }, { > + .start = IRQ_DM355_GPIO1, > + .end = IRQ_DM355_GPIO1, > .flags = IORESOURCE_IRQ > | IORESOURCE_IRQ_HIGHEDGE /* rising (active high) */, > }, > @@ -204,10 +209,11 @@ static struct davinci_mmc_config dm355ev > static __init void dm355_evm_init(void) > { > davinci_psc_init(); > + davinci_gpio_init(); > > gpio_request(1, "dm9000"); > gpio_direction_input(1); > - dm355evm_dm9000_rsrc[2].start = gpio_to_irq(1); > + set_irq_type(gpio_to_irq(1), IRQ_TYPE_EDGE_RISING); > > platform_add_devices(davinci_evm_devices, > ARRAY_SIZE(davinci_evm_devices)); > diff -uNrp mach-davinci.orig/gpio.c mach-davinci/gpio.c > --- mach-davinci.orig/gpio.c 2009-04-09 16:02:02.000000000 -0600 > +++ mach-davinci/gpio.c 2009-04-09 16:06:00.000000000 -0600 > @@ -325,4 +325,9 @@ static int __init davinci_gpio_irq_setup > > return 0; > } > -arch_initcall(davinci_gpio_irq_setup); > + > +void davinci_gpio_init(void) > +{ > + davinci_gpio_irq_setup(); > +} > + > diff -uNrp mach-davinci.orig/include/mach/gpio.h mach-davinci/include/mach/ > gpio.h > --- mach-davinci.orig/include/mach/gpio.h 2009-04-09 16:07:42.000000000 -0600 > +++ mach-davinci/include/mach/gpio.h 2009-04-09 16:06:23.000000000 -0600 > @@ -18,6 +18,8 @@ > > #define DAVINCI_GPIO_BASE 0x01C67000 > > +extern void davinci_gpio_init(void) > + > /* > * basic gpio routines > * > > > > -----Original Message----- > From: David Brownell [mailto:[email protected]] > Sent: Thu 4/9/2009 3:43 PM > To: Tom Wheeler > Cc: [email protected] > Subject: Re: DM355 and DM9000 Ethernet > > On Thursday 09 April 2009, Tom Wheeler wrote: >> I have had problems getting the dm9000 mac/phy working properly with the >> DM355 EVM. I have seen a number of posts indicating problems with the >> dm9000 and the DM355. > > In my case, enabling LOCKDEP is sufficient to make all of those > problems vanish ... a dm9000 IRQ handler bugfix made *some* of > the problems go away. (e3162d381fc359ebe5c98a3e216888a7cb200051 > is in 2.6.29 and thus DaVinci GIT.) > > >> The 2.6.18 kernel requests the individual >> interrupt for GPIO1 (IRQ 45) where the 2.6.28 kernel uses the gpio >> controller interrupt (IRQ 65) which is chained to the bank interrupt. >> By changing the 2.6.28 kernel to reflect what I saw in the 2.6.18 kernel >> this seemed to solve the problems I was seeing. > > How did you get the "direct" GPIO IRQ to work? Did you have > to disable its bank IRQ or anything? Last time I tried to > use those "direct" IRQs, they didn't work at all. > > >> Are there known issues with the DM355 gpio controller interrupt handling >> where it chains the individual interrupts to the bank interrupt? > > So far as I know, the DM355 EVM is the first DaVinci board to > make heavy use of GPIO IRQs. So it's plausible that there be > some kind of load-dependent bug there. There's no confirmation > of such a bug in IRQ handling, though. > > I'm moderately convinced there *is* a timing bug affecting that > EVM, but whether it's EMIF bus timings or some IRQ handling race > is an open question. > > - Dave > > > > _______________________________________________ > Davinci-linux-open-source mailing list > [email protected] > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list [email protected] http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
