From mboxrd@z Thu Jan 1 00:00:00 1970 From: Takashi Iwai Subject: Re: [PATCH] ASoC: rsnd: stop all working stream when .remove Date: Mon, 04 Sep 2017 20:46:34 +0200 Message-ID: References: <874lsnniv3.wl%kuninori.morimoto.gx@renesas.com> <87d17akgqr.wl%kuninori.morimoto.gx@renesas.com> Mime-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by alsa0.perex.cz (Postfix) with ESMTP id 4F87126683B for ; Mon, 4 Sep 2017 20:46:35 +0200 (CEST) In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: alsa-devel-bounces@alsa-project.org Sender: alsa-devel-bounces@alsa-project.org To: Kuninori Morimoto Cc: Linux-ALSA , Mark Brown , Simon List-Id: alsa-devel@alsa-project.org 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