From: Laurent Pinchart <firstname.lastname@example.org>
To: Francesco Dolcini <email@example.com>
Cc: Francesco Dolcini <firstname.lastname@example.org>,
Max Krummenacher <email@example.com>,
Max Krummenacher <firstname.lastname@example.org>,
Fabio Estevam <email@example.com>,
Krzysztof Kozlowski <firstname.lastname@example.org>,
Marcel Ziswiler <email@example.com>,
NXP Linux Team <firstname.lastname@example.org>,
Pengutronix Kernel Team <email@example.com>,
Philippe Schenker <firstname.lastname@example.org>,
Rob Herring <email@example.com>,
Sascha Hauer <firstname.lastname@example.org>,
Shawn Guo <email@example.com>,
Subject: Re: [PATCH 1/2] arm64: dts: imx8mp-verdin: add dsi to hdmi functionality
Date: Mon, 5 Sep 2022 22:26:14 +0300 [thread overview]
Message-ID: <YxZNVoMKly9eQ2xE@pendragon.ideasonboard.com> (raw)
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:
> > > Hello Laurent,
> > > answering here for both patches (1/2 and 2/2).
> > >
> > > On Thu, Sep 01, 2022 at 09:07:49PM +0300, Laurent Pinchart wrote:
> > > > On Thu, Sep 01, 2022 at 05:40:50PM +0200, Max Krummenacher wrote:
> > > > > From: Max Krummenacher <firstname.lastname@example.org>
> > > > >
> > > > > Add the hdmi connector present on the dsi to hdmi adapter now
> > > > > required by the upstream lontium bridge driver.
> > > > > The dsi to hdmi adapter is enabled in an device tree overlay.
> > > >
> > > > Shouldn't the connector also be in the overlay ? There's certainly no
> > > > physical HDMI connector on the i.MX8MP Verdin SoM :-)
> > >
> > > Toradex DTS include and overlay files structure so far has been a little
> > > bit different and not following the expectation you just stated here,
> > > you can just check the current *toradex*dts* files and you'll see that there
> > > is other stuff that is not strictly part of the module.
> > >
> > > Copying from a previous email thread on a very similar discussion 
> > > some of the reasons:
> > >
> > > - The SoM dtsi representing not only the functionality implemented into
> > > the SoM, but the whole connector pinout to the carrier makes very easy
> > > to just include a different som.dtsi in the carrier board dts and just
> > > switch SoM, for example from a colibri-imx6 to a colibri-imx7.
> > That's fine, but I don't see how that's related to the issue at hand.
> > The DSI to HDMI bridge wouldn't be present on either SoM, would it ?
> > > - We avoid code duplication
> > >
> > > This is working for us pretty well so far and the majority of the users
> > > of ours modules rely on this structure, we would prefer not to change that.
> > It may work for your current use cases, but it doesn't make it right :-)
> Most of engineering is about compromise, being consistent with what we
> did so far and the end-user experience need to be taken into account.
Sure, and so do mainline requirements :-)
> > 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) , of course we do have also the option to
> have LVDS or HDMI using an external add-on DSI bridge as this patches are
> 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 ?
> Of course, we keep these stuff disabled by default, so apart for some small size
> increase I do not see a real issue.
It's the same issue as adding any DT node for peripherals that do not
exist, I fail to see a compelling reason to do so here, given that this
seems to be easy to handle in the carrier board .dtsi or in overlays.
Maybe I'm missing something ?
>  https://docs.toradex.com/110977-verdin_imx8m_plus_v1.1_datasheet.pdf
linux-arm-kernel mailing list
next prev parent reply other threads:[~2022-09-05 19:51 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 [this message]
2022-09-05 21:17 ` Francesco Dolcini
2022-09-05 22:03 ` Laurent Pinchart
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).