On 10/2/20 3:53 AM, Christoph Hellwig wrote:

...

@@ -8,6 +8,7 @@ #include <linux/shmem_fs.h> #include <linux/dma-buf.h> #include <linux/pfn_t.h> +#include <linux/dma-noncoherent.h>

NAK, dma-noncoherent.h is not for driver use. And will in fact go away in 5.10.

Not actually used, so can be removed.

...

#include <drm/drm_prime.h>

@@ -808,6 +809,20 @@ int msm_gem_cpu_fini(struct drm_gem_object *obj) return 0; }

+void msm_gem_sync_cache(struct drm_gem_object *obj, uint32_t flags,

• size_t range_start, size_t range_end)
  

+{

• struct msm_gem_object *msm_obj = to_msm_bo(obj);
• /* TODO: sync only the required range, and don't invalidate on clean */
• if (flags & MSM_GEM_SYNC_CACHE_CLEAN)

• sync_for_device(msm_obj);
  

• if (flags & MSM_GEM_SYNC_CACHE_INVALIDATE)

• sync_for_cpu(msm_obj);
  

And make to these ones as well. They are complete abuses of the DMA API, and while we had to live with that for now to not cause regressions they absoutely must not be exposed in a userspace ABI like this.

How do you propose that cached non-coherent memory be implemented? It is a useful feature for userspace.