【软件框架】
在对要做的事情一无所知的时候，从全局看看系统的拓扑图对我们认识新事物有很大的帮助。Audio 部分的驱动程序框架如下图所示：
这幅图明显地分为 3 级。
上方蓝色系的 ALSA Kernel 整体属于Linux Kernel，是原生Linux 操作系统的一部分，其中又分出 ASoC Core 和 PCM Core 两级，和她们相关的代码都可以直接在 Linux 源码中找到。
中间淡红色的部分看名字就知道和驱动相关，分为左右 2 条支线。需要注意的是左侧支线由 ASoC 派生而来，而 ASoC 虽本质上属于 ALSA，但在代码上将各部分驱动进行分离设计，也就是这里看到的 Platform Driver、Machine Driver、Codec Driver，分别对应 CPU 驱动、板驱动、编解码芯片驱动。这种架构增强了 CPU 芯片驱动和编解码芯片驱动的可移植性，让我们在开发音频驱动时只需要重新编写电路板相关的板驱动即可。进一步分析，紧接 Platform Driver 后面是 SST Driver，这个 SST 即 Smart Sound Technology，是 Intel 自研的技术，所以这部分结构不一定适用于其它 CPU 芯片，但一旁的 DMA Driver 却是所有 CPU 驱动都必须包含的，因为音频的实质是数据；Codec Driver 之后是 I2C 驱动，对于编解码芯片寄存器的读写都是通过 I2C 总线实现。右侧支线从 PCM Core 引出，这部分我目前还不熟悉，从框图和字面意思上看是和高清音频接口相关的，直接通过 ALSA 的 PCM 机制进行操作并且在硬件上使用专门的 HDMI 控制器而非编解码芯片。
下方灰色一级是最底层的硬件部分，依次为 CPU 内嵌的 DSP 模块、独立的编解码芯片、独立的 HDMI 控制器。在 DSP 与 Codec 之间存在音频数据传输，虽然在图中没有注明，但我们知道这是通过 I2S 总线实现的。在我的实际项目中，DSP 模块集成在编解码芯片中。
无疑，编解码芯片驱动，也即 Codec Driver 部分是我们编写音频驱动的核心。负责对内驱动芯片实现设备/驱动正常注册，对外沟通 DSP 进行音频数据交换。所以下文以此为中心进行代码分析。
【源码文件架构】
按照 ASoC 框架的设计理念，源码文件应该分为 3 个部分，分别是 Platform Driver、Machine Driver、Codec Driver，这 3 者为并行关系，各对应一份源码。其中，Platform Driver 相关的源码主要实现 DMA 功能和 DAI，即 DSP 模块的 I2S 数据传输功能，并导出相应变量或操作函数接口；Codec Driver 相关的源码主要实现 I/O 控制、DAPM 和 PCM 配置，并导出相应变量或操作函数接口；Machine Driver 相关的源码则将前 2 个文件中导出的接口绑定在一起。内核启动后，以模块的形式加载 3 个驱动。
在我的实际项目中，文件 rt5677.c 中是 Codec Driver 部分的源码，文件 cht_rt5677.c 中则为 Machine Driver 部分的源码。前者实现编解码芯片的寄存器配置、设备/驱动创建与注册，后者实现将 Machine 与 Platform 绑定。
【Machine Driver 代码分析】
既然驱动是以模块的形式载入的，那么我们就从模块初始化函数开始阅读代码。
模块初始化函数部分的代码为 late_initcall(snd_cht_driver_init);
查看 snd_cht_driver_init() 函数：
static int __init snd_cht_driver_init(void)
{
…
return platform_driver_register(&snd_cht_mc_driver);
}
原来是注册 platform 驱动，接下来的流程应该就比较熟悉了。
结构体snd_cht_mc_driver 的定义如下：
static struct platform_driver snd_cht_mc_driver = {
.driver = {
.owner = THIS_MODULE,
.name = "cht_rt5677",
.pm = &snd_cht_mc_pm_ops,
},
.probe = snd_cht_mc_probe, // 绑定 probe() 函数
.remove = snd_cht_mc_remove,
.shutdown = snd_cht_mc_shutdown,
};
这里的 probe 函数 snd_cht_mc_probe() 会在平台驱动注册过程中被调用。查看该函数代码：
static int snd_cht_mc_probe(struct platform_device *pdev)
{
…
/* register the soc card */
snd_soc_card_cht.dev = &pdev->dev;
ret_val = snd_soc_register_card(&snd_soc_card_cht); // 注册声卡
…
platform_set_drvdata(pdev,&snd_soc_card_cht); // 设定声卡信息
codec = cht_get_codec(&snd_soc_card_cht);
// use gpio GPIO_SPK_EN to enable/disable ext boost pa
gpio_request(GPIO_SPK_EN, "speaker boost pa ctl");
gpio_direction_output(GPIO_SPK_EN, 0);
…
return ret_val;
}
其中 snd_soc_register_card() 是ASoC Core 中的函数，由Linux 内核实现，功能是创建和注册一个声卡设备。而函数 platform_set_drvdata() 的功能是将预设的声卡结构体值配置到 machine driver。追踪 snd_soc_card_cht 这个结构体，其定义如下：
/* SoCcard */
static struct snd_soc_card snd_soc_card_cht = {
.name = "cherrytrailaud",
.dai_link = cht_dailink, // 绑定 dai_link
.num_links = ARRAY_SIZE(cht_dailink),
.set_bias_level = cht_set_bias_level,
.dapm_widgets = cht_dapm_widgets, // 绑定 dapm_widgets
.num_dapm_widgets = ARRAY_SIZE(cht_dapm_widgets),
.dapm_routes = cht_audio_map,
.num_dapm_routes = ARRAY_SIZE(cht_audio_map),
.controls = cht_mc_controls, // 绑定 controls
.num_controls = ARRAY_SIZE(cht_mc_controls),
};
在这里我们看到了 cht_dailink 数组、cht_dapm_widgets() 数组、cht_mc_controls 数组。后 2 者主要实现 DAPM 相关操作，我们重点查看 cht_dailink，该数组核心部分代码如下：
static struct snd_soc_dai_link cht_dailink[] = {
[CHT_DPCM_AUDIO] = {
.name = "Cherrytrail Audio Port",
.stream_name = "Cherrytrail Audio",
.cpu_dai_name = "Headset-cpu-dai",
.codec_name = "snd-soc-dummy",
.codec_dai_name = "snd-soc-dummy-dai",
.platform_name = "sst-platform",
.init = cht_audio_init, // 绑定 init() 函数
.ignore_suspend = 1,
.dynamic = 1,
.ops = &cht_aif1_ops,
.dpcm_playback = 1,
},
…
};
初始化函数 cht_audio_init() 在第 1 个 cht_dailink 元素中被绑定。至此，Machine Driver 相关代码的分析就完成了。
