Try to address the DMA-buf coherency problem

Christian König ckoenig.leichtzumerken at gmail.com
Thu Oct 27 12:14:12 UTC 2022


Am 20.10.22 um 14:13 schrieb Christian König:
> Hi guys,
>
> after finding that we essentially have two separate worlds for coherent sharing
> of buffer through DMA-buf I thought I will tackle that problem a bit and at
> least allow the framework to reject attachments which won't work.
>
> So those patches here add a new dma_coherent flag to each DMA-buf object
> telling the framework that dev_is_dma_coherent() needs to return true for an
> importing device to be able to attach. Since we should always have a fallback
> path this should give userspace the chance to still keep the use case working,
> either by doing a CPU copy instead or reversing the roles of exporter and
> importer.
>
> For DRM and most V4L2 devices I then fill in the dma_coherent flag based on the
> return value of dev_is_dma_coherent(). Exporting drivers are allowed to clear
> the flag for their buffers if special handling like the USWC flag in amdgpu or
> the uncached allocations for radeon/nouveau are in use.
>
> Additional to that importers can also check the flag if they have some
> non-snooping operations like the special scanout case for amdgpu for example.
>
> The patches are only smoke tested and the solution isn't ideal, but as far as
> I can see should at least keep things working.

Gentle ping on this. Lucas, Daniel and Nicolas you have been rather 
active in the last discussion. Do you mind taking a look?

Thanks,
Christian.

>
> Please review and/or comment,
> Christian.
>
>



More information about the dri-devel mailing list