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@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.
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
"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