Re: Re: [PATCH 1/2] dt-bindings: mux-controller: ti: add binding for event mux router

[Conor Dooley <conor@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 5633 bytes --]

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@ti.com>
> > > ---
> > >   .../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@ti.com>
> > > +
> > > +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.

> 
> 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".

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
> > > 
> 

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]