From owner-p4-projects@FreeBSD.ORG Tue Dec 16 19:49:41 2008 Return-Path: Delivered-To: p4-projects@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 32767) id 011851065677; Tue, 16 Dec 2008 19:49:41 +0000 (UTC) Delivered-To: perforce@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9FF35106564A; Tue, 16 Dec 2008 19:49:40 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe16.tele2.se [212.247.155.225]) by mx1.freebsd.org (Postfix) with ESMTP id D574D8FC1F; Tue, 16 Dec 2008 19:49:39 +0000 (UTC) (envelope-from hselasky@c2i.net) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.0 c=1 a=9QZaWaqL03AA:10 a=P3SC899gXHkOLDnkTYxLZw==:17 a=6qg7fpzqtNTjt-6BxOgA:9 a=ZMOo19WPgtzKbKUQDrUA:7 a=lp1h9MYjMOLdfV-ewx9a6K9jSOkA:4 a=50e4U0PicR4A:10 Received: from [62.113.133.240] (account mc467741@c2i.net [62.113.133.240] verified) by mailfe16.swip.net (CommuniGate Pro SMTP 5.2.6) with ESMTPA id 424047508; Tue, 16 Dec 2008 19:49:36 +0100 From: Hans Petter Selasky To: Sam Leffler Date: Tue, 16 Dec 2008 19:51:52 +0100 User-Agent: KMail/1.9.7 References: <200812122326.mBCNQX6w024511@repoman.freebsd.org> <200812161722.06337.hselasky@c2i.net> <4947F310.5050403@freebsd.org> In-Reply-To: <4947F310.5050403@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200812161951.54051.hselasky@c2i.net> Cc: Perforce Change Reviews Subject: Re: PERFORCE change 154573 for review X-BeenThere: p4-projects@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: p4 projects tree changes List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Dec 2008 19:49:41 -0000 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