Re: DT Query on "New Compatible vs New Property"

[Sudeep Holla <sudeep.holla@arm.com>]

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