[U-Boot] [PATCH v4 1/2] usb: ehci: add Faraday USB 2.0 EHCI support

Kuo-Jung Su
2013-05-09T01:51:10Z

2013/5/8 Marek Vasut <marex@denx.de>:
> Dear Kuo-Jung Su,
>
>> 2013/5/8 Marek Vasut <marex@denx.de>:
>> > Dear Kuo-Jung Su,
>> >
>> > [...]
>> >
>> >> >> --- a/common/usb_hub.c
>> >> >> +++ b/common/usb_hub.c
>> >> >> @@ -419,6 +419,14 @@ static int usb_hub_configure(struct usb_device
>> >> >> *dev)
>> >> >>
>> >> >> portstatus = le16_to_cpu(portsts->wPortStatus);
>> >> >> portchange = le16_to_cpu(portsts->wPortChange);
>> >> >>
>> >> >> +#ifdef CONFIG_USB_EHCI_FARADAY
>> >> >> + /* Faraday EHCI needs a long long delay here */
>> >> >> + if (!portchange && !portstatus) {
>> >> >> + if (get_timer(start) < 250)
>> >> >> + continue;
>> >> >> + }
>> >> >> +#endif
>> >> >
>> >> > I'd say just call a weak function here, in case some other non-EHCI
>> >> > compliant controller happened to need this too. btw. does it need to
>> >> > be 250 ms or can you poll for readiness somehow ?
>> >>
>> >> Got it, thanks. I'll add a weak function later,
>> >> and about the 250 ms is actually an estimated value.
>> >> The delay time is actually board specific, it looks to me
>> >> that it's somehow related to the number of usb host controllers
>> >> and the attached usb flash drivers.
>> >>
>> >> For example:
>> >>
>> >> 1. A369 - FUSBH200: a usb flash driver attached
>> >>
>> >> A369 - FOTG210: nothing attached
>> >>
>> >> => no extra delay required.
>> >>
>> >> 2. A369 - FUSBH200: nothing attached
>> >>
>> >> A369 - FOTG210: a usb flash driver attached
>> >>
>> >> => no extra delay required.
>> >>
>> >> 3. A369 - FUSBH200: a usb flash driver attached
>> >>
>> >> A369 - FOTG210: a usb flash driver attached
>> >>
>> >> => The 2nd ehci host requires 200 ms extra delay to detect the attached
>> >> device. So I put a 250ms here for safe.
>> >
>> > Urgh, isn't it a PHY problem then? Or can this not be solved like
>> > board/genesi/mx51_efikamx/efikamx-usb.c board_ehci_hcd_postinit() or such
>> > function?
>>
>> It looks to me that it's something related to root hub reset.
>> And now I've found that adding a extra delay to usb_hub_power_on()
>> would help to resolve this issue.
>> So I plan to add a new macro constant for it.
>> For example:
>>
>> 1. Add this to README:
>> CONFIG_USB_HUB_MIN_POWER_ON_DELAY defines the minimum
>> interval for usb hub power-on delay.(minimum 100msec)
>>
>> 2. Update usb_hub.c as bellow:
>> static void usb_hub_power_on(struct usb_hub_device *hub)
>> {
>> ......
>> /* Wait at least 100 msec for power to become stable */
>> mdelay(max(pgood_delay, USB_HUB_MIN_POWER_ON_DELAY));
>> }
>
> Let's try it.
>

Got it, thanks

> Best regards,
> Marek Vasut

--
Best wishes,
Kuo-Jung Su