Hi Christoph,
On 20/06/18 00:21, Christoph Hellwig wrote:
On Tue, Jun 19, 2018 at 11:06:19PM +1000, Greg Ungerer wrote:
For the nommu case there is no magic because there is no underlying
pages or page table entries to set any control bits for. There is no
fine grained control, just a couple of cache enabled regions (such as
all of RAM) and some bulk control (such as invalidate and clear).
But it does still require cache maintenance for dma operations. For
example the drivers/net/ethernet/freescale/fec_main.c driver is
common on ColdFire SoC parts and it needs to do all the appropriate
dma operations to work right. Though on some of the older simpler
parts (5752 for example) there ins only instruction cache and you
don't have to do dma operations on it.
Well, if there is no data cache everything is coherent. For those
parts we should be using dma_direct_ops. If there is a data cache
dma_alloc_coherent needs to make sure we bypass it. If we can't
do that we need to fail normal coherent request and only allow
allocations with the DMA_ATTR_NON_CONSISTENT flag.
Ok, yep. That is going to be the case for some ColdFire parts.
That wasn't added to that alloc code when we started supporting
ColdFire parts with more advanced caching mechanisms. Outside of
the FEC driver there has not been a lot of devices that use DMA
on these platforms.
The fec drivers uses dma_alloc_coherent for the TX descriptors,
but I don't really see any manual cache maintainance in it.
What do I miss?
No, your right, I missed that. I don't see anything in the ColdFire
doco that indicates that there is any coherency on the FEC module
on the more advanced parts with cache. So I suspect that is a real
problem (not one that anyone has reported in practice yet though...)
Regards
Greg
--
To unsubscribe from this list: send the line "unsubscribe linux-m68k" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
