Linux ALSA声卡驱动之八：ASoC架构中的Platform

今天药忘吃喽~ 2022-06-17 10:48 272阅读 0赞

转载自：[http://blog.csdn.net/droidphone/article/details/7316061][http_blog.csdn.net_droidphone_article_details_7316061]

# 1.  Platform驱动在ASoC中的作用 #

前面几章内容已经说过，ASoC被分为Machine，Platform和Codec三大部件，Platform驱动的主要作用是完成音频数据的管理，最终通过CPU的数字音频接口（DAI）把音频数据传送给Codec进行处理，最终由Codec输出驱动耳机或者是喇叭的音信信号。在具体实现上，ASoC有把Platform驱动分为两个部分：snd\_soc\_platform\_driver和snd\_soc\_dai\_driver。其中，platform\_driver负责管理音频数据，把音频数据通过dma或其他操作传送至cpu dai中，dai\_driver则主要完成cpu一侧的dai的参数配置，同时也会通过一定的途径把必要的dma等参数与snd\_soc\_platform\_driver进行交互。

/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/

声明：本博内容均由http://blog.csdn.net/droidphone原创，转载请注明出处，谢谢！  
/\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*\*/

# 2.  snd\_soc\_platform\_driver的注册 #

通常，ASoC把snd\_soc\_platform\_driver注册为一个系统的platform\_driver，不要被这两个相像的术语所迷惑，前者只是针对ASoC子系统的，后者是来自Linux的设备驱动模型。我们要做的就是：

*  定义一个snd\_soc\_platform\_driver结构的实例；
 *  在platform\_driver的probe回调中利用ASoC的API：snd\_soc\_register\_platform()注册上面定义的实例；
 *  实现snd\_soc\_platform\_driver中的各个回调函数；

以kernel3.3中的/sound/soc/samsung/dma.c为例：

![save_snippets.png][]

static struct snd_soc_platform_driver samsung_asoc_platform = {
    	.ops		= &dma_ops,
    	.pcm_new	= dma_new,
    	.pcm_free	= dma_free_dma_buffers,
    };
    
    static int __devinit samsung_asoc_platform_probe(struct platform_device *pdev)
    {
    	return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);
    }
    
    static int __devexit samsung_asoc_platform_remove(struct platform_device *pdev)
    {
    	snd_soc_unregister_platform(&pdev->dev);
    	return 0;
    }
    
    static struct platform_driver asoc_dma_driver = {
    	.driver = {
    		.name = "samsung-audio",
    		.owner = THIS_MODULE,
    	},
    
    	.probe = samsung_asoc_platform_probe,
    	.remove = __devexit_p(samsung_asoc_platform_remove),
    };
    
    module_platform_driver(asoc_dma_driver);

**snd\_soc\_register\_platform() **该函数用于注册一个snd\_soc\_platform，只有注册以后，它才可以被Machine驱动使用。它的代码已经清晰地表达了它的实现过程：

*  为snd\_soc\_platform实例申请内存；
 *  从platform\_device中获得它的名字，用于Machine驱动的匹配工作；
 *  初始化snd\_soc\_platform的字段；
 *  把snd\_soc\_platform实例连接到全局链表platform\_list中；
 *  调用snd\_soc\_instantiate\_cards，触发声卡的machine、platform、codec、dai等的匹配工作；

# 3.  cpu的snd\_soc\_dai driver驱动的注册 #

dai驱动通常对应cpu的一个或几个I2S/PCM接口，与snd\_soc\_platform一样，dai驱动也是实现为一个platform driver，实现一个dai驱动大致可以分为以下几个步骤：

*  定义一个snd\_soc\_dai\_driver结构的实例；
 *  在对应的platform\_driver中的probe回调中通过API：snd\_soc\_register\_dai或者snd\_soc\_register\_dais，注册snd\_soc\_dai实例；
 *  实现snd\_soc\_dai\_driver结构中的probe、suspend等回调；
 *  实现snd\_soc\_dai\_driver结构中的snd\_soc\_dai\_ops字段中的回调函数；

**snd\_soc\_register\_dai**  这个函数在上一篇介绍codec驱动的博文中已有介绍，请参考：[Linux ALSA声卡驱动之七：ASoC架构中的Codec][Linux ALSA_ASoC_Codec]。  
**snd\_soc\_dai**  该结构在snd\_soc\_register\_dai函数中通过动态内存申请获得， 简要介绍一下几个重要字段：

