第三章：ASoC框架详解

好，咱们今天聊聊ASoC。这个框架，说白了就是Linux内核为了搞定嵌入式音频而搞的一套标准化方案。我在三星和高通干了这么多年，几乎天天跟它打交道。你想想看，如果没有ASoC，每个音频驱动都得自己从头造轮子，那得多痛苦？

ASoC核心思想：Codec / Platform / DAI

ASoC把音频子系统拆成了三个角色：Codec、Platform、DAI。这个设计我个人觉得非常优雅，各司其职，互不干扰。

• Codec：负责音频编解码、音量控制、混音等模拟域操作。比如WM8994、ALC5651这些芯片。
• Platform：负责数字域的音频数据传输，说白了就是DMA、I2S控制器这些。Exynos的DMA引擎就属于这一块。
• DAI：数字音频接口，连接Codec和Platform的桥梁。I2S、PCM、TDM都属于DAI。

我在项目中遇到过一个问题：某个Codec驱动里把音量控制写死了，结果Platform那边怎么调都没用。后来发现是Codec的寄存器映射搞错了。嗯，这里要注意，Codec和Platform的职责边界一定要清晰，别越界。

DAPM：动态音频电源管理

DAPM，全称Dynamic Audio Power Management。这玩意儿是ASoC最牛的地方之一。它可以根据音频路径的连通状态，自动开关电源域。说白了，就是没用的模块就断电，省电。

为什么会这样？因为嵌入式设备对功耗极其敏感。你想想看，手机播放音乐时，如果整个音频子系统都上电，那电池撑不了多久。DAPM就是来解决这个问题的。

DAPM的核心是音频路径。它把Codec内部的各个模块（比如DAC、ADC、Mixer、PGA）看作节点，节点之间有连接线。当一条音频路径被激活时，路径上的所有节点都会自动上电；路径断开时，节点自动下电。

我曾经踩过一个坑：某个Codec的DAPM widget定义错了，导致播放音乐时某个PGA没上电，声音出不来。查了两天才发现是widget的注册顺序有问题。嗯，DAPM的widget注册顺序很重要，一定要按照信号流向从输入到输出依次注册。

Machine Driver编写

Machine Driver是ASoC里最灵活的部分。它负责把Codec、Platform、DAI绑定在一起，形成一个完整的音频设备。说白了，就是搭积木。

一个典型的Machine Driver需要做以下几件事：

1. 定义DAI链路（dai_link），指定Codec和Platform的匹配关系。
2. 配置音频时钟和PLL参数。
3. 注册平台设备，绑定Codec和Platform驱动。
4. 实现ops回调函数，比如hw_params、startup、shutdown等。

我个人的习惯是，先写好dai_link数组，再写ops回调。这样结构清晰，不容易乱。

下面是一个简化的Machine Driver示例，基于Exynos平台：

static struct snd_soc_dai_link exynos_audio_dai_links[] = {
    {
        .name = "WM8994",
        .stream_name = "WM8994 HiFi",
        .cpu_dai_name = "exynos-i2s.0",
        .codec_dai_name = "wm8994-aif1",
        .platform_name = "exynos-dma.0",
        .codec_name = "wm8994-codec.0",
        .ops = &exynos_audio_ops,
    },
};

static struct snd_soc_card exynos_audio_card = {
    .name = "Exynos Audio Card",
    .owner = THIS_MODULE,
    .dai_link = exynos_audio_dai_links,
    .num_links = ARRAY_SIZE(exynos_audio_dai_links),
};

static int exynos_audio_probe(struct platform_device *pdev)
{
    struct snd_soc_card *card = &exynos_audio_card;
    card->dev = &pdev->dev;
    return devm_snd_soc_register_card(&pdev->dev, card);
}

你看，代码其实不复杂。但要注意，cpu_dai_name和codec_dai_name必须和设备树中的节点名完全一致。我曾经因为少写了一个下划线，导致驱动加载失败，查了半天。

避坑指南

我总结几个常见的坑，你写驱动时注意一下：

• 时钟配置：Codec和Platform的时钟必须匹配。我遇到过MCLK频率不对，导致音频采样率偏移的情况。
• DAPM路径：一定要检查所有widget的连接关系。漏掉一个，音频路径就可能断掉。
• 设备树匹配：Machine Driver的compatible属性必须和设备树中的节点匹配。否则驱动根本不会加载。

我曾经在Exynos 5422平台上调试音频，发现播放时左声道没声音。查了三天，最后发现是DAPM路径里少了一条连接线。嗯，从那以后我写DAPM路径时都会画个图，确保每个节点都连上了。

总结

ASoC框架的核心就是Codec、Platform、DAI这三个角色，加上DAPM这个省电利器。Machine Driver则是把它们串起来的胶水代码。你只要理解了这几个概念，写音频驱动就会轻松很多。

下一章我会讲音频DSP的底层开发，包括Exynos的ABOX和Qualcomm的ADSP。到时候咱们再细聊。