On Mon, 28 Dec 2020 at 09:21, Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx> 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
