alsa(audio)驱动分析.docVIP

Alsa驱动分析 Guide Revision History Date Issue Description Author 31/12/2008 0.5 First draft Wylhistory 目录 1. Abstract 3 2. Introduction 3 3. 音频驱动框架介绍 3 3.1 音频设备的注册 3 3.2 音频驱动的注册 4 3.2.1 Probe函数的调用 4 3.2.2 Soc_probe函数 4 4. 通常的使用流程的分析 6 4.1.1 open过程介绍 6 4.1.2 snd_pcm_hw_params流程分析 8 4.1.3 prepare流程分析 9 4.1.4 write的流程 15 4.1.5 使用流程的总结t 18 5. Amixer调用的相关逻辑 18 5.1.1 Amixer调用的上层逻辑 19 5.1.2 Amixer的内核流程 20 6. 总结 21 7. 未讨论 21 Abstract 主要是讲2.6.21内核里面的alsa驱动的架构，以及在我们的平台上需要注意的东西。. Introduction 分成几个部分: 驱动整体框架，一个简单的播放流程介绍，以及我们的平台需要注意的地方； 音频驱动框架介绍 音频设备的注册 这就是设备的注册了，设备本身非常简单，复杂的是这个设备的drvdata，drvdata里面包含了三部分，关于machine的，关于platform的，关于codec的，从大体上说machine主要是关于cpu这边的也可以说是关于ssp本身设置的，而platform是关于平台级别的，就是说这个平台本身实现相关的，而codec就是与我们所用的音频codec相关的；基本上这里就可以看出整个音频驱动的架构特点，就是从alsa层进入——内核alsa层接口-core层，这里再调用上面说的三个方面的函数来处理，先是cpu级别的，再是platform的，再是codec级别的，这几层做完了，工作也就做得差不多了，后面会详细讲讲，当然这个执行顺序不是固定的(不知道是不是marvel写代码不专业导致的)，但多半都包括了这三部分的工作; 音频驱动的注册 Probe函数的调用 前面讲了设备的注册，里面的设备的名字就是”soc-audio”,而这里的driver的注册时名字也是” soc-audio”，对于platform的设备匹配的原则是根据名字的，所以将会匹配成功，成功后就会执行audio驱动提供的probe函数soc_probe; Soc_probe函数 这个函数本身架构很简单，和前面说的逻辑一样，先调用了cpu级别的probe，再是codec级别的，最后是platform的（这里三个的顺序就不一样），但是因为cpu级别的和platform级别的都为空，最后都调用了codec级别的probe函数，也就是micco_soc_probe，这个函数基本上就完成了所有应该完成的音频驱动的初始化了；简单的划分，分成两部分，对上和对下：对上主要是注册设备节点，以及这些设备节点对应的流的创建；对下主要是读写函数的设置，codec本身的dai设置，初始化寄存器的设置，最重要的就是后面的control的创建和门的创建了，如下图所示： 这里面的第一部分就是负责初始化的； 第二部分就是创建卡和流，对于alsa驱动来说，是先分成卡0，卡1…,然后对于每一个卡的每一个cpu支持的dai（digit audio interface）也就是pcm接口 或者i2S接口等都要建立对应的流，一个dai有可能包含两个流，一个是录的一个是play的，但在我们的平台上对于i2S的dai是没有录音功能的，所以我们的平台只有一个卡，三个流，pcm的录和play，i2S的play；流的创建还是更多的考虑为上层服务的，它所提供的接口都是soc层的，这里非常重要的地方在于驱动的一个典型做法那就是如何把关键的内核数据结构和export到外部的/dev下的设备节点实现关联，比如: 关键数据结构struct snd_pcm，是根据cpu所固有的dai创建的，而对于每一个struct snd_pcm又可能用到两个substream（它们实现具体的流的播放等），它们之间的链接是通过它的内部数据成员struct snd_pcm_str streams[2];来连接的，而这个snd_pcm类型的指针是在函数snd_device_new里面通过device_data放到设备里面的，这个设备会在snd_device_register_all 的时候注册到/dev下面，并且调用dev_set_drvdata(preg-dev, private_data);来把这个指针放到设备的私有数据里面；而在需要使用的时候通过sn