| Message ID | 20201104224356.18040-2-nm@ti.com |
|---|---|
| State | New |
| Headers | show |
| Series | [1/4] arm64: dts: ti: k3-am65*: Cleanup disabled nodes at SoC dtsi level | expand |
On 05/11/2020 00:43, Nishanth Menon wrote: > The device tree standard sets the default node behavior when status > property as enabled. There are many reasons for doing the same, number > of strings in device tree, default power management functionality etc > are few of the reasons. > > In general, after a few rounds of discussions [1] there are few > options one could take when dealing with SoC dtsi and board dts > > a. SoC dtsi provide nodes as a super-set default (aka enabled) state and > to prevent messy board files, when more boards are added per SoC, we > optimize and disable commonly un-used nodes in board-common.dtsi > b. SoC dtsi disables all hardware dependent nodes by default and board > dts files enable nodes based on a need basis. > c. Subjectively pick and choose which nodes we will disable by default > in SoC dtsi and over the years we can optimize things and change > default state depending on the need. > > While there are pros and cons on each of these approaches, the right > thing to do will be to stick with device tree default standards and > work within those established rules. So, we choose to go with option > (a). > > Lets cleanup defaults of am654 SoC dtsi before this gets more harder > to cleanup later on and new SoCs are added. > > The dtb generated is identical with the patch and it is just cleanup to > ensure we have a clean usage model > > [1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/ > > Fixes: 9bcb631e9953 ("arm64: dts: ti: k3-am654-main: Add McASP nodes") > Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node") > Cc: Jyri Sarha <jsarha@ti.com> > Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> > Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> > Cc: Tony Lindgren <tony@atomide.com> > Signed-off-by: Nishanth Menon <nm@ti.com> > --- > arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 -------- > arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 16 ++++++++++++++++ > 2 files changed, 16 insertions(+), 8 deletions(-) Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ti.com> Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
diff --git a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi index 533525229a8d..21e50021dd83 100644 --- a/arch/arm64/boot/dts/ti/k3-am65-main.dtsi +++ b/arch/arm64/boot/dts/ti/k3-am65-main.dtsi @@ -770,8 +770,6 @@ mcasp0: mcasp@2b00000 { clocks = <&k3_clks 104 0>; clock-names = "fck"; power-domains = <&k3_pds 104 TI_SCI_PD_EXCLUSIVE>; - - status = "disabled"; }; mcasp1: mcasp@2b10000 { @@ -789,8 +787,6 @@ mcasp1: mcasp@2b10000 { clocks = <&k3_clks 105 0>; clock-names = "fck"; power-domains = <&k3_pds 105 TI_SCI_PD_EXCLUSIVE>; - - status = "disabled"; }; mcasp2: mcasp@2b20000 { @@ -808,8 +804,6 @@ mcasp2: mcasp@2b20000 { clocks = <&k3_clks 106 0>; clock-names = "fck"; power-domains = <&k3_pds 106 TI_SCI_PD_EXCLUSIVE>; - - status = "disabled"; }; cal: cal@6f03000 { @@ -865,8 +859,6 @@ dss: dss@04a00000 { interrupts = <GIC_SPI 166 IRQ_TYPE_EDGE_RISING>; - status = "disabled"; - dss_ports: ports { #address-cells = <1>; #size-cells = <0>; diff --git a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts index d12dd89f3405..199c4d4e7539 100644 --- a/arch/arm64/boot/dts/ti/k3-am654-base-board.dts +++ b/arch/arm64/boot/dts/ti/k3-am654-base-board.dts @@ -486,3 +486,19 @@ &cpsw_port1 { phy-mode = "rgmii-rxid"; phy-handle = <&phy0>; }; + +&mcasp0 { + status = "disabled"; +}; + +&mcasp1 { + status = "disabled"; +}; + +&mcasp2 { + status = "disabled"; +}; + +&dss { + status = "disabled"; +};
The device tree standard sets the default node behavior when status property as enabled. There are many reasons for doing the same, number of strings in device tree, default power management functionality etc are few of the reasons. In general, after a few rounds of discussions [1] there are few options one could take when dealing with SoC dtsi and board dts a. SoC dtsi provide nodes as a super-set default (aka enabled) state and to prevent messy board files, when more boards are added per SoC, we optimize and disable commonly un-used nodes in board-common.dtsi b. SoC dtsi disables all hardware dependent nodes by default and board dts files enable nodes based on a need basis. c. Subjectively pick and choose which nodes we will disable by default in SoC dtsi and over the years we can optimize things and change default state depending on the need. While there are pros and cons on each of these approaches, the right thing to do will be to stick with device tree default standards and work within those established rules. So, we choose to go with option (a). Lets cleanup defaults of am654 SoC dtsi before this gets more harder to cleanup later on and new SoCs are added. The dtb generated is identical with the patch and it is just cleanup to ensure we have a clean usage model [1] https://lore.kernel.org/linux-arm-kernel/20201027130701.GE5639@atomide.com/ Fixes: 9bcb631e9953 ("arm64: dts: ti: k3-am654-main: Add McASP nodes") Fixes: fc539b90eda2 ("arm64: dts: ti: am654: Add DSS node") Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Cc: Peter Ujfalusi <peter.ujfalusi@ti.com> Cc: Tony Lindgren <tony@atomide.com> Signed-off-by: Nishanth Menon <nm@ti.com> --- arch/arm64/boot/dts/ti/k3-am65-main.dtsi | 8 -------- arch/arm64/boot/dts/ti/k3-am654-base-board.dts | 16 ++++++++++++++++ 2 files changed, 16 insertions(+), 8 deletions(-)