On 2022-04-29 4:19 PM, Cezary Rojewski wrote:
On 2022-04-26 11:58 PM, Pierre-Louis Bossart wrote:
On 4/26/22 12:23, Cezary Rojewski wrote:
Audio DSP device supports D0 substates in form of D0ix, allowing for
preserving more power even when device is still considered active (D0).
When entered, certain domains which are not being currently used become
power gated. Entering and leaving D0ix is a complex process and differs
between firmware generations.
Conditions that disallow D0i3 and require immediate D0i0 transition
include but may not be limited to: IPC traffic, firmware tracing and
SRAM I/O. To make D0ix toggling sane, delay D0i3 transition and refresh
the timer each time an IPC is requrested.
typo: requested.
Ack.
I find it odd to list all kinds of criteria but only handle one in the
end. Do the other matter, is this a TODO, unclear what you are trying
to say.
Good question. Firmware tracing code is part of debugfs.c file which has
not yet been shared. But all other usages, not listed here, come down to
invoking enable_d0ix() or disable_d0ix() whenever given operation blocks
DSP from transitioning to D0iX.
Other usages such as directly accessing SRAM (outside of IPC handling)
is non-existant in the avs-driver. When IPCs, most firmware generations
take care of toggling d0ix for you.
Sorry for the million typos.
In the last one what I meant is: directly accessing SRAM is a separate
case, that is, when done outside of IPC protocol. We do not do that in
the avs-driver. Why IPC protocol is 'so special'? Most firmware
generations take care of toggling D0iX for the software so there is no
need to disable the transition, read the reply from SRAM, do anything
else necessary and re-enable it. Note: it's not true for all the
generations :)
Regardless of the firmware generation used, software should be smart
about choosing the right time for the transition. If we were to
transition blindly after every single IPC, DSP would probably end up
consuming more power than if no D0iX request were ever sent.
Regards,
Czarek
