Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <CAPM=9txTjip6SonSATB-O38TGX9ituQaw+29PnAkNJ960R1z6g@mail.gmail.com>
 <CAHk-=wjHDrmx+Rj+oJw5V4mfWjpYzpwcJbqY-L-nvsNW_d8e_g@mail.gmail.com> <CAPM=9tzLFenqZQo_NQqKd5xPQ5g-5WY+JxTotL7AHk_+6S89ow@mail.gmail.com>
In-Reply-To: <CAPM=9tzLFenqZQo_NQqKd5xPQ5g-5WY+JxTotL7AHk_+6S89ow@mail.gmail.com>
From:   Daniel Vetter <daniel.vetter@ffwll.ch>
Date:   Fri, 20 Sep 2019 08:12:29 +0200
Message-ID: <CAKMK7uHdNgL2hKdGqKeht2n2An4jemhrr2Jpn0JYpHbop67GpA@mail.gmail.com>
Subject: Re: [git pull] drm tree for 5.4-rc1
To:     Dave Airlie <airlied@gmail.com>
Cc:     Linus Torvalds <torvalds@linux-foundation.org>,
        Alexandre Courbot <acourbot@chromium.org>,
        dri-devel <dri-devel@lists.freedesktop.org>,
        LKML <linux-kernel@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, Sep 20, 2019 at 2:11 AM Dave Airlie <airlied@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