Re: PCI DMA to small buffers on cache-incoherent arch

["David S. Miller" <davem@redhat.com>]

   From: David Brownell <david-b@pacbell.net>
   Date: Wed, 12 Jun 2002 12:13:08 -0700

   >  In general I certainly support
   > the idea of making the DMA mapping stuff device generic instead of
   > tied to PCI.  
   
   PCI was a good place to start (focus ... :) but clearly it shouldn't
   be the only bus architecture with such support.  Note that there are
   actually two related approaches in the DMA-mapping.txt APIs ... one is
   DMA mapping, the other is "consistent memory".  Both should be made
   generic rather than PCI-specific, not just mapping APIs.
   
I tried to imply this, if I didn't it is my error.

The intention is that every interface in DMA-mapping.txt will have
a dev_* counterpart when we move away from pci_dev to the generic
device struct.

One idea I want people to avoid is that we end up trying to do DMA
operations from a USB generic device struct.  This will lead to
multiple levels of indirection to do the PCI dma operation (USB device
--> USB bus --> PCI bus --> PCI bus DMA ops) and that will be ugly as
hell.
   
   Based on the discussion, I think the answer for now is to go with
   the (b) variant you had originally started with, using kmalloc for
   the buffers.  The __dma_buffer style macro didn't seem popular;
   though I agree that it's not clear kmalloc() really solves it
   today.  (Given DaveM's SPARC example, the minimum size value it
   returns would need to be 128 bytes ... which clearly isn't so.)
   
Let's ignore the sparc64 issue for now.  It's really a red herring
because as Pavel mentioned I could just use the largest size.

In actuality the "sparc64 issue" was partially a straw-man.  Sparc64
has none of the DMA alignment issues as the PCI controller provides
coherency of partial cacheline transfers, we just need to flush
pending writes and prefetched reads out of the PCI controllers around
non-consistent DMA transfers.
   
Franks a lot,
David S. Miller
davem@redhat.com