[PATCH 0/6] arm64: ti: Use syscon for the Control Module

[PATCH 0/6] arm64: ti: Use syscon for the Control Module

[Tomi Valkeinen]

I have been trying to get BeagleY-AI display support to upstream:

20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com

One difficulty has been the handling of the Control Module region, as
we need access to a single in that region, surrounded by registers for
other subsystems. In my series I made the related node a syscon, thus
allowing versatile access to the registers:

https://lore.kernel.org/all/20260513-beagley-ai-display-v2-14-9e9bcefde6bc@ideasonboard.com/

However, that's not a correct way to handle it. I realized we already
have ti,j721e-system-controller.yaml binding for older SoCs, which has
syscon but it's not used for the newer TI SoCs. This series takes the
same binding into use for the newer SoCs.

I think this is an ABI change, but I also think this is not an ABI
break. I hope people with more expertise in this area can confirm my
thoughts.

I believe we could drop the renaming patches, and just adjust the
ti,j721e-system-controller.yaml a bit more to accommodate the "wrong"
node names. But if there's no downside to the renames, I think it's nice
to have a more consistent naming.

 Tomi

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
Tomi Valkeinen (6):
      arm64: dts: ti: j784s4/j742s2: Rename pcieN-ctrl nodes to pcie-ctrl
      arm64: dts: ti: k3-am62*: Rename 'clock-controller' to 'clock'
      arm64: dts: ti: k3-am62-main: Rename 'oldi-io-controller' to 'dss-oldi-io-ctrl'
      dt-bindings: soc: ti: ti,j721e-system-controller: Relax the bindings
      dt-bindings: soc: ti: ti,j721e-system-controller: Add more compatibles
      arm64: dts: ti: Use syscon and simple-mfd for the main conf region

 .../devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml | 10 ++++++----
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi                       |  9 +++++----
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi                      |  7 ++++---
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi         |  6 +++---
 arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi       |  6 +++---
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi                     |  4 ++--
 6 files changed, 23 insertions(+), 19 deletions(-)
---
base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
change-id: 20260528-ti-main-conf-d75aea5e5c2b

Best regards,
--  
Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>

[PATCH 1/6] arm64: dts: ti: j784s4/j742s2: Rename pcieN-ctrl nodes to pcie-ctrl

[Tomi Valkeinen]

For some reason the pcie control node names were numbered
(e.g. 'pcie1-ctrl'). Fix the names to 'pcie-ctrl' so that we can, in a
later patch, more easily use a common system controller binding.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 4 ++--
 arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi               | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index c2636e624f18..2570723efa4f 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
@@ -65,12 +65,12 @@ cpsw0_phy_gmii_sel: phy@4044 {
 			ti,qsgmii-main-ports = <7>, <7>;
 		};
 
