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

[cpp]?view plain?copy

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 用于設置接口的格式：

[cpp]?view plain?copy

#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 用于設置接口時鐘的開關特性：

[cpp]?view plain?copy

#define?SND_SOC_DAIFMT_CONT?????(1?<

#define?SND_SOC_DAIFMT_GATED????????(2?<

bit 8-11 用于設置接口時鐘的相位：

[cpp]?view plain?copy

#define?SND_SOC_DAIFMT_NB_NF????????(1?<

#define?SND_SOC_DAIFMT_NB_IF????????(2?<

#define?SND_SOC_DAIFMT_IB_NF????????(3?<

#define?SND_SOC_DAIFMT_IB_IF????????(4?<

bit 12-15 用于設置接口主從格式：

[cpp]?view plain?copy

#define?SND_SOC_DAIFMT_CBM_CFM??????(1?<

#define?SND_SOC_DAIFMT_CBS_CFM??????(2?<

#define?SND_SOC_DAIFMT_CBM_CFS??????(3?<

#define?SND_SOC_DAIFMT_CBS_CFS??????(4?<

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字段中，它的定義如下

[cpp]?view plain?copy

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

[cpp]?view plain?copy

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函數的實現：

[cpp]?view plain?copy

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

[csharp]?view plain?copy

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?

avail?+=?runtime->boundary;??

else?if?((snd_pcm_uframes_t)?avail?>=?runtime->boundary)??

avail?-=?runtime->boundary;??

return?avail;??

}??

要想映射到真正的緩沖區位置，只要減去runtime->hw_ptr_base即可。下面的api用于更新這幾個指針的當前位置：

[cpp]?view plain?copy

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個緩沖區管理字段，然后喚醒相應的等待進程；

[cpp]?view plain?copy

"font-family:Arial,?Verdana,?sans-serif;">"white-space:?normal;">

"code"?class="cpp">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)?

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

?