On Mon, 04 Sep 2017 20:43:19 +0200, Takashi Iwai wrote:
On Mon, 04 Sep 2017 19:44:36 +0200, Kuninori Morimoto wrote:
Hi Takasi-san
The lack of stop sync is a known problem in the ALSA PCM infrastructure. The standard idiom is to do sync at both prepare and hw_free (or close) callbacks.
Thanks. This path main sync is for clk ON/OFF
Hm, but it's managed as PCM trigger, no? How can the rsnd_io_is_working() return true after PCM streams are stopped?
It is based on PCM trigger, thus, it returns false if PCM streams are stopped.
This driver calls clk_get() when PCM started, and clk_put() when stopped. And it calles clk_enable() on .probe, and clk_disable() on .remove.
My problem is that user unbinds driver during Sound playing, this means clk_get() is called, but clk_put() is not called.
Then, .remove will call clk_disable(), but clk_put() is not yet called. Then, kernel indicates clk user count mismatch. This patch calls missing PCM stop (= clk_put()) position function if needed. Is this clear answer for you ?
This isn't something you shouldn't fiddle with the codec layer. If the driver gets removed during the operation, you have to cancel the operation and sync with it in a proper way, then proceed the rest of the remove, not only a codec-specific resource management.
Admittedly, there is no common infrastructure for that. But it doesn't mean that each codec driver should do its own hack.
I can imagine a way like calling the card disconnect/free at codec remove, so that it can sync with the whole stop operation before doing the rest. This should be ignored when the code path is from the card removal -- e.g. checking card->shutdown flag.
Here I mentioned the codec driver, but it's applied to each lower-level component. It'd need some graceful way to communicate with the top-level card to assure the removal of the component.
Takashi