2. 程式人生 > >Linux音訊驅動之ASoC架構中的Platform

Linux音訊驅動之ASoC架構中的Platform

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

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. staticint __devinit samsung_asoc_platform_probe(struct platform_device *pdev)  
  7. {  
  8.     return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);  
  9. }  
  10. staticint __devexit samsung_asoc_platform_remove(struct platform_device *pdev)  
  11. {  
  12.     snd_soc_unregister_platform(&pdev->dev);  
  13.     return 0;  
  14. }  
  15. staticstruct platform_driver asoc_dma_driver = {  
  16.     .driver = {  
  17.         .name = "samsung-audio",  
  18.         .owner = THIS_MODULE,  
  19.     },  
  20.     .probe = samsung_asoc_platform_probe,  
  21.     .remove = __devexit_p(samsung_asoc_platform_remove),  
  22. };  
  23. 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. staticstruct 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. staticint __devinit samsung_asoc_platform_probe(struct platform_device *pdev)  
  7. {  
  8.     return snd_soc_register_platform(&pdev->dev, &samsung_asoc_platform);  
  9. }  

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

  1. staticint 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.     pr_debug("Entered %s\n", __func__);  
  7.     buf->dev.type = SNDRV_DMA_TYPE_DEV;  
  8.     buf->dev.dev = pcm->card->dev;  
  9.     buf->private_data = NULL;  
  10.     buf->area = dma_alloc_writecombine(pcm->card->dev, size,  
  11.                        &buf->addr, GFP_KERNEL);  
  12.     if (!buf->area)  
  13.         return -ENOMEM;  
  14.     buf->bytes = size;  
  15.     return 0;  
  16. }  

