Date: Tue, 16 Dec 2008 19:51:52 +0100 From: Hans Petter Selasky <hselasky@c2i.net> To: Sam Leffler <sam@freebsd.org> Cc: Perforce Change Reviews <perforce@freebsd.org> Subject: Re: PERFORCE change 154573 for review Message-ID: <200812161951.54051.hselasky@c2i.net> In-Reply-To: <4947F310.5050403@freebsd.org> References: <200812122326.mBCNQX6w024511@repoman.freebsd.org> <200812161722.06337.hselasky@c2i.net> <4947F310.5050403@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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]=3D0x014b8a3c > buffer[1]=3D0x00000000 > buffer[2]=3D0x00000000 > buffer[3]=3D0x00000000 > buffer[4]=3D0x00000000 > > to: > > buffer[0]=3D0x014b8a3c > buffer[1]=3D0x00000008 > buffer[2]=3D0x00000000 > buffer[3]=3D0x00000000 > buffer[4]=3D0x00000000 > The other 32-bit words are used to store subsequent 4K memory pages that=20 should be part of the transfer. In your case only one field is initialised= =20 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]=3D0x01091fc8 > > > > vs: > > > > buffer[0]=3D0x014b8a3c > > > > - 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 pack= et > > (PID=3D2), 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? =20 =46rom the USB device. I guess something is wrong with the request being se= nt. > Am I actually talking to the device? =20 Most likely. Check the EHCI specification when the QTD_HALTED bit is set. A= n=20 USB cable analyzer would answer this question for sure. For example there a= re=20 some from Beagle that can be used with Linux. > It appears the =20 > 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. =2D-HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200812161951.54051.hselasky>