LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Philipp Zabel <p.zabel@pengutronix.de>
To: Wen He <wen.he_1@nxp.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"dri-devel@lists.freedesktop.org"
	<dri-devel@lists.freedesktop.org>
Cc: Leo Li <leoyang.li@nxp.com>
Subject: Re: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE
Date: Tue, 23 Jul 2019 12:29:36 +0200	[thread overview]
Message-ID: <1563877776.3731.3.camel@pengutronix.de> (raw)
In-Reply-To: <DB7PR04MB5195F5731555285623955738E2F10@DB7PR04MB5195.eurprd04.prod.outlook.com>

On Tue, 2019-07-09 at 03:11 +0000, Wen He wrote:
[...]
> > Thank you for the patch, but this does not seem right.
> > ipuv3-crtc.c is part of DRM_IMX, which already depends on IMX_IPUV3_CORE.
> > How did you manage to make it try to compile imxdrm?

I assume the answer to my question is that you have removed the
IMX_IPUV3_CORE dependency in the LS1028A BSP?

> Thanks for the review, Philipp,
> 
> NXP LS1028A platform use same Display IP with IMX8, so they have use same display
> transmit controller drivers, config 'DRM_IMX' is used to support drm common drivers
> on the NXP I.MX and LS1028A, display transmit controller is coming to plan upstream.  

Is it the i.MX8MQ DCSS or the i.MX8QM DPU that is shared with LS1028A?

> Actually, we have done compile of the imxdrm on LS1028A BSP release.

Can you point me changes that have been applied? It is still unclear to
me how you managed to build imx-drm, unless you have removed the
IMX_IPUV3_CORE dependency from DRM_IMX.

> > Since LS1028A does not have the IPUv3, keeping this under COMPILE_TEST
> > should be correct.
> 
> Although LS1028A does not have the IPVv3, but DRM_IMX depends on it, LS1028A display
> Transmit controller drivers also depends on DRM_IMX, so we need add this dependency to
> solve the compile issue.

The imx-drm driver is not suited to drive the i.MX8 display controllers.
They should get their own drm drivers, as they have nothing in common
with the i.MX5/6 IPU. There are no video capture capabilities, so they
don't need the subsystem spanning driver layout, and without muxable
shared encoders there is no need for the component design either.

regards
Philipp

      reply	other threads:[~2019-07-23 10:29 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-08 10:56 Wen He
2019-07-05 10:32 ` Philipp Zabel
2019-07-09  3:11   ` [EXT] " Wen He
2019-07-23 10:29     ` Philipp Zabel [this message]

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=1563877776.3731.3.camel@pengutronix.de \
    --to=p.zabel@pengutronix.de \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=leoyang.li@nxp.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=wen.he_1@nxp.com \
    --subject='Re: [EXT] Re: [v1] gpu: ipu-v3: allow to build with ARCH_LAYERSCAPE' \
    /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

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).