Skip to content

[RFC] feat(linux): s2idle: Document the mode selection logic#641

Draft
DhruvaG2000 wants to merge 1 commit intoTexasInstruments:masterfrom
DhruvaG2000:s2idle_mode_sel_v1
Draft

[RFC] feat(linux): s2idle: Document the mode selection logic#641
DhruvaG2000 wants to merge 1 commit intoTexasInstruments:masterfrom
DhruvaG2000:s2idle_mode_sel_v1

Conversation

@DhruvaG2000
Copy link
Collaborator

Document the mode selection logic using the s2idle flow

Document the mode selection logic using the s2idle flow

Signed-off-by: Dhruva Gole <d-gole@ti.com>
Copy link
Contributor

@kwillis01 kwillis01 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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:**
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Comparison to RTC + DDR not needed because of the differences section below. Removing it makes this section a little simpler.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

8 participants