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@st-md-mailman.stormreply.com https://st-md-mailman.stormreply.com/mailman/listinfo/uboot-stm32