Re: [PATCH v2 2/3] arm64: dts: ti: Introduce J742S2 SoC family

[Manorit Chawdhry <m-chawdhry@ti.com>]

Hi Andrew,

On 09:37-20240731, Andrew Davis wrote:
> On 7/31/24 8:57 AM, Manorit Chawdhry wrote:
> > Hi Nishanth,
> > 
> > On 06:06-20240731, Nishanth Menon wrote:
> > > On 09:49-20240731, Manorit Chawdhry wrote:
> > > > > > + */
> > > > > > +
> > > > > > +#include "k3-j784s4.dtsi"
> > > > > > +
> > > > > > +/ {
> > > > > > +	model = "Texas Instruments K3 J742S2 SoC";
> > > > > > +	compatible = "ti,j742s2";
> > > > > > +
> > > > > > +	cpus {
> > > > > > +		cpu-map {
> > > > > > +			/delete-node/ cluster1;
> > > > > > +		};
> > > > > > +	};
> > > > > > +
> > > > > > +	/delete-node/ cpu4;
> > > > > > +	/delete-node/ cpu5;
> > > > > > +	/delete-node/ cpu6;
> > > > > > +	/delete-node/ cpu7;
> > > > > 
> > > > > I suggest refactoring by renaming the dtsi files as common and split out
> > > > > j784s4 similar to j722s/am62p rather than using /delete-node/
> > > > > 
> > > > 
> > > > I don't mind the suggestion Nishanth if there is a reason behind it.
> > > > Could you tell why we should not be using /delete-node/?
> > > > 
> > > 
> > > Maintenance, readability and sustenance are the reasons. This is a
> > > optimized die. It will end up having it's own changes in property
> > > and integration details. While reuse is necessary, modifying the
> > > properties with overrides and /delete-nodes/ creates maintenance
> > > challenges down the road. We already went down this road with am62p
> > > reuse with j722s, and eventually determined split and reuse is the
> > > best option. See [1] for additional guidance.
> > > 
> > > 
> > > [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree/bindings/dts-coding-style.rst#n189
> > 
> > Thank you for giving some reasoning, would do the needful!
> > 
> 
> This refactor will require some interesting naming for the
> common SoC files. Based on your name for the EVM, I'm guessing
> you will go with

One other reason I was trying to avoid that and going with
/delete-node/. For such a small delta change tbh, this churn doesn't
feel worth the effort to me and is just gonna create confusion.

EVM one was required as Rob did raise an interesting point and we did
require a soc file that wasn't existing with the previous patchset but
now for deleting just 4 cpus and 1 dsp, am gonna have to rename all the
files, change the hierarchical structure, add all the cpus again with
some weird naming for the file as don't know if some other soc is gonna
come up in future so don't wanna clutter the file names as well with
j784s4-j742s2-j7xxx.dtsi which is just gonna create another set of mess
in future.

Regards,
Manorit

> 
> k3-j784s4-common.dtsi
> 
> included from the real k3-j784s4.dtsi and the new k3-j742s2.dtsi?
> 
> Too bad the Jacinto SoC names don't use a hierarchical naming. :(
> 
> J7<family><part><spin><etc>..
> 
> Andrew
> 
> > Regards,
> > Manorit
> > 
> > > 
> > > -- 
> > > Regards,
> > > Nishanth Menon
> > > Key (0xDDB5849D1736249D) / Fingerprint: F8A2 8693 54EB 8232 17A3  1A34 DDB5 849D 1736 249D
> >