On Thu, Oct 20, 2022 at 5:13 AM Christian König <ckoenig.leichtzumerken@xxxxxxxxx> wrote: > > When a device driver is snooping the CPU cache during access we assume > that all importers need to be able to snoop the CPU cache as well. > > Signed-off-by: Christian König <christian.koenig@xxxxxxx> > --- > drivers/gpu/drm/drm_prime.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 20e109a802ae..d5c70b6fe8a4 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -28,6 +28,7 @@ > > #include <linux/export.h> > #include <linux/dma-buf.h> > +#include <linux/dma-map-ops.h> > #include <linux/rbtree.h> > #include <linux/module.h> > > @@ -889,6 +890,7 @@ struct dma_buf *drm_gem_prime_export(struct drm_gem_object *obj, > .size = obj->size, > .flags = flags, > .priv = obj, > + .coherent = dev_is_dma_coherent(dev->dev), To set the coherent flag correctly, I think I'd need a way to override on a per buffer basis, since coherency is a property of the gpu pgtables (which in the msm case is an immutable property of the gem object). We also have some awkwardness that drm->dev isn't actually the GPU, thanks to the kernels device model seeing a collection of other small devices shoehorned into a single drm device to fit userspace's view of the world. So relying on drm->dev isn't really going to give sensible results. I guess msm could just bury our heads in the sand and continue to do things the way we have been (buffers that are mapped cached-coherent are only self-shared) but would be nice to catch if userspace tried to import one into (for ex) v4l2.. BR, -R > .resv = obj->resv, > }; > > -- > 2.25.1 >
