【DAPM杂谈之二】实践是检验真理的标准

本文主要分析DAPM的设计与实现

内核的版本是：linux-5.15.164，下载链接：Linux内核下载

主要讲解有关于DAPM相关的知识，会给出一些例程并分析内核如何去实现的

/*****************************************************************************************************************/

声明: 本博客内容均由芯心智库-CSDN博客原创，转载or引用请注明出处，谢谢!

创作不易，如果文章对你有帮助，麻烦点赞 收藏支持~感谢

/*****************************************************************************************************************/

目录

零、本文主要内容

一、虚拟寄存器的定义

1.1 实现寄存器的读写

2.1 基于kcontrol实现打印所有的寄存器

二、widget实现和route的定义

三、实验验证

3.1 验证环境

3.2 源码编译方法和加载ko

3.3 实验观察一下现象

四、总结

---

零、本文主要内容

前面讲了一下内核的官方文档，但是光是看文档并不能对DAPM有深入的了解，很多时候我们对原理很懂，但是在实践中总是遇到各种各样的问题.....本文就从应用的角度去看DAPM是如何调用的！

为什么要先从应用的角度去分析，而不从设计者的角度去分析内核中的调用流程呢？因为我觉得实践才是检验真理的唯一标准！先学会用好，再去深究为什么它可以让我用得这么丝滑。

要实践一下DAPM，首先需要一份具备声卡的代码，声卡的注册也是不小的一块内容，我要继续讲一下声卡要怎么写的话，怕是有点冗长了，你可以参考我的文章：

【ASOC全解析（一）】ASOC架构简介和欲解决的问题

我基于我之前的文章（有声卡，但是没有kcontrol、Widgets等等）进行二次开发演示DAPM的功能。

本文所有提交的代码可以见平台：https://github.com/xiaoWEN7/ASOC_DAPM/tree/master

一、虚拟寄存器的定义

1.1 实现寄存器的读写

因为我们的code并不是真实存在的codec，因此会有一个问题，就是我们的各种widget需要设定寄存器的时候，无法去设定，那么为了解决这个问题，我们需要原本的snd_soc_component_driver结构体下面定义一下:

.read = virtual_reg_read,
.write = virtual_reg_write,

这部分一般的codec驱动程序都是不定义的（通常使用regmap），但是为了更加容易去控制我们手动去指定寄存器的读写函数，参考代码调用：

/sound/soc/soc-component.c
static unsigned int soc_component_read_no_lock(struct snd_soc_component *component,unsigned int reg)
{int ret;unsigned int val = 0;if (component->regmap)ret = regmap_read(component->regmap, reg, &val);else if (component->driver->read) {ret = 0;val = component->driver->read(component, reg);}elseret = -EIO;if (ret < 0)return soc_component_ret(component, ret);return val;
}
static unsigned int soc_component_read_no_lock(struct snd_soc_component *component,unsigned int reg)
{int ret;unsigned int val = 0;if (component->regmap)ret = regmap_read(component->regmap, reg, &val);else if (component->driver->read) {ret = 0;val = component->driver->read(component, reg);}elseret = -EIO;if (ret < 0)return soc_component_ret(component, ret);return val;
}

我们定义component->driver->read的读写函数和虚拟一个寄存器reg_data：

/* 寄存器列表 */
enum reg {VCODEC_ADCL_REG,VCODEC_MIC1_REG,VCODEC_Output_mixer_REG,VCODEC_CTRL_NUM   //寄存器总数
};static u32 reg_data[VCODEC_CTRL_NUM];  //虚拟的寄存器static unsigned int virtual_reg_read(struct snd_soc_component *component, unsigned int reg)
{pr_info("virtual_reg_read : reg = %d reg_data[reg]=%d \n",reg,reg_data[reg]);return reg_data[reg];
}static int virtual_reg_write(struct snd_soc_component *component, unsigned int reg, unsigned int value)
{pr_info("virtual_reg_write : reg = %d , value = %d\n",reg ,value);reg_data[reg] = value;return 0;
}static struct snd_soc_component_driver soc_my_codec_drv = {.probe = my_codec_probe,.remove = my_codec_remove,.read = virtual_reg_read,.write = virtual_reg_write,
};

2.1 基于kcontrol实现打印所有的寄存器

上面虽然实现了寄存器的读写，要一次一次的核对Kernel log，这其实并不方便，我在这里实现一个kcontrol用于显示所有的寄存器数值：

先在snd_soc_component_driver我们使用controls：

.controls		    = my_controls,
.num_controls		= ARRAY_SIZE(my_controls),

然后实现my_controls:

