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
prev parent 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 \
/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
all inboxes | Powered by JetHome®