[U-Boot] [PATCH v2] usbh/ehci: Increase timeout for enumeration

[Vipin Kumar <vipin.kumar@st.com>]

On 12/7/2012 3:48 PM, Igor Grinberg wrote:
>
>
> On 12/07/12 12:03, Igor Grinberg wrote:
>> On 12/07/12 10:58, Vipin Kumar wrote:
>>> The current logic reads the port status just once after usb_hub_power_on and
>>> expects the portstatus and portchange to report the connection status
>>> immediately and correctly.
>>>
>>> Few pen drives are not able to report both of them immediately ie. those pens
>>> report the connection change but not the connected state after the first read.
>>> This opportunity once lost is gone for ever because the u-boot, unlike linux or
>>> any other OS, works in polling mode.
>>>
>>> This patch modifies the logic to read the port status continuously until the
>>> portstatus and portchange both report a connection change as well as a connected
>>> state or no connection change and no connection. This logic is placed in a
>>> timeout of 10 sec. At the end of it, the pen drive would have either reported a
>>> ONE or a ZERO in bit 1 of portstatus as well as portchange.
>>>
>>> It enhances the set of pen drives which can eventually be detected by u-boot
>>>
>>> Signed-off-by: Vipin Kumar<vipin.kumar@st.com>
>>> ---
>>> Hello Marek, Igor,
>>>
>>> I found another way to handle it. Please let me know if it is OK from the USB
>>> stack poit of view. The fact is that a few pens do not report a connected status
>>> in portstatus while they report a connection change in portchange after a
>>> usb_hub_power_on.
>>>
>>> In this patch, I have tried to compare the connection bit from portstatus and
>>> portchange for a timeout of 10 seconds. The situation is asumed to be stable
>>> once both of them report the same. This seems to have increased the set of pens
>>> supported by u-boot without any apparent side effect
>>>
>>> Please let me know if this is OK from your side
>>
>> Basically, this one looks fine, although I have two minor concerns below.
>>
>>>
>>> Regards
>>> Vipin
>>>
>>>   common/usb_hub.c | 25 ++++++++++++++++++++-----
>>>   1 file changed, 20 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/common/usb_hub.c b/common/usb_hub.c
>>> index e4a1201..3a66b0e 100644
>>> --- a/common/usb_hub.c
>>> +++ b/common/usb_hub.c
>>> @@ -396,14 +396,29 @@ static int usb_hub_configure(struct usb_device *dev)
>>>   	for (i = 0; i<  dev->maxchild; i++) {
>>>   		ALLOC_CACHE_ALIGN_BUFFER(struct usb_port_status, portsts, 1);
>>>   		unsigned short portstatus, portchange;
>>> +		int ret;
>>> +		ulong start = get_timer(0);
>>> +
>>> +		do {
>>> +			ret = usb_get_port_status(dev, i + 1, portsts);
>>> +			if (ret<  0) {
>>> +				USB_HUB_PRINTF("get_port_status failed\n");
>>> +				break;
>>> +			}
>>> +
>>> +			portstatus = le16_to_cpu(portsts->wPortStatus);
>>> +			portchange = le16_to_cpu(portsts->wPortChange);
>>> +
>>> +			if ((portchange&  USB_PORT_STAT_C_CONNECTION) ==
>>> +				(portstatus&  USB_PORT_STAT_CONNECTION))
>>
>> I don't know if there is any corner case when the above check
>> will always fail and so it will always wait a maximal delay time.
>> Are those registers that identical, or can there be differences?
>
> Never mind, my mistake, USB_PORT_STAT_C_CONNECTION and USB_PORT_STAT_CONNECTION
> are the same bit in the register.
>
>>
>>> +				break;
>>> +
>>> +			mdelay(100);
>>> +		} while (get_timer(start)<  CONFIG_SYS_HZ * 10);
>>
>> Is there any justification for the CONFIG_SYS_HZ * 10?
>> I would be much more fine with this patch if there were any
>> (even just test based * 2) reason for that number.
>
> Once you address this one, feel free to add:
> Acked-by: Igor Grinberg<grinberg@compulab.co.il>
>

Thanks Igor, let me wait for Marek's comments also

>>
>>>
>>> -		if (usb_get_port_status(dev, i + 1, portsts)<  0) {
>>> -			USB_HUB_PRINTF("get_port_status failed\n");
>>> +		if (ret<  0)
>>>   			continue;
>>> -		}
>>>
>>> -		portstatus = le16_to_cpu(portsts->wPortStatus);
>>> -		portchange = le16_to_cpu(portsts->wPortChange);
>>>   		USB_HUB_PRINTF("Port %d Status %X Change %X\n",
>>>   				i + 1, portstatus, portchange);
>>>
>>
>