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 ?
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 ?