static const char *const reg_date[] = { "VCODEC_ADCL_REG", "VCODEC_MIC1_REG", "VCODEC_Output_mixer_REG"};int current_reg = 0;// 定义一个枚举描述结构
static const struct soc_enum audio_reg_dump =SOC_ENUM_SINGLE_EXT(ARRAY_SIZE(reg_date),
reg_date);// 获取当前音频输出模式的函数
static int get_audio_reg(struct snd_kcontrol *kcontrol,struct snd_ctl_elem_value *ucontrol)
{int i;ucontrol->value.integer.value[0] = current_reg;pr_info("************audio_reg Dump************\n");for(i=0;i<VCODEC_CTRL_NUM;i++){pr_info("reg_data[%d] = %d \n",i,reg_data[i]);}pr_info("************audio_reg Dump************\n");return 0;
}// 设置音频输出模式的函数
static int set_audio_reg(struct snd_kcontrol *kcontrol,struct snd_ctl_elem_value *ucontrol)
{current_reg = ucontrol->value.integer.value[0];pr_info("current_reg :  %d \n",current_reg);return 0;
}static const struct snd_kcontrol_new my_controls[] = {SOC_ENUM_EXT("Get Audio reg", audio_reg_dump,get_audio_reg, set_audio_reg),
};

这边我还顺便实现了基本的读写功能，这个是为什么呢？主要是展示后面的DAPM的特征用的。这一点我们文章往后会分析一下。

二、widget实现和route的定义

widget和route一般是需要同时出现了：

widget：抽象硬件成为一个一个小部件

route：描述这些部件之间的连接关系

所以要同时对这两个进行定义：

    .dapm_widgets		= vcodec_dapm_widgets,.num_dapm_widgets	= ARRAY_SIZE(vcodec_dapm_widgets),.dapm_routes		= vcodec_dapm_routes,.num_dapm_routes	= ARRAY_SIZE(vcodec_dapm_routes),

然后就是实现了，我这边假设一种硬件通路，可以让mic1这个硬件连接到ADC采集器并且ADC采集的数据直接输出到上层，硬件框架大概如下：

那么这个路由也是很明确的，应该这么写：

/* 定义音频路径（路由） */
static const struct snd_soc_dapm_route vcodec_dapm_routes[] = {/* MIC 输入路径 */{"ADCL Input", "MIC1 Boost Switch", "MIC1"},{"ADCL", NULL, "ADCL Input"},{"Output Switch", "Output_mixer", "ADCL"},/* 如果有其他输入输出路径，在此添加 */{"ADC Output", NULL, "Output Switch"},
};

MIC1可以通过一个开关去选择它到底要从ADCL Input采集，还是ADCR Input采集（我上面的路由没有抽象出ADCR的通路）。

然后如果走ADCL Input进行输入，那么会经过ADCL的控制器，这ADC控制器有很多设置，其中bit 2是使能开关，当然除了使能之外，还需要设置ADC的阻抗、通道选择、预分频器设置等等一堆设置，这些设置往往是真正需要工作的时候才开始设置，不然耗电还是挺高的。

最后经过ADCL的采集后，产生了数字信号，那么数字信号还可以被各种增益、削频等出来，也可以直接输出到上层。如果走Output Switch代表了ADC直接采集的数字信号会被输出到上层使用，如果走other swith就是其他的处理了。

综合上面，代码如下实现：

/* 定义事件处理函数 */
static int vcodec_capture_event(struct snd_soc_dapm_widget *w,struct snd_kcontrol *kcontrol, int event)
{switch (event) {case SND_SOC_DAPM_WILL_PMU:pr_info("Vcodec capture event: POST_PMU\n");break;case SND_SOC_DAPM_WILL_PMD:pr_info("Vcodec capture event: POST_PMD\n");break;default:break;}return 0;
}/* 定义控制项 */
static const struct snd_kcontrol_new mic1_input_mixer[] = {SOC_DAPM_SINGLE("MIC1 Boost Switch", VCODEC_MIC1_REG, 0, 1, 0),/* 如果有其他控件可以在这里继续添加 */
};static const struct snd_kcontrol_new mic1_Output_mixer[] = {SOC_DAPM_SINGLE("Output_mixer", VCODEC_Output_mixer_REG, 0, 1, 0),/* 如果有其他控件可以在这里继续添加 */
};/* 定义 DAPM Widget */
static const struct snd_soc_dapm_widget vcodec_dapm_widgets[] = {SND_SOC_DAPM_INPUT("MIC1"),SND_SOC_DAPM_MIXER("ADCL Input", SND_SOC_NOPM, 0, 0,mic1_input_mixer, ARRAY_SIZE(mic1_input_mixer)),/* 2表示偏移量，也就是设置这个寄存器的数值为 1<<2 = 4 */SND_SOC_DAPM_AIF_OUT_E("ADCL", "Capture", 0, VCODEC_ADCL_REG,2, 0, vcodec_capture_event,SND_SOC_DAPM_WILL_PMU | SND_SOC_DAPM_WILL_PMD),SND_SOC_DAPM_MIXER("Output Switch", SND_SOC_NOPM, 0, 0,mic1_Output_mixer, ARRAY_SIZE(mic1_Output_mixer)),SND_SOC_DAPM_OUTPUT("ADC Output"),  /* 输出口 */
};/* 定义音频路径（路由） */
static const struct snd_soc_dapm_route vcodec_dapm_routes[] = {/* MIC 输入路径 */{"ADCL Input", "MIC1 Boost Switch", "MIC1"},{"ADCL", NULL, "ADCL Input"},{"Output Switch", "Output_mixer", "ADCL"},/* 如果有其他输入输出路径，在此添加 */{"ADC Output", NULL, "Output Switch"},
};

