On Tue, Mar 19, 2024 at 02:40:32PM +0000, Srinivas Kandagatla wrote: > > On 19/03/2024 12:00, Sudeep Holla wrote: > > > > OTH, my argument so far is that the presence of SCMI node indicates some > > or more SCMI features are available on this platform. The SCMI node itself > > then will have the resource provider nodes(like clock, power, perf, reset, > > regulator,...etc). If the individual device nodes are consumers of those > > resources, they will be pointing to those instead of non-SCMI clock, reset, > > ...etc resource providers. So ideally we don't need anything more in the > > DT. > > The situation that you described is perfect case of SCMI. > > With SCMI perf device support case, combination of these clks, regulators > and reset are moved under the perf domain. Its no more the same type of > resource provider. So the DT bindings will change drastically. > Not sure what you refer as "drastic". Ulf added binding to represent both power and performance domains extending the current binding used for power domains and used by genpd framework. The whole idea with abstraction i.e. clks, regulators, reset all moved into the firmware under one perf domains means you need less information in the device tree. So this whole discussion about adding more info to deal with it sounds moot to me and hence all my arguments. I am not debating on the implementation just to be clear. I accept changes might be needed there. The $subject is all about DT bindings and what need to be changes and for me nothing, just use existing bindings and if there are issues there, let us discuss it with specifics. > so the existing driver that was expecting clk/regulators/resets now has to > deal with perf domain. > Agreed. -- Regards, Sudeep
