[Uboot-stm32] [PATCH v2 1/2] usb: hub: allow to increase HUB_DEBOUNCE_TIMEOUT

[Patrick DELAUNAY]

Hi,

On 9/24/22 19:04, Marek Vasut wrote:
> On 9/12/22 15:37, Patrick DELAUNAY wrote:
>> Hi,
>
> Hi,
>
>> On 9/9/22 14:24, Marek Vasut wrote:
>>> On 9/9/22 11:45, Patrick Delaunay wrote:
>>>> Add a new CONFIG_USB_HUB_DEBOUNCE_TIMEOUT to increase the
>>>> HUB_DEBOUNCE_TIMEOUT value, for example to 2s because some usb device
>>>> needs around 1.5s or more to make the hub port status to be
>>>> connected steadily after being powered off and powered on.
>>>>
>>>> This 2s value is aligned with Linux driver and avoids to configure
>>>> "usb_pgood_delay" as a workaround for connection timeout on
>>>> some USB device; normally the env variable "usb_pgood_delay" is used
>>>> to delay the first query after power ON and thus the device answer,
>>>> but this variable not used to increase the connection timeout delay.
>>>
>>> I realized this has one problem -- what happens if you have multiple 
>>> USB controllers in your system ? The answer is, all of them are 
>>> affected by the increased delay, possibly even those which do not 
>>> require the extra delay.
>>>
>>> Would it be possible to configure this per-controller (or should 
>>> this even be per-device?) in DT ? In fact, I wonder whether this is 
>>> not becoming a Vbus regulator ramp-up time kind of delay here ?
>>
>>
>> Yes, but I don't think, it is blocking.
>>
>> This timeout will be common for all the USB HUB in the system, as it 
>> is done in Linux kernel.
>
> I just realized this is not the same delay as the usb_pgood_delay, 
> right ?
>

Yes it is 2 different timeout in USB stack, usb_scan_port()

1/ pgood_delay used in

      hub->query_delay = get_timer(0) + max(100, (int)pgood_delay);

      => time before the devices are queried


      * Don't talk to the device before the query delay is expired.
      * This is needed for voltages to stabalize.

2/ HUB_DEBOUNCE_TIMEOUT used in

     hub->connect_timeout =  hub->query_delay + HUB_DEBOUNCE_TIMEOUT

     => timeout (max)   for usb_get_port_status() answer OR No 
connection change happened (portchange/portstatus)



> This is actually the maximum wait for a device to start communicating, 
> i.e. even if this timeout is set to a very high value, most devices 
> will not take that long and will start communicating in shorter time 
> anyway, so the time of completion for e.g. '=> usb reset' is not 
> affected by this change on very much all systems, correct ?


Yes  as it is a max value, it is a protection timeout for problematic 
devices,

it should not occur for normal use case, but only when the device are 
correctly detected on the HUB port...


I think the the 'usb reset' sequence  is impacted:

  usb_init => usb_new_device => usb_hub_probe => usb_hub_configure =

   - usb_hub_power_on()

    -usb_device_list_scan()


But as it is a CONFIG it is a platform choice.


Regards


> _______________________________________________
> Uboot-stm32 mailing list
> Uboot-stm32 at st-md-mailman.stormreply.com
> https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32