From: Cezary Rojewski <cezary.rojewski@intel.com>
To: Mark Brown <broonie@kernel.org>
Cc: alsa-devel@alsa-project.org, tiwai@suse.com,
Pierre-Louis Bossart <pierre-louis.bossart@linux.intel.com>,
hdegoede@redhat.com, amadeuszx.slawinski@linux.intel.com
Subject: Re: [PATCH 2/3] ASoC: core: Inline resume work back to resume function
Date: Tue, 8 Nov 2022 20:22:58 +0100 [thread overview]
Message-ID: <c600f448-9cbc-c67b-96ee-e78490f0495b@intel.com> (raw)
In-Reply-To: <Y2kWKRLp2WARpPqZ@sirena.org.uk>
On 2022-11-07 3:28 PM, Mark Brown wrote:
> It'd be good to at least have some idea of practical usage as well, the
> functions return void because nothing was making any use of the return
> values.
The problem is mainly connected to a resume operation as even if
something fails at suspend, there is a chance for the driver to recover
things up during resume.
Now, if something fails during the resume operation, blindly returning 0
makes userspace think everything is fine and we can keep going, whereas
the stream may no longer be operational and requires complete recovery
(close, reopen).
alsa-utils/aplay/aplay.c does snd_pcm_resume() as long as -EAGAIN is
returned, then falls back to snd_pcm_prepare() before finally giving up.
As snd_pcm_prepare() checks pcm's state before invoking ->prepare(), one
option is to set substream->runtime->status->state to
SNDRV_PCM_STATE_DISCONNECTED to ensure dai->hw_free() gets called right
after.
TLDR: it all comes down to some granularity missing. Suspend/resume for
the AudioDSP drivers do basically entire pcm-lifecycle within what is
supposed to be a simple TRIGGER_SUSPEND/RESUME operation.
> There's also an expectation that suspend and resume be fast...
You're right. Sound devices should not disturb the PM for the entire system.
Looking at this after thinking the performance/stability argument
through, indeed deferring work is a good way of dealing with the situation.
Regards,
Czarek
next prev parent reply other threads:[~2022-11-08 19:24 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-04 13:12 [PATCH 0/3] ASoC: core: Suspend/resume error propagation Cezary Rojewski
2022-11-04 13:12 ` [PATCH 1/3] ASoC: component: Propagate result of suspend and resume callbacks Cezary Rojewski
2022-11-04 14:00 ` Pierre-Louis Bossart
2022-11-07 8:51 ` Amadeusz Sławiński
2022-11-07 14:11 ` Pierre-Louis Bossart
2022-11-04 13:12 ` [PATCH 2/3] ASoC: core: Inline resume work back to resume function Cezary Rojewski
2022-11-04 13:58 ` Pierre-Louis Bossart
2022-11-04 23:54 ` Mark Brown
2022-11-07 9:26 ` Cezary Rojewski
2022-11-07 14:28 ` Mark Brown
2022-11-08 19:22 ` Cezary Rojewski [this message]
2022-11-04 13:12 ` [PATCH 3/3] ASoC: core: Propagate component suspend/resume errors 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=c600f448-9cbc-c67b-96ee-e78490f0495b@intel.com \
--to=cezary.rojewski@intel.com \
--cc=alsa-devel@alsa-project.org \
--cc=amadeuszx.slawinski@linux.intel.com \
--cc=broonie@kernel.org \
--cc=hdegoede@redhat.com \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=tiwai@suse.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.