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/
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
