2. 程式人生 > >alsa音效卡驅動分析總結 （二）

alsa音效卡驅動分析總結 （二）

阿新 • • 發佈：2019-01-06

alsa音效卡驅動分析總結 

來自：http://blog.chinaunix.net/uid-20672559-id-3515392.html

現在我們開始分析ASOC：

ASoC被分為Machine、Platform和Codec三大部分。其中的Machine驅動負責Platform和Codec之間的耦合和裝置或板子特定的程式碼。

看起來挺複雜，其實需要我們做的事情並不多，大部分核心已經完成。下面我們分析哪些是我們需要自己做的：

codec驅動：負責音訊解碼。這部分程式碼完全無平臺無關，裝置原廠提供，我們只需要把它加進核心編譯就好了。

platform驅動：與處理器晶片相關，這部分程式碼在該晶片商用之前方案產商提供的

demo板已完全確定了，也就是說我們只需要使用就可以了。

machine驅動：好了，到了最關鍵的地方了，machine驅動是耦合platform和codec驅動，同時與上層互動的程式碼。由於上層是標準的alsa架構，所以下層介面肯定要做了統一，所以我很負責的告訴你，這部分由machine本身的platform驅動和platform裝置組成(請跟asoc的platform驅動區別)，platform驅動核心幫我們完成了，所以你無須過多的關心你的驅動怎麼跟上層alsa怎麼衍接的問題，我們只需要註冊一個machine的platform裝置以及完成platform和codec耦合就ok

asoc的關係圖如下：（以下適應於

linux3.0。linux2.6會有所不同）

                                                                        

上圖把asoc架構顯示的淋漓盡致，如果你分析了asoc你就會發現上圖描述的結構以及函式真的一個都跑不了。

Machie：

Machine platform device:(~/sound/soc/samsung/smdk_wm8994.c)

  1. smdk_snd_device = platform_device_alloc("soc-audio", -1);  
  2. if (!smdk_snd_device)  
  3. return
     -ENOMEM;  
  4.     platform_set_drvdata(smdk_snd_device, &smdk);  
  5.     ret = platform_device_add(smdk_snd_device);  
  1. staticstruct snd_soc_dai_link smdk_dai[] = {  
  2.     { /* Primary DAI i/f */
  3.         .name = "WM8994 AIF1",  
  4.         .stream_name = "Pri_Dai",  
  5.         .cpu_dai_name = "samsung-i2s.0",  
  6.         .codec_dai_name = "wm8994-aif1",  
  7.         .platform_name = "samsung-audio",  
  8.         .codec_name = "wm8994-codec",  
  9.         .init = smdk_wm8994_init_paiftx,  
  10.         .ops = &smdk_ops,  
  11.     }, { /* Sec_Fifo Playback i/f */
  12.         .name = "Sec_FIFO TX",  
  13.         .stream_name = "Sec_Dai",  
  14.         .cpu_dai_name = "samsung-i2s.4",  
  15.         .codec_dai_name = "wm8994-aif1",  
  16.         .platform_name = "samsung-audio",  
  17.         .codec_name = "wm8994-codec",  
  18.         .ops = &smdk_ops,  
  19.     },  
  20. };  
  21. staticstruct snd_soc_card smdk = {  
  22.     .name = "SMDK-I2S",  
  23.     .owner = THIS_MODULE,  
  24.     .dai_link = smdk_dai,  
  25.     .num_links = ARRAY_SIZE(smdk_dai),  
  26. };  

通過snd_soc_card結構，又引出了Machine驅動的另外兩個個數據結構：

  • snd_soc_dai_link（例項：smdk_dai[] ）
  • snd_soc_ops（例項：smdk_ops ）

snd_soc_dai_link看名字就知道，很明顯它是起耦合連結作用的。它指定了Platform、Codec、codec_dai、cpu_dai的名字，稍後Machine驅動將會利用這些名字去匹配已經在系統中註冊的platform，codec，dai。

snd_soc_ops連線Platform和Codec的dai_link對應的ops操作函式，本例就是smdk_ops，它只實現了hw_params函式：smdk_hw_params。

到此為止，最主要的部分machine的平臺設備註冊我們完成了。

