Re: [PATCH v2 0/4] soundwire: qcom: stablity fixes

[Srinivas Kandagatla]

On 08/06/2023 13:40, Johan Hovold wrote:
> On Thu, Jun 08, 2023 at 12:11:45PM +0200, Johan Hovold wrote:
> > On Wed, Jun 07, 2023 at 10:36:40AM +0100, Srinivas Kandagatla wrote:
>
> > No, not yet, but I just triggered the above once more after not having
> > seen with my latest -rc5 branch for a while (e.g. 20 reboots?):
> >
> > [   11.430131] qcom-soundwire 3210000.soundwire-controller: Qualcomm Soundwire controller v1.6.0 Registered
> > [   11.431741] wcd938x_codec audio-codec: bound sdw:0:0217:010d:00:4 (ops wcd938x_sdw_component_ops [snd_soc_wcd938x_sdw])
> > [   11.431933] wcd938x_codec audio-codec: bound sdw:0:0217:010d:00:3 (ops wcd938x_sdw_component_ops [snd_soc_wcd938x_sdw])
> > [   11.435406] qcom-soundwire 3330000.soundwire-controller: Qualcomm Soundwire controller v1.6.0 Registered
> > [   11.449286] qcom-soundwire 3250000.soundwire-controller: Qualcomm Soundwire controller v1.6.0 Registered
> > [   11.450632] wsa883x-codec sdw:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
> > [   11.453155] wsa883x-codec sdw:0:0217:0202:00:1: WSA883X Version 1_1, Variant: WSA8835_V2
> > [   11.456511] wsa883x-codec sdw:0:0217:0202:00:2: WSA883X Version 1_1, Variant: WSA8835_V2
> > [   11.562623] q6apm-dai 3000000.remoteproc:glink-edge:gpr:service@1:dais: Adding to iommu group 23
> > [   11.585766] snd-sc8280xp sound: ASoC: adding FE link failed
> > [   11.585872] snd-sc8280xp sound: ASoC: topology: could not load header: -517
> > [   11.586021] qcom-apm gprsvc:service:2:1: tplg component load failed-517
> > [   11.586100] qcom-apm gprsvc:service:2:1: ASoC: error at snd_soc_component_probe on gprsvc:service:2:1: -22
> > [   11.586530] snd-sc8280xp sound: ASoC: failed to instantiate card -22
> > [   11.591831] snd-sc8280xp: probe of sound failed with error -22
> >
> > I don't think I've ever seen it before dropping the runtime PM patch as
> > you did in v2, and I hit it twice fairly quickly after dropping it. And
> > now again.
> >
> > I'm not saying that the runtime PM patch is necessarily correct, and
> > perhaps it is just changes in timing that lead to the above, but we
> > definitely have a bug here.
>
> I searched my notes and realised that I have seen this once also with
> the runtime pm patch. So the fact that happened to see it more often
> after dropping it is likely due to changes in timing.
>
> Looking at the above log it seems like we hit a probe deferral somewhere
> as some resource is not available yet, and this is eventually turned
> into a hard failure that breaks audio as the error is propagated up the
> stack.

I was looking at this too, And I think this change should help..
Not tried it though


----------------------------------->cut<----------------------------------
diff --git a/drivers/soundwire/qcom.c b/drivers/soundwire/qcom.c
index cdabfe2feceb..b57532d6b163 100644
--- a/drivers/soundwire/qcom.c
+++ b/drivers/soundwire/qcom.c
@@ -543,7 +543,7 @@ static int qcom_swrm_enumerate(struct sdw_bus *bus)
 		list_for_each_entry_safe(slave, _s, &bus->slaves, node) {
 			if (sdw_compare_devid(slave, id) == 0) {
 				qcom_swrm_set_slave_dev_num(bus, slave, i);
-				if (!slave->prop.simple_clk_stop_capable)
+				if (slave->prop.clk_stop_mode1)
 					ctrl->clock_stop_not_supported = true;

 				found = true;
diff --git a/sound/soc/qcom/qdsp6/topology.c 
b/sound/soc/qcom/qdsp6/topology.c
index cccc59b570b9..3c50a560bc84 100644
--- 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) {
+	if (ret < 0)
 		dev_err(dev, "tplg component load failed%d\n", ret);
-		ret = -EINVAL;
-	}

 	release_firmware(fw);
 err:

----------------------------------->cut<----------------------------------

> Johan