On 9/10/2018 5:08 PM, Mark Brown wrote: > On Mon, Sep 10, 2018 at 01:36:29PM +0530, Akshu Agrawal wrote: >> If capture and playback are started on different channel (I2S/BT) >> there is a possibilty that channel information passed from machine driver >> is overwritten before the configuration is done in dma driver. >> Example: >> 113.597588: cz_max_startup: ---playback sets BT channel >> 113.597694: cz_dmic1_startup: ---capture sets I2S channel >> 113.597979: acp_dma_hw_params: ---configures capture for I2S channel >> 113.598114: acp_dma_hw_params: ---configures playback for I2S channel >> >> This is fixed by having lock between startup and prepare. This ensures >> no other codec startup gets called between a codec's startup(where channel >> info is set) and hw_params(where channel info is read). > > This isn't viable - the driver will deadlock if the application hits an > error and never gets to startup, or if the application tries to > simultaneously configure two channels (ie, do all the prepares and then > all the parameter configuration and then startup). We can avoid deadlock by having another mutex_unlock in the shutdown call of each of codec's ops. Wouldn't in all possible termination scenarios, it will cleanup and exit via shutdown callback? Having said that I think there is a better approach to this, is by having 2 separate instance variable for playback and capture for passing instance info from machine driver to dma driver. Respective codec in machine driver will set the capture/playback instance. dma driver on the basis of substream->stream can read the correct one. No fear of deadlock in this. Thanks, Akshu _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
