diff mbox

ARM: OMAP4: change the device names in usb_bind_phy

Message ID 519503DA.5070303@iki.fi (mailing list archive)
State New, archived
Headers show

Commit Message

Tomi Valkeinen May 16, 2013, 4:05 p.m. UTC 
On 16/05/13 18:58, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130515 03:59]:
>> On 23/04/13 09:14, Kishon Vijay Abraham I wrote:
>>> After the device names are created using PLATFORM_DEVID_AUTO, the old
>>> device names given in usb_bind_phy are no longer valid causing the musb
>>> controller not to get the phy reference. Updated the usb_bind_phy with
>>> the new device names to get MUSB functional in omap4 panda.
>>>
>>> Signed-off-by: Kishon Vijay Abraham I <kishon@ti.com>
>>> ---
>>> Tested in OMAP4 PANDA.
>>>  arch/arm/mach-omap2/board-4430sdp.c    |    2 +-
>>>  arch/arm/mach-omap2/board-omap4panda.c |    2 +-
>>>  2 files changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/arch/arm/mach-omap2/board-4430sdp.c b/arch/arm/mach-omap2/board-4430sdp.c
>>> index 00d7290..56a9a4f 100644
>>> --- a/arch/arm/mach-omap2/board-4430sdp.c
>>> +++ b/arch/arm/mach-omap2/board-4430sdp.c
>>> @@ -730,7 +730,7 @@ static void __init omap_4430sdp_init(void)
>>>  	omap4_sdp4430_wifi_init();
>>>  	omap4_twl6030_hsmmc_init(mmc);
>>>  
>>> -	usb_bind_phy("musb-hdrc.0.auto", 0, "omap-usb2.1.auto");
>>> +	usb_bind_phy("musb-hdrc.2.auto", 0, "omap-usb2.3.auto");
>>>  	usb_musb_init(&musb_board_data);
>>>  
>>>  	status = omap_ethernet_init();
>>
>> I'm seeing
>>
>> [    2.190155] unable to find transceiver
>> [    2.190155] HS USB OTG: no transceiver configured
>> [    2.190155] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
>> with status -517
>> [    2.207458] platform musb-hdrc.0.auto: Driver musb-hdrc requests
>> probe deferral
>>
>> on 4430sdp with v3.10-rc1. Does that mean that the musb-hdrc.0.auto was
>> indeed correct, and the new value of musb-hdrc.2.auto is not?
> 
> Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
> like the some transceivers should depend on that for omap4.

Yes, I have OCP2SCP=y.

>> The musb-hdrc id is wrong on overo also.
> 
> Hmm has there been a fix posted for that?

I couldn't find with a quick look. We debugged and discussed this on an irc
channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
on overo fixed the issue, and it looks very similar to the error on 4430sdp.
The overo fix was just:



Is that ID "randomly" chosen? Doesn't that mean that it'll just get broken
every now and then?

 Tomi

--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Comments

Tony Lindgren May 16, 2013, 4:20 p.m. UTC | #1 
* Tomi Valkeinen <tomi.valkeinen@iki.fi> [130516 09:11]:
> On 16/05/13 18:58, Tony Lindgren wrote:
> > * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130515 03:59]:
> > 
> > Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
> > like the some transceivers should depend on that for omap4.
> 
> Yes, I have OCP2SCP=y.

Hmm well no idea beyond that then. Sounds like Kishon should check it.
 
> >> The musb-hdrc id is wrong on overo also.
> > 
> > Hmm has there been a fix posted for that?
> 
> I couldn't find with a quick look. We debugged and discussed this on an irc
> channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
> on overo fixed the issue, and it looks very similar to the error on 4430sdp.
> The overo fix was just:
> 
> diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
> index 4ca6b68..a496774 100644
> --- a/arch/arm/mach-omap2/board-overo.c
> +++ b/arch/arm/mach-omap2/board-overo.c
> @@ -472,7 +472,7 @@ static void __init overo_init(void)
>                                   mt46h32m32lf6_sdrc_params);
>         board_nand_init(overo_nand_partitions,
>                         ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
> -       usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
> +       usb_bind_phy("musb-hdrc.1.auto", 0, "twl4030_usb");
>         usb_musb_init(NULL);
>  
>         usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));
> 
> 
> Is that ID "randomly" chosen? Doesn't that mean that it'll just get broken
> every now and then?

Yes if so it's not a good solution. For omap4 we'll be flipping over to
be device tree only for v3.11, but that still leaves earlier omaps to
worry about.

I'll wait for a proper patch for the above for the -rc series after we
hear from Kishon.

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Kishon Vijay Abraham I May 17, 2013, 5:39 a.m. UTC | #2 
Hi,

