Hi Pierre,
On 10/5/2021 6:47 PM, Pierre-Louis Bossart wrote:
My patches don't change anything related to a spinlock or pcm stream
management, so not sure what could cause this rather spectacular
failure. That hints at a fundamental configuration difference, possibly
caused by your component chaining?
Since in your case you have a 1:1 mapping between FE and BE, would you
mind testing by backtracking, one patch at a time to see which one of
the three last patches could cause a problem on your board?
I tested this further. It appears that things work fine till 'patch 3/5'
of yours. After I take 'patch 4/5', the print "BUG: scheduling while
atomic: aplay" started showing up and I see a hang. This failure was
seen for 2x1 mixer test itself.
The 'patch 4/5' introduces mutex_lock/unlock() in dpcm_be_dai_trigger().
This seems to be the problem, since trigger() runs in atomic context
depending on the PCM 'nonatomic' flag. I am not sure if your design sets
'nonatomic' flag by default and that is why the issue is not seen at
your end?
With below (just for testing purpose), tests ran well. I was able to run
2x1, 3x1 ... 10x1 mixer tests.
diff --git a/sound/soc/soc-pcm.c b/sound/soc/soc-pcm.c
index e5df898..2ce30d1 100644
--- a/sound/soc/soc-pcm.c
+++ b/sound/soc/soc-pcm.c
@@ -2045,7 +2045,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime
*fe, int stream,
struct snd_soc_dpcm *dpcm;
int ret = 0;
- mutex_lock(&fe->card->dpcm_mutex);
+ //mutex_lock(&fe->card->dpcm_mutex);
for_each_dpcm_be(fe, stream, dpcm) {
struct snd_pcm_substream *be_substream;
@@ -2166,7 +2166,7 @@ int dpcm_be_dai_trigger(struct snd_soc_pcm_runtime
*fe, int stream,
}
}
end:
- mutex_unlock(&fe->card->dpcm_mutex);
+ //mutex_unlock(&fe->card->dpcm_mutex);
if (ret < 0)
dev_err(fe->dev, "ASoC: %s() failed at %s (%d)\n",
__func__, be->dai_link->name, ret);
In fact I picked up all of your patches + above test patch, it worked fine.
Thanks,
Sameer.
