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

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

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@quicinc.com> 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.


-- 
Regards,
Sudeep