linux ALSA 声卡驱动之Asoc架构中的Platform

Linux驱动之platform总线详解⽬录1、platform 总线简介1.1、Linux 驱动的分离和分层思想1.1.1、Linux 驱动的分离1.2、platform 平台驱动模型2、platform 框架2.1、platform 总线2.2、platform 驱动2.2.1、platform 驱动定义2.2.2、platform 驱动注册2.3、platform 设备2.3.1、platform 设备定义2.4、platform 匹配过程3、总结1、platform 总线简介1.1、Linux 驱动的分离和分层思想1.1.1、Linux 驱动的分离先讲 Linux 驱动的分离，Linux 操作系统⽀持在各类 CPU 上运⾏，因为每⼀种 CPU 对设备的驱动不⼀样，这样就造成了Linux 内核中积累了⼤量代码，并且这些代码关于同⼀设备的描述⼤致相同，这就使得内核代码很冗余。

以 CPU 通过 I2C 控制 MPU6050 为例：从图可以看出每⼀种平台下都有⼀套主机驱动和⼀套设备驱动，因为每个平台的 I2C 控制器不同，所以这个主机驱动得每个平台配⼀个⾃⼰的，但⼤家所⽤的 MPU6050 是⼀样的，所以完全可以就共⽤⼀套设备驱动代码。

完善后框架如下：当然，这只是对于 I2C 下的 MPU6050 这个设备，实际情况下，I2C 下肯定会挂载很多设备，根据这个思路，我们可以得到框架为：⽽在实际开发中，I2C 主机驱动半导体⼚家会编写好，设备驱动也由设备⼚家编写好，我们只需要提供设备信息即可，如设备接到那个 I2C 接⼝上，I2C 速度为多少。

这样就相当于把设备信息从设备驱动中剥离出来，⽽设备驱动也会⽤标准⽅法去获取设备信息（如从设备树中获取设备信息）。

这样就相当于驱动只负责驱动，设备（信息）只负责设备，想办法将两者进⾏匹配即可，来做这个匹配⼯作的就是总线，这就构成了 Linux 中的总线-驱动-设备模型。

DAPM是Dynamic Audio Power Management的缩写，直译过来就是动态音频电源管理的意思，DAPM是为了使基于linux的移动设备上的音频子系统，在任何时候都工作在最小功耗状态下。

DAPM对用户空间的应用程序来说是透明的，所有与电源相关的开关都在ASoc core中完成。

用户空间的应用程序无需对代码做出修改，也无需重新编译，DAPM根据当前激活的音频流（playback/capture）和声卡中的mixer等的配置来决定那些音频控件的电源开关被打开或关闭。

/******************************************************************************************* **********/声明：本博内容均由/droidphone原创，转载请注明出处，谢谢！/******************************************************************************************* **********/DAPM控件是由普通的soc音频控件演变而来的，所以本章的内容我们先从普通的soc音频控件开始。

snd_kcontrol_new结构在正式讨论DAPM之前，我们需要先搞清楚ASoc中的一个重要的概念：kcontrol，不熟悉的读者需要浏览一下我之前的文章：Linux ALSA声卡驱动之四：Control设备的创建。

通常，一个kcontrol代表着一个mixer（混音器），或者是一个mux（多路开关），又或者是一个音量控制器等等。

从上述文章中我们知道，定义一个kcontrol主要就是定义一个snd_kcontrol_new 结构，为了方便讨论，这里再次给出它的定义：[cpp]view plaincopystruct snd_kcontrol_new {snd_ctl_elem_iface_t iface; /* interface identifier * /unsigned int device; /* device/client number * /unsigned int subdevice; /* subdevice (substream) number */const unsigned char *name; /* ASCII name of item */ unsigned int index; /* index of item */unsigned int access; /* access rights */unsigned int count; /* count of same elements */snd_kcontrol_info_t *info;snd_kcontrol_get_t *get;snd_kcontrol_put_t *put;union {1snd_kcontrol_tlv_rw_t *c;const unsigned int *p;} tlv;unsigned long private_value;};回到Linux ALSA声卡驱动之四：Control设备的创建中，我们知道，对于每个控件，我们需要定义一个和他对应的snd_kcontrol_new结构，这些snd_kcontrol_new结构会在声卡的初始化阶段，通过snd_soc_add_codec_controls函数注册到系统中，用户空间就可以通过amixer或alsamixer等工具查看和设定这些控件的状态。

