[PATCH v3 4/6] arm64: dts: imx8mm: Add Engicam i.Core MX8M Mini C.TOUCH 2.0

Krzysztof Kozlowski krzk at kernel.org
Mon Dec 28 03:34:16 EST 2020


On Mon, 28 Dec 2020 at 09:21, Jagan Teki <jagan at amarulasolutions.com> wrote:
> > > #include "imx8mm.dtsi"
> > > #include "imx8mm-beacon-som.dtsi"
> > > #include "imx8mm-beacon-baseboard.dtsi"
> > >
> > > (SoC dtsi, SoM dtsi, Carrier board dtsi)
> > >
> > > > design which makes any sense. We do not create empty DTS files which
> > > > only include one more DTSI. The contents of
> > > > imx8mm-engicam-ctouch2.dtsi should be directly in
> > > > imx8mm-icore-mx8mm-ctouch2.dts. That's the same problem as with v1 -
> > > > you overcomplicate simple stuff. It really looks like you ignored the
> > > > comments from v1 in multiple places.
> > >
> > > As explained above, the design is pretty much the same as the existing SoM's.
> > >
> > > imx8mm-engicam-ctouch2.dtsi is not just a dtsi file where nodes are
> > > enabled. It has nodes enabled for Carrier board, so keeping nodes
> > > separately will
> >
> > The files represent real devices or their components. So you have a
> > SOM - a DTSI file. You have a carrier board - a DTS file. That's
> > simple design which is mostly followed, unless something over
> > complicated passes the review.
> >
> > > 1. More verbose for which IP's are available in the carrier board
> >
> > No difference when carrier DTSI is the DTS. Exactly the same.
> >
> > > 2. Easy to extend if someone can create another SoM with a similar Carrier.
> >
> > Not really, if they include carrier DTSI they need to override a lot.
> > So usually (including practice - I did it) they *copy* the carrier to
> > create their own design.
>
> But what if the new board has slite change to use exiting carrier like
> what ctouch2 10" OF. Can we add ctouch2 dtsi as a separate file for
> this case?

If you submit another DTS using the imx8mm-engicam-ctouch2.dtsi - with
its own differences of course (not copying other DTS...) - then having
a DTSI makes sense. In current form, still NAK for all the reasons I
explained more than once.

Best regards,
Krzysztof



More information about the linux-arm-kernel mailing list