Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Mon, 3 Jul 2023 09:48:34 +0200
From:   Johan Hovold <johan@kernel.org>
To:     Srinivas Kandagatla <srinivas.kandagatla@linaro.org>,
        Mark Brown <broonie@kernel.org>
Cc:     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
Message-ID: <ZKJ9UrB8FRkLzLc-@hovoldconsulting.com>
References: <20230628092404.13927-1-srinivas.kandagatla@linaro.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20230628092404.13927-1-srinivas.kandagatla@linaro.org>
Precedence: bulk

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.

> Fixes: 9b4fe0f1cd79 ("ASoC: qdsp6: audioreach: add q6apm-dai support")
> Cc: <Stable@vger.kernel.org>

I noticed that Mark dropped this to avoid regressions in stable, but if
this indeed fixes the probe race then we may want to consider
backporting it after all.

> Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
> ---
>  sound/soc/qcom/qdsp6/q6apm-dai.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/sound/soc/qcom/qdsp6/q6apm-dai.c b/sound/soc/qcom/qdsp6/q6apm-dai.c
> index 5eb0b864c740..c90db6daabbd 100644
> --- a/sound/soc/qcom/qdsp6/q6apm-dai.c
> +++ b/sound/soc/qcom/qdsp6/q6apm-dai.c
> @@ -840,6 +840,7 @@ static const struct snd_soc_component_driver q6apm_fe_dai_component = {
>  	.pointer	= q6apm_dai_pointer,
>  	.trigger	= q6apm_dai_trigger,
>  	.compress_ops	= &q6apm_dai_compress_ops,
> +	.use_dai_pcm_id = true,
>  };
>  
>  static int q6apm_dai_probe(struct platform_device *pdev)

Johan