+Trilok
On 3/4/2024 3:01 AM, Sudeep Holla wrote:
On Fri, Mar 01, 2024 at 12:53:25PM +0100, Ulf Hansson wrote:
On Wed, 28 Feb 2024 at 18:11, Srinivas Kandagatla
<srinivas.kandagatla@xxxxxxxxxx> wrote:
On 28/02/2024 16:22, Ulf Hansson wrote:
On Wed, 28 Feb 2024 at 17:09, Sudeep Holla <sudeep.holla@xxxxxxx> wrote:
On Wed, Feb 28, 2024 at 03:20:44PM +0100, Krzysztof Kozlowski wrote:
On 28/02/2024 15:02, Sudeep Holla wrote:
On Wed, Feb 28, 2024 at 02:27:30PM +0100, Ulf Hansson wrote:
On Mon, 26 Feb 2024 at 15:24, Nikunj Kela <quic_nkela@xxxxxxxxxxx> wrote:
Hi Sudeep,
I would like to conclude on this thread. I was discussing this with Ulf.
He thinks that using the domain names to identify if platform is
abstracting clocks etc. are not scalable and sufficient. Instead he
thinks that the change in the interface to OS(and FW) is a good
candidate for a new compatible(even though HW is same). Even for SCMI,
we do change phandle in DT to SCMI protocol phandle so that is like a
different platform altogether. Could you please let me know if you still
think that using a different compatible in this case is not warranted.
My apologies for joining this discussion at this late state. Yet, I
just wanted to confirm what Nikunj said above.
In the end we are indeed talking about adding a new platform, as
changing the FW interface from a QCOM proprietary one into SCMI,
simply requires updates to a DTS file(s) that is platform specific.
The way I read this sounds like all this are platform specific and need
new compatible.
That said, it also seems reasonable to me to use a compatible string,
to allow us to describe the update of HW for various affected devices.
While I agree with the above statement, it depends on what you refer as
update of HW above. It is all Qcom specific and there is so much turn
between SoCs that this shouldn't matter but I would like to take example
and describe what I initially mentioned/argued against.
Lets us assume 2 SoCs: A and B. A is old and didn't use SCMI while B is
new and migrated to use SCMI. Now let us assume both A and B SoCs have
exact same version/revision of an IP: X. Now just because B uses SCMI,
should X have one compatible to be used in A and another in B. That
doesn't sound right IMO.
That's trivial to answer, because these are different SoCs. Compatibles
are SoC specific and every SoC-IP-block needs its compatible. Rob was
repeating this many times that versioned compatibles are discouraged.
OK I may have confused or derailed the discussion with the mention of
"exact same version/revision" of X. This is not related versioned compatibles.
Let me try to explain it with some real example. If you look at all the
users of "arm,coresight-tpiu", they all have same compatible on all the
platforms irrespective of the clock/reset/voltage/power domain providers
on these platforms.
E.g. on juno it is based on SCMI while on qcom-msm8974/apq8064 or
hi3660/hi6220 it is platform specific clock/power domain providers.
However all these platform have the same compatible "arm,coresight-tpiu".
That was the point I was trying to make and not related to versioned
compatible for different versions on an IP.
That's perfectly fine, if that is sufficient. It would also be
perfectly fine to extend it with a platform/soc specific compatible,
when needed.
An example could be:
compatible = "qcom,sm8450-coresight-tpiu", "arm,coresight-tpiu";
The issue is not the same as the above example.
We already have a soc specific compatible in this case
ex: "qcom,sc8280xp-ufshc"
making another compatible like "qcom,sc8280xp-ufshc-scmi" or
"qcom,sc8280xp-ufshc-xyz" based on how some of the resources (clks,
regulators) are provided in bindings does not really make sense.
Fact is that we are representing the same IP block.
AFAIU, we should go with same compatible irrespective of how the
resourcing needs are satisfied.
I get your point. Nevertheless, we need to create a new platform (new
DTS file), as we are changing the FW interface to SCMI. That means the
toplevel compatible for the platform will be a new one
(Documentation/devicetree/bindings/arm/qcom.yaml).
While I don't understand the details of the above mentioned platform,
it should be a blanket rule that the toplevel compatible for the platform
has to be new.
Check
arch/arm64/boot/dts/arm/juno.dts
arch/arm64/boot/dts/arm/juno-scmi.dtsi
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.
--
Regards,
Sudeep
Hi All,
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.
Thank you!
