-
Notifications
You must be signed in to change notification settings - Fork 349
zephyr: cpu: Suspend and resume DAIs during D3 state transitions #9454
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
zephyr: cpu: Suspend and resume DAIs during D3 state transitions #9454
Conversation
kv2019i
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some questions inline.
zephyr/lib/cpu.c
Outdated
| mod = comp_mod(icd->cd); | ||
| cd = module_get_private_data(mod); | ||
| dd = cd->dd[0]; | ||
| if (dai_remove(dd->dai->dev) < 0) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, @tmleman can you refresh why this is needed on SOF side? I mean Zephyr has a PM framework for devices and actually most of the DAI drivers we have, register to it. E.g. Intel dmic driver implements dmic_pm_action(). So Zephyr should already put the devices to the suspend -- not sure why we need this on SOF side.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SOF manages DAI power states explicitly due to the requirement that all audio pipelines must be paused before entering D3. Zephyr's PM framework doesn't automatically suspend devices like DAIs during system PM transitions, as it's designed for devices to be suspended based on runtime usage. SOF's power management needs to synchronize DAI states with the DSP core during audio-specific power transitions, which is beyond the scope of Zephyr's device-level PM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@tmleman please capture this in some comments inside the code so people can understand why can't we just use (yet) the Zephyr PM.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tmleman , and indeed I'll echo @dbaluta 's comment that please add a comment about this. This is different from e.g. Linux kernel (devices are suspended when system is suspended), so this can be surprising to many people. And looking at Zephyr docs, PM_DEVICE_SYSTEM_MANAGED states ""This option enables the system-managed device power management. The power management subsystem will suspend
devices before entering a low power state. "" Isn't this what we want for SOF as well (and this option is set for SOF)? @ceolin @nashif can you chime in on this as well?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @tmleman . I now realize I've been confused by the probe/remove functions. In Linux kernel, these are part of the device model (linux/device/driver.h) and they don't imply power up/down like used here. But in Zephyr, probe/remove are actually DAI specific methods, and the documentation explicitly mentions power-up/down.
Now we don't need to have alignment, but as Zephyr is using similar naming (for device model and runtime-pm), this is somewhat unfortunate reuse of terms. But oh well, now that I realize that, then I understand the patch and am good with it.
d34ec9c to
b9f68ec
Compare
b9f68ec to
b7564b1
Compare
fcb1219 to
47a5680
Compare
Zephyr's device power management framework offers two methods for reducing power consumption: Device Runtime Power Management and System-Managed Device Power Management. These methods allow devices to be suspended when idle, either independently or as part of system power state transitions. The framework is designed to minimize power usage with minimal intervention from applications, relying on device drivers to manage the power state transitions of their devices. The SOF firmware uses Zephyr's Device Runtime Power Management for DAIs, where the device driver is responsible for indicating the active or idle state of the device. However, during system-wide power state transitions such as D3 entry and exit, explicit power state management is necessary to maintain audio data integrity and prevent artifacts. In SOF, entry into the D3 power state requires that there be no active audio pipelines. This means that all pipelines must be paused (if not deleted), and while paused DAIs remain powered up, they must be explicitly managed to ensure they are in the correct state for D3 transitions. This patch enhances the SOF firmware's power management by adding static helper functions `suspend_dais()` and `resume_dais()` within `cpu.c`. These functions manage the power states of DAI components explicitly during D3 state transitions, ensuring that DAIs are suspended before the DSP core enters D3 and resumed upon wake-up. By implementing this logic within the SOF firmware, we provide a more integrated and reliable power management process that aligns with the complex requirements of audio DSP workloads. This approach ensures that the SOF firmware can manage DAI power states effectively, complementing Zephyr's device runtime PM framework. Signed-off-by: Tomasz Leman <tomasz.m.leman@intel.com>
|
@lgirdwood This looks good to me. |
Zephyr's device power management framework offers two methods for reducing power consumption: Device Runtime Power Management and System-Managed Device Power Management. These methods allow devices to be suspended when idle, either independently or as part of system power state transitions. The framework is designed to minimize power usage with minimal intervention from applications, relying on device drivers to manage the power state transitions of their devices.
The SOF firmware uses Zephyr's Device Runtime Power Management for DAIs, where the device driver is responsible for indicating the active or idle state of the device. However, during system-wide power state transitions such as D3 entry and exit, explicit power state management is necessary to maintain audio data integrity and prevent artifacts. In SOF, entry into the D3 power state requires that there be no active audio pipelines. This means that all pipelines must be paused (if not deleted), and while paused DAIs remain powered up, they must be explicitly managed to ensure they are in the correct state for D3 transitions.
This patch enhances the SOF firmware's power management by adding static helper functions
suspend_dais()andresume_dais()withincpu.c. These functions manage the power states of DAI components explicitly during D3 state transitions, ensuring that DAIs are suspended before the DSP core enters D3 and resumed upon wake-up. By implementing this logic within the SOF firmware, we provide a more integrated and reliable power management process that aligns with the complex requirements of audio DSP workloads. This approach ensures that the SOF firmware can manage DAI power states effectively, complementing Zephyr's device runtime PM framework.