*  driver  指向关联的snd\_soc\_dai\_driver结构，由注册时通过参数传入；
 *  playback\_dma\_data  用于保存该dai播放stream的dma信息，例如dma的目标地址，dma传送单元大小和通道号等；
 *  capture\_dma\_data  同上，用于录音stream；
 *  platform  指向关联的snd\_soc\_platform结构；

**snd\_soc\_dai\_driver**  该结构需要自己根据不同的soc芯片进行定义，关键字段介绍如下：

*  probe、remove  回调函数，分别在声卡加载和卸载时被调用；
 *  suspend、resume  电源管理回调函数；
 *  ops  指向snd\_soc\_dai\_ops结构，用于配置和控制该dai；
 *  playback  snd\_soc\_pcm\_stream结构，用于指出该dai支持的声道数，码率，数据格式等能力；
 *  capture  snd\_soc\_pcm\_stream结构，用于指出该dai支持的声道数，码率，数据格式等能力；

# 4.  snd\_soc\_dai\_driver中的ops字段 #

ops字段指向一个snd\_soc\_dai\_ops结构，该结构实际上是一组回调函数的集合，dai的配置和控制几乎都是通过这些回调函数来实现的，这些回调函数基本可以分为3大类，驱动程序可以根据实际情况实现其中的一部分：

工作时钟配置函数  通常由machine驱动调用：

*  set\_sysclk  设置dai的主时钟；
 *  set\_pll  设置PLL参数；
 *  set\_clkdiv  设置分频系数；
 *  dai的格式配置函数  通常由machine驱动调用：
 *  set\_fmt   设置dai的格式；
 *  set\_tdm\_slot  如果dai支持时分复用，用于设置时分复用的slot；
 *  set\_channel\_map 声道的时分复用映射设置；
 *  set\_tristate  设置dai引脚的状态，当与其他dai并联使用同一引脚时需要使用该回调；

标准的snd\_soc\_ops回调  通常由soc-core在进行PCM操作时调用：

*  startup
 *  shutdown
 *  hw\_params
 *  hw\_free
 *  prepare
 *  trigger

抗pop，pop声  由soc-core调用：

*  digital\_mute

以下这些api通常被machine驱动使用，machine驱动在他的snd\_pcm\_ops字段中的hw\_params回调中使用这些api：

*  snd\_soc\_dai\_set\_fmt()  实际上会调用snd\_soc\_dai\_ops或者codec driver中的set\_fmt回调；
 *  snd\_soc\_dai\_set\_pll() 实际上会调用snd\_soc\_dai\_ops或者codec driver中的set\_pll回调；
 *  snd\_soc\_dai\_set\_sysclk()  实际上会调用snd\_soc\_dai\_ops或者codec driver中的set\_sysclk回调；
 *  snd\_soc\_dai\_set\_clkdiv()  实际上会调用snd\_soc\_dai\_ops或者codec driver中的set\_clkdiv回调；

snd\_soc\_dai\_set\_fmt(struct snd\_soc\_dai \*dai, unsigned int fmt)的第二个参数fmt在这里特别说一下，ASoC目前只是用了它的低16位，并且为它专门定义了一些宏来方便我们使用：

bit 0-3 用于设置接口的格式：

![save_snippets.png][]

#define SND_SOC_DAIFMT_I2S		1 /* I2S mode */
    #define SND_SOC_DAIFMT_RIGHT_J		2 /* Right Justified mode */
    #define SND_SOC_DAIFMT_LEFT_J		3 /* Left Justified mode */
    #define SND_SOC_DAIFMT_DSP_A		4 /* L data MSB after FRM LRC */
    #define SND_SOC_DAIFMT_DSP_B		5 /* L data MSB during FRM LRC */
    #define SND_SOC_DAIFMT_AC97		6 /* AC97 */
    #define SND_SOC_DAIFMT_PDM		7 /* Pulse density modulation */

bit 4-7 用于设置接口时钟的开关特性：

![save_snippets.png][]

#define SND_SOC_DAIFMT_CONT		(1 << 4) /* continuous clock */
    #define SND_SOC_DAIFMT_GATED		(2 << 4) /* clock is gated */

bit 8-11 用于设置接口时钟的相位：

![save_snippets.png][]

#define SND_SOC_DAIFMT_NB_NF		(1 << 8) /* normal bit clock + frame */
    #define SND_SOC_DAIFMT_NB_IF		(2 << 8) /* normal BCLK + inv FRM */
    #define SND_SOC_DAIFMT_IB_NF		(3 << 8) /* invert BCLK + nor FRM */
    #define SND_SOC_DAIFMT_IB_IF		(4 << 8) /* invert BCLK + FRM */

bit 12-15 用于设置接口主从格式：

