linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: CK Hu <ck.hu@mediatek.com>
To: Daniel Vetter <daniel@ffwll.ch>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>,
	David Airlie <airlied@linux.ie>,
	Gustavo Padovan <gustavo@padovan.org>,
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>,
	Sean Paul <sean@poorly.run>,
	"Philipp Zabel" <p.zabel@pengutronix.de>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	<linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-mediatek@lists.infradead.org>,
	<srv_heupstream@mediatek.com>
Subject: Re: [PATCH 3/3] drm/mediatek: Use drm_gem_cma_object instead of mtk_drm_gem_obj
Date: Mon, 29 Oct 2018 11:11:16 +0800	[thread overview]
Message-ID: <1540782676.13715.4.camel@mtksdaap41> (raw)
In-Reply-To: <20181026102156.GH21967@phenom.ffwll.local>

Hi,Daniel:

On Fri, 2018-10-26 at 12:21 +0200, Daniel Vetter wrote:
> On Fri, Oct 26, 2018 at 03:22:03PM +0800, CK Hu wrote:
> > After adding dma_dev in struct drm_device and
> > drm_gem_cma_dumb_create_no_kmap(), drm_gem_cma_object could replace
> > mtk_drm_gem_obj, so use drm_gem_cma_object instead of mtk_drm_gem_obj to
> > reduce redundant code.
> > 
> > Signed-off-by: CK Hu <ck.hu@mediatek.com>
> 
> A few questions/thoughts:
> 
> - Why do you need both drm_device->dev and drm_device->dma_dev? Can't you
>   just register the drm_device with the right struct device?
> 

In [1], mmsys is the drm driver and ovl0 and ovl1 is the sub device
which has dma function.
In this drm, there are two crtc and each one is comprised of many
component.
This is an example of mt8173:

crtc0: ovl0, color0, aal, od, rdma0, ufoe, dsi0
crtc1: ovl1, color1, gamma, rdma1, dpi0

In the device node of ovl0 and ovl1, there is a 'iommus' parameter in
it, so use dma_alloc_xxx() and dma_map_xxx() with that device would get
iova rather than pa. I don't think it's a good idea to register ovl0 or
ovl1 as drm device because each one is just a component in a pipeline.
mmsys controls the clock and routing of multi-media system which include
this drm system, so it's better to register mmsys as drm device. Maybe
we could move 'iommus' parameter from ovl device to mmsys device, so the
dma device changes from ovl device to mmsys device. I'm not sure this
would be a good choice, how do you think?

[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arm64/boot/dts/mediatek/mt8173.dtsi?h=v4.19

> - You don't use drm_gem_prime_import_dev, so prime import isn't using the
>   right device either.

Yes, you are right. I'm not familiar with whore drm core, so I start to
modify what Mediatek drm use. But this function still works for the drm
device that itself is dma device. If one day there is a drm device which
itself is not a dma device and need this function, send a patch to
modify this function and test it with that drm device. If you want me to
modify all in advance, I'm ok but need others to test it because
Mediatek drm driver does not use them.

> 
> - exynos seems to have the same or at least similar issue, stronger case
>   for your patches if you can solve both.

I'm still Mediatek's employee. If I modify other company's driver and it
is not a MUST-BE for Mediatek, Mediatek may think I give contribution to
other company. So I've better not to modify exynos driver.

> - I'd start out with using struct drm_gem_cma_object in mtk (similar to
>   what vc4 does), and then reusing as much as possible of the existing
>   helpers. And then looking later on what's still left (like the support
>   for leaving out the virtual mapping).

I'm not clear what vc4 does. It looks like that you want me to redefine
mtk_drm_gem_obj based on drm_gem_cma_object. So it would be like

struct mtk_drm_gem_obj {
	struct drm_gem_cma_object base;
	void *cookie;
	unsigned long dma_attrs;
};

I could try to modify as this and see what have left.

Regards,
CK

> 
> -Daniel
> 

[Snip...]

> > ---
> > -- 
> > 1.9.1
> > 
> 



  reply	other threads:[~2018-10-29  3:11 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-26  7:22 [PATCH 0/3] Mediatek drm driver use drm_gem_cma_object instead of mtk_drm_gem_obj CK Hu
2018-10-26  7:22 ` [PATCH 1/3] drm: Add dma_dev in struct drm_device CK Hu
2018-10-26  7:22 ` [PATCH 2/3] drm: Add drm_gem_cma_dumb_create_no_kmap() helper function CK Hu
2018-10-26  7:22 ` [PATCH 3/3] drm/mediatek: Use drm_gem_cma_object instead of mtk_drm_gem_obj CK Hu
2018-10-26 10:21   ` Daniel Vetter
2018-10-29  3:11     ` CK Hu [this message]
2018-10-29  9:16       ` Daniel Vetter
2018-10-30  6:54         ` CK Hu
2018-10-30  9:02           ` Daniel Vetter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1540782676.13715.4.camel@mtksdaap41 \
    --to=ck.hu@mediatek.com \
    --cc=airlied@linux.ie \
    --cc=daniel.vetter@ffwll.ch \
    --cc=daniel@ffwll.ch \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=gustavo@padovan.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=maarten.lankhorst@linux.intel.com \
    --cc=matthias.bgg@gmail.com \
    --cc=p.zabel@pengutronix.de \
    --cc=sean@poorly.run \
    --cc=srv_heupstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).