Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

On Tue, Aug 04, 2026 at 10:07, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On Thu, Jul 30, 2026 at 03:58:14PM +0200, Mattijs Korpershoek wrote:
>> SA8255p platform abstracts resources such as clocks, interconnect and
>> GPIO pins configuration in Firmware. SCMI power protocol is used to
>> request resource configurations.
>> 
>> Two power domains can be requested: transfer and core.
>> transfer controls clocks and interconnects and core controls
>> the GDSC, resets and TLMM (GPIOs).
>> 
>> Add a new binding for the Qualcomm SA8255p Synopsys Femto High-Speed
>> USB PHY V2 found in SA8255P.
>> 
>> Signed-off-by: Mattijs Korpershoek <mkorpershoek@kernel.org>
>> ---
>>  .../bindings/phy/qcom,sa8255p-usb-hs-phy.yaml      | 52 ++++++++++++++++++++++
>>  1 file changed, 52 insertions(+)
>> 
>> diff --git a/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> new file mode 100644
>> index 000000000000..09f7ca6e7f72
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/phy/qcom,sa8255p-usb-hs-phy.yaml
>> @@ -0,0 +1,52 @@
>> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/phy/qcom,sa8255p-usb-hs-phy.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Qualcomm SA8255p Synopsys Femto High-Speed USB PHY V2
>> +
>> +maintainers:
>> +  - Mattijs Korpershoek <mkorpershoek@kernel.org>
>> +
>> +properties:
>> +  compatible:
>> +    const: qcom,sa8255p-usb-hs-phy
>> +
>> +  reg:
>> +    maxItems: 1
>> +
>> +  "#phy-cells":
>> +    const: 0
>> +
>> +  power-domains:
>> +    maxItems: 2
>> +
>> +  power-domain-names:
>> +    items:
>> +      - const: transfer
>> +      - const: core
>
> Here and in your other binding you call these 'transfer' and 'core' but
> all other bindings call them 'power' and 'perf'. Why this difference?

Thanks for the question. I had to do some digging because I did not know
the answer to this.

Per my understanding, the SCMI firmware (in my case, gearvm) exposes
multiple protocols identified by a protocol_id.

For example, power domains have protocol_id=0x11 and and performance
domain have protocol_id=0x13. This is defined in ARM's den0056 spec:
https://support.arm.com/documentation/den0056/f/

Each USB phy has 2 distinct power domains.
This can be observed at runtime from linux via:

/sys/kernel/debug/pm_genpd # grep 'scmi-power-usb0.*phy.*' pm_genpd_summary
scmi-power-usb0-ss-phy-pm       off-0                           0
scmi-power-usb0-ss-phy-rpm      off-0                           0
scmi-power-usb0-hs-phy-pm       off-0                           0
scmi-power-usb0-hs-phy-rpm      off-0                           0

In the case of the other bindings - for example i2c - there is only one
power domain (0x11) and one perf domain (protocol_id 0x13):

/sys/kernel/debug/pm_genpd # grep i2c0 pm_genpd_summary
scmi-perf-i2c0_7                on                              0
scmi-power-i2c0                 off-0                           0

I hope that explains the naming difference. Please let me know if this
is still unclear.

> What are these domains responsible for?

If we take the example of the high-speed (hs) phy, we can see that on
the firmware side, the only difference is the -pm or -rpm suffix.
When Linux requests scmi-power-usb0-hs-phy-pm (mapped to 'core' in the
bindings), the SCMI firmware (gearvm) will interact with the reset line,
the clks and the regulator.
When requesting scmi-power-usb0-hs-phy-rpms (mapped to 'transfer' in the
bindings), the SCMI firmware will only interact with the USB clocks
(reset and regulators remain unchanged).

>
> Commit msg is pretty useless here - repeats the diff. I can read the
> diff but I still do not understand why such naming.

'core' controls reset, clocks and regulators.
'transfer' only controls clocks. Putting 'transfer' to 'off' is
interesting in case of runtime suspend/resume as it cuts the data
transfer (by disabling usb clock)

Is it more clear that way?

>
> And why core is not the first one? It clearly feels like the power
> domain thus the main one.

The order is based on how it's defined in the SCMI firmware. It's not a
problem to put 'core' first as power-domain-names property is only used
by the linux driver. Only the SCMI channel (in my case 12) and domain
indices (0,1) matter here.

>
> Best regards,
> Krzysztof