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.