![save_snippets.png][]

#define SND_SOC_DAIFMT_CBM_CFM		(1 << 12) /* codec clk & FRM master */
    #define SND_SOC_DAIFMT_CBS_CFM		(2 << 12) /* codec clk slave & FRM master */
    #define SND_SOC_DAIFMT_CBM_CFS		(3 << 12) /* codec clk master & frame slave */
    #define SND_SOC_DAIFMT_CBS_CFS		(4 << 12) /* codec clk & FRM slave */

# 5.  snd\_soc\_platform\_driver中的ops字段 #

该ops字段是一个snd\_pcm\_ops结构，实现该结构中的各个回调函数是soc platform驱动的主要工作，他们基本都涉及dma操作以及dma buffer的管理等工作。下面介绍几个重要的回调函数：

ops.open

当应用程序打开一个pcm设备时，该函数会被调用，通常，该函数会使用snd\_soc\_set\_runtime\_hwparams()设置substream中的snd\_pcm\_runtime结构里面的hw\_params相关字段，然后为snd\_pcm\_runtime的private\_data字段申请一个私有结构，用于保存该平台的dma参数。

ops.hw\_params

驱动的hw\_params阶段，该函数会被调用。通常，该函数会通过snd\_soc\_dai\_get\_dma\_data函数获得对应的dai的dma参数，获得的参数一般都会保存在snd\_pcm\_runtime结构的private\_data字段。然后通过snd\_pcm\_set\_runtime\_buffer函数设置snd\_pcm\_runtime结构中的dma buffer的地址和大小等参数。要注意的是，该回调可能会被多次调用，具体实现时要小心处理多次申请资源的问题。

ops.prepare

正式开始数据传送之前会调用该函数，该函数通常会完成dma操作的必要准备工作。

ops.trigger

数据传送的开始，暂停，恢复和停止时，该函数会被调用。

ops.pointer

该函数返回传送数据的当前位置。

# 6.  音频数据的dma操作 #

soc-platform驱动的最主要功能就是要完成音频数据的传送，大多数情况下，音频数据都是通过dma来完成的。

##  6.1.  申请dma buffer ##

因为dma的特殊性，dma buffer是一块特殊的内存，比如有的平台规定只有某段地址范围的内存才可以进行dma操作，而多数[嵌入式][Link 1]平台还要求dma内存的物理地址是连续的，以方便dma控制器对内存的访问。在ASoC[架构][Link 2]中，dma buffer的信息保存在snd\_pcm\_substream结构的snd\_dma\_buffer \*buf字段中，它的定义如下

![save_snippets.png][]

struct snd_dma_buffer {
    	struct snd_dma_device dev;	/* device type */
    	unsigned char *area;	/* virtual pointer */
    	dma_addr_t addr;	/* physical address */
    	size_t bytes;		/* buffer size in bytes */
    	void *private_data;	/* private for allocator; don't touch */
    };

那么，在哪里完成了snd\_dam\_buffer结构的初始化赋值操作呢？答案就在snd\_soc\_platform\_driver的pcm\_new回调函数中，还是以/sound/soc/samsung/dma.c为例：

![save_snippets.png][]

pcm\_new字段指向了dma\_new函数，dma\_new函数进一步为playback和capture分别调用preallocate\_dma\_buffer函数，我们看看preallocate\_dma\_buffer函数的实现：

![save_snippets.png][]

static int preallocate_dma_buffer(struct snd_pcm *pcm, int stream)
    {
    	struct snd_pcm_substream *substream = pcm->streams[stream].substream;
    	struct snd_dma_buffer *buf = &substream->dma_buffer;
    	size_t size = dma_hardware.buffer_bytes_max;
    
    	pr_debug("Entered %s\n", __func__);
    
    	buf->dev.type = SNDRV_DMA_TYPE_DEV;
    	buf->dev.dev = pcm->card->dev;
    	buf->private_data = NULL;
    	buf->area = dma_alloc_writecombine(pcm->card->dev, size,
    					   &buf->addr, GFP_KERNEL);
    	if (!buf->area)
    		return -ENOMEM;
    	buf->bytes = size;
    	return 0;
    }

该函数先是获得事先定义好的buffer大小，然后通过dma\_alloc\_weitecombine函数分配dma内存，然后完成substream->dma\_buffer的初始化赋值工作。上述的pcm\_new回调会在声卡的建立阶段被调用，调用的详细的过程请参考[Linux ALSAs声卡驱动之六：ASoC架构中的Machine][Linux ALSAs_ASoC_Machine]中的图3.1。

