From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Thu, 23 Jun 2016 01:02:44 +0200 Subject: [U-Boot] testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks In-Reply-To: References: <1466575944061.38274@alliedtelesis.co.nz> Message-ID: <576B1914.9070707@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 06/22/2016 08:36 AM, Rajesh Bhagat wrote: > > > From: Matthew Bright [mailto:Matthew.Bright at alliedtelesis.co.nz] > Sent: Wednesday, June 22, 2016 11:42 AM > To: Rajesh Bhagat ; marex at denx.de > Cc: u-boot at lists.denx.de; Chris Packham ; Mark Tomlinson > Subject: testing: [PATCH v7 0/3] common: usb_storage: Implement logic to calculate optimal usb maximum trasfer blocks > > On 06/16/2016 12:35 PM, Rajesh Bhagat wrote: >> Performs code cleanup by making common function for usb_stor_read/write >> and implements the logic to calculate the optimal usb maximum trasfer blocks >> instead of sending USB_MAX_XFER_BLK blocks which is 65535 and 20 in case >> of EHCI and other USB protocols respectively. >> >> Rajesh Bhagat (3): >> common: usb_storage: Make common function for usb_read_10/usb_write_10 >> common: usb_storage: Make common function for >> usb_stor_read/usb_stor_write >> common: usb_storage : Implement logic to calculate optimal usb maximum >> trasfer blocks >> >> common/usb_storage.c | 213 +++++++++++++++++++++++---------------------------- >> include/usb.h | 1 + >> 2 files changed, 98 insertions(+), 116 deletions(-) >> >> >> Hi Rajesh & Marek >> >> I have spend the last couple of days testing these patches on the >> v2016.05 release, with an usb mass storage device that is able to >> consistently reproduce the USB_MAX_XFER_BLK issue as described in >> the "Issue with USB mass storage (thumb drives)" u-boot thread. >> >> http://lists.denx.de/pipermail/u-boot/2016-February/244464.html? >> > > Hello Matt, > >> I can confirm the patch correctly increases the max transfer bocks >> after a successful read, and decreases the max transfer bocks after >> a read failure. However, I have noticed that once the ehci time out >> error occurs, the usb device appears to lock up. When in this state >> the usb device will stop responding to any further transfers. This >> behavior is independent of the number of blocks, and will continue >> until the ehci has been reset. >> > > I believe the lockup behavior mentioned by you to be device specific quirk. > I tested 3 pen drives, which recovered from EHCI timeout behavior by > reducing the number of blocks (check below output): > 3 devices is not a representative sample. -- Best regards, Marek Vasut