Re: [PATCH v1] of/irq: do irq resolution in platform_get_irq_byname()

From: Grygorii Strashko
Date: Wed May 28 2014 - 05:19:25 EST

Hi All,

On 05/28/2014 12:03 PM, Grant Likely wrote:
On Wed, May 28, 2014 at 9:49 AM, Chen-Yu Tsai <wens@xxxxxxxx> wrote:
On Wed, May 28, 2014 at 4:25 PM, Linus Walleij <linus.walleij@xxxxxxxxxx> wrote:
On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones@xxxxxxxxxx> wrote:
On Tue, 27 May 2014, Rob Herring wrote:

On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@xxxxxxxxxx> wrote:
On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@xxxxxxxxxx> wrote:
On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@xxxxxx> wrote:
The commit 9ec36cafe43bf835f8f29273597a5b0cbc8267ef
"of/irq: do irq resolution in platform_get_irq" from Rob Herring -
moves resolving of the interrupt resources in platform_get_irq().
But this solution isn't complete because platform_get_irq_byname()
need to be modified the same way.

Hence, fix it by adding interrupt resolution code at the
platform_get_irq_byname() function too.

Cc: Russell King <linux@xxxxxxxxxxxxxxxx>
Cc: Rob Herring <robh@xxxxxxxxxx>
Cc: Tony Lindgren <tony@xxxxxxxxxxx>
Cc: Grant Likely <grant.likely@xxxxxxxxxx>
Cc: Thierry Reding <thierry.reding@xxxxxxxxx>

Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx>

Applied, Thanks.

As of next-20150526, the ST u8500 Snowball board has been failing boot
in linux-next, and was bisected down to this patch (commit
ad69674e73a1 in -next). Full boot failure attached.

I have not dug any deeper, but can confirm that next-20140526 with
this patch reverted boots again on the snowball board.

There's a patch on the list which fixes it. The problem is stmmac
driver was expecting only one error code.

Does Snowball even use stmmac?

No.

I don't get this...

Log says musb is wrestling control over some pins with some other driver:

[ 1.441497] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already
requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto
[ 1.453369] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto)
status -22
[ 1.460571] pinctrl-nomadik soc:pinctrl: could not request pin 256
(GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik
[ 1.472076] musb-hdrc musb-hdrc.0.auto: Error applying setting,
reverse things back
[ 1.479827] HS USB OTG: no transceiver configured
[ 1.484558] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[ 1.492309] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral
[ 1.500183] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already
requested by a03e0000.usb_per5; cannot claim for musb-hdrc.0.auto
[ 1.512023] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.0.auto)
status -22
[ 1.519226] pinctrl-nomadik soc:pinctrl: could not request pin 256
(GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik
[ 1.530731] musb-ux500 musb-hdrc.0.auto: Error applying setting,
reverse things back
[ 1.539184] pinctrl-nomadik soc:pinctrl: pin GPIO256_AF28 already
requested by a03e0000.usb_per5; cannot claim for musb-hdrc.1.auto
[ 1.551025] pinctrl-nomadik soc:pinctrl: pin-256 (musb-hdrc.1.auto)
status -22
[ 1.558258] pinctrl-nomadik soc:pinctrl: could not request pin 256
(GPIO256_AF28) from group usb_a_1 on device pinctrl-nomadik
[ 1.569732] musb-hdrc musb-hdrc.1.auto: Error applying setting,
reverse things back
[ 1.577453] HS USB OTG: no transceiver configured

[ .. repeats until the end .. ]

I think this is not related to this patch.

The bisected patch causes platform_get_irq() to always parse the
devicetree to obtain the irq instead of using a precalculated value in
the platform_device. There are two possible scenarios for this problem
that I can think of:
1) Platform_get_irq() is getting called multiple times (which would
happen on a deferred probe) but the setup code isn't handling it
properly, like trying to request the GPIO more than once
2) the platform_device was preloaded with an irq number that differs
from what is determined when parsing the tree. This would happen if a
platform_device was created manually.


Could anyone try attached patch? It has to improve situation, but it might not fix all problems (see my previous e-mail).

Regards,
-grygorii

--
From 4a41912dba648c935982274966426fa430fd5aa4 Mon Sep 17 00:00:00 2001
From: Grygorii Strashko <grygorii.strashko@xxxxxx>
Date: Wed, 28 May 2014 12:53:34 +0300
Subject: [PATCH] mfd: ab8500: fix dt irq mapping

The AD8500 defines itself as interrupt-controller in DT,
but it doesn't assign DT node to IRQ domain when creates it.
As result, of_irq_xx() helpers don't work because they can't
find necessary IRQ domain.

Hence, fix it by assigning AD8500 core device DT node to IRQ
domain when it's created.

Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx>
---
drivers/mfd/ab8500-core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/mfd/ab8500-core.c b/drivers/mfd/ab8500-core.c
index a8ee4a3..cf2e6a1 100644
--- a/drivers/mfd/ab8500-core.c
+++ b/drivers/mfd/ab8500-core.c
@@ -591,7 +591,7 @@ static int ab8500_irq_init(struct ab8500 *ab8500, struct device_node *np)
num_irqs = AB8500_NR_IRQS;

/* If ->irq_base is zero this will give a linear mapping */
- ab8500->domain = irq_domain_add_simple(NULL,
+ ab8500->domain = irq_domain_add_simple(ab8500->dev->of_node,
num_irqs, 0,
&ab8500_irq_ops, ab8500);

--
1.7.9.5



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/