Messages in this thread | | | Date | Wed, 11 Feb 2004 19:58:12 -0800 | From | "David S. Miller" <> | Subject | Re: [Patch] dma_sync_to_device |
| |
On Wed, 11 Feb 2004 20:46:11 -0700 Deepak Saxena <dsaxena@plexity.net> wrote:
> /me groks now. I am assuming this is a 2.7 thing as it is > reinterpreting/redefining the API.
No, it is adding an operation that previously was impossible to make occur.
> In ARM, pci_dma_sync_single() does > a cache flush, which is why I was confused asked about two cache flushes. > What you are proposing is that by definition pci_dma_sync_* syncs > bridges caches with system memory, while pci_dma_sync_device_* syncs > the CPU's cache with system memory. > > This will definetely confuse a lot of driver writers.
What I am proposing, is to keep pci_dma_sync_*() with it's current definition which is to transfer control of the buffer from DEVICE to CPU. It has always been defined this way.
I am also adding a new operation, pci_dma_sync_device_*() which transfers control of the buffer from CPU back to DEVICE. This operation was not possible previously.
Therefore we will merge this into both 2.6.x and 2.4.x as soon as a suitable full and reviewed patch exists.
If you flush the cache on ARM for pci_dma_sync_*(), so what? If the cpu writes to the buffer then asks the device to DMA from the area it's going to see garbage.
To be honest there aren't many pci_dma_sync_*() users, and thus it is relatively easy to audit them all for problems in this area. Yes, updates and clarifications in the docs will be necessary as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |