[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250128094720.sgk7gyr5oawzxbez@bogus>
Date: Tue, 28 Jan 2025 09:47:20 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Vivek yadav <linux.ninja23@...il.com>
Cc: Dhruva Gole <d-gole@...com>, linux-newbie@...r.kernel.org,
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,
Sudeep Holla <sudeep.holla@....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 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.
> 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 ?
> 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)
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.
--
Regards,
Sudeep
Powered by blists - more mailing lists