Kevin, I had tried Tom's patch to use the direct interrupts and it worked fine (no netdev transmit errors) until recently. But it stopped working with the latest on linux-davinci git (has GPIO driver changes from Dave). Basically the link itself is not getting detected.
Thanks Sneha > -----Original Message----- > From: Kevin Hilman [mailto:[email protected]] > Sent: Friday, May 08, 2009 5:03 PM > To: Tom Wheeler > Cc: Narnakaje, Snehaprabha; David Brownell; davinci-linux-open- > [email protected] > Subject: Re: DM355 and DM9000 Ethernet > > "Tom Wheeler" <[email protected]> writes: > > > Kevin, > > > > Here is an interesting bit of info. > > > > I masked the bank0 interrupt in EINT1 and the dm9000 is still running. > > This should eliminate the bank0 interrupt from being generated to the > > core. > > > > That partially solves the problem, but if any other GPIOs in bank0 are > ever configured as interrupts, that will be unmasked again and we'll > be back to having double interrupts. > > I'd still like to figure out why the bank interrupts aren't working, > but in the mean time, I will probably push a fix that is inspired by > your patch. > > Thanks, > > Kevin > > > > > > > > > > > > > > > > -----Original Message----- > > From: Kevin Hilman [mailto:[email protected]] > > Sent: Friday, May 01, 2009 12:01 PM > > To: Tom Wheeler > > Cc: Narnakaje, Snehaprabha; David Brownell; > > [email protected] > > Subject: Re: DM355 and DM9000 Ethernet > > > > "Tom Wheeler" <[email protected]> writes: > > > >> 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. > > > > Thanks so much for all your detective work here. It's made it much > > easier for me to understand what's going on. > > > >> 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. > > > > I did some experiments yesterday to confirm this as well. > > > >> 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. > > > > I've noticed this too and it's annoying because each time I think I > > get it working, as I put a heavier load on it it fails again. :( > > > >> 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. > > > > Yes, the direct interrupt works better but the end result is that it > > requires two interrupts to fire and get handled for every network > > interrupt. This is what I'm trying to avoid so I'm trying to debug > > the problem with the GPIO interrupt handling. > > > > Kevin > > > >> > >> 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
