[PATCH 2/3] drm/prime: set the dma_coherent flag for export

[Christian König]

Am 20.10.22 um 16:43 schrieb Rob Clark:
> On Thu, Oct 20, 2022 at 5:13 AM Christian König
> <ckoenig.leichtzumerken at gmail.com> 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 at amd.com>
>> ---
>>   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.

Yeah, I've the same problem for amdgpu where some buffers are snooped 
while others aren't.

But this should be unproblematic since the flag can always be cleared by 
the driver later on (it just can't be set).

Additional to that I've just noted that armada, i915, omap and tegra use 
their own DMA-buf export function. MSM could do the same as well if the 
device itself is marked as not coherent while some buffers are mapped 
cache coherent.

Regards,
Christian.

> 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
>>