在声卡的hw\_params阶段，snd\_soc\_platform\_driver结构的ops->hw\_params会被调用，在该回调用，通常会使用api：snd\_pcm\_set\_runtime\_buffer()把substream->dma\_buffer的数值拷贝到substream->runtime的相关字段中（.dma\_area, .dma\_addr,  .dma\_bytes），这样以后就可以通过substream->runtime获得这些地址和大小信息了。

dma buffer获得后，即是获得了dma操作的源地址，那么目的地址在哪里？其实目的地址当然是在dai中，也就是前面介绍的snd\_soc\_dai结构的playback\_dma\_data和capture\_dma\_data字段中，而这两个字段的值也是在hw\_params阶段，由snd\_soc\_dai\_driver结构的ops->hw\_params回调，利用api：snd\_soc\_dai\_set\_dma\_data进行设置的。紧随其后，snd\_soc\_platform\_driver结构的ops->hw\_params回调利用api：snd\_soc\_dai\_get\_dma\_data获得这些dai的dma信息，其中就包括了dma的目的地址信息。这些dma信息通常还会被保存在substream->runtime->private\_data中，以便在substream的整个生命周期中可以随时获得这些信息，从而完成对dma的配置和操作。

## 6.2  dma buffer管理 ##

播放时，应用程序把音频数据源源不断地写入dma buffer中，然后相应platform的dma操作则不停地从该buffer中取出数据，经dai送往codec中。录音时则正好相反，codec源源不断地把A/D转换好的音频数据经过dai送入dma buffer中，而应用程序则不断地从该buffer中读走音频数据。

![0_13316162851ZB9.gif][]

图6.2.1   环形缓冲区

环形缓冲区正好适合用于这种情景的buffer管理，理想情况下，大小为Count的缓冲区具备一个读指针和写指针，我们期望他们都可以闭合地做环形移动，但是实际的情况确实：缓冲区通常都是一段连续的地址，他是有开始和结束两个边界，每次移动之前都必须进行一次判断，当指针移动到末尾时就必须人为地让他回到起始位置。在实际应用中，我们通常都会把这个大小为Count的缓冲区虚拟成一个大小为n\*Count的逻辑缓冲区，相当于理想状态下的圆形绕了n圈之后，然后把这段总的距离拉平为一段直线，每一圈对应直线中的一段，因为n比较大，所以大多数情况下不会出现读写指针的换位的情况（如果不对buffer进行扩展，指针到达末端后，回到起始端时，两个指针的前后相对位置会发生互换）。扩展后的逻辑缓冲区在计算剩余空间可条件判断是相对方便。alsa driver也使用了该方法对dma buffer进行管理：

![0_1331617647jjqN.gif][]

图6.2.2  alsa driver缓冲区管理

snd\_pcm\_runtime结构中，使用了四个相关的字段来完成这个逻辑缓冲区的管理：

*  snd\_pcm\_runtime.hw\_ptr\_base  环形缓冲区每一圈的基地址，当读写指针越过一圈后，它按buffer size进行移动；
 *  snd\_pcm\_runtime.status->hw\_ptr  硬件逻辑位置，播放时相当于读指针，录音时相当于写指针；  
    
 *  snd\_pcm\_runtime.control->appl\_ptr  应用逻辑位置，播放时相当于写指针，录音时相当于读指针；  
    
 *  snd\_pcm\_runtime.boundary  扩展后的逻辑缓冲区大小，通常是(2^n)\*size；

通过这几个字段，我们可以很容易地获得缓冲区的有效数据，剩余空间等信息，也可以很容易地把当前逻辑位置映射回真实的dma buffer中。例如，获得播放缓冲区的空闲空间：

![save_snippets.png][]

static inline snd_pcm_uframes_t snd_pcm_playback_avail(struct snd_pcm_runtime *runtime)
    {
    	snd_pcm_sframes_t avail = runtime->status->hw_ptr + runtime->buffer_size - runtime->control->appl_ptr;
    	if (avail < 0)
    		avail += runtime->boundary;
    	else if ((snd_pcm_uframes_t) avail >= runtime->boundary)
    		avail -= runtime->boundary;
    	return avail;
    }

要想映射到真正的缓冲区位置，只要减去runtime->hw\_ptr\_base即可。下面的api用于更新这几个指针的当前位置：

![save_snippets.png][]

int snd_pcm_update_hw_ptr(struct snd_pcm_substream *substream)

所以要想通过snd\_pcm\_playback\_avail等函数获得正确的信息前，应该先要调用这个api更新指针位置。

