Devicetree
 help / color / mirror / Atom feed
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

  reply	other threads:[~2026-08-11  6:18 UTC|newest]

Thread overview: 9+ 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-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