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

[Mattijs Korpershoek <mkorpershoek@kernel.org>]

On Tue, Aug 11, 2026 at 08:18, Krzysztof Kozlowski <krzk@kernel.org> wrote:

> On 10/08/2026 16:59, Mattijs Korpershoek wrote:
>>>> +  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
>
> What about perf domains?

The perf domains for USB are also exposed by the SCMI firmware and are
also registered with genpd:

/sys/kernel/debug/pm_genpd # grep usb0 pm_genpd_summary
scmi-perf-usb0-ss-phy_86        on                              0
scmi-perf-usb0-hs-phy_85        on                              0
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
scmi-perf-usb0_0                on                              0
scmi-power-usb0-pm              off-0                           0
scmi-power-usb0-rpm             off-0                           0

They are marked as "on" here GENPD_FLAG_ALWAYS_ON is set in
scmi_perf_domain.c

If we query the SCMI firmware using raw commands, we can get some more
information about the perf domain:

# Get the OPP table for domain 0:
/sys/kernel/debug/scmi/12 # printf '\x04\x4c\x18\x00\x00\x00\x00\x00\x00\x00\x00\x00' > /sys/kernel/debug/scmi/12/raw/message
/sys/kernel/debug/scmi/12 # xxd /sys/kernel/debug/scmi/12/raw/message
00000000: 044c 1800 0000 0000 0800 0000 0a00 0000  .L..............
00000010: 0000 0000 0000 0000 0b00 0000 0000 0000  ................
00000020: 0000 0000 0c00 0000 0000 0000 0000 0000  ................
00000030: 0d00 0000 0000 0000 0000 0000 0e00 0000  ................
00000040: 0000 0000 0000 0000 0f00 0000 0000 0000  ................
00000050: 0000 0000 1000 0000 0000 0000 0000 0000  ................
00000060: 1100 0000 0000 0000 0000 0000            ............

This gives us 8 opps, from 0x0a to 0x11, which look like opaque values.

I did not need to initialize the perf domains (in the driver) in order
to get USB working on my Ride4 (SA8775P) board.
Since the SCMI firmware exposes the perf domains, should I describe them
in the bindings, as optional?

>
>
>> 
>> 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)
>
> Either the binding or the commit msg should be clear that these are
> power domains responsible only for power on SA platform, not for perf
> (so a power power domain... ehh :/)

Yeah, the terminology is a bit confusing. In the SCMI spec, we have: *
"Power domain management protocol" for protocol_id=0x11 * "Performance
domain management protocol" for protocol_id=0x13

Since linux models both via genpd (drivers/pmdomain) we end up with a
"power power domain" and a "perf power domain".

I will rephrase the commit msg in the next version.

>
>> 
>> 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
>
>
> Then core goes before transfer.

Ok, will change in v2 and update the other series as well.

Thanks again for the reviews.

>
>
> Best regards,
> Krzysztof

-- 
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy