On 05/04/2016 09:41 AM, Stefan Roese wrote:
On 03.05.2016 22:51, Marek Vasut wrote:
Some devices, like the SanDisk Cruzer Pop need some time to process the Set Configuration request, so wait a little until they are ready.
Signed-off-by: Marek Vasut marex@denx.de Cc: Chin Liang See clsee@altera.com Cc: Dinh Nguyen dinguyen@opensource.altera.com Cc: Hans de Goede hdegoede@redhat.com Cc: Stefan Roese sr@denx.de Cc: Stephen Warren swarren@nvidia.com
common/usb.c | 8 ++++++++ 1 file changed, 8 insertions(+)
diff --git a/common/usb.c b/common/usb.c index 63429d4..205041b 100644 --- a/common/usb.c +++ b/common/usb.c @@ -1107,6 +1107,14 @@ int usb_select_config(struct usb_device *dev) "len %d, status %lX\n", dev->act_len, dev->status); return err; }
- /*
* Wait until the Set Configuration request gets processed by the* device. This is required by at least SanDisk Cruzer Pop USB 2.0* and Kingston DT Ultimate 32GB USB 3.0 on DWC2 OTG controller.*/- mdelay(10);
debug("new device strings: Mfr=%d, Product=%d, SerialNumber=%d\n", dev->descriptor.iManufacturer, dev->descriptor.iProduct, dev->descriptor.iSerialNumber);As you might have expected, I'm not a fan of adding new delays to the common USB code. As this negatively affects all platforms. Did you test these two sticks that require this delay on other platforms than SoCFPGA?
Yes, on intel. Many microframes pass between these control EP requests, while on the dwc2 in u-boot, quite a few of these requests end in the same microframe because the code is fast, which is what the stick does not like.
I would be very interested to know, if these keys are successfully detected without this patch on other platforms. I don't have access to these USB keys, so I can't test it on my platforms.
Thanks, Stefan