细心的你会发现，在DAPM中也定义了一些kcontrol，如下：

SOC_DAPM_SINGLE("MIC1 Boost Switch", VCODEC_MIC1_REG, 0, 1, 0),
SOC_DAPM_SINGLE("Output_mixer", VCODEC_Output_mixer_REG, 0, 1, 0),

DAPM的kcontrol是带有DAPM关键字的，而普通的kcontrol是不带DAPM关键字的，那么我们可以比较容易的推导出来，这个带了DAPM关键字的kcontrol要比普通的kcontrol要多做了一些事情，来实现DAPM的特征，这个具体带了什么功能，后续文章会继续讲解。

三、实验验证

3.1 验证环境

为了方便去验证DAPM，我这边直接在云服务器上面验证，我的云服务器的版本如下（你可以使用其他的云服务器，但是Linux Kernel需要是5.15左右）：

# uname -a
Linux 5.15.0-113-generic #123-Ubuntu SMP Mon Jun 10 08:16:17 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux# lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.4 LTS
Release:        22.04
Codename:       jammy

我搞的更多的是安卓方面的开发，这边搭建一个tinyasla的环境（如果你熟悉原生的Linux环境，比如aplay、amixer，也可以自行搭建自己熟悉的）：

git clone https://github.com/tinyalsa/tinyalsa
然后按照官方文档搭建：
make
sudo make install
sudo ldconfig

在云服务器上面，一般是关闭了音频模块的，手动打开一下，如果你使用实际的Ubuntu设备，是带有真实声卡的，可以不用下面的操作：

modprobe snd_soc_core

3.2 源码编译方法和加载ko

源码的编译，直接make就会生成ko：

make

生成结果：

# ls
codec.c  machine.c  Makefile  platform.c
# make
make -C /usr/src/linux-headers-5.15.0-113-generic M=`pwd` modules
make[1]: Entering directory '/usr/src/linux-headers-5.15.0-113-generic'CC [M]  /root/test_Asoc/new_ASOC/platform.oCC [M]  /root/test_Asoc/new_ASOC/codec.oCC [M]  /root/test_Asoc/new_ASOC/machine.oMODPOST /root/test_Asoc/new_ASOC/Module.symversCC [M]  /root/test_Asoc/new_ASOC/codec.mod.oLD [M]  /root/test_Asoc/new_ASOC/codec.koBTF [M] /root/test_Asoc/new_ASOC/codec.ko
Skipping BTF generation for /root/test_Asoc/new_ASOC/codec.ko due to unavailability of vmlinuxCC [M]  /root/test_Asoc/new_ASOC/machine.mod.oLD [M]  /root/test_Asoc/new_ASOC/machine.koBTF [M] /root/test_Asoc/new_ASOC/machine.ko
Skipping BTF generation for /root/test_Asoc/new_ASOC/machine.ko due to unavailability of vmlinuxCC [M]  /root/test_Asoc/new_ASOC/platform.mod.oLD [M]  /root/test_Asoc/new_ASOC/platform.koBTF [M] /root/test_Asoc/new_ASOC/platform.ko
Skipping BTF generation for /root/test_Asoc/new_ASOC/platform.ko due to unavailability of vmlinux
make[1]: Leaving directory '/usr/src/linux-headers-5.15.0-113-generic'
# ls
codec.c        codec.mod.c       codec.o       machine.ko       .machine.mod.cmd    .machine.o.cmd      Module.symvers       .platform.ko.cmd   platform.mod.o
codec.ko       .codec.mod.cmd    .codec.o.cmd  .machine.ko.cmd  machine.mod.o       Makefile            .Module.symvers.cmd  platform.mod       .platform.mod.o.cmd
.codec.ko.cmd  codec.mod.o       .git          machine.mod      .machine.mod.o.cmd  modules.order       platform.c           platform.mod.c     platform.o
codec.mod      .codec.mod.o.cmd  machine.c     machine.mod.c    machine.o           .modules.order.cmd  platform.ko          .platform.mod.cmd  .platform.o.cmd
#

加载ko（注意machine.ko一定是最后加载的，因为是在machine.ko会注册声卡，dai link依赖前面两个ko）：

# insmod codec.ko
# insmod platform.ko
# insmod machine.ko
# cat /proc/asound/pcm
00-00: MY-CODEC my_codec.0-0 :  : playback 1 : capture 1
#

通过cat /proc/asound/pcm我们可以看到声卡已经加载成功了。

3.3 实验观察一下现象

根据我们的源码，我们会注册三个控件，一个是普通的kcontrol，两个是DAMP类的kcontrol，可以输入命令查看一下：

# tinymix contents
Number of controls: 3
ctl     type    num     name                                            device  value
0       ENUM    1       Get Audio reg                                   0> VCODEC_ADCL_REG, VCODEC_MIC1_REG, VCODEC_Output_mixer_REG,
1       BOOL    1       ADCL Input MIC1 Boost Switch                    0Off
2       BOOL    1       Output Switch Output_mixer                      0Off
#