On 05/20/2016 07:07 AM, Rajesh Bhagat wrote: > > >> -----Original Message----- >> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Marek Vasut >> Sent: Tuesday, May 10, 2016 6:02 PM >> To: Diego <diego...@zoho.com> >> Cc: u-boot@lists.denx.de; Stefan Roese <s...@denx.de> >> Subject: Re: [U-Boot] Issue with USB mass storage (thumb drives) >> >> On 05/10/2016 02:04 PM, Diego wrote: >>> In data mercoledì 4 maggio 2016 23:36:46, Marek Vasut ha scritto: >>>> On 05/04/2016 04:06 PM, Diego wrote: >>>>> In data mercoledì 4 maggio 2016 13:45:57, Marek Vasut ha scritto: >>>>>> On 05/04/2016 11:13 AM, Diego wrote: >>>>>>> <snip> >>>>>>> So I see three options: >>>>>>> 1) 65535 default with quirk table >>>>>>> 2) 32767 default without quirk table >>>>>>> 3) 32767 default with quirk table >>>>>>> >>>>>>> Personally I think 3) would be the safest solution, but I think 2) >>>>>>> would at least work for most thumb drives. >>>>>> >>>>>> 1) with the quirk table would be the way to go, modern(ish) drives >>>>>> should work fine with 65535 . >>>>> >>>>> I personally can't see any improvement with more recent thumb >>>>> drives, quite the opposite. >>>>> >>>>> <snip> >>>>> Why are you saying modern(ish) drives should work? >>>> >>>> Hmmmmm :-( >>>> >>>>> For others following the thread, please post your experience, >>>>> especially with more recent drives (remember to test with files >16MB). >>>> >>>> I don't think it's really worth doing a thread about which sticks >>>> work and which don't. I would find it much more valuable to address >>>> this issue properly. I wonder if it would make sense to, instead of >>>> starting with a big value which might not work, start with a >>>> small(er) value and increase it with each subsequent block transfer. >>>> Quite similarly to what TCP does. Would you be willing to look into it ? >>>> >>> >>> Hi Marek, >> >> Hi! >> >>> so your proposal is to ramp up transferred block size during transfer? >>> What's the rationale behind the proposal? In other words, why do you >>> think it will fix the problem? >> >> You will get one transfer failure somewhere in the middle and this will let >> you >> determine the maximum transfer size for particular stick. >> >>> Regarding implementing your proposal, it might take me very long to >>> find some time to dedicate to it, so if anybody else wants to step up >>> before I look at it, just raise your hand. >> >> OK >> > > Hello Marek, > > I have a question regarding USB_MAX_XFER_BLK macro, Why XHCI code doesn't > seem to > focus on this value and is not impacted, kept the value so low i.e. 20? > > #ifdef CONFIG_USB_EHCI > /* > * The U-Boot EHCI driver can handle any transfer length as long as there is > * enough free heap space left, but the SCSI READ(10) and WRITE(10) commands > are > * limited to 65535 blocks. > */ > #define USB_MAX_XFER_BLK 65535 > #else > #define USB_MAX_XFER_BLK 20 > #endif > > Common code suggests it is used in same way as used in EHCI. Please comment.
The MAX_XFER_BLK = 20 was for OHCI/UHCI, so the code should likely be patches to set it to higher value for XHCI. Feel free to test and send a patch. Thanks Best regards, Marek Vasut _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot