DaVinci unbanked GPIO IRQs broken
Unbanked GPIO IRQs (I am on DM365) seem to have been broken by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion to generic irq chip, leading to an oops from request_irq(). Please note I am on kernel 3.0.0-rc7 not the latest, although I tried more recent gpio.c patches to no avail, I think this is probably still broken in 3.2. The problem seems to be with chip_data and chip getting overwritten in davinci_gpio_irq_setup(), this was fixed for banked IRQs but not unbanked. I had a go at fixing the overwrite of chip_data but it still oopses in the same function, irq_gc_mask_set_bit(). Looking at the way gpio_irqchip_unbanked is copied from the irq and modified looks pretty fishy but I am out of time to work on this more (reverting the conversion to generic irq chip works for me). Requesting an IRQ for example IRQ 44 for GPIO 0, I get a backtrace, hopefuly my mail client won't mangle this too badly. Unable to handle kernel paging request at virtual address febf pgd = c22dc000 [febf] *pgd= Internal error: Oops: 801 [#1] PREEMPT Modules linked in: mcu(+) edmak irqk cmemk CPU: 0Not tainted (3.0.0-rc7+ #93) PC is at irq_gc_mask_set_bit+0x68/0x7c LR is at vprintk+0x22c/0x484 pc : []lr : []psr: 6093 sp : c33e3ba0 ip : c33e3af0 fp : c33e3bc4 r10: c04555bc r9 : c33d4340 r8 : 6013 r7 : 002d r6 : c04555bc r5 : fec67010 r4 : r3 : c04734c8 r2 : fec0 r1 : r0 : 0026 Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user Control: 0005317f Table: 822dc000 DAC: 0015 Process modprobe (pid: 526, stack limit = 0xc33e2270) Stack: (0xc33e3ba0 to 0xc33e4000) 3ba0: c007d3d4 c33e3bcc c04555bc c04555bc c33d4340 c33e3bdc c33e3bc8 3bc0: c007f5f8 c0080bb4 c04555bc c33e3bf4 c33e3be0 c007f654 c007f5c0 3be0: c04555bc c33e3c24 c33e3bf8 c007e6e8 c007f618 c01f2284 c0350af8 3c00: c0405214 bf016c98 0001 c33dc008 002d c33e3c54 c33e3c28 3c20: c007e888 c007e408 0001 c23ef880 c33dc000 c33dc080 c25caa00 3c40: c0487498 bf017078 c33e3c94 c33e3c58 bf016b44 c007e7d4 bf017078 c33dc008 3c60: c25caa08 c33dc008 c33e3c84 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3c80: c0496d60 bf017484 c33e3ca4 c33e3c98 c022a698 bf01692c c33e3cd4 c33e3ca8 3ca0: c01f5d88 c022a688 bf017484 c25caa00 c25caa00 c01f5f48 c25caa08 3cc0: c0496d60 c33e3cec c33e3cd8 c01f5f8c c01f5d10 c33e3cf0 3ce0: c33e3d14 c33e3cf0 c01f5210 c01f5f58 c303cb48 c25ecf94 c25caa00 c25caa00 3d00: c25caa34 c33e3dd8 c33e3d34 c33e3d18 c01f6044 c01f51b8 c0496d3c c25caa00 3d20: c044e918 c33e3dd8 c33e3d44 c33e3d38 c01f4ff4 c01f5fcc c33e3d94 c33e3d48 3d40: c01f3d10 c01f4fd8 c044e918 c01f52c0 c034d570 3d60: c33e3d84 c33e3d70 c022bf84 c25caa00 c044e918 c33e3dd8 c25c2e00 3d80: c0496d60 bf01763c c33e3db4 c33e3d98 c022b1a0 c01f384c c25caa00 c33e3dd8 3da0: c33e3dd8 c33e3dd4 c33e3db8 c022b27c c022b0e8 bf01763c 3dc0: c0451c80 c33e3dd8 c33e3e34 c33e3dd8 bf016f60 c022b210 5f75636d 746e6f63 3de0: 006c6f72 bf0174bc 3e00: 00989680 0020 c0451c80 c0451c80 bf0174dc c01f5eb0 3e20: c33f0f00 bf0174dc c33e3e44 c33e3e38 c01f72f4 bf016e2c c33e3e74 c33e3e48 3e40: c01f5d88 c01f72e4 c0451c80 c0451cb4 bf0174dc c01f5eb0 c33f0f00 3e60: c0473100 c33e3e94 c33e3e78 c01f5f44 c01f5d10 c33e3e98 3e80: bf0174dc c01f5eb0 c33e3ebc c33e3e98 c01f5534 c01f5ec0 c303c038 c3061c30 3ea0: 3cd8 00098258 bf0174dc c0462ac8 c33e3ecc c33e3ec0 c01f5bec c01f54dc 3ec0: c33e3efc c33e3ed0 c01f4d30 c01f5bdc bf0173a0 c33e2000 3cd8 00098258 3ee0: bf0174dc c33e2000 c00301a4 bf019000 c33e3f1c c33e3f00 c01f6588 c01f4c8c 3f00: 3cd8 00098258 c33e2000 c33e3f2c c33e3f20 c01f777c c01f6524 3f20: c33e3f3c c33e3f30 bf019014 c01f7740 c33e3f7c c33e3f40 c002f3ec bf019010 3f40: 3cd8 00098258 bf017518 3cd8 00098258 bf017518 3f60: c00301a4 c33e2000 c33e3fa4 c33e3f80 c007b934 c002f3c4 3f80: c00b307c c00b2f48 3cd8 0003 0080 c33e3fa8 3fa0: c0030020 c007b8b8 3cd8 00098288 3cd8 00098258 00098240 3fc0: 3cd8 0003 0080 00098008 00098028 00098288 0001 3fe0: be892998 be892988 00013d7c 40178740 6010 00098288 09089041 00200845 Backtrace: [] (irq_gc_mask_set_bit+0x0/0x7c) from [] (irq_enable+0x48/0x58) r6:c33d4340 r5:c04555bc r4:c04555bc [] (irq_enable+0x0/0x58) from [] (irq_startup+0x4c/0x54) r5:c04555bc r4: [] (irq_startup+0x0/0x54) from [] (__setup_irq+0x2f0/0x3cc) r5:c04555bc r4: [] (__setup_irq+0x0/0x3cc) from [] (request_threaded_irq+0xc4/0x110) r8:002d r7:c33dc008 r6: r5:0001 r4:bf016c98 [] (request_threaded_irq+0x0/0x110) from [] (mcu_spi_probe+0x228/0x37c [mcu]) [] (mcu_spi_probe+0x0/0x37c [mcu]) from [] (spi_drv_probe+0x20/0x24) [] (spi_drv_probe+0x0/0x24) from [] (dri
RE: DaVinci unbanked GPIO IRQs broken
Hi Jon,
On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote:
> Unbanked GPIO IRQs (I am on DM365) seem to have been broken
> by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion
> to generic irq chip, leading to an oops from request_irq().
>
> Please note I am on kernel 3.0.0-rc7 not the latest, although
> I tried more recent gpio.c patches to no avail, I think this is
> probably still broken in 3.2.
Yes, I was able to reproduce it on my 3.2-rc6 based branch.
>
> The problem seems to be with chip_data and chip getting overwritten
> in davinci_gpio_irq_setup(), this was fixed for banked IRQs but not
> unbanked. I had a go at fixing the overwrite of chip_data but it
> still oopses in the same function, irq_gc_mask_set_bit().
The root cause indeed seems to be chip_data getting
overwritten.
I made a patch for it and was able to test that requesting IRQ
number 44 doesn't oops. Yet to figure out if there is an easy way
to trigger an unbanked GPIO IRQ on the EVM, so a large part of
the patch is actually untested. Anyway, can you give this patch
a shot (hopefully not mailer mangled)? I don't like the fact that
it increases davinci_soc_info usage, but first lets see if it fixes
the issue.
Thanks,
Sekhar
--8<
From: Sekhar Nori
Date: Fri, 13 Jan 2012 15:55:35 +0530
Subject: [PATCH] gpio/davinci: fix unbanked gpio irq handling
Unbanked GPIO irq setup code was overwriting chip_data leading
to oops on request_irq()
Fix the issue.
Reported-by: Jon Povey
Signed-off-by: Sekhar Nori
---
drivers/gpio/gpio-davinci.c | 15 ++-
1 files changed, 10 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index df0d595..a6777e5 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -313,10 +313,16 @@ static int gpio_to_irq_unbanked(struct gpio_chip *chip,
unsigned offset)
return -ENODEV;
}
-static int gpio_irq_type_unbanked(struct irq_data *d, unsigned trigger)
+static int gpio_irq_type_unbanked(struct irq_data *data, unsigned trigger)
{
- struct davinci_gpio_regs __iomem *g = irq2regs(d->irq);
- u32 mask = (u32) irq_data_get_irq_handler_data(d);
+ struct davinci_gpio_controller *d;
+ struct davinci_gpio_regs __iomem *g;
+ struct davinci_soc_info *soc_info = &davinci_soc_info;
+ u32 mask;
+
+ d = (struct davinci_gpio_controller *)data->handler_data;
+ g = (struct davinci_gpio_regs __iomem *)d->regs;
+ mask = __gpio_mask(data->irq - soc_info->gpio_irq);
if (trigger & ~(IRQ_TYPE_EDGE_FALLING | IRQ_TYPE_EDGE_RISING))
return -EINVAL;
@@ -400,8 +406,7 @@ static int __init davinci_gpio_irq_setup(void)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) {
irq_set_chip(irq, &gpio_irqchip_unbanked);
- irq_set_handler_data(irq, (void *)__gpio_mask(gpio));
- irq_set_chip_data(irq, (__force void *)g);
+ irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
--
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Nori, Sekhar wrote: > On Wed, Jan 11, 2012 at 17:17:34, Jon Povey wrote: >> Unbanked GPIO IRQs (I am on DM365) seem to have been broken >> by commit aac4dd1dab8acfc244d697473d2a5f4424a5746c, conversion >> to generic irq chip, leading to an oops from request_irq(). > The root cause indeed seems to be chip_data getting > overwritten. > > I made a patch for it and was able to test that requesting IRQ > number 44 doesn't oops. Yet to figure out if there is an easy way > to trigger an unbanked GPIO IRQ on the EVM, so a large part of > the patch is actually untested. Anyway, can you give this patch > a shot (hopefully not mailer mangled)? I don't like the fact that > it increases davinci_soc_info usage, but first lets see if it fixes > the issue. gpio_export(n, 1) and using sysfs to set the gpio to output can be used to test. Tried quickly rebasing my stuff to 3.2, your patch fixes the oops, but the interrupt does not trigger. I don't have time to investigate why not right now, sorry. But I did try reverting the genirq change too, and the interrupt handler still wasn't called, so maybe something else broke somewhere, or it could be something needs updating in my board support. I tried applying this patch (modulo gpio path change) to my 3.0-rc7 base with the genirq stuff left in. I still get an oops and backtrace when requesting the irq! If this is clearer: 3.2 vanilla: oops requesting irq 3.2 + your patch: no oops, isr is not run 3.2 + reverted genirq: no oops, isr is not run 3.0-rc7: oops requesting irq 3.0-rc7 + your patch: oops requesting irq 3.0-rc7 + reverted genirq: no oops, isr works -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Sorry, last email had some lies, I had testing errors: Jon Povey wrote: > But I did try reverting the genirq change too, and > the interrupt handler still wasn't called This was incorrect, interrupt DOES work with genirq reverted on 3.2. > 3.2 vanilla: oops requesting irq > 3.2 + your patch: no oops, isr is not run These are still the case > 3.2 + reverted genirq: no oops, isr is not run This was incorrect, real result is: no oops, isr WORKS. (with or without your patch). -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Hi Jon, On Mon, Jan 16, 2012 at 17:08:30, Jon Povey wrote: > Sorry, last email had some lies, I had testing errors: > > Jon Povey wrote: > > But I did try reverting the genirq change too, and > > the interrupt handler still wasn't called > > This was incorrect, interrupt DOES work with genirq reverted on 3.2. > > > 3.2 vanilla: oops requesting irq > > 3.2 + your patch: no oops, isr is not run > > These are still the case > > > 3.2 + reverted genirq: no oops, isr is not run > > This was incorrect, real result is: no oops, isr WORKS. > (with or without your patch). I was able to reproduce this on the EVM using v2.6.38 (works) and v3.2 + my patch (doesn't work). I just started poking some registers to see what is happening. Will keep you updated on any progress. Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Hi Jon,
On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote:
> I was able to reproduce this on the EVM using v2.6.38 (works)
> and v3.2 + my patch (doesn't work). I just started poking some
> registers to see what is happening. Will keep you updated
> on any progress.
>
Following patch fixes the issue of interrupt handler not getting
called. I tested it using GPIO3 on DM365. On applying this, I
see a constant rate of 4-5 interrupts per second on that line.
Yet to figure out what is triggering those. Anyway I will wait for
you to test this after you are back before sending this to Grant.
Thanks,
Sekhar
--8<-
From: Sekhar Nori
Date: Fri, 27 Jan 2012 00:31:54 +0530
Subject: [PATCH] gpio/davinci: fix enabling of unbanked GPIO IRQs
Unbanked GPIO IRQ handling code made a copy of just
the irq_chip structure for GPIO IRQ lines which caused
problems after the generic IRQ chip conversion because
there was no valid irq_chip_type structure with the
right "regs" populated. irq_gc_mask_set_bit() was
therefore accessing random addresses.
Fix it by making a copy of irq_chip_type structure
instead. This will ensure sane register offsets.
Reported-by: Jon Povey
Signed-off-by: Sekhar Nori
---
drivers/gpio/gpio-davinci.c | 11 ++-
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/drivers/gpio/gpio-davinci.c b/drivers/gpio/gpio-davinci.c
index a6777e5..3d00016 100644
--- a/drivers/gpio/gpio-davinci.c
+++ b/drivers/gpio/gpio-davinci.c
@@ -386,7 +386,7 @@ static int __init davinci_gpio_irq_setup(void)
* IRQ mux conflicts; gpio_irq_type_unbanked() is only for GPIOs.
*/
if (soc_info->gpio_unbanked) {
- static struct irq_chip gpio_irqchip_unbanked;
+ static struct irq_chip_type gpio_unbanked;
/* pass "bank 0" GPIO IRQs to AINTC */
chips[0].chip.to_irq = gpio_to_irq_unbanked;
@@ -394,9 +394,10 @@ static int __init davinci_gpio_irq_setup(void)
/* AINTC handles mask/unmask; GPIO handles triggering */
irq = bank_irq;
- gpio_irqchip_unbanked = *irq_get_chip(irq);
- gpio_irqchip_unbanked.name = "GPIO-AINTC";
- gpio_irqchip_unbanked.irq_set_type = gpio_irq_type_unbanked;
+ gpio_unbanked = *container_of(irq_get_chip(irq),
+ struct irq_chip_type, chip);
+ gpio_unbanked.chip.name = "GPIO-AINTC";
+ gpio_unbanked.chip.irq_set_type = gpio_irq_type_unbanked;
/* default trigger: both edges */
g = gpio2regs(0);
@@ -405,7 +406,7 @@ static int __init davinci_gpio_irq_setup(void)
/* set the direct IRQs up to use that irqchip */
for (gpio = 0; gpio < soc_info->gpio_unbanked; gpio++, irq++) {
- irq_set_chip(irq, &gpio_irqchip_unbanked);
+ irq_set_chip(irq, &gpio_unbanked.chip);
irq_set_handler_data(irq, &chips[gpio / 32]);
irq_set_status_flags(irq, IRQ_TYPE_EDGE_BOTH);
}
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
Hi Jon, On Fri, Jan 27, 2012 at 18:49:42, Nori, Sekhar wrote: > Hi Jon, > > On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote: > > > I was able to reproduce this on the EVM using v2.6.38 (works) > > and v3.2 + my patch (doesn't work). I just started poking some > > registers to see what is happening. Will keep you updated > > on any progress. > > > > Following patch fixes the issue of interrupt handler not getting > called. I tested it using GPIO3 on DM365. On applying this, I > see a constant rate of 4-5 interrupts per second on that line. > Yet to figure out what is triggering those. Anyway I will wait for > you to test this after you are back before sending this to Grant. Are you back? Did you get a chance to test this? Thanks, Sekhar ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
RE: DaVinci unbanked GPIO IRQs broken
> On Fri, Jan 27, 2012 at 18:49:42, Nori, Sekhar wrote: >> Hi Jon, >> >> On Tue, Jan 17, 2012 at 15:32:23, Nori, Sekhar wrote: >> >>> I was able to reproduce this on the EVM using v2.6.38 (works) >>> and v3.2 + my patch (doesn't work). I just started poking some >>> registers to see what is happening. Will keep you updated >>> on any progress. >>> >> >> Following patch fixes the issue of interrupt handler not getting >> called. I tested it using GPIO3 on DM365. On applying this, I >> see a constant rate of 4-5 interrupts per second on that line. >> Yet to figure out what is triggering those. Anyway I will wait for >> you to test this after you are back before sending this to Grant. > > Are you back? Did you get a chance to test this? Hi, sorry about that. I was away for a month, and forgot about this. Tested just now. It seems good, GPIO interrupts work under 3.2 with this patch same as they do if I revert the genirq change. I noticed that something else is broken for me under 3.2 (my FPGA driver fails to load bitstream) compared with 3.0, but that is also broken with genirq reverted so I think it's a separate issue and your patch is good. So, Tested-By: Jon Povey -- Jon Povey jon.po...@racelogic.co.uk Racelogic is a limited company registered in England. Registered number 2743719 . Registered Office Unit 10, Swan Business Centre, Osier Way, Buckingham, Bucks, MK18 1TB . The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
