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