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.
thanks,
Srini
Krzysztof, please correct me if I am wrong.
Kind regards
Uffe
