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

[Peter Rosin <peda@lysator.liu.se>]

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