Re: [PATCH v2 1/3] dt-bindings: soc: ti: Document the ti,tda54-mcu-scm-conf binding

[Moteen Shah <m-shah@ti.com>]

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 other
>> 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.
>>
> A nit, subject: drop second/last, redundant "binding". The
> "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 also
>> 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@ti.com>
>> Signed-off-by: Aniket Limaye <a-limaye@ti.com>
>> Signed-off-by: Moteen Shah <m-shah@ti.com>
>> ---
>>   .../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@ti.com>
>> +  - Moteen Shah <m-shah@ti.com>
>> +
>> +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.
> I don't get the need of this property. You have a one, specific device, so
> 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