OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Paul Walmsley]

Hi

your commit 0e970cec05635adbe7b686063e2548a8e4afb8f4 ("gpio/omap: don't 
create an IRQ mapping for every GPIO on DT") breaks the boot on the 
OMAP5912 OSK:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729013931/boot/5912osk/5912osk_log.txt

This test included a stripped-down version of your commit 
949eb1a4d29dc75e0b5b16b03747886b52ecf854 ("gpio/omap: fix build error when 
OF_GPIO is not defined."), since 0e970cec also broke the build.

The previous commit ad81f0545ef01ea651886dddac4bef6cec930092 ("Linux 
3.11-rc1") boots cleanly:

http://www.pwsan.com/omap/testlogs/test_v3.11-rc1/20130721020309/boot/5912osk/5912osk_log.txt

OMAP5912 OSK is an OMAP1 platform, and therefore non-DT.

Could you please put together a fix for this?


regards,

- Paul

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Linus Walleij]

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Paul Walmsley]

Hi Linus, 

On Mon, 29 Jul 2013, Linus Walleij wrote:

> 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?

Yep, it boots fine with those three patches reverted:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729030748/boot/5912osk/5912osk_log.txt


- Paul

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Javier Martinez Canillas]

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);

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Javier Martinez Canillas]

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?

Thanks a lot and best regards,
Javier

commit 486402aee8f31f067dacc6a83c4a3509fc9d3bfa
Author: Javier Martinez Canillas <javier.martinez@collabora.co.uk>
Date:   Mon Jul 29 11:03:43 2013 +0200

    gpio/omap: setup IRQ in chip init instead .map for OMAP1

    OMAP1 still uses the legacy domain mapping and was not converted
    to use the linear mapping like OMAP2+ platforms.

    So, irq_create_mapping() does not call the omap irq_domain_ops
    .map function handler and the GPIO-IRQ are not correctly initialized.

    Do the IRQ setup in omap_gpio_chip_init() for OMAP1 platforms to
    avoid this issue.

    Signed-off-by: Javier Martinez Canillas <javier.martinez@collabora.co.uk>

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);
 }

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Santosh Shilimkar]

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Alexander Holler]

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[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.

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Alexander Holler]

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Santosh Shilimkar]

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

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Paul Walmsley]

Hi

On Mon, 29 Jul 2013, Javier Martinez Canillas wrote:

> 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);
> 

For some reason this patch didn't apply cleanly on v3.11-rc3, so 
hand-applied the following patch.  It still doesn't boot on v3.11-rc3:

http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729032525/boot/5912osk/5912osk_log.txt


- Paul

diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
index c57244e..23da829 100644
--- a/drivers/gpio/gpio-omap.c
+++ b/drivers/gpio/gpio-omap.c
@@ -1090,8 +1090,19 @@ 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);
 }

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Javier Martinez Canillas]

On 29/07/2013, at 11:47, Paul Walmsley <paul@pwsan.com> wrote:

> Hi
> 
> On Mon, 29 Jul 2013, Javier Martinez Canillas wrote:
> 
>> 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);
> 
> For some reason this patch didn't apply cleanly on v3.11-rc3, so 
> hand-applied the following patch.  It still doesn't boot on v3.11-rc3:
> 
> http://www.pwsan.com/omap/testlogs/bisect_5912osk_boot_fail_v3.11-rc3/20130729032525/boot/5912osk/5912osk_log.txt
> 
> 
> - Paul
> 

Weird since it was against -rc3, maybe my mail client corrupted somehow.

I'm out of ideas now and I don't have an OMAP1 platform to further debug this issue.

I guess the safer approach is to just revert these since they are causing a regression and what the patches aims to fix as been broken since the initial OMAP migration to DT anyways.

Unless the current gpio-omap maintainers are willing to keep these patches and know how to fix this OMAP1 regression

Thanks a lot and sorry for this mess,
Javier

> diff --git a/drivers/gpio/gpio-omap.c b/drivers/gpio/gpio-omap.c
> index c57244e..23da829 100644
> --- a/drivers/gpio/gpio-omap.c
> +++ b/drivers/gpio/gpio-omap.c
> @@ -1090,8 +1090,19 @@ 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);
> }

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Linus Walleij]

On Mon, Jul 29, 2013 at 12:19 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:

> I guess the safer approach is to just revert these since they are causing
> a regression and what the patches aims to fix as been broken since the
> initial OMAP migration to DT anyways.

I have already reverted these and pushed to linux-next.

Actually input-hogs was not such a good idea either, after
meditating on this I realized that the information about what
GPIOs are used as interrupts is a piece of information that
already exist in the device tree, albeit a bit distributed.

So I'm drafting an RFC to indicate how I think this should
be solved.

Yours,
Linus Walleij

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Javier Martinez Canillas]

On 29/07/2013, at 13:43, Linus Walleij <linus.walleij@linaro.org> wrote:

> On Mon, Jul 29, 2013 at 12:19 PM, Javier Martinez Canillas
> <javier.martinez@collabora.co.uk> wrote:
> 
>> I guess the safer approach is to just revert these since they are causing
>> a regression and what the patches aims to fix as been broken since the
>> initial OMAP migration to DT anyways.
> 
> I have already reverted these and pushed to linux-next.
> 

Thanks for doing that and sorry for all the inconvenience.

Too bad this regression was not found before the patches hit mainline and they even were on linux-next for some time but shit happens :-(

> Actually input-hogs was not such a good idea either, after
> meditating on this I realized that the information about what
> GPIOs are used as interrupts is a piece of information that
> already exist in the device tree, albeit a bit distributed.
> 
> So I'm drafting an RFC to indicate how I think this should
> be solved.
> 

Great, I hope we can finally have a good solution for this long standing issue.

> Yours,
> Linus Walleij

Best regards,
Javier

OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"

[Linus Walleij]

On Mon, Jul 29, 2013 at 2:40 PM, Javier Martinez Canillas
<javier.martinez@collabora.co.uk> wrote:
> On 29/07/2013, at 13:43, Linus Walleij <linus.walleij@linaro.org> wrote:

>> So I'm drafting an RFC to indicate how I think this should
>> be solved.
>>
>
> Great, I hope we can finally have a good solution for this long standing issue.

I have sent out this RFC patch, subject:
"RFC: interrupt consistency check for OF GPIO IRQs"

Please review the general concept of this patch and whether
it would help solving the OMAP situation for v3.12.

The patch as it stands will not work, and I cannot create a
proper test here because I have no test target system
(I am technically on vacation), but I will get to it as I get back.

And folks: you shouldn't feel bad about this. The problem is
not OMAPs at all, the problem has been there all the time
and we have discussed it for some time, it just happened that
OMAP was the first system that tried to come up with some
kind of fix for it, and for this you should be thanked, even if
we need to take another path in the end.

Yours,
Linus Walleij