Hi Thomas,
On Thu, 16 Oct 2025 13:42:59 +0200
Thomas Zimmermann <[email protected]> wrote:
> > Honestly, I'm not too sure why this is a problem if this hook is
> > optional. If it turns out to be too simple for more complex use cases
> > others have, it can still be extended when those drivers transition to
> > this ::sync() approach, as no in-kernel API is immutable. And in the
> > meantime, we have a solution for two drivers that doesn't imply
> > duplicating a bunch of drm_prime boiler-plate that's otherwise rather
> > generic.
>
> The prime code you'd have to duplicate is just 10 lines, plus some small
> per-driver code. Most of that being data-structure inits.
I went for this approach, with a few simple changes to drm_prime.c to
be able to re-use more of the prime boilerplate.
>
> I want to point out that I'm not opposing the general idea of GEM sync,
> but I think it should get more feedback from others. It's supposed to be
> a generic interface after all. Hence I was asking to put all this into a
> separate series.
New version sent, with more recipients this time. Hopefully I get some
answers to the dma_buf::{begin,end}_cpu_access() questions I have.
Regards,
Boris