LinuxALSA声卡驱动之⼋：ASoC架构中的Platform#define SND_SOC_DAIFMT_AC97 6 /* AC97 */#define SND_SOC_DAIFMT_PDM 7 /* Pulse density modulation */ bit 4-7 ⽤于设置接⼝时钟的开关特性：1. #def ine SND_SOC_DAIFMT_CONT (1 << 4) /* cont inuous clock */2. #def ine SND_SOC_DAIFMT_GAT ED (2 << 4) /* clock is gat ed */bit 8-11 ⽤于设置接⼝时钟的相位1. #def ine SND_SOC_DAIFMT_NB_NF (1 << 8) /* normal bit clock + f rame */2. #def ine SND_SOC_DAIFMT_NB_IF (2 << 8) /* normal BCLK + inv FRM */3. #def ine SND_SOC_DAIFMT_IB_NF (3 << 8) /* invert BCLK + nor FRM */4. #def ine SND_SOC_DAIFMT_IB_IF (4 << 8) /* invert BCLK + FRM */bit 12-15 ⽤于设置接⼝主从格式：1. #def ine SND_SOC_DAIFMT_CBM_CFM (1 << 12) /* codec clk & FRM mast er */2. #def ine SND_SOC_DAIFMT_CBS_CFM (2 << 12) /* codec clk slave & FRM mast er */3. #def ine SND_SOC_DAIFMT_CBM_CFS (3 << 12) /* codec clk mast er & f rame slave */4. #def ine SND_SOC_DAIFMT_CBS_CFS (4 << 12) /* codec clk & FRM slave */5. snd_soc_platform_driver中的ops字段该ops字段是⼀个snd_pcm_ops结构，实现该结构中的各个回调函数是socplat f orm驱动的主要⼯作，他们基本都涉及dma操作以及dma buf f er的管理等⼯作。

Linux设备驱动模型之platform总线深入浅出在Linux2.6以后的设备驱动模型中，需关心总线，设备和驱动这三种实体，总线将设备和驱动绑定。

在系统每注册一个设备的时候，会寻找与之匹配的驱动；相反，在系统每注册一个驱动的时候，会寻找与之匹配的设备，而匹配由总线完成。

对于依附在USB、PCI、I2C、SPI等物理总线来这些都不是问题。

但是在嵌入式系统里面，在Soc系统中集成的独立外设控制器，挂接在Soc内存空间的外设等却不依附在此类总线。

基于这一背景，Linux发明了一种总线，称为platform。

相对于USB、PCI、I2C、SPI等物理总线来说，platform总线是一种虚拟、抽象出来的总线，实际中并不存在这样的总线。

platform总线相关代码：driver\base\platform.c 文件相关结构体定义：include\linux\platform_device.h 文件中platform总线管理下最重要的两个结构体是platform_device和platform_driver 分别表示设备和驱动在Linux中的定义如下一：platform_driver//include\linux\platform_device.h struct platform_driver { int (*probe)(struct platform_device *); //探测函数，在注册平台设备时被调用int (*remove)(struct platform_device *); //删除函数，在注销平台设备时被调用void (*shutdown)(struct platform_device *); int (*suspend)(struct platform_device *, pm_message_t state); //挂起函数，在关机被调用int (*suspend_late)(struct platform_device *, pm_message_t state); int (*resume_early)(struct platform_device *); int (*resume)(struct platform_device *);//恢复函数，在开机时被调用struct device_driver driver;//设备驱动结构};12345678。

目前，linux系统常用的音频驱动有两种形式:alsa ossalsa:现在是linux下音频驱动的主要形式，与简单的oss兼容。

oss：过去的形式而我们板子上的uda1341用的就是alsa驱动。

alsa概述：因为我们用的是板上系统，用的也是alsa 的一个soc子系统。

所以我们直接讲解alsa soc子系统。

ALSA SoC LayerALSA板上系统层==============The overall project goal of the ALSA System on Chip (ASoC) layer is toprovide better ALSA support for embedded system-on-chip processors (e.g.pxa2xx, au1x00, iMX, etc) and portable audio codecs. Prior to the ASoCsubsystem there was some support in the kernel for SoC audio, however ithad some limitations:-ALSA板上系统(ASoC)层的总体项目目标，是为对SOC嵌入式处理器和便携音频解码器提供更好的ALSA支持。

