【软件框架】     在对要做的事情一无所知的时候，从全局看看系统的拓扑图对我们认识新事物有很大的帮助。Audio 部分的驱动程序框架如下图所示：     这幅图明显地分为 3 级。     上方蓝 {MOD}系的 ALSA Kernel 整体属于Linux Kernel，是原生Linux 操作系统的一部分，其中又分出 ASoC Core 和 PCM Core 两级，和她们相关的代码都可以直接在 Linux 源码中找到。     中间淡红 {MOD}的部分看名字就知道和驱动相关，分为左右 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 控制器而非编解码芯片。     下方灰 {MOD}一级是最底层的硬件部分，依次为 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 相关代码的分析就完成了。