On Fri, Jul 19, 2013 at 6:46 AM, Gerhard Sittig <g...@denx.de> wrote: > So: No, not having to fiddle with DMA stuff when doing PCI need > not be a problem, it's actually expected. But since a DMA engine > might be involved (that's just not under your command), the > accompanying problems may arise. You may need to flush CPU > provided data upon write before telling an external entity to > access it, and may need to invalidate caches (to have data > re-fetched) before the CPU accesses what an external entity did > manipulate. And this applies to both payload data as well as > management data (descriptors) if the latter apply to the former.
This is something I've been exploring today. But what is unclear is _how_ to flush/invalidate the caches'. I was going to tweak the driver to setup the descriptors, flush the cache, then enable the hardware (and when taking the device down, disable the hardware, flush the cache, then deallocate the descriptors). But this is in the network code and it isn't obvious how to make this happen. I think I figured something out. Basically, in the receive interrupt, prior to reading the data in the descriptor, I call dma_sync_single_for_cpu(). Then the driver can continue to process the data, then unmap the DMA region (with dma_unmap_single() ). When setting up the descriptors, after calling dma_map_single(), configuring the descriptor, I then call dma_sync_single_for_device(). Does this look correct? However, on the PPC platforms, these calls (dma_sync_*) are NOPs unless CONFIG_NOT_COHERENT_CACHE is defined (which it doesn't appear to be for the 8349). So I tweaked the Kconfig to enable CONFIG_NOT_COHERENT. Things built ok, but I'm not sure if this is sufficient to invoke the cache flush necessary. Am I on the right track? Thanks, Pete _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
