[U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices

Dan Murphy dmurphy at ti.com
Tue Jul 16 22:19:56 CEST 2013


Marek
On 07/14/2013 10:19 PM, Marek Vasut wrote:
> Dear Dan Murphy,
>
>> Roger
>>
>> On 07/11/2013 09:23 AM, Roger Quadros wrote:
>>> Hi Marek,
>>>
>>> On 07/11/2013 03:35 PM, Marek Vasut wrote:
>>>> Dear Roger Quadros,
>>>>
>>>>> On 07/11/2013 02:16 AM, Dan Murphy wrote:
>>>>>> On 07/10/2013 05:20 PM, Marek Vasut wrote:
>>>>>>> Dear Dan Murphy,
>>>>>>>
>>>>>>>> Add a __weak function that can be overridden to reset devices
>>>>>>>> attached to an ehci devices after the FEAT_POWER has been submitted
>>>>>>>>
>>>>>>>> Signed-off-by: Dan Murphy <dmurphy at ti.com>
>>>>>>>> ---
>>>>>>>>
>>>>>>>>  drivers/usb/host/ehci-hcd.c |    7 +++++++
>>>>>>>>  1 file changed, 7 insertions(+)
>>>>>>>>
>>>>>>>> diff --git a/drivers/usb/host/ehci-hcd.c
>>>>>>>> b/drivers/usb/host/ehci-hcd.c index 706cf0c..fdd3994 100644
>>>>>>>> --- a/drivers/usb/host/ehci-hcd.c
>>>>>>>> +++ b/drivers/usb/host/ehci-hcd.c
>>>>>>>> @@ -616,6 +616,11 @@ __weak uint32_t
>>>>>>>> *ehci_get_portsc_register(struct ehci_hcor *hcor, int port) return
>>>>>>>> (uint32_t *)&hcor->or_portsc[port];
>>>>>>>>
>>>>>>>>  }
>>>>>>>>
>>>>>>>> +__weak void ehci_reset_attached_devices(int port)
>>>>>>>> +{
>>>>>>>> +	return;
>>>>>>>> +}
>>>>> Does this function need to be ehci specific? Other USB controllers
>>>>> might also need such a function.
>>>> You'd need to implement this for each of the xHCIs
>>> OK.
>> I can move the API to the usb-hub to call this after the FEAT_POWER is
>> completed
>>
>>>>>>>> +
>>>>>>> Can the reset not happen elsewhere?
>>>>>> I have tried to move this around and keep this out of this file
>>>>>> completely but nothing else seems to work.
>>>>>>
>>>>>> For port 2 where the USB3530 is we don't have the issue the 3530
>>>>>> enumerates properly.
>>>>>>
>>>>>> I did not see any information in the data sheet eluding to a timing
>>>>>> issue.
>>>>> This is the information I had received earlier from SMSC about USB3503A
>>>>> hub
>> This has nothing to do with the 3503A this is the LAN9730.  The 3503 works
>> just fine without the additional reset.
>>
>>>>> "You need the host up and running, and ready to go, THEN negate
>>>>> RESET_N. That is probably 95% of the issues."
>>>>>
>>>>> Please make sure the following sequence is done.
>>>>>
>>>>> - power up hub (RESET is active at this point).
>>>>> - start USB controller
>>>>> - wait a few ms
>>>>> - release hub RESET.
>>>>>
>>>>> giving a quick look at the u-boot code it seems you need to release the
>>>>> hub reset after usb_lowlevel_init() _OR_ usb_init() returns.
>>>> Then it would also work in usb_lowlevel_init() ?
>>> It should as long as we place the "release reset" after EHCI controller
>>> has started. Maybe safer to put it in the end of usb_lowlevel_init().
>>>
>>> cheers,
>>> -roger
>> I moved the reset to the usb_lowlevel_init and it did not work.
>> I tried holding the 9730 in reset until after ehci hcd init is complete and
>> pulled it out of reset once the hcd is initialized but still no
>> enumeration.
> Can you try waiting a little after negating the reset ? It might be that the 
> device takes some time to come back to life.
>
> Best regards,
> Marek Vasut
I have tried that.

I have a more general less invasive patch set I am going to submit.

It will place the last two patches that in in disagreement at the end of the set so at least we can get the initial ones in.

Dan

-- 
------------------
Dan Murphy



More information about the U-Boot mailing list