ALSA中Widget、route、kcontrol 命名规则

来源：互联网发布：手机蓝牙共享网络win10 编辑：程序博客网时间：2024/06/11 02:51

对于上面的命名规则，我一直很疑惑，那天我仔细的研究了下：

Kcontrol:

对于struct snd_kcontrol_new结构体里面有以下主要成员：

1、 iface:是定义了kcontrol 的类型，有很多的类型通常以SND_CTL_ELEM_IFACE_xxx定义，有mux、mixer、card、master等一些类型

2、 aceee:设置访问的权限，也是有宏实现好的，SNDRV_CTL_ELEM_ACESS_READ是值读的，这个时候，在结构体里面的put函数就没有必要实现了，如果是SNDRV_CTL_ELEM_ACESS_WRITE就意味着是只写的，这个时候get函数就没有必要实现了。加入control的值频繁的变化的话，那么就设置acess的值是VOLATILE。当control的值处于非激活状态的时候应设置INACTIVE标志

3、 private_value：是包含一个长整型的值，这个值里面很重要，这个里面的值会传递给info()、get()、put()这些callback function使用，这个private_value里面有很多的成员，下面我会举例说明下

4、 name：这个成员也是非常重要的成员，因为kcontrol的作用是由名称来区分的，对于相同名称的kcontrol则用index 区分的，对于mixer通路就是通过和route.control_name从widget中找到合适的kcontrol的,对于mux是根据route.control_name和kcontrol中private_data里面的txt数组里面的名字匹配的

这个private_data有很多的宏可以定义，定义的成员有主要有以下几个：

4.1:reg_left指的是register的值，这个代表是左声道的register

4.2:reg_right指的是register的值，这个代表是右声道的register

4.3:xshift指的控制的位偏移，其实就是的功能的那个位开始，为头

4.4:max:指的是控制的功能在codec register中时由几位控制的

4.5:invert:看英文的意思就是反转的意思，o代表是不反转的意思，1代表反转的意思，如果反转的话，那么设置的值越大结构也就越大，如果是不反转的话，那么效果和反转是相反的。

5、这个name 的定义还有一些标准的规则，”SOURCE,DIRECTION,FUNCTION”中文的定义是”源，方向，功能”SOURCE是定义控制的源，例如PCM、Master。DIRECTION是

控制的方向如：capture、playback，如果FUNCTION省略的话，那么就代表是双向的。FUNCTION是功能：switch、Volume、route等

6、 put:kcontrol 对于很多的switch 、slider应用广泛，它可以被用户控件进行存取，从而达到读写codec register的作用，当上层需要写codec register的时候，就会最终调用到这个put函数

7、 get:根据名字也可以看出，get是得到数据就从codec中得到数据，就是read，上层如果要从codec 中读取数据的时候，最终就会调用到这个read函数

snd_soc_dapm_add_routes

上面的函数会进行route 的添加和path 的创建

Route 的命名规则是：route(sink,control,source),sink是目的的widget,control 是control的名字,这个control其实就是sink里面的control就是sink 里面的control，source是源widget,上面route的定义的意思是：通过sink中的kcontrol控制达到source---àsink的path的控制

在snd_soc_dapm_add_routes函数里面会进行如下动作

1、会根据route 里面的sink和source的名字找到名字相同的widget,然后创建path ,将找到的widget赋值给path

2、设置widget是否是extern widget,和path的connect 的状态，主要分为几种类型：static、dynamic、两种类型，有的widget开始就是处于connect status，就不需要自己去通过kcontrol去连接，下面去讲解下mux和mixer着两种case

Case mux:

dapm_connect_mux函数

staticintdapm_connect_mux(struct snd_soc_dapm_context *dapm,

struct snd_soc_dapm_widget *src,struct snd_soc_dapm_widget *dest,

struct snd_soc_dapm_path *path,constchar *control_name,

conststruct snd_kcontrol_new *kcontrol)

