From: Srinivas Kandagatla <srini@kernel.org>
To: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>,
Srinivas Kandagatla <srini@kernel.org>,
Mark Brown <broonie@kernel.org>
Cc: Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
Val Packett <val@packett.cool>,
Luca Weiss <luca.weiss@fairphone.com>,
linux-sound@vger.kernel.org, linux-arm-msm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] ASoC: qcom: q6apm-lpass-dais: start the graph at prepare
Date: Wed, 8 Jul 2026 23:13:18 +0100 [thread overview]
Message-ID: <523fd389-e423-4acd-8edb-029d2633cf1a@kernel.org> (raw)
In-Reply-To: <20260705033830.305907-1-jorijnvdgraaf@catcrafts.net>
On 7/5/26 4:38 AM, Jorijn van der Graaf wrote:
> The DAPM power-up sequence runs during snd_pcm prepare, but the BE
> port graph is only started at trigger time. A codec that powers up
> synchronously from a DAPM widget event and needs a running bit clock
I guess you are referring to the IBIT clk that dsp provides, not the mclk.
Could you not enable this from the machine driver?
> at that point - such as aw88261 since commit caea99ac809d ("ASoC:
> codecs: aw88261: remove async start") - can therefore never see a
> live clock: its power-up check runs before the trigger and fails on
> every stream start.>
> Start the graph at the end of prepare instead, mirroring what
> q6afe_dai_prepare() does on the legacy stack, so the interface
> clocks already run when DAPM powers up the codec. The FE side
> already starts its own graph at prepare in q6apm_dai_prepare();
> only the BE waited for trigger. The trigger-time start is kept as
> a fallback, guarded by is_port_started.
>
> Tested on the Fairphone (Gen. 6) - 2x aw88261 on Senary MI2S:
> without this the amplifiers fail to power up with SYSST reporting
> "no clock" on every stream start; with it they start synchronously,
> including for the first short stream of the boot.
>
> Assisted-by: Claude:claude-fable-5
> Signed-off-by: Jorijn van der Graaf <jorijnvdgraaf@catcrafts.net>
> ---
> Sending as RFC because this changes when the port starts clocking for
> every AudioReach platform, and I may be missing the reason the start
> was placed in trigger rather than prepare in the first place:
>
> - Is there a downside to starting the graph at prepare on AudioReach
> (power, pop/click, or DSP-side constraints)? The legacy q6afe stack
> has started its ports at the end of prepare all along, and the FE
> side of AudioReach already starts its graph in q6apm_dai_prepare().
> - With the BE started at prepare, the BE graph now starts before the
> FE graph for playback (prepare runs BE-first) — does
> APM_CMD_GRAPH_START ordering between the two graphs matter?
> - Is the capture direction fine with this, or should it stay
> trigger-started?
>
> If this approach is right, the trigger callback becomes unreachable
> and I would drop it entirely in a non-RFC respin, like q6afe (which
> has no trigger op); it is kept here to keep the diff minimal.
>
> Note: the test setup also carried my pending aw88261 power-up check
> fix, which addresses an unrelated SYSST-check failure on this board:
> https://lore.kernel.org/linux-sound/20260704192857.88366-1-jorijnvdgraaf@catcrafts.net/
>
> Context (report and analysis of the aw88261 failure):
> https://lore.kernel.org/linux-sound/d2318ba8-43f9-478b-8f9e-2c09d44ae0b1@packett.cool/
>
> sound/soc/qcom/qdsp6/q6apm-lpass-dais.c | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
>
> diff --git a/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c b/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c
> index 006b283484d9..36e12a770c72 100644
> --- a/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c
> +++ b/sound/soc/qcom/qdsp6/q6apm-lpass-dais.c
> @@ -224,6 +224,20 @@ static int q6apm_lpass_dai_prepare(struct snd_pcm_substream *substream, struct s
> dev_err(dai->dev, "Failed to prepare Graph %d\n", rc);
> goto err;
> }
> +
> + /*
> + * Start the graph here already, like q6afe does: this way the
> + * interface clocks are running before the DAPM power-up sequence,
> + * for codecs that need a live bit clock to power up (e.g.
> + * aw88261). The trigger callback keeps its start as a fallback.
> + */
> + rc = q6apm_graph_start(dai_data->graph[dai->id]);
This is going to break pipewire DP audio case, because pipewire will
call prepare during the startup and if we do not have DP plugged in dsp
will fail to start the graph and whole pipewire Audio defaults to dummy.
--srini
> + if (rc < 0) {
> + dev_err(dai->dev, "Failed to start APM port %d\n", dai->id);
> + goto err;
> + }
> + dai_data->is_port_started[dai->id] = true;
> +
> return 0;
> err:
> if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
>
> base-commit: be44d21728b6646189779923b841ad3a46d694e5
prev parent reply other threads:[~2026-07-08 22:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-05 3:38 [RFC PATCH] ASoC: qcom: q6apm-lpass-dais: start the graph at prepare Jorijn van der Graaf
2026-07-08 14:05 ` Mark Brown
2026-07-08 21:55 ` Jorijn van der Graaf
2026-07-08 22:18 ` Srinivas Kandagatla
2026-07-10 14:32 ` Jorijn van der Graaf
2026-07-08 22:13 ` Srinivas Kandagatla [this message]
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=523fd389-e423-4acd-8edb-029d2633cf1a@kernel.org \
--to=srini@kernel.org \
--cc=broonie@kernel.org \
--cc=jorijnvdgraaf@catcrafts.net \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sound@vger.kernel.org \
--cc=luca.weiss@fairphone.com \
--cc=perex@perex.cz \
--cc=tiwai@suse.com \
--cc=val@packett.cool \
/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