該函式先是獲得事先定義好的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.     elseif ((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. <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)  
  2. {  
  3.     struct snd_pcm_runtime *runtime;  
  4.     unsigned long flags;  
  5.     if (PCM_RUNTIME_CHECK(substream))  
  6.         return;  
  7.     runtime = substream->runtime;  
  8.     if (runtime->transfer_ack_begin)  
  9.         runtime->transfer_ack_begin(substream);  
  10.     snd_pcm_stream_lock_irqsave(substream, flags);  
  11.     if (!snd_pcm_running(substream) ||  
  12.         snd_pcm_update_hw_ptr0(substream, 1) < 0)  
  13.         goto _end;  
  14.     if (substream->timer_running)  
  15.         snd_timer_interrupt(substream->timer, 1);  
  16.  _end:  
  17.     snd_pcm_stream_unlock_irqrestore(substream, flags);  
  18.     if (runtime->transfer_ack_end)  
  19.         runtime->transfer_ack_end(substream);  

  20. 相關推薦

    Linux音訊驅動之ASoC架構中的Platform

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

    Linux音訊驅動之ASoC驅動架構

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

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

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

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

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

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

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

    Linux ALSA框架之七:ASoC架構中的Codec

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

    Linux音訊驅動-ASOC之Machine

    struct snd_soc_dai_link { /* config - must be set by machine driver */ const char *name; /* Codec name */ const char *stream_name; /* Stream name */

    linux音訊子系統之alsa asoc層

    ALSA SoC層概述 ALSA片上系統（ASoC）層的總體專案目標是為嵌入式片上系統處理器（例如pxa2xx，au1x00，iMX等）和行動式音訊編解碼器提供更好的ALSA支援。在ASoC子系統之前，核心對SoC音訊有一些支援，但它有一些限制： - 編解碼器驅動程式通常與底層SoC CPU緊密

    Linux 裝置驅動開發 —— 裝置樹在platform裝置驅動中的使用

             關與裝置樹的概念，我們在Exynos4412 核心移植（六）—— 裝置樹解析 裡面已經學習過，下面看一下裝置樹在裝置驅動開發中起到的作用          Device Tree是一種描述硬體的資料結構，裝置樹源(Device Tree Source)檔案

    Linux音訊驅動-AOSC之Codec

    概述 ASOC的出現是為了讓Codec獨立於CPU，減少和CPU之間的耦合，這樣同一個Codec驅動無需修改就可以適用任何一款平臺。還是以下圖做參考例子: 在Machine中已經知道，snd_soc_dai_link結構就指明瞭該Machine所使用的Platform和

    linux驅動編寫（音效卡驅動之asoc移植）

    【 宣告：版權所有，歡迎轉載，請勿用於商業用途。 聯絡信箱：feixiaoxing @163.com】    Linux下面的音效卡驅動很複雜，根本不是一篇部落格能夠說清楚的。所以，本片文章的目的就是讓

    Linux：驅動之字元裝置工作原理（未完）

    字元裝置驅動工作原理 系統整體工作原理 應用層->API->裝置驅動->硬體？ API：open、read、write、close等？ 驅動原始碼中提供真正的open、read、write、close等函式實體？ file_

    Linux：驅動之為應用程式實現呼叫（未完）

    應用程式如何呼叫驅動 目前尚不是最終版本，還望有心人自己學習的時候，把自己整合的知識點相關的答案也好問題也好，或者實踐過程中的一些操作截圖，再或者其他的一些想要分享材料發給筆者郵箱：[email protected]，我們一起完善這篇部落格！筆者寫這篇部落格

    Linux：驅動之字元設備註冊新介面（未完）

    驅動之字元設備註冊新介面 目前尚不是最終版本，還望有心人自己學習的時候，把自己整合的知識點相關的答案也好問題也好，或者實踐過程中的一些操作截圖，再或者其他的一些想要分享材料發給筆者郵箱：[email protected]，我們一起完善這篇部落格！筆者寫這篇部

    Linux音訊驅動-PCM裝置

    概述 1.  什麼是pcm？ pcm(Pulse-code modulation)脈衝編碼調製，是將模擬訊號轉化為數字訊號的一種方法。聲音的轉化的過程為，先對連續的模擬訊號按照固定頻率週期性取樣，將取樣到的資料按照一定的精度

    Linux裝置驅動之字元裝置驅動---轉

    一、linux系統將裝置分為3類：字元裝置、塊裝置、網路裝置。 應用程式呼叫的流程框圖： 三種裝置的定義分別如下， 字元裝置：只能一個位元組一個位元組的讀寫的裝置，不能隨機讀取裝置記憶體中的某一資料，讀取資料需要按照先後順序進行。字元裝置是面向流的裝置，常見的字

    linux I2C 驅動之----i2c驅動的註冊過程(i2c_register_driver->driver_register(&driver->driver)->driver_find)

    Linux下i2c驅動的載入過程，分為i2c裝置層、i2c adapter層與i2c核心層 i2c裝置驅動層也就是我們為特定i2c裝置編寫的驅動，下面是我自己理解的i2c驅動的註冊過程 在我們寫的i2c裝置驅動中，我們會呼叫i2c_add_driver()開始i2c裝

    Linux裝置驅動之workqueue----中斷底半部機制

    文章為本人學習筆記和總結，如有錯誤，請多多指教； 引言： linux實現中斷底半部的機制主要有tasklet、工作佇列、軟中斷和執行緒化； 本文主要介紹下工作佇列---workqueue 1、工作佇列（workqueue）簡介 Linux中的Workqueue機制就

    Linux裝置驅動之3.4.2核心下的I2C驅動

    框架 1.1 硬體協議簡介 1.2 驅動框架 1.3 bus-drv-dev模型及寫程式 a. 裝置的4種構建方法 詳情參照：linux-3.4.2\Documentation\i2c：instantiating-devices： 以下摘取部分

    嵌入式Linux音訊驅動開發

    1.嵌入式音訊系統硬體連線 下圖所示的嵌入式裝置使用IIS將音訊資料傳送給編解碼器。對編解碼器的I/O暫存器的程式設計通過IIC匯流排進行。 2.音訊體系結構-ALSA ALSA是Advanced Linux Sound Architecture 的縮寫，目前已經成為了li