Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[nrf fromlist] soc: nordic: nrf54h20: Add LRC around idle #2032

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

adamkondraciuk
Copy link
Contributor

Add LRC domain power management around idle. The Fast Clock Domain needs to be forced-on during CPU idle. Also the force needs to be disabled on idle-exit.

soc/nordic/nrf54h/soc.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/Kconfig.soc Outdated Show resolved Hide resolved
Copy link
Contributor

@hubertmis hubertmis left a comment

Choose a reason for hiding this comment

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

The resource usage conflict with clock_control seems to be still in place. Have a look at these functions:
https://github.com/nrfconnect/sdk-zephyr/blob/main/drivers/clock_control/clock_control_nrf2_common.c#L169-L198

soc/nordic/common/soc_lrcconf.h Show resolved Hide resolved
soc/nordic/common/soc_lrcconf.h Outdated Show resolved Hide resolved
soc/nordic/nrf54h/power.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/power.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/soc.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/Kconfig Outdated Show resolved Hide resolved
soc/nordic/nrf54h/soc.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/soc.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/soc.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/power.h Outdated Show resolved Hide resolved
soc/nordic/nrf54h/power.c Outdated Show resolved Hide resolved
soc/nordic/nrf54h/power.c Show resolved Hide resolved
soc/nordic/nrf54h/power.c Show resolved Hide resolved
soc/nordic/nrf54h/power.c Outdated Show resolved Hide resolved
@adamkondraciuk adamkondraciuk force-pushed the idle_lrcconf_config branch 2 times, most recently from 2292c30 to 40ce7fe Compare October 1, 2024 13:20
Copy link
Contributor

@hubertmis hubertmis left a comment

Choose a reason for hiding this comment

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

Just please align the sub-states ids with the design. Other than that it looks good!

soc/nordic/nrf54h/power.c Outdated Show resolved Hide resolved
@adamkondraciuk
Copy link
Contributor Author

Just please align the sub-states ids with the design. Other than that it looks good!

How about overlays here ? Maybe those states could be defined in DTS instead?

@hubertmis
Copy link
Contributor

How about overlays here ? Maybe those states could be defined in DTS instead?

Yes, all power states should be defined in the .soc device tree files. Not in the sample overlays.

@karstenkoenig
Copy link
Contributor

How about overlays here ? Maybe those states could be defined in DTS instead?

Yes, all power states should be defined in the .soc device tree files. Not in the sample overlays.

@nordic-segl did that here and has his name forever tied to nrf54h20 power management ❤️
zephyrproject-rtos/zephyr#79098

The way the idle state is defined there will mean that any k_sleep() with a wakeup under 100ms will not go via the pm defined idle state but handled by the idle thread itself via a direct call to k_cpu_idle().

@hubertmis
Copy link
Contributor

hubertmis commented Oct 2, 2024

The way the idle state is defined there will mean that any k_sleep() with a wakeup under 100ms will not go via the pm defined idle state but handled by the idle thread itself via a direct call to k_cpu_idle().

Then I would consider modifying this a little:

power-states {
	active: active {
		compatible = "zephyr,power-state";
		power-state-name = "active";
		min-residency-us = <0>;
	};
	idle: idle {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-idle";
		substate-id = <0>;
		min-residency-us = <100>; // Guessing. TBD
	};
	// substate-id = <1>; is reserved for "idle-cache-retained"
	idle-cache-disabled: idle-cache-disabled {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-idle";
		substate-id = <2>;
		min-residency-us = <100000>; // Guessing. TBD
	};
};

This way the power management decisions are explicit and clear. You don't need to get expertise "What happens when the current residency is lower than defined for any power state?"

@adamkondraciuk
Copy link
Contributor Author

adamkondraciuk commented Oct 2, 2024

The way the idle state is defined there will mean that any k_sleep() with a wakeup under 100ms will not go via the pm defined idle state but handled by the idle thread itself via a direct call to k_cpu_idle().

Then I would consider modifying this a little:

power-states {
	active: active {
		compatible = "zephyr,power-state";
		power-state-name = "active";
		min-residency-us = <0>;
	};
	idle: idle {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-idle";
		substate-id = <0>;
		min-residency-us = <100>; // Guessing. TBD
	};
	// substate-id = <1>; is reserved for "idle-cache-retained"
	idle-cache-disabled: idle-cache-disabled {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-idle";
		substate-id = <2>;
		min-residency-us = <100000>; // Guessing. TBD
	};
};

This way the power management decisions are explicit and clear. You don't need to get expertise "What happens when the current residency is lower than defined for any power state?"

Zephyr doc describes such behavior very clearly here . Does it make sense to redefine those states which would behave exactly as described in Zephyr doc? That is a bit confusing. Also it introduces additional overhead for the simplest power states. IMO even idle:idle is too much here

@hubertmis
Copy link
Contributor

Zephyr doc describes such behavior very clearly here . Does it make sense to redefine those states which would behave exactly as described in Zephyr doc? That is a bit confusing. Also it introduces additional overhead for the simplest power states. IMO even idle:idle is too much here

Ok, I wasn't aware it is a rule in Zephyr. Then I'm fine with keeping the power states set limited to idle-with-cache-disabled and s2ram. But let's add substates' placeholders for lighter sleep states in case we need to add active in the future:

power-states {
	// substate-id = <0>; is reserved for "idle", cache powered on
	// substate-id = <1>; is reserved for "idle-cache-retained"
	idle-cache-disabled: idle-cache-disabled {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-idle";
		substate-id = <2>;
		min-residency-us = <100000>; // Guessing. TBD
	};
	s2ram: s2ram {
		compatible = "zephyr,power-state";
		power-state-name = "suspend-to-ram";
		substate-id = <0>;
		min-residency-us = <...>;
	};
};

@adamkondraciuk adamkondraciuk changed the title [nrf_noup] soc: nordic: nrf54h20: Add LRC around idle [nrf fromlist] soc: nordic: nrf54h20: Add LRC around idle Oct 2, 2024
@adamkondraciuk adamkondraciuk force-pushed the idle_lrcconf_config branch 2 times, most recently from 6b16788 to 1789fb0 Compare October 2, 2024 10:11
Copy link
Contributor

@nordic-piks nordic-piks left a comment

Choose a reason for hiding this comment

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

Duplicated power states definition needs to be remove from https://github.com/nrfconnect/sdk-nrf/tree/main/tests/benchmarks/multicore
at PR which updates into sdk-nrf.

Due to the possibility of simultaneous accesess to LRCCONF registers,
additional management is required.

Upstream PR: zephyrproject-rtos/zephyr#79067

Signed-off-by: Adam Kondraciuk <[email protected]>
Add `idle` and `s2ram` power states for nRF54H20 cpuapp and cpurad.
Also the substate `idle_cache_disable` added.

Upstream PR: zephyrproject-rtos/zephyr#79067

Signed-off-by: Adam Kondraciuk <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants