Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Tue, 6 Sep 2022 01:03:35 +0300
From:   Laurent Pinchart <laurent.pinchart@ideasonboard.com>
To:     Francesco Dolcini <francesco.dolcini@toradex.com>
Cc:     Francesco Dolcini <francesco@dolcini.it>,
        Max Krummenacher <max.oss.09@gmail.com>,
        Max Krummenacher <max.krummenacher@toradex.com>,
        Fabio Estevam <festevam@gmail.com>,
        Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>,
        Marcel Ziswiler <marcel.ziswiler@toradex.com>,
        NXP Linux Team <linux-imx@nxp.com>,
        Pengutronix Kernel Team <kernel@pengutronix.de>,
        Philippe Schenker <philippe.schenker@toradex.com>,
        Rob Herring <robh+dt@kernel.org>,
        Sascha Hauer <s.hauer@pengutronix.de>,
        Shawn Guo <shawnguo@kernel.org>, devicetree@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: imx8mp-verdin: add dsi to hdmi
 functionality
Message-ID: <YxZyN+ynx9q/3GK6@pendragon.ideasonboard.com>
References: <20220901154051.1885509-1-max.oss.09@gmail.com>
 <YxD09SqpcbB3dt8I@pendragon.ideasonboard.com>
 <20220902155720.GB5699@francesco-nb.int.toradex.com>
 <YxKe00H2S9AzF0Yi@pendragon.ideasonboard.com>
 <YxNM75ZtHVKDjTa/@livingston.pivistrello.it>
 <YxZNVoMKly9eQ2xE@pendragon.ideasonboard.com>
 <20220905211703.GA6180@francesco-nb.int.toradex.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20220905211703.GA6180@francesco-nb.int.toradex.com>
Precedence: bulk

Hi Francesco,

On Mon, Sep 05, 2022 at 11:17:03PM +0200, Francesco Dolcini wrote:
> 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.

OK, I got it now.

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

That sounds good to me. Would you be able to give it a try to see if it
works well ?

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

This sounds like a broader question, not specific to Toradex, opinions
from Rob and Krzysztof would be useful.

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

Thank you, that's very appreciated.

-- 
Regards,

Laurent Pinchart