From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
<alsa-devel@alsa-project.org>, <broonie@kernel.org>
Cc: upstream@semihalf.com, harshapriya.n@intel.com, rad@semihalf.com,
tiwai@suse.com, hdegoede@redhat.com,
amadeuszx.slawinski@linux.intel.com, cujomalainey@chromium.org,
lma@semihalf.com
Subject: Re: [PATCH 08/14] ASoC: Intel: avs: D0ix power state support
Date: Fri, 29 Apr 2022 16:33:56 +0200 [thread overview]
Message-ID: <d183de84-dc9a-8fbd-b016-d7d965d4905f@intel.com> (raw)
In-Reply-To: <349d743d-682b-757b-ce92-cb7c1e9c74fd@intel.com>
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
next prev parent reply other threads:[~2022-04-29 14:35 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 17:23 [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 01/14] ASoC: Intel: avs: Account for libraries when booting basefw Cezary Rojewski
2022-04-26 21:21 ` Pierre-Louis Bossart
2022-05-01 9:45 ` Cezary Rojewski
2022-05-06 15:25 ` Piotr Maziarz
2022-05-06 15:47 ` Pierre-Louis Bossart
2022-04-26 17:23 ` [PATCH 02/14] ASoC: Intel: avs: Generic soc component driver Cezary Rojewski
2022-04-26 21:33 ` Pierre-Louis Bossart
2022-05-01 10:45 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 03/14] ASoC: Intel: avs: Generic PCM FE operations Cezary Rojewski
2022-04-26 17:23 ` [PATCH 04/14] ASoC: Intel: avs: non-HDA PCM BE operations Cezary Rojewski
2022-04-26 21:40 ` Pierre-Louis Bossart
2022-05-01 10:48 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 05/14] ASoC: Intel: avs: HDA " Cezary Rojewski
2022-04-26 21:45 ` Pierre-Louis Bossart
2022-05-01 10:55 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 06/14] ASoC: Intel: avs: Coredump and recovery flow Cezary Rojewski
2022-04-26 21:53 ` Pierre-Louis Bossart
2022-05-01 15:32 ` Cezary Rojewski
2022-05-02 13:53 ` Pierre-Louis Bossart
2022-04-26 17:23 ` [PATCH 07/14] ASoC: Intel: avs: Prepare for firmware tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 08/14] ASoC: Intel: avs: D0ix power state support Cezary Rojewski
2022-04-26 21:58 ` Pierre-Louis Bossart
2022-04-29 14:19 ` Cezary Rojewski
2022-04-29 14:33 ` Cezary Rojewski [this message]
2022-04-26 17:23 ` [PATCH 09/14] ASoC: Intel: avs: Event tracing Cezary Rojewski
2022-04-26 17:23 ` [PATCH 10/14] ASoC: Intel: avs: Machine board registration Cezary Rojewski
2022-04-26 22:12 ` Pierre-Louis Bossart
2022-04-29 14:01 ` Cezary Rojewski
2022-05-04 9:41 ` Amadeusz Sławiński
2022-05-04 11:12 ` Cezary Rojewski
2022-05-04 11:26 ` Péter Ujfalusi
2022-05-04 12:33 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 11/14] ASoC: Intel: avs: PCI driver implementation Cezary Rojewski
2022-04-26 17:23 ` [PATCH 12/14] ASoC: Intel: avs: Power management Cezary Rojewski
2022-04-26 22:18 ` Pierre-Louis Bossart
2022-04-29 13:44 ` Cezary Rojewski
2022-04-26 17:23 ` [PATCH 13/14] ASoC: Intel: avs: SKL-based platforms support Cezary Rojewski
2022-04-26 17:23 ` [PATCH 14/14] ASoC: Intel: avs: APL-based " Cezary Rojewski
2022-04-27 8:15 ` [PATCH 00/14] ASoC: Intel: avs: Driver core and PCM operations Cezary Rojewski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d183de84-dc9a-8fbd-b016-d7d965d4905f@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=cujomalainey@chromium.org \
--cc=harshapriya.n@intel.com \
--cc=hdegoede@redhat.com \
--cc=lma@semihalf.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=rad@semihalf.com \
--cc=tiwai@suse.com \
--cc=upstream@semihalf.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox