On 3/14/2024 3:55 AM, Sudeep Holla wrote:
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.
For SMMU, we dont need to make any changes in the existing driver.
Simple power-domain over SCMI will suffice since we don't need to do
clock scaling etc. for SMMU. We will use this new property in Qualcomm
emac, UFS, USB, QUPs(i2c,spi,uart) drivers.
Hope I have conveyed my point better with example this time.
--
Regards,
Sudeep
