Linux声卡驱动(3)——DAPM

一、DAPM简介

  DAPM是Dynamic Audio Power Management的缩写,直译过来就是动态音频电源管理的意思,DAPM是为了使基于linux的移动设备上的音频子系统,在任何时候都工作在最小功耗状态下。DAPM对用户空间的应用程序来说是透明的,所有与电源相关的开关都在ASoc core中完成。DAPM根据当前激活的音频流(playback/capture)和声卡中的mixer等的配置来决定那些音频控件的电源开关被打开或关闭。


二、DAPM的抽象

1. kcontrol
  通常,一个kcontrol代表着一个mixer(混音器),或者是一个mux(多路开关),又或者是一个音量控制器等等。定义一个kcontrol主要就是定义一个snd_kcontrol_new结构.对于每个控件,都需要定义一个和他对应的snd_kcontrol_new结构,这些snd_kcontrol_new结构会在声卡的初始化阶段,通过snd_soc_add_codec_controls()注册到系统中,用户空间就可以通过amixer或alsamixer(Linux ala-slib)或tinymix(Android tinyAlsa)等工具查看和设定这些控件的状态。

定义控件使用的宏举例:
SOC_SINGLE 简单型的控件
SOC_SINGLE_TLV 是SOC_SINGLE的一种扩展,主要用于定义那些有增益控制的控件,例如音量控制器,EQ均衡器等等。
SOC_DOUBLE 与SOC_SINGLE相对应,区别是SOC_SINGLE只控制一个变量,而SOC_DOUBLE则可以同时在一个寄存器中控制两个相似的变量,最常用的就是用于一些立体声的控件,需要同时对左右声道进行控制的情况,因为多了一个声道,参数也就相应地多了一个shift位移值。

SOC_SINGLE_EXT 像这样的后面带_EXT的可以指定自己的put和get成员回调函数而不是默认的。

这些宏中使用soc_mixer_control结构来描述mixer控件的寄存器信息,soc_enum结构来描述mux控件的寄存器信息。

用户空间对kcontrol的修改,最终都会调用到kcontrol的put回调函数。

2. widget

  音频控件单元抽象为kcontrol,DAPM的基本单元是widget,使用snd_soc_dapm_widget结构表示,它是对kcontrol进一步的封装,是kcontrol和开关(有的是组件前面的Switch和组件组成一个widget,有的是后面的)的组合体。

  一个widget用snd_soc_dapm_widget结构体来描述,通常,会根据音频硬件的组成,分别在声卡的codec驱动、platform驱动和machine驱动中定义一组widget,这些widget用数组进行组织,我们一般会使用dapm框架提供的大量的辅助宏来定义这些widget数组。

  widget把kcontrol和动态电源管理进行了有机的结合,同时还具备音频路径的连结功能,一个widget可以与它相邻的widget有某种动态的连结关系。

  widget所包含的kcontrol与普通的kcontrol有所不同,它们的定义方法与标准的kcontrol也有所不同。普通snd_kcontrol_new结构可以使用宏例如SOC_SINGLE("ALC Max Gain", WM8960_ALC1, 4, 7, 0)进行初始化,而widget的snd_kcontrol_new结构使用SOC_DAPM_SINGLE("LINPUT2 Switch", WM8960_LINPATH, 6, 1, 0)初始化,区别是初始化回调函数不同。

SoC动态音频电源管理,最多可以拥有4个电源域的宏来初始化snd_kcontrol_new结构
(1). Codec domain - VREF,VMID通常在codec的probe/remove时控制。但如果侧音不需要上电,可以在stream time设置。
(2). Platform/Machine domain - 物理的输入和输出连接是平台/机器和用户操作特定的,在Machine驱动程序和用户空间中设置,例如插入HP时的处理。
(3). Path domain - 在用户更改混音器(mix)和多路复用器(mux)设置时自动设置内部编解码器路径混合器。
(4). Stream domain - DAC和ADC。 启用流playback/capture时启用。
从soc-dapm.h中宏的reg看出,只有Path domain和Stream domain宏中指定了电源管理寄存器。

  一个电源域对应一个dapm context,使用snd_soc_dapm_context结构表示。属于codec中的widget位于一个dapm context中;属于platform的widget位于一个dapm context中;属于整个声卡的widget位于一个dapm context中。
  对于音频系统的硬件来说,通常要提供合适的偏置电压才能正常地工作,有了dapm context这种组织方式,我们可以方便地对同一组widget进行统一的偏置电压管理。
  snd_soc_dapm_context被实体内嵌到代表codec(snd_soc_codec )、platform(snd_soc_platform )、card(snd_soc_card )、dai(snd_soc_dai )的结构体中:

