📚 课程目录第4章 ASoC框架深度解析

4、ASoC框架深度解析：三大组件与DAPM机制

ASoC（ALSA System on Chip）是嵌入式Linux音频驱动的核心框架。说实话，我刚接触它的时候也觉得头大——又是Codec又是Platform，还有DAPM那一堆路径控制。但搞明白之后你会发现，这套设计其实非常优雅。

咱们先看一张整体架构图，心里有个谱：

4.1 三大组件：各司其职

ASoC把音频驱动拆成三个独立模块。为什么要拆？因为嵌入式平台的SoC和Codec芯片往往来自不同厂商，耦合在一起就乱套了。

4.1.1 Codec Driver

Codec驱动管理音频编解码芯片本身。它负责DAC/ADC、混音器、增益控制、输入输出选择这些硬件功能。

我早期做过一个项目，Codec芯片的寄存器手册有400多页。嗯，这时候你就知道为什么需要ASoC帮你抽象了。

Codec驱动的核心结构体是 snd_soc_codec_driver，里面包含：

struct snd_soc_codec_driver {
    // 编解码器控制函数
    int (*probe)(struct snd_soc_codec *codec);
    int (*remove)(struct snd_soc_codec *codec);
    
    // 寄存器读写（必须实现）
    int (*read)(struct snd_soc_codec *codec, unsigned int reg);
    int (*write)(struct snd_soc_codec *codec, unsigned int reg, unsigned int value);
    
    // DAPM widget 和 route 定义
    const struct snd_soc_dapm_widget *dapm_widgets;
    int num_dapm_widgets;
    const struct snd_soc_dapm_route *dapm_routes;
    int num_dapm_routes;
    
    // 控件定义
    const struct snd_kcontrol_new *controls;
    int num_controls;
};

个人习惯：我写Codec驱动时，会先把所有寄存器地址用宏定义好，再写读写函数。这样后面加DAPM widget时，填寄存器地址直接引用宏，不容易写错。

4.1.2 Platform Driver

Platform驱动处理SoC这一侧的音频接口。说白了就是CPU怎么把音频数据送给Codec。常见的包括I2S、PCM、AC97这些数字音频接口，还有DMA引擎。

Platform驱动的核心是 snd_soc_platform_driver：

struct snd_soc_platform_driver {
    // PCM 操作
    const struct snd_pcm_ops *ops;
    
    // DMA 配置
    struct snd_dmaengine_dai_dma_data *dma_data;
    
    // 组件探测
    int (*probe)(struct snd_soc_platform *platform);
};

我记得有一次调试I2S时钟，发现播放声音变调。查了半天，原来是Platform驱动里设置的采样率跟Codec侧不一致。这种问题用示波器看BCLK频率最直接。

4.1.3 Machine Driver

Machine驱动是胶水层。它把Codec和Platform绑在一起，告诉系统：这个Codec连在哪个DAI（数字音频接口）上，用哪条I2C总线控制，GPIO怎么配置。

Machine驱动的核心是 snd_soc_card 和 snd_soc_dai_link：

static struct snd_soc_dai_link my_dai_link = {
    .name = "MyCodec",
    .stream_name = "My Audio",
    .codec_dai_name = "wm8960-hifi",
    .codec_name = "wm8960.0-001a",
    .platform_name = "samsung-i2s",
    .cpu_dai_name = "samsung-i2s.0",
    .ops = &my_ops,
};

static struct snd_soc_card my_card = {
    .name = "MyBoard",
    .dai_link = &my_dai_link,
    .num_links = 1,
};

注意：Machine驱动里 codec_name 和 platform_name 必须跟设备树或板级文件里的名字完全一致。我曾经因为拼写错误，浪费了整整一个下午。

4.2 DAPM：动态音频电源管理

DAPM是ASoC最精妙的设计之一。它的核心思想是：只用给正在使用的音频路径供电。

你想想看，一个Codec芯片内部可能有多个ADC、DAC、混音器、功放。如果全部同时供电，功耗扛不住。DAPM会根据音频数据流的方向，自动开关对应的电源域。

4.2.1 DAPM Widget

Widget是DAPM的基本单元。每个widget代表一个硬件模块，比如“左声道DAC”、“右声道ADC”、“扬声器功放”。

