On Wed, Mar 13, 2024 at 01:04:15PM +0000, Srinivas Kandagatla wrote: > > > On 13/03/2024 11:04, Sudeep Holla wrote: > > On Tue, Mar 12, 2024 at 09:52:56AM -0700, Nikunj Kela wrote: > > > +Trilok > > > > > > On 3/4/2024 3:01 AM, Sudeep Holla wrote: > > > > arch/arm64/boot/dts/arm/juno-scmi.dts > > > > > > > > One is with old firmware interface and -scmi is with SCMI. No new top > > > > level compatible change is needed. I understand it was switch from one > > > > interface to the another and not like Qcom platforms which is moving > > > > from in-kernel solution to firmware solution. But the general rule applies > > > > here as well unless there are specific reasons for needing that exception. > > > > I am not against it or ruling that out, just curious to understand them. > > > > > > Thank you all for all your inputs on this. I discussed this with Srini and > > > he suggested that we could use a new optional DT property like "qcom, > > > fw-managed" to ascertain if we are running on firmware managed variant. Thus > > > each device node in the dts can add this. I did ask him if, instead of > > > putting it to each device node, we can use it at the board level however he > > > thinks that it would not be easy to update yaml documentation on DT nodes > > > with board level property. So if everyone here agrees with this approach, I > > > would like to close this thread. > > > > The counter argument from me for that is simple. If you are OK to manage with > > one board level compatible/property(doesn't matter for this discussion), then > > why can't that be the compatible of the firmware itself(SCMI and RPMI both > > must have their own compatible already). The main point is why do you need > > any extra information when they are already present. My comment is just for > > this one board level compatible/property. > > Board specific compatible might not scale, as this will bring in changes to > every driver and bindings with new board addition. > > BoardLevel property, how are we going to reflect this each device DT > bindings? > > Is this new property going to be part of scmi/rpmi firmware node? > Nope, the point was will the presence of (available) scmi/rpmi device node suffice if we are thinking of single board level property or compatible. I was not mixing the discussion of whether adding such a property to each needed device node in this discussion to keep it simple. I have already expressed my opinion on that. I am sure qcom will go and do what they want which may work fine for qcom specific drivers but it will not work for a generic IP driver used by many vendors. Not sure if Qcom SoCs are just bundle of Qcom specific IPs or they do have some generic non-Qcom IPs. Lets us take SMMU as example. If the SCMI/RPMI controls the power to it, would you go and add this new compatible in the generic SMMU bindings and add support in the driver for that ? That is big NO as the driver would just need to use std framework interface(doesn't matter Runtime PM/Clock/ Reset/genpd/PM OPP). That means they don't need any specific bindings to inform SMMU driver that the power is f/w managed. Hope I have conveyed my point better with example this time. -- Regards, Sudeep
