動核心結構體、傳輸接口與probe排查)
這篇接著上一篇的內(nèi)容往下走。上一回把I2C子系統(tǒng)的分層和文件分布過了一遍這次專門啃硬骨頭i2c_adapter、i2c_algorithm、i2c_client、i2c_driver、i2c_msg 這幾個結構體以及 i2c_transfer、i2c_master_send、i2c_master_recv、i2c_smbus_這些接口*。說實話我接觸過的絕大多數(shù)I2C驅(qū)動問題表面看是“時序不對”“設備沒響應”往下挖兩層基本都落在這些結構體的某個字段填錯了或者某個接口的返回值沒檢查。所以這篇不打算寫成內(nèi)核文檔的翻譯稿而是按照我自己寫驅(qū)動、調(diào)板子的順序把這幾個結構體拆開看把接口的坑一個個標出來。剛入門的讀者能照著搭出一個能跑的驅(qū)動骨架有經(jīng)驗的朋友可以重點看參數(shù)計算、匹配邏輯和排查那幾節(jié)里面的細節(jié)大多是文檔里不會寫、只在調(diào)試現(xiàn)場才會撞上的東西。1. 先把I2C子系統(tǒng)的“人物關系”理清楚1.1 四個核心結構體各自扮演什么角色我習慣把I2C子系統(tǒng)當成一家快遞公司來理解。i2c_adapter是那條運輸線路也就是控制器本身負責把包裹送到目的地i2c_algorithm是具體的運輸方式是卡車還是飛機它決定了“包裹怎么送出去”這個最底層的動作i2c_client是收件人代表掛在這條線上的某一顆從設備芯片地址就是門牌號i2c_driver是派件員掌握著處理這類包裹的業(yè)務邏輯。包裹本身是i2c_msg里面裝著地址、方向、數(shù)據(jù)和長度。這個類比不是玩文字游戲它直接對應代碼里誰注冊誰、誰引用誰。i2c_adapter里有一個algo指針指向i2c_algorithmi2c_client里有一個adapter指針指回它掛靠的那條線路i2c_driver的probe回調(diào)收到的是i2c_client *和i2c_device_id *。寫驅(qū)動的時候如果你清楚自己此刻在操作哪一層就不會出現(xiàn)“在probe里直接寫寄存器地址去操作控制器”這種越界操作。再補一層關系內(nèi)核啟動后i2c_client的來源有兩條路。老平臺走板級文件里的i2c_board_info由i2c_register_board_info在啟動早期登記等adapter注冊時統(tǒng)一實例化新平臺走設備樹of_i2c_register_devices遍歷adapter節(jié)點下的子節(jié)點為每個子節(jié)點調(diào)用i2c_new_client_device生成client。這兩條路的終點是同一個函數(shù)所以無論你用的是哪種方式probe里看到的東西是一樣的。結構體所在層級誰創(chuàng)建核心職責i2c_adapter控制器抽象控制器驅(qū)動持有鎖、超時、重試、算法指針i2c_algorithm硬件操作控制器驅(qū)動實現(xiàn) master_xfer / smbus_xferi2c_client從設備實例設備樹或板級信息保存7位地址、所屬adapter、irqi2c_driver設備驅(qū)動從設備驅(qū)動匹配表、probe、removei2c_msg單次傳輸描述調(diào)用者地址、標志、緩沖區(qū)、長度1.2 一條數(shù)據(jù)從用戶態(tài)到SCL波形的完整路徑很多人寫驅(qū)動時只看自己那一層結果一出問題就不知道往上往下該找誰。把整條鏈路走一遍心里就有譜了。用戶態(tài)用i2c-dev接口發(fā)起一次I2C_RDWRioctl內(nèi)核里i2cdev_ioctl_rdwr把用戶傳進來的數(shù)組拷成內(nèi)核態(tài)的i2c_msg數(shù)組然后調(diào)用i2c_transfer。i2c_transfer拿到adapter檢查algo-master_xfer是否存在加bus_lock再調(diào)__i2c_transfer里面按需切換mux通道最后把消息數(shù)組交給master_xfer?？刂破黩?qū)動的master_xfer才是真正碰寄存器的地方把每條msg拆成起始位、地址字節(jié)、讀寫位、數(shù)據(jù)字節(jié)、ACK位、停止位寫進控制器的FIFO或者命令寄存器然后要么忙等要么等中斷要么等DMA完成。所以當你說“I2C不通”的時候至少要問自己三個問題msg構造對了嗎傳輸層返回什么錯誤波形到底出來了沒有這三個問題分別對應驅(qū)動作者、i2c核心、硬件三個責任方排查時從中間往外擴最快。1.3 為什么Linux要把“設備”和“驅(qū)動”拆成兩半這個問題我被問過不止一次。答案在總線模型的匹配機制上i2c_client描述“這里有個什么東西”i2c_driver描述“我會處理什么東西”兩者通過匹配表對上號才調(diào)probe。這樣同一份驅(qū)動代碼可以服務多塊板子板子上有沒有這顆芯片、地址是多少全部由設備樹或板級信息決定驅(qū)動本身不需要改動。代價是匹配失敗時現(xiàn)象很隱蔽驅(qū)動加載了lsmod能看到但probe就是不進也沒有報錯。因為對內(nèi)核來說“沒匹配上”是正常狀態(tài)總線上隨時可能有它不認識的設備。這一點必須提前建立預期否則第一次遇到會懷疑人生。后面第6節(jié)會把匹配失敗的幾種典型原因列全。2. i2c_adapter與i2c_algorithm控制器側怎么搭骨架2.1 i2c_adapter里哪些字段必須由你來填i2c_adapter是個大結構體字段多到第一次看會有點暈但真正需要驅(qū)動作者關心的就那么幾個。owner填THIS_MODULE保證adapter在使用時模塊不會被卸載algo指向你的算法實現(xiàn)algo_data是私有數(shù)據(jù)指針通常塞你的自定義結構體master_xfer里adap-algo_data取回來就能拿到寄存器基址、時鐘、FIFO深度這些東西nr是總線編號-1表示讓內(nèi)核動態(tài)分配name會出現(xiàn)在/sys/bus/i2c/devices/i2c-N/name里起個能看懂的名字調(diào)試時省事timeout和retries決定單次傳輸?shù)某瑫r和重試次數(shù)。dev字段必須初始化i2c_add_adapter內(nèi)部會調(diào)device_register如果dev.parent沒設設備樹里adapter節(jié)點的解析、電源管理、sysfs路徑都會出問題。我見過有人手工分配adapter結構體卻忘了adap-dev.parent pdev-dev結果probe能過但設備樹子節(jié)點一個都沒被實例化查了半天以為是of_i2c_register_devices沒被調(diào)用實際上是parent沒設導致of_node沒繼承下來。還有一個容易被忽略的字段是lock_ops。默認走i2c_adapter自帶的忙等鎖在原子上下文或者中斷里發(fā)傳輸時可能需要換成i2c_lock_ops里基于raw spinlock的實現(xiàn)。是否要動它取決于你的master_xfer_atomic是否實現(xiàn)了普通場景不用管。2.2 master_xfer的返回值和實現(xiàn)要點master_xfer的簽名是int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)。返回值語義必須記牢成功時返回實際處理的msg條數(shù)失敗返回負的錯誤碼。注意不是返回字節(jié)數(shù)也不是返回0。返回0會被上層當成“一條都沒傳”i2c_transfer會把它當錯誤處理。實現(xiàn)上有幾個固定套路。先用i2c_check_functionality之類的邏輯判斷本次傳輸是否被硬件支持比如10位地址、SMBus塊傳輸。然后遍歷msgs每條msg單獨起一次傳輸判斷msgs[i].flags I2C_M_RD決定方向把msgs[i].addr左移一位拼上讀寫位組成地址字節(jié)。數(shù)據(jù)長度放在msgs[i].len緩沖區(qū)在msgs[i].buf。中間的重復起始位要靠I2C_M_NOSTART標志判斷但很多控制器硬件并不支持任意位置插入重復起始這時候就要在驅(qū)動里手動把多條msg合并處理。注意master_xfer里面不能睡眠等待太久也不能調(diào)用可能睡眠的接口去做與本次傳輸無關的事?？刂破黩?qū)動可能被上層在持鎖狀態(tài)下調(diào)用把大塊內(nèi)存分配、文件操作之類的東西塞進來輕則觸發(fā)調(diào)度告警重則死鎖。忙等和中斷的選擇也要提前想清楚。傳輸長度短、頻率高的場景比如讀傳感器一個寄存器用忙等加超時判斷最省事幾十微秒就過去了。傳輸長度長或者控制器FIFO很淺就得走中斷加完成量。我一般會給忙等設一個上限超過就轉(zhuǎn)成等待完成量避免在慢速設備上把CPU占死。2.3 注冊adapter的兩種方式與編號坑注冊接口有兩個i2c_add_adapter和i2c_add_numbered_adapter。前者讓內(nèi)核從空閑編號里挑一個后者要求你指定adap-nr如果這個號已經(jīng)被占用就返回-EBUSY。什么時候必須用帶編號的當設備樹里有i2c-N這樣的別名或者板級代碼里寫死了adapter_nr的時候。不帶編號的注冊在單控制器板子上沒問題多控制器場景下編號順序取決于probe順序可能這次是i2c-0和i2c-1下次驅(qū)動加載順序變了就互換用戶態(tài)腳本里的i2cdetect -y 0就指錯了設備。我現(xiàn)在的習慣是只要板子有多個I2C控制器一律走i2c_add_numbered_adapter用of_alias_get_id從設備樹別名里取號穩(wěn)定可預期。卸載路徑對應i2c_del_adapter它會先標記adapter為刪除狀態(tài)再解綁所有client。這里有個時序問題如果client的remove回調(diào)里還要通過i2c_transfer訪問設備必須在i2c_del_adapter之前完成否則傳輸會直接失敗。比較穩(wěn)妥的做法是把設備側的清理放在remove里adapter的注銷放在模塊exit的最后一步。3. i2c_client與i2c_driver設備與驅(qū)動怎么配對3.1 i2c_client的地址到底是7位還是8位client-addr存的是7位地址不含讀寫位。這是新手最容易翻車的地方。數(shù)據(jù)手冊上寫0x50通常就是7位地址寫0xA0是8位寫地址寫0xA1是8位讀地址。設備樹里reg 0x50填7位代碼里client-addr也是7位拼地址字節(jié)的時候左移一位再或上方向位。判斷方法很直接合法的7位地址范圍是0x00到0x7F超過0x7F的值一定不是7位地址。設備樹里寫reg 0xA0會被內(nèi)核當成非法地址通常會看到類似于“invalid reg”的報錯或者設備創(chuàng)建失敗。把0x50寫成0xA0導致的另一個典型現(xiàn)象是i2cdetect能掃到0x50但驅(qū)動probe之后讀寫全失敗因為實際發(fā)出的地址和芯片對不上。client-flags里還藏著不少信息比如I2C_CLIENT_TEN表示10位地址I2C_CLIENT_PEC表示SMBus包錯誤校驗使能I2C_CLIENT_WAKE表示可以喚醒系統(tǒng)。irq字段由設備樹里的interrupts屬性或者板級信息填充client-irq是0表示沒有中斷線。3.2 i2c_driver的匹配表怎么寫才不白忙活i2c_driver里放匹配信息的地方有兩個id_table指向的i2c_device_id數(shù)組和driver.of_match_table指向的of_device_id數(shù)組。匹配優(yōu)先級是of_match_table 優(yōu)先其次是 id_table最后才是按 name 字段的模糊匹配。這個順序決定了你只有一條表寫對是不夠的如果設備樹寫了compatible而驅(qū)動只提供了id_table但內(nèi)核走的是設備樹匹配路徑那就可能匹配不上。實際寫法我一般兩個表都填i2c_device_id里的名字用來支持老平臺和模塊別名of_device_id里的compatible必須和設備樹節(jié)點一字不差包括廠商前綴。字符串比較是精確匹配大小寫敏感多一個減號少一個逗號都不行。static const struct i2c_device_id demo_id[] { { demo-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(i2c, demo_id); static const struct of_device_id demo_of_match[] { { .compatible vendor,demo-sensor }, { } }; MODULE_DEVICE_TABLE(of, demo_of_match); static struct i2c_driver demo_driver { .driver { .name demo-sensor, .of_match_table demo_of_match, .pm demo_pm_ops, }, .probe demo_probe, .remove demo_remove, .id_table demo_id, }; module_i2c_driver(demo_driver);module_i2c_driver這個宏把i2c_add_driver和i2c_del_driver包在一起省掉樣板代碼。用它的前提是初始化只在注冊時做沒有額外的全局資源要在模塊加載時分階段準備絕大多數(shù)傳感器驅(qū)動都滿足。3.3 probe時序里該做什么、不該做什么probe進來時client已經(jīng)創(chuàng)建好、地址已經(jīng)確定、設備樹節(jié)點可以通過client-dev.of_node拿到但設備的供電、復位引腳、時鐘這些外部條件不一定就緒。所以probe的第一件事通常是把這些資源拿全devm_regulator_get、devm_gpiod_get_optional、devm_clk_get_optional。用devm_前綴的好處是失敗路徑和remove路徑都不用你手動釋放內(nèi)核會自動回收。第二件事是先做一次“存在性探測”。讀一下chip id寄存器確認芯片真的在。這一步的價值在于把“接錯地址”“芯片沒焊好”“供電沒上來”這類問題在probe階段就暴露出來而不是等到用戶態(tài)調(diào)用時才報一堆超時。讀chip id失敗的時候用dev_err_probe輸出錯誤它會把-EPROBE_DEFER轉(zhuǎn)成靜默的延遲探測避免在依賴資源還沒就緒時刷屏。注意probe里不要做長時間阻塞的操作比如輪詢等待芯片內(nèi)部自檢完成。如果確實需要等待用msleep分段等并且設置一個合理的上限。probe卡住會拖慢整個總線的設備注冊嚴重的時候影響啟動。第三件事是注冊字符設備、hwmon、input、iio 之類的對外接口以及申請中斷。中斷申請一般放在最后因為中斷處理函數(shù)里可能馬上要讀寄存器此時設備初始化必須已經(jīng)完成。中斷處理里用i2c_transfer時要特別小心很多adapter在中斷上下文里會退回忙等模式如果傳輸出錯或者設備沒響應超時時間會原樣生效容易觸發(fā)軟鎖。穩(wěn)妥的寫法是用IRQF_ONESHOT加線程化中斷把I2C傳輸放到線程上下文里做。remove回調(diào)的順序反過來先釋放對外接口再關中斷最后關電源同時記得pm_runtime的狀態(tài)也要歸位。用devm_管理之后這段代碼能精簡不少但跟硬件狀態(tài)相關的、必須立刻生效的動作還是要顯式寫出來。4. i2c_msg與傳輸接口數(shù)據(jù)到底怎么發(fā)出去4.1 i2c_msg的四個字段和常見組合套路i2c_msg只有四個字段但組合方式?jīng)Q定了通信能不能成。addr是7位從機地址flags是標志位len是本次傳輸?shù)淖止?jié)數(shù)buf是數(shù)據(jù)緩沖區(qū)指針。flags里常用的有I2C_M_RD表示讀方向I2C_M_NOSTART表示不發(fā)起始位直接續(xù)傳I2C_M_IGNORE_NAK表示忽略從機不應答I2C_M_STOP表示傳輸結束后發(fā)停止位。后三個都屬于“一般情況下別用”的選項用了就要清楚自己在繞開什么。最典型的組合是“寫寄存器地址再讀數(shù)據(jù)”這個操作在很多芯片上要求中間有重復起始位而不是停止位。寫法是把兩條i2c_msg放在一個數(shù)組里第一條寫方向、長度為1、內(nèi)容是從機寄存器地址第二條讀方向、長度為N、緩沖區(qū)是接收區(qū)然后一次i2c_transfer傳2條?？刂破黩?qū)動如果支持重復起始兩條msg之間就不會插入停止位如果不支持它可能會退化成“停止起始”的時序有些芯片因此拒絕響應。static int demo_read_regs(struct i2c_client *client, u8 reg, u8 *buf, int len) { int ret; struct i2c_msg msgs[2] { { .addr client-addr, .flags 0, .len 1, .buf reg, }, { .addr client-addr, .flags I2C_M_RD, .len len, .buf buf, }, }; ret i2c_transfer(client-adapter, msgs, ARRAY_SIZE(msgs)); if (ret 0) return ret; if (ret ! ARRAY_SIZE(msgs)) return -EIO; return 0; }注意最后那個判斷。i2c_transfer成功時返回處理的msg條數(shù)兩條都成返回2。如果只返回1說明第一條成了第二條沒成這在時序上有意義必須當錯誤處理不能只看“非負”。這段代碼我?guī)缀踉诿總€驅(qū)動里都會寫一遍雖然啰嗦但從沒想過用更短的寫法替代因為錯誤路徑清晰比代碼短重要。4.2 i2c_transfer的鎖語義和不能踩的坑i2c_transfer內(nèi)部會獲取adapter-bus_lock把整組msg作為一個原子操作發(fā)出去。這意味著兩件事第一不要把兩段邏輯上無關的傳輸拼進同一個數(shù)組會白白占用總線鎖第二在已經(jīng)持有某些鎖的情況下調(diào)用它要檢查鎖的嵌套關系避免形成環(huán)路。i2c_transfer不能在中斷上下文里直接調(diào)用這一點經(jīng)常被誤解。雖然有些控制器驅(qū)動實現(xiàn)了master_xfer_atomic來支持原子上下文但前提是你明確知道自己的傳輸走的是這條路。穩(wěn)妥做法永遠是把傳輸挪到線程上下文或者工作隊列里。返回值處理有幾個固定的錯誤碼要認-ENXIO通常表示地址沒有應答或者從機不存在-ETIMEDOUT表示傳輸超時-EAGAIN在某些驅(qū)動里表示總線仲裁失敗可重試-EOPNOTSUPP多半是功能不支持比如用了SMBus但控制器沒實現(xiàn)?？吹?ENXIO先去量波形確認地址發(fā)出去沒有看到-ETIMEDOUT先查上拉電阻和時鐘拉伸。4.3 封裝接口與SMBus怎么選i2c_master_send和i2c_master_recv是最簡單的封裝前者發(fā)一段連續(xù)數(shù)據(jù)后者收一段連續(xù)數(shù)據(jù)返回值是實際發(fā)送或接收的字節(jié)數(shù)失敗返回負數(shù)。它們內(nèi)部就是構造一條i2c_msg調(diào)i2c_transfer適合“一次性發(fā)一包”的場景比如給顯示屏刷一段緩沖區(qū)。SMBus接口是另一套體系包括i2c_smbus_read_byte_data、i2c_smbus_write_byte_data、i2c_smbus_read_i2c_block_data等。它們的便利之處在于把“寫命令字節(jié)讀數(shù)據(jù)”這個套路封裝好了調(diào)用者不用自己拼msg數(shù)組。但代價是每次調(diào)用都會重新獲取總線鎖如果連續(xù)讀多個寄存器開銷比一次i2c_transfer傳多條msg大得多。而且SMBus有自己的一套協(xié)議限制比如塊讀的最大長度通常是32字節(jié)超過就得分批。我的選擇標準很簡單寄存器級的小數(shù)據(jù)量訪問用SMBus接口代碼短、可讀性好需要保證時序連續(xù)性的多段傳輸比如先寫地址再讀一長串數(shù)據(jù)或者反過來連續(xù)寫多個寄存器不能被打斷就用i2c_transfer自己拼msg。另外SMBus接口默認要求控制器實現(xiàn)smbus_xfer如果只有master_xfer內(nèi)核會用軟件模擬的方式實現(xiàn)SMBus功能沒問題但效率會低一些functionality里是否置了I2C_FUNC_SMBUS_*位可以提前判斷。接口適用場景返回值語義是否自行加鎖i2c_transfer多條msg組合、需要原子性msg條數(shù) / 負錯誤碼是i2c_master_send連續(xù)寫一段字節(jié)數(shù) / 負錯誤碼是i2c_master_recv連續(xù)讀一段字節(jié)數(shù) / 負錯誤碼是i2c_smbus_read_byte_data讀單寄存器數(shù)據(jù)或負錯誤碼是每次調(diào)用i2c_smbus_read_i2c_block_data塊讀字節(jié)數(shù) / 負錯誤碼是每次調(diào)用5. 設備是怎么“長”出來的設備樹與實例化路徑5.1 設備樹節(jié)點的最小可用寫法設備樹里I2C從設備節(jié)點掛在控制器節(jié)點下面reg填7位地址compatible和驅(qū)動里的of_device_id對應。一個能用的最小節(jié)點是這樣的i2c1 { status okay; clock-frequency 400000; demo_sensor: sensor50 { compatible vendor,demo-sensor; reg 0x50; interrupt-parent gpio1; interrupts 12 IRQ_TYPE_EDGE_FALLING; vdd-supply reg_3v3; reset-gpios gpio1 13 GPIO_ACTIVE_LOW; }; };clock-frequency決定總線速率不填默認100kHz。400kHz是快速模式對布線和上拉電阻的要求比100kHz高不少板子上拉阻值偏大或者走線偏長的時候400kHz很容易出問題調(diào)試階段建議先用100kHz跑通再往上提。節(jié)點名里的sensor50只是個標簽真正起作用的是reg屬性。后面的地址要和reg一致雖然內(nèi)核不強制校驗但寫錯了讀代碼的人會誤解工具鏈也可能給出警告。5.2 i2c_new_client_device與i2c_new_device的區(qū)別用戶態(tài)或者內(nèi)核模塊里想手工創(chuàng)建client會碰到兩個函數(shù)。i2c_new_device是老接口失敗時返回NULL需要看errno才知道原因。i2c_new_client_device是新接口失敗時返回ERR_PTR可以直接用IS_ERR和PTR_ERR取錯誤碼。新代碼統(tǒng)一用后者錯誤處理更清晰。手工創(chuàng)建client的典型場景是設備樹里沒法描述某個設備的初始化順序或者需要在運行時根據(jù)探測結果動態(tài)掛設備。這時候先填一個i2c_board_info結構體把type設成和驅(qū)動id_table里一致的名字addr設成7位地址of_node指向?qū)脑O備樹節(jié)點然后調(diào)i2c_new_client_device。注意創(chuàng)建出來的client要記得在不用的時候i2c_unregister_device否則會在總線上留下一個懸空實例。還有一個細節(jié)i2c_new_scanned_device用于地址探測它會先用i2c_default_probe去試探地址上有沒有設備應答應答了才創(chuàng)建client。地址探測本身有風險某些芯片在被隨意讀一下之后會進入異常狀態(tài)所以除非你確認目標芯片不會因為誤讀而出問題否則不推薦依賴掃描式探測。5.3 匹配優(yōu)先級與多設備共存前面提過匹配順序是of_match_table優(yōu)先但具體流程還涉及i2c_device_match里的幾段判斷。設備樹路徑下of_driver_match_device先比對compatible匹配上就調(diào)probe沒有設備樹節(jié)點或者compatible不匹配才退到i2c_match_id用 id_table 比名字最后還有一層按driver-name的字符串比較。這意味著如果同一個驅(qū)動既要支持設備樹又要支持老平臺可以只寫of_match_table加id_tablename那層基本用不上。同一條總線上掛多個同類設備時設備樹里每個節(jié)點有自己的地址驅(qū)動probe會被調(diào)用多次每次拿到不同的client。驅(qū)動內(nèi)部要避免用全局變量保存“設備狀態(tài)”狀態(tài)應該掛在i2c_set_clientdata里probe里set、remove里get各個實例互不干擾。這個坑我在早期代碼里踩過兩個相同傳感器接在同一條總線上第二個設備的讀數(shù)覆蓋了第一個查了半天才發(fā)現(xiàn)是靜態(tài)變量。6. 常見問題與排查技巧實錄6.1 probe不進的排查順序這是最高頻的問題。我的排查順序是固定的按代價從低到高走。第一步確認驅(qū)動真的加載了lsmod或者dmesg | grep 驅(qū)動名模塊加載失敗會在dmesg里留痕。第二步看compatible字符串有沒有拼錯直接diff設備樹源文件和驅(qū)動里的字符串比肉眼比對可靠。第三步看總線上有沒有這個clientls /sys/bus/i2c/devices/下面應該有1-0050這樣的目錄目錄名格式是“總線號-地址”。如果沒有說明設備樹節(jié)點沒被解析檢查adapter節(jié)點的status是不是okay以及of_i2c_register_devices有沒有被調(diào)用。第四步如果client存在但probe沒進說明匹配失敗。把驅(qū)動編譯進內(nèi)核而不是模塊看啟動日志里有沒有匹配相關的提示或者打開I2C核心的調(diào)試輸出加內(nèi)核參數(shù)dyndbgfile drivers/i2c/* p能看到匹配過程的細節(jié)。第五步如果probe進了但返回錯誤dev_err_probe輸出的錯誤碼就是方向-EPROBE_DEFER表示依賴資源沒就緒-ENODEV表示探測失敗其他錯誤碼按字面意思查。現(xiàn)象最可能原因快速驗證模塊沒加載依賴未滿足或符號沖突dmesg 看加載日志client 不存在設備樹節(jié)點未使能或解析失敗ls /sys/bus/i2c/devicesclient 存在但無probecompatible 不匹配對比設備樹與驅(qū)動字符串probe 返回 -EPROBE_DEFER電源/時鐘/GPIO 未就緒檢查 regulator 與 pinctrlprobe 返回 -ENXIO地址無應答i2cdetect 掃地址6.2 返回-ENXIO但設備明明焊在上面遇到這個先別改代碼去量波形。我最常遇到的原因有三個。第一上拉電阻沒焊或者阻值太大總線空閑時電平拉不到高示波器一看就是緩坡上升。第二引腳復用沒配對I2C的SCL和SDA被別的功能占用波形上根本看不到時鐘。第三設備供電沒上芯片處于未上電狀態(tài)自然不會應答。軟件側還有一個隱蔽原因10位地址和7位地址混用。如果設備用的是10位地址client-flags必須置I2C_CLIENT_TEN否則發(fā)出去的地址格式不對。10位地址的傳輸會在地址字節(jié)前多發(fā)一個特殊的保留字節(jié)用7位方式發(fā)就完全對不上。再一個可能是地址沖突。同一條總線上兩個設備地址相同i2c_new_client_device在創(chuàng)建第二個時會返回-EBUSY但如果兩個設備是分兩次、在不同時間創(chuàng)建的可能第一個已經(jīng)正常工作了第二個創(chuàng)建失敗而你只看到驅(qū)動沒probe。i2cdetect -y 1能看到那條總線上所有應答的地址掃描結果和預期對比一下多出來的地址就要警惕。6.3 時鐘拉伸、速率與上拉電阻的計算時鐘拉伸是從機在SCL為低時拉住總線不放告訴主機“我還沒準備好”。主機必須支持這個機制否則數(shù)據(jù)會錯。i2c_adapter的timeout和retries在這里就有意義了超時設太短稍微慢一點的從機就被判失敗設太長從機異常拉死總線時CPU會跟著卡很久。我的經(jīng)驗值是從機手冊里給的最大響應時間乘以2到3倍再留一點余量100kHz總線上通常設幾百毫秒到1秒。上拉電阻的取值有公式可算。上升時間約束給出上限Rp(max) tr / (0.8473 * Cb)其中tr是標準允許的最大上升時間100kHz標準模式是1000ns400kHz快速模式是300nsCb是總線電容包括走線、引腳和器件電容通常按100pF到200pF估算。灌電流約束給出下限Rp(min) (Vdd - Vol) / IolVol是低電平最大電壓一般取0.4VIol是引腳能灌入的最小電流常見是3mA。舉個實際例子Vdd取3.3VCb按150pF估400kHz模式下Rp(max) 300ns / (0.8473 * 150pF) ≈ 2360Ω也就是2.36kΩRp(min) (3.3 - 0.4) / 3mA ≈ 967Ω。所以阻值落在約1kΩ到2.2kΩ之間比較合適實際板子上用1.8kΩ或2.2kΩ都很常見。如果總線上掛了七八個設備Cb會變大Rp(max)相應變小這時候就得減小阻值或者降低總線速率。很多人把400kHz切回100kHz問題就消失了本質(zhì)上是上升時間約束被放寬了不是問題真的解決了。6.4 并發(fā)訪問與鎖的處理同一條總線上多個設備、多個驅(qū)動并發(fā)訪問是常態(tài)。i2c_transfer自己會加總線鎖所以單次傳輸之間不會互相踩。但要注意“讀-改-寫”這種復合操作不是原子的先讀一個寄存器判斷某位再寫回去中間可能被另一個設備的傳輸插進來雖然別的設備操作的是自己的地址不影響數(shù)據(jù)但如果兩個線程操作同一個設備就會出競態(tài)。解決辦法是在驅(qū)動內(nèi)部加自己的mutex把針對同一個client的復合操作保護起來。不要用adapter-bus_lock做這件事那是核心層的鎖你手動去拿會破壞封裝。用mutex_lock(client-dev... )也不對正確的做法是在自己的私有結構體里放一把mutexprobe里初始化remove里銷毀。中斷上下文和線程上下文都要訪問設備時鎖的選擇更講究。中斷處理里不能睡但i2c_transfer可能睡所以中斷處理里只能做標記、喚醒線程真正的傳輸放到線程里做。用spin_lock_irqsave保護共享標志位用mutex保護傳輸序列這兩把鎖分工明確不要混用。6.5 我調(diào)I2C時固定會用的幾招i2cdetect是最快的存活檢查-y跳過交互-r用讀方式探測-q用SMBus快速命令探測。有的芯片用讀方式不應答但用寫方式能應答兩種都試一下能省很多時間。i2cdump可以用來快速看一片寄存器區(qū)域確認芯片是否處于預期狀態(tài)不過要小心別去dump那些讀操作有副作用的芯片。內(nèi)核側的調(diào)試輸出我一般開CONFIG_I2C_DEBUG_CORE和CONFIG_I2C_DEBUG_ALGO再配合動態(tài)調(diào)試在drivers/i2c/i2c-core-base.c上打開。這樣做能看到每次傳輸?shù)膍sg構成、地址、方向、返回碼比自己加printk干凈得多。如果懷疑時序問題邏輯分析儀接在SCL和SDA上觸發(fā)條件設成起始位抓一次完整傳輸對照芯片手冊的時序參數(shù)逐個看起始保持時間、數(shù)據(jù)建立時間、停止建立時間哪個不達標就改哪。這個手段看起來笨但定位硬件層面的問題時幾乎沒有替代品。最后分享一個我自己的習慣每寫一個新驅(qū)動先不寫probe邏輯只寫最小骨架——匹配表、probe里讀chip id并打印、remove里打印。確認這三點都通了再往里填功能。這個做法看著慢實際上省掉了大量“功能代碼和匹配問題糾纏在一起”的調(diào)試時間。踩過幾次“以為是寄存器寫錯、其實根本沒進probe”的坑之后這套流程就再也改不掉了。 Linux I2C驅(qū)動核心結構體、傳輸接口與probe排查
這篇接著上一篇的內(nèi)容往下走。上一回把I2C子系統(tǒng)的分層和文件分布過了一遍這次專門啃硬骨頭i2c_adapter、i2c_algorithm、i2c_client、i2c_driver、i2c_msg 這幾個結構體以及 i2c_transfer、i2c_master_send、i2c_master_recv、i2c_smbus_這些接口*。說實話我接觸過的絕大多數(shù)I2C驅(qū)動問題表面看是“時序不對”“設備沒響應”往下挖兩層基本都落在這些結構體的某個字段填錯了或者某個接口的返回值沒檢查。所以這篇不打算寫成內(nèi)核文檔的翻譯稿而是按照我自己寫驅(qū)動、調(diào)板子的順序把這幾個結構體拆開看把接口的坑一個個標出來。剛入門的讀者能照著搭出一個能跑的驅(qū)動骨架有經(jīng)驗的朋友可以重點看參數(shù)計算、匹配邏輯和排查那幾節(jié)里面的細節(jié)大多是文檔里不會寫、只在調(diào)試現(xiàn)場才會撞上的東西。1. 先把I2C子系統(tǒng)的“人物關系”理清楚1.1 四個核心結構體各自扮演什么角色我習慣把I2C子系統(tǒng)當成一家快遞公司來理解。i2c_adapter是那條運輸線路也就是控制器本身負責把包裹送到目的地i2c_algorithm是具體的運輸方式是卡車還是飛機它決定了“包裹怎么送出去”這個最底層的動作i2c_client是收件人代表掛在這條線上的某一顆從設備芯片地址就是門牌號i2c_driver是派件員掌握著處理這類包裹的業(yè)務邏輯。包裹本身是i2c_msg里面裝著地址、方向、數(shù)據(jù)和長度。這個類比不是玩文字游戲它直接對應代碼里誰注冊誰、誰引用誰。i2c_adapter里有一個algo指針指向i2c_algorithmi2c_client里有一個adapter指針指回它掛靠的那條線路i2c_driver的probe回調(diào)收到的是i2c_client *和i2c_device_id *。寫驅(qū)動的時候如果你清楚自己此刻在操作哪一層就不會出現(xiàn)“在probe里直接寫寄存器地址去操作控制器”這種越界操作。再補一層關系內(nèi)核啟動后i2c_client的來源有兩條路。老平臺走板級文件里的i2c_board_info由i2c_register_board_info在啟動早期登記等adapter注冊時統(tǒng)一實例化新平臺走設備樹of_i2c_register_devices遍歷adapter節(jié)點下的子節(jié)點為每個子節(jié)點調(diào)用i2c_new_client_device生成client。這兩條路的終點是同一個函數(shù)所以無論你用的是哪種方式probe里看到的東西是一樣的。結構體所在層級誰創(chuàng)建核心職責i2c_adapter控制器抽象控制器驅(qū)動持有鎖、超時、重試、算法指針i2c_algorithm硬件操作控制器驅(qū)動實現(xiàn) master_xfer / smbus_xferi2c_client從設備實例設備樹或板級信息保存7位地址、所屬adapter、irqi2c_driver設備驅(qū)動從設備驅(qū)動匹配表、probe、removei2c_msg單次傳輸描述調(diào)用者地址、標志、緩沖區(qū)、長度1.2 一條數(shù)據(jù)從用戶態(tài)到SCL波形的完整路徑很多人寫驅(qū)動時只看自己那一層結果一出問題就不知道往上往下該找誰。把整條鏈路走一遍心里就有譜了。用戶態(tài)用i2c-dev接口發(fā)起一次I2C_RDWRioctl內(nèi)核里i2cdev_ioctl_rdwr把用戶傳進來的數(shù)組拷成內(nèi)核態(tài)的i2c_msg數(shù)組然后調(diào)用i2c_transfer。i2c_transfer拿到adapter檢查algo-master_xfer是否存在加bus_lock再調(diào)__i2c_transfer里面按需切換mux通道最后把消息數(shù)組交給master_xfer?？刂破黩?qū)動的master_xfer才是真正碰寄存器的地方把每條msg拆成起始位、地址字節(jié)、讀寫位、數(shù)據(jù)字節(jié)、ACK位、停止位寫進控制器的FIFO或者命令寄存器然后要么忙等要么等中斷要么等DMA完成。所以當你說“I2C不通”的時候至少要問自己三個問題msg構造對了嗎傳輸層返回什么錯誤波形到底出來了沒有這三個問題分別對應驅(qū)動作者、i2c核心、硬件三個責任方排查時從中間往外擴最快。1.3 為什么Linux要把“設備”和“驅(qū)動”拆成兩半這個問題我被問過不止一次。答案在總線模型的匹配機制上i2c_client描述“這里有個什么東西”i2c_driver描述“我會處理什么東西”兩者通過匹配表對上號才調(diào)probe。這樣同一份驅(qū)動代碼可以服務多塊板子板子上有沒有這顆芯片、地址是多少全部由設備樹或板級信息決定驅(qū)動本身不需要改動。代價是匹配失敗時現(xiàn)象很隱蔽驅(qū)動加載了lsmod能看到但probe就是不進也沒有報錯。因為對內(nèi)核來說“沒匹配上”是正常狀態(tài)總線上隨時可能有它不認識的設備。這一點必須提前建立預期否則第一次遇到會懷疑人生。后面第6節(jié)會把匹配失敗的幾種典型原因列全。2. i2c_adapter與i2c_algorithm控制器側怎么搭骨架2.1 i2c_adapter里哪些字段必須由你來填i2c_adapter是個大結構體字段多到第一次看會有點暈但真正需要驅(qū)動作者關心的就那么幾個。owner填THIS_MODULE保證adapter在使用時模塊不會被卸載algo指向你的算法實現(xiàn)algo_data是私有數(shù)據(jù)指針通常塞你的自定義結構體master_xfer里adap-algo_data取回來就能拿到寄存器基址、時鐘、FIFO深度這些東西nr是總線編號-1表示讓內(nèi)核動態(tài)分配name會出現(xiàn)在/sys/bus/i2c/devices/i2c-N/name里起個能看懂的名字調(diào)試時省事timeout和retries決定單次傳輸?shù)某瑫r和重試次數(shù)。dev字段必須初始化i2c_add_adapter內(nèi)部會調(diào)device_register如果dev.parent沒設設備樹里adapter節(jié)點的解析、電源管理、sysfs路徑都會出問題。我見過有人手工分配adapter結構體卻忘了adap-dev.parent pdev-dev結果probe能過但設備樹子節(jié)點一個都沒被實例化查了半天以為是of_i2c_register_devices沒被調(diào)用實際上是parent沒設導致of_node沒繼承下來。還有一個容易被忽略的字段是lock_ops。默認走i2c_adapter自帶的忙等鎖在原子上下文或者中斷里發(fā)傳輸時可能需要換成i2c_lock_ops里基于raw spinlock的實現(xiàn)。是否要動它取決于你的master_xfer_atomic是否實現(xiàn)了普通場景不用管。2.2 master_xfer的返回值和實現(xiàn)要點master_xfer的簽名是int (*master_xfer)(struct i2c_adapter *adap, struct i2c_msg *msgs, int num)。返回值語義必須記牢成功時返回實際處理的msg條數(shù)失敗返回負的錯誤碼。注意不是返回字節(jié)數(shù)也不是返回0。返回0會被上層當成“一條都沒傳”i2c_transfer會把它當錯誤處理。實現(xiàn)上有幾個固定套路。先用i2c_check_functionality之類的邏輯判斷本次傳輸是否被硬件支持比如10位地址、SMBus塊傳輸。然后遍歷msgs每條msg單獨起一次傳輸判斷msgs[i].flags I2C_M_RD決定方向把msgs[i].addr左移一位拼上讀寫位組成地址字節(jié)。數(shù)據(jù)長度放在msgs[i].len緩沖區(qū)在msgs[i].buf。中間的重復起始位要靠I2C_M_NOSTART標志判斷但很多控制器硬件并不支持任意位置插入重復起始這時候就要在驅(qū)動里手動把多條msg合并處理。注意master_xfer里面不能睡眠等待太久也不能調(diào)用可能睡眠的接口去做與本次傳輸無關的事?？刂破黩?qū)動可能被上層在持鎖狀態(tài)下調(diào)用把大塊內(nèi)存分配、文件操作之類的東西塞進來輕則觸發(fā)調(diào)度告警重則死鎖。忙等和中斷的選擇也要提前想清楚。傳輸長度短、頻率高的場景比如讀傳感器一個寄存器用忙等加超時判斷最省事幾十微秒就過去了。傳輸長度長或者控制器FIFO很淺就得走中斷加完成量。我一般會給忙等設一個上限超過就轉(zhuǎn)成等待完成量避免在慢速設備上把CPU占死。2.3 注冊adapter的兩種方式與編號坑注冊接口有兩個i2c_add_adapter和i2c_add_numbered_adapter。前者讓內(nèi)核從空閑編號里挑一個后者要求你指定adap-nr如果這個號已經(jīng)被占用就返回-EBUSY。什么時候必須用帶編號的當設備樹里有i2c-N這樣的別名或者板級代碼里寫死了adapter_nr的時候。不帶編號的注冊在單控制器板子上沒問題多控制器場景下編號順序取決于probe順序可能這次是i2c-0和i2c-1下次驅(qū)動加載順序變了就互換用戶態(tài)腳本里的i2cdetect -y 0就指錯了設備。我現(xiàn)在的習慣是只要板子有多個I2C控制器一律走i2c_add_numbered_adapter用of_alias_get_id從設備樹別名里取號穩(wěn)定可預期。卸載路徑對應i2c_del_adapter它會先標記adapter為刪除狀態(tài)再解綁所有client。這里有個時序問題如果client的remove回調(diào)里還要通過i2c_transfer訪問設備必須在i2c_del_adapter之前完成否則傳輸會直接失敗。比較穩(wěn)妥的做法是把設備側的清理放在remove里adapter的注銷放在模塊exit的最后一步。3. i2c_client與i2c_driver設備與驅(qū)動怎么配對3.1 i2c_client的地址到底是7位還是8位client-addr存的是7位地址不含讀寫位。這是新手最容易翻車的地方。數(shù)據(jù)手冊上寫0x50通常就是7位地址寫0xA0是8位寫地址寫0xA1是8位讀地址。設備樹里reg 0x50填7位代碼里client-addr也是7位拼地址字節(jié)的時候左移一位再或上方向位。判斷方法很直接合法的7位地址范圍是0x00到0x7F超過0x7F的值一定不是7位地址。設備樹里寫reg 0xA0會被內(nèi)核當成非法地址通常會看到類似于“invalid reg”的報錯或者設備創(chuàng)建失敗。把0x50寫成0xA0導致的另一個典型現(xiàn)象是i2cdetect能掃到0x50但驅(qū)動probe之后讀寫全失敗因為實際發(fā)出的地址和芯片對不上。client-flags里還藏著不少信息比如I2C_CLIENT_TEN表示10位地址I2C_CLIENT_PEC表示SMBus包錯誤校驗使能I2C_CLIENT_WAKE表示可以喚醒系統(tǒng)。irq字段由設備樹里的interrupts屬性或者板級信息填充client-irq是0表示沒有中斷線。3.2 i2c_driver的匹配表怎么寫才不白忙活i2c_driver里放匹配信息的地方有兩個id_table指向的i2c_device_id數(shù)組和driver.of_match_table指向的of_device_id數(shù)組。匹配優(yōu)先級是of_match_table 優(yōu)先其次是 id_table最后才是按 name 字段的模糊匹配。這個順序決定了你只有一條表寫對是不夠的如果設備樹寫了compatible而驅(qū)動只提供了id_table但內(nèi)核走的是設備樹匹配路徑那就可能匹配不上。實際寫法我一般兩個表都填i2c_device_id里的名字用來支持老平臺和模塊別名of_device_id里的compatible必須和設備樹節(jié)點一字不差包括廠商前綴。字符串比較是精確匹配大小寫敏感多一個減號少一個逗號都不行。static const struct i2c_device_id demo_id[] { { demo-sensor, 0 }, { } }; MODULE_DEVICE_TABLE(i2c, demo_id); static const struct of_device_id demo_of_match[] { { .compatible vendor,demo-sensor }, { } }; MODULE_DEVICE_TABLE(of, demo_of_match); static struct i2c_driver demo_driver { .driver { .name demo-sensor, .of_match_table demo_of_match, .pm demo_pm_ops, }, .probe demo_probe, .remove demo_remove, .id_table demo_id, }; module_i2c_driver(demo_driver);module_i2c_driver這個宏把i2c_add_driver和i2c_del_driver包在一起省掉樣板代碼。用它的前提是初始化只在注冊時做沒有額外的全局資源要在模塊加載時分階段準備絕大多數(shù)傳感器驅(qū)動都滿足。3.3 probe時序里該做什么、不該做什么probe進來時client已經(jīng)創(chuàng)建好、地址已經(jīng)確定、設備樹節(jié)點可以通過client-dev.of_node拿到但設備的供電、復位引腳、時鐘這些外部條件不一定就緒。所以probe的第一件事通常是把這些資源拿全devm_regulator_get、devm_gpiod_get_optional、devm_clk_get_optional。用devm_前綴的好處是失敗路徑和remove路徑都不用你手動釋放內(nèi)核會自動回收。第二件事是先做一次“存在性探測”。讀一下chip id寄存器確認芯片真的在。這一步的價值在于把“接錯地址”“芯片沒焊好”“供電沒上來”這類問題在probe階段就暴露出來而不是等到用戶態(tài)調(diào)用時才報一堆超時。讀chip id失敗的時候用dev_err_probe輸出錯誤它會把-EPROBE_DEFER轉(zhuǎn)成靜默的延遲探測避免在依賴資源還沒就緒時刷屏。注意probe里不要做長時間阻塞的操作比如輪詢等待芯片內(nèi)部自檢完成。如果確實需要等待用msleep分段等并且設置一個合理的上限。probe卡住會拖慢整個總線的設備注冊嚴重的時候影響啟動。第三件事是注冊字符設備、hwmon、input、iio 之類的對外接口以及申請中斷。中斷申請一般放在最后因為中斷處理函數(shù)里可能馬上要讀寄存器此時設備初始化必須已經(jīng)完成。中斷處理里用i2c_transfer時要特別小心很多adapter在中斷上下文里會退回忙等模式如果傳輸出錯或者設備沒響應超時時間會原樣生效容易觸發(fā)軟鎖。穩(wěn)妥的寫法是用IRQF_ONESHOT加線程化中斷把I2C傳輸放到線程上下文里做。remove回調(diào)的順序反過來先釋放對外接口再關中斷最后關電源同時記得pm_runtime的狀態(tài)也要歸位。用devm_管理之后這段代碼能精簡不少但跟硬件狀態(tài)相關的、必須立刻生效的動作還是要顯式寫出來。4. i2c_msg與傳輸接口數(shù)據(jù)到底怎么發(fā)出去4.1 i2c_msg的四個字段和常見組合套路i2c_msg只有四個字段但組合方式?jīng)Q定了通信能不能成。addr是7位從機地址flags是標志位len是本次傳輸?shù)淖止?jié)數(shù)buf是數(shù)據(jù)緩沖區(qū)指針。flags里常用的有I2C_M_RD表示讀方向I2C_M_NOSTART表示不發(fā)起始位直接續(xù)傳I2C_M_IGNORE_NAK表示忽略從機不應答I2C_M_STOP表示傳輸結束后發(fā)停止位。后三個都屬于“一般情況下別用”的選項用了就要清楚自己在繞開什么。最典型的組合是“寫寄存器地址再讀數(shù)據(jù)”這個操作在很多芯片上要求中間有重復起始位而不是停止位。寫法是把兩條i2c_msg放在一個數(shù)組里第一條寫方向、長度為1、內(nèi)容是從機寄存器地址第二條讀方向、長度為N、緩沖區(qū)是接收區(qū)然后一次i2c_transfer傳2條?？刂破黩?qū)動如果支持重復起始兩條msg之間就不會插入停止位如果不支持它可能會退化成“停止起始”的時序有些芯片因此拒絕響應。static int demo_read_regs(struct i2c_client *client, u8 reg, u8 *buf, int len) { int ret; struct i2c_msg msgs[2] { { .addr client-addr, .flags 0, .len 1, .buf reg, }, { .addr client-addr, .flags I2C_M_RD, .len len, .buf buf, }, }; ret i2c_transfer(client-adapter, msgs, ARRAY_SIZE(msgs)); if (ret 0) return ret; if (ret ! ARRAY_SIZE(msgs)) return -EIO; return 0; }注意最后那個判斷。i2c_transfer成功時返回處理的msg條數(shù)兩條都成返回2。如果只返回1說明第一條成了第二條沒成這在時序上有意義必須當錯誤處理不能只看“非負”。這段代碼我?guī)缀踉诿總€驅(qū)動里都會寫一遍雖然啰嗦但從沒想過用更短的寫法替代因為錯誤路徑清晰比代碼短重要。4.2 i2c_transfer的鎖語義和不能踩的坑i2c_transfer內(nèi)部會獲取adapter-bus_lock把整組msg作為一個原子操作發(fā)出去。這意味著兩件事第一不要把兩段邏輯上無關的傳輸拼進同一個數(shù)組會白白占用總線鎖第二在已經(jīng)持有某些鎖的情況下調(diào)用它要檢查鎖的嵌套關系避免形成環(huán)路。i2c_transfer不能在中斷上下文里直接調(diào)用這一點經(jīng)常被誤解。雖然有些控制器驅(qū)動實現(xiàn)了master_xfer_atomic來支持原子上下文但前提是你明確知道自己的傳輸走的是這條路。穩(wěn)妥做法永遠是把傳輸挪到線程上下文或者工作隊列里。返回值處理有幾個固定的錯誤碼要認-ENXIO通常表示地址沒有應答或者從機不存在-ETIMEDOUT表示傳輸超時-EAGAIN在某些驅(qū)動里表示總線仲裁失敗可重試-EOPNOTSUPP多半是功能不支持比如用了SMBus但控制器沒實現(xiàn)?？吹?ENXIO先去量波形確認地址發(fā)出去沒有看到-ETIMEDOUT先查上拉電阻和時鐘拉伸。4.3 封裝接口與SMBus怎么選i2c_master_send和i2c_master_recv是最簡單的封裝前者發(fā)一段連續(xù)數(shù)據(jù)后者收一段連續(xù)數(shù)據(jù)返回值是實際發(fā)送或接收的字節(jié)數(shù)失敗返回負數(shù)。它們內(nèi)部就是構造一條i2c_msg調(diào)i2c_transfer適合“一次性發(fā)一包”的場景比如給顯示屏刷一段緩沖區(qū)。SMBus接口是另一套體系包括i2c_smbus_read_byte_data、i2c_smbus_write_byte_data、i2c_smbus_read_i2c_block_data等。它們的便利之處在于把“寫命令字節(jié)讀數(shù)據(jù)”這個套路封裝好了調(diào)用者不用自己拼msg數(shù)組。但代價是每次調(diào)用都會重新獲取總線鎖如果連續(xù)讀多個寄存器開銷比一次i2c_transfer傳多條msg大得多。而且SMBus有自己的一套協(xié)議限制比如塊讀的最大長度通常是32字節(jié)超過就得分批。我的選擇標準很簡單寄存器級的小數(shù)據(jù)量訪問用SMBus接口代碼短、可讀性好需要保證時序連續(xù)性的多段傳輸比如先寫地址再讀一長串數(shù)據(jù)或者反過來連續(xù)寫多個寄存器不能被打斷就用i2c_transfer自己拼msg。另外SMBus接口默認要求控制器實現(xiàn)smbus_xfer如果只有master_xfer內(nèi)核會用軟件模擬的方式實現(xiàn)SMBus功能沒問題但效率會低一些functionality里是否置了I2C_FUNC_SMBUS_*位可以提前判斷。接口適用場景返回值語義是否自行加鎖i2c_transfer多條msg組合、需要原子性msg條數(shù) / 負錯誤碼是i2c_master_send連續(xù)寫一段字節(jié)數(shù) / 負錯誤碼是i2c_master_recv連續(xù)讀一段字節(jié)數(shù) / 負錯誤碼是i2c_smbus_read_byte_data讀單寄存器數(shù)據(jù)或負錯誤碼是每次調(diào)用i2c_smbus_read_i2c_block_data塊讀字節(jié)數(shù) / 負錯誤碼是每次調(diào)用5. 設備是怎么“長”出來的設備樹與實例化路徑5.1 設備樹節(jié)點的最小可用寫法設備樹里I2C從設備節(jié)點掛在控制器節(jié)點下面reg填7位地址compatible和驅(qū)動里的of_device_id對應。一個能用的最小節(jié)點是這樣的i2c1 { status okay; clock-frequency 400000; demo_sensor: sensor50 { compatible vendor,demo-sensor; reg 0x50; interrupt-parent gpio1; interrupts 12 IRQ_TYPE_EDGE_FALLING; vdd-supply reg_3v3; reset-gpios gpio1 13 GPIO_ACTIVE_LOW; }; };clock-frequency決定總線速率不填默認100kHz。400kHz是快速模式對布線和上拉電阻的要求比100kHz高不少板子上拉阻值偏大或者走線偏長的時候400kHz很容易出問題調(diào)試階段建議先用100kHz跑通再往上提。節(jié)點名里的sensor50只是個標簽真正起作用的是reg屬性。后面的地址要和reg一致雖然內(nèi)核不強制校驗但寫錯了讀代碼的人會誤解工具鏈也可能給出警告。5.2 i2c_new_client_device與i2c_new_device的區(qū)別用戶態(tài)或者內(nèi)核模塊里想手工創(chuàng)建client會碰到兩個函數(shù)。i2c_new_device是老接口失敗時返回NULL需要看errno才知道原因。i2c_new_client_device是新接口失敗時返回ERR_PTR可以直接用IS_ERR和PTR_ERR取錯誤碼。新代碼統(tǒng)一用后者錯誤處理更清晰。手工創(chuàng)建client的典型場景是設備樹里沒法描述某個設備的初始化順序或者需要在運行時根據(jù)探測結果動態(tài)掛設備。這時候先填一個i2c_board_info結構體把type設成和驅(qū)動id_table里一致的名字addr設成7位地址of_node指向?qū)脑O備樹節(jié)點然后調(diào)i2c_new_client_device。注意創(chuàng)建出來的client要記得在不用的時候i2c_unregister_device否則會在總線上留下一個懸空實例。還有一個細節(jié)i2c_new_scanned_device用于地址探測它會先用i2c_default_probe去試探地址上有沒有設備應答應答了才創(chuàng)建client。地址探測本身有風險某些芯片在被隨意讀一下之后會進入異常狀態(tài)所以除非你確認目標芯片不會因為誤讀而出問題否則不推薦依賴掃描式探測。5.3 匹配優(yōu)先級與多設備共存前面提過匹配順序是of_match_table優(yōu)先但具體流程還涉及i2c_device_match里的幾段判斷。設備樹路徑下of_driver_match_device先比對compatible匹配上就調(diào)probe沒有設備樹節(jié)點或者compatible不匹配才退到i2c_match_id用 id_table 比名字最后還有一層按driver-name的字符串比較。這意味著如果同一個驅(qū)動既要支持設備樹又要支持老平臺可以只寫of_match_table加id_tablename那層基本用不上。同一條總線上掛多個同類設備時設備樹里每個節(jié)點有自己的地址驅(qū)動probe會被調(diào)用多次每次拿到不同的client。驅(qū)動內(nèi)部要避免用全局變量保存“設備狀態(tài)”狀態(tài)應該掛在i2c_set_clientdata里probe里set、remove里get各個實例互不干擾。這個坑我在早期代碼里踩過兩個相同傳感器接在同一條總線上第二個設備的讀數(shù)覆蓋了第一個查了半天才發(fā)現(xiàn)是靜態(tài)變量。6. 常見問題與排查技巧實錄6.1 probe不進的排查順序這是最高頻的問題。我的排查順序是固定的按代價從低到高走。第一步確認驅(qū)動真的加載了lsmod或者dmesg | grep 驅(qū)動名模塊加載失敗會在dmesg里留痕。第二步看compatible字符串有沒有拼錯直接diff設備樹源文件和驅(qū)動里的字符串比肉眼比對可靠。第三步看總線上有沒有這個clientls /sys/bus/i2c/devices/下面應該有1-0050這樣的目錄目錄名格式是“總線號-地址”。如果沒有說明設備樹節(jié)點沒被解析檢查adapter節(jié)點的status是不是okay以及of_i2c_register_devices有沒有被調(diào)用。第四步如果client存在但probe沒進說明匹配失敗。把驅(qū)動編譯進內(nèi)核而不是模塊看啟動日志里有沒有匹配相關的提示或者打開I2C核心的調(diào)試輸出加內(nèi)核參數(shù)dyndbgfile drivers/i2c/* p能看到匹配過程的細節(jié)。第五步如果probe進了但返回錯誤dev_err_probe輸出的錯誤碼就是方向-EPROBE_DEFER表示依賴資源沒就緒-ENODEV表示探測失敗其他錯誤碼按字面意思查。現(xiàn)象最可能原因快速驗證模塊沒加載依賴未滿足或符號沖突dmesg 看加載日志client 不存在設備樹節(jié)點未使能或解析失敗ls /sys/bus/i2c/devicesclient 存在但無probecompatible 不匹配對比設備樹與驅(qū)動字符串probe 返回 -EPROBE_DEFER電源/時鐘/GPIO 未就緒檢查 regulator 與 pinctrlprobe 返回 -ENXIO地址無應答i2cdetect 掃地址6.2 返回-ENXIO但設備明明焊在上面遇到這個先別改代碼去量波形。我最常遇到的原因有三個。第一上拉電阻沒焊或者阻值太大總線空閑時電平拉不到高示波器一看就是緩坡上升。第二引腳復用沒配對I2C的SCL和SDA被別的功能占用波形上根本看不到時鐘。第三設備供電沒上芯片處于未上電狀態(tài)自然不會應答。軟件側還有一個隱蔽原因10位地址和7位地址混用。如果設備用的是10位地址client-flags必須置I2C_CLIENT_TEN否則發(fā)出去的地址格式不對。10位地址的傳輸會在地址字節(jié)前多發(fā)一個特殊的保留字節(jié)用7位方式發(fā)就完全對不上。再一個可能是地址沖突。同一條總線上兩個設備地址相同i2c_new_client_device在創(chuàng)建第二個時會返回-EBUSY但如果兩個設備是分兩次、在不同時間創(chuàng)建的可能第一個已經(jīng)正常工作了第二個創(chuàng)建失敗而你只看到驅(qū)動沒probe。i2cdetect -y 1能看到那條總線上所有應答的地址掃描結果和預期對比一下多出來的地址就要警惕。6.3 時鐘拉伸、速率與上拉電阻的計算時鐘拉伸是從機在SCL為低時拉住總線不放告訴主機“我還沒準備好”。主機必須支持這個機制否則數(shù)據(jù)會錯。i2c_adapter的timeout和retries在這里就有意義了超時設太短稍微慢一點的從機就被判失敗設太長從機異常拉死總線時CPU會跟著卡很久。我的經(jīng)驗值是從機手冊里給的最大響應時間乘以2到3倍再留一點余量100kHz總線上通常設幾百毫秒到1秒。上拉電阻的取值有公式可算。上升時間約束給出上限Rp(max) tr / (0.8473 * Cb)其中tr是標準允許的最大上升時間100kHz標準模式是1000ns400kHz快速模式是300nsCb是總線電容包括走線、引腳和器件電容通常按100pF到200pF估算。灌電流約束給出下限Rp(min) (Vdd - Vol) / IolVol是低電平最大電壓一般取0.4VIol是引腳能灌入的最小電流常見是3mA。舉個實際例子Vdd取3.3VCb按150pF估400kHz模式下Rp(max) 300ns / (0.8473 * 150pF) ≈ 2360Ω也就是2.36kΩRp(min) (3.3 - 0.4) / 3mA ≈ 967Ω。所以阻值落在約1kΩ到2.2kΩ之間比較合適實際板子上用1.8kΩ或2.2kΩ都很常見。如果總線上掛了七八個設備Cb會變大Rp(max)相應變小這時候就得減小阻值或者降低總線速率。很多人把400kHz切回100kHz問題就消失了本質(zhì)上是上升時間約束被放寬了不是問題真的解決了。6.4 并發(fā)訪問與鎖的處理同一條總線上多個設備、多個驅(qū)動并發(fā)訪問是常態(tài)。i2c_transfer自己會加總線鎖所以單次傳輸之間不會互相踩。但要注意“讀-改-寫”這種復合操作不是原子的先讀一個寄存器判斷某位再寫回去中間可能被另一個設備的傳輸插進來雖然別的設備操作的是自己的地址不影響數(shù)據(jù)但如果兩個線程操作同一個設備就會出競態(tài)。解決辦法是在驅(qū)動內(nèi)部加自己的mutex把針對同一個client的復合操作保護起來。不要用adapter-bus_lock做這件事那是核心層的鎖你手動去拿會破壞封裝。用mutex_lock(client-dev... )也不對正確的做法是在自己的私有結構體里放一把mutexprobe里初始化remove里銷毀。中斷上下文和線程上下文都要訪問設備時鎖的選擇更講究。中斷處理里不能睡但i2c_transfer可能睡所以中斷處理里只能做標記、喚醒線程真正的傳輸放到線程里做。用spin_lock_irqsave保護共享標志位用mutex保護傳輸序列這兩把鎖分工明確不要混用。6.5 我調(diào)I2C時固定會用的幾招i2cdetect是最快的存活檢查-y跳過交互-r用讀方式探測-q用SMBus快速命令探測。有的芯片用讀方式不應答但用寫方式能應答兩種都試一下能省很多時間。i2cdump可以用來快速看一片寄存器區(qū)域確認芯片是否處于預期狀態(tài)不過要小心別去dump那些讀操作有副作用的芯片。內(nèi)核側的調(diào)試輸出我一般開CONFIG_I2C_DEBUG_CORE和CONFIG_I2C_DEBUG_ALGO再配合動態(tài)調(diào)試在drivers/i2c/i2c-core-base.c上打開。這樣做能看到每次傳輸?shù)膍sg構成、地址、方向、返回碼比自己加printk干凈得多。如果懷疑時序問題邏輯分析儀接在SCL和SDA上觸發(fā)條件設成起始位抓一次完整傳輸對照芯片手冊的時序參數(shù)逐個看起始保持時間、數(shù)據(jù)建立時間、停止建立時間哪個不達標就改哪。這個手段看起來笨但定位硬件層面的問題時幾乎沒有替代品。最后分享一個我自己的習慣每寫一個新驅(qū)動先不寫probe邏輯只寫最小骨架——匹配表、probe里讀chip id并打印、remove里打印。確認這三點都通了再往里填功能。這個做法看著慢實際上省掉了大量“功能代碼和匹配問題糾纏在一起”的調(diào)試時間。踩過幾次“以為是寄存器寫錯、其實根本沒進probe”的坑之后這套流程就再也改不掉了。