Linux ALSA音效卡驅動之八：ASoC架構中的Platform

阿新 • • 發佈：2018-12-30

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為例：

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。
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 用於設定介面的格式：

#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 用於設定介面時鐘的開關特性：

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

bit 8-11 用於設定介面時鐘的相位：

#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 用於設定介面主從格式：

#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操作，而多數嵌入式平臺還要求dma記憶體的實體地址是連續的，以方便dma控制器對記憶體的訪問。在ASoC架構中，dma buffer的資訊儲存在snd_pcm_substream結構的snd_dma_buffer *buf欄位中，它的定義如下

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為例：

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);
}

pcm_new欄位指向了dma_new函式，dma_new函式進一步為playback和capture分別呼叫preallocate_dma_buffer函式，我們看看preallocate_dma_buffer函式的實現：

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中的圖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中讀走音訊資料。

圖6.2.1 環形緩衝區環形緩衝區正好適合用於這種情景的buffer管理，理想情況下，大小為Count的緩衝區具備一個讀指標和寫指標，我們期望他們都可以閉合地做環形移動，但是實際的情況確實：緩衝區通常都是一段連續的地址，他是有開始和結束兩個邊界，每次移動之前都必須進行一次判斷，當指標移動到末尾時就必須人為地讓他回到起始位置。在實際應用中，我們通常都會把這個大小為Count的緩衝區虛擬成一個大小為n*Count的邏輯緩衝區，相當於理想狀態下的圓形繞了n圈之後，然後把這段總的距離拉平為一段直線，每一圈對應直線中的一段，因為n比較大，所以大多數情況下不會出現讀寫指標的換位的情況（如果不對buffer進行擴充套件，指標到達末端後，回到起始端時，兩個指標的前後相對位置會發生互換）。擴充套件後的邏輯緩衝區在計算剩餘空間可條件判斷是相對方便。alsa driver也使用了該方法對dma buffer進行管理：

圖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中。例如，獲得播放緩衝區的空閒空間：

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用於更新這幾個指標的當前位置：

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個緩衝區管理欄位，然後喚醒相應的等待程序；

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驅動的幾個重要資料結構之間的關係:

圖7.1 ASoC Platform驅動

一堆的private_data，很重要但也很容易搞混，下面的圖不知對大家有沒有幫助：

圖7.2 private_data

Linux ALSA音效卡驅動之八：ASoC架構中的Platform

1. Platform驅動在ASoC中的作用

2. snd_soc_platform_driver的註冊

3. cpu的snd_soc_dai driver驅動的註冊

4. snd_soc_dai_driver中的ops欄位

5. snd_soc_platform_driver中的ops欄位

6. 音訊資料的dma操作

6.1. 申請dma buffer

6.2 dma buffer管理

Linux ALSA音效卡驅動之八：ASoC架構中的Platform

Linux ALSA音效卡驅動之六：ASoC架構中的Machine

Linux ALSA音效卡驅動之七：ASoC架構中的Codec

Linux ALSA音效卡驅動之五：移動裝置中的ALSA

Linux ALSA音效卡驅動之五：移動裝置中的ALSA（ASoC）

Linux ALSA音效卡驅動之三：PCM裝置的建立

Linux ALSA音效卡驅動之二：音效卡的建立

Linux ALSA音效卡驅動之四：Control裝置的建立

Linux ALSA 音效卡驅動之一：ALSA架構簡介

Linux ALSA音效卡驅動之一：ALSA架構簡介

Linux ALSA音效卡驅動之一：ALSA系統架構

ALSA音效卡驅動中的DAPM詳解之二：widget-具備路徑和電源管理資訊的kcontrol

ALSA音效卡驅動中的DAPM詳解之七：dapm事件機制（dapm event）

ALSA音效卡驅動中的DAPM詳解之五：建立widget之間的連線關係

ALSA音效卡驅動中的DAPM詳解之四：在驅動程式中初始化並註冊widget和route

ALSA音效卡驅動中的DAPM詳解之一：kcontrol

linux驅動編寫（音效卡驅動之asoc移植）

android下除錯音效卡驅動之概述

android下除錯音效卡驅動之總結

android下除錯音效卡驅動之wm8960介紹二

Linux ALSA音效卡驅動之八：ASoC架構中的Platform

1. Platform驅動在ASoC中的作用

2. snd_soc_platform_driver的註冊

3. cpu的snd_soc_dai driver驅動的註冊

4. snd_soc_dai_driver中的ops欄位

5. snd_soc_platform_driver中的ops欄位

6. 音訊資料的dma操作

6.1. 申請dma buffer

6.2 dma buffer管理

相關推薦