下面我們關注machine平臺驅動部分(這部分核心不需要我們實現，但我們需要知道它是怎麼工作的）

ASoC的platform_driver在以下檔案中定義：sound/soc/soc-core.c。

還是先從模組的入口看起：

[cpp] view plaincopy

  1. staticint __init snd_soc_init(void)  
  2. {  
  3.     ......  
  4. return platform_driver_register(&soc_driver);  
  5. }  

soc_driver的定義如下：

[cpp] view plaincopy

  1. /* ASoC platform driver */
  2. staticstruct platform_driver soc_driver = {  
  3.     .driver     = {  
  4.         .name       = "soc-audio", //確保你註冊machine平臺裝置和它保持一致
  5.         .owner      = THIS_MODULE,  
  6.         .pm     = &soc_pm_ops,  
  7.     },  
  8.     .probe      = soc_probe,  
  9.     .remove     = soc_remove,  
  10. };  

初始化入口soc_probe()

soc_probe函式本身很簡單，它先從platform_device引數中取出snd_soc_card，然後呼叫snd_soc_register_card，通過snd_soc_register_card，為snd_soc_pcm_runtime陣列申請記憶體，每一個dai_link對應snd_soc_pcm_runtime陣列的一個單元，然後把snd_soc_card中的dai_link配置複製到相應的snd_soc_pcm_runtime中，最後，大部分的工作都在snd_soc_instantiate_card中實現，下面就看看snd_soc_instantiate_card做了些什麼：

該函式首先利用card->instantiated來判斷該卡是否已經例項化，如果已經例項化則直接返回，否則遍歷每一對dai_link，進行codec、platform、dai的繫結工作，下只是程式碼的部分選節，詳細的程式碼請直接參考完整的程式碼樹。

static int soc_probe(struct platform_device *pdev){       struct snd_soc_card *card =platform_get_drvdata(pdev);//別忘記了machine的platform_set_drvdata //取出snd_soc_card       .............       ret =snd_soc_register_card(card);//註冊

        ............       }

下面我們看snd_soc_register_card()函式:

int snd_soc_register_card(struct snd_soc_card *card){。。。。。。。。       card->rtd =kzalloc(sizeof(struct snd_soc_pcm_runtime) *                        (card->num_links + card->num_aux_devs),                        GFP_KERNEL);//為snd_soc_pcm_runtime陣列申請記憶體，每一個dai_link對應一個snd_soc_pcm_runtime陣列單元。。。。。。。。       for (i = 0; i <card->num_links; i++)              card->rtd[i].dai_link= &card->dai_link[i];//把snd_soc_card中的dai_link複製到相應的snd_soc_pcm_runtime

。。。。。。。。

       snd_soc_instantiate_cards();//將呼叫snd_soc_instantiate_card()//最為重要}

下面我們分析snd_soc_instantiate_card()函式：

static void snd_soc_instantiate_card(struct snd_soc_card*card){。。。。。。。。       if (card->instantiated) {  //判斷該卡是否已經例項化，如果是就返回              mutex_unlock(&card->mutex);              return;       }       /* bind DAIs */       for (i = 0; i <card->num_links; i++) //否則遍例每一對dai_link，進行codec,flatrom,dai的繫結工作              soc_bind_dai_link(card,i);/*******************************************************************************************************************************************************************

ASoC定義了三個全域性的連結串列頭變數：codec_list、dai_list、platform_list，系統中所有的Codec、DAI、Platform都在註冊時連線到這三個全域性連結串列上。soc_bind_dai_link函式逐個掃描這三個連結串列，根據card->dai_link[]中的名稱進行匹配，匹配後把相應的codec，dai和platform例項賦值到card->rtd[]中（snd_soc_pcm_runtime）。經過這個過程後，snd_soc_pcm_runtime：（card->rtd）中儲存了本Machine中使用的Codec，DAI和Platform驅動的資訊。

*****************************************************************************************************************************************************************/       /* bind completed ? */       if (card->num_rtd !=card->num_links) {              mutex_unlock(&card->mutex);              return;       }。。。。。。。。。       /* card bind complete soregister a sound card */       ret =snd_card_create(SNDRV_DEFAULT_IDX1, SNDRV_DEFAULT_STR1,                     card->owner,0, &card->snd_card);

。。。。。。。。。       card->snd_card->dev =card->dev;       card->dapm.bias_level =SND_SOC_BIAS_OFF;       card->dapm.dev =card->dev;       card->dapm.card = card;       list_add(&card->dapm.list,&card->dapm_list);//初始化codec快取，建立音效卡例項。。。。。。。。。。。。。

//下面是最重要的probe匹配工作       if (card->probe) {              ret =card->probe(card);              if (ret < 0)                     gotocard_probe_error;       }。。。。。。。。。              ret =soc_probe_dai_link(card, i, order);//主要的耦合連結工作在此函式完成。。。。。。。。。              ret =soc_probe_aux_dev(card, i);。。。。。。。。。       if (card->late_probe) {//最後的音效卡初始化工作，              ret =card->late_probe(card);       }。。。。。。。。。       ret =snd_card_register(card->snd_card);//然後呼叫標準的alsa驅動的音效卡函式進行音效卡註冊

。。。。。。。。。       }到這裡音效卡已經註冊好了，音效卡可以正常工作了，我們再分析最後一個函式，也就是它們是怎麼匹配的 soc_probe_dai_link():

static int soc_probe_dai_link(struct snd_soc_card *card,int num, int order){。。。。。。。。。。       /* probe the cpu_dai */       if (!cpu_dai->probed&&                     cpu_dai->driver->probe_order== order) {              if(!try_module_get(cpu_dai->dev->driver->owner))                     return -ENODEV;              if(cpu_dai->driver->probe) {                     ret =cpu_dai->driver->probe(cpu_dai);                     if (ret < 0){                            printk(KERN_ERR"asoc: failed to probe CPU DAI %s\n",                                          cpu_dai->name);                            module_put(cpu_dai->dev->driver->owner);                            returnret;                     }              }              cpu_dai->probed = 1;              /* mark cpu_dai asprobed and add to card dai list */              list_add(&cpu_dai->card_list,&card->dai_dev_list);       }       /* probe the CODEC */       if (!codec->probed&&                     codec->driver->probe_order== order) {              ret =soc_probe_codec(card, codec);              if (ret < 0)                     return ret;       }       /* probe the platform */       if (!platform->probed&&                     platform->driver->probe_order== order) {              ret = soc_probe_platform(card,platform);              if (ret < 0)                     return ret;       }       /* probe the CODEC DAI */       if (!codec_dai->probed&& codec_dai->driver->probe_order == order) {              if(codec_dai->driver->probe) {                     ret =codec_dai->driver->probe(codec_dai);                     if (ret < 0){                            printk(KERN_ERR"asoc: failed to probe CODEC DAI %s\n",                                          codec_dai->name);                            returnret;                     }              }              /* mark codec_dai asprobed and add to card dai list */              codec_dai->probed =1;              list_add(&codec_dai->card_list,&card->dai_dev_list);       }       /* complete DAI probe duringlast probe */       if (order !=SND_SOC_COMP_ORDER_LAST)              return 0;

。。。。。。。。。。       /* create the pcm */       ret = soc_new_pcm(rtd, num);//如果上面都匹配成功將建立標準的alsa的pcm邏輯裝置。。。。。。。。。。       }好了，到此為止我們最主要的部分machine部分分析完成了。

相關推薦

alsa音效卡驅動分析總結 （二）

alsa音效卡驅動分析總結  來自：http://blog.chinaunix.net/uid-20672559-id-3515392.html 現在我們開始分析ASOC： ASoC被分為Machine、Platform和Codec三大部分。其中的Machine驅動負責

ALSA聲卡驅動的DAPM（二）-建立過程

使用 浪費 pri mach tin 寄存器 rac 控件 所有 在上一篇文章中，我們重點介紹了widget、path、route之間的關系及其widget的註冊； http://www.cnblogs.com/linhaostudy/p/8509899.html

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

上一篇文章中，我們介紹了音訊驅動中對基本控制單元的封裝：kcontrol。利用kcontrol，我們可以完成對音訊系統中的mixer，mux，音量控制，音效控制，以及各種開關量的控制，通過對各種kcontrol的控制，使得音訊硬體能夠按照我們預想的結果進行工作。同時我

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

前面的六篇文章，我們已經討論了dapm關於動態電源管理的有關知識，包括widget的建立和初始化，widget之間的連線以及widget的上下電順序等等。本章我們準備討論dapm框架中的另一個機制：事件機制。通過dapm事件機制，widget可以對它所關心的dapm事

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

1.  ASoC的由來 ASoC--ALSA System on Chip ，是建立在標準ALSA驅動層上，為了更好地支援嵌入式處理器和移動裝置中的音訊Codec的一套軟體體系。在ASoc出現之前，核心對於SoC中的音訊已經有部分的支援，不過會有一些侷限性：    C

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

1. struct snd_card 1.1. snd_card是什麼 snd_card可以說是整個ALSA音訊驅動最頂層的一個結構，整個音效卡的軟體邏輯結構開始於該結構，幾乎所有與聲音相關的邏輯裝置都是在snd_card的管理之下，音效卡驅動的第一個動作通常就是建立一

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

前面一節的內容我們提到，ASoC被分為Machine、Platform和Codec三大部分，其中的Machine驅動負責Platform和Codec之間的耦合以及部分和裝置或板子特定的程式碼，再次引用上一節的內容：Machine驅動負責處理機器特有的一些控制元件和音訊

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

1.  Platform驅動在ASoC中的作用 前面幾章內容已經說過，ASoC被分為Machine，Platform和Codec三大部件，Platform驅動的主要作用是完成音訊資料的管理，最終通過CPU的數字音訊介面（DAI）把音訊資料傳送給Codec進行處理，最終由Co

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

前面我們主要著重於codec、platform、machine驅動程式中如何使用和建立dapm所需要的widget，route，這些是音訊驅動開發人員必須要了解的內容，經過前幾章的介紹，我們應該知道如何在alsa音訊驅動的3大部分（codec、platform、machin

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

1. PCM是什麼         PCM是英文Pulse-code modulation的縮寫，中文譯名是脈衝編碼調製。我們知道在現實生活中，人耳聽到的聲音是模擬訊號，PCM就是要把聲音從模擬轉換成數字訊號的一種技術，他的原理簡單地說就是利用一個固定的頻率對模擬訊號進行取

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

1、在除錯中出現問題後，首先看I2C通訊有沒有問題，wm8960暫存器的設定是靠I2C來完成，另外I2C通訊不成功在開發板中是沒      有音效卡相關的裝置節點。       a、首先檢視Machi

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

三、LINPUT輸入通道介紹             有關LINPUT的主要配置如下：            R32的bit8(LMN1)置1：LINPUT1連線PGA；            R0

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

DAPM是Dynamic Audio Power Management的縮寫，直譯過來就是動態音訊電源管理的意思，DAPM是為了使基於linux的移動裝置上的音訊子系統，在任何時候都工作在最小功耗狀態下。DAPM對使用者空間的應用程式來說是透明的，所有與電源相關的開關都在A

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

1.  ASoC的由來 ASoC--ALSA System on Chip ，是建立在標準ALSA驅動層上，為了更好地支援嵌入式處理器和移動裝置中的音訊Codec的一套軟體體系。在ASoc出現之前，核心對於SoC中的音訊已經有部分的支援，不過會有一些侷限性：  

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

一.  概述     ALSA是Advanced Linux Sound Architecture 的縮寫，目前已經成為了linux的主流音訊體系結構，想了解更多的關於ALSA的這一開源專案的資訊和知識，請檢視以下網址：http://www.alsa-project.org/。     在核心裝置驅動層，

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

1.  Codec簡介 在移動裝置中，Codec的作用可以歸結為4種，分別是： 對PCM等訊號進行D/A轉換，把數字的音訊訊號轉換為模擬訊號對Mic、Linein或者其他輸入源的模擬訊號進行A/D轉換，把模擬的聲音訊號轉變CPU能夠處理的數字訊號對音訊通路進行控制，比如

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

一.  概述     ALSA是Advanced Linux Sound Architecture 的縮寫，目前已經成為了linux的主流音訊體系結構，想了解更多的關於ALSA的這一開源專案的資訊和知識，請檢視以下網址：http://www.alsa-project.org/。     在核心裝置驅動層

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

Linux ALSA 系統架構ALSA 是Linux音效卡驅動的架構，下面基於linux-2.6.32描述下ALSA系統架構。ALSA系統可以分為alsa-lib、alsa- driver，而alsa-driver又分為core層和底層硬體層。作為開發者，我們只需移植底層硬

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

Control介面 Control介面主要讓使用者空間的應用程式（alsa-lib）可以訪問和控制音訊codec晶片中的多路開關，滑動控制元件等。對於Mixer（混音）來說，Control介面顯得尤為重要，從ALSA 0.9.x版本開始，所有的mixer工作都是通過co

alsa音效卡驅動移植

1 配置核心支援UDA1341:  /* 下面是需要配置的巨集，後面函式的編譯取決這些巨集 */CONFIG_SND_S3C24XX_I2S  // s3c24xx-i2s.c CONFIG_SND_