cvs commit: src/sys/dev/usb usbdi.c

[Ian Dowse]

In message <200611291204.43704.Danovitsch at 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