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. g. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
