PERFORCE change 154573 for review

[Hans Petter Selasky]

On Monday 15 December 2008, Sam Leffler wrote:
> Hans Petter Selasky wrote:
> > On Saturday 13 December 2008, Sam Leffler wrote:
> >> Hans Petter Selasky wrote:
> >>> On Saturday 13 December 2008, Sam Leffler wrote:
> >>
> >> No.  But if you are interested in helping debug the problem I'm happy to
> >> send you debug output.  The controller rejects all cmds setting the
> >> ERRINT status bit.  The qTD contents and xfer contents look fine but I
> >> haven't been able to identify the cause given the overlay qTD contents.
> >> I'm in the process of collecting comparative traces from linux where usb
> >> works.
> >
> > Send me the EHCI traces and I will have a look at it. Have you tried
> > USB2? The patches which you need to apply should be similar.
>
> This is what I get w/ sysctl hw.usb.ehci.debug=6 for the first cmd
> submitted after card insert:
>

>
> Subsequent cmds fail similarly.  I don't see the issue and don't
> understand how to use the overlay qTD information to pinpoint the reason
> the controller is rejecting the request.
>
> This happens w/ either of the 2 USB ports (1 port / controller):
>

Hi Sam,

The overlay qTD is a copy of the last processed QTD. You might need to do a 
cache invalidate on the memory region before reading it.

What I see:

- The first TD completed successfully, and that TD had a lower physical memory 
adddress than the one that failed.

 buffer[0]=0x01091fc8

vs:

 buffer[0]=0x014b8a3c

- Halted usually means that that you had a STALL token sent from the device to 
the host, which indicates that the contents of the SETUP packet (PID=2), in 
the first TD did not contain valid data, possible due to a missing cache 
flush.

        return ((status & EHCI_QTD_HALTED) ?
            USB_ERR_STALLED : USB_ERR_NORMAL_COMPLETION);

--HPS