Hi Tom,
"Tom Wheeler" <[email protected]> writes:
> 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.
Thanks for this patch to the GPIO interrupt working for dm9000. This
has helped shed some light on what is going on here.
But... I still don't like what it takes to get this working and it
needs some more debugging and probably a bit of a rework on the GPIO
IRQ handling code.
Basically, it works because it takes both the direct GPIO and the
banked GPIO ISRs to run for this to work correctly.
With your patch both the direct IRQ for GPIO1 (45) and the bank IRQ
(54) fire and get serviced. IRQ45 gets dispatched as an edge handler
directly to the dm9000 ISR: ack, dispatch, unmask. Before the
dispatch though, IRQ54 fires which causes the ack of the actual GPIO
interrupt. It's a fluke that both interrupt are even enabled, and is
a side-effect of the fact that set_irq_type() actually enables the
banked interrupt (which is a bug.)
If I don't let IRQ54 actualy fire and ack the GPIO bank IRQ, it stops
working again. Maybe I'm missing something in my late-night reading
of the GPIO docs, but is there an alternate way of acking a direct
GPIO interrupts without having to use the bank registers. Acking in
the INTC doesn't seem to do the job. So, what seems like a shortcut
of a GPIO interrupts direct to INTC seems to be to be extra work due
to still having to go through the bank registers to find and ack the
right GPIO anyways.
Kevin
> 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
