[RFC] feat(linux): s2idle: Document the mode selection logic by DhruvaG2000 · Pull Request #641 · TexasInstruments/processor-sdk-doc

DhruvaG2000 · 2026-03-18T10:29:31Z

Document the mode selection logic using the s2idle flow

kwillis01

It might be good to see if there are other places in the previous parts of the doc that can be updated or that the new info can loop into and consolidate.

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

ti-scaria · 2026-03-20T07:38:06Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+2. **Constraint Propagation**: When a device in the CLUSTER_PD is active (e.g., Display Subsystem),
+   the cluster cannot enter its deepest idle state. The constraint propagates up the hierarchy,
+   preventing both CLUSTER_PD and MAIN_PD from entering deeper states.
+


Is the above point correct, since when we use rtcwake, even if the Display is connected, it does enter the selected LPM

ti-scaria · 2026-03-20T07:42:14Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+3. **Automatic Mode Selection**: The cpuidle framework uses the hierarchy to automatically select
+   the deepest possible state. If any device in a power domain is active or has latency constraints,
+   shallower states are automatically chosen.
+


Similarly, the framework is obeying the latency constraint for mode selection but not the power domain mapping on forced s2idle

ti-scaria · 2026-03-20T09:26:18Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+
+1. Each device or CPU can register a latency constraint (in nanoseconds)
+2. The cpuidle governor queries these constraints before selecting an idle state
+3. Only idle states with ``exit-latency-us`` ≤ constraint are considered


the governor compares the constraint with exit-latency-us + entry-latency-us. This could cause confusion while setting the constraints

ti-scaria · 2026-03-20T09:29:03Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+domain idle states defined for s2idle suspend.
+
+**Setting QoS Constraints from User Space:**
+


Now we could also provide using exec command that Kevin mentioned for setting the constraints
"exec 4<>/dev/cpu_wakeup_latency; echo 0x3e8 >&4"

ti-scaria · 2026-03-20T09:37:49Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+(e.g., "0x7ef41").
+
+* **To force Deep Sleep mode**: Set constraint above Deep Sleep's exit latency (10ms = 10,000 μs)
+  but below RTC+DDR's exit latency (600ms = 600,000 μs). For example, use **520 μs (520,001 ns)**:


As mentioned above the constraint compares with exit+entry

ti-scaria · 2026-03-20T09:45:08Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+
+1. Registers a global CPU wakeup latency constraint
+2. Causes the cpuidle governor to filter out any idle states with exit latency exceeding this value
+3. Remains active as long as the file descriptor is open


These two points should be highlighted a bit more since the constraints are only valid till the file is open and this is how we enable mode selection

ti-scaria · 2026-03-20T09:57:10Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+   #include <signal.h>
+
+   #define QOS_DEV "/dev/cpu_wakeup_latency"
+   #define LATENCY_VAL "0x1000"  /* 4096 ns (4 μs) in hex */


the latency value is in microseconds

ti-scaria · 2026-03-20T10:01:26Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+
+  **Calculation:**
+
+  - Target latency: 520 μs = 520,000 ns (round to 520,001 for convenience)


The values here should be 520ms and 520000 us

Document the mode selection logic using the s2idle flow Signed-off-by: Dhruva Gole <d-gole@ti.com>

kwillis01

Mostly looks good, I think that the QoS Latency Constraints and Mode Selection section needs to be fixed up to flow better and be a little more condensed.

kwillis01 · 2026-04-01T16:52:26Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+This mapping ensures that when the Display (DSS0) is active, the system won't enter states that
+would cause DDR Auto Self-Refresh issues. Similarly, active UART or USB connections prevent
+deeper system states that would disconnect those interfaces.


It might be nicer to move this block up to the "Hierarchical Structure" heading since it shows this there. However, this is also fine here, just felt like it might be extra info the user might not necessarily need.

kwillis01 · 2026-04-01T16:56:59Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+
+.. note::
+   For complete Device Tree definitions including all latency parameters, refer to the platform's
+   device tree source files (e.g., ``k3-am62l-main.dtsi``).


For this release its in k3-am62l3-evm-idle-states.dtso

kwillis01 · 2026-04-01T19:12:32Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+
+**Setting QoS Constraints from User Space:**
+
+Applications can constrain the system's low-power behavior by writing to the PM QoS device file.


I think it should be specified that it is the PM QoS CPU wakeup latency file. Just because this sentence makes it sound like each device would have a PM QoS file, when its only for CPUs.

kwillis01 · 2026-04-01T19:17:10Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+3. Only idle states with ``exit-latency-us`` ≤ constraint are considered
+4. The deepest eligible state is selected
+
+**Setting QoS Constraints from User Space:**


I think this section should be combined with the Example: Deep Sleep Mode Selection section. You're showing an example of how to set the QoS constraint without properly explaining it. Also by combining with the Example: Deep Sleep Mode Selection section you can make this into an example for just deepsleep

kwillis01 · 2026-04-01T19:18:05Z

source/linux/Foundational_Components/Power_Management/pm_psci_s2idle.rst

+that the cpuidle governor correctly respects QoS constraints and selects the appropriate idle state
+based on latency requirements.
+
+**Selecting Specific Low-Power Modes:**


This section should go after the How It Sets QoS Constraints: section since that is when the /dev/cpu_wakeup_latency is explained

github-actions bot assigned devarsht, DhruvaG2000, gehariprasath, praneethbajjuri, r-vignesh, uditkumarti and vishalmti Mar 18, 2026

kwillis01 suggested changes Mar 18, 2026

View reviewed changes

ti-scaria reviewed Mar 20, 2026

View reviewed changes

feat(linux): s2idle: Document the mode selection logic

6209735

Document the mode selection logic using the s2idle flow Signed-off-by: Dhruva Gole <d-gole@ti.com>

DhruvaG2000 force-pushed the s2idle_mode_sel_v1 branch from 995b85e to 6209735 Compare March 31, 2026 17:26

github-actions bot requested review from devarsht, gehariprasath, praneethbajjuri, r-vignesh, uditkumarti and vishalmti March 31, 2026 17:27

kwillis01 suggested changes Apr 1, 2026

View reviewed changes

		domain idle states defined for s2idle suspend.

		Setting QoS Constraints from User Space:


		Calculation:

		- Target latency: 520 μs = 520,000 ns (round to 520,001 for convenience)


		Setting QoS Constraints from User Space:

		Applications can constrain the system's low-power behavior by writing to the PM QoS device file.

Conversation

DhruvaG2000 commented Mar 18, 2026

Uh oh!

kwillis01 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ti-scaria Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ti-scaria Mar 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kwillis01 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

ti-scaria Mar 20, 2026 •

edited

Loading

ti-scaria Mar 20, 2026 •

edited

Loading