Re: Fwd: ARM64: CPUIdle driver is not select any Idle state other then WFI

[Dhruva Gole <d-gole@ti.com>]

Hi Sudeep and Vivek,

On Jan 28, 2025 at 09:47:20 +0000, Sudeep Holla wrote:
> On Mon, Jan 27, 2025 at 10:47:28PM +0530, Vivek yadav wrote:
> > Hi @Dhruva Gole,
> > 
> > Q.1. Does your CA-53 properly go into CPUIdle state and come out of
> > sleep state ?
> 
> Yes, well tested on other SoCs. Seems like system integration issue.

Yes, with the local-timer-stop property removed, all A53 cores do enter
idle in TF-A at the same time.

> > As of now I made some changes in the DT node. After making changes in
> > latency (which is mentioned below).
> > 
> >  idle-states {
> >        entry-method = "psci";
> >         cpu_ret_l: cpu-retention-l {
> >           compatible = "arm,idle-state";
> >           arm,psci-suspend-param = <0x00000000>;
> >           local-timer-stop;
> >           entry-latency-us = <300000>; # 300ms
> >            exit-latency-us = <300000>; # 300ms
> >            min-residency-us = <1000000>; # 1 sec
> >      };
> >  };
> >
> 
> Does these align with expectation of PSCI implementation in the firmware ?

Just to add here, value of that parameter has some encoded
meaning and is given in the PSCI standard:
Table 7 power_state parameter bit fields in Original format
https://developer.arm.com/documentation/den0022/fb/?lang=en

> 
> 
> > I can see that  CA-55 went into a sleep state (state1) using command
> > ``cat /sys/devices/system/cpu/cpu*/cpuidle/state*/time``.
> > As you mention earlier in a multicore system (2 or more) at least one
> > core keeps working and does not go into sleep state. It should happen
> > as per theory and other developers' case.
> > 
> > In my case, after some time, both CPUs (CPU0 and CPU1) go into sleep
> > state (state1). Hence the system console hangs.
> > 
> > My expectations are,
> > If I type anything on keyboard. UART interrupt should take out CPUs
> > from sleep state and execute commands. OR some periodic timer should
> > take the CPU out of sleep. Which is not happening as of now.
> > As you said  we can safely remove`` local-timer-stop``. It means local
> > timers are working for the CPUs and triggering interrupts ?
> > 
> 
> Please go the thread and understand when and why you need local-timer-stop and
> how it is related to the arm,psci-suspend-param value(especially the state
> context loss bit)

Yes this is the important bit, if you know that on your platform the
A53s are just not going to power off or stop timers upon entering idle
then you must remove the local-timer-stop property from your DT
cpu_ret_l.
However, if you do have a scenario where the timer would be getting
stopped or modified in idle scenario, then linux needs to be able to use
another timer that is routed to the GIC and is unaffected while the
system is in idle.

This is what my understanding is so far, I am yet to do experiments with
local-timer-stop + different timer in the case of idle.

> 
> I have not got response to my questions. You can just play with DT and get
> things working here if the firmware expectation, hardware functionality
> and DT properties don't align.

I have responded to the thread now, sorry for not getting back earlier!

-- 
Best regards,
Dhruva Gole
Texas Instruments Incorporated