PERFORCE change 154573 for review

[Hans Petter Selasky]

Hi Sam,

On Tuesday 16 December 2008, Sam Leffler wrote:
>
> > 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.
>
> Yes, this is what the docs says about the overlay qTD but what do the
> 2nd and later words mean?  They went from:
>
> buffer[0]=0x014b8a3c
> buffer[1]=0x00000000
> buffer[2]=0x00000000
> buffer[3]=0x00000000
> buffer[4]=0x00000000
>
> to:
>
> buffer[0]=0x014b8a3c
> buffer[1]=0x00000008
> buffer[2]=0x00000000
> buffer[3]=0x00000000
> buffer[4]=0x00000000
>

The other 32-bit words are used to store subsequent 4K memory pages that 
should be part of the transfer. In your case only one field is initialised 
because the length is less than "0x1000 - (0x014b8a3c & 0xFFF)" bytes.

> All memory allocated to hold usb data structures are allocated coherent
> so should not require an invalidate.  I have also inserted explicit
> dcache invalidates while debugging this issue "just in case".

Ok.

>
> USB works fine on another xscale platform where the usb controller is on
> the pci bus so I'd expect any cache coherency issues to already be dealt
> with (I found the PIO cache invalidate issue I fixed a while back on
> this other board).
>
> > 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);
>
> So maybe this answers one question I have; is this error from the device
> or the controller?  

From the USB device. I guess something is wrong with the request being sent.

> Am I actually talking to the device?  

Most likely. Check the EHCI specification when the QTD_HALTED bit is set. An 
USB cable analyzer would answer this question for sure. For example there are 
some from Beagle that can be used with Linux.

> It appears the  
> controller is functional as I get interrupts, get status for things like
> ports, etc.  Remember this is a big-endian host.  On another xscale
> platform the usb controller is on the pci bus and we setup xfers
> (dma+pio) to be swizzled by the byte lane hardware so everything just
> works wrt little-endian-ness.  I've been searching for something
> byte-order related that is missing.  The linux usb code swizzles
> descriptor contents on the host but I don't see it doing anything to the
> data sent to the device; it's still little-endian.

--HPS