[PATCH v3 0/2] [media] videobuf2-dc: Add support for cacheable MMAP
hch at lst.de
Thu Jul 13 23:36:00 AEST 2017
On Thu, Jul 13, 2017 at 02:21:53PM +0100, Russell King - ARM Linux wrote:
> My conclusion of the dma_alloc_noncoherent() and dma_cache_sync() API
> when it was introduced is that it's basically a completely broken
> interface, and I've never seen any point to it. Maybe some of that is
> because it's badly documented - which in turn makes it badly designed
> (because there's no specification detailing what it's supposed to be
> I'd like to see that thing die...
It's not exactly the best interface ever, so any improvement is welcome.
I've posted a series to kill dma_alloc_noncoherent in favor of
dma_alloc_attrs a short while ago, and a big chunk of it should have
made it into 4.12. I plan to kill it off entirely for 4.13.
That leaves dma_cache_sync() - it's used by 6 drivers:
Those are used on parisc, mips for a few old SGI systems, the SH
dreamcast and powerpc marvell mv64x60 devices.
So it shouldn't be too hard to figure out if they could be moved
to the normal dma_sync_* calls.
On parisc dma_cache_sync is equivalent to dma_sync_single_for_cpu,
so that should be fine.
On mips the implementation of dma_sync_single_for_cpu is a little
more complicated, but both dma_sync_single_for_cpu and dma_cache_sync
end up calling __dma_sync_virtual, so they look like the same in
the end as well.
On SH sync_single_for_device is implemented using dma_cache_sync,
and there is no dma_sync_single_for_cpu.
On powerpc both dma_sync_single_for_cpu and dma_sync_single_for_device
are implemented using the same primitive as dma_cache_sync.
In short: killing off dma_cache_sync and using the existing and
better defined syncing primitives looks entirely feasible.
I'll add it to my TODO list for 4.13.
More information about the Linuxppc-dev