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
