[RFC] feat(linux): s2idle: Document the mode selection logic#641
[RFC] feat(linux): s2idle: Document the mode selection logic#641DhruvaG2000 wants to merge 1 commit intoTexasInstruments:masterfrom
Conversation
Document the mode selection logic using the s2idle flow Signed-off-by: Dhruva Gole <d-gole@ti.com>
github-actions
bot
assigned
devarsht,
DhruvaG2000,
gehariprasath,
praneethbajjuri,
r-vignesh,
uditkumarti and
vishalmti
kwillis01
left a comment
kwillis01
left a comment
There was a problem hiding this comment.
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.
| Power Domain Hierarchy in Device Tree | ||
| ====================================== | ||
|
|
||
| The power domain hierarchy in the Device Tree defines how different system components are grouped |
There was a problem hiding this comment.
nit: s/Device Tree/device tree
| The Device Tree defines multiple idle states at each level of the hierarchy, each with different | ||
| power/latency trade-offs: | ||
|
|
||
| **CPU-Level Idle States:** |
There was a problem hiding this comment.
Not sure if the code blocks really say that much. Might be better to explain what each state does and then link to the code for people to look into if they want to.
| }; | ||
| }; | ||
|
|
||
| Understanding the Suspend Parameters |
There was a problem hiding this comment.
IMO everything in this section should somehow be combined with the "Understanding the Suspend Parameter" from above so it all flows together well. Having these in separate sections makes the info feel disjointed and that you might be repeating a lot of the same info. It can be placed here or earlier on, but preferably together.
| 3. Only idle states with ``exit-latency-us`` ≤ constraint are considered | ||
| 4. The deepest eligible state is selected | ||
|
|
||
| **Example: Deep Sleep Mode Selection:** |
There was a problem hiding this comment.
I think this should be moved after the explanation of "Selecting Specific Low-Power Modes" and "How It Sets QoS Constraints" so the example comes after the explanation.
| - **State Type = 1 (Power Down)**: Context is lost; firmware must restore state on resume | ||
| - **State ID = 0x2235**: Platform-specific identifier that the PSCI firmware (TF-A) recognizes | ||
| as "Deep Sleep" mode where DDR is in Self-Refresh and more peripherals in the Main domain | ||
| remain powered compared to RTC+DDR mode, providing faster resume at the cost of higher power |
There was a problem hiding this comment.
Comparison to RTC + DDR not needed because of the differences section below. Removing it makes this section a little simpler.
| 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. | ||
|
|
There was a problem hiding this comment.
Is the above point correct, since when we use rtcwake, even if the Display is connected, it does enter the selected LPM
| 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. | ||
|
|
There was a problem hiding this comment.
Similarly, the framework is obeying the latency constraint for mode selection but not the power domain mapping on forced s2idle
|
|
||
| 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 |
There was a problem hiding this comment.
the governor compares the constraint with exit-latency-us + entry-latency-us. This could cause confusion while setting the constraints
| domain idle states defined for s2idle suspend. | ||
|
|
||
| **Setting QoS Constraints from User Space:** | ||
|
|
There was a problem hiding this comment.
Now we could also provide using exec command that Kevin mentioned for setting the constraints
"exec 4<>/dev/cpu_wakeup_latency; echo 0x3e8 >&4"
| (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)**: |
There was a problem hiding this comment.
As mentioned above the constraint compares with exit+entry
|
|
||
| 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 |
There was a problem hiding this comment.
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
| #include <signal.h> | ||
|
|
||
| #define QOS_DEV "/dev/cpu_wakeup_latency" | ||
| #define LATENCY_VAL "0x1000" /* 4096 ns (4 μs) in hex */ |
There was a problem hiding this comment.
the latency value is in microseconds
|
|
||
| **Calculation:** | ||
|
|
||
| - Target latency: 520 μs = 520,000 ns (round to 520,001 for convenience) |
There was a problem hiding this comment.
The values here should be 520ms and 520000 us
9 participants
Document the mode selection logic using the s2idle flow