-		pcie0_ctrl: pcie0-ctrl@4070 {
+		pcie0_ctrl: pcie-ctrl@4070 {
 			compatible = "ti,j784s4-pcie-ctrl", "syscon";
 			reg = <0x4070 0x4>;
 		};
 
-		pcie1_ctrl: pcie1-ctrl@4074 {
+		pcie1_ctrl: pcie-ctrl@4074 {
 			compatible = "ti,j784s4-pcie-ctrl", "syscon";
 			reg = <0x4074 0x4>;
 		};
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
index 78fcd0c40abc..336bb9b99201 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi
@@ -152,12 +152,12 @@ c71_3: dsp@67800000 {
 };
 
 &scm_conf {
-	pcie2_ctrl: pcie2-ctrl@4078 {
+	pcie2_ctrl: pcie-ctrl@4078 {
 		compatible = "ti,j784s4-pcie-ctrl", "syscon";
 		reg = <0x4078 0x4>;
 	};
 
-	pcie3_ctrl: pcie3-ctrl@407c {
+	pcie3_ctrl: pcie-ctrl@407c {
 		compatible = "ti,j784s4-pcie-ctrl", "syscon";
 		reg = <0x407c 0x4>;
 	};

-- 
2.43.0

[PATCH 2/6] arm64: dts: ti: k3-am62*: Rename 'clock-controller' to 'clock'

[Tomi Valkeinen]

Multiple dtsi files have clock nodes with 'clock-controller' names.
Rename them to 'clock' to be more in line with the fact that it's just a
single clock.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi               | 4 ++--
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi              | 4 ++--
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi | 4 ++--
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index c5ee263d34a6..228f8c3e8bf6 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -59,7 +59,7 @@ epwm_tbclk: clock-controller@4130 {
 			#clock-cells = <1>;
 		};
 
-		audio_refclk0: clock-controller@82e0 {
+		audio_refclk0: clock@82e0 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e0 0x4>;
 			clocks = <&k3_clks 157 0>;
@@ -68,7 +68,7 @@ audio_refclk0: clock-controller@82e0 {
 			#clock-cells = <0>;
 		};
 
-		audio_refclk1: clock-controller@82e4 {
+		audio_refclk1: clock@82e4 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e4 0x4>;
 			clocks = <&k3_clks 157 10>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 9e5b75a4e88e..9287d7be7cc8 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -60,7 +60,7 @@ epwm_tbclk: clock-controller@4130 {
 			#clock-cells = <1>;
 		};
 
-		audio_refclk0: clock-controller@82e0 {
+		audio_refclk0: clock@82e0 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e0 0x4>;
 			clocks = <&k3_clks 157 0>;
@@ -69,7 +69,7 @@ audio_refclk0: clock-controller@82e0 {
 			#clock-cells = <0>;
 		};
 
-		audio_refclk1: clock-controller@82e4 {
+		audio_refclk1: clock@82e4 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e4 0x4>;
 			clocks = <&k3_clks 157 10>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index f130c7cb998d..7c2f03780885 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -46,7 +46,7 @@ main_conf: bus@100000 {
 		#size-cells = <1>;
 		ranges = <0x00 0x00 0x00100000 0x20000>;
 
-		audio_refclk0: clock-controller@82e0 {
+		audio_refclk0: clock@82e0 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e0 0x4>;
 			clocks = <&k3_clks 157 0>;
@@ -55,7 +55,7 @@ audio_refclk0: clock-controller@82e0 {
 			#clock-cells = <0>;
 		};
 
-		audio_refclk1: clock-controller@82e4 {
+		audio_refclk1: clock@82e4 {
 			compatible = "ti,am62-audio-refclk";
 			reg = <0x82e4 0x4>;
 			clocks = <&k3_clks 157 18>;

-- 
2.43.0

[PATCH 3/6] arm64: dts: ti: k3-am62-main: Rename 'oldi-io-controller' to 'dss-oldi-io-ctrl'

[Tomi Valkeinen]

In k3-am62-main.dtsi the OLDI IO controller node is named
'oldi-io-controller' but every other dtsi file has it as
'dss-oldi-io-ctrl'. Rename it to 'dss-oldi-io-ctrl' so we can more
easily use a common system controller binding in a future patch.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index 228f8c3e8bf6..ffc71ab623e0 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -77,7 +77,7 @@ audio_refclk1: clock@82e4 {
 			#clock-cells = <0>;
 		};
 
-		dss_oldi_io_ctrl: oldi-io-controller@8600 {
+		dss_oldi_io_ctrl: dss-oldi-io-ctrl@8600 {
 			compatible = "ti,am625-dss-oldi-io-ctrl", "syscon";
 			reg = <0x8600 0x200>;
 		};

-- 
2.43.0

[PATCH 4/6] dt-bindings: soc: ti: ti,j721e-system-controller: Relax the bindings

[Tomi Valkeinen]

The ti,j721e-system-controller binding specifies a specific schema for
each child node. For example, any clock node under the system controller
node must be a ti,am654-serdes-ctrl.

To be able to use the same system-controller binding for more SoCs,
relax the bindings by making both clock-controller and clock accept any
kind of child node.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 .../devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml      | 6 ++----
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index f3bd0be3b279..56712ebdd01b 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -53,9 +53,8 @@ patternProperties:
 
   "^clock-controller@[0-9a-f]+$":
     type: object
-    $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#
     description:
-      Clock provider for TI EHRPWM nodes.
+      A clock controller with registers in the Control Module.
 
   "phy@[0-9a-f]+$":
     type: object
@@ -76,9 +75,8 @@ patternProperties:
 
   "^clock@[0-9a-f]+$":
     type: object
-    $ref: /schemas/soc/ti/ti,am654-serdes-ctrl.yaml#
     description:
-      This is the Serdes Control region.
+      A clock with registers in the Control Module.
 
   "^dss-oldi-io-ctrl@[0-9a-f]+$":
     type: object

-- 
2.43.0

Re: [PATCH 4/6] dt-bindings: soc: ti: ti,j721e-system-controller: Relax the bindings

[Krzysztof Kozlowski]

On Thu, May 28, 2026 at 03:53:45PM +0300, Tomi Valkeinen wrote:
> The ti,j721e-system-controller binding specifies a specific schema for
> each child node. For example, any clock node under the system controller
> node must be a ti,am654-serdes-ctrl.
> 
> To be able to use the same system-controller binding for more SoCs,
> relax the bindings by making both clock-controller and clock accept any

NAK, you cannot relax bindings.

> kind of child node.
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
>  .../devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml      | 6 ++----
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> index f3bd0be3b279..56712ebdd01b 100644
> --- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> +++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
> @@ -53,9 +53,8 @@ patternProperties:
>  
>    "^clock-controller@[0-9a-f]+$":
>      type: object
> -    $ref: /schemas/clock/ti,am654-ehrpwm-tbclk.yaml#

No, child nodes cannot be generic (see also writing bindings). You must
have $ref or use the compatible style.

Best regards,
Krzysztof

[PATCH 5/6] dt-bindings: soc: ti: ti,j721e-system-controller: Add more compatibles

[Tomi Valkeinen]

Add the following to the list of accepted compatibles so that we can use
the same binding on these SoCs too:

ti,am62-system-controller
ti,am62a-system-controller
ti,am62p-system-controller
ti,j784s4-system-controller

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 .../devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml        | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
index 56712ebdd01b..11365cb9fb0a 100644
--- a/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
+++ b/Documentation/devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml
@@ -26,10 +26,14 @@ properties:
   compatible:
     items:
       - enum:
+          - ti,am62-system-controller
+          - ti,am62a-system-controller
+          - ti,am62p-system-controller
           - ti,am654-system-controller
           - ti,j7200-system-controller
           - ti,j721e-system-controller
           - ti,j721s2-system-controller
+          - ti,j784s4-system-controller
       - const: syscon
       - const: simple-mfd
 

-- 
2.43.0

Re: [PATCH 5/6] dt-bindings: soc: ti: ti,j721e-system-controller: Add more compatibles

[Krzysztof Kozlowski]

On Thu, May 28, 2026 at 03:53:46PM +0300, Tomi Valkeinen wrote:
> Add the following to the list of accepted compatibles so that we can use
> the same binding on these SoCs too:
> 
> ti,am62-system-controller
> ti,am62a-system-controller
> ti,am62p-system-controller
> ti,j784s4-system-controller

You just copied diff - that's pointless. We can read the diff. Explain
why - what are these? Why there is 62 and 62a? Are these different SoCs?

Your commit must say WHY you are doing this, not what you are doing.

Best regards,
Krzysztof

[PATCH 6/6] arm64: dts: ti: Use syscon and simple-mfd for the main conf region

[Tomi Valkeinen]

We already had a common binding (ti,j721e-system-controller.yaml) for
the Control Module region for multiple TI SoCs. This was not used for
more recent SoCs. These more recent SoCs just have a "simple-bus"
representing the Control Module. In a few cases the
simple-bus node also had "reg" property, which is not correct for a
simple-bus, but we make use of it in this patch.

With the adjustments done in previous commits to the dtsi files and the
bindings, we can now use the TI system-controller bindings in am62,
am62a, am62p-j722s and j784s4-j742s2 dtsi files. This means that the
node for the Control Module (labeled 'main_conf' or 'scm_conf') changes
from "simple-bus" to, e.g., "ti,am62p-system-controller", "syscon",
"simple-mfd".

While, as far as I understand, this is an ABI change, I believe this
does not cause any breakages: the old dtbs with "simple-bus" will
continue booting fine, with the child nodes getting instantiated, and
the new dtbs with "simple-mfd" behave exactly the same way.

With this change, we can use the Control Module as a syscon from the
drivers. E.g. on some SoCs we have a single register in the Control
Module related to DSS DPI output control, surrounded by registers for
totally different subsystems. Instead of having to create a new syscon
child node for this single register the DSS node can now just point to
the register with 'ti,dpi-io-ctrl = <&main_conf 0x8300>'.

Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
---
 arch/arm64/boot/dts/ti/k3-am62-main.dtsi                 | 3 ++-
 arch/arm64/boot/dts/ti/k3-am62a-main.dtsi                | 3 ++-
 arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi   | 2 +-
 arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi | 2 +-
 4 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
index ffc71ab623e0..3f61f2a9b2bb 100644
--- a/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62-main.dtsi
@@ -42,7 +42,8 @@ gic_its: msi-controller@1820000 {
 	};
 
 	main_conf: bus@100000 {
-		compatible = "simple-bus";
+		compatible = "ti,am62-system-controller", "syscon", "simple-mfd";
+		reg = <0 0x00100000 0 0x20000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 		ranges = <0x0 0x00 0x00100000 0x20000>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
index 9287d7be7cc8..2a5cadbc11fa 100644
--- a/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62a-main.dtsi
@@ -42,7 +42,8 @@ gic_its: msi-controller@1820000 {
 	};
 
 	main_conf: bus@100000 {
-		compatible = "simple-bus";
+		compatible = "ti,am62a-system-controller", "syscon", "simple-mfd";
+		reg = <0 0x00100000 0 0x20000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
 		ranges = <0x00 0x00 0x00100000 0x20000>;
diff --git a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
index 7c2f03780885..58805e287496 100644
--- a/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi
@@ -40,7 +40,7 @@ gic_its: msi-controller@1820000 {
 	};
 
 	main_conf: bus@100000 {
-		compatible = "simple-bus";
+		compatible = "ti,am62p-system-controller", "syscon", "simple-mfd";
 		reg = <0x00 0x00100000 0x00 0x20000>;
 		#address-cells = <1>;
 		#size-cells = <1>;
diff --git a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
index 2570723efa4f..cccd90d43446 100644
--- a/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
+++ b/arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi
@@ -46,7 +46,7 @@ l3cache-sram@200000 {
 	};
 
 	scm_conf: bus@100000 {
-		compatible = "simple-bus";
+		compatible = "ti,j784s4-system-controller", "syscon", "simple-mfd";
 		reg = <0x00 0x00100000 0x00 0x1c000>;
 		#address-cells = <1>;
 		#size-cells = <1>;

-- 
2.43.0

Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module

[Andrew Davis]

On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
> I have been trying to get BeagleY-AI display support to upstream:
> 
> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com
> 
> One difficulty has been the handling of the Control Module region, as
> we need access to a single in that region, surrounded by registers for
> other subsystems. In my series I made the related node a syscon, thus
> allowing versatile access to the registers:
> 
> https://lore.kernel.org/all/20260513-beagley-ai-display-v2-14-9e9bcefde6bc@ideasonboard.com/
> 
> However, that's not a correct way to handle it. I realized we already
> have ti,j721e-system-controller.yaml binding for older SoCs, which has
> syscon but it's not used for the newer TI SoCs. This series takes the
> same binding into use for the newer SoCs.
> 

We moved away from this system-controller thing because it was always
a hack to allow us to poke into random control registers from nodes
throughout the DT. This was a mess and also caused issues with multiple
mappings to the same registers (some sub nodes inside the control space
also make their own mappings). If you need access to registers then make
a node with those registers in the `reg` property.

The only reason we didn't get rid of `ti,j721e-system-controller.yaml`
completely from the older SoCs was we were told it would be an ABI
break to correct those DT files. Let's not spread that problem to
new SoCs.

Andrew

> I think this is an ABI change, but I also think this is not an ABI
> break. I hope people with more expertise in this area can confirm my
> thoughts.
> 
> I believe we could drop the renaming patches, and just adjust the
> ti,j721e-system-controller.yaml a bit more to accommodate the "wrong"
> node names. But if there's no downside to the renames, I think it's nice
> to have a more consistent naming.
> 
>   Tomi
> 
> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> ---
> Tomi Valkeinen (6):
>        arm64: dts: ti: j784s4/j742s2: Rename pcieN-ctrl nodes to pcie-ctrl
>        arm64: dts: ti: k3-am62*: Rename 'clock-controller' to 'clock'
>        arm64: dts: ti: k3-am62-main: Rename 'oldi-io-controller' to 'dss-oldi-io-ctrl'
>        dt-bindings: soc: ti: ti,j721e-system-controller: Relax the bindings
>        dt-bindings: soc: ti: ti,j721e-system-controller: Add more compatibles
>        arm64: dts: ti: Use syscon and simple-mfd for the main conf region
> 
>   .../devicetree/bindings/soc/ti/ti,j721e-system-controller.yaml | 10 ++++++----
>   arch/arm64/boot/dts/ti/k3-am62-main.dtsi                       |  9 +++++----
>   arch/arm64/boot/dts/ti/k3-am62a-main.dtsi                      |  7 ++++---
>   arch/arm64/boot/dts/ti/k3-am62p-j722s-common-main.dtsi         |  6 +++---
>   arch/arm64/boot/dts/ti/k3-j784s4-j742s2-main-common.dtsi       |  6 +++---
>   arch/arm64/boot/dts/ti/k3-j784s4-main.dtsi                     |  4 ++--
>   6 files changed, 23 insertions(+), 19 deletions(-)
> ---
> base-commit: e7ae89a0c97ce2b68b0983cd01eda67cf373517d
> change-id: 20260528-ti-main-conf-d75aea5e5c2b
> 
> Best regards,
> --
> Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
> 
> 

Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module

[Tomi Valkeinen]

Hi Andrew,

On 29/05/2026 01:59, Andrew Davis wrote:
> On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
>> I have been trying to get BeagleY-AI display support to upstream:
>>
>> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com
>>
>> One difficulty has been the handling of the Control Module region, as
>> we need access to a single in that region, surrounded by registers for
>> other subsystems. In my series I made the related node a syscon, thus
>> allowing versatile access to the registers:
>>
>> https://lore.kernel.org/all/20260513-beagley-ai-display- 
>> v2-14-9e9bcefde6bc@ideasonboard.com/
>>
>> However, that's not a correct way to handle it. I realized we already
>> have ti,j721e-system-controller.yaml binding for older SoCs, which has
>> syscon but it's not used for the newer TI SoCs. This series takes the
>> same binding into use for the newer SoCs.
>>
> 
> We moved away from this system-controller thing because it was always
> a hack to allow us to poke into random control registers from nodes
> throughout the DT. This was a mess and also caused issues with multiple
> mappings to the same registers (some sub nodes inside the control space
> also make their own mappings). If you need access to registers then make
> a node with those registers in the `reg` property.

Like in this patch (dss_dpi0_clk_ctrl)?

https://lore.kernel.org/all/20260420-beagley-ai-display-v1-14-f628543dfd14%40ideasonboard.com/

My understanding is that that's NACKed, as we end up adding new syscon 
compats and syscon nodes for (possibly many) single register blocks.

  Tomi

Re: [PATCH 0/6] arm64: ti: Use syscon for the Control Module

[Tomi Valkeinen]

Hi Andrew, Krzysztof,

On 29/05/2026 01:59, Andrew Davis wrote:
> On 5/28/26 7:53 AM, Tomi Valkeinen wrote:
>> I have been trying to get BeagleY-AI display support to upstream:
>>
>> 20260513-beagley-ai-display-v2-0-9e9bcefde6bc@ideasonboard.com
>>
>> One difficulty has been the handling of the Control Module region, as
>> we need access to a single in that region, surrounded by registers for
>> other subsystems. In my series I made the related node a syscon, thus
>> allowing versatile access to the registers:
>>
>> https://lore.kernel.org/all/20260513-beagley-ai-display- 
>> v2-14-9e9bcefde6bc@ideasonboard.com/
>>
>> However, that's not a correct way to handle it. I realized we already
>> have ti,j721e-system-controller.yaml binding for older SoCs, which has
>> syscon but it's not used for the newer TI SoCs. This series takes the
>> same binding into use for the newer SoCs.
>>
> 
> We moved away from this system-controller thing because it was always
> a hack to allow us to poke into random control registers from nodes
> throughout the DT. This was a mess and also caused issues with multiple
> mappings to the same registers (some sub nodes inside the control space
> also make their own mappings). If you need access to registers then make
> a node with those registers in the `reg` property.
> 
> The only reason we didn't get rid of `ti,j721e-system-controller.yaml`
> completely from the older SoCs was we were told it would be an ABI
> break to correct those DT files. Let's not spread that problem to
> new SoCs.
I'm still stuck on this issue.

So, to summarize, we have the big control module memory region from 
which various drivers need "random" registers. In my particular case, 
the display subsystem (DSS) driver needs to access a single register 
from the control module, but as the control module contains a lot of 
registers, there are other similar cases too (I've seen at least one 
other series, trying to add access to control module registers).

Taking AM62 SoC as an example, we have this in upstream:

https://github.com/torvalds/linux/blob/4edcdefd4083ae04b1a5656f4be6cd83ae919ef4/arch/arm64/boot/dts/ti/k3-am62-main.dtsi#L44

"main_conf" (simple-bus) node representing the control module, and nodes 
under that representing either small things like clocks or, in 
dss_oldi_io_ctrl case, a syscon.

I'm aware of three options on how to handle this.

1) Adding small syscon nodes under the main_conf, similar to the 
existing dss_oldi_io_ctrl.

I did this in the earlier series: 
https://lore.kernel.org/all/20260420-beagley-ai-display-v1-3-f628543dfd14%40ideasonboard.com/ 


2) Making the whole control module a syscon, as I do in this series.

3) Adding the required registers as a new 'reg' block under the dss' DT 
node.

Both 1) and 2) have been nacked or at least very strongly questioned. 3) 
doesn't feel right, the register is not a register for the IP but an 
external SoC integration register.

Is there an option 4)? In your opinion, is one of the above the one 
clear choice?

  Tomi