Message-ID: <1ce1fc6b-fc16-4fb7-9f68-57b495aa5eae@ti.com>
Date: Tue, 22 Apr 2025 14:12:21 +0530
From: Chintan Vankar <c-vankar@...com>
To: Rob Herring <robh@...nel.org>
CC: Conor Dooley <conor+dt@...nel.org>,
        Krzysztof Kozlowski
	<krzk+dt@...nel.org>,
        Peter Rosin <peda@...ntia.se>, <s-vadapalli@...com>,
        <danishanwar@...com>, <linux-kernel@...r.kernel.org>,
        <devicetree@...r.kernel.org>, Vignesh Raghavendra <vigneshr@...com>,
        Nishanth
 Menon <nm@...com>
Subject: Re: [RFC PATCH v2 1/2] devicetree: bindings: mux: reg-mux: Update
 bindings for reg-mux for new property

Hello Rob,

The reason to introduce new bindings for mux-controller is to make use
of it to implement Timesync Router. Timesync Router module provides a
mechanism to mux M interrupt inputs to N interrupt outputs, where all M
inputs are selectable to be driven per N ouput.

More details about Timesync Router can be found in section 11.3.2.1 of
TRM at: https://www.ti.com/lit/ug/spruiu1d/spruiu1d.pdf

Timesync Router is identical to mux-controller, but the issue to use
mux-controller subsystem for it is it's current binding. As it is
discussed in the series, drawback of this approach is, while configuring
mux-controller one need to specify every register of memory space with
offset and mask in "mux-reg-masks" and "idle-states" property, it would
be complex for the devices with large memory space. To overcome this
limitation, new bindings are introduced, which allows to define all
these values in the same property, making it easy to define and extend
the mux-controller node.

We tried to implement Timesync Router by modeling it as an Interrupt
Router. But that is not accepted, RFC series for that is at:
https://lore.kernel.org/r/20250205160119.136639-1-c-vankar@ti.com/.

Also we tried to implement it as a new driver in MUX subsystem, but that
is almost identical to "mmio.c" driver, which I posted it as this
series.

I want your suggestion on whether a new bindings can be acceptable and
we can use the same to implement Timesync Router, if not can you please
advice me on how can I implement it ?

Regards,
Chintan.

On 06/03/25 04:00, Vankar, Chintan wrote:
> Hello Rob,
> 
> On 3/6/2025 3:44 AM, Rob Herring wrote:
>> On Wed, Mar 5, 2025 at 3:43 PM Vankar, Chintan <c-vankar@...com> wrote:
>>>
>>> Hello Rob,
>>>
>>> On 3/5/2025 2:10 AM, Rob Herring wrote:
>>>> On Tue, Mar 4, 2025 at 1:03 PM Vankar, Chintan <c-vankar@...com> wrote:
>>>>>
>>>>> Hello Rob,
>>>>>
>>>>> On 3/4/2025 9:09 PM, Rob Herring wrote:
>>>>>> On Tue, Mar 04, 2025 at 03:53:05PM +0530, Chintan Vankar wrote:
>>>>>>> DT-binding of reg-mux is defined in such a way that one need to 
>>>>>>> provide
>>>>>>> register offset and mask in a "mux-reg-masks" property and 
>>>>>>> corresponding
>>>>>>> register value in "idle-states" property. This constraint forces 
>>>>>>> to define
>>>>>>> these values in such a way that "mux-reg-masks" and "idle-states" 
>>>>>>> must be
>>>>>>> in sync with each other. This implementation would be more 
>>>>>>> complex if
>>>>>>> specific register or set of registers need to be configured which 
>>>>>>> has
>>>>>>> large memory space. Introduce a new property 
>>>>>>> "mux-reg-masks-state" which
>>>>>>> allow to specify offset, mask and value as a tuple in a single 
>>>>>>> property.
>>>>>>
>>>>>> Maybe in hindsight that would have been better, but having 2 ways to
>>>>>> specify the same thing that we have to maintain forever is not an
>>>>>> improvement.
>>>>>>
>>>>>> No one is making you use this binding. If you have a large number of
>>>>>> muxes, then maybe you should use a specific binding.
>>>>>>
>>>>>
>>>>> Thank you for reviewing the patch. The reason behind choosing mux
>>>>> subsystem is working and implementation of mmio driver. As we can see
>>>>> that implementing this new property in mux-controller is almost
>>>>> identical to mmio driver, and it would make it easier to define and
>>>>> extend mux-controller's functionality. If we introduce the new driver
>>>>> than that would be most likely a clone of mmio driver.
>>>>
>>>> I'm talking about the binding, not the driver. They are independent.
>>>> Generic drivers are great. I love them. Generic bindings, not so much.
>>>>
>>>>> Let me know if implementation would be accepted by adding a new
>>>>> compatible for it.
>>>>
>>>> Adding a new compatible to the mmio driver? Certainly. That happens
>>>> all the time.
>>>>
>>>> I also didn't say don't use this binding as-is. That's fine too.
>>>>
>>>
>>> Can you please review the following binding:
>>>
>>> oneOf:
>>>     - required: [ mux-reg-masks ]
>>>     - required: [ mux-reg-masks-state ]
>>>
>>> allOf:
>>>     - if:
>>>         required:
>>>           - mux-reg-masks-state
>>>       then:
>>>         properties:
>>>           idle-states: false
>>>
>>> required:
>>>     - compatible
>>>     - '#mux-control-cells'
>>>
>>> I think it won't disturb the current bindings and keep backward
>>> compatibility with existing implementation.
>>
>> Wasn't that the case before? There's nothing really different here.
>>
> 
> No, the binding before was not considering "mux-reg-masks" as required
> property which was breaking actual dt-binding. In this binding, one of
> the properties from "mux-reg-masks" or "mux-reg-masks-state" is required
> which keeps the binding as it is unless someone wants to use
> "mux-reg-masks-state".
> 
> Regards,
> Chintan.
> 
>> Rob

Powered by blists - more mailing lists