[git pull] drm tree for 5.4-rc1

[Daniel Vetter]

On Fri, Sep 20, 2019 at 2:11 AM Dave Airlie <airlied at gmail.com> wrote:
> > Hmm. My merge isn't identical to that. It's close though. Different
> > order for one #define which might be just from you and me merging
> > different directions.
> >
> > But I also ended up removing the .gem_prime_export initialization to
> > drm_gem_prime_export, because it's the default if none exists. That's
> > the left-over from
> >
> >     3baeeb21983a ("drm/mtk: Drop drm_gem_prime_export/import")
> >
> > after the import stayed around because it got turned into an actually
> > non-default one.
> >
> > I think that both of our merges are right - equivalent but just
> > slightly different.
> >
> > But the reason I'm pointing this out is that I also get the feeling
> > that if it needs that dev->dev_private difference from the default
> > function in prime_import(), wouldn't it need the same for prime_export
> > too?
> >
> > I don't know the code, and I don't know the hardware, but just from a
> > "pattern matching" angle I just wanted to check whether maybe there's
> > need for a mtk_drm_gem_prime_export() wrapper that does that same
> > thing with
> >
> >         struct mtk_drm_private *private = dev->dev_private;
> >
> >         .. use private->dev  instead of dev->dev ..
> >
> > So I'm just asking that somebody that knows that drm/mtk code should
> > double-check that oddity.
>
> I've cc'ed Alexandre who wrote the import half of this code to look into it.
>
> I've looked at the other results and it all seems fine to me.

(pre-coffee, but let's hope the brain is awake enough)

This asymmetry in prime import/export is somewhat common for devices
with funky dma requirements/setup in the dt/soc world.

- on export we need to use the "official" struct device, so that when
we re-import (i.e. userspace just shared a buffer across process
through fd-passing, not across device-drivers) the common helpers
realize "ah this is ours, let me just grab the underlying buffer
object", instead of creating a full new buffer object handle like it
does for a real import of a dma-buf from a different device driver.
Because having 2 buffer object handles pointing at the same underlying
buffer objects tends to not go well.

- on import otoh we need to pass the struct device we actually need
for dma (which for reasons that I don't fully grok isn't the same, I
got it explained once by dt/soc folks and forgot again why exactly),
so that dma_map_sg and friends dtrt.

So that part should be all fine.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch