Re: [PATCH v2 1/3] dt-bindings: soc: ti: Document the ti,tda54-mcu-scm-conf binding
From: Moteen Shah
Date: Mon Nov 02 2026 - 00:21:19 EST
On 28/10/26 17:54, Krzysztof Kozlowski wrote:
On Tue, Oct 27, 2026 at 02:06:58PM +0530, Moteen Shah wrote:
TDA54's MCU domain exposes a shared scm_conf syscon region that otherA nit, subject: drop second/last, redundant "binding". The
peripherals, including chipid, access into rather than owning a
dedicated register window. Rather than a bare fallback entry in the
generic syscon compatible list, give it a dedicated binding
describing the region and the proxy/claim/lock arbitration scheme
that gates write access to a subset of its registers.
"dt-bindings" prefix is already stating that these are bindings.
See also:
https://elixir.bootlin.com/linux/v7.1-rc7/source/Documentation/devicetree/bindings/submitting-patches.rst#L23
Some of the claimable registers are gate clock controls, so alsoI don't get the need of this property. You have a one, specific device, so
document the required "#clock-cells" property that lets the node be
referenced directly as a clock provider for those gates. The clock
specifier selects the ePWM time-base gate by instance number.
Co-developed-by: Aniket Limaye <a-limaye@xxxxxx>
Signed-off-by: Aniket Limaye <a-limaye@xxxxxx>
Signed-off-by: Moteen Shah <m-shah@xxxxxx>
---
.../soc/ti/ti,tda54-mcu-scm-conf.yaml | 78 +++++++++++++++++++
1 file changed, 78 insertions(+)
create mode 100644 Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
diff --git a/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml b/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
new file mode 100644
index 0000000000000..111cbb739b5f1
--- /dev/null
+++ b/Documentation/devicetree/bindings/soc/ti/ti,tda54-mcu-scm-conf.yaml
@@ -0,0 +1,78 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/soc/ti/ti,tda54-mcu-scm-conf.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Texas Instruments TDA54 SoC MCU Domain System Control Module Configuration registers
+
+maintainers:
+ - Aniket Limaye <a-limaye@xxxxxx>
+ - Moteen Shah <m-shah@xxxxxx>
+
+description: |
+ The TDA54 SoC's MCU domain exposes a System Control Module configuration
+ register region (scm_conf) containing miscellaneous control and status
+ registers for MCU domain peripherals, including the JTAGID/device
+ identification registers, boot configuration and status registers, and
+ device feature registers.
+
+ A subset of these registers is write-protected by a proxy/claim scheme:
+ each register is mirrored across 8 proxy regions, and a host must unlock
+ via LOCK_KICK. Any proxy other than proxy-0 must also claim a register
+ through its CLAIM register before writing through that proxy. Proxy-0 is
+ the default access proxy: its claim bits are tied low, so it needs no
+ claim and can write any register that is not claimed by another proxy.
+ For example: Proxy0's CLAIM0 register sits at offset 0x3100, while the
+ same register mirrored at ProxyN sits at N * 0x4000 + 0x3100.
+
+ Each of the 8 proxy regions also has its own fault status and
+ interrupt registers, but a fault can only be handled through proxy-0.
+ Hence, interrupt/fault handling is not described by this binding.
+
+ Some of the claimable registers are gate clock controls (e.g. the
+ ehrpwm_tbclk gates). This node is the clock provider for those gates;
+ writes to them are still routed through the proxy claim scheme described
+ above.
+
+properties:
+ compatible:
+ const: ti,tda54-mcu-scm-conf
+
+ reg:
+ maxItems: 1
+
+ ti,proxy-id:
+ $ref: /schemas/types.yaml#/definitions/uint32
+ minimum: 0
+ maximum: 7
+ description:
+ Proxy region (0-7) through which this node's clients access
+ claimable registers and their fault status registers.
why the proxy id would vary per board?
It also looks like re-implementing access controllers.
Best regards,
Krzysztof
Thanks for the review, Krzysztof. I’ll drop the redundant “binding” from the subject.
ti,proxy-id is not intended to vary by board. It selects the proxy window used by this Linux instance. One use case we need to support is running two VMs with different proxy IDs, with each VM’s DT describing the proxy it uses.
The driver reads the ID from DT and performs register accesses through that proxy; it does not allocate proxy IDs or decide which VM uses which one.
Do let me know if this clears your question.
Regards,
Moteen