在ASoC子系统之前，己有对内核的SoC 音频支持，但是那些支持存在一些局限：Codec drivers were often tightly coupled to the underlying SoCCPU. This is not ideal and leads to code duplication - for example,Linux had different wm8731 drivers for 4 different SoC platforms.解码器常常与底层嵌入式处理器一对一紧密结合。

这是非理想化的，因为这将导致代码的重复－例如，对四个不同的嵌入式平台，Linux要有不同的wm8731驱动。

1.Linux ALSA声卡驱动之一：ALSA架构简介一. 概述ALSA是Advanced Linux Sound Architecture 的缩写，目前已经成为了linux的主流音频体系结构，想了解更多的关于ALSA的这一开源项目的信息和知识，请查看以下网址：/。

在内核设备驱动层，ALSA提供了alsa-driver，同时在应用层，ALSA为我们提供了alsa-lib，应用程序只要调用alsa-lib提供的API，即可以完成对底层音频硬件的控制。

图 1.1 alsa的软件体系结构由图1.1可以看出，用户空间的alsa-lib对应用程序提供统一的API接口，这样可以隐藏了驱动层的实现细节，简化了应用程序的实现难度。

内核空间中，alsa-soc其实是对alsa-driver的进一步封装，他针对嵌入式设备提供了一些列增强的功能。

本系列博文仅对嵌入式系统中的alsa-driver和alsa-soc进行讨论。

二. ALSA设备文件结构我们从alsa在linux中的设备文件结构开始我们的alsa之旅. 看看我的电脑中的alsa驱动的设备文件结构:$ cd /dev/snd$ ls -lcrw-rw----+ 1 root audio 116, 8 2011-02-23 21:38 controlC0crw-rw----+ 1 root audio 116, 4 2011-02-23 21:38 midiC0D0crw-rw----+ 1 root audio 116, 7 2011-02-23 21:39 pcmC0D0ccrw-rw----+ 1 root audio 116, 6 2011-02-23 21:56 pcmC0D0pcrw-rw----+ 1 root audio 116, 7 2011-02-23 21:39 pcmC0D1ccrw-rw----+ 1 root audio 116, 5 2011-02-23 21:38 pcmC0D1pcrw-rw----+ 1 root audio 116, 3 2011-02-23 21:38 seqcrw-rw----+ 1 root audio 116, 2 2011-02-23 21:38 timer$我们可以看到以下设备文件:∙controlC0 --> 用于声卡的控制，例如通道选择，混音，麦克风的控制等∙midiC0D0 --> 用于播放midi音频∙pcmC0D0c --〉用于录音的pcm设备∙pcmC0D0p --〉用于播放的pcm设备∙seq --〉音序器∙timer --〉定时器其中，C0D0代表的是声卡0中的设备0，pcmC0D0c最后一个c代表capture，pcmC0D0p最后一个p代表playback，这些都是alsa-driver中的命名规则。

linuxALSA声卡驱动之Asoc架构中的Codec1. Codec简介在移动设备中，Codec的作⽤可以归结为4种，分别是：.对PCM等信号进⾏D/A转换，把数字的⾳频信号转换为模拟信号.对Mic、Linein或者其他输⼊源的模拟信号进⾏A/D转换，把模拟的声⾳信号转变CPU能够处理的数字信号.对⾳频通路进⾏控制，⽐如播放⾳乐，收听调频收⾳机，⼜或者接听电话时，⾳频信号在codec内的流通路线是不⼀样的.对⾳频信号做出相应的处理，例如⾳量控制，功率放⼤，EQ控制等等ASoC对Codec的这些功能都定义好了⼀些列相应的接⼝，以⽅便地对Codec进⾏控制。

ASoC对Codec驱动的⼀个基本要求是：驱动程序的代码必须要做到平台⽆关性，以⽅便同⼀个Codec的代码不经修改即可⽤在不同的平台上。

以下的讨论基于wolfson的Codec芯⽚WM8994，2.ASoc中对Codec的数据抽象描述Codec的最主要的⼏个数据结构分别是：snd_soc_codec、snd_soc_codec_driver、snd_soc_dai、snd_soc_dai_driver、其中snd_soc_dai 和snd_soc_dai_driver在ASoc的Platform驱动中也会使⽤到，Platform和Codec的DAI 通过snd_soc_dai_link结构，在Machine驱动中进⾏绑定连接。

