* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 9:19 ` Javier Martinez Canillas
0 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 9:19 UTC (permalink / raw)
To: linux-arm-kernel
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);
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 9:19 ` Javier Martinez Canillas
@ 2013-07-29 9:39 ` Javier Martinez Canillas
-1 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 9:39 UTC (permalink / raw)
To: Linus Walleij
Cc: Paul Walmsley, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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);
}
^ permalink raw reply related [flat|nested] 30+ messages in thread* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 9:39 ` Javier Martinez Canillas
0 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 9:39 UTC (permalink / raw)
To: linux-arm-kernel
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);
}
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 9:39 ` Javier Martinez Canillas
@ 2013-07-29 12:57 ` Santosh Shilimkar
-1 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 12:57 UTC (permalink / raw)
To: Javier Martinez Canillas, Linus Walleij
Cc: Paul Walmsley, Kevin Hilman, Enric Balletbo i Serra, Grant Likely,
Linux-OMAP, Jean-Christophe PLAGNIOL-VILLARD,
linux-arm-kernel@lists.infradead.org
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
^ permalink raw reply [flat|nested] 30+ messages in thread* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 12:57 ` Santosh Shilimkar
0 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 12:57 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 12:57 ` Santosh Shilimkar
@ 2013-07-29 14:52 ` Alexander Holler
-1 siblings, 0 replies; 30+ messages in thread
From: Alexander Holler @ 2013-07-29 14:52 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Javier Martinez Canillas, Linus Walleij, Paul Walmsley,
Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 14:52 ` Alexander Holler
0 siblings, 0 replies; 30+ messages in thread
From: Alexander Holler @ 2013-07-29 14:52 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 14:52 ` Alexander Holler
@ 2013-07-29 15:06 ` Santosh Shilimkar
-1 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 15:06 UTC (permalink / raw)
To: Alexander Holler
Cc: Javier Martinez Canillas, Linus Walleij, Paul Walmsley,
Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 15:06 ` Santosh Shilimkar
0 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 15:06 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 15:06 ` Santosh Shilimkar
@ 2013-07-29 15:18 ` Alexander Holler
-1 siblings, 0 replies; 30+ messages in thread
From: Alexander Holler @ 2013-07-29 15:18 UTC (permalink / raw)
To: Santosh Shilimkar
Cc: Javier Martinez Canillas, Linus Walleij, Paul Walmsley,
Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 15:18 ` Alexander Holler
0 siblings, 0 replies; 30+ messages in thread
From: Alexander Holler @ 2013-07-29 15:18 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 15:18 ` Alexander Holler
@ 2013-07-29 15:23 ` Santosh Shilimkar
-1 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 15:23 UTC (permalink / raw)
To: Alexander Holler
Cc: Javier Martinez Canillas, Linus Walleij, Paul Walmsley,
Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 15:23 ` Santosh Shilimkar
0 siblings, 0 replies; 30+ messages in thread
From: Santosh Shilimkar @ 2013-07-29 15:23 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 9:19 ` Javier Martinez Canillas
@ 2013-07-29 9:47 ` Paul Walmsley
-1 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-07-29 9:47 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Linus Walleij, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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);
}
^ permalink raw reply related [flat|nested] 30+ messages in thread* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 9:47 ` Paul Walmsley
0 siblings, 0 replies; 30+ messages in thread
From: Paul Walmsley @ 2013-07-29 9:47 UTC (permalink / raw)
To: linux-arm-kernel
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);
}
^ permalink raw reply related [flat|nested] 30+ messages in thread* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 9:47 ` Paul Walmsley
@ 2013-07-29 10:19 ` Javier Martinez Canillas
-1 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 10:19 UTC (permalink / raw)
To: Paul Walmsley
Cc: Linus Walleij, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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);
> }
^ permalink raw reply [flat|nested] 30+ messages in thread* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 10:19 ` Javier Martinez Canillas
0 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 10:19 UTC (permalink / raw)
To: linux-arm-kernel
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);
> }
^ permalink raw reply [flat|nested] 30+ messages in thread* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 10:19 ` Javier Martinez Canillas
@ 2013-07-29 11:43 ` Linus Walleij
-1 siblings, 0 replies; 30+ messages in thread
From: Linus Walleij @ 2013-07-29 11:43 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Paul Walmsley, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 11:43 ` Linus Walleij
0 siblings, 0 replies; 30+ messages in thread
From: Linus Walleij @ 2013-07-29 11:43 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 11:43 ` Linus Walleij
@ 2013-07-29 12:40 ` Javier Martinez Canillas
-1 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 12:40 UTC (permalink / raw)
To: Linus Walleij
Cc: Paul Walmsley, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 12:40 ` Javier Martinez Canillas
0 siblings, 0 replies; 30+ messages in thread
From: Javier Martinez Canillas @ 2013-07-29 12:40 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
2013-07-29 12:40 ` Javier Martinez Canillas
@ 2013-07-29 15:26 ` Linus Walleij
-1 siblings, 0 replies; 30+ messages in thread
From: Linus Walleij @ 2013-07-29 15:26 UTC (permalink / raw)
To: Javier Martinez Canillas
Cc: Paul Walmsley, Linux-OMAP, Enric Balletbo i Serra,
linux-arm-kernel@lists.infradead.org, Grant Likely,
Jean-Christophe PLAGNIOL-VILLARD, Santosh Shilimkar, Kevin Hilman
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
^ permalink raw reply [flat|nested] 30+ messages in thread
* OMAP5912 boot broken by "gpio/omap: don't create an IRQ mapping for every GPIO on DT"
@ 2013-07-29 15:26 ` Linus Walleij
0 siblings, 0 replies; 30+ messages in thread
From: Linus Walleij @ 2013-07-29 15:26 UTC (permalink / raw)
To: linux-arm-kernel
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
^ permalink raw reply [flat|nested] 30+ messages in thread