Deprecate pci_dma_sync_{single,sg}()?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines
[...]
In the current linux-mips implementation, this has some subtle problems:
pci_unmap_{single,sg}() is essentially a no-op. Thus, in the above example, a driver would break (stale cachelines from a previous pci_dma_sync_*/read would not be invalidated). One might argue that a cache invalidate should happen in thepci_unmap_single(). But then the other case (where a driver does apci_map, DMAs, does apci_unmap, and sends it up the stack) would require an additional cache flush/invalidate that is not needed at all.
Frist, fix mips, it is broken. Then patch those simple minded drivers that do map->dma->unmap cycle and suffer performance degradation to use pci_unmap(..., PCI_DMA_NONE).
-- Pete
From: Pete Zaitcev <[email protected]>
Date: Wed, 5 Jun 2002 17:56:29 -0400
Quoted 9 lines
[...]
In the current linux-mips implementation, this has some subtle problems:
pci_unmap_{single,sg}() is essentially a no-op. Thus, in the above example, a driver would break (stale cachelines from a previous pci_dma_sync_*/read would not be invalidated). One might argue that a cache invalidate should happen in thepci_unmap_single(). But then the other case (where a driver does apci_map, DMAs, does apci_unmap, and sends it up the stack) would require an additional cache flush/invalidate that is not needed at all.
Frist, fix mips, it is broken.
No, MIPS is not broken. If there is no intervening call into the PCI DMA layer between the read of the data and giving the buffer back to the device, it has no reason to flush.
It flushes when it should, at pci_map_single() time for PCI_DMA_FROM_DEVICE direction.
This provides the behavior exactly as inteded by the API. It is precisely the optimization non-cache-coherent cpu systems are expected to do for best performance.