diff mbox

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

Message ID 5385B566.2050600@ti.com (mailing list archive)
State New, archived
Headers show

Commit Message

Grygorii Strashko May 28, 2014, 10:07 a.m. UTC
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@csie.org> wrote:
>> On Wed, May 28, 2014 at 4:25 PM, Linus Walleij <linus.walleij@linaro.org> wrote:
>>> On Wed, May 28, 2014 at 9:18 AM, Lee Jones <lee.jones@linaro.org> wrote:
>>>> On Tue, 27 May 2014, Rob Herring wrote:
>>>>
>>>>> On Tue, May 27, 2014 at 3:23 PM, Kevin Hilman <khilman@linaro.org> wrote:
>>>>>> On Fri, May 23, 2014 at 1:03 AM, Grant Likely <grant.likely@linaro.org> wrote:
>>>>>>> On Tue, 20 May 2014 13:42:02 +0300, Grygorii Strashko <grygorii.strashko@ti.com> 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@arm.linux.org.uk>
>>>>>>>> Cc: Rob Herring <robh@kernel.org>
>>>>>>>> Cc: Tony Lindgren <tony@atomide.com>
>>>>>>>> Cc: Grant Likely <grant.likely@linaro.org>
>>>>>>>> Cc: Thierry Reding <thierry.reding@gmail.com>
>>>>>>>>
>>>>>>>> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com>
>>>>>>>
>>>>>>> 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@ti.com>
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@ti.com>
---
  drivers/mfd/ab8500-core.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Kevin Hilman June 2, 2014, 2:48 p.m. UTC | #1
Grygorii Strashko <grygorii.strashko@ti.com> writes:

> Hi All,
>
> On 05/28/2014 12:03 PM, Grant Likely wrote:

[...]

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

I can confirm it makes the STE Snowball boot again on top of next-20150602.

> From 4a41912dba648c935982274966426fa430fd5aa4 Mon Sep 17 00:00:00 2001
> From: Grygorii Strashko <grygorii.strashko@ti.com>
> 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@ti.com>

Tested-by: Kevin Hilman <khilman@linaro.org>

Kevin
Grant Likely June 3, 2014, 9:20 a.m. UTC | #2
On Mon, 02 Jun 2014 07:48:59 -0700, Kevin Hilman <khilman@linaro.org> wrote:
> Grygorii Strashko <grygorii.strashko@ti.com> writes:
> 
> > Hi All,
> >
> > On 05/28/2014 12:03 PM, Grant Likely wrote:
> 
> [...]
> 
> >> 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).
> 
> I can confirm it makes the STE Snowball boot again on top of next-20150602.
> 
> > From 4a41912dba648c935982274966426fa430fd5aa4 Mon Sep 17 00:00:00 2001
> > From: Grygorii Strashko <grygorii.strashko@ti.com>
> > 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@ti.com>
> 
> Tested-by: Kevin Hilman <khilman@linaro.org>

So is that it, or were there other problems? If it is then you can add
my acked-by when applying.

Acked-by: Grant Likely <grant.likely@linaro.org>
Grygorii Strashko June 3, 2014, 11:12 a.m. UTC | #3
Hi,

On 06/03/2014 12:20 PM, Grant Likely wrote:
> On Mon, 02 Jun 2014 07:48:59 -0700, Kevin Hilman <khilman@linaro.org> wrote:
>> Grygorii Strashko <grygorii.strashko@ti.com> writes:
>>
>>> Hi All,
>>>
>>> On 05/28/2014 12:03 PM, Grant Likely wrote:
>>
>> [...]
>>
>>>> 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).
>>
>> I can confirm it makes the STE Snowball boot again on top of next-20150602.
>>
>>>  From 4a41912dba648c935982274966426fa430fd5aa4 Mon Sep 17 00:00:00 2001
>>> From: Grygorii Strashko <grygorii.strashko@ti.com>
>>> 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@ti.com>
>>
>> Tested-by: Kevin Hilman <khilman@linaro.org>

Thanks for testing it.

> 
> So is that it, or were there other problems? If it is then you can add

This is minimal solution and some sub-devices of ab8500 MFD may still 
not work.

For example, ab8500-debugfs may not work (ste-dbx5x0.dtsi):
	ab8500-debugfs {
		compatible = "stericsson,ab8500-debug";
	};

 and its DT definition may need to be updated to explicitly define IRQs,
smth like this:
	ab8500-debugfs {
		compatible = "stericsson,ab8500-debug";
		interrupts = <0 IRQ_TYPE_LEVEL_HIGH
			      111 IRQ_TYPE_LEVEL_HIGH>;
		interrupt-names = "IRQ_FIRST", "IRQ_LAST";
	};

> my acked-by when applying.
> 
> Acked-by: Grant Likely <grant.likely@linaro.org>
> 

I've reposted this patch already:
 https://lkml.org/lkml/2014/6/2/379

Regards,
-grygorii
diff mbox

Patch

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