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

Optimize PM structures #39286

Closed
keith-zephyr opened this issue Oct 8, 2021 · 3 comments
Closed

Optimize PM structures #39286

keith-zephyr opened this issue Oct 8, 2021 · 3 comments
Assignees
Labels
area: API Changes to public APIs Enhancement Changes/Updates/Additions to existing features

Comments

@keith-zephyr
Copy link
Contributor

When a board enables CONFIG_PM, the Z_DEVICE_DEFINE macro allocates an extra 96 (or 100) bytes per device instance. This is true regardless of whether the device instance requires power management notification.

There is significant RAM and flash savings if power management is only declared for the device instances that need power management (5000 bytes or more).

There are three possible solutions:

  1. Automatically detect when the pm_control_fn parameter is NULL, and exclude the PM related definitions. PR#39166 implements this approach, but needs some minor cleanup.
  2. Add a new token PM_DISABLED. Caller's use PM_DISABLED in place of NULL for the pm_control_fn parameter. Draft PR#39256
  3. Split out PM structures completely from the Z_DEFINE_DEFINE and associated macros. Require device instances that need power management to add TBD macros to enable power management.
@keith-zephyr keith-zephyr added Enhancement Changes/Updates/Additions to existing features area: API Changes to public APIs labels Oct 8, 2021
keith-zephyr added a commit to keith-zephyr/zephyr that referenced this issue Oct 11, 2021
If a driver doesn't support PM, as indicated by setting the
pm_control_fn parameter to NULL, no need to manage busy or wakeup state.
This also prepares the PM support for issue zephyrproject-rtos#39286, which will allocate
PM structures only for the devices that request it.

Signed-off-by: Keith Short <keithshort@google.com>
@keith-zephyr
Copy link
Contributor Author

From the Zephyr API meeting 2021-10-12.
Option 3 is rejected because it essentially reverts back to the original implementation of power management. API member noted that splitting the power management from the device led to poor adoption of power management when users create new drivers.

@ceolin ceolin self-assigned this Oct 13, 2021
nashif pushed a commit that referenced this issue Oct 13, 2021
If a driver doesn't support PM, as indicated by setting the
pm_control_fn parameter to NULL, no need to manage busy or wakeup state.
This also prepares the PM support for issue #39286, which will allocate
PM structures only for the devices that request it.

Signed-off-by: Keith Short <keithshort@google.com>
@keith-zephyr
Copy link
Contributor Author

@gmarull has opened PR #39397 that I'll refer to as option 4.

Option 4 is similar to option 3, in that the PM definitions are broken out into a new macro. However, the Z_DEVICE_DEFINE macro changes the pm_control_fn parameter to pm_enable, so power management is still part of the general device initialization.

Rushybrook pushed a commit to Rushybrook/zephyr that referenced this issue Oct 21, 2021
If a driver doesn't support PM, as indicated by setting the
pm_control_fn parameter to NULL, no need to manage busy or wakeup state.
This also prepares the PM support for issue zephyrproject-rtos#39286, which will allocate
PM structures only for the devices that request it.

Signed-off-by: Keith Short <keithshort@google.com>
@keith-zephyr
Copy link
Contributor Author

PR#39397 merged and addresses this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: API Changes to public APIs Enhancement Changes/Updates/Additions to existing features
Projects
None yet
Development

No branches or pull requests

2 participants