dt-bindings: soc: adi: Add SC5XX SoC component bindings #3033

artursartamonovsadi · 2025-12-02T15:08:39Z

Document device tree bindings for ADI SC5XX SoC components including
PADS config, reset controller, system event controller, trigger routing
unit, and RPMSG support.

Ported files from 5.15.x lnxdsp-linux repo

PR Type

Bug fix (a change that fixes an issue)
New feature (a change that adds new functionality)
Breaking change (a change that affects other repos or cause CIs to fail)

PR Checklist

I have conducted a self-review of my own code changes
I have compiled my changes, including the documentation
I have tested the changes on the relevant hardware
I have updated the documentation outside this repo accordingly
I have provided links for the relevant upstream lore

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml

Documentation/devicetree/bindings/soc/adi/adi,system-event-controller.yaml

pamolloy · 2025-12-02T15:38:35Z

@artursartamonovsadi don't worry about the builds succeeding but please take a look at the "checks":

https://github.com/analogdevicesinc/linux/actions/runs/19863355918/job/56919188243?pr=3033

artursartamonovsadi · 2025-12-03T14:23:22Z

device-tree binding checks are passing

nunojsa · 2025-12-04T14:05:09Z

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml

+  - Arturs Artamonovs <arturs.artamonovs@analog.com>
+  - Utsav Agarwal <Utsav.Agarwal@analog.com>
+
+description: |


In practice, no need for pre-formatting

nunojsa · 2025-12-04T14:06:06Z

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml

+      ...
+      adi,system-config = <&pads_system_config>;
+      ...
+    };


Just to note (it seems this is not the case). The preferred style for indentation in the DT example are 4 spaces

Im checking other yaml DT examples all of them have 2 spaces, that why I followed that style

nunojsa · 2025-12-04T14:06:35Z

Documentation/devicetree/bindings/soc/adi/adi,reset-controller.yaml

+
+  adi,sharc-max:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: "Maximum valid SHARC core ID/count"


no constrains? Can we have the full unsigned int range?

I will limit it to 2 cores

nunojsa · 2025-12-04T14:07:11Z

Documentation/devicetree/bindings/soc/adi/adi,system-event-controller.yaml

+  reg:
+    maxItems: 1
+
+  "adi,rcu":


Why quoting?

nunojsa · 2025-12-04T14:08:04Z

Documentation/devicetree/bindings/soc/adi/adi,system-event-controller.yaml

+
+  "adi,sharc-cores":
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: "Number of SHARC cores available"


Same comment about constrains. I guess we have a limited number of cores 😉

nunojsa · 2025-12-04T14:12:07Z

Documentation/devicetree/bindings/soc/adi/adi,trigger-routing-unit.yaml

+        "adi,tru-slave-id":
+          description: Trigger Routing Slave ID
+          minItems: 1
+          maxItems: 1


I think you only need minItems: 1. Then maxItems defaults to 1...

nunojsa · 2025-12-04T14:12:45Z

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml

+    oneOf:
+      - items:
+          - enum:
+              - adi,pads-system-config


Why? Keep the original please

nunojsa · 2025-12-04T14:12:59Z

Documentation/devicetree/bindings/soc/adi/adi,system-event-controller.yaml

+    oneOf:
+      - items:
+          - enum:
+              - adi,system-event-controller


nunojsa · 2025-12-04T14:13:35Z

Documentation/devicetree/bindings/soc/adi/adi,trigger-routing-unit.yaml

      adi,max-slave-id = <187>;
-    };

-    &tru {


Ahh I see. The fixup commits are not very helpful for reviewing

Should I merge them then and just to have single commit?

Yup, fixup commits are helpful for development, but should be squashed before review and merge. A PR really shouldn't be approved with fixup commits. And the DCO workflow also doesn't seem to handle it

The re-review button in the Reviewers section at the top left of the PR is also super helpful after you've made a bunch of updates to notify folks

Documentation/devicetree/bindings/soc/adi/adi,trigger-routing-unit.yaml

pamolloy · 2025-12-04T15:24:47Z

We discussed during the meeting yesterday, but it would be good to convert the txt to yaml.

Can you also update MAINTAINERS appropriately?

nunojsa · 2025-12-04T15:27:17Z

We discussed during the meeting yesterday, but it would be good to convert the txt to yaml.

Agreed! It's work that will be needed anyways so better to do it now.

artursartamonovsadi · 2025-12-05T12:42:56Z

We discussed during the meeting yesterday, but it would be good to convert the txt to yaml.

Can you also update MAINTAINERS appropriately?

Hi, I prefer the scope of PR to stay within devicetree bindings, there is no maintainers defined in this adsp-main-6.12 branches, so far. But MAINTAINERS defined in upstreaming patch series. Maybe better to open separate PR, with complete MAINTAINERS list, rather in single PR we can try to fix all the issues.

artursartamonovsadi · 2025-12-05T16:02:39Z

@nunojsa I have left one "|" in adi,rpmsg-SC598.yaml description as if I remove it I get this error from dt binding check:
Error: entation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml:21:60: [error] syntax error: mapping values are not allowed here (syntax)

nunojsa · 2025-12-12T12:04:17Z

I have left one "|" in adi,rpmsg-SC598.yaml description as if I remove it I get this error from dt binding check:
Error: entation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml:21:60: [error] syntax error: mapping values are not allowed here (syntax)

That's odd! I would suspect there's more into it. AFAIK, there is no mandatory usage for |

nunojsa

Some more comments from me. As @pamolloy, I would expect a commit per binding

nunojsa · 2025-12-12T12:05:28Z

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml

+    emac0: ethernet@31040000 {
+      reg = <0x31040000 0x2000>;
+      adi,system-config = <&pads_system_config>;
+    };


Indentation still looks wrong... Are you using 4 spaces? I think 2 spaces is also acceptable but IIRC, 4 is the preferred

I followed other yaml DT examples all of them have 2 spaces

As I said, IIRC 2 spaces are acceptable but nor the preferred:

https://elixir.bootlin.com/linux/v6.18.1/source/Documentation/devicetree/bindings/example-schema.yaml#L269

nunojsa · 2025-12-12T12:06:26Z

Documentation/devicetree/bindings/soc/adi/adi,reset-controller.yaml

+  adi,sharc-max:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Maximum valid SHARC core ID/count
+    maximum: 2


Hmm the above two is odd. Why not a simple adi,sharc-count? Or just the adi,sharc-max. IOW, why do we need both properties?

All cores have their ID's from system perspective. Like In case of SC598 Core0/ARM, Core1/SHARC, Core2/SHARC,
adi,sharc-min will be 1, and adi-sharc-max will be 2. For SC589 it will be Core0/ARM, Core1/SHARC adi,sharc-min 1, adi-sharc-max 2. For something like SC596 and SC570 there will be just 1 SHARC Core. so adi,sharc-min and adi,sharc-max will be 1

This will not fit well when core id's assigned in other order or not in continues Core id's

Hmm I see, Still two properties seems wrong to me and hard to understand. What about something like adi,sharc-core-ids? And the property is an array of minimum 1 and maximum of what? Not sure what's the max number of shark cores we can have today :). And example:

https://elixir.bootlin.com/linux/v6.18.1/source/Documentation/devicetree/bindings/input/adi,adp5588.yaml#L67

Will fix in yaml file and do new PR for fix within a driver

nunojsa · 2025-12-12T12:07:19Z

Documentation/devicetree/bindings/soc/adi/adi,reset-controller.yaml

+  adi,sharc-min:
+    $ref: /schemas/types.yaml#/definitions/uint32
+    description: Minimum valid SHARC core ID/count
+    minimum: 0


There is no maximum in this property...

nunojsa · 2025-12-12T12:08:29Z

Documentation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml

+  - Utsav Agarwal <Utsav.Agarwal@analog.com>
+
+description: |
+  Describes device tree binding for adi rpmsg driver


bindings are not about drivers. It's about HW. Don't use description like the above or any driver details in bindings. Maintainers will complain about it

nunojsa · 2025-12-12T12:09:31Z

Documentation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml

+   262144 | 0x00684000 | 0x08000000
+   524288 | 0x00d04000 | 0x10000000
+  1048576 | 0x01a04000 | 0x20000000
+  2097152 | 0x03404000 | 0x40000000


Seems like you're adding too much description in here. Just add a small device description

nunojsa · 2025-12-12T12:10:14Z

Documentation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml

+  reg:
+    maxItems: 1
+
+  core-id:


Is this a standard property? Otherwise it needs the adi vendor prefix

Its sharc core id for rpmsg communication

nunojsa · 2025-12-12T12:10:41Z

Documentation/devicetree/bindings/soc/adi/adi,rpmsg-SC598.yaml

+
+  memory-region:
+    maxItems: 1
+    description: |


the above both properties could drop |

Documentation/devicetree/bindings/soc/adi/adi,trigger-routing-unit.yaml

artursartamonovsadi · 2025-12-12T16:09:48Z

We discussed during the meeting yesterday, but it would be good to convert the txt to yaml.

Can you also update MAINTAINERS appropriately?

Created MAINTAINERS entries for all other drivers #3045

Document the PADS system configuration register binding. Provides voltage and endian selection controls for SC5XX peripheral drivers. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

Document the Reset Control Unit (RCU) binding for managing SHARC and ARM core start/stop/reset operations on SC5XX processors Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

Document the RPMSG binding for ARM-SHARC inter-core communication on SC598 processors using TRU-based signaling and shared memory. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

… SC5XX Document the System Event Controller (SEC) binding, which provides interrupt control for SHARC cores on SC5XX processors. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

Document the Trigger Routing Unit (TRU) binding for mapping trigger masters to slaves, enabling inter-core communication on SC5XX. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

artursartamonovsadi requested review from CalebEthridgeADI, UtsavAgarwalADI, jiez, nunojsa, ozan956, pamolloy and vasbimpikasadi December 2, 2025 15:09

pamolloy reviewed Dec 2, 2025

View reviewed changes

Documentation/devicetree/bindings/soc/adi/adi,pads-system-config.yaml Outdated Show resolved Hide resolved

pamolloy reviewed Dec 2, 2025

View reviewed changes

Documentation/devicetree/bindings/soc/adi/adi,system-event-controller.yaml Outdated Show resolved Hide resolved

ozan956 approved these changes Dec 3, 2025

View reviewed changes

UtsavAgarwalADI approved these changes Dec 3, 2025

View reviewed changes

CalebEthridgeADI approved these changes Dec 3, 2025

View reviewed changes

nunojsa reviewed Dec 4, 2025

View reviewed changes

artursartamonovsadi force-pushed the adsp-main-6.12-devicetree-soc branch from e70e148 to 17ae7c8 Compare December 5, 2025 12:54

pamolloy requested a review from nunojsa December 10, 2025 09:12

artursartamonovsadi force-pushed the adsp-main-6.12-devicetree-soc branch from 91c267a to ffd6b12 Compare December 10, 2025 14:14

nunojsa reviewed Dec 12, 2025

View reviewed changes

artursartamonovsadi force-pushed the adsp-main-6.12-devicetree-soc branch 2 times, most recently from 557a43f to e4fdef9 Compare December 15, 2025 19:13

artursartamonovsadi added 3 commits December 15, 2025 19:17

dt-bindings: soc: adi: Add PADS system config binding for SC5XX

248a3bd

Document the PADS system configuration register binding. Provides voltage and endian selection controls for SC5XX peripheral drivers. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

dt-bindings: soc: adi: Add reset controller config binding for SC5XX

a181f77

Document the Reset Control Unit (RCU) binding for managing SHARC and ARM core start/stop/reset operations on SC5XX processors Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

dt-bindings: soc: adi: Add rpmsg config binding for SC5XX

2fdca97

Document the RPMSG binding for ARM-SHARC inter-core communication on SC598 processors using TRU-based signaling and shared memory. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

dt-bindings: soc: adi: Add system event controller config binding for…

a8d311a

… SC5XX Document the System Event Controller (SEC) binding, which provides interrupt control for SHARC cores on SC5XX processors. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

artursartamonovsadi force-pushed the adsp-main-6.12-devicetree-soc branch from e4fdef9 to 1bc5ff6 Compare December 15, 2025 19:19

artursartamonovsadi requested review from nunojsa and pamolloy December 16, 2025 08:07

dt-bindings: soc: adi: Add trigger routing unit config binding for SC5XX

facfd8c

Document the Trigger Routing Unit (TRU) binding for mapping trigger masters to slaves, enabling inter-core communication on SC5XX. Signed-off-by: Arturs Artamonovs <Arturs.Artamonovs@analog.com>

artursartamonovsadi force-pushed the adsp-main-6.12-devicetree-soc branch from 3ffb77b to facfd8c Compare December 17, 2025 17:26

dt-bindings: soc: adi: Add SC5XX SoC component bindings #3033

Are you sure you want to change the base?

dt-bindings: soc: adi: Add SC5XX SoC component bindings #3033

Uh oh!

Conversation

artursartamonovsadi commented Dec 2, 2025

PR Type

PR Checklist

Uh oh!

Uh oh!

Uh oh!

pamolloy commented Dec 2, 2025

Uh oh!

artursartamonovsadi commented Dec 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

pamolloy Dec 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

pamolloy commented Dec 4, 2025

Uh oh!

nunojsa commented Dec 4, 2025

Uh oh!

artursartamonovsadi commented Dec 5, 2025

Uh oh!

artursartamonovsadi commented Dec 5, 2025

Uh oh!

nunojsa commented Dec 12, 2025

Uh oh!

nunojsa left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

pamolloy Dec 10, 2025 •

edited

Loading