Re: [PATCH] ASoC: rsnd: stop all working stream when .remove

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel



[Index of Archives]     [ALSA User]     [Linux Audio Users]     [Kernel Archive]     [Asterisk PBX]     [Photo Sharing]     [Linux Sound]     [Video 4 Linux]     [Gimp]     [Yosemite News]

  Powered by Linux