[PATCH v2] dt-bindings: phy: qcom,usb-snps-femto-v2: Add bindings for QCS9100

[Aiqun Yu (Maria)]

On 7/12/2024 4:03 AM, Rob Herring wrote:
> On Thu, Jul 11, 2024 at 06:05:57PM +0800, Aiqun Yu (Maria) wrote:
>>
>>
>> On 7/11/2024 12:45 AM, Trilok Soni wrote:
>>> On 7/10/2024 9:27 AM, Rob Herring wrote:
>>>> On Tue, Jul 09, 2024 at 08:46:19PM +0800, Tengfei Fan wrote:
>>>>> Document the compatible string for USB phy found in Qualcomm QCS9100
>>>>> SoC.
>>>>> QCS9100 is drived from SA8775p. Currently, both the QCS9100 and SA8775p
>>>>> platform use non-SCMI resource. In the future, the SA8775p platform will
>>>>> move to use SCMI resources and it will have new sa8775p-related device
>>>>> tree. Consequently, introduce "qcom,qcs9100-usb-hs-phy" to describe
>>>>> non-SCMI based USB phy.
>>>>>
>>>>> Signed-off-by: Tengfei Fan <quic_tengfan at quicinc.com>
>>>>> ---
>>>>> Introduce support for the QCS9100 SoC device tree (DTSI) and the
>>>>> QCS9100 RIDE board DTS. The QCS9100 is a variant of the SA8775p.
>>>>> While the QCS9100 platform is still in the early design stage, the
>>>>> QCS9100 RIDE board is identical to the SA8775p RIDE board, except it
>>>>> mounts the QCS9100 SoC instead of the SA8775p SoC.
>>>>>
>>>>> The QCS9100 SoC DTSI is directly renamed from the SA8775p SoC DTSI, and
>>>>> all the compatible strings will be updated from "SA8775p" to "QCS9100".
>>>>> The QCS9100 device tree patches will be pushed after all the device tree
>>>>> bindings and device driver patches are reviewed.
>>>>
>>>> I'm not convinced this is not just pointless churn. Aren't we going to 
>>>> end up with 2 compatible strings for everything? SCMI should just change 
>>>> the providers, but otherwise the consumers are the same. I suppose if 
>>>> clocks are abstracted into power-domains (an abuse IMO) then the 
>>>> bindings change.
>>>>
>>>> Why do we need to support both SCMI and not-SCMI for the same chip?
>>>
>>> IOT SKU of this SOC is using the non-SCMI solution and Auto SKU
>>> of this SOC is using the SCMI based solution due to additional
>>> safety requirements. 
>>
>> More add-on information, IOT SKU which have qcs9100 soc mounted will
>> have firmware releases which support non-scmi solution.
>> And AUTO SKU which mounted with SA8775p will have different firmware
>> releases which support SCMI solution.
> 
> Yes, I understand the difference. My question is why should upstream 
> support that? Normally, I wouldn't notice or care, but the churn of 
> renaming everything makes me notice. Why do the maintainers need to 
> review all these extra changes because QCom couldn't figure out their 
> plans?

Upstreaming prematurely, prior to finalizing all solutions, will have a
significant pain point like this. I recognize the extra workload
involved in reviewing these changes, but our aim is to minimize future
maintenance efforts. SA8775p with non-SCMI resource solutions is going
to be deprecated.

The SA8775p is currently undergoing active development, with Qualcomm
firmware updates altering essential resources such as clocks,
regulators, etc. designs, to align with safety requirements.
> 
> So after you duplicate all the compatible strings, what's next? Changing 
> all the SA8775p bindings which is an ABI break? Presumably, some 

Yes, ABI is going to break/evolve as sa8775p moves to scmi based
infrastructure. Auto product line intends to subsequently submit
corresponding changes for sa8775p while derived part qcs9100 support,
continue evolve in conventional manner.
> bindings may not change at all? In that case, you don't need any rename.> I have no visibility into what's coming next, so please educate me.


For instance, in this binding, ‘clk’, ‘resets’, and other elements are
mandatory if ‘compatible’ includes qcs9100. However, after the SCMI
resource solution is checked in, for ‘compatible’ containing sa8775p, it
may only require ‘power-domains’ and ‘power-domain-names’.”

A reference to one SCMI resource solution RFC, which will definitely
require some changes, can be found here[1]:
[1]
https://lore.kernel.org/lkml/1709657858-8563-4-git-send-email-quic_sriramd@quicinc.com/

The proposed solution(with compatible differentiation) will exhibit the
following differences in addition to the current RFC.[1] :

1. Both have SCMI and non-SCMI support in the same driver.
The binding documentation will specify that ‘qcs9100’ compatibility
requires properties such as ‘clk’, ‘reset’, ‘vdd’, etc., while ‘SA8775p’
compatibility necessitates properties like ‘power-domains’,
‘power-domain-names’, etc., as mandatory.

2. having a /delete-property/ becomes unnecessary.
The proposed solution will introduce a completely new SA8775p.dtsi from
the outset. The current qcs9100.dtsi will not be included into this new
SA8775p.dtsi.

3. Driver C files will not eliminate calls to ‘clk’, ‘vreg’, etc.
Instead, they will differentiate with a ‘qcs9100’ compatibility to
include operation with legacy "clk", "vreg" calls, while ‘sa8775p’ will
incorporate operations calls for ‘power-domains’, and so on.

4. "hsphy,fw-managed" property to indicate SCMI resources is not necessary.
Current patch have been using a DT property " hsphy,fw-managed;" to
figure if it is SCMI based vs non-scmi. While it is going to be
suggested to be designed to use "sa8775p" compatible.

Further more:
LinaroConnect presentation on qcom SCMI approach here[2]:
[2]https://resources.linaro.org/en/resource/wfnfEwBhRjLV1PEAJoDDte

> 
> The minimal amount of changes here is you are stuck with the existing 
> identifiers for the non-SCMI SKU. Then you can add a "new SoC" for the 
> SCMI SKU. You might not like the names now, but you picked them and are 
> kind of stuck with them.

SA8775P is already announced Auto SOC for our OEMs. We can't ask for
creating new Auto SKU to show the solution w/ SCMI like "SA8775P<XYZ>".

Since the current code of SA8775P is matching w/ what is required for
the purpose of QCS9100 s/w architecture the clear rename was proposed.
It will also look odd to IOT customers to see their SOC DT file starting
w/ the SA8775P.

For the current Qualcomm device trees in upstream, we still use ‘soc’
naming in the base soc device tree, which is consistent with our current
hardware SOC naming convention. The basic <soc_name>.dtsi is, by
default, aligned with the current market name of the SOC.

Welcome comments and suggestions on the information we have proposed above.
> 
> Rob

-- 
Thx and BRs,
Aiqun(Maria) Yu