On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote:
> * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130516 09:11]:
>> On 16/05/13 18:58, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130515 03:59]:
>>>
>>> Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
>>> like the some transceivers should depend on that for omap4.
>>
>> Yes, I have OCP2SCP=y.
>
> Hmm well no idea beyond that then. Sounds like Kishon should check it.
>
>>>> The musb-hdrc id is wrong on overo also.
>>>
>>> Hmm has there been a fix posted for that?
>>
>> I couldn't find with a quick look. We debugged and discussed this on an irc
>> channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
>> on overo fixed the issue, and it looks very similar to the error on 4430sdp.
>> The overo fix was just:

hmm.. I think using device name to bind the controller and the phy can 
no longer be used reliably. I think it's better to have something like 
what Grant suggested in my other patch series.. to have the phy 
reference into the host controllers platform_data structure. And for the 
phy reference I'll have label and id.

Does this makes sense to you?

Thanks
Kishon
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Tony Lindgren May 17, 2013, 5:23 p.m. UTC | #3 
* Kishon Vijay Abraham I <kishon@ti.com> [130516 22:45]:
> Hi,
> 
> On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote:
> >* Tomi Valkeinen <tomi.valkeinen@iki.fi> [130516 09:11]:
> >>On 16/05/13 18:58, Tony Lindgren wrote:
> >>>* Tomi Valkeinen <tomi.valkeinen@iki.fi> [130515 03:59]:
> >>>
> >>>Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
> >>>like the some transceivers should depend on that for omap4.
> >>
> >>Yes, I have OCP2SCP=y.
> >
> >Hmm well no idea beyond that then. Sounds like Kishon should check it.
> >
> >>>>The musb-hdrc id is wrong on overo also.
> >>>
> >>>Hmm has there been a fix posted for that?
> >>
> >>I couldn't find with a quick look. We debugged and discussed this on an irc
> >>channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
> >>on overo fixed the issue, and it looks very similar to the error on 4430sdp.
> >>The overo fix was just:
> 
> hmm.. I think using device name to bind the controller and the phy
> can no longer be used reliably. I think it's better to have
> something like what Grant suggested in my other patch series.. to
> have the phy reference into the host controllers platform_data
> structure. And for the phy reference I'll have label and id.
> 
> Does this makes sense to you?

Sounds OK to me, but I guess that would be for v3.11. I think we
still need a fix for at least overo for v3.10?

Regards,

Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Florian Vaussard May 21, 2013, 12:08 p.m. UTC | #4 
On 05/17/2013 07:23 PM, Tony Lindgren wrote:
> * Kishon Vijay Abraham I <kishon@ti.com> [130516 22:45]:
>> Hi,
>>
>> On Thursday 16 May 2013 09:50 PM, Tony Lindgren wrote:
>>> * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130516 09:11]:
>>>> On 16/05/13 18:58, Tony Lindgren wrote:
>>>>> * Tomi Valkeinen <tomi.valkeinen@iki.fi> [130515 03:59]:
>>>>>
>>>>> Just checking.. Do you have CONFIG_OMAP_OCP2SCP=y in your .config? Sounds
>>>>> like the some transceivers should depend on that for omap4.
>>>>
>>>> Yes, I have OCP2SCP=y.
>>>
>>> Hmm well no idea beyond that then. Sounds like Kishon should check it.
>>>
>>>>>> The musb-hdrc id is wrong on overo also.
>>>>>
>>>>> Hmm has there been a fix posted for that?
>>>>
>>>> I couldn't find with a quick look. We debugged and discussed this on an irc
>>>> channel with Kishon, who said he'll send a patch. Changing the musb-hdrc ID
>>>> on overo fixed the issue, and it looks very similar to the error on 4430sdp.
>>>> The overo fix was just:
>>
>> hmm.. I think using device name to bind the controller and the phy
>> can no longer be used reliably. I think it's better to have
>> something like what Grant suggested in my other patch series.. to
>> have the phy reference into the host controllers platform_data
>> structure. And for the phy reference I'll have label and id.
>>
>> Does this makes sense to you?
>
> Sounds OK to me, but I guess that would be for v3.11. I think we
> still need a fix for at least overo for v3.10?
>

Indead, musb-hdrc is broken on overo with 3.10-rc2. The patch posted in this
thread fixes the issue.

Regards,

Florian
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff mbox

Patch

diff --git a/arch/arm/mach-omap2/board-overo.c b/arch/arm/mach-omap2/board-overo.c
index 4ca6b68..a496774 100644
--- a/arch/arm/mach-omap2/board-overo.c
+++ b/arch/arm/mach-omap2/board-overo.c
@@ -472,7 +472,7 @@  static void __init overo_init(void)
                                  mt46h32m32lf6_sdrc_params);
        board_nand_init(overo_nand_partitions,
                        ARRAY_SIZE(overo_nand_partitions), NAND_CS, 0, NULL);
-       usb_bind_phy("musb-hdrc.0.auto", 0, "twl4030_usb");
+       usb_bind_phy("musb-hdrc.1.auto", 0, "twl4030_usb");
        usb_musb_init(NULL);
 
        usbhs_init_phys(phy_data, ARRAY_SIZE(phy_data));