From: Takashi Iwai <tiwai@suse.de>
To: Johan Hovold <johan@kernel.org>
Cc: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
Mark Brown <broonie@kernel.org>,
johan+linaro@kernel.org, perex@perex.cz, tiwai@suse.com,
lgirdwood@gmail.com, ckeepax@opensource.cirrus.com,
kuninori.morimoto.gx@renesas.com, linux-kernel@vger.kernel.org,
pierre-louis.bossart@linux.intel.com,
alsa-devel@alsa-project.org, Stable@vger.kernel.org
Subject: Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device number
Date: Mon, 03 Jul 2023 10:19:29 +0200 [thread overview]
Message-ID: <877crh76ge.wl-tiwai@suse.de> (raw)
In-Reply-To: <ZKKA6K44mp_vjwtp@hovoldconsulting.com>
On Mon, 03 Jul 2023 10:03:52 +0200,
Johan Hovold wrote:
>
> On Mon, Jul 03, 2023 at 09:48:34AM +0200, Johan Hovold wrote:
> > On Wed, Jun 28, 2023 at 10:24:04AM +0100, Srinivas Kandagatla wrote:
> > > For some reason we ended up with a setup without this flag.
> > > This resulted in inconsistent sound card devices numbers which
> > > are also not starting as expected at dai_link->id.
> > > (Ex: MultiMedia1 pcm ended up with device number 4 instead of 0)
> > >
> > > With this patch patch now the MultiMedia1 PCM ends up with device number 0
> > > as expected.
> >
> > This appears to fix the intermittent probe breakage that I see every
> > five boots or so:
> >
> > [ 11.843320] q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23
> > [ 11.867467] snd-sc8280xp sound: ASoC: adding FE link failed
> > [ 11.867574] snd-sc8280xp sound: ASoC: topology: could not load header: -517
> > [ 11.867725] qcom-apm gprsvc:service:2:1: tplg component load failed-517
> > [ 11.867933] qcom-apm gprsvc:service:2:1: ASoC: error at snd_soc_component_probe on gprsvc:service:2:1: -22
> > [ 11.868379] snd-sc8280xp sound: ASoC: failed to instantiate card -22
> > [ 11.873645] snd-sc8280xp: probe of sound failed with error -22
> >
> > and which I've reported here:
> >
> > https://lore.kernel.org/lkml/ZIHMMFtuDtvdpFAZ@hovoldconsulting.com/
> >
> > as unrelated changes in timings resulting from that series made the
> > problem much harder (but not impossible) to hit.
> >
> > With this fix, I've rebooted 20+ times without hitting the issue once.
> >
> > I'm guessing that you found this issue while investigated that probe
> > race, Srini? It does look related, and it does seem to make the problem
> > go away, but I'm not comfortable claiming that the intermittent probe
> > breakage has been resolved without some analysis to back that up.
>
> Ok, scratch that. I just hit the race again also with this patch
> applied:
>
> [ 11.815028] q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23
> [ 11.838667] snd-sc8280xp sound: ASoC: adding FE link failed
> [ 11.838774] snd-sc8280xp sound: ASoC: topology: could not load header: -517
> [ 11.838916] qcom-apm gprsvc:service:2:1: tplg component load failed-517
> [ 11.838996] qcom-apm gprsvc:service:2:1: ASoC: error at snd_soc_component_probe on gprsvc:service:2:1: -22
> [ 11.839430] snd-sc8280xp sound: ASoC: failed to instantiate card -22
> [ 11.844801] snd-sc8280xp: probe of sound failed with error -22
Isn't it rather an issue about the error code passing in qcom driver?
How about the change like below?
Takashi
--- a/sound/soc/qcom/qdsp6/topology.c
+++ b/sound/soc/qcom/qdsp6/topology.c
@@ -1276,10 +1276,8 @@ int audioreach_tplg_init(struct snd_soc_component *component)
}
ret = snd_soc_tplg_component_load(component, &audioreach_tplg_ops, fw);
- if (ret < 0) {
- dev_err(dev, "tplg component load failed%d\n", ret);
- ret = -EINVAL;
- }
+ if (ret < 0)
+ dev_err_probe(dev, ret, "tplg component load failed %d\n", ret);
release_firmware(fw);
err:
next prev parent reply other threads:[~2023-07-03 8:19 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-28 9:24 [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device number Srinivas Kandagatla
2023-06-29 15:43 ` Mark Brown
2023-06-29 16:06 ` Greg KH
2023-06-29 16:16 ` Mark Brown
2023-06-29 17:22 ` Greg KH
2023-06-29 17:38 ` Mark Brown
2023-06-29 18:48 ` Greg KH
2023-06-29 21:23 ` Mark Brown
2023-06-29 17:33 ` Srinivas Kandagatla
2023-06-29 17:42 ` Mark Brown
2023-06-30 5:42 ` Srinivas Kandagatla
2023-06-30 17:07 ` Mark Brown
2023-07-03 7:48 ` Johan Hovold
2023-07-03 8:03 ` Johan Hovold
2023-07-03 8:19 ` Takashi Iwai [this message]
2023-07-03 8:48 ` Johan Hovold
2023-07-03 12:21 ` Johan Hovold
2023-07-03 11:56 ` Mark Brown
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=877crh76ge.wl-tiwai@suse.de \
--to=tiwai@suse.de \
--cc=Stable@vger.kernel.org \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=ckeepax@opensource.cirrus.com \
--cc=johan+linaro@kernel.org \
--cc=johan@kernel.org \
--cc=kuninori.morimoto.gx@renesas.com \
--cc=lgirdwood@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=perex@perex.cz \
--cc=pierre-louis.bossart@linux.intel.com \
--cc=srinivas.kandagatla@linaro.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox