"Tom Wheeler" <twhee...@control4.com> 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:khil...@deeprootsystems.com] > Sent: Friday, May 01, 2009 12:01 PM > To: Tom Wheeler > Cc: Narnakaje, Snehaprabha; David Brownell; > davinci-linux-open-source@linux.davincidsp.com > Subject: Re: DM355 and DM9000 Ethernet > > "Tom Wheeler" <twhee...@control4.com> 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:khil...@deeprootsystems.com] >> Sent: Friday, May 01, 2009 9:32 AM >> To: Tom Wheeler >> Cc: Narnakaje, Snehaprabha; David Brownell; >> davinci-linux-open-source@linux.davincidsp.com >> 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:nsnehapra...@ti.com] >>> Sent: Thu 4/30/2009 8:39 PM >>> To: Tom Wheeler; David Brownell >>> Cc: davinci-linux-open-source@linux.davincidsp.com >>> 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: davinci-linux-open-source-boun...@linux.davincidsp.com [ >>> mailto:davinci-linux-open-source-boun...@linux.davincidsp.com] On >> Behalf Of Tom >>> Wheeler >>> Sent: Thursday, April 09, 2009 6:21 PM >>> To: David Brownell >>> Cc: davinci-linux-open-source@linux.davincidsp.com >>> 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:davi...@pacbell.net] >>> Sent: Thu 4/9/2009 3:43 PM >>> To: Tom Wheeler >>> Cc: davinci-linux-open-source@linux.davincidsp.com >>> 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 >>> Davinci-linux-open-source@linux.davincidsp.com >>> > http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source _______________________________________________ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
