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

["Sharma, Rahul" <r-sharma3@ti.com>]

Hi Peter,

On 9/19/2026 11:34 AM, Peter Rosin wrote:
> Den Fri, Sep 18, 2026 at 11: 35: 28PM +0530, skrev rahul sharma: > Hi
> Conor, > > On 18/09/26 03: 40, Conor wrote: > > On 17 September 2026 17:
> 44: 21 GMT+02: 00, rahul sharma <r-sharma3@ ti. com> > > wrote: >Hi Conor,
> 
> 
> Den Fri, Sep 18, 2026 at 11:35:28PM +0530, skrev rahul sharma:
>> Hi Conor,
>> 
>> On 18/09/26 03:40, Conor wrote:
>> > On 17 September 2026 17: 44: 21 GMT+02: 00, rahul sharma <r-sharma3@ ti. com>
>> > wrote: >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,
>> > 
>> > 
>> > 
>> > On 17 September 2026 17:44:21 GMT+02:00, rahul sharma <r-sharma3@ti.com> wrote:
>> > > 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@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: https://urldefense.com/v3/__http://devicetree.org/schemas/mux/ti,am62l-
> event- > <https://urldefense.com/v3/__http://devicetree.org/schemas/mux/ti,am62l-event-
>>>> mux-router.yaml*__;Iw!!G3vK!VJUh5A8cDCko1ZAGtTQ8V-
>> > LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDckFu6UyA$ <https://urldefense.com/v3/__http://devicetree.org/schemas/mux/ti,am62l-
> event-mux-router.yaml*__;Iw!!G3vK!VJUh5A8cDCko1ZAGtTQ8V-
> LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDckFu6UyA$> > <https://urldefense.com/v3/__http://devicetree.org/schemas/mux/ti,am62l-event-mux-router.yaml*__;Iw!!G3vK!VJUh5A8cDCko1ZAGtTQ8V-LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDckFu6UyA$>
>>>> > > > > > +$schema: https://urldefense.com/v3/__http://devicetree.org/meta-schemas/
> core.yaml*__;Iw!! > <https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!
>>>> G3vK!VJUh5A8cDCko1ZAGtTQ8V-LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDdyRJuLcg$ <https://urldefense.com/v3/__http://devicetree.org/meta-schemas/
> core.yaml*__;Iw!!G3vK!VJUh5A8cDCko1ZAGtTQ8V-
> LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDdyRJuLcg$> > <https://urldefense.com/v3/__http://devicetree.org/meta-schemas/core.yaml*__;Iw!!G3vK!VJUh5A8cDCko1ZAGtTQ8V-LL1vTj1BNr5NNBonzfy5GnFCQkP4Oc-0Kkq4xVdCcEA5bQcDdyRJuLcg$>
>>>> > > > > > +
>> > > > > > > +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.
>> > > > 
>> > > 
>> > > 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.
>> > 
>> > The reason you cite here for needing reg offset is exactly what using mux-controls from a consumer node provides.
>> 
>> I will refactor this to use mux-control-cells. I will drop ti,reg-mask-val
>> from the bindings and instead source the reg-offset and value from the
>> consumer node.
> 
> Since you have this ti,reg-mask-val in the binding I assume you have 
> different setups needing different values. But, since it is obviously OK 
> to handle the variation in the mux-controller DT node, it should also be 
> possible to simply enumerate the different setups as different 
> compatibles. Then all needed compatibles could be handled by this driver 
> which would use the compatible to look up the needed values in a table.
> 
> The relevant tqble can surely not be all that large?
> 
> I prefer that over passing values in the cells, whixh seems a bit 
> convoluted to me.
> 
> Cheers,
> Peter

Thanks for the feedback and the suggestion.

I will move forward with the mux-consumer approach and drop the
ti,reg-mask-val property to keep the implementation more generic.

While the number of compatible strings may be manageable for the current
hardware, we are expecting a new series of SoCs in development that will
follow this architecture. Using unique compatible strings for every
routing variation would lead to an excessive growth of strings in the
driver, increasing the upstream maintenance burden. By allowing the reg
offset(or output channel number) to be defined in the consumer DT node,
we keep the driver logic generic and avoid unnecessary complexity as
this along with new SoC series evolves.

BR,
Rahul
>