public inbox for devicetree@vger.kernel.org
 help / color / mirror / Atom feed
From: Sudeep Holla <sudeep.holla@arm.com>
To: Ben Horgan <ben.horgan@arm.com>
Cc: <linux-arm-kernel@lists.infradead.org>,
	<devicetree@vger.kernel.org>,
	Lorenzo Pieralisi <lpieralisi@kernel.org>,
	Sudeep Holla <sudeep.holla@arm.com>,
	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 16:51:55 +0100	[thread overview]
Message-ID: <20250508-manipulative-positive-fossa-27dff8@sudeepholla> (raw)
In-Reply-To: <9183535a-2866-4fa5-9ed4-96695f0437ee@arm.com>

Hi Ben,

Thanks for taking a look at this.

On Thu, May 08, 2025 at 02:25:19PM +0100, Ben Horgan wrote:
> 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?

Generally we only infer the CPU topology information from cpu-map.
We can reuse the cluster idle state node with CPUs on 2 different
clusters if they both has similar characteristics as each CPUs carry
this information independent of each other. On new DSU style clusters
with 3 different types of cpus within a single cluster, each type may
have different idle state characteristics and may need different nodes
for both cpu and cluster level idle states.

In short, the term cluster used here doesn't mean anything specific and
may not co-relate to the CPU topology.

-- 
Regards,
Sudeep

  reply	other threads:[~2025-05-08 15:52 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 ` [PATCH 1/3] arm64: dts: fvp: Add CPU idle states for Rev C model Ben Horgan
2025-05-08 15:51   ` Sudeep Holla [this message]
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=20250508-manipulative-positive-fossa-27dff8@sudeepholla \
    --to=sudeep.holla@arm.com \
    --cc=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 \
    /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