[U-Boot] [PATCH] usb: dwc2: Enhance interrupt handling for CONTROL transaction

[Marek Vasut <marex@denx.de>]

On Thursday, January 14, 2016 at 04:20:12 PM, Marek Vasut wrote:
> On Thursday, January 14, 2016 at 03:50:18 PM, Chin Liang See wrote:
> > On Wed, 2016-01-13 at 16:22 +0100, Marek Vasut wrote:
> > > On Wednesday, January 13, 2016 at 04:18:43 PM, Chin Liang See wrote:
> > > > On Wed, 2016-01-13 at 03:58 +0100, Marek Vasut wrote:
> > > > > On Tuesday, January 05, 2016 at 05:16:05 PM, Marek Vasut wrote:
> > > > > > On Tuesday, January 05, 2016 at 04:51:47 PM, Chin Liang See
> > > > > > 
> > > > > > wrote:
> > > > > > > On Tue, 2016-01-05 at 15:36 +0100, Marek Vasut wrote:
> > > > > > > > On Tuesday, January 05, 2016 at 06:00:04 AM, Chin Liang See
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > Per DesignWare USB OTG databook, driver should retry up
> > > > > > > > > to
> > > > > > > > > 3 times when transaction error (hcint.xacterr) happen.
> > > > > > > > > But
> > > > > > > > > the 3 times doesn't count when the response is nack
> > > > > > > > > (hcint.nak) or frame overrun (hcint.frmoverun)
> > > > > > > > > 
> > > > > > > > > This patch solved the enumeration error as spotted at
> > > > > > > > > socfpga
> > > > > > > > > cyclone5_socdk when plugging in certain pendrive.
> > > > > > > > > 
> > > > > > > > > Signed-off-by: Chin Liang See <clsee@altera.com>
> > > > > > > > > Cc: Marek Vasut <marex@denx.de>
> > > > > > > > > Cc: Dinh Nguyen <dinguyen@opensource.altera.com>
> > > > > > > > > Cc: Dinh Nguyen <dinh.linux@gmail.com>
> > > > > > > > > Cc: Pavel Machek <pavel@denx.de>
> > > > > > > > > Cc: Oleksandr Tymoshenko <gonzo@bluezbox.com>
> > > > > > > > > Cc: Stephen Warren <swarren@wwwdotorg.org>
> > > > > > > > > Cc: Alexander Stein <alexanders83@web.de>
> > > > > > > > > Cc: Peter Griffin <peter.griffin@linaro.org>
> > > > > > > > 
> > > > > > > > I applied this change on top of u-boot-socfpga/master and
> > > > > > > > tested it
> > > > > > > > on
> > > > > > > > SoCFPGA CycloneV SoCDK with "Sandisk cruzer force" stick.
> > > > > > > > The
> > > > > > > > board
> > > > > > > > gets
> > > > > > > > completely stuck if I have dcache ENABLED and perform 'usb
> > > > > > > > reset'.
> > > > > > > > This
> > > > > > > 
> > > > > > > > patch is:
> > > > > > > Thanks Marek for testing. I managed to find a SanDisk Cruzer
> > > > > > > Blade and
> > > > > > > notice the same fail behaviours as yours. FYI, note that this
> > > > > > > patch
> > > > > > > works well with other 3 pendrive that I have.
> > > > > > > 
> > > > > > > With SanDisk, the dwc2 driver was timed out as hcint.xfercomp
> > > > > > > and
> > > > > > > chhltd never get set even after 1s. It keep retrying
> > > > > > > endlessly
> > > > > > > due to
> > > > > > > miss handling for the ETIMEDOUT within this patch.
> > > > > > > 
> > > > > > > In short, the retry doesn't work for SanDisk but the dcache
> > > > > > > disable
> > > > > > > works. Need to figure out more what cause the failure.
> > > > > > 
> > > > > > Excellent, I have one of those too (I bought the entire lineup
> > > > > > of
> > > > > > these
> > > > > > sandisk sticks at one point ;-) )
> > > > > 
> > > > > Hi, any news on the SoCFPGA USB/QSPI problem investigation?
> > > > > Thanks!
> > > > 
> > > > I am still troubleshooting it. I played with few configuration
> > > > within
> > > > L3 but not helping. This including avoiding multiple outstanding
> > > > transaction and security (allow both secure and non secure).
> > > 
> > > Yeah
> > > 
> > > > But all these issue will gone once dcache is off. I believe need to
> > > > visit the MMU table.
> > > 
> > > I was there already ;-) But given enough eyeballs, are bugs are
> > > shallow.
> > 
> > Continue some troubleshooting today. Notice some behavior change where
> > the SanDisk Cruzer Blade failed after POR and dcache disable.
> > 
> > After enabling the debug message, the hub is complaining over current
> > (port change = 0x9) on the port where pen drive is plugged in. The port
> > status = 0x10 indicate no device present.
> > 
> > Appreciate any quick advise while digging more the hub spec.
> 
> I suspect the data are corrupted somewhere. I wouldn't trust the content
> of the descriptor at that point.

Hi, any news on the USB mess ? :-)