| Message ID | 51F63864.9000601@collabora.co.uk (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Javier, On Monday 29 July 2013 05:39 AM, Javier Martinez Canillas wrote: > On 07/29/2013 11:19 AM, Javier Martinez Canillas wrote: >> On 07/29/2013 11:01 AM, Linus Walleij wrote: >>> Hi Paul, >>> >>> On Mon, Jul 29, 2013 at 9:52 AM, Paul Walmsley <paul@pwsan.com> wrote: >>> >>>> your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't >>>> create an IRQ mapping for every GPIO on DT") breaks the boot on the >>>> OMAP5912 OSK: >>> >>> I'm contemplating just reverting this whole series, as I didn't like >>> the approach from the beginning and it has exploded in exactly >>> the way I thought it would. >>> >>> If we revert these three patches: >>> >>> commit 949eb1a4d29dc75e0b5b16b03747886b52ecf854 >>> "gpio/omap: fix build error when OF_GPIO is not defined." >>> commit b4419e1a15905191661ffe75ba2f9e649f5d565e >>> "gpio/omap: auto request GPIO as input if used as IRQ via DT" >>> commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 >>> "gpio/omap: don't create an IRQ mapping for every GPIO on DT" >>> >>> Does the OMAP1 boot again after this? >>> >>> I think it's a way better idea to proceed with input-hogs on the gpiochip >>> DT node and use that to get auto-request on the GPIO lines that >>> will be used as IRQs only. >>> >>> Yours, >>> Linus Walleij >>> >> >> Hi Paul, >> >> I've looked at this and it seems that irq_create_mapping() does not call the >> irq_domain_ops .map function handler since OMAP1 still uses legacy domain >> mapping. I don't have an OMAP1 platform to test but could you please see if the >> following patch [1] makes your OMAP1 platforms to boot again? >> >> But I agree with Linus and probably we should just go and revert the whole >> series since it is very hard to get it right. In another thread a user reported >> that this change also broke his DTS tree. >> >> I really tried to get this right without breaking anything but there are just >> too many OMAP platforms behaving differently and most OMAP drivers are only half >> converted to DT so this is really a can of worms. >> >> Thanks a lot and sorry for the inconvenience, >> Javier >> >> [1]: >> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c >> index c57244e..f1c6da8 100644 >> --- a/drivers/gpio/gpio-omap.c >> +++ b/drivers/gpio/gpio-omap.c >> @@ -1090,8 +1090,18 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) >> * are used as interrupts. >> */ >> if (!omap_gpio_chip_boot_dt(&bank->chip)) >> - for (j = 0; j < bank->width; j++) >> - irq_create_mapping(bank->domain, j); >> + for (j = 0; j < bank->width; j++) { >> + int irq = irq_create_mapping(bank->domain, j); >> + irq_set_lockdep_class(irq, &gpio_lock_class); >> + irq_set_chip_data(irq, bank); >> + if (bank->is_mpuio) { >> + omap_mpuio_alloc_gc(bank, irq, bank->width); >> + } else { >> + irq_set_chip_and_handler(irq, &gpio_irq_chip, >> + handle_simple_irq); >> + set_irq_flags(irq, IRQF_VALID); >> + } >> + } >> irq_set_chained_handler(bank->irq, gpio_irq_handler); >> irq_set_handler_data(bank->irq, bank); >> > > In case this solves Paul issue, a cleaned patch with a commit message is [2]. > But we should decide if is better to fix this or just drop the patches and go > with Linus' input-hogs idea to do the GPIO auto request. > > Santosh, Kevin, Grant, what do you think we should do? > With some helps from MMC and other guys, we validated the Linus's tip which includes your patches. It actually doesn't break anything and as OMAP hsmmc maintainer clarified, the cd-gpios isn't supported yet for DT. While supporting that it can use appropriate binding whichever works. But with OMAP1 breakage reported by Paul, I think we are not left with choice but to revert those commits. We *must* respect rc rules for the fixes. *No regression* Thanks for your hardwork to cook up those patches but now Linus's W proposal is going to be generic, hopefully the issue can be address better. Till then we can't get the ethernet support. Linus, I guess you have already gone ahead on revert path as seen from other email. Lets just make that official. We are sorry for cause you trouble over a week-end. Regards, Santosh
Am 29.07.2013 14:57, schrieb Santosh Shilimkar: > With some helps from MMC and other guys, we validated the Linus's tip which includes > your patches. It actually doesn't break anything and as OMAP hsmmc maintainer > clarified, the cd-gpios isn't supported yet for DT. While supporting that it > can use appropriate binding whichever works. > > But with OMAP1 breakage reported by Paul, I think we are not left with choice > but to revert those commits. We *must* respect rc rules for the fixes. > *No regression* > > Thanks for your hardwork to cook up those patches but now Linus's W proposal > is going to be generic, hopefully the issue can be address better. Till > then we can't get the ethernet support. The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected. I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work. If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2. Regards, Alexander Holler
On Monday 29 July 2013 10:52 AM, Alexander Holler wrote: > Am 29.07.2013 14:57, schrieb Santosh Shilimkar: > >> With some helps from MMC and other guys, we validated the Linus's tip which includes >> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer >> clarified, the cd-gpios isn't supported yet for DT. While supporting that it >> can use appropriate binding whichever works. >> >> But with OMAP1 breakage reported by Paul, I think we are not left with choice >> but to revert those commits. We *must* respect rc rules for the fixes. >> *No regression* >> >> Thanks for your hardwork to cook up those patches but now Linus's W proposal >> is going to be generic, hopefully the issue can be address better. Till >> then we can't get the ethernet support. > > The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected. > > I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work. > > If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2. > The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5. OMAP3 based boards are getting converted but they are bit far from being DT only. So my statement was again from what we support on mainline today and those platform don't use gpio-keys. But for testing perspective, I guess its good idea. As mentioned above, we are going ahead with revert and possible better alternative to the root of the problem. Regards, Santosh P.S: Please sensibly wrap your email replies to 80 chars so that people can read it without scrolling to the end of the line. Regards, Santosh
Am 29.07.2013 17:06, schrieb Santosh Shilimkar: > On Monday 29 July 2013 10:52 AM, Alexander Holler wrote: >> Am 29.07.2013 14:57, schrieb Santosh Shilimkar: >> >>> With some helps from MMC and other guys, we validated the Linus's tip which includes >>> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer >>> clarified, the cd-gpios isn't supported yet for DT. While supporting that it >>> can use appropriate binding whichever works. >>> >>> But with OMAP1 breakage reported by Paul, I think we are not left with choice >>> but to revert those commits. We *must* respect rc rules for the fixes. >>> *No regression* >>> >>> Thanks for your hardwork to cook up those patches but now Linus's W proposal >>> is going to be generic, hopefully the issue can be address better. Till >>> then we can't get the ethernet support. >> >> The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected. >> >> I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work. >> >> If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2. >> > The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5. > OMAP3 based boards are getting converted but they are bit far from being > DT only. So my statement was again from what we support on mainline today > and those platform don't use gpio-keys. But for testing perspective, > I guess its good idea. > I wonder how you do know that no board with OMAP chips does use gpio-keys? Does TI restrict their users/customers to only certified drivers? ;) > As mentioned above, we are going ahead with revert and possible better > alternative to the root of the problem. > > Regards, > Santosh > P.S: Please sensibly wrap your email replies to 80 chars so that > people can read it without scrolling to the end of the line. Line-wrapping mail readers do exist since some decades and I believe people should be able to read e-mails with whatever line width they prefer (and NOT what I prefer). So I never will hard-limit mails to some specific line width on my side (besides from patch). That's just a very bad behaviour. Regards, Alexander Holler
On Monday 29 July 2013 11:18 AM, Alexander Holler wrote: > Am 29.07.2013 17:06, schrieb Santosh Shilimkar: >> On Monday 29 July 2013 10:52 AM, Alexander Holler wrote: >>> Am 29.07.2013 14:57, schrieb Santosh Shilimkar: >>> >>>> With some helps from MMC and other guys, we validated the Linus's tip which includes >>>> your patches. It actually doesn't break anything and as OMAP hsmmc maintainer >>>> clarified, the cd-gpios isn't supported yet for DT. While supporting that it >>>> can use appropriate binding whichever works. >>>> >>>> But with OMAP1 breakage reported by Paul, I think we are not left with choice >>>> but to revert those commits. We *must* respect rc rules for the fixes. >>>> *No regression* >>>> >>>> Thanks for your hardwork to cook up those patches but now Linus's W proposal >>>> is going to be generic, hopefully the issue can be address better. Till >>>> then we can't get the ethernet support. >>> >>> The problem never was just the omap_hsmmc driver. I rather would say all drivers which do use GPIOs as IRQs were affected. >>> >>> I've only used the omap_hsmmc driver as example, because that was the driver I've tried to actually use with sd-cards, which is rather impossible without having a working CD-signal. And all code was already there and seems to work (at least during my few tests), so I've just added an entry to the dts to be able to use a mmc-slot as one would expect a mmc-slot does work. >>> >>> If someone wants to test a new feature at the same front, I would suggest to try it out using gpio-keys. That driver should work on almost any architecture/platform/hardware which supports gpios and is small enough to be a good test candidate. Having had a short look at gpio-keys.c, I think the same problems as with omap_hsmmc would have been occured when someone had tried to use that driver with 3.11-rc2. >>> >> The 3 OMAP platforms which supports DT are AM33XX, OMAP4 and OMAP5. >> OMAP3 based boards are getting converted but they are bit far from being >> DT only. So my statement was again from what we support on mainline today >> and those platform don't use gpio-keys. But for testing perspective, >> I guess its good idea. >> > > I wonder how you do know that no board with OMAP chips does use gpio-keys? > > Does TI restrict their users/customers to only certified drivers? ;) > I just grep on kernel.org tree and my comment was restricted to what is current state in mainline for DT. I never said it can't be used or no board is using it. Sorry if i was not clear enough. Regards, Santosh
diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c index c57244e..c6f7c56 100644 --- a/drivers/gpio/gpio-omap.c +++ b/drivers/gpio/gpio-omap.c @@ -1053,6 +1053,7 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) { int j; static int gpio; + int irq = 0; /* * REVISIT eventually switch from OMAP-specific gpio structs @@ -1090,8 +1091,20 @@ static void omap_gpio_chip_init(struct gpio_bank *bank) * are used as interrupts. */ if (!omap_gpio_chip_boot_dt(&bank->chip)) - for (j = 0; j < bank->width; j++) - irq_create_mapping(bank->domain, j); + for (j = 0; j < bank->width; j++) { + irq = irq_create_mapping(bank->domain, j); +#ifdef CONFIG_ARCH_OMAP1 + irq_set_lockdep_class(irq, &gpio_lock_class); + irq_set_chip_data(irq, bank); + if (bank->is_mpuio) { + omap_mpuio_alloc_gc(bank, irq, bank->width); + } else { + irq_set_chip_and_handler(irq, &gpio_irq_chip, + handle_simple_irq); + set_irq_flags(irq, IRQF_VALID); + } +#endif + } irq_set_chained_handler(bank->irq, gpio_irq_handler); irq_set_handler_data(bank->irq, bank); }