以播放(playback)为例，我现在知道至少有3个途径可以完成对dma buffer的写入：

*  应用程序调用alsa-lib的snd\_pcm\_writei、snd\_pcm\_writen函数；
 *  应用程序使用ioctl：SNDRV\_PCM\_IOCTL\_WRITEI\_FRAMES或SNDRV\_PCM\_IOCTL\_WRITEN\_FRAMES；
 *  应用程序使用alsa-lib的snd\_pcm\_mmap\_begin/snd\_pcm\_mmap\_commit;

以上几种方式最终把数据写入dma buffer中，然后修改runtime->control->appl\_ptr的值。

播放过程中，通常会配置成每一个period size生成一个dma中断，中断处理函数最重要的任务就是：

*  更新dma的硬件的当前位置，该数值通常保存在runtime->private\_data中；
 *  调用snd\_pcm\_period\_elapsed函数，该函数会进一步调用snd\_pcm\_update\_hw\_ptr0函数更新上述所说的4个缓冲区管理字段，然后唤醒相应的等待进程；

![save_snippets.png][]

[cpp] view plain copy print ? void snd_pcm_period_elapsed(struct snd_pcm_substream *substream)   {       struct snd_pcm_runtime *runtime;       unsigned long flags;          if (PCM_RUNTIME_CHECK(substream))           return;       runtime = substream->runtime;          if (runtime->transfer_ack_begin)           runtime->transfer_ack_begin(substream);          snd_pcm_stream_lock_irqsave(substream, flags);       if (!snd_pcm_running(substream) ||           snd_pcm_update_hw_ptr0(substream, 1) < 0)           goto _end;          if (substream->timer_running)           snd_timer_interrupt(substream->timer, 1);    _end:       snd_pcm_stream_unlock_irqrestore(substream, flags);       if (runtime->transfer_ack_end)           runtime->transfer_ack_end(substream);       kill_fasync(&runtime->fasync, SIGIO, POLL_IN);   }   void snd_pcm_period_elapsed(struct snd_pcm_substream *substream)
    {
    	struct snd_pcm_runtime *runtime;
    	unsigned long flags;
    
    	if (PCM_RUNTIME_CHECK(substream))
    		return;
    	runtime = substream->runtime;
    
    	if (runtime->transfer_ack_begin)
    		runtime->transfer_ack_begin(substream);
    
    	snd_pcm_stream_lock_irqsave(substream, flags);
    	if (!snd_pcm_running(substream) ||
    	    snd_pcm_update_hw_ptr0(substream, 1) < 0)
    		goto _end;
    
    	if (substream->timer_running)
    		snd_timer_interrupt(substream->timer, 1);
     _end:
    	snd_pcm_stream_unlock_irqrestore(substream, flags);
    	if (runtime->transfer_ack_end)
    		runtime->transfer_ack_end(substream);
    	kill_fasync(&runtime->fasync, SIGIO, POLL_IN);
    }
    如果设置了transfer_ack_begin和transfer_ack_end回调，snd_pcm_period_elapsed还会调用这两个回调函数。

7.  图说代码

最后，反正图也画了，好与不好都传上来供参考一下，以下这张图表达了 ASoC中Platform驱动的几个重要[数据结构][Link 3]之间的关系:

![0_1331621814MGnE.gif][]

图7.1   ASoC Platform驱动

一堆的private\_data，很重要但也很容易搞混，下面的图不知对大家有没有帮助：

![0_13316219184kJc.gif][]

图7.2  private\_data

[http_blog.csdn.net_droidphone_article_details_7316061]: http://blog.csdn.net/droidphone/article/details/7316061
[save_snippets.png]: /images/20220617/fadf6aadcdd646599df1434f16568ad5.png
[Linux ALSA_ASoC_Codec]: http://blog.csdn.net/droidphone/article/details/7283833
[Link 1]: http://lib.csdn.net/base/embeddeddevelopment
[Link 2]: http://lib.csdn.net/base/architecture
[Linux ALSAs_ASoC_Machine]: http://blog.csdn.net/droidphone/article/details/7231605
[0_13316162851ZB9.gif]: /images/20220617/b29fc47aedc3456c89a49270d1e0a763.png
[0_1331617647jjqN.gif]: /images/20220617/256e902f8d9346aeb95feddc638205ce.png
[Link 3]: http://lib.csdn.net/base/datastructure
[0_1331621814MGnE.gif]: /images/20220617/d20dc2859cf840d29b8e06a4fb01d9fa.png
[0_13316219184kJc.gif]: /images/20220617/b8f76863a5ac4f0dbb89730b9bca0fad.png