[PATCH 1/3] arm64: dts: fvp: Add CPU idle states for Rev C model

[Sudeep Holla]

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 at 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