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
