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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20250128115232.kte35toxn3puoqwk@bogus>
Date: Tue, 28 Jan 2025 11:52:32 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Dhruva Gole <d-gole@...com>
Cc: Vivek yadav <linux.ninja23@...il.com>, linux-newbie@...r.kernel.org,
	Sudeep Holla <sudeep.holla@....com>, linux-pm@...r.kernel.org,
	daniel.lezcano@...aro.org, lpieralisi@...nel.org, krzk@...nel.org,
	christian.loehle@....com, quic_sibis@...cinc.com,
	cristian.marussi@....com, linux-arm-kernel@...ts.infradead.org,
	linux-kernel@...r.kernel.org, vigneshr@...com, khilman@...com,
	sebin.francis@...com, khilman@...libre.com
Subject: Re: Fwd: ARM64: CPUIdle driver is not select any Idle state other
 then WFI

On Tue, Jan 28, 2025 at 04:44:07PM +0530, Dhruva Gole wrote:
> 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.
>

Cool.

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

Excellent! I just wanted to be sure that we are not just playing with these in
the DT without realising what that means to the PSCI implementation.

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

Looks like we are in sync with our understanding now, that's progress.

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

Yes, that would be interesting.

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

No worries, just wanted to make sure those queries didn't slip through the
cracks.

--
Regards,
Sudeep