[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAPM=9tzLFenqZQo_NQqKd5xPQ5g-5WY+JxTotL7AHk_+6S89ow@mail.gmail.com>
Date: Fri, 20 Sep 2019 10:11:09 +1000
From: Dave Airlie <airlied@...il.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
Alexandre Courbot <acourbot@...omium.org>
Cc: Daniel Vetter <daniel.vetter@...ll.ch>,
dri-devel <dri-devel@...ts.freedesktop.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [git pull] drm tree for 5.4-rc1
> 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.
Dave.
Powered by blists - more mailing lists