archive mirror
 help / color / mirror / Atom feed
From: Francesco Dolcini <>
To: Laurent Pinchart <>
Cc: Francesco Dolcini <>,
	Francesco Dolcini <>,
	Max Krummenacher <>,
	Max Krummenacher <>,
	Fabio Estevam <>,
	Krzysztof Kozlowski <>,
	Marcel Ziswiler <>,
	NXP Linux Team <>,
	Pengutronix Kernel Team <>,
	Philippe Schenker <>,
	Rob Herring <>,
	Sascha Hauer <>,
	Shawn Guo <>,,,
Subject: Re: [PATCH 1/2] arm64: dts: imx8mp-verdin: add dsi to hdmi functionality
Date: Mon, 5 Sep 2022 23:17:03 +0200	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hello Laurent,

On Mon, Sep 05, 2022 at 10:26:14PM +0300, Laurent Pinchart wrote:
> On Sat, Sep 03, 2022 at 02:47:43PM +0200, Francesco Dolcini wrote:
> > On Sat, Sep 03, 2022 at 03:24:51AM +0300, Laurent Pinchart wrote:
> > > On Fri, Sep 02, 2022 at 05:57:20PM +0200, Francesco Dolcini wrote:
> > > > On Thu, Sep 01, 2022 at 09:07:49PM +0300, Laurent Pinchart wrote:
> > > Someone can integrate a Verdin SoM with a carrier board that has no DSI
> > > to HDMI (or LVDS) bridge, there should thus be no such device in the
> > > device tree. The SoM has DSI signals present on its connector, that's
> > > what the SoM .dtsi should expose.
> > 
> > Just for the record Verdin i.MX8M Plus do have both HDMI and LVDS on the
> > connector (in addition to DSI) [1], of course we do have also the option to
> > have LVDS or HDMI using an external add-on DSI bridge as this patches are
> > about.
> > 
> > Said that it's true that sometime we describe peripherals that are part of the
> > SOM family into the SOM dtsi, this avoid quite a lot of duplications given the
> > amount of carrier board that are available on the market that use just the same
> > building blocks (and this was one of the 2 points I mentioned as a reasoning
> > for our current DTS files structure).
> If those "SoM family" peripherals are on the carrier board, what's the
> issue with describing them in the carrier board .dtsi ? And if they're
> on an add-on board (such as, if I understand correctly, the DSI to HDMI
> encoder for the Dahlia carrier board), what's the issue with describing
> them in an overlay ?

These SOM family peripherals are in multiples(!) carrier boards AND on
accessories. The drawback of being strict as you are asking is that we
would end-up with a massive duplication of this small DTS building
blocks, therefore the decision in the past to put those in the base SOM
dtsi file.

Maybe adding something like imx8mp-verdin-dsi-hdmi.dtsi and
imx8mp-verdin-dsi-lvds.dtsi that can be included by both overlay and
carrier dts files as needed would solve both the need of being strict on
the board definition in the dts file and avoid duplications?
Not sure if that would work smoothly, it looks like adding some
complexity and maintenance overhead, but maybe is the correct solution.

Anyway, while I fully understand your reasoning, I'm still not happy to
change this for the current toradex products, since users of
our dts file currently rely on the expectations I tried to explain in
this email thread and Max patches are implementing (and this is
currently uniform over the whole toradex product range).

> Maybe I'm missing something ?
I tried to give more insights.


linux-arm-kernel mailing list

  reply	other threads:[~2022-09-05 21:18 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-09-01 15:40 [PATCH 1/2] arm64: dts: imx8mp-verdin: add dsi to hdmi functionality Max Krummenacher
2022-09-01 15:40 ` [PATCH 2/2] arm64: dts: imx8mp-verdin: add dsi to lvds functionality Max Krummenacher
2022-09-01 18:10   ` Laurent Pinchart
2022-09-01 18:07 ` [PATCH 1/2] arm64: dts: imx8mp-verdin: add dsi to hdmi functionality Laurent Pinchart
2022-09-02 15:57   ` Francesco Dolcini
2022-09-03  0:24     ` Laurent Pinchart
2022-09-03 12:47       ` Francesco Dolcini
2022-09-05 19:26         ` Laurent Pinchart
2022-09-05 21:17           ` Francesco Dolcini [this message]
2022-09-05 22:03             ` Laurent Pinchart

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:

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

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

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