把一塊 i.MX6ULL 板子上的聲卡整明白最繞不開的就是fsl-asoc-card.c這個驅(qū)動。它是 NXP 平臺 ASoC 機器驅(qū)動的通用實現(xiàn)負(fù)責(zé)把 CPU 側(cè)的 SAI 和外部 Codec “縫”成一張完整的 HiFi 聲卡。網(wǎng)上講 ALSA 和 ASoC 的資料不少但真到probe函數(shù)級別一段一段跟過源碼的人其實不多。這篇文章就拿fsl-asoc-card.c的 probe 流程開刀從 compatible 匹配到snd_soc_register_card把每一步在干什么、為什么要這么干講清楚。如果你正在調(diào) imx6ull 的音頻驅(qū)動或者想弄懂機器驅(qū)動怎么和 DTS 配合生成聲卡這篇逐段拆解應(yīng)該能幫你少走不少彎路。1. 先明白 fsl-asoc-card.c 到底在縫什么1.1 ASoC 的三角關(guān)系machine 就是那根線ASoC 框架把音頻驅(qū)動拆成三個角色CPU DAI、Codec、Machine。CPU DAI 在 i.MX6ULL 上就是 SAI同步音頻接口它負(fù)責(zé)把內(nèi)存里的 PCM 數(shù)據(jù)用 I2S 格式發(fā)出去Codec 是板子上的編解碼芯片比如 WM8960、SGTL5000負(fù)責(zé)把數(shù)字信號轉(zhuǎn)成模擬信號或者反過來Machine 驅(qū)動則負(fù)責(zé)把這兩者連接起來告訴 ASoC哪塊 CPU DAI 和哪顆 Codec 配對用什么采樣率、什么聲道格式?？梢赃@樣理解CPU 側(cè)就像是一個只講數(shù)字協(xié)議的搬運工Codec 是一個只懂模擬信號的翻譯官而 machine 驅(qū)動是那根電話線它要確保兩邊說的都是同一種“方言”否則音頻數(shù)據(jù)就傳不過去。fsl-asoc-card.c在 i.MX6ULL 上扮演的正是 machine 驅(qū)動這個角色。它本身不處理音頻數(shù)據(jù)也不配置硬件寄存器它只負(fù)責(zé)“牽線搭橋”告訴內(nèi)核這三者之間的連接關(guān)系。這也是為什么很多初學(xué)者上來就去找音頻數(shù)據(jù)流經(jīng)的代碼路徑找半天找不到——因為機器驅(qū)動里根本沒有音頻數(shù)據(jù)只有綁定關(guān)系和初始化順序。理解了這點你再去看probe函數(shù)里的那些結(jié)構(gòu)體賦值就不會覺得亂了。1.2 fsl-asoc-card.c 和 simple-card 的取舍內(nèi)核里其實早就有一個通用機器驅(qū)動simple-card很多平臺用它也能跑起來。那為什么 NXP 還要單獨維護一個fsl-asoc-card.c因為它比 simple-card 多做了幾件 NXP 平臺特定的事。比如說不同 Codec 對 MCLK 的頻率要求不一樣WM8960 需要 24MHz 或者 12MHz 的 SYSCLK而 SGTL5000 可能對時鐘的使能時序更敏感。fsl-asoc-card 里針對常見 Codec 做了適配能在hw_params階段正確設(shè)置 clock 和格式。另一個典型場景是 ESAI 接口的 TDM 模式simple-card 不一定能正確處理每條 DAI 的 slot 配置。加上 fsl-asoc-card 直接綁定了fsl,imx-audio-wm8960、fsl,imx-audio-sgtl5000這類 compatibleDTS 里寫起來更直觀對 NXP 參考板上常見的 Codec 型號幾乎做到開箱即用。當(dāng)然這不是說 simple-card 不行。如果你的板子用的是通用 Codec且不需要特定時鐘時序simple-card 反而更輕量。但既然你點開了fsl-asoc-card.c大概率就是用 NXP 官方的參考設(shè)計那跟著這套驅(qū)動走下去是最省事的路徑。1.3 probe 在整條鏈路里的位置一個聲卡從無到有要經(jīng)過設(shè)備樹節(jié)點匹配、platform driver probe、dai_link 填充、snd_soc_register_card 注冊、card instantiate 這一連串過程。probe函數(shù)是其中的總調(diào)度它做的事情可以歸納為三件拿到硬件信息、填充描述結(jié)構(gòu)體、把結(jié)構(gòu)體交給 ASoC 框架注冊。后面幾個章節(jié)會逐段展開這三件事。先給讀者一個心理預(yù)期fsl_asoc_card_probe本身的代碼量并不大幾十行到一百多行但它牽扯出的數(shù)據(jù)結(jié)構(gòu)很多。真正理解它的人不是記住了每一行而是明白了它往dai_link里填的那些字符串最終如何被 ASoC 框架用來查找和綁定設(shè)備。2. probe 前半場從 compatible 到私有數(shù)據(jù)就位2.1 入口函數(shù)與設(shè)備樹匹配以 5.4 版本內(nèi)核為例fsl-asoc-card.c的驅(qū)動入口用的是一個標(biāo)準(zhǔn)platform_driver結(jié)構(gòu)static const struct of_device_id fsl_asoc_card_dt_ids[] { { .compatible fsl,imx-audio-sgtl5000, }, { .compatible fsl,imx-audio-wm8960, }, { .compatible fsl,imx-audio-cs42888, }, { .compatible fsl,imx-audio-wm8962, }, { .compatible fsl,imx-audio-ak4458, }, { .compatible fsl,imx-audio-ak5558, }, { .compatible fsl,imx-audio-esai, }, { .compatible fsl,imx-audio-sai, }, {}, }; static struct platform_driver fsl_asoc_card_driver { .probe fsl_asoc_card_probe, .driver { .name fsl-asoc-card, .pm snd_soc_pm_ops, .of_match_table fsl_asoc_card_dt_ids, }, };probe函數(shù)的入口長這樣代碼有省略但核心邏輯保留static int fsl_asoc_card_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct fsl_asoc_card_priv *priv; struct device_node *np dev-of_node; int ret; priv devm_kzalloc(dev, sizeof(*priv), GFP_KERNEL); if (!priv) return -ENOMEM; priv-dev dev; dev_set_drvdata(dev, priv); /* 獲取 CPU DAI 信息 */ ret fsl_asoc_card_get_dai(priv); if (ret) return ret; /* 獲取 Codec 信息 */ ret fsl_asoc_card_get_codec(priv); if (ret) return ret; /* 填充 dai_link */ ret fsl_asoc_card_fill_dai_link(priv); if (ret) return ret; /* 注冊聲卡 */ ret snd_soc_register_card(priv-card); if (ret) { dev_err(dev, snd_soc_register_card failed: %d\n, ret); return ret; } return 0; }入口的邏輯非常直白devm_kzalloc分配一個私有數(shù)據(jù)結(jié)構(gòu)體然后依次調(diào)用幾個輔助函數(shù)去獲取 DAI、獲取 Codec、填充 dai_link最后注冊。這種寫法在 Linux 驅(qū)動里非常典型——先準(zhǔn)備數(shù)據(jù)再提交注冊。注意這里用的是devm_kzalloc它會在驅(qū)動解綁時自動釋放內(nèi)存省掉了手動kfree的麻煩也讓remove函數(shù)變得很干凈。2.2 fsl_asoc_card_priv 這個“總管”里有什么私有數(shù)據(jù)結(jié)構(gòu)體fsl_asoc_card_priv是整個聲卡驅(qū)動的“總管”它貫穿了 probe 后續(xù)的所有階段。不同內(nèi)核版本結(jié)構(gòu)體略有差異但核心字段是穩(wěn)定的struct fsl_asoc_card_priv { struct device *dev; struct snd_soc_card card; struct snd_soc_dai_link dai_link; struct snd_soc_dai_link_component cpu_dai; struct snd_soc_dai_link_component codec_dai; struct snd_soc_dai_link_component platform_dai; struct snd_soc_dai_link_component codec_component; struct fsl_asoc_dai_priv dai_priv; ... };這個結(jié)構(gòu)體的設(shè)計意圖很明顯把聲卡描述拆成 CPU DAI、Codec、Platform 三塊每一塊用snd_soc_dai_link_component記錄名字和設(shè)備節(jié)點。snd_soc_card和snd_soc_dai_link是 ASoC 框架要求填的兩大核心結(jié)構(gòu)前者代表聲卡本身后者代表一組數(shù)據(jù)鏈路。從snd_soc_dai_link_component這個命名就能看出現(xiàn)代內(nèi)核把“Codec”和“DAI”分開描述了不再像老內(nèi)核那樣把 codec 直接掛在 dai_link 上。這是一種更靈活的模型一個 Codec 芯片里可以存在多個 DAI比如 WM8960 有 AIF1、AIF2 兩個音頻接口通過 codec_dai 的名字來指定用哪一個。2.3 fsl_asoc_card_get_dai先把 CPU 側(cè)的信息摳出來fsl_asoc_card_get_dai的作用是從設(shè)備樹節(jié)點拿到 CPU DAI 的 phandle 和名字。DTS 里通常這么寫sound { compatible fsl,imx6ull-evk-wm8960, fsl,imx-audio-wm8960; model wm8960-audio; cpu-dai sai2; audio-codec wm8960; codec-dai-name wm8960-hifi; audio-routing Headphone Jack, HP_L, Headphone Jack, HP_R, LINPUT1, AMIC, LINPUT3, AMIC; mux-int-pin 1; mux-ext-pin 1; };cpu-dai sai2指向 SAI2 節(jié)點fsl_asoc_card_get_dai內(nèi)部會調(diào)用of_parse_phandle找到這個節(jié)點再讀取節(jié)點的名字最終拼出 CPU DAI 的設(shè)備名。這個設(shè)備名會填進cpu_dai組件里以后 ASoC 框架就是靠它去找已經(jīng)注冊的 DAI 設(shè)備。這里比較容易忽略的一點是CPU DAI 的設(shè)備節(jié)點必須已經(jīng)有一個對應(yīng)的平臺驅(qū)動在跑。對 SAI2 來說驅(qū)動是fsl-sai.c如果 SAI2 節(jié)點沒有status okay或者 SAI 驅(qū)動沒有成功 probe后面再怎么做聲卡匹配都會失敗而且報錯信息可能要到很晚才出現(xiàn)。2.4 fsl_asoc_card_get_codecCodec 的設(shè)備節(jié)點也要拿到與 CPU DAI 類似fsl_asoc_card_get_codec負(fù)責(zé)解析audio-codec屬性。codec 通常在 I2C 總線上比如 WM8960 掛在 I2C1 上設(shè)備節(jié)點是一個 i2c_client。驅(qū)動讀取audio-codec的 phandle同樣拿到 codec 設(shè)備的完整名字然后把它填進 codec 組件。這一步需要特別注意Codec 本身也是一個獨立驅(qū)動的設(shè)備。如果 I2C 上的 WM8960 沒有成功 probefsl_asoc_card_get_codec可能不會立刻報錯因為這里只是在解析設(shè)備樹名字并沒有去檢查設(shè)備是否活躍。等到后面snd_soc_register_card真正去綁定 codec 時才會發(fā)現(xiàn)找不到對應(yīng)的 codec 設(shè)備那時候的報錯就讓人一頭霧水了。3. probe 中場dai_link 是怎么被填出來的3.1 dai_link 的每個字段都有來歷fsl_asoc_card_fill_dai_link是 probe 里信息密度最高的一段。它把前面解析到的 CPU DAI、Codec 信息逐一填進struct snd_soc_dai_link結(jié)構(gòu)體。核心代碼大概長這樣static int fsl_asoc_card_fill_dai_link(struct fsl_asoc_card_priv *priv) { struct snd_soc_dai_link *dai_link priv-dai_link; dai_link-name HiFi; dai_link-stream_name HiFi; dai_link-cpus priv-cpu_dai; dai_link-num_cpus 1; dai_link-codecs priv-codec_component; dai_link-num_codecs 1; dai_link-platforms priv-platform_dai; dai_link-num_platforms 1; dai_link-ops fsl_asoc_card_ops; dai_link-init fsl_asoc_card_dai_init; return 0; }這里name和stream_name都叫 “HiFi”這個字符串會出現(xiàn)在聲卡的 PCM 設(shè)備名里。cpus、codecs、platforms這三組指針分別指向前面解析出的組件結(jié)構(gòu)體。ops指向的是一個回調(diào)集里面有hw_params、startup、shutdown等函數(shù)這些回調(diào)會在聲卡運行時被 ASoC 調(diào)用。init回調(diào)在 dai_link 初始化時執(zhí)行通常用于設(shè)置 codec 的私有數(shù)據(jù)或初始化 kcontrol。注意一點在老版本內(nèi)核里dai_link 直接使用cpu_dai_name、codec_name、codec_dai_name這種字符串字段而新版本改成了snd_soc_dai_link_component數(shù)組。如果你在網(wǎng)上搜到舊代碼看到字符串賦值不要奇怪那是內(nèi)核 API 演進的結(jié)果。理解這一點你查代碼時就不容易犯迷糊。3.2 codec_dai_name 是從哪來的DTS 里codec-dai-name wm8960-hifi這個屬性最終會被解析進 codec_dai 組件的dai_name字段。這個字符串必須和 codec 驅(qū)動內(nèi)部注冊的 DAI 名字完全一致多一個空格都不行。WM8960 驅(qū)動里會這樣注冊 DAIstatic struct snd_soc_dai_driver wm8960_dai { .name wm8960-hifi, .playback { ... }, .capture { ... }, };也就是說Machine 驅(qū)動說“我要用名字叫 wm8960-hifi 的 DAI”ASoC 框架就去 Codec 驅(qū)動已注冊的 DAI 列表里找這個名字。如果 DTS 里寫成了wm8960_hifi或者wm8960-hifi1那匹配就會失敗聲卡注冊就會報錯。這個設(shè)計既是 ASoC 靈活性的體現(xiàn)也是初學(xué)者最容易踩的坑。內(nèi)核打印的錯誤信息有時不夠直觀比如只顯示一個ASoC: DAI wm8960-hifi not registered如果不清楚匹配規(guī)則很難快速定位到是 DTS 里一個短橫線和下劃線的區(qū)別。3.3 ops 里藏著的 HiFi 參數(shù)控制fsl_asoc_card_ops里的核心回調(diào)是hw_params。以 WM8960 為例它需要對 codec 設(shè)置系統(tǒng)時鐘否則 Codec 內(nèi)部的 DSP 和 DAC/ADC 都起不來static int fsl_asoc_card_hw_params(struct snd_pcm_substream *substream, struct snd_pcm_hw_params *params) { struct snd_soc_pcm_runtime *rtd substream-private_data; struct fsl_asoc_card_priv *priv ...; unsigned int sample_rate params_rate(params); unsigned int mclk; /* 根據(jù)采樣率計算合適的 MCLK */ mclk fsl_asoc_card_get_mclk_rate(sample_rate, priv); /* 設(shè)置 CPU DAI 和 Codec 的系統(tǒng)時鐘 */ snd_soc_dai_set_sysclk(rtd-cpu_dai, 0, mclk, 0); snd_soc_dai_set_sysclk(rtd-codec_dai, 0, mclk, 0); return 0; }為什么要根據(jù)采樣率計算 MCLK因為常見的音頻采樣率是 8k 的整數(shù)倍和 48k 的整數(shù)倍這兩組頻率對 MCLK 的要求不同。比如 44.1kHz 系常用 22.5792MHz 或 11.2896MHz48kHz 系常用 24.576MHz 或 12.288MHz。WM8960 的 SYSCLK 要求通常是采樣率的 256 倍、384 倍、512 倍等這里 fsl-asoc-card 會優(yōu)先選擇固定的 PLL 輸出頻率讓 Codec 工作在最優(yōu)狀態(tài)。如果你在移植中改了 Codec比如把 WM8960 換成 SGTL5000就一定要關(guān)注這個fsl_asoc_card_get_mclk_rate函數(shù)。不同 Codec 的 MCLK 范圍、PLL 倍頻系數(shù)都不一樣直接套用會出現(xiàn)“播放有聲音但明顯變調(diào)”或者“錄音全是噪音”的怪問題。3.4 dai_init撥碼開關(guān)和私有設(shè)置的入口dai_link 的init回調(diào)在 ASoC 框架實例化這條路時會被調(diào)用fsl-asoc-card 里通常會在此時做一些 Codec 專屬的設(shè)置。比如從設(shè)備樹讀取audio-routing屬性創(chuàng)建音頻路由或者通過snd_soc_dapm_force_enable_pin強制開啟某個引腳。有些參考板上音頻路徑里有一個外部模擬開關(guān)切換 Line-in 和 Mic 輸入由 GPIO 控制。這時就可以在dai_init里讀取 DTS 中自定義的mux-int-pin、mux-ext-pin屬性通過snd_soc_dapm_new_controls注冊自定義開關(guān)。這也是為什么dai_init往往比hw_params更容易讓人困惑——它做的事情高度依賴具體板卡設(shè)計沒有一個統(tǒng)一套路。拿到一份不熟悉的 DTS最好的辦法是在dai_init里打一個dev_info把接收到的節(jié)點內(nèi)容打印出來再對照原理圖確認(rèn)每一個 pin 的含義。4. probe 后半場snd_soc_register_card 和那根“針線”4.1 注冊前的自檢fsl_asoc_card_fill_dai_link完成后probe 還剩最后一個關(guān)鍵動作調(diào)用snd_soc_register_card。不過在此之前有些版本會先檢查card結(jié)構(gòu)體的完整性比如 num_dapm_widgets 是否合法、driver_name 是否為空等。這些自檢邏輯散落在 ASoC 框架內(nèi)部probe 本身反而看不到太多。實際上當(dāng) fsl-asoc-card 走到snd_soc_register_card時它正在做的事情可以概括為把一張“還沒通電”的聲卡描述注冊到 ALSA 核心。注冊成功之后ALSA 核心會為它創(chuàng)建邏輯設(shè)備節(jié)點但真正的硬件初始化還要等到 card instantiate 過程。這里有一個容易混淆的概念snd_soc_register_card和后面聲卡真正變得“可用”之間還有一段路要走。它更像是在社保局登記了一個人的戶口但這個人還沒開始上班。真正的上班也就是 DAC 初始化、codec bias 上電是在 instantiate 階段完成的。4.2 snd_soc_register_card 之后發(fā)生了什么snd_soc_register_card會觸發(fā)snd_soc_instantiate_card這個過程做幾件大事第一遍歷card-dai_link數(shù)組對每個 dai_link 調(diào)用soc_bind_dai_link把 cpu_dai、codec_dai、platform 從內(nèi)核已注冊的設(shè)備列表里找出來并綁定。這就是最常報錯的地方如果找不到匹配的 CPU DAI 或 Codec這里會輸出ASoC: CPU DAI ... not registered之類的錯誤。第二對所有綁定的 DAI 調(diào)用snd_soc_dai_probe這個函數(shù)會調(diào)用 DAI 驅(qū)動自己的probe回調(diào)完成硬件初始化。對 SAI 來說就是配置引腳、時鐘、DMA 通道對 Codec 來說就是復(fù)位、初始化寄存器。第三調(diào)用card-probe回調(diào)也就是 fsl-asoc-card 里fsl_asoc_card_probe注意這個和 platform driver 的 probe 不是同一個函數(shù)只是名字容易混淆。這個回調(diào)里通常會做snd_soc_card_late_probe前的最后準(zhǔn)備比如設(shè)置 Codec 的輸出功率。這個“延遲綁定”機制是 ASoC 比老式 ALSA 驅(qū)動先進的地方。CPU DAI 和 Codec 設(shè)備不需要嚴(yán)格按順序 probe只要在snd_soc_register_card之后的某個時刻兩邊都已經(jīng)注冊好框架就能動態(tài)完成綁定。所以你會看到有時候 dmesg 里 I2C Codec 的 probe 日志出現(xiàn)在聲卡日志之后這是正?，F(xiàn)象。4.3 late_probe修音量的最后機會fsl-asoc-card 里還有一個late_probe回調(diào)通常在聲卡基本成型后調(diào)用用于處理代碼執(zhí)行順序的問題。例如 WM8960 的輸出偏置電壓需要等時鐘穩(wěn)定之后再配置放在late_probe里就比放在普通probe里更穩(wěn)妥。實戰(zhàn)中l(wèi)ate_probe常被用來打印聲卡狀態(tài)、補充創(chuàng)建 kcontrol 等操作。如果你在調(diào)試中遇到“聲卡注冊成功但 alsamixer 里找不到某個控件”可以考慮是不是控件創(chuàng)建早了或者創(chuàng)建晚了。把控件創(chuàng)建挪到late_probe往往能解決這類時序問題。5. 實際操作中的坑與排查5.1 常見報錯速查表調(diào)聲卡驅(qū)動時dmesg 里的錯誤信息是最直接的線索。我整理了一份出現(xiàn)頻率最高的報錯和對應(yīng)的排查方向報錯信息含義排查方向ASoC: CPU DAI ... not registeredCPU DAI 沒有被綁定檢查 SAI 節(jié)點 status、fsl-sai 驅(qū)動是否 probe 成功ASoC: CODEC DAI ... not registeredCodec DAI 名字不匹配核對codec-dai-name和 codec 驅(qū)動中的 dai 名字Failed to set sysclk時鐘設(shè)置失敗檢查 MCLK 引腳、PLL 配置用示波器測時鐘輸出wm8960: ASoC: error at soc_codec_probe on wm8960Codec 驅(qū)動 probe 失敗檢查 I2C 地址、I2C 通信是否正常snd_soc_register_card failed: -517依賴設(shè)備未 ready檢查是否是 -EPROBE_DEFER等待 Codec 或 SAI 驅(qū)動就緒-517這個返回值特別有意思。它對應(yīng)-EPROBE_DEFER意思是“這次先不干了等依賴的設(shè)備注冊好了再試一次”。內(nèi)核會把該 probe 插入延遲隊列等 Codec 或 SAI probe 完成后再次嘗試。所以你看到-517不代表失敗而是一種基于依賴的排隊等待機制。5.2 我踩過的三個具體坑第一個坑是codec-dai-name寫錯。曾經(jīng)把wm8960-hifi寫成wm8960_HiFi大小寫加下劃線全錯了開機后 dmesg 一直報wm8960_HiFi not registered。當(dāng)時圍著 I2C 和 GPIO 排查了半天最后用cat /sys/kernel/debug/asoc/dais查了系統(tǒng)里實際注冊的 DAI 名字才恍然大悟。這個調(diào)試節(jié)點的信息非常全強烈建議遇到 DAI 綁定問題先看一眼。第二個坑是 SAI2 的 MCLK 出不來。DTS 里明明配了fsl,sai-synchronous-rx之類的屬性但用示波器量 SAI2_MCLK 引腳始終沒有時鐘輸出。最后發(fā)現(xiàn)是 IOMUX 里少了SAI2_MCLK的 pinmux 配置引腳還處于 GPIO 模式。這個問題在 dmesg 里不會報任何錯誤因為內(nèi)核認(rèn)為時鐘已經(jīng)使能只是物理引腳沒通。第三個坑是聲卡注冊成功但沒有 PCM 設(shè)備。這種情況往往出現(xiàn)在 platform DAI 沒配對好導(dǎo)致 PCM 設(shè)備沒有創(chuàng)建成功。排查方法是aplay -l如果顯示**** List of PLAYBACK Hardware Devices ****下面一片空白多半是 codec 或 platform 的 DMA 配置有問題需要回到 SAI 的fsl-sai.c驅(qū)動里核對 DMA 綁定。5.3 怎么快速確認(rèn)聲卡已經(jīng)“縫”好確認(rèn)聲卡狀態(tài)最快的方法是看/proc/asound/cardsrootimx6ull:~# cat /proc/asound/cards 0 [wm8960audio ]: wm8960-audio - wm8960-audio wm8960-audio看到[wm8960audio]說明聲卡已經(jīng)注冊成功了。再用aplay -l查看 PCM 設(shè)備rootimx6ull:~# aplay -l **** List of PLAYBACK Hardware Devices **** card 0: wm8960audio [wm8960-audio], device 0: HiFi wm8960-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0這里的HiFi就是 dai_link 里的stream_namewm8960-hifi是 Codec 的 DAI 名字?？吹竭@一行說明從 CPU DAI 到 Codec DAI 的整條鏈路已經(jīng)綁定成功。如果還是想深入看綁定情況可以檢查 debugfsrootimx6ull:~# ls /sys/kernel/debug/asoc/ dais componentscomponents文件會列出 codec、platform、cpu_dai 等所有組件格式類似snd-soc-dummy、wm8960.0-001a、5a020000.sai這樣。逐個對照很容易發(fā)現(xiàn)問題出在哪個環(huán)節(jié)。6. 從 fsl-asoc-card 出發(fā)怎么改造成私有驅(qū)動6.1 復(fù)制代碼要克制理解后再動手很多人拿到一塊定制板子第一反應(yīng)是直接把fsl-asoc-card.c復(fù)制一份改個名字然后開始堆自己的代碼。我建議克制一下這個沖動。因為 fsl-asoc-card 里的邏輯和 DTS 的綁定關(guān)系已經(jīng)比較成熟隨意復(fù)制再修改往往會遺失掉一些隱性的處理比如特定 Codec 的時鐘表格、DAPM 路由初始化等。更穩(wěn)妥的做法是先在原版驅(qū)動上跑通聲音確認(rèn)鏈路沒有問題再把需要擴展的部分以回調(diào)或者獨立文件的方式加入。比如新 Codec 需要額外的 PLL 配置可以先在fsl_asoc_card_ops里增加一個自定義的hw_params回調(diào)而不是整個替換驅(qū)動。6.2 一個簡單例子增加自定義 DAPM 控件假設(shè)你的板子有一個 GPIO 控制的功放需要在聲卡初始化時注冊一個“功放開關(guān)”?？梢栽?card 的 probe 回調(diào)里這樣寫static const struct snd_kcontrol_new amp_controls[] { SOC_GPIO_SWITCH(Amp Switch, amp_gpio, 0, 0), }; static int fsl_asoc_card_my_probe(struct snd_soc_card *card) { struct snd_soc_card *card ...; int ret; ret snd_soc_add_card_controls(card, amp_controls, ARRAY_SIZE(amp_controls)); if (ret) return ret; return 0; }把這個回調(diào)掛到card-probe上聲卡注冊時就會自動創(chuàng)建這個 kcontrol。這樣在 tinymix 里就能看到Amp Switch可以直接控制功放通斷。6.3 個人經(jīng)驗調(diào)聲卡驅(qū)動要從“時鐘、格式、路由”三件套入手做了這么多年嵌入式音頻調(diào)試我總結(jié)出一個經(jīng)驗絕大多數(shù)聲卡問題出在三個地方——時鐘不對、格式不匹配、路由沒通。時鐘不對的表現(xiàn)是播放變調(diào)、錄音頻率漂移優(yōu)先查 MCLK 和 BCLK 的配置格式不匹配的表現(xiàn)是播放或錄音完全無聲但無報錯優(yōu)先查 I2S 格式是 I2S 還是 LEFT_J、位寬是 16bit 還是 24bit路由沒通的表現(xiàn)是聲卡注冊正常但某個通路沒聲音優(yōu)先查 DAPM 路由和 kcontrol 的開關(guān)狀態(tài)。這次拆解fsl-asoc-card.c的 probe回頭看其實就是圍繞這三件事在準(zhǔn)備數(shù)據(jù)因為只有把時鐘信息、格式信息、設(shè)備綁定信息全部填進 dai_link 和 opsASoC 框架才能在后來的hw_params階段正確執(zhí)行硬件配置。所以下次你再看到snd_soc_register_card成功但沒聲音時不用慌把這“時鐘、格式、路由”三件事各查一遍很多問題能自己浮出水面。驅(qū)動代碼只是替你把這三件事描述給了內(nèi)核真正出問題時硬件鏈路反而更容易暴露出真相。