上一篇文章中，我们介绍了音频驱动中对基本控制单元的封装：kcontrol。利用kcontrol，我们可以完成对音频系统中的mixer，mux，音量控制，音效控制，以及各种开关量的控制，通过对各种kcontrol的控制，使得音频硬件能够按照我们预想的结果进行工作。同时我们可以看到，kcontrol还是有以下几点不足：
/*****************************************************************************************************/
声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！
/*****************************************************************************************************/
为此，DAPM框架正是为了要解决以上这些问题而诞生的，DAPM目前已经是ASoc中的重要组成部分，让我们先从DAPM的数据结构开始，了解它的设计思想和工作原理。
文章的开头，我们说明了一下目前kcontrol的一些不足，而DAPM框架为了解决这些问题，引入了widget这一概念，所谓widget，其实可以理解为是kcontrol的进一步升级和封装，她同样是指音频系统中的某个部件，比如mixer，mux，输入输出引脚，电源供应器等等，甚至，我们可以定义虚拟的widget，例如playback stream widget。widget把kcontrol和动态电源管理进行了有机的结合，同时还具备音频路径的连结功能，一个widget可以与它相邻的widget有某种动态的连结关系。在DAPM框架中，widget用结构体snd_soc_dapm_widget来描述：
struct snd_soc_dapm_widget {
enum snd_soc_dapm_type id;
const char *name; /* widget name */
......
/* dapm control */
int reg; /* negative reg = no direct dapm */
unsigned char shift; /* bits to shift */
unsigned int value; /* widget current value */
unsigned int mask; /* non-shifted mask */
......
int (*power_check)(struct snd_soc_dapm_widget *w);
int (*event)(struct snd_soc_dapm_widget*, struct snd_kcontrol *, int);
/* kcontrols that relate to this widget */
int num_kcontrols;
const struct snd_kcontrol_new *kcontrol_news;
struct snd_kcontrol **kcontrols;
/* widget input and outputs */
struct list_head sources;
struct list_head sinks;
......
};id 该widget的类型值，比如snd_soc_dapm_output，snd_soc_dapm_mixer等等。
*name 该widget的名字
*sname 代表该widget所在stream的名字，比如对于snd_soc_dapm_dai_in类型的widget，会使用该字段。
*codec *platform 指向该widget所属的codec和platform。
list 所有注册到系统中的widget都会通过该list，链接到代表声卡的snd_soc_card结构的widgets链表头字段中。
*dapm snd_soc_dapm_context结构指针，ASoc把系统划分为多个dapm域，每个widget属于某个dapm域，同一个域代表着同样的偏置电压供电策略，比如，同一个codec中的widget通常位于同一个dapm域，而平台上的widget可能又会位于另外一个platform域中。
*priv 有些widget可能需要一些专有的数据，可以使用该字段来保存，像snd_soc_dapm_dai_in类型的widget，会使用该字段来记住与之相关联的snd_soc_dai结构指针。
*regulator 对于snd_soc_dapm_regulator_supply类型的widget，该字段指向与之相关的regulator结构指针。
*params 目前对于snd_soc_dapm_dai_link类型的widget，指向该dai的配置信息的snd_soc_pcm_stream结构。
reg shift mask 这3个字段用来控制该widget的电源状态，分别对应控制信息所在的寄存器地址，位移值和屏蔽值。
value on_val off_val 电源状态的当前只，开启时和关闭时所对应的值。
power invert 用于指示该widget当前是否处于上电状态，invert则用于表明power字段是否需要逻辑反转。
active connected 分别表示该widget是否处于激活状态和连接状态，当和相邻的widget有连接关系时，connected位会被置1，否则置0。
new 我们定义好的widget（snd_soc_dapm_widget结构），在注册到声卡中时需要进行实例化，该字段用来表示该widget是否已经被实例化。
ext 表示该widget当前是否有外部连接，比如连接mic，耳机，喇叭等等。
force 该位被设置后，将会不管widget当前的状态，强制更新至新的电源状态。
ignore_suspend new_power power_checked 这些电源管理相关的字段。
subseq 该widget目前在上电或下电队列中的排序编号，为了防止在上下电的过程中出现pop-pop声，DAPM会给每个widget分配合理的上下电顺序。
*power_check 用于检查该widget是否应该上电或下电的回调函数指针。
event_flags 该字段是一个位或字段，每个位代表该widget会关注某个DAPM事件通知。只有被关注的通知事件会被发送到widget的事件处理回调函数中。
*event DAPM事件处理回调函数指针。
num_kcontrols *kcontrol_news **kcontrols 这3个字段用来描述与该widget所包含的kcontrol控件，例如一个mixer控件或者是一个mux控件。
sources sinks 两个链表字段，两个widget如果有连接关系，会通过一个snd_soc_dapm_path结构进行连接，sources链表用于链接所有的输入path，sinks链表用于链接所有的输出path。
power_list 每次更新整个dapm的电源状态时，会根据一定的算法扫描所有的widget，然后把需要变更电源状态的widget利用该字段链接到一个上电或下电的链表中，扫描完毕后，dapm系统会遍历这两个链表执行相应的上电或下电操作。
dirty 链表字段，widget的状态变更后，dapm系统会利用该字段，把该widget加入到一个dirty链表中，稍后会对dirty链表进行扫描，以执行整个路径的更新。
inputs 该widget的所有有效路径中，连接到输入端的路径数量。
outputs 该widget的所有有效路径中，连接到输出端的路径数量。
*clk 对于snd_soc_dapm_clock_supply类型的widget，指向相关联的clk结构指针。
以上我们对snd_soc_dapm_widget结构的各个字段所代表的意义一一做出了说明，这里只是让大家现有个概念，至于每个字段的详细作用，我们会在以后相关的章节中提及。
在DAPM框架中，把各种不同的widget划分为不同的种类，snd_soc_dapm_widget结构中的id字段用来表示该widget的种类，可选的种类都定义在一个枚举中：
/* dapm widget types */
enum snd_soc_dapm_type {......}
之前已经提到，一个widget是有输入和输出的，而且widget之间是可以动态地进行连接的，那它们是用什么来连接两个widget的呢？DAPM为我们提出了path这一概念，path相当于电路中的一根跳线，它把一个widget的输出端和另一个widget的输入端连接在一起，path用snd_soc_dapm_path结构来描述：
struct snd_soc_dapm_path {
const char *name;
/* source (input) and sink (output) widgets */
struct snd_soc_dapm_widget *source;
struct snd_soc_dapm_widget *sink;
struct snd_kcontrol *kcontrol;
/* status */
u32 connect:1; /* source and sink widgets are connected */
u32 walked:1; /* path has been walked */
u32 walking:1; /* path is in the process of being walked */
u32 weak:1; /* path ignored for power management */
int (*connected)(struct snd_soc_dapm_widget *source,
struct snd_soc_dapm_widget *sink);
struct list_head list_source;
struct list_head list_sink;
struct list_head list;
};
图1 widget通过path进行连接
另外，snd_soc_dapm_path结构的list字段用于把所有的path注册到声卡中，其实就是挂在snd_soc_card结构的paths链表头字段中。如果你要自己定义方法来检查path的当前连接状态，你可以提供自己的connected回调函数指针。
connect，walked，walking，weak是几个辅助字段，用于帮助所有path的遍历。
通过上一节的内容，我们知道，一个路径的连接至少包含以下几个元素：起始端widget，跳线path，到达端widget，在DAPM中，用snd_soc_dapm_route结构来描述这样一个连接关系：
struct snd_soc_dapm_route {
const char *sink;
const char *control;
const char *source;
int (*connected)(struct snd_soc_dapm_widget *source,
struct snd_soc_dapm_widget *sink);
};这里直接使用名字字符串来描述连接关系，所有定义好的route，最后都要注册到dapm系统中，dapm会根据这些名字找出相应的widget，并动态地生成所需要的snd_soc_dapm_path结构，正确地处理各个链表和指针的关系，实现两个widget之间的连接，具体的连接代码分析，我们留到以后的章节中讨论。