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