Sorry, I'm not clear on this one. I was first proposing (for the short
term, at least) to not change anything at all: all the existing
implementations of pci_dma_sync_*(..., PCIDMA_TO_DEVICE) already do what
is required: prepare the buffer to be DMAed from by the controller. Most
drivers won't have to deal with this; most network drivers, for example,
do a pci_map_*() on an skb passed down from the stack and subsequently
pci_unmap_*() those buffers once transmitted, thus having no need for
pci_dma_sync_*()... So I don't see how this makes anything else less
The network drivers use PCI_DMA_FROM_DEVICE because they are working
on receive packets, which get DMA'd 'from' the device to memory.
This is also the same case the SCSI drivers use.
> Please, add a new call to handle your case. Thanks.
Such a call would do what pci_dma_sync_*(..., PCIDMA_TO_DEVICE) already
does (unless that is what you want - to have a new call just for the
sake of clarity...).
A call with PCI_DMA_TO_DEVICE means nearly the same thing
as PCI_DMA_FROM_DEVICE. Namely "revoke PCI ownership of memory"
which means "take the memory out of the PCI domain".
Implementation wise this means:
1) If PCI_DMA_TO_DEVICE, purge any data cached in PCI controller
prefetch caches that require SW flushing.
2) If PCI_DMA_FROM_DEVICE, do the actions in #1 plus if CPU
is not cache coherent flush caches so that PCI written
data is visible to the CPU.
That is what the interface does.
Now that we've established that, you want a new operation.
That operation is "Re-prepare DMA memory so that PCI realm
will see it". And the semantics of this would be to, on
CPUs which are no cache coherent with PCI, to flush the cache
to prevent inconsistencies between PCI and the CPU.
The CPU cache flush is needed in both cases to/from cases.
So do you finally understand why you must create a new interface
to accomplish what you want?
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/