常见的widget类型：

Widget类型	宏定义	说明
输入引脚	SND_SOC_DAPM_INPUT	外部信号进入Codec
输出引脚	SND_SOC_DAPM_OUTPUT	信号输出到外部
混音器	SND_SOC_DAPM_MIXER	多路信号混合
DAC	SND_SOC_DAPM_DAC	数字转模拟
ADC	SND_SOC_DAPM_ADC	模拟转数字
功放	SND_SOC_DAPM_PGA	可编程增益放大器
电源域	SND_SOC_DAPM_SUPPLY	供电节点

定义widget的示例：

static const struct snd_soc_dapm_widget my_widgets[] = {
    SND_SOC_DAPM_INPUT("Mic Jack"),
    SND_SOC_DAPM_ADC("Left ADC", "HiFi Capture", WM8960_PWR1, 2, 0),
    SND_SOC_DAPM_DAC("Left DAC", "HiFi Playback", WM8960_PWR2, 6, 0),
    SND_SOC_DAPM_PGA("Speaker PGA", SND_SOC_NOPM, 0, 0, NULL, 0),
    SND_SOC_DAPM_OUTPUT("Speaker"),
};

4.2.2 DAPM Route

Route定义widget之间的连接关系。DAPM根据这些连接，决定哪些widget需要上电。

static const struct snd_soc_dapm_route my_routes[] = {
    // 录音路径
    {"Left ADC", NULL, "Mic Jack"},
    
    // 播放路径
    {"Speaker PGA", NULL, "Left DAC"},
    {"Speaker", NULL, "Speaker PGA"},
};

这里有个关键点：DAPM是事件驱动的。当用户开始录音时，DAPM会沿着路径反向追溯，把“Mic Jack → Left ADC”路径上的所有widget依次上电。停止录音时再依次下电。

避坑指南：我曾经在调试一个项目时，发现录音有爆音。查了两天才发现，是DAPM上电顺序不对——ADC还没稳定，数据就开始采集了。解决方案是在widget定义里加上 SND_SOC_DAPM_POST_PMU 延迟事件。

4.3 音频路径与kcontrol绑定

DAPM自动管理电源，但用户还需要手动控制一些开关——比如选择麦克风输入还是线路输入，调节音量大小。这些控制就是kcontrol。

kcontrol通过 snd_kcontrol_new 结构体定义：

static const struct snd_kcontrol_new my_controls[] = {
    SOC_SINGLE("Speaker Volume", WM8960_LOUT1, 0, 127, 0),
    SOC_ENUM("Mic Select", mic_enum),
};

但这里有个容易混淆的地方：kcontrol和DAPM widget是什么关系？

简单说：

DAPM widget 管理电源——决定哪个模块供电
kcontrol 管理参数——决定音量大小、输入选择
两者通过 mixer控件 绑定在一起

举个例子，一个混音器widget可以包含多个kcontrol：

// 定义混音器控件
static const struct snd_kcontrol_new my_mixer_controls[] = {
    SOC_DAPM_SINGLE("Mic Playback Switch", WM8960_MIXER, 0, 1, 0),
    SOC_DAPM_SINGLE("Line Playback Switch", WM8960_MIXER, 1, 1, 0),
};

// 定义混音器widget，绑定上面的控件
SND_SOC_DAPM_MIXER("Output Mixer", SND_SOC_NOPM, 0, 0, 
                   my_mixer_controls, ARRAY_SIZE(my_mixer_controls)),

当用户通过amixer关闭“Mic Playback Switch”时，DAPM会检测到这条路径断开，自动把Mic相关的ADC下电。这就是kcontrol和DAPM绑定的精髓。

调试技巧：用 amixer contents 查看所有kcontrol的状态。用 cat /sys/kernel/debug/asoc/codec_reg 查看Codec寄存器实时值。这两个命令是我调试音频路径的标配。

4.4 小结

ASoC三大组件各管一摊：Codec管芯片、Platform管接口、Machine管连线。DAPM在这之上做智能电源管理，kcontrol给用户提供操作入口。

搞懂这套体系，你写音频驱动时就不会觉得无从下手了。先确定Machine层怎么连，再写Codec的widget和route，最后用kcontrol暴露控制接口。按这个顺序来，思路会清晰很多。