close

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進行交互。


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

 

  1. static struct snd_soc_platform_driver samsung_asoc_platform = {  
  2.     .ops        = &dma_ops,  
  3.     .pcm_new    = dma_new,  
  4.     .pcm_free   = dma_free_dma_buffers,  
  5. };  
  6.   
  7. static int __devinit samsung_asoc_platform_probe(struct platform_device *pdev)  
  8. {  
  9.     return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);  
  10. }  
  11.   
  12. static int __devexit samsung_asoc_platform_remove(struct platform_device *pdev)  
  13. {  
  14.     snd_soc_unregister_platform(&pdev->dev);  
  15.     return 0;  
  16. }  
  17.   
  18. static struct platform_driver asoc_dma_driver = {  
  19.     .driver = {  
  20.         .name = "samsung-audio",  
  21.         .owner = THIS_MODULE,  
  22.     },  
  23.   
  24.     .probe = samsung_asoc_platform_probe,  
  25.     .remove = __devexit_p(samsung_asoc_platform_remove),  
  26. };  
  27.   
  28. 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 用於設置介面的格式：

 

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

 

bit 4-7 用於設置介面時鐘的開關特性：

 

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

 

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

 

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

 

bit 12-15 用於設置介面主從格式：

 

  1. #define SND_SOC_DAIFMT_CBM_CFM      (1 << 12) /* codec clk & FRM master */  
  2. #define SND_SOC_DAIFMT_CBS_CFM      (2 << 12) /* codec clk slave & FRM master */  
  3. #define SND_SOC_DAIFMT_CBM_CFS      (3 << 12) /* codec clk master & frame slave */  
  4. #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欄位中，它的定義如下

 

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

 

那麼，在哪裡完成了snd_dam_buffer結構的初始化賦值操作呢？答案就在snd_soc_platform_driver的pcm_new回呼函數中，還是以/sound/soc/samsung/dma.c為例：

 

  1. static struct snd_soc_platform_driver samsung_asoc_platform = {  
  2.     .ops        = &dma_ops,  
  3.     .pcm_new    = dma_new,  
  4.     .pcm_free   = dma_free_dma_buffers,  
  5. };  
  6.   
  7. static int __devinit samsung_asoc_platform_probe(struct platform_device *pdev)  
  8. {  
  9.     return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);  
  10. }  

 

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

 

  1. static int preallocate_dma_buffer(struct snd_pcm *pcm, int stream)  
  2. {  
  3.     struct snd_pcm_substream *substream = pcm->streams[stream].substream;  
  4.     struct snd_dma_buffer *buf = &substream->dma_buffer;  
  5.     size_t size = dma_hardware.buffer_bytes_max;  
  6.   
  7.     pr_debug("Entered %s\n", __func__);  
  8.   
  9.     buf->dev.type = SNDRV_DMA_TYPE_DEV;  
  10.     buf->dev.dev = pcm->card->dev;  
  11.     buf->private_data = NULL;  
  12.     buf->area = dma_alloc_writecombine(pcm->card->dev, size,  
  13.                        &buf->addr, GFP_KERNEL);  
  14.     if (!buf->area)  
  15.         return -ENOMEM;  
  16.     buf->bytes = size;  
  17.     return 0;  
  18. }  

 

該函數先是獲得事先定義好的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中。例如，獲得播放緩衝區的空閒空間：

 

  1. static inline snd_pcm_uframes_t snd_pcm_playback_avail(struct snd_pcm_runtime *runtime)  
  2. {  
  3.     snd_pcm_sframes_t avail = runtime->status->hw_ptr + runtime->buffer_size - runtime->control->appl_ptr;  
  4.     if (avail < 0)  
  5.         avail += runtime->boundary;  
  6.     else if ((snd_pcm_uframes_t) avail >= runtime->boundary)  
  7.         avail -= runtime->boundary;  
  8.     return avail;  
  9. }  

 


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

 

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

 

  1. Void  snd_pcm_period_elapsed(struct snd_pcm_substream *substream)  
  2. {  
  3.     struct snd_pcm_runtime *runtime;  
  4.     unsigned long flags;  
  5.   
  6.     if (PCM_RUNTIME_CHECK(substream))  
  7.         return;  
  8.     runtime = substream->runtime;  
  9.   
  10.     if (runtime->transfer_ack_begin)  
  11.         runtime->transfer_ack_begin(substream);  
  12.   
  13.     snd_pcm_stream_lock_irqsave(substream, flags);  
  14.     if (!snd_pcm_running(substream) ||  
  15.         snd_pcm_update_hw_ptr0(substream, 1) < 0)  
  16.         goto _end;  
  17.   
  18.     if (substream->timer_running)  
  19.         snd_timer_interrupt(substream->timer, 1);  
  20.  _end:  
  21.     snd_pcm_stream_unlock_irqrestore(substream, flags);  
  22.     if (runtime->transfer_ack_end)  
  23.         runtime->transfer_ack_end(substream);  
  24.     kill_fasync(&runtime->fasync, SIGIO, POLL_IN);  
  25. }  

 

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

 

 

 

7.  圖說代碼

 

最後，反正圖也畫了，好與不好都傳上來供參考一下，以下這張圖表達了 ASoC中Platform驅動的幾個重要資料結構之間的關係:

 

 

                                                                                  圖7.1   ASoC Platform驅動

 

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

 

 

                                                              圖7.2  private_data

 

 

 

 /*****************************************************************************************************/
聲明：本博內容均由http://blog.csdn.net/droidphone原創，轉載請注明出處，謝謝！
原文出處
http://blog.csdn.net/droidphone/article/details/7316061

/****

arrow
arrow
    全站熱搜
    創作者介紹
    創作者 立你斯 的頭像
    立你斯

    立你斯學習記錄

    立你斯 發表在 痞客邦 留言(0) 人氣()

    E-mail轉寄