{

struct soc_enum *e = (struct soc_enum *)kcontrol->private_value;

int i;

for (i = 0; i < e->max; i++) {

if (!(strcmp(control_name, e->texts[i]))) {

list_add(&path->list, &dapm->card->paths);

list_add(&path->list_sink, &dest->sources);

list_add(&path->list_source, &src->sinks);

path->name = (char*)e->texts[i];

dapm_set_path_status(dest, path, 0);

return 0;

}

return -ENODEV;

}

看上面的代码，我们就会发现，我们会将route中的control_name和这个widget.private_data.txt[i]中的名字数组进行对比，如果一样的话，就代表这个widget中的kcontrol可以控制这个path 的通路的

接下来我们再看两外一个函数：

Case: mixer：

dapm_connect_mixer：会创建关于mixer相关的path

/* connect mixer widget to its interconnecting audio paths */

staticintdapm_connect_mixer(struct snd_soc_dapm_context *dapm,

struct snd_soc_dapm_widget *src,struct snd_soc_dapm_widget *dest,

struct snd_soc_dapm_path *path,constchar *control_name)

{

int i;

/* search for mixer kcontrol */

for (i = 0; i < dest->num_kcontrols; i++) {

if (!strcmp(control_name, dest->kcontrols[i].name)) {

list_add(&path->list, &dapm->card->paths);

list_add(&path->list_sink, &dest->sources);

list_add(&path->list_source, &src->sinks);

path->name = dest->kcontrols[i].name;

dapm_set_path_status(dest, path, i);

return 0;

}

return -ENODEV;

}

看了上面的代码，你会发现我们会发现我们的widget里面有很多的kcontrol数组，我们再创建path 的时候，我们会根据route 的control name 和mixer widget中的kcontrol数组里面的kocntrol .name进行匹配，如果成功的话，那么才会创建这个path

接下来我们再看另外一个函数：

dapm_set_path_status：这个函数会判断我们的创建的path的通路的状态

/* set up initial codec paths */

staticvoiddapm_set_path_status(struct snd_soc_dapm_widget *w,

struct snd_soc_dapm_path *p,int i)

{

switch (w->id) {

case snd_soc_dapm_switch:

case snd_soc_dapm_mixer:

case snd_soc_dapm_mixer_named_ctl: {

int val;

struct soc_mixer_control *mc = (struct soc_mixer_control *)

w->kcontrols[i].private_value;

unsignedint reg = mc->reg;

unsignedint shift = mc->shift;

int max = mc->max;

unsignedint mask = (1 << fls(max)) - 1;

unsignedint invert = mc->invert;

val = snd_soc_read(w->codec, reg);

val = (val >> shift) & mask;

if ((invert && !val) || (!invert && val))

p->connect = 1;

else

p->connect = 0;

}

break;

case snd_soc_dapm_mux: {

struct soc_enum *e = (struct soc_enum *)w->kcontrols[i].private_value;

int val, item, bitmask;

for (bitmask = 1; bitmask < e->max; bitmask <<= 1)

;

val = snd_soc_read(w->codec, e->reg);

item = (val >> e->shift_l) & (bitmask - 1);

p->connect = 0;

for (i = 0; i < e->max; i++) {

if (!(strcmp(p->name, e->texts[i])) && item == i)

p->connect = 1;

}

break;

case snd_soc_dapm_virt_mux: {

struct soc_enum *e = (struct soc_enum *)w->kcontrols[i].private_value;

p->connect = 0;

/* since a virtual mux has no backing registers to

* decide which path to connect, it will try to match

* with the first enumeration. This is to ensure

* that the default mux choice (the first) will be

* correctly powered up during initialization.

if (!strcmp(p->name, e->texts[0]))

p->connect = 1;

}

break;

case snd_soc_dapm_value_mux: {

struct soc_enum *e = (struct soc_enum *)

w->kcontrols[i].private_value;

int val, item;

val = snd_soc_read(w->codec, e->reg);

val = (val >> e->shift_l) & e->mask;

for (item = 0; item < e->max; item++) {

if (val == e->values[item])

break;

}

p->connect = 0;

for (i = 0; i < e->max; i++) {

if (!(strcmp(p->name, e->texts[i])) && item == i)

p->connect = 1;

}

break;

/* does not effect routing - always connected */

case snd_soc_dapm_pga:

case snd_soc_dapm_out_drv:

case snd_soc_dapm_output:

case snd_soc_dapm_adc:

case snd_soc_dapm_input:

case snd_soc_dapm_dac:

case snd_soc_dapm_micbias:

case snd_soc_dapm_vmid:

case snd_soc_dapm_supply:

case snd_soc_dapm_aif_in:

case snd_soc_dapm_aif_out:

p->connect = 1;

break;

/* does effect routing - dynamically connected */

case snd_soc_dapm_hp:

case snd_soc_dapm_mic:

case snd_soc_dapm_spk:

case snd_soc_dapm_line:

case snd_soc_dapm_pre:

case snd_soc_dapm_post:

p->connect = 0;

break;

}

这个函数，我自我感觉重要性还是很强的，我讲解下两种情况：

（1）case snd_soc_dapm_switch:

case snd_soc_dapm_mixer:

case snd_soc_dapm_mixer_named_ctl:

这个case 我们会根据shift，invert，max，reg的值，找出控制这个控制这个path的kcontrol register的某几位，然后根据这几位的值，判断path的状态，我们再定义widget的时候，也是需要按照datasheet中的值进行定义widget的

（2）case snd_soc_dapm_mux: {

struct soc_enum *e = (struct soc_enum *)w->kcontrols[i].private_value;

int val, item, bitmask;

for (bitmask = 1; bitmask < e->max; bitmask <<= 1)

;

val = snd_soc_read(w->codec, e->reg);

item = (val >> e->shift_l) & (bitmask - 1);

p->connect = 0;

for (i = 0; i < e->max; i++) {

if (!(strcmp(p->name, e->texts[i])) && item == i)

p->connect = 1;

}

对于上面的case ，我们会会读取出reg的值，将读取出来的值获取到item的值，我们会将path.name和widget.private_data.txt[i]中的name数组进行对比，首先是必须相等，然后就是从reg中的item必须和匹配i的值是相等的，这就要求我们在定义这个txt档的时候，必须和datasheet中定义的顺序是一致的；举例如下：

staticconstchar *linput_mux_text[] = {

"IN1L","IN2L", "IN3L"

};

看到上面的datasheet中值的顺序吗。这也是按照这种顺序过来的，不然我们的item的匹配时不会成功的