調(diào)試一顆SPI接口的傳感器時(shí)最讓人抓狂的場(chǎng)景往往不是波形完全沒(méi)動(dòng)靜而是片選拉低了、時(shí)鐘也出來(lái)了代碼里spi_read()返回 0 表示成功緩沖區(qū)里卻清一色是 0xFF或者單字節(jié)讀 ID 一切正常一旦連續(xù)讀幾十字節(jié)就后半段全是臟數(shù)據(jù)。前面折騰寄存器手冊(cè)、上電時(shí)序、Mode 配錯(cuò)最后發(fā)現(xiàn)問(wèn)題出在對(duì)spi_message和spi_transfer的理解上——消息被拆成了幾段cs_change位置放錯(cuò)片選在中間被抬高了一次從機(jī)狀態(tài)機(jī)直接復(fù)位。這篇內(nèi)容圍繞 Linux 下 SPI 設(shè)備驅(qū)動(dòng)的數(shù)據(jù)收發(fā)處理流程把這條鏈路上真正起作用的結(jié)構(gòu)體和函數(shù)逐個(gè)拆開(kāi)講。包括spi_device、spi_driver、spi_controller這三者怎么湊到一起spi_message和spi_transfer怎么組織一次完整的事務(wù)spi_sync與spi_async的調(diào)用鏈差在哪里控制器側(cè)的transfer_one_message與set_cs又是怎么把數(shù)據(jù)真正推到時(shí)序線上的。適合已經(jīng)能寫(xiě)字符設(shè)備、但一遇到 SPI 時(shí)序問(wèn)題就卡住的驅(qū)動(dòng)開(kāi)發(fā)者也適合想把現(xiàn)有驅(qū)動(dòng)從能跑改到穩(wěn)跑的老手。下面這些內(nèi)容全部基于內(nèi)核 SPI 子系統(tǒng)的通用實(shí)現(xiàn)邏輯不同版本在字段命名上有差異比如老的spi_master后來(lái)并入spi_controller我會(huì)在關(guān)鍵處點(diǎn)出來(lái)。1. 從設(shè)備樹(shù)節(jié)點(diǎn)到 probe 函數(shù)spi_device 與 spi_driver 的匹配鏈路很多人寫(xiě) SPI 驅(qū)動(dòng)是照著模板抄的of_match_table填了、probe寫(xiě)了、spi_setup()調(diào)了設(shè)備能起來(lái)但問(wèn)到spi_device里的max_speed_hz到底是誰(shuí)填的、什么時(shí)候填的就說(shuō)不清了。而恰恰是這幾個(gè)字段決定了后面每一次傳輸?shù)臅r(shí)鐘頻率、字長(zhǎng)和片選行為配錯(cuò)了就是上面那種讀回全 FF的經(jīng)典故障。1.1 spi_device 不是驅(qū)動(dòng) new 出來(lái)的是總線枚舉出來(lái)的這一點(diǎn)必須先掰清楚。你寫(xiě)的驅(qū)動(dòng)里沒(méi)有kzalloc(sizeof(struct spi_device))spi_device是 SPI 總線在枚舉階段創(chuàng)建的驅(qū)動(dòng)只是認(rèn)領(lǐng)其中一個(gè)。整條鏈路大致是設(shè)備樹(shù)里有一個(gè)掛在 SPI 控制器下面的子節(jié)點(diǎn)帶compatible、reg、spi-max-frequency等屬性控制器驅(qū)動(dòng)在probe里注冊(cè)控制器devm_spi_register_controller內(nèi)核遍歷該控制器下的子節(jié)點(diǎn)每個(gè)子節(jié)點(diǎn)對(duì)應(yīng)調(diào)用一次spi_alloc_device()分配spi_device再由of_spi_parse_dt()或spi_device_parse_dt這類(lèi)平臺(tái)相關(guān)的解析函數(shù)把 DTS 屬性灌進(jìn)去接著spi_add_device()把這個(gè)spi_device掛到總線設(shè)備鏈表上注冊(cè)到設(shè)備模型總線開(kāi)始匹配找到spi_driver調(diào)用你的probe。所以probe被調(diào)用的時(shí)候spi-max_speed_hz、spi-mode、spi-chip_select、spi-bits_per_word這些字段已經(jīng)是從設(shè)備樹(shù)里解析好的初值。你的probe里再調(diào)spi_setup(spi)作用是把驅(qū)動(dòng)想用的配置和控制器能力做一次協(xié)商和下發(fā)而不是從零開(kāi)始填。這里有個(gè)實(shí)際影響如果你在probe里手改spi-mode但忘了重新調(diào)spi_setup()控制器寄存器還是舊配置波形不會(huì)變。反過(guò)來(lái)如果 DTS 里根本沒(méi)有spi-max-frequency解析出來(lái)的max_speed_hz可能是 0很多控制器會(huì)退化成默認(rèn)頻率常見(jiàn)是幾百 kHz 到 1 MHz這時(shí)候你會(huì)發(fā)現(xiàn)明明寫(xiě)了 10M示波器上只有 500k根子不在驅(qū)動(dòng)代碼里。1.2 關(guān)鍵字段逐個(gè)說(shuō)清楚它們的生效位置spi_device字段不少但真正影響數(shù)據(jù)收發(fā)的就這幾個(gè)我把它們和在哪一層生效對(duì)應(yīng)起來(lái)字段來(lái)源生效位置配錯(cuò)的典型表現(xiàn)max_speed_hzDTSspi-max-frequency驅(qū)動(dòng)可下調(diào)spi_transfer.speed_hz為空時(shí)用它頻率過(guò)高導(dǎo)致采樣錯(cuò)位讀回?cái)?shù)據(jù)高位錯(cuò)亂modeDTSspi-cpol/spi-cpha或spi-tx/rx-*spi_setup()下發(fā)到控制器CPOL/CPHA 反了數(shù)據(jù)整體偏移一位bits_per_wordDTS 或驅(qū)動(dòng)設(shè)置每次 transfer 繼承8/16 位混用字節(jié)序錯(cuò)亂chip_selectDTSreg控制器set_cs使用片選錯(cuò)位多個(gè)從機(jī)同時(shí)被選中cs_gpiodDTScs-gpios控制器用 GPIO 做片選時(shí)GPIO 方向或電平反了從機(jī)永遠(yuǎn)不被選中irqDTSinterrupts驅(qū)動(dòng)request_irq使用中斷觸發(fā)類(lèi)型不對(duì)讀數(shù)據(jù)永遠(yuǎn)等不到mode這個(gè)字段值得單獨(dú)說(shuō)一句。它的低兩位是 CPOL 和 CPHA高位還有SPI_CS_HIGH、SPI_LSB_FIRST、SPI_3WIRE、SPI_LOOP、SPI_NO_CS、SPI_READY這些標(biāo)志位。很多人只關(guān)心 CPOL/CPHA忽略了SPI_CS_HIGH——如果你的從機(jī)片選是高電平有效DTS 里沒(méi)寫(xiě)spi-cs-high那控制器會(huì)一直按低有效處理結(jié)果就是從機(jī)上電后始終處于選中態(tài)你發(fā)什么它都在聽(tīng)但片選松開(kāi)的動(dòng)作永遠(yuǎn)不發(fā)生從機(jī)內(nèi)部狀態(tài)機(jī)就不會(huì)復(fù)位。這類(lèi)問(wèn)題在單次讀 ID 時(shí)可能碰巧能過(guò)連續(xù)讀寫(xiě)時(shí)必然出錯(cuò)。1.3 spi_driver 的兩條匹配路徑OF 匹配與 modalias 匹配spi_driver結(jié)構(gòu)體本身很簡(jiǎn)單核心就三塊struct device_driver driver內(nèi)含of_match_table、name、pm回調(diào)、const struct spi_device_id *id_table、probe/remove。匹配走的是 SPI 總線的match函數(shù)邏輯順序是先看of_driver_match_device()也就是of_match_table里的compatible和設(shè)備樹(shù)節(jié)點(diǎn)比對(duì)如果不匹配再看spi_match_device()用id_table里的名字和spi-modalias比對(duì)兩條都不中設(shè)備就掛著沒(méi)人管/sys/bus/spi/devices/下能看到它但driver鏈接是空的。提示modalias一般由compatible字符串轉(zhuǎn)換而來(lái)斜杠、逗號(hào)之類(lèi)的字符會(huì)被替換所以只寫(xiě)of_match_table通常也能匹配上但在某些用spi_board_info靜態(tài)注冊(cè)設(shè)備的平臺(tái)上modalias來(lái)自spi_board_info.modalias這時(shí)候id_table就是必須的。兩種都寫(xiě)是最穩(wěn)的做法。probe的返回值也有講究。返回 0 表示接管成功返回-ENODEV或-ENXIO表示這個(gè)設(shè)備我不認(rèn)識(shí)總線會(huì)繼續(xù)嘗試其他驅(qū)動(dòng)在有多驅(qū)動(dòng)競(jìng)爭(zhēng)同一 compatible 時(shí)有用返回其他負(fù)值則是硬失敗設(shè)備進(jìn)入probe failed狀態(tài)不會(huì)再重試。我見(jiàn)過(guò)把-EPROBE_DEFER寫(xiě)成-EAGAIN的結(jié)果電源管理芯片還沒(méi)就緒SPI 設(shè)備直接放棄注冊(cè)后續(xù)永遠(yuǎn)起不來(lái)。2. spi_message 與 spi_transfer一次事務(wù)到底被拆成了什么如果說(shuō)spi_device是跟誰(shuí)說(shuō)話那spi_message就是這一趟要說(shuō)幾句、每句多長(zhǎng)。這是整個(gè) SPI 驅(qū)動(dòng)里最需要?jiǎng)幽X子設(shè)計(jì)的地方也是最容易埋坑的地方。因?yàn)?SPI 是全雙工但半雙工時(shí)序的總線一次片選拉低期間可以連續(xù)發(fā)多段數(shù)據(jù)、中間夾延時(shí)、甚至在中途抬片選這些復(fù)雜行為全靠spi_message里掛的spi_transfer鏈表來(lái)描述。2.1 spi_transfer 的字段決定了每一段的物理形態(tài)一個(gè)spi_transfer描述一段連續(xù)傳輸核心字段tx_buf/rx_buf發(fā)送和接收緩沖區(qū)指針可以為 NULL。兩個(gè)都為 NULL 就是純延時(shí)配合delay用。len這一段傳輸?shù)淖止?jié)數(shù)。speed_hz本段專(zhuān)用頻率為 0 則繼承spi_device.max_speed_hz。bits_per_word本段專(zhuān)用字長(zhǎng)為 0 則繼承。delay這一段結(jié)束后、下一段開(kāi)始前的延時(shí)結(jié)構(gòu)體spi_delay支持微秒和納秒兩種單位。cs_change這一段結(jié)束后是否改變片選狀態(tài)語(yǔ)義在不同上下文下不一樣后面細(xì)講。tx_nbits/rx_nbits單線、雙線、四線、八線模式用于 QSPI/OctalSPI。tx_dma/rx_dmaDMA 地址僅當(dāng)is_dma_mapped為真時(shí)有效老式用法新代碼基本不用。這里最容易搞錯(cuò)的是delay和cs_change的組合語(yǔ)義。舉個(gè)真實(shí)場(chǎng)景讀一個(gè) SPI 接口的 ADC協(xié)議要求發(fā)命令字 → 等 10 微秒轉(zhuǎn)換 → 讀結(jié)果。正確做法是三段 transfer第一段tx_buf cmd, len 1發(fā)命令第二段tx_buf NULL, rx_buf NULL, len 0, delay 10us純延時(shí)第三段rx_buf buf, len 2讀結(jié)果。如果圖省事把延時(shí)塞在第二段的delay上然后直接讀你會(huì)發(fā)現(xiàn)時(shí)鐘線在延時(shí)期間的狀態(tài)不符合從機(jī)要求——因?yàn)檠訒r(shí)發(fā)生在段與段之間片選保持低電平但時(shí)鐘停在最后一個(gè)邊沿某些從機(jī)會(huì)把這當(dāng)成一次額外的時(shí)鐘跳變。這種情況在手冊(cè)里通常寫(xiě)成CS must remain low during conversion但沒(méi)告訴你 SCLK 要保持什么電平只能靠示波器驗(yàn)證。2.2 棧上分配 message 是常見(jiàn)做法但異步場(chǎng)景下是致命錯(cuò)誤標(biāo)準(zhǔn)寫(xiě)法是這樣的struct spi_transfer xfer { .tx_buf tx, .rx_buf rx, .len len, }; struct spi_message msg; spi_message_init(msg); spi_message_add_tail(xfer, msg); ret spi_sync(spi, msg);spi_message_init()做的是INIT_LIST_HEAD(msg-transfers)加上若干字段清零spi_message_add_tail()把 transfer 掛到鏈表尾部并累加frame_length。這兩個(gè)函數(shù)本身沒(méi)有內(nèi)存分配所以把 message 和 transfer 放在棧上是完全合法且最常見(jiàn)的做法——前提是用spi_sync。換成spi_async就完全不一樣了。spi_async在把消息掛進(jìn)控制器的隊(duì)列后就返回了真正的傳輸是異步完成的。如果你在函數(shù)里定義棧上的spi_message函數(shù)一返回棧幀被覆蓋控制器后面再去訪問(wèn)msg-transfers鏈表讀到的就是垃圾指針。表現(xiàn)出來(lái)往往是隨機(jī)的內(nèi)核 oops而且現(xiàn)場(chǎng)很難復(fù)現(xiàn)因?yàn)槿Q于棧被覆寫(xiě)的時(shí)機(jī)。正確做法是用spi_async時(shí)把spi_message和spi_transfer一起嵌進(jìn)驅(qū)動(dòng)的私有結(jié)構(gòu)體用kzalloc分配或作為設(shè)備結(jié)構(gòu)體成員并在complete回調(diào)里統(tǒng)一釋放。這個(gè)坑我在早期項(xiàng)目里踩過(guò)一次現(xiàn)象是高負(fù)載下偶發(fā) panic查了兩天才定位到。2.3 什么時(shí)候必須拆成多段什么時(shí)候一段就夠判斷標(biāo)準(zhǔn)其實(shí)只有一條從機(jī)的協(xié)議是否要求在某段數(shù)據(jù)之間插入片選變化或延時(shí)空檔。不需要就合并成一段需要就拆。合并的好處很實(shí)際減少 message 內(nèi)部循環(huán)次數(shù)、減少控制器與驅(qū)動(dòng)的交互開(kāi)銷(xiāo)、對(duì) DMA 更友好長(zhǎng)連續(xù)緩沖區(qū)比多段短緩沖區(qū)更容易映射成大塊。有些控制器對(duì)單個(gè) transfer 有長(zhǎng)度上限controller-max_transfer_size超過(guò)需要驅(qū)動(dòng)自己拆但這個(gè)是控制器能力限制和協(xié)議要求是兩回事。需要拆的典型情況命令與數(shù)據(jù)之間有轉(zhuǎn)換時(shí)間要求如某些溫濕度傳感器讀操作要求先寫(xiě)地址、抬片選、再拉低片選讀數(shù)據(jù)部分 EEPROM 的時(shí)序需要在同一片選周期內(nèi)切換頻率speed_hz是 per-transfer 的整段 message 共享頻率的話就不需要拆全雙工通信里發(fā)送和接收長(zhǎng)度不對(duì)稱(chēng)且硬件 FIFO 深度有限。spi_write_then_read()這個(gè)輔助函數(shù)就是兩段合并的封裝它內(nèi)部構(gòu)造兩段 transfer寫(xiě) 讀中間不抬片選適合絕大多數(shù)寄存器地址 讀數(shù)據(jù)的場(chǎng)景。但要注意它有棧上分配內(nèi)部 buffer 的行為傳輸長(zhǎng)度受SPI_BUFSIZ限制通常是 32 字節(jié)左右超過(guò)就得自己拼 message。3. spi_sync 與 spi_async調(diào)用鏈一同步一異步語(yǔ)義差別很大很多驅(qū)動(dòng)里spi_sync和spi_async是混著用的初始化讀 ID 用spi_sync中斷里讀數(shù)據(jù)用spi_async。但兩者的調(diào)用鏈和控制流完全不同混用不當(dāng)就會(huì)出問(wèn)題——最常見(jiàn)的是在原子上下文里調(diào)spi_sync導(dǎo)致睡眠告警或者spi_async的返回值被誤當(dāng)成傳輸完成。3.1 spi_sync 的執(zhí)行路徑與返回值語(yǔ)義spi_sync(spi, message)內(nèi)部大致是加總線鎖spi_bus_lock保證同一時(shí)刻一個(gè)控制器上只有一個(gè) message 在處理把 message 掛進(jìn)controller-queue調(diào)用控制器的transfer老接口或transfer_one_message新接口啟動(dòng)傳輸用completion等待傳輸結(jié)束wait_for_completion喚醒后返回message-status。關(guān)鍵點(diǎn)在于spi_sync是可能睡眠的。它要等 completion要持有可睡眠的鎖所以絕對(duì)不能在中斷上下文、軟中斷、或者持有自旋鎖的區(qū)域里調(diào)用。真在中斷里需要發(fā)數(shù)據(jù)只能用spi_async或者把工作推給 workqueue/線程化中斷。返回值語(yǔ)義也要注意spi_sync返回 0 只代表消息走完了流程沒(méi)有報(bào)錯(cuò)不代表從機(jī)給出了有效應(yīng)答。從機(jī)不回?cái)?shù)據(jù)、總線被拉死、MISO 懸空spi_sync照樣返回 0只有超時(shí)或控制器報(bào)錯(cuò)才會(huì)返回負(fù)值。所以判斷通信是否成功必須校驗(yàn)接收緩沖區(qū)內(nèi)容比如讀 ID 寄存器比對(duì)預(yù)期值不能只看返回值。message-actual_length是另一個(gè)有用的字段它記錄了實(shí)際傳輸?shù)淖止?jié)數(shù)。正常情況下等于frame_length但如果控制器中途出錯(cuò)或被信號(hào)打斷actual_length會(huì)比預(yù)期小這時(shí)候即使status是 0也要當(dāng)作部分失敗處理。3.2 spi_async 的回調(diào)上下文與資源釋放時(shí)機(jī)spi_async(spi, message)的返回值含義和spi_sync完全不同返回 0消息已成功入隊(duì)傳輸會(huì)在稍后發(fā)生返回負(fù)值入隊(duì)失敗消息根本沒(méi)發(fā)出去complete回調(diào)不會(huì)被調(diào)用。入隊(duì)成功后控制器完成傳輸時(shí)會(huì)調(diào)用message-complete(message-context)。這個(gè)回調(diào)可能在中斷上下文里執(zhí)行所以里面不能睡眠、不能調(diào)spi_sync、不能kfree帶鎖的資源用kfree本身可以但不能在里面等待。回調(diào)里通常只做三件事置完成標(biāo)志、喚醒等待隊(duì)列、把數(shù)據(jù)掛到環(huán)形緩沖區(qū)。資源釋放的時(shí)機(jī)是另一個(gè)高頻錯(cuò)誤點(diǎn)。很多人寫(xiě)成ret spi_async(spi, msg); if (ret 0) kfree(msg.transfers); /* 錯(cuò)傳輸還沒(méi)開(kāi)始 */正確的做法是讓complete回調(diào)負(fù)責(zé)釋放或者用一個(gè)引用計(jì)數(shù)把驅(qū)動(dòng)持有和控制器持有分開(kāi)。更省事的做法是把 message 和 transfer 內(nèi)嵌在設(shè)備私有結(jié)構(gòu)體里用一把自旋鎖保護(hù)當(dāng)前是否有傳輸在進(jìn)行的狀態(tài)而不是每次動(dòng)態(tài)分配。注意spi_async不保證消息按調(diào)用順序執(zhí)行雖然多數(shù)控制器內(nèi)部是 FIFO 隊(duì)列但驅(qū)動(dòng)層不該依賴(lài)這個(gè)假設(shè)。如果協(xié)議有嚴(yán)格順序要求比如先配置寄存器再讀數(shù)據(jù)要么用spi_sync串起來(lái)要么自己在驅(qū)動(dòng)層維護(hù)隊(duì)列等上一個(gè)回調(diào)完成再發(fā)下一個(gè)。3.3 transfer_one_message 與 transfer_one控制器側(cè)的兩套接口寫(xiě)設(shè)備驅(qū)動(dòng)的人一般不用直接碰這兩個(gè)但理解它們有助于判斷問(wèn)題出在驅(qū)動(dòng)還是控制器。spi_controller里有兩個(gè)回調(diào)transfer_one_message(ctlr, msg)控制器負(fù)責(zé)整條 message 的處理自己遍歷 transfer 鏈表處理片選、延時(shí)、頻率切換全部完成后調(diào)spi_finalize_current_message(ctlr)。返回 0 表示已接管稍后完成。transfer_one(ctlr, msg, xfer)控制器只處理一段transfer返回 1 表示這段已完成且整條 message 也完成返回 0 表示這段已啟動(dòng)但異步完成返回負(fù)值表示出錯(cuò)。由 SPI 核心的spi_transfer_one_message()負(fù)責(zé)遍歷鏈表、調(diào)set_cs、調(diào)spi_transfer_delay_exec?，F(xiàn)代驅(qū)動(dòng)大多實(shí)現(xiàn)transfer_one因?yàn)楹诵膸湍闾幚砹随湵肀闅v和延時(shí)控制器只需要關(guān)心怎么把一段 buffer 變成時(shí)序。但這也意味著延時(shí)和片選的語(yǔ)義由核心統(tǒng)一解釋你在設(shè)備驅(qū)動(dòng)里寫(xiě)的delay和cs_change最終是被spi_transfer_delay_exec()和spi_set_cs()消費(fèi)的。4. 片選與延時(shí)被低估的時(shí)序細(xì)節(jié)全在 spi_controller 這一側(cè)數(shù)據(jù)收發(fā)出問(wèn)題八九成的根因不在數(shù)據(jù)緩沖區(qū)而在片選和延時(shí)。這兩個(gè)東西在設(shè)備驅(qū)動(dòng)代碼里通常只體現(xiàn)為一個(gè)cs_change標(biāo)志和一個(gè)delay字段但它們?cè)诳刂破鱾?cè)的執(zhí)行方式直接決定了波形長(zhǎng)什么樣。4.1 set_cs 與 cs_gpiod片選到底是硬件還是 GPIOspi_controller有兩種片選實(shí)現(xiàn)方式硬件片選控制器外設(shè)自帶 CS 引腳驅(qū)動(dòng)實(shí)現(xiàn)set_cs(ctlr, spi, enable)回調(diào)直接寫(xiě)寄存器。這種方式時(shí)序最準(zhǔn)片選動(dòng)作和時(shí)鐘邊沿的間隔由硬件保證。GPIO 片選DTS 里寫(xiě)cs-gpios核心把 GPIO 描述符填進(jìn)spi-cs_gpiod由核心的spi_set_cs()統(tǒng)一操作 GPIO。這種方式靈活但時(shí)序精度差——GPIO 操作要經(jīng)過(guò)幾層函數(shù)調(diào)用片選到第一個(gè)時(shí)鐘邊沿的建立時(shí)間可能達(dá)到微秒級(jí)。對(duì)于高速 SPI比如 20 MHz 以上GPIO 片選經(jīng)常導(dǎo)致第一個(gè)字節(jié)采樣錯(cuò)誤因?yàn)槠x建立時(shí)間不夠。解決方式有兩種一是改用控制器硬件片選二是在 DTS 里配置cs-setup-us對(duì)應(yīng)spi-cs_setup來(lái)插入建立延時(shí)代價(jià)是降低吞吐。還有一個(gè)容易忽略的字段cs_inactive。它定義片選無(wú)效時(shí)的電平默認(rèn)是高電平對(duì)應(yīng)低有效片選。如果從機(jī)是高有效片選除了SPI_CS_HIGH標(biāo)志還要確認(rèn)cs_inactive的值和硬件實(shí)際電平匹配否則會(huì)出現(xiàn)片選看起來(lái)在動(dòng)但邏輯反了的情況。4.2 delay 的兩種單位與 spi_transfer_delay_exec 的執(zhí)行位置spi_transfer.delay是struct spi_delay類(lèi)型里面有一個(gè)value和一個(gè)unit單位可以是SPI_DELAY_UNIT_USECS或SPI_DELAY_UNIT_NSECS。早期內(nèi)核用的是delay_usecs純微秒新代碼建議用delay結(jié)構(gòu)體因?yàn)榧{秒級(jí)延時(shí)在高速時(shí)序里是剛需。執(zhí)行位置在spi_transfer_one_message()的循環(huán)里一段 transfer 交給控制器完成或啟動(dòng)后核心調(diào)用spi_transfer_delay_exec(xfer)執(zhí)行延時(shí)然后根據(jù)cs_change決定是否調(diào)spi_set_cs()。這里的執(zhí)行順序是先延時(shí)后處理片選。所以如果你寫(xiě)延時(shí) 10 微秒后抬片選寫(xiě)法是delay 10uscs_change 1而不是反過(guò)來(lái)。理解這一點(diǎn)很多片選提前松開(kāi)的詭異現(xiàn)象就解釋得通了。納秒級(jí)延時(shí)的實(shí)現(xiàn)方式取決于平臺(tái)有的用ndelay()有的用控制器自帶的延時(shí)計(jì)數(shù)器更準(zhǔn)有的干脆退化成udelay()不準(zhǔn)。如果協(xié)議要求嚴(yán)格的納秒級(jí)間隔比如某些高速 ADC 的轉(zhuǎn)換觸發(fā)最好確認(rèn)控制器是否支持硬件延時(shí)否則只能降頻換取時(shí)序余量。4.3 cs_change 的三層語(yǔ)義別只記一種cs_change的含義在不同位置完全不同這是 SPI 子系統(tǒng)里最容易誤用的字段場(chǎng)景cs_change 語(yǔ)義一段 transfer 之后后面還有別的 transfer抬片選、再拉低制造一個(gè)片選脈沖最后一段 transfer 之后傳輸結(jié)束后保持片選有效不抬只有一段 transfer 的 message同上傳輸結(jié)束后保持片選也就是說(shuō)cs_change 1在中間位置是切換在末尾位置是保持。很多人以為它統(tǒng)一是切換片選結(jié)果在單段 message 上設(shè)了cs_change 1期望傳輸完抬片選實(shí)際卻是一直保持低電平從機(jī)永遠(yuǎn)不釋放總線下一次通信直接沖突。這個(gè)設(shè)計(jì)的歷史原因是為了支持多次 message 共享一個(gè)片選周期的場(chǎng)景。要讓片選在末尾抬起正確做法是cs_change 0默認(rèn)值。4.4 頻率切換的實(shí)際代價(jià)speed_hz是 per-transfer 的看起來(lái)可以隨意在 message 內(nèi)部切頻率。但實(shí)際執(zhí)行時(shí)控制器每次切換頻率都要重算分頻寄存器某些控制器還會(huì)有切換后需要等待若干個(gè)時(shí)鐘周期穩(wěn)定的隱性要求。如果 message 里塞了七八段不同頻率的 transfer實(shí)際吞吐可能比單一頻率還低。我的經(jīng)驗(yàn)是除非協(xié)議強(qiáng)制要求比如配置階段用低頻、數(shù)據(jù)傳輸用高頻否則整條 message 用統(tǒng)一頻率靠spi_device.max_speed_hz一次性設(shè)定。真要分段改頻率把不同頻率的部分拆成獨(dú)立 message中間用spi_sync串起來(lái)代碼更清晰調(diào)試也更容易。5. 排查鏈路實(shí)錄從讀回全 FF到定位到具體字段理論講完說(shuō)點(diǎn)實(shí)際的。下面這條排查鏈路是我在一個(gè) SPI 傳感器項(xiàng)目里真實(shí)走過(guò)的順序基本可以復(fù)用到大多數(shù)通信不通的場(chǎng)景。5.1 第一步永遠(yuǎn)是確認(rèn)物理層而不是改代碼拿到讀回全 FF的現(xiàn)象先別急著懷疑驅(qū)動(dòng)。全 FF 意味著 MISO 一直保持高電平可能的原因有從機(jī)沒(méi)上電、從機(jī)沒(méi)被片選選中、MISO 線沒(méi)接、從機(jī)處于復(fù)位狀態(tài)、從機(jī)根本沒(méi)收到有效命令。用邏輯分析儀抓四根線CS、SCLK、MOSI、MISO看三件事片選有沒(méi)有真的被拉低如果一直是高問(wèn)題在片選配置SCLK 有沒(méi)有波形如果沒(méi)有檢查控制器是否真的啟動(dòng)了傳輸或者時(shí)鐘引腳復(fù)用沒(méi)配對(duì)MOSI 上發(fā)的字節(jié)和代碼里寫(xiě)的是否一致如果 MOSI 全 0說(shuō)明發(fā)送緩沖區(qū)根本沒(méi)被控制器讀到。這一步能排掉一半的問(wèn)題。我遇到過(guò)一次spi_sync返回 0、波形全無(wú)最后發(fā)現(xiàn)是控制器的時(shí)鐘門(mén)控沒(méi)開(kāi)probe里漏了clk_prepare_enable()。代碼層面完全看不出來(lái)只有波形能告訴你真相。5.2 波形正常但數(shù)據(jù)錯(cuò)按 mode、字長(zhǎng)、字節(jié)序的順序排波形有了數(shù)據(jù)不對(duì)按這個(gè)順序排ModeCPOL/CPHA 四種組合抓波形對(duì)照從機(jī)手冊(cè)的時(shí)序圖。CPHA 錯(cuò)位表現(xiàn)為數(shù)據(jù)整體偏移半個(gè)到一個(gè)時(shí)鐘讀出來(lái)的值看著像但不對(duì)。字長(zhǎng)bits_per_word是 8 還是 16如果從機(jī)是 16 位寄存器、你按 8 位發(fā)地址會(huì)被拆成兩個(gè)字節(jié)從機(jī)收到的是錯(cuò)誤地址。字節(jié)序SPI_LSB_FIRST標(biāo)志。絕大多數(shù) SPI 器件是 MSB first但有些傳感器是 LSB first配反了讀出來(lái)的值位序是鏡像的。位寬模式單線、雙線、四線。tx_nbits配成 2 但硬件只接了 MOSI 一根線數(shù)據(jù)會(huì)丟一半。這四項(xiàng)里Mode 和字長(zhǎng)占問(wèn)題總量的八成以上。我現(xiàn)在的習(xí)慣是新器件上手先用最低頻率1 MHz 以下、8 位字長(zhǎng)、Mode 0 跑通讀 ID再逐步往上加頻率和改 Mode每改一項(xiàng)驗(yàn)證一次出問(wèn)題立刻知道是哪一項(xiàng)。5.3 短傳輸正常、長(zhǎng)傳輸出錯(cuò)看長(zhǎng)度上限和 DMA 對(duì)齊這是另一類(lèi)高頻問(wèn)題。單字節(jié)讀 ID 正常連續(xù)讀 64 字節(jié)就后半段全是臟數(shù)據(jù)。原因通常有三個(gè)控制器單次傳輸長(zhǎng)度上限。controller-max_transfer_size和max_message_size是控制器能力聲明如果超了有的控制器會(huì)截?cái)嘤械闹苯訄?bào)錯(cuò)。查/sys/class/spi_master/spiX/下有沒(méi)有相關(guān)屬性或者在驅(qū)動(dòng)里讀ctlr-max_transfer_size判斷。DMA 緩沖區(qū)對(duì)齊。走 DMA 的控制器通常要求緩沖區(qū)按 cache line 對(duì)齊32 或 64 字節(jié)。用kmalloc分配的緩沖區(qū)不保證對(duì)齊棧上的緩沖區(qū)更是隨機(jī)。表現(xiàn)為前半段對(duì)、后半段錯(cuò)因?yàn)榭?cache line 的部分被 DMA 跳過(guò)或重復(fù)搬運(yùn)。解決辦法是用dma_alloc_coherent()或者在spi_message上依賴(lài)核心的spi_map_msg()做 bounce buffer。從機(jī) FIFO 深度限制。有些從機(jī)的接收 FIFO 只有 8 字節(jié)你連續(xù)發(fā) 64 字節(jié)超出部分被丟棄。這種情況必須在 message 里拆段每段之間加延時(shí)等從機(jī)取走數(shù)據(jù)。5.4 用 spi_statistics 和動(dòng)態(tài)調(diào)試定位瓶頸內(nèi)核給每個(gè)spi_device和spi_controller都掛了統(tǒng)計(jì)計(jì)數(shù)器在/sys/class/spi_master/spiX/statistics/和/sys/class/spi_master/spiX/spiX.Y/statistics/下可以看到bytes_tx/bytes_rx累計(jì)收發(fā)字節(jié)數(shù)和你代碼里的預(yù)期對(duì)不上就說(shuō)明有傳輸被丟棄messages/transfers消息數(shù)和段數(shù)用來(lái)驗(yàn)證 message 拆分是否符合預(yù)期errors錯(cuò)誤計(jì)數(shù)配合timedout判斷是不是超時(shí)spi_sync/spi_async兩種調(diào)用的次數(shù)。排查時(shí)先cat一遍這些計(jì)數(shù)器跑一輪測(cè)試再cat一遍差值能告訴你很多信息。比如messages增加了 1 但transfers增加了 5說(shuō)明你的 message 被拆成了 5 段如果預(yù)期是 2 段那拆分邏輯就有問(wèn)題。動(dòng)態(tài)調(diào)試也很實(shí)用echo file spi.c p /sys/kernel/debug/dynamic_debug/control echo file spi-mem.c p /sys/kernel/debug/dynamic_debug/control dmesg -w打開(kāi)后能看到每次spi_sync的 message 長(zhǎng)度、每段 transfer 的參數(shù)、控制器的啟動(dòng)和完成時(shí)間點(diǎn)。配合 ftrace 的irqsoff或preemptofftracer還能看出傳輸過(guò)程中是否被中斷打斷。6. 一份能直接改著用的驅(qū)動(dòng)骨架最后給一份完整骨架覆蓋注冊(cè)、probe、讀寫(xiě)封裝、卸載。省略了具體寄存器操作重點(diǎn)在結(jié)構(gòu)體初始化和 message 組織方式上。6.1 私有結(jié)構(gòu)體與驅(qū)動(dòng)的注冊(cè)struct myspi_dev { struct spi_device *spi; struct mutex io_lock; /* 串行化并發(fā)訪問(wèn) */ u8 *tx_buf; u8 *rx_buf; struct spi_transfer xfer; struct spi_message msg; }; static const struct of_device_id myspi_of_match[] { { .compatible vendor,myspi-sensor }, { } }; MODULE_DEVICE_TABLE(of, myspi_of_match); static const struct spi_device_id myspi_id[] { { myspi-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(spi, myspi_id); static struct spi_driver myspi_driver { .driver { .name myspi-sensor, .of_match_table myspi_of_match, .pm myspi_pm_ops, }, .id_table myspi_id, .probe myspi_probe, .remove myspi_remove, }; module_spi_driver(myspi_driver);module_spi_driver()展開(kāi)后就是spi_register_driver()加模塊退出時(shí)的spi_unregister_driver()。id_table和of_match_table都寫(xiě)覆蓋 DTS 枚舉和spi_board_info靜態(tài)注冊(cè)兩條路徑。6.2 probe 里必須做的事static int myspi_probe(struct spi_device *spi) { struct myspi_dev *dev; int ret; dev devm_kzalloc(spi-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-spi spi; mutex_init(dev-io_lock); spi_set_drvdata(spi, dev); /* 頻率不超過(guò)從機(jī)上限字長(zhǎng)固定 8 位Mode 從 DTS 繼承 */ spi-max_speed_hz min(spi-max_speed_hz, 10000000u); spi-bits_per_word 8; spi-mode ~SPI_MODE_X_MASK; /* 如需強(qiáng)制 Mode 0可在此處改 */ ret spi_setup(spi); if (ret) { dev_err(spi-dev, spi_setup failed: %d\n, ret); return ret; } dev-tx_buf devm_kmalloc(spi-dev, MYSPI_MAX_XFER, GFP_KERNEL | __GFP_DMA); dev-rx_buf devm_kmalloc(spi-dev, MYSPI_MAX_XFER, GFP_KERNEL | __GFP_DMA); if (!dev-tx_buf || !dev-rx_buf) return -ENOMEM; spi_message_init(dev-msg); dev-xfer.tx_buf dev-tx_buf; dev-xfer.rx_buf dev-rx_buf; spi_message_add_tail(dev-xfer, dev-msg); return myspi_hw_init(dev); }幾個(gè)細(xì)節(jié)緩沖區(qū)用__GFP_DMA分配是為了提高 DMA 可用概率但真正的 cache line 對(duì)齊還要靠dma_alloc_coherentspi_setup()必須在改完mode/bits_per_word/max_speed_hz之后調(diào)用否則改動(dòng)不生效spi_message_init和spi_message_add_tail放在 probe 里做一次后續(xù)每次傳輸只改xfer.len和緩沖區(qū)內(nèi)容減少重復(fù)開(kāi)銷(xiāo)。6.3 讀寫(xiě)封裝一段式 message 的復(fù)用static int myspi_xfer(struct myspi_dev *dev, const u8 *tx, u8 *rx, size_t len) { int ret; if (len 0 || len MYSPI_MAX_XFER) return -EINVAL; mutex_lock(dev-io_lock); if (tx) memcpy(dev-tx_buf, tx, len); else memset(dev-tx_buf, 0, len); dev-xfer.len len; dev-xfer.speed_hz 0; /* 繼承 spi_device 設(shè)置 */ dev-xfer.bits_per_word 0; dev-xfer.delay.value 0; dev-xfer.cs_change 0; ret spi_sync(dev-spi, dev-msg); if (ret 0 rx) memcpy(rx, dev-rx_buf, len); mutex_unlock(dev-io_lock); return ret; }用mutex而不是自旋鎖因?yàn)閟pi_sync會(huì)睡眠。xfer和msg在結(jié)構(gòu)體里復(fù)用避免每次動(dòng)態(tài)分配。傳輸完成后memcpy出來(lái)是因?yàn)橄乱淮蝹鬏敃?huì)覆蓋rx_buf不拷走的話數(shù)據(jù)就丟了。單段 message 里cs_change保持 0傳輸結(jié)束后片選自動(dòng)抬起這是絕大多數(shù)從機(jī)期望的行為。如果從機(jī)要求多段之間保持片選才需要構(gòu)造多段 message 并單獨(dú)處理cs_change。6.4 remove 與異常路徑static void myspi_remove(struct spi_device *spi) { struct myspi_dev *dev spi_get_drvdata(spi); myspi_hw_suspend(dev); /* mutex 不需要顯式銷(xiāo)毀devm 分配的內(nèi)存自動(dòng)釋放 */ }因?yàn)槿坑胐evm_*分配remove 里基本不用手動(dòng)釋放。唯一要注意的是如果驅(qū)動(dòng)里用了spi_asyncremove 之前必須確保沒(méi)有正在進(jìn)行的傳輸否則回調(diào)觸發(fā)時(shí)私有結(jié)構(gòu)體已經(jīng)被釋放。做法是在 remove 里先置一個(gè)shutdown標(biāo)志然后wait_for_completion_timeout()等當(dāng)前傳輸結(jié)束。7. 幾個(gè)用血換來(lái)的經(jīng)驗(yàn)第一永遠(yuǎn)先用spi_sync把功能跑通再考慮優(yōu)化成spi_async。異步帶來(lái)的復(fù)雜度和并發(fā)問(wèn)題只有在確實(shí)需要中斷上下文、高吞吐隊(duì)列時(shí)才值得。很多驅(qū)動(dòng)寫(xiě)異步是因?yàn)榭雌饋?lái)性能更好實(shí)際 SPI 總線速率受限于從機(jī)異步省下的那點(diǎn)調(diào)度開(kāi)銷(xiāo)根本體現(xiàn)不出來(lái)。第二spi_setup()的返回值一定要檢查。它內(nèi)部要和控制器協(xié)商頻率、字長(zhǎng)、模式如果控制器不支持你要求的組合會(huì)返回-EINVAL。忽略這個(gè)返回值后面所有傳輸都會(huì)用上一次生效的配置跑現(xiàn)象莫名其妙。第三調(diào)試時(shí)把max_speed_hz降到 1 MHz 以下。絕大多數(shù)時(shí)序問(wèn)題是頻率太高導(dǎo)致的建立/保持時(shí)間不夠降頻后問(wèn)題消失就說(shuō)明是時(shí)序余量問(wèn)題而不是邏輯錯(cuò)誤。這個(gè)技巧能幫你在一分鐘內(nèi)把問(wèn)題范圍縮小一半。第四給每個(gè)關(guān)鍵傳輸點(diǎn)加dev_dbg打印actual_length和status。status為 0 但actual_length小于預(yù)期的情況說(shuō)明傳輸被部分完成這種隱性失敗最容易被漏掉。第五片選是 SPI 里最不像數(shù)據(jù)線的數(shù)據(jù)線。它不傳數(shù)據(jù)但決定了數(shù)據(jù)的邊界。所有數(shù)據(jù)看起來(lái)錯(cuò)位讀出來(lái)多一個(gè)字節(jié)偶爾成功偶爾失敗的問(wèn)題先懷疑片選時(shí)序比懷疑數(shù)據(jù)緩沖區(qū)有效得多。