"Tom Wheeler" <[email protected]> writes: > 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
