[alsa-devel] [PATCH v4] ASoC: ak4613: call dummy write for PW_MGMT1/3 when Playback

Takashi Sakamoto o-takashi at sakamocchi.jp
Thu Dec 7 02:42:24 CET 2017


On Dec 5 2017 11:21, Kuninori Morimoto wrote:
> 
> Hi Takashi, again
> 
>>> +static void ak4613_dummy_write(struct work_struct *work)
>>> +{
>>> +	struct ak4613_priv *priv = container_of(work,
>>> +						struct ak4613_priv,
>>> +						dummy_write_work);
>>> +	struct snd_soc_component *component = priv->component;
>>> +	unsigned int mgmt1;
>>> +	unsigned int mgmt3;
>>> +
>>> +	/* wait 5 LR clocks */
>>> +	udelay(5000000 / priv->rate);
>>> +
>>> +	snd_soc_component_read(component, PW_MGMT1, &mgmt1);
>>> +	snd_soc_component_read(component, PW_MGMT3, &mgmt3);
>>> +
>>> +	snd_soc_component_write(component, PW_MGMT1, mgmt1);
>>> +	snd_soc_component_write(component, PW_MGMT3, mgmt3);
>>> +}
>>
>> In my understanding, it's better to have care of kernel preemption in
>> this case because data transmission is already activated and these
>> should be executed as quick as possible to prevent much presentation
>> loss.
> 
> To avoid v6 patch, I want to know more clearly.
> Do you mean it needs spin lock ?
> If so lock in trigger, and unlock here ?
> Or lock/unlock on each ?

Hm.

Taking offload to scheduling tasks demands developers to have enough
knowledge about running process contexts on Operating System.
Apparently, you have little knowledge about it (and few interests in
it, in my opinion. I guess that you don't know Linux kernel adds
several kthreads for workqueues according to their priorities and
localities).

Please study about it, before proposing your insistences. Your
colleagues or offshore staffs might help your learning.


Regards

Takashi Sakamoto


More information about the Alsa-devel mailing list