Re: [RFC] URBs and buffer management

On Wednesday 06 June 2007, Oliver Neukum wrote:
> Am Mittwoch, 6. Juni 2007 schrieb Pete Zaitcev:
> > 	The consistent allocation was intended to things like mailboxes,
> > where it is more advantageous to load a couple of words from uncached
> > memory than to call an API which invalidates or flushes the caches.
> > In case of USB, QHs and TDs are a good example, which is why the
> > pool allocation is layered on top of consistent allocations.

Well, "things like mailboxes" is over-specialized.  The key issue
is not needing to use buffer synch operations.  There are lots of
places where having a second level of hardware races to fight with
would be just ... dumb.


> > It we all were using SPARC or MIPS, we'd learn this pretty quickly.
> > However, on x86 and s390, which are I/O coherent, there is really
> > not much difference. The consistent mapping is cached.
> > 
> > So this decision is comes down pretty much to giving a damn about
> > ARM or SPARC.

Or MIPS/SPIM, many PowerPC systems, SH, AVR32 ... that answer is easy!!
Most architectures running Linux, other than x86, don't bother spending
silicon to make their CPU caches snoop bus traffic.

 
> > There is also a question of tying up IOMMU resources for a long time.
> > If you set up DMA mappings in advance with usb_buffer_alloc, you keep
> > a part of your IOMMU unavailable to things like mass storage, which

As I understand it the actual mechanism is more like:  platforms
always set up a chunk of memory as uncached, and always map that
through the IOMMU.  Call that the DMA-{coherent,consistent} region.

Utilities like dma_alloc_coherent() -- and hence usb_buffer_alloc(),
dma_pool_*(), and so on -- return memory from that region.

So the resources are *always* tied up; fixed overhead.  What's visible
to drivers is that per-transfer buffer operations are not needed.


> Yet the documentation claims that the IOMMU is not affected? Quote:
> 
>   The memory buffer returned is "dma-coherent"; sometimes you might need to
>   force a consistent memory access ordering by using memory barriers.  It's
>   not using a streaming DMA mapping, so it's good for small transfers on
>   systems where the I/O would otherwise tie up an IOMMU mapping.  (See

That's not worded as well as it might be.  The issue is tying up a private
mapping, and needing to map/unmap for each keystroke (using the example of
a USB HID keyboard).


>   Documentation/DMA-mapping.txt for definitions of "coherent" and "streaming"
>   DMA mappings.)

I've got a patch in the works to update docs, since nobody else seems to
have stepped up to the bar on that issue ...

- Dave


-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel