Re: [Patch] dma_sync_to_device

[Matt Porter]

On Wed, Feb 11, 2004 at 07:51:48AM +0100, Martin Diehl wrote:
> On Tue, 10 Feb 2004, Deepak Saxena wrote:
> 
> > > +	pci_dma_sync_to_device_single(dev, dma_handle, size, direction);
> > 
> > Maybe I am missunderstanding something, but how is this
> > any different than simply doing:
> > 
> > 	pci_dma_sync_single(dev, dma_handle, size, DMA_TO_DEVICE);
> 
> For i386 you are right: the implementation of pci_dma_sync_single and 
> pci_dma_sync_to_device_single happen to be identical. This is because this 
> arch is cache-coherent so all we have to do to achieve consistency is 
> flushing the buffers. However, for other arch's there might be significant 
> dependency on the direction.

Sure, other non cache coherent arch's that I'm aware of (PPC, ARM, etc.)
already implement the least expensive cache operations based on the
direction parameter in pci_dma_sync_single(). On PPC, we do the right
thing based on each of three valid directions, I don't yet see what
additional information pci_dma_sync_to_device_single() provides. 

> The existing pci_dma_sync_single was meant for the FROM_DEVICE direction 
> only. I agree it's not entirely obvious currently. But making it 

It's definitely not obvious since DMA-mapping.txt shows it as having
a direction parameter and makes no claim that it is only for the
FROM_DEVICE direction.  In addition, all the non-coherent arches I've
worked on implement all the directions.

> BIDIRECTIONAL would be pretty expensive on some none cache-coherent archs 
> and the whole point of having separate streaming mappings with dedicated 
> TO or FROM direction would be void.

BIDIRECTIONAL would be expensive, yes, that's why pci_dma_sync_single()
implementation use the already present directional information to do
the right thing.

Maybe we need a clear example.

-Matt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/