定义麦克风,耳机,扬声器,线路输入接口这几种widget,还可以定义一个dapm事件回调函数wevent,因为其是外接设备,提供回调用于事件通知。
/* codec domain */
SND_SOC_DAPM_VMID(wname)

/* platform domain */
SND_SOC_DAPM_INPUT(wname)
SND_SOC_DAPM_OUTPUT(wname)
SND_SOC_DAPM_MIC(wname, wevent)
SND_SOC_DAPM_HP(wname, wevent)
SND_SOC_DAPM_SPK(wname, wevent)
SND_SOC_DAPM_LINE(wname, wevent)

  如果需要自定义这些widget的dapm事件处理回调函数,也可以使用下面这些带“_E”后缀的版本,eg: SND_SOC_DAPM_PGA_E,这类的宏可以指定event_flag用于表示对哪些事件感兴趣。

  为了防止pop-pop声,需要用户程序关注各个widget上电和下电的顺序。各个widget的上下电次序表示在两个全局数组dapm_up_seq/dapm_down_seq 中。消pop音延时的时长导出到debugfs了,文件名为dapm_pop_time


dai widget应该是用于抽象Soc的dai接口到path中:
  dai widget又分为cpu dai widget和codec dai widget,它们在machine驱动分别匹配上相应的codec和platform后,由soc_probe_platform和soc_probe_codec这两个函数通过调用dapm的api函数snd_soc_dapm_new_dai_widgets()来创建的,通常会为playback和capture各自创建一个dai widget,他们的类型分别是:
  snd_soc_dapm_dai_in 对应playback dai
  snd_soc_dapm_dai_out 对应capture dai
另外,dai widget的名字是使用stream name来命名的,他通常来自snd_soc_dai_driver中的stream_name字段。dai widget的sname字段也使用同样的名字。

dai widget和stream widget是通过stream name进行匹配的

用struct snd_soc_pcm_stream表示,Codec驱动中的struct snd_soc_dai_driver结构中动态指定playback/capture两个stream widget。

  把dai widget和stream widget连接在一起,就是为了能把ASoc中的pcm处理部分和dapm进行关联,pcm的处理过程中,会通过发出stream event来通知dapm系统,重新扫描并调整音频路径上各个widget的电源状态。

  因为dai widget和codec上的stream widget是相连的,所以,dai widget的激活状态改变,会沿着音频路径传递到路径上的所有widget,等dapm_power_widgets返回后,如果发出的是SND_SOC_DAPM_STREAM_START事件,路径上的所有widget会处于上电状态,保证音频数据流的顺利播放,如果发出的是SND_SOC_DAPM_STREAM_STOP事件,路径上的所有widget会处于下电状态,保证最小的功耗水平。

 

3. route

route用于指定两个widget之间的连接关系,使用snd_soc_dapm_route结构表示,通常,所有的路径信息会用一个snd_soc_dapm_route结构数组来定义。和widget一样,路径信息也分别存在与codec驱动,machine驱动和platform驱动中。

snd_soc_dapm_route在定义的时候若是两个widget之间是直连的,没有经过开关Switch,那么kcontrol字符串就初始化为NULL。

 

4. path

route注册后被解析成path,使用snd_soc_dapm_path结构表示。kcontrol和widget都可以通过静态定义。但是path只能通过route解析而来。

一个path表示一段连接,至少包含:source widget,跳线path,sink widget。在DAPM中,用snd_soc_dapm_route结构来描述这样一个连接关系。


5. complete path

  dapm要给一个widget上电的其中一个前提条件是:这个widget位于一条完整的音频路径上,而一条完整的音频路径的两头,必须是输入/输出端,或者是一个外部音频设备,又或者是一个处于激活状态的音频流widget。分别用is_connected_output_ep()和is_connected_input_ep()得到该widget是否有同时连接到一个输入端和一个输出端,如果是,返回1来表示该widget需要上电。

在扫描dapm_dirty链表时,dapm使用两个链表来分别保存需要上电和需要下电的widget,扫描完毕后按照上电次序,统一对各个widget上电。
up_list 保存需要上电的widget
down_list 保存需要下电的widget。

 

三、参考

ALSA声卡驱动中的DAPM详解之一:kcontrol
ALSA声卡驱动中的DAPM详解之二:widget-具备路径和电源管理信息的kcontrol
ALSA声卡驱动中的DAPM详解之三:如何定义各种widget
ALSA声卡驱动中的DAPM详解之四:在驱动程序中初始化并注册widget和route
ALSA声卡驱动中的DAPM详解之五:建立widget之间的连接关系
ALSA声卡驱动中的DAPM详解之六:精髓所在,牵一发而动全身
ALSA声卡驱动中的DAPM详解之七:dapm事件机制(dapm event)

 

猜你喜欢

转载自www.cnblogs.com/hellokitty2/p/10924332.html