Re: [PATCH] ASoC: qdsp6: q6apm: use dai link pcm id as pcm device number

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxxxxxxx/
> > 
> > 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:



[Index of Archives]     [Linux Kernel]     [Kernel Development Newbies]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite Hiking]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux