Dear Anatolij,
In message <aanlktikbnmdtjncjd-pjehwsw+ng8stf1izt1utg6...@mail.gmail.com> Remy
Bohmer wrote:
> Hi,
>
> 2010/8/31 Anatolij Gustschin <ag...@denx.de>:
> > Checking the status field of the qTD token in the current code
> > do not take into acount cases where endpoint stall (halted) bit
> > is set together with some other status bits. As a result clearing
> > stall on an endpoint won't be done if other status bits were set.
>
> Reading this description and this code:
>
> > /* special handling of STALL in DATA phase */
> > - if ((result < 0) && (us->pusb_dev->status & USB_ST_STALLED)) {
> > + if ((result < 0) &&
> > + (us->pusb_dev->status & (USB_ST_STALLED | USB_ST_CRC_ERR))) {
> > USB_STOR_PRINTF("DATA:stall\n");
>
> Description and code do not seem to match. The old implementation
> explicitly checked if the STALLED bit was set, and if so the endpoint
> would be cleared. Now, it seems you are clearing the endpoint _also_
> when the CRC_ERR bit is set.
>
> There are a lot more reasons, at least on other host controllers that
> set the status USB_ST_CRC_ERR, does this change not break the other
> code? (A simple grep will show you the situations where it is
> returned.)
>
> > E.g. 'usb start' often fails with Toshiba USB stick 0x930/0x6545
> > connected to the SMSC USB 2.0 hub 0x424/0x2514. Debugging the
> > issue showed that while bulk IN transfers with length of 13 or
> > 18 the status field of the qTD token sometimes indicates trans-
> > action error (XactErr) and sometimes additionally endpoint halted
> > state. In the latter case resetting the USB device in error
> > recovery code fails as no clear stall request on the endpoint
> > will be done.
>
> OK
>
> > However this fix is not enough to solve 'usb start' problem
> > with hub/stick combination mentioned above. Running with lot of
> > debug code in ehci_submit_async() I've never seen the problem
> > with usb stick recognition. After removing this debug code the
> > similar problem sometimes showed up again. Therefore the patch
> > also adds delay in ehci_submit_async() for above-mentioned
> > hub/stick combination. Even without this delay the fix is an
>
> Why only for these USB sticks? Are these sticks special among the
> thousands of different sticks out there?
> Or could it be more reliable to always do this delay for all USB
> sticks? Or even better, what are we missing here that the delay is
> needed at all?
>
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-hcd.c
> > index 37d056e..7463a75 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
>
> Is this problem only valid for the EHCI code? I can imagine that the
> other host controllers (like UHCI and OHCI and so on) code suffer the
> same problem and need similar fixes...
> (At least I know that I have here a couple of USB sticks that show
> similar problems with OHCI ;-) )
As far as I can tell you never replied to thesequestions, with the
result that this patch did not make it into mainline yet.
Could you please have a look? Thanks.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: w...@denx.de
An expert is a person who avoids the small errors while sweeping on
to the grand fallacy.
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
