From: Krzysztof Kozlowski <krzk@kernel.org>
To: Mattijs Korpershoek <mkorpershoek@kernel.org>
Cc: Vinod Koul <vkoul@kernel.org>,
Neil Armstrong <neil.armstrong@linaro.org>,
Rob Herring <robh@kernel.org>,
Krzysztof Kozlowski <krzk+dt@kernel.org>,
Conor Dooley <conor+dt@kernel.org>,
Philipp Zabel <p.zabel@pengutronix.de>,
linux-arm-msm@vger.kernel.org, linux-phy@lists.infradead.org,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY
Date: Tue, 11 Aug 2026 08:18:13 +0200 [thread overview]
Message-ID: <162bfbf1-f8da-4083-96e9-2557688b0072@kernel.org> (raw)
In-Reply-To: <87a4qu2f98.fsf@kernel.org>
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?
>
> 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 :/)
>
> 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.
Best regards,
Krzysztof
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
next prev parent reply other threads:[~2026-08-11 6:18 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-30 13:58 [PATCH 0/2] Add support for SA8255P in the phy-qcom-snps-femto-v2 phy driver Mattijs Korpershoek
2026-07-30 13:58 ` [PATCH 1/2] dt-bindings: phy: Add sa8255p high-speed USB PHY Mattijs Korpershoek
2026-07-30 14:06 ` sashiko-bot
2026-07-30 14:13 ` Mattijs Korpershoek
2026-08-04 8:07 ` Krzysztof Kozlowski
2026-08-10 14:59 ` Mattijs Korpershoek
2026-08-11 6:18 ` Krzysztof Kozlowski [this message]
2026-08-11 10:33 ` Mattijs Korpershoek
2026-07-30 13:58 ` [PATCH 2/2] phy: qcom-snps-femto-v2: Add support for SA8255P Mattijs Korpershoek
2026-07-30 14:13 ` sashiko-bot
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=162bfbf1-f8da-4083-96e9-2557688b0072@kernel.org \
--to=krzk@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk+dt@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=mkorpershoek@kernel.org \
--cc=neil.armstrong@linaro.org \
--cc=p.zabel@pengutronix.de \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox