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