Re: [PATCH V3 1/3] dt-binding: Add register-settings binding

[Jon Hunter <jonathanh@nvidia.com>]

Hi Rob,

On 09/10/2025 17:33, Rob Herring wrote:
> On Tue, Sep 30, 2025 at 04:01:27PM +0100, Jon Hunter wrote:
>> Hi Chintan,
>>
>> On 29/09/2025 05:39, Chintan Vankar wrote:
>>
>> ...
>>
>>> Following your series, I would like to bring to your attention that
>>> Texas Instruments SoCs also have a component which requires similar kind
>>> of configuration, named Timesync Router(TSR). It enables the
>>> multiplexing of M inputs to N outputs, where inputs can be selectively
>>> driven based on N output configuration. A detailed explanation of the
>>> TSR and our attempts we tried to implement TSR can be found in following
>>> RFC series:
>>> https://lore.kernel.org/all/20250605063422.3813260-1-c-vankar@ti.com/
>>> https://lore.kernel.org/all/20250205160119.136639-1-c-vankar@ti.com/
> 
> I fail to see how that is related to this series. I'm not going to
> study these 2 implementations and imagine how it could be implemented
> using this series. If the amount of overlap is just 'reg-settings' node,
> then that's not really enough. More below.
> 
>>> To implement TSR, the relevant registers must be configured via the
>>> device tree. We initially assumed that the device could be handled as a
>>> mux-controller and could be extended in the same subsystem, but it was
>>> ineffective. Having explored both the approaches, we now plan to
>>> implement TSR within misc subsystem, which aligns with the dt-bindings
>>> that you have proposed in this series.
>>>
>>> The purpose to replying over this series is to inform you that we also
>>> have a component requiring configuration as outlined in this series. Let
>>> us know if you have any suggestions for this.
>>
>> That's great! Thanks for the feedback.
>>
>> Rob, Krzysztof, Conor, have you guys had chance to look at this series some
>> more? We are open to re-working it as necessary to address any
>> concerns/comments you have. However, this appears to be stalled at the
>> moment and I am not sure what we should do next to push this forward.
> 
> I fail to see what is generic here? There's a generic node name, but
> that has nothing else common. The 2 examples share nothing because it
> is all bus specific. But then the bus specific stuff is NVIDIA specific.
> It's the bus specific part that should be generic (to the bus type) IMO.

We are looking for a generic way to program values into hardware 
register fields for various different devices such as I2C, SPI, USB, 
PCIe, etc. Device-tree is a good candidate for this, because the values 
can be device or board specific. I know this was a year ago now, but at 
last years plumbers we did discuss with Krzysztof and other vendors at 
the device-tree session also indicated that they had a need to store 
register level data in device-tree to accomplish something similar.

So the idea behind this series is to define a generic binding for 
storing register values in device-tree that could be used for 
potentially any device. The aim of this RFC is to see if there is any 
interest for pursuing this still and if so, what would be a good way to 
describe this data in device-tree. The proposed binding is one idea that 
we had come up but we are not tied to it.

> A concrete second user would go a long way to help. Anything "common"
> from one vendor ends up needing something different from the 2nd user.
> Somehow that 2nd user always shows up a month later... So the rule is
> generally I want to see 2 users. Yeah, it's hard to get others to pay
> attention, but that's not really my problem.

Yes completely makes sense and no problem there. If this does not get 
any traction and is not acceptable, then we could just make all the 
properties we need vendor specific and have various 'nvidia' properties 
for each controller. It is not ideal either, but that could work.

Jon

-- 
nvpublic