下⾯我们⼏个结构体的定义。

Snd_soc_codecSnd_soc_codec_driverSnd_soc_daiSnd_soc_dai_driverSnd_soc_dai_ops⽤于实现该dai的控制盒参数配置3 Codec的注册因为Codec驱动的代码要做到平台⽆关性，要使得Machine驱动能够使⽤该Codec。

Codec驱动的⾸要任务就是确定snd_soc_codec和snd_soc_dai的实例，并把他们注册到系统中，注册的codec和dai才能为Machine驱动所⽤。

Linux设备驱动之platform
根据Linux设备模型可知，一个现实的Linux设备和驱动通常都需要挂接在一种总线上，对于本身依附于PCI、USB等的设备而言，这自然不是问题，但是在嵌入式系统里面，SoC系统中集成的独立的外设控制器、挂接在SoC 内存空间的外设等却不依附于此类总线。

基于这一背景，Linux设计了一种虚拟的总线，称为platform总线，相应的设备称为platform_device，而驱动称为platform_driver。

设计目的
兼容设备模型
使得设备被挂接在一个总线上，因此，符合Linux 2.6 的设备模型。

其结果是，配套的sysfs 结点、设备电源管理都成为可能。

BSP和驱动隔离
在BSP中定义platform设备和设备使用的资源、设备的具体配置信息。

而在驱动中，只需要通过通用API去获取资源和数据，做到了板相关代码和驱动代码的分离，使得驱动具有更好的可扩展性和跨平台性。

软件架构
内核中Platform设备有关的实现位于include/linux/platform_device.h和drivers/base/platform.c两个文件中，它的软件架构如下：
由图片可知，Platform设备在内核中的实现主要包括三个部分：
Platform Bus，基于底层bus模块，抽象出一个虚拟的Platform bus，用于挂载Platform设备；
Platform Device，基于底层device模块，抽象出Platform Device，用于表示Platform设备；Platform Driver，基于底层device_driver模块，抽象出Platform Driver，用于驱动Platform 设备。

Linux⾳频驱动学习之：（1）ASOC详解⼀、⾳频架构概述（1）ALSA是Advanced Linux Sound Architecture 的缩写，⽬前已经成为了linux的主流⾳频体系结构，想了解更多的关于ALSA的这⼀开源项⽬的信息和知识，请查看以下⽹址：/。

在内核设备驱动层，ALSA提供了alsa-driver，同时在应⽤层，ALSA为我们提供了alsa-lib，应⽤程序只要调⽤alsa-lib提供的API，即可以完成对底层⾳频硬件的控制。

（2）PCM是英⽂Pulse-code modulation的缩写，中⽂译名是脉冲编码调制。

我们知道在现实⽣活中，⼈⽿听到的声⾳是模拟信号，PCM就是要把声⾳从模拟转换成数字信号的⼀种技术，他的原理简单地说就是利⽤⼀个固定的频率对模拟信号进⾏采样，采样后的信号在波形上看就像⼀串连续的幅值不⼀的脉冲，把这些脉冲的幅值按⼀定的精度进⾏量化，这些量化后的数值被连续地输出、传输、处理或记录到存储介质中，所有这些组成了数字⾳频的产⽣过程。

PCM信号的两个重要指标是采样频率和量化精度，⽬前，CD⾳频的采样频率通常为44100Hz，量化精度是16bit。

通常，播放⾳乐时，应⽤程序从存储介质中读取⾳频数据（MP3、WMA、AAC......），经过解码后，最终送到⾳频驱动程序中的就是PCM数据，反过来，在录⾳时，⾳频驱动不停地把采样所得的PCM数据送回给应⽤程序，由应⽤程序完成压缩、存储等任务。

所以，⾳频驱动的两⼤核⼼任务就是：playback 如何把⽤户空间的应⽤程序发过来的PCM数据，转化为⼈⽿可以辨别的模拟⾳频capture 把mic拾取到得模拟信号，经过采样、量化，转换为PCM信号送回给⽤户空间的应⽤程序（3）ASoC--ALSA System on Chip： 建⽴在标准ALSA驱动层上，为了更好地⽀持嵌⼊式处理器和移动设备中的⾳频Codec的⼀套软件体系。