1.  Platform驅動在ASoC中的作用

 

面幾章內容已經說過,ASoC被分為MachinePlatformCodec三大部件,Platform驅動的主要作用是完成音訊資料的管理,最終通過CPU的數位音訊介面(DAI)把音訊資料傳送給Codec進行處理,最終由Codec輸出驅動耳機或者是喇叭的音信信號。在具體實現上,ASoCPlatform驅動分為兩個部分:snd_soc_platform_driversnd_soc_dai_driver。其中,platform_driver負責管理音訊資料,把音訊資料通過dma或其他操作傳送至cpu dai中,dai_driver則主要完成cpu一側的dai的參數配置,同時也會通過一定的途徑把必要的dma等參數與 snd_soc_platform_driver進行交互。


2.  snd_soc_platform_driver的註冊

 

通常,ASoCsnd_soc_platform_driver註冊為一個系統的platform_driver,不要被這兩個相像的術語所迷惑,前者只是針對ASoC子系統的,後者是來自Linux的設備驅動模型。我們要做的就是:

 

  • 定義一個snd_soc_platform_driver結構的實例;
  • platform_driverprobe回檔中利用ASoCAPIsnd_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,觸發音效卡的machineplatformcodecdai等的匹配工作;

 

3.  cpusnd_soc_dai driver驅動的註冊

 

dai驅動通常對應cpu的一個或幾個I2S/PCM介面,與snd_soc_platform一樣,dai驅動也是實現為一個platform driver,實現一個dai驅動大致可以分為以下幾個步驟:

 

  • 定義一個snd_soc_dai_driver結構的實例;
  • 在對應的platform_driver中的probe回檔中通過APIsnd_soc_register_dai或者snd_soc_register_dais,註冊snd_soc_dai實例;
  • 實現snd_soc_dai_driver結構中的probesuspend等回檔;
  • 實現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播放streamdma資訊,例如dma的目標位址,dma傳送單元大小和通道號等;
  • capture_dma_data  同上,用於錄音stream
  • platform  指向關聯的snd_soc_platform結構;

 

snd_soc_dai_driver  該結構需要自己根據不同的soc晶片進行定義,關鍵欄位介紹如下:

 

  • proberemove  回呼函數,分別在音效卡載入和卸載時被調用;
  • suspendresume  電源管理回呼函數;
  • 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

 

poppop  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_driverpcm_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函數進一步為playbackcapture分別調用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 會被調用,在該回檔用,通常會使用apisnd_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_datacapture_dma_data欄位中,而這兩個欄位的值也是在hw_params階段,由 snd_soc_dai_driver結構的ops->hw_params回檔,利用apisnd_soc_dai_set_dma_data進 行設置的。緊隨其後,snd_soc_platform_driver結構的ops->hw_params回檔利用 apisnd_soc_dai_get_dma_data獲得這些daidma資訊,其中就包括了dma的目的地址資訊。這些dma資訊通常還會被保 存在substream->runtime->private_data中,以便在substream的整個生命週期中可以隨時獲得這些信 息,從而完成對dma的配置和操作。

 

6.2  dma buffer管理

 

播放時,應用程式把音訊資料源源不斷地寫入dma buffer中,然後相應platformdma操作則不停地從該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-libsnd_pcm_writeisnd_pcm_writen函數;
  • 應用程式使用ioctlSNDRV_PCM_IOCTL_WRITEI_FRAMESSNDRV_PCM_IOCTL_WRITEN_FRAMES
  • 應用程式使用alsa-libsnd_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_begintransfer_ack_end回檔,snd_pcm_period_elapsed還會調用這兩個回呼函數。<br>  

 

 

 

7.  圖說代碼

 

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

 

 

                                                                                  7.1   ASoC Platform驅動

 

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

 

 

                                                              7.2  private_data

 

 

 

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

/****

    全站熱搜

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