Re: Re: Re: [PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router
From: rahul sharma
Date: Thu Sep 17 2026 - 12:30:10 EST
Hi Conor,
On 15/09/26 19:19, Conor Dooley wrote:
On Tue, Sep 15, 2026 at 06:10:45PM +0530, rahul sharma wrote:
Hi Conor,
Thanks for reviewing.
Apologies for the delay in responding.
On 28/08/26 21:57, Conor Dooley wrote:
On Fri, Aug 28, 2026 at 03:36:14PM +0530, Rahul Sharma wrote:
Add binding for the event mux router of TI's K3 based SoC AM62L.
The TI K3 mux routers which route the GPIO input events or Time-Sync
events b/w peripherals instead of routing to a CPU.
Refer Section 10.2 and 10.2.1 of https://www.ti.com/lit/pdf/sprujb4
Signed-off-by: Rahul Sharma <r-sharma3@xxxxxx>
---
.../mux/ti,am62l-event-mux-router.yaml | 79 +++++++++++++++++++
1 file changed, 79 insertions(+)
create mode 100644 Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
diff --git a/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
new file mode 100644
index 000000000000..a5ba7f78a156
--- /dev/null
+++ b/Documentation/devicetree/bindings/mux/ti,am62l-event-mux-router.yaml
@@ -0,0 +1,79 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/mux/ti,am62l-event-mux-router.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI Event Multiplexer on K3 SoCs
+
+maintainers:
+ - Rahul Sharma <r-sharma3@xxxxxx>
+
+description:
+ The TI K3 mux routers routes the GPIO input events or Time
+ Sync events between peripherals instead of routing to a CPU.
+
+allOf:
+ - $ref: mux-controller.yaml#
+
+properties:
+ compatible:
+ const: ti,am62l-event-mux-router
+
+ reg:
+ description: Register base address and size.
+ maxItems: 1
+
+ '#mux-control-cells':
+ const: 1
+ description:
+ Number of cells in a mux control specifier. This should be 1.
+ The cell specifies which mux control to use (0-based index).
+
+ ti,reg-mask-val:
+ $ref: /schemas/types.yaml#/definitions/uint32-matrix
+ items:
+ items:
+ - description: Register offset (relative to reg base)
+ - description: Bit mask for the mux control bits
+ - description: Value to write when mux is active (state 1)
+ minItems: 1
+ description: |
+ Array of triplets specifying register offset, mask, and value for each
+ mux control. Each triplet contains:
+ - register offset (relative to reg base)
+ - bit mask for the mux control bits
+ - value to write when mux is active (state 1)
You have a device-specific compatible, why do you need this? If the
active setting depends on the device or w/e, why can that not come from
a mux-control-cell?
This is a boot-time/board-fixed routing decision, not a runtime-selectable
mux that any driver ever calls mux_control_select() on.
2/3 of this property appears to describe the register layout of the
device, that's not affected by the board or some boot time decision.
You are right about the mask element; I will move the mask into the driver since it is constant across all entries. However, the reg-offset must remain in the DT, as it is specific to each BCDMA channel's trigger line configuration. This allows the DT to define the unique routing offsets required for the hardware.
Please refer below link for the IP block diagram:
https://github.com/lucifer-9852/linux/commit/aed1746e411a9f0ad7824f4e4a7121e6f56a4ef2
For detailed view of IP you can refer Section 10.2 and 10.2.1 of TRM
https://www.ti.com/lit/pdf/sprujb4
That's precisely why we added ti,reg-mask-val as a controller-side property
rather than sourcing the value from a consumer's mux-control-cell: there is
no runtime consumer selecting between states, so the routing has to be fully
described on the provider.
Why do you have #mux-control-cells if there are no consumers? I don't
understand why the GPIO controller or the device that the interrupt is
being routed to cannot have a mux-controls property that contains the
"value to write when the mux is active".
You are correct regarding #mux-control-cells. Since, this driver is used for static routing rather than runtime selection by a consumer, that property is unnecessary. I will remove it.
BR,
Rahul
Confused,
Conor.
BR,
Rahul
+
+ idle-states:
+ $ref: /schemas/types.yaml#/definitions/uint32-array
This is not needed, you get the type from mux-controller.yaml.
pw-bot: changes-requested
Thanks,
Conor.
+ description: |
+ Idle state for each mux control. Each entry corresponds to a mux control:
+ - 0: clear masked bits when idle, also refers to inactive state
+ - 1: set configured value when idle, also refers to active state
+ - MUX_IDLE_AS_IS (-1): keep current state when idle
+
+required:
+ - compatible
+ - reg
+ - '#mux-control-cells'
+ - ti,reg-mask-val
+ - idle-states
+
+additionalProperties: false
+
+examples:
+ - |
+ #include <dt-bindings/mux/mux.h>
+
+ // Example 1: TI AM62L GPIO Mux Router
+ mux-controller@a00000 {
+ compatible = "ti,am62l-event-mux-router";
+ reg = <0xa00000 0x400>;
+ #mux-control-cells = <1>;
+
+ /* Mux Register addresses: 0xa00004 + (J × 4) */
+ /* GPIO0_40 -> BCDMA trigger 15 */
+ ti,reg-mask-val = <0x40 0x000ff 0x00028>;
+ idle-states = <0>;
+ };
--
2.34.1