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