On Fri, 13 Oct 2017 11:11:42 +0200, Kuninori Morimoto wrote:
Hi Takashi
I tested this patch-set. I noticed that it doesn't work if I used DPCM (Kernel has Oops). I will investigate it next week
Could you show the Oops message if you have? My concern is whether it happens by stopping at disconnect, or it's just another missing piece.
OK, but kernel log doesn't help you. see below
My environment now is I'm using DPCM. FE : rsnd FE : rsnd BE : ak4613
1st issue is that kernel need below patch. I guess BE is using dummy driver, and it doesn't have ops(?). If this is needed, I can post it.
No, this can't be right. Every PCM implementation mandates the presence of a trigger callback. It's a must. If a fix needed, it has to be fixed in the driver side.
diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index 2fec2fe..972408b 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -1241,7 +1241,8 @@ static int snd_pcm_do_stop(struct snd_pcm_substream *substream, int state) { if (substream->runtime->trigger_master == substream && snd_pcm_running(substream))
substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_STOP);
if (substream->ops && substream->ops->trigger)substream->ops->trigger(substream, SNDRV_PCM_TRIGGER_STOP);}
After this patch, my driver side clock counter mismatch Oops happen. It seems this is because FE side wasn't called snd_pcm_stop(); (= BE side only called snd_pcm_stop()).
So the check might work around an Oops, but it's no "fix", per se.
I could confirm this by printing who's stop was called by local quick hack.
Maybe timing reason, if kernel has Oops for some reasons, then, both BE/FE snd_pcm_stop() are called. If no Oops, BE snd_pcm_stop() only called.
Any pending delayed work (like rtd->delayed_work)? This is flushed at soc_cleanup_card_resources(), but it's called at card removal, thus it's too late for the hot-removal of the component.
thanks,
Takashi