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
plaincopy

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
plaincopy

#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
plaincopy

#define SND_SOC_DAIFMT_CONT     (1 << 4) /* continuous clock */  

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

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

[cpp]view
plaincopy

#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 用於設置接口主從格式：

[cpp]view
plaincopy

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

[cpp]view
plaincopy

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
plaincopy

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
plaincopy

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
plaincopy

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

[cpp]view
plaincopy


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
plaincopy

<span style="font-family:Arial, Verdana, sans-serif;"><span style="white-space: normal;"></span></span><pre name="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) < 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);  

}  

</pre>如果設置了transfer_ack_begin和transfer_ack_end回調，snd_pcm_period_elapsed還會調用這兩個回調函數。<br>  

<br>  

<pre></pre>  

<pre></pre>  

<pre></pre>

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管理

《Python進階》學習筆記

Leetcode 3161. 物塊放置查詢

一個docker容器暴露多個端口

leetcode 60 排列序列

微服務實踐之使用 Visual Studio 2022 調試Dapr 應用程序

wpf附加屬性理解 WPF附加屬性

基於uda34x的ALSA聲卡驅動之設備建立流程

linux音頻alsa驅動分析之三解碼器

linux音頻alsa驅動文檔閱讀之四數字音頻接口

Android 加載鍵盤佈局文件過程

4.0音頻系統HAL初探

https://yachay.unat.edu.pe/blog/index.php?comment_area=format_blog&comment_component=blog&comment_co

linux以太網驅動總結