From: Kevin Hilman <khilman@baylibre.com>
To: "cristian.marussi@arm.com" <cristian.marussi@arm.com>,
"souvik.chakravarty@arm.com" <souvik.chakravarty@arm.com>,
Sudeep Holla <sudeep.holla@arm.com>,
Ulf Hansson <ulf.hansson@linaro.org>
Cc: "arm-scmi@vger.kernel.org" <arm-scmi@vger.kernel.org>,
Dhruva Gole <d-gole@ti.com>, Sebin Francis <sebin.francis@ti.com>
Subject: mixing SCMI and PSCI power domain hierarchy
Date: Mon, 07 Apr 2025 16:31:41 -0700 [thread overview]
Message-ID: <7hecy3h7ky.fsf@baylibre.com> (raw)
Hello SCMI folks,
I'm trying to figure out how to model a power-domain hierarchy when
there is a mixture of SCMI and PSCI domains.
Let's say I have a top-level PD, managed by PSCI, but inside it it has
both a CPU cluster (with cluster & CPU PDs controlled by PSCI) as well
as some other sub-domains for leaf devices that are controlled by SCMI.
A simplified version looks something like this:
SOC
|
|- TOP1_PD (PSCI)
|
|-- LEAF1_PD (SCMI)
|-- LEAF2_PD (SCMI)
|
\-- CLUSTER_PD (PSCI)
|
|-- CPU1_PD (PSCI)
\-- CPU2_PD (PSCI)
So the main question is: how do I describe the SCMI part of this today
in DT? Currently, I have something like this for the SCMI-controlled
PDs:
scmi_pds: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
bootph-all;
};
and the leaf devices under LEAF1_PD and LEAF2_PD would have
`power-domains = <&scmi_pds N>` properties, indicating their PD is
managed by SCMI. That part works fine. And I'm also able to model the
CPU PDs and CLUSTER_PD just fine, including using
domain-idle-states... (Hi Ulf ;)
But... how do I describe the relationship of this hierarchy? In
particular, when the SCMI-controlled PDs are actually subdomains of a
top-level, non-SCMI PD. I tried adding `power-domains = <&TOP1_PD>`
inside the scmi_pds node, but that property seems to be ignored. So it
seems that currently it has not been considered to have SCMI PDs as
sub-domains of other PDs. Is that correct? Is this something anyone
else has considered adding?
The hierarchy I describe above is not made up, it's for the TI AM62L
SoC, which is in the process of being upstreamed[1], and we're trying to
figure out the proper way to describe the power domain hierarchy of this
SoC in a way that can support the multiple low-power idle states that
the SoC family plans to support.
All suggestions, redirections, corrections welcome!
Thanks,
Kevin
[1]
https://lore.kernel.org/r/20250109-am62lx-v3-0-ef171e789527@ti.com
next reply other threads:[~2025-04-07 23:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-07 23:31 Kevin Hilman [this message]
2025-04-10 13:07 ` mixing SCMI and PSCI power domain hierarchy Ulf Hansson
2025-04-16 0:22 ` Kevin Hilman
2025-04-16 13:22 ` Ulf Hansson
2025-04-16 16:34 ` Kevin Hilman
2025-04-16 19:28 ` Kevin Hilman
2025-04-25 10:48 ` Ulf Hansson
2025-04-16 23:57 ` Kevin Hilman
2025-04-25 11:08 ` Ulf Hansson
2025-04-25 14:39 ` Kevin Hilman
2025-05-16 12:36 ` Ulf Hansson
2025-05-28 20:09 ` Kevin Hilman
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=7hecy3h7ky.fsf@baylibre.com \
--to=khilman@baylibre.com \
--cc=arm-scmi@vger.kernel.org \
--cc=cristian.marussi@arm.com \
--cc=d-gole@ti.com \
--cc=sebin.francis@ti.com \
--cc=souvik.chakravarty@arm.com \
--cc=sudeep.holla@arm.com \
--cc=ulf.hansson@linaro.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