From: Ben Horgan <ben.horgan@arm.com>
To: Sudeep Holla <sudeep.holla@arm.com>,
linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org
Cc: Lorenzo Pieralisi <lpieralisi@kernel.org>,
Liviu Dudau <liviu.dudau@arm.com>, Leo Yan <leo.yan@arm.com>
Subject: Re: [PATCH 1/3] arm64: dts: fvp: Add CPU idle states for Rev C model
Date: Thu, 8 May 2025 14:25:19 +0100 [thread overview]
Message-ID: <9183535a-2866-4fa5-9ed4-96695f0437ee@arm.com> (raw)
In-Reply-To: <20250508103225.354925-1-sudeep.holla@arm.com>
Hi,
On 5/8/25 11:32, Sudeep Holla wrote:
> Add CPU idle state definitions to the FVP Rev C device tree to enable
> support for CPU lower power modes. This allows the system to properly
> enter low power states during idle. It is disabled by default as it is
> know to impact performance on the models.
>
> Note that the power_state parameter(arm,psci-suspend-param) doesn't use
> the Extended StateID format for compatibility reasons on FVP.
>
> Tested on the FVP Rev C model with PSCI support enabled firmware.
>
> Signed-off-by: Sudeep Holla <sudeep.holla@arm.com>
> ---
> arch/arm64/boot/dts/arm/fvp-base-revc.dts | 32 +++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/arm/fvp-base-revc.dts b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> index 9e10d7a6b5a2..ff4e6f4d8797 100644
> --- a/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> +++ b/arch/arm64/boot/dts/arm/fvp-base-revc.dts
> @@ -44,6 +44,30 @@ cpus {
> #address-cells = <2>;
> #size-cells = <0>;
>
> + idle-states {
> + entry-method = "arm,psci";
> +
> + CPU_SLEEP_0: cpu-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x0010000>;
> + entry-latency-us = <40>;
> + exit-latency-us = <100>;
> + min-residency-us = <150>;
> + status = "disabled";
> + };
> +
> + CLUSTER_SLEEP_0: cluster-sleep-0 {
> + compatible = "arm,idle-state";
> + local-timer-stop;
> + arm,psci-suspend-param = <0x1010000>;
> + entry-latency-us = <500>;
> + exit-latency-us = <1000>;
> + min-residency-us = <2500>;
> + status = "disabled";
> + };
> + };
Do we need a cpu-map so we know which cpus the cluster idle affects?
> +
> cpu0: cpu@0 {
> device_type = "cpu";
> compatible = "arm,armv8";
> @@ -56,6 +80,7 @@ cpu0: cpu@0 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C0_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu1: cpu@100 {
> device_type = "cpu";
> @@ -69,6 +94,7 @@ cpu1: cpu@100 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C0_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu2: cpu@200 {
> device_type = "cpu";
> @@ -82,6 +108,7 @@ cpu2: cpu@200 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C0_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu3: cpu@300 {
> device_type = "cpu";
> @@ -95,6 +122,7 @@ cpu3: cpu@300 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C0_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu4: cpu@10000 {
> device_type = "cpu";
> @@ -108,6 +136,7 @@ cpu4: cpu@10000 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C1_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu5: cpu@10100 {
> device_type = "cpu";
> @@ -121,6 +150,7 @@ cpu5: cpu@10100 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C1_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu6: cpu@10200 {
> device_type = "cpu";
> @@ -134,6 +164,7 @@ cpu6: cpu@10200 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C1_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> cpu7: cpu@10300 {
> device_type = "cpu";
> @@ -147,6 +178,7 @@ cpu7: cpu@10300 {
> d-cache-line-size = <64>;
> d-cache-sets = <256>;
> next-level-cache = <&C1_L2>;
> + cpu-idle-states = <&CPU_SLEEP_0 &CLUSTER_SLEEP_0>;
> };
> C0_L2: l2-cache0 {
> compatible = "cache";
--
Thanks,
Ben
next prev parent reply other threads:[~2025-05-08 13:25 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 10:32 [PATCH 1/3] arm64: dts: fvp: Add CPU idle states for Rev C model Sudeep Holla
2025-05-08 10:32 ` [PATCH 2/3] arm64: dts: fvp: Add system timer for broadcast during CPU idle Sudeep Holla
2025-05-08 10:32 ` [PATCH 3/3] arm64: dts: fvp: Reserve 64MB for the FF-A firmware in memory map Sudeep Holla
2025-05-08 13:25 ` Ben Horgan [this message]
2025-05-08 15:51 ` [PATCH 1/3] arm64: dts: fvp: Add CPU idle states for Rev C model Sudeep Holla
2025-05-08 16:09 ` Leo Yan
2025-05-08 16:13 ` Sudeep Holla
2025-05-09 14:16 ` Rob Herring (Arm)
2025-05-09 15:29 ` Sudeep Holla
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=9183535a-2866-4fa5-9ed4-96695f0437ee@arm.com \
--to=ben.horgan@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=leo.yan@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=liviu.dudau@arm.com \
--cc=lpieralisi@kernel.org \
--cc=sudeep.holla@arm.com \
/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