[U-Boot] [[PATCH v2 5/6] USB: ehci: Add a weak function for resetting devices
Marek Vasut
marex at denx.de
Mon Jul 15 05:19:22 CEST 2013
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
More information about the U-Boot
mailing list