Date: Wed, 06 Dec 2006 02:43:01 +0000 From: Ian Dowse <iedowse@iedowse.com> To: "Daan Vreeken [PA4DAN]" <Danovitsch@vitsch.net> Cc: scottl@samsco.org, src-committers@freebsd.org, cvs-src@freebsd.org, cvs-all@freebsd.org, "M. Warner Losh" <imp@bsdimp.com> Subject: Re: cvs commit: src/sys/dev/usb usbdi.c Message-ID: <200612060243.aa54643@nowhere.iedowse.com> In-Reply-To: Your message of "Wed, 29 Nov 2006 12:04:43 %2B0100." <200611291204.43704.Danovitsch@vitsch.net>
next in thread | previous in thread | raw e-mail | index | archive | help
In message <200611291204.43704.Danovitsch@vitsch.net>, "Daan Vreeken [PA4DAN]" writes: >Hi Ian, > >On Wednesday 29 November 2006 11:58, you wrote: >> Thanks for all the details - I'll try to put together a patch in the >> next few days that adds bus_dmamap_sync() calls whereever there are >> shared access ordering requirements in the host controller drivers. >> As Olivier mentioned, bus_dma(9) says that this should be done even >> for BUS_DMA_COHERENT allocations, so adding them may fix problems on >> other platforms too. > >Ok, thanks for looking into this! >At the moment I'm working on a driver for the USB device port that's on the >ARM board. The driver is about half way being usefull. Once it's finished I >can debug USB problems from the device perspective and see what data actually >goes over the wire. That should show us what exactly goes wrong without the >bus_dmapmap_sync() calls. I haven't yet found the time to look into this unfortunately - one thing that did become obvious however is that the interface to the USB host controller hardware does need something very close to BUS_DMA_COHERENT mappings. For example, the host controllers allow you to link certain structures into linked lists that the hardware is constantly traversing, without ever halting the hardware (you first set up the "next" pointer in the new entry and then change a "next" pointer in a live entry to point at the new entry). This kind of update wouldn't be possible with bounce buffers, for example, because a BUS_DMASYNC_PREWRITE call to update the live "next" pointer could inadvertently clobber other state in the live object. Assuming that the mapping is "coherent enough" for BUS_DMASYNC_PREWRITE to only write what needs to be written, then the next issue is whether it is really necessary to go through a potentally large number of transfer descriptors, calling BUS_DMASYNC_PREWRITE on each one? Is there any hardware we support where coherent mappings require a per-region flush/barrier call to ensure writes have taken place? On the arm platform it seemed that just a global flush/barrier was enough, given the effect of the usbdi.c patch, and on i386/amd64 no flush/barrier seems to be required at all. Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200612060243.aa54643>