：從MFD到syscon與regmap的底層機制)
1. 一個物理設備為什么要拆成一群驅動MFD的出現(xiàn)邏輯1.1 單驅動時代的維護噩夢做嵌入式Linux驅動開發(fā)的人十有八九會遇到這樣一種芯片一顆芯片里既有ADC又有GPIO還帶兩路LDO、一個看門狗和一個復位控制器。我最早接手這種項目時習慣性地在一個驅動文件里把這些功能全寫了結果probe函數(shù)長得像流水賬IRQ處理里塞滿了各種功能的判斷IOCTL滿天飛。后來同事想單獨復用里面的GPIO驅動幾乎要連鍋端光是拆文件就拆了兩天。這種芯片在嵌入式領域太常見了PMIC、SoC內(nèi)部的混合信號模塊、外掛的編解碼器都是典型的一個物理設備多類功能形態(tài)。如果不做拆分直接的痛點有四個功能耦合ADC讀到一半GPIO來了中斷兩個邏輯互相干擾出問題很難定位。復用困難換一塊主控想保留其中一路regulator的邏輯根本沒法單獨搬走。生命周期混亂一個probe里要初始化多個子系統(tǒng)任何一個失敗都會拖垮全部功能。代碼結構失控維護半年后沒人敢動這個文件改動一處影響全局。所以Linux內(nèi)核才搞出了MFDMulti-Functional Device子系統(tǒng)。它的核心思想很簡單把一個物理設備通過虛擬總線拆分成多個平臺設備每個設備專職做一類事。這樣ADC驅動只管ADCregulator驅動只管穩(wěn)壓GPIO驅動只管引腳各干各的最后通過資源描述把共享的中斷、寄存器配置傳遞下去。1.2 MFD做了一件什么事mfd_cell與子設備注冊MFD的使用模式看一眼代碼就明白了。主設備驅動在probe階段做基礎初始化然后構造一個mfd_cell數(shù)組里面描述每個子功能模塊的名字、資源、設備樹compatible等最后調(diào)用devm_mfd_add_devices()一次性把這些cell注冊成平臺設備。static const struct mfd_cell my_pmic_devs[] { { .name my-pmic-adc, .of_compatible vendor,my-pmic-adc, .num_resources 1, .resources adc_resources, }, { .name my-pmic-gpio, .of_compatible vendor,my-pmic-gpio, .num_resources 1, .resources gpio_resources, }, };主驅動的probe短很多static int my_pmic_probe(struct platform_device *pdev) { struct regmap *regmap; int irq; regmap devm_regmap_init_i2c(to_i2c_client(pdev-dev), config); if (IS_ERR(regmap)) return PTR_ERR(regmap); irq platform_get_irq(pdev, 0); if (irq 0) return irq; /* 注冊中斷控制器 */ ret devm_regmap_add_irq_chip(pdev-dev, regmap, irq, IRQF_ONESHOT, 0, irq_chip, irq_data); if (ret) return ret; return devm_mfd_add_devices(pdev-dev, PLATFORM_DEVID_NONE, my_pmic_devs, ARRAY_SIZE(my_pmic_devs), NULL, 0, NULL); }每個子模塊的驅動寫法和普通platform驅動完全一樣自己注冊一個platform_driver匹配子節(jié)點compatible后在probe里通過platform_get_resource()拿到寄存器地址或中斷號。MFD負責的只是生出這些子設備子設備完全不知道父設備的內(nèi)部實現(xiàn)。這樣設計還有一個隱藏好處很多PMIC可以直接復用內(nèi)核里現(xiàn)成的子驅動比如regulator框架下的regmap_regulator驅動、GPIO框架下的gpio-regmap驅動只要MFD把regmap和中斷域傳遞正確幾乎不用新寫驅動代碼。如果覺得這些概念抽象可以把MFD想象成物業(yè)公司一棟大樓物理芯片有很多房間子功能物業(yè)統(tǒng)一負責水電寄存器映射、門禁中斷控制器各家公司子驅動租下房間后按自己的方式經(jīng)營水電出問題找物業(yè)內(nèi)部業(yè)務互不干涉。2. syscon底層到底藏了什么regmap的誕生和解剖2.1 syscon是“系統(tǒng)控制寄存器區(qū)的統(tǒng)管者”說完MFD再來看syscon。這兩個東西出現(xiàn)頻率一樣高但解決的問題完全不同。SoC里經(jīng)常存在這樣一段寄存器區(qū)域它既不屬于某個標準外設也不歸某個驅動獨占而是一堆雜七雜八的控制位混在一起。比如0x1000處是某個外設的軟復位寄存器0x1004處是睡眠喚醒使能0x1008處又變成了另一個外設的時鐘門控。傳統(tǒng)做法是每個驅動各自ioremap這段地址然后各讀各的。這樣做的后果很糟糕同一段物理內(nèi)存被映射了好幾份虛擬地址沒有統(tǒng)一緩存機制也沒法用內(nèi)核的調(diào)試框架統(tǒng)一查看。syscon就是來解決這個問題的。它把這堆系統(tǒng)控制寄存器抽象成一個統(tǒng)一的設備節(jié)點由內(nèi)核helper在底層創(chuàng)建一個全局共享的regmap實例。別的驅動想操作寄存器時不再自己ioremap而是通過syscon API去拿到這個regmap然后走regmap的讀寫接口。看到這里你應該明白了syscon本身不是一個功能驅動它更像一個寄存器倉庫管理員。誰需要用這段寄存器就到倉庫管理員那里登記一下領一把鑰匙struct regmap *用完了歸還。倉庫內(nèi)部用什么方式管理貨架、怎么做緩存、怎么加鎖調(diào)用者不需要關心。2.2 regmap不是簡單的read/write套殼很多初學者把regmap理解成封裝了read/write函數(shù)的寄存器操作工具這個理解沒錯但低估了它的含金量。regmap真正的價值在于分了兩層緩存層可以配置cache_type把寄存器值緩存在內(nèi)存里避免頻繁訪問慢速總線比如I2C。物理層通過regmap_config里注冊的reg_read、reg_write函數(shù)指針對接實際總線可以是MMIO、I2C、SPI甚至可以是自定義的回調(diào)。static const struct regmap_config my_syscon_config { .reg_bits 32, .val_bits 32, .reg_stride 4, .max_register 0x3ff, .cache_type REGCACHE_RBTREE, };對于一個regmap實例幾乎所有操作都收斂成幾個通用函數(shù)regmap_read(regmap, reg, val)讀單個寄存器。regmap_write(regmap, reg, val)寫單個寄存器。regmap_update_bits(regmap, reg, mask, val)讀-改-寫保證并發(fā)安全。regmap_field_read/write操作寄存器里某個bit域不用手動移位并掩碼。syscon在底層創(chuàng)建regmap時會自動從設備樹節(jié)點的reg屬性里解析地址和長度并且根據(jù)reg-io-width屬性設置寄存器位寬一般不需要驅動開發(fā)者手動配置那些初始化參數(shù)。這也是syscon API能短小精悍的原因——它把最繁瑣的配置都干掉了。另外注意一個細節(jié)syscon創(chuàng)建的regmap默認是沒有打開cache的。因為系統(tǒng)控制寄存器往往需要及時反映硬件狀態(tài)如果開了緩存又沒處理好失效邏輯讀到的可能是舊值。這一點在后面的設備樹坑里會詳細展開。3. MFD syscon 合體流程從probe到子設備拿到regmap3.1 一條完整的注冊鏈路MFD和syscon經(jīng)常一起出現(xiàn)因為很多MFD芯片本身就是多個功能模塊共享一大段寄存器空間的典型。它們合體后的注冊鏈路大致是這樣的內(nèi)核在設備模型初始化階段或devm_platform_iomap_resource()被調(diào)用時MFD主驅動先probe。主驅動解析設備樹找到compatible syscon的節(jié)點調(diào)用syscon_node_to_regmap()獲得統(tǒng)一regmap。主驅動用這個regmap繼續(xù)初始化芯片的基礎功能讀版本號、響應軟復位、初始化中斷控制寄存器。主驅動注冊MFD的子設備通過mfd_cell或設備樹子節(jié)點把資源、中斷域傳遞下去。子驅動probe時再次通過syscon API拿到同一個regmap然后各自操作屬于自己的寄存器區(qū)間。這種設計最關鍵的一點是所有子驅動共享同一個regmap實例而不是各自創(chuàng)建一份。這樣不僅節(jié)省內(nèi)存還能保證并發(fā)安全——regmap內(nèi)部自帶了spinlock或mutex多個驅動同時讀寫同一段寄存器不會打架。以實際代碼為例。假設一個PMIC主驅動的probe里有這樣的初始化static int pmic_main_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; struct regmap_irq_chip_data *irq_data; unsigned int version; int ret; /* 通過設備樹phandle找到syscon節(jié)點對應的regmap */ regmap syscon_regmap_lookup_by_phandle(dev-of_node, pmic,regmap); if (IS_ERR(regmap)) return PTR_ERR(regmap); /* 讀取芯片版本寄存器的bit[4:0] */ ret regmap_read(regmap, PMIC_VERSION_REG, version); if (ret) return ret; dev_info(dev, PMIC version: 0x%x\n, version 0x1f); /* 在這里注冊regmap irq chip為子設備提供中斷 */ ret devm_regmap_add_irq_chip(dev, regmap, irq, IRQF_ONESHOT, 0, pmic_irq_chip, irq_data); if (ret) return ret; /* 注冊MFD子設備 */ return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, pmic_cells, ARRAY_SIZE(pmic_cells), NULL, 0, irq_data); }再來看子驅動側比如ADC子驅動。它的probe里不需要重復初始化regmap直接查phandle拿現(xiàn)成的regmap就行static int pmic_adc_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; regmap syscon_regmap_lookup_by_phandle(dev-of_node, syscon); if (IS_ERR(regmap)) return PTR_ERR(regmap); /* 利用regmap_field取得某個ADC轉換結果位域 */ adc_data-field devm_regmap_field_alloc(dev, regmap, adc_field_config); if (IS_ERR(adc_data-field)) return PTR_ERR(adc_data-field); return 0; }這種模式的好處顯而易見主驅動負責大而全的基礎工作子驅動負責小而專的業(yè)務邏輯。寄存器映射、中斷分發(fā)這些容易出錯的部分被MFD和syscon徹底封裝掉了。3.2 simple-mfd與syscon配合的設備樹解法在設備樹層面一個常見的組合是compatible syscon, simple-mfdpmic: pmic20000000 { compatible syscon, simple-mfd; reg 0x20000000 0x1000; #address-cells 1; #size-cells 1; adc0 { compatible vendor,pmic-adc; reg 0x0 0x100; interrupts 5 IRQ_TYPE_LEVEL_HIGH; /* 子驅動拿到同一顆芯片的regmap */ syscon pmic; }; gpio100 { compatible vendor,pmic-gpio; reg 0x100 0x100; gpio-controller; #gpio-cells 2; }; };這里syscon負責把這顆芯片的寄存器空間變成統(tǒng)一regmapsimple-mfd則告訴內(nèi)核這個節(jié)點下面還有子設備需要of_platform_populate()把它們都創(chuàng)建出來。兩者疊加之后一個節(jié)點同時完成了寄存器倉庫和子設備掛載兩個工作。需要提醒一下simple-mfdsyscon的寫法在內(nèi)核社區(qū)有過一些爭論。某些維護者認為simple-mfd節(jié)點的子設備不應該共用父節(jié)點的regmap字段而應該通過phandle顯式傳遞。但從實際項目來看這種寫法在大量SoC平臺都工作正常只要子設備驅動里用syscon_regmap_lookup_by_phandle()明確引用父節(jié)點而不是隱式依賴就會很安全。3.3 中斷與寄存器regmap_irq_chip讓父設備更穩(wěn)定MFD芯片的另一個復雜點在中斷。一顆PMIC通常只有一個中斷輸出引腳但內(nèi)部可能掛了十幾個中斷源ADC完成中斷、過壓保護中斷、看門狗超時中斷、按鍵檢測中斷……如果這些都要子驅動各自去處理原始中斷那父設備的中斷引腳早就被搶破了。Linux內(nèi)核的regmap_irq_chip方案可以完美處理這件事。它利用regmap讀寫能力直接操作中斷狀態(tài)寄存器和屏蔽寄存器把單一物理中斷拆成多個虛擬中斷并建立一個irq domain讓子設備通過platform_get_irq()拿到屬于自己的中斷號。static const struct regmap_irq pmic_irqs[] { REGMAP_IRQ_REG(PMIC_IRQ_ADC_DONE, 0x10, BIT(0)), REGMAP_IRQ_REG(PMIC_IRQ_OVP, 0x10, BIT(1)), REGMAP_IRQ_REG(PMIC_IRQ_WDOG, 0x10, BIT(2)), }; static const struct regmap_irq_chip pmic_irq_chip { .name pmic-irq, .status_base 0x10, .mask_base 0x12, .unmask_base 0x13, .ack_base 0x11, .num_irqs ARRAY_SIZE(pmic_irqs), .irqs pmic_irqs, };實現(xiàn)這種機制之后子驅動像處理普通外設中斷一樣注冊request_threaded_irq()就可以寄存器層面的狀態(tài)判斷、中斷清除全部由regmap_irq_chip自動完成。這既簡化了子驅動又保證了中斷響應的一致性。4. 驅動側最常用的syscon API選型與用法4.1 查找regmap的三個API對比syscon相關API里日常打交道最多的就是下面這三個API參數(shù)適用場景返回說明syscon_node_to_regmap()struct device_node *np已知節(jié)點指針直接獲取該節(jié)點對應的regmap成功返回struct regmap *失敗返回ERR_PTRsyscon_regmap_lookup_by_compatible()const char *compatible不知道具體節(jié)點只知道compatible字符串同上syscon_regmap_lookup_by_phandle()struct device_node *np,const char *property子驅動通過設備樹屬性引用父syscon節(jié)點同上三者的關系可以用一句話概括syscon_node_to_regmap()是底層實現(xiàn)后兩個是它的封裝。實際開發(fā)中我推薦優(yōu)先使用syscon_regmap_lookup_by_phandle()因為它在設備樹里顯式聲明了依賴關系可讀性最強也方便后續(xù)維護的人一眼看出這個驅動在用哪個syscon節(jié)點。一個容易忽略的細節(jié)這幾個函數(shù)返回的都是ERR_PTR判斷失敗時一定要用IS_ERR()不能直接比較NULL。很多新手在probe里寫regmap syscon_regmap_lookup_by_phandle(np, syscon); if (!regmap) return -EINVAL;這樣寫一旦返回ERR_PTR(-EPROBE_DEFER)會被當成成功后面繼續(xù)操作就會訪問非法指針內(nèi)核直接oops。正確的寫法是regmap syscon_regmap_lookup_by_phandle(np, syscon); if (IS_ERR(regmap)) { ret PTR_ERR(regmap); if (ret -EPROBE_DEFER) return ret; dev_err(dev, failed to get syscon regmap: %d\n, ret); return ret; }4.2 讀寫寄存器regmap_update_bits與regmap_field實操拿到regmap之后具體的寄存器操作也有講究。直接regmap_write()寫一個整值寄存器是最簡單的情況但實際項目里更多時候要求只改某個寄存器里的某幾個bit其他bit保持不變。這時候如果用read-modify-write需要自己加鎖、自己移位非常容易寫錯。regmap_update_bits()就是為這種場景準備的/* 在寄存器0x20的bit[7:5]寫入新的分頻系數(shù) */ ret regmap_update_bits(regmap, 0x20, 0xe0, div 5);參數(shù)含義分別是regmap、寄存器地址、掩碼哪幾位會被改動、新值已經(jīng)左移對齊到位域上。regmap內(nèi)部會處理讀改寫和并發(fā)保護比自己手動操作可靠得多。更進一步的方案是regmap_field。它的作用是預先描述一個位域之后操作這個位域只需要一句regmap_field_write()完全不用管移位和掩碼。static const struct reg_field version_field REG_FIELD(0x00, 0, 4); field devm_regmap_field_alloc(dev, regmap, version_field); if (IS_ERR(field)) return PTR_ERR(field); ret regmap_field_read(field, version);假如寄存器地址是0x00bit[0]到bit[4]存的是版本號用REG_FIELD(reg, lsb, msb)聲明之后regmap_field_read()讀出來的就直接是版本號數(shù)值不需要知道它在哪個bit、也不需要手動移位。平時我寫MFD子驅動凡是涉及芯片功能配置的地方都傾向用regmap_field。它還有一個好處是讓寄存器布局變得更加集中和顯眼后續(xù)查硬件手冊對照代碼時效率高很多。4.3 一個可供抄作業(yè)的例子下面用一段完整的最小示例演示子驅動里如何拿到syscon regmap并完成讀版本號更新bit域兩步典型操作static int demo_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; struct regmap_field *cfg_field; unsigned int version; int ret; regmap syscon_regmap_lookup_by_phandle(dev-of_node, syscon); if (IS_ERR(regmap)) return dev_err_probe(dev, PTR_ERR(regmap), failed to get syscon regmap\n); ret regmap_read(regmap, 0x00, version); if (ret) return ret; dev_info(dev, chip version: 0x%x\n, version); cfg_field devm_regmap_field_alloc(dev, regmap, REG_FIELD(0x20, 1, 3)); if (IS_ERR(cfg_field)) return PTR_ERR(cfg_field); /* 開啟某個功能位同時保留其他bit不變 */ ret regmap_field_write(cfg_field, 0x5); if (ret) return ret; return 0; }dev_err_probe()是內(nèi)核5.2以后比較推薦的錯誤返回方式它既能打印日志又能在-EPROBE_DEFER時靜默處理避免啟動階段刷屏。如果你維護的內(nèi)核版本較老沒有這個函數(shù)也可以自己用IS_ERR加條件判斷實現(xiàn)同樣的邏輯。5. 設備樹里容易被忽視的坑5.1 compatible的順序問題compatible屬性是有順序語義的。內(nèi)核在匹配驅動時會按順序比較第一個字符串。所以compatible syscon, simple-mfd和compatible simple-mfd, syscon效果完全不同。syscon框架在of_syscon_register()里會遍歷compatible屬性找到包含syscon的字符串才會執(zhí)行注冊邏輯。如果把simple-mfd放在前面某些內(nèi)核版本在遍歷到第一個字符串時可能不會繼續(xù)查找syscon導致syscon注冊失敗。正確做法是把syscon放在第一個compatible syscon, simple-mfd;這一點在文檔里經(jīng)常被忽略但在實際排障中能省下很多時間。如果你發(fā)現(xiàn)子驅動調(diào)用syscon_regmap_lookup_by_phandle()返回-EINVAL先檢查一下這個順序。5.2 reg重疊問題syscon的管理粒度是節(jié)點。兩個不同的設備樹節(jié)點即使reg指向同一段物理地址也會被syscon創(chuàng)建成兩個獨立regmap實例。這意味著同一塊寄存器可能被兩個驅動同時訪問卻沒有任何同步機制。我見過一個項目兩個模塊分別定義了syscon節(jié)點指向同一段寄存器區(qū)域各自操作自己的bit。結果A模塊寫入的數(shù)據(jù)被B模塊的緩存覆蓋問題極其隱蔽用調(diào)試器看硬件寄存器完全正常但軟件讀出來總是不對。正解是整個系統(tǒng)里同一段物理寄存器區(qū)域只允許一個syscon節(jié)點。其他模塊通過phandle引用這個唯一節(jié)點獲取regmap。所以設備樹里看到重復的syscon定義不要猶豫先合并再往下查。5.3 cache與只讀寄存器如果你在子驅動里自建regmap并打開cache會遇到一類典型問題寄存器由硬件自動更新比如中斷狀態(tài)寄存器、ADC結果寄存器但regmap緩存不會自動失效驅動讀到的永遠是緩存里的舊值。syscon默認regmap是不開cache的cache_type REGCACHE_NONE所以直接用syscon場景下這個問題不常見。但如果你在MFD主驅動里自定義了regmap且開了cache必須對硬件自動更新的寄存器做特殊處理要么在讀取時設置regmap_bypass標志跳過緩存要么把這些寄存器設置為volatile讓regmap每次都走物理總線讀取要么在硬件更新后手動調(diào)用regmap_cache_only(false)并flush。在配置regmap_config時如果確定某些寄存器是硬件自動更新的可以在volatile_reg回調(diào)里返回true這是最干凈的方案。5.4 probe順序與EPROBE_DEFERsimple-mfdsyscon場景下子設備的probe順序并不嚴格。如果子驅動依賴主MFD的regmap_irq_chip已經(jīng)注冊完畢而設備樹順序恰好讓子設備先probe就會遇到中斷資源不存在的問題。這種情況下子驅動不能直接將-ENXIO返回了事而應該返回-EPROBE_DEFER告訴內(nèi)核我還沒準備好過一會兒再試我一次。內(nèi)核會在后續(xù)時機重新觸發(fā)probe直到依賴條件滿足。判斷一個錯誤是否應該返回-EPROBE_DEFER有個簡單標準如果這個資源是由另一個驅動/框架注冊的并且名字里帶devm_或irq_domain大概率需要-EPROBE_DEFER。比如platform_get_irq()返回-ENXIO時先別急著報錯確認中斷域是否已注冊如果沒注冊就返回-EPROBE_DEFER。6. 調(diào)試經(jīng)驗和一次真實排障6.1 用debugfs把regmap扒開看內(nèi)核默認開啟CONFIG_DEBUG_FS和CONFIG_REGMAP_DEBUG后每個regmap實例都會在/sys/kernel/debug/regmap/目錄下生成一個子目錄。目錄名通常是設備名加序號里面有registers當前所有寄存器的值。access每個寄存器的可讀可寫權限表。range寄存器地址范圍信息。遇到驅動讀出來的寄存器值和硬件手冊對不上第一步就去看這里cat /sys/kernel/debug/regmap/*/registers輸出大概是00: 00000010 04: 00000000 08: 00000001這能快速告訴你是驅動讀錯了地址還是物理總線上的值本身就不對。如果地址范圍里沒有你要看的寄存器那多半是max_register配置太小了regmap直接拒絕越界訪問。6.2 devmem交叉驗證debugfs只能反映軟件層面的regmap視角要驗證硬件真實狀態(tài)還需要一把物理標尺。在嵌入式Linux的busybox環(huán)境里通常有devmem工具# 查看物理地址0x20000020處的32位值 devmem 0x20000020 32這個命令繞過regmap直接讀物理地址。如果devmem讀出來的值與debugfs里regmap顯示的不一致問題基本可以鎖定在regmap緩存或者寄存器地址映射方向如果兩邊一致但和硬件手冊預期不符那就要檢查設備樹里的reg地址、reg-io-width是否與芯片選型匹配了。devmem讀出來的物理地址必須和reg屬性完全對應如果syscon節(jié)點有多個reg段還要確認你讀的是哪一段。這里沒有捷徑只能對著芯片手冊逐項核對。6.3 共享regmap的釋放坑syscon返回的regmap是所有驅動共享的負責創(chuàng)建它的一般是syscon框架或MFD主驅動。子驅動在remove時千萬不要去調(diào)用regmap_exit()或devm_regmap_exit()之類的東西這個regmap并不歸你管。我踩過一次很隱蔽的坑某子驅動在remove里加了regmap_exit(regmap)試圖清理資源。結果另一個正在運行的驅動拿著同一個regmap指針下一次regmap_read直接崩潰而且現(xiàn)場看起來完全像硬件故障。排查了整整一個下午最后在代碼review里發(fā)現(xiàn)是這個熱心的release函數(shù)干的好事。關于共享對象原則很簡單誰創(chuàng)建誰釋放。通過syscon API拿到的regmap生命周期由syscon框架統(tǒng)一管理子驅動只需使用即可。6.4 probe失敗排查清單最后整理一份排查清單純經(jīng)驗總結按出現(xiàn)頻率排序現(xiàn)象常見原因定位手段syscon_regmap_lookup_by_phandle返回-EINVAL設備樹節(jié)點compatible順序不對或屬性沒寫檢查/proc/device-tree下對應節(jié)點的compatible屬性返回-EPROBE_DEFERsyscon節(jié)點尚未完成注冊確認節(jié)點沒有被status disabled禁用regmap_read返回-EIO寄存器地址超過max_register查看debugfs regmap目錄下的range讀到的值一直不變緩存未失效檢查volatile_reg配置用devmem交叉驗證中斷一直不觸發(fā)irq domain尚未注冊查看/proc/interrupts確認子驅動中斷號是否映射成功probe反復重入父設備和子設備probe順序沖突確認返回了-EPROBE_DEFER而不是-ENXIO做MFD syscon開發(fā)最大的經(jīng)驗其實就一句話不要試圖繞過框架自己管理底層寄存器。MFD已經(jīng)把芯片拆分的骨架搭好了syscon把寄存器訪問的內(nèi)存管理做透了我們要做的只是把業(yè)務邏輯裝進合適的殼里。真正難搞的問題往往不是代碼寫不出來而是沒有理解框架為什么這樣設計。只要能想明白誰創(chuàng)建、誰使用、誰釋放這三個問題整個驅動架構就會清晰很多。 嵌入式Linux驅動開發(fā)：從MFD到syscon與regmap的底層機制
1. 一個物理設備為什么要拆成一群驅動MFD的出現(xiàn)邏輯1.1 單驅動時代的維護噩夢做嵌入式Linux驅動開發(fā)的人十有八九會遇到這樣一種芯片一顆芯片里既有ADC又有GPIO還帶兩路LDO、一個看門狗和一個復位控制器。我最早接手這種項目時習慣性地在一個驅動文件里把這些功能全寫了結果probe函數(shù)長得像流水賬IRQ處理里塞滿了各種功能的判斷IOCTL滿天飛。后來同事想單獨復用里面的GPIO驅動幾乎要連鍋端光是拆文件就拆了兩天。這種芯片在嵌入式領域太常見了PMIC、SoC內(nèi)部的混合信號模塊、外掛的編解碼器都是典型的一個物理設備多類功能形態(tài)。如果不做拆分直接的痛點有四個功能耦合ADC讀到一半GPIO來了中斷兩個邏輯互相干擾出問題很難定位。復用困難換一塊主控想保留其中一路regulator的邏輯根本沒法單獨搬走。生命周期混亂一個probe里要初始化多個子系統(tǒng)任何一個失敗都會拖垮全部功能。代碼結構失控維護半年后沒人敢動這個文件改動一處影響全局。所以Linux內(nèi)核才搞出了MFDMulti-Functional Device子系統(tǒng)。它的核心思想很簡單把一個物理設備通過虛擬總線拆分成多個平臺設備每個設備專職做一類事。這樣ADC驅動只管ADCregulator驅動只管穩(wěn)壓GPIO驅動只管引腳各干各的最后通過資源描述把共享的中斷、寄存器配置傳遞下去。1.2 MFD做了一件什么事mfd_cell與子設備注冊MFD的使用模式看一眼代碼就明白了。主設備驅動在probe階段做基礎初始化然后構造一個mfd_cell數(shù)組里面描述每個子功能模塊的名字、資源、設備樹compatible等最后調(diào)用devm_mfd_add_devices()一次性把這些cell注冊成平臺設備。static const struct mfd_cell my_pmic_devs[] { { .name my-pmic-adc, .of_compatible vendor,my-pmic-adc, .num_resources 1, .resources adc_resources, }, { .name my-pmic-gpio, .of_compatible vendor,my-pmic-gpio, .num_resources 1, .resources gpio_resources, }, };主驅動的probe短很多static int my_pmic_probe(struct platform_device *pdev) { struct regmap *regmap; int irq; regmap devm_regmap_init_i2c(to_i2c_client(pdev-dev), config); if (IS_ERR(regmap)) return PTR_ERR(regmap); irq platform_get_irq(pdev, 0); if (irq 0) return irq; /* 注冊中斷控制器 */ ret devm_regmap_add_irq_chip(pdev-dev, regmap, irq, IRQF_ONESHOT, 0, irq_chip, irq_data); if (ret) return ret; return devm_mfd_add_devices(pdev-dev, PLATFORM_DEVID_NONE, my_pmic_devs, ARRAY_SIZE(my_pmic_devs), NULL, 0, NULL); }每個子模塊的驅動寫法和普通platform驅動完全一樣自己注冊一個platform_driver匹配子節(jié)點compatible后在probe里通過platform_get_resource()拿到寄存器地址或中斷號。MFD負責的只是生出這些子設備子設備完全不知道父設備的內(nèi)部實現(xiàn)。這樣設計還有一個隱藏好處很多PMIC可以直接復用內(nèi)核里現(xiàn)成的子驅動比如regulator框架下的regmap_regulator驅動、GPIO框架下的gpio-regmap驅動只要MFD把regmap和中斷域傳遞正確幾乎不用新寫驅動代碼。如果覺得這些概念抽象可以把MFD想象成物業(yè)公司一棟大樓物理芯片有很多房間子功能物業(yè)統(tǒng)一負責水電寄存器映射、門禁中斷控制器各家公司子驅動租下房間后按自己的方式經(jīng)營水電出問題找物業(yè)內(nèi)部業(yè)務互不干涉。2. syscon底層到底藏了什么regmap的誕生和解剖2.1 syscon是“系統(tǒng)控制寄存器區(qū)的統(tǒng)管者”說完MFD再來看syscon。這兩個東西出現(xiàn)頻率一樣高但解決的問題完全不同。SoC里經(jīng)常存在這樣一段寄存器區(qū)域它既不屬于某個標準外設也不歸某個驅動獨占而是一堆雜七雜八的控制位混在一起。比如0x1000處是某個外設的軟復位寄存器0x1004處是睡眠喚醒使能0x1008處又變成了另一個外設的時鐘門控。傳統(tǒng)做法是每個驅動各自ioremap這段地址然后各讀各的。這樣做的后果很糟糕同一段物理內(nèi)存被映射了好幾份虛擬地址沒有統(tǒng)一緩存機制也沒法用內(nèi)核的調(diào)試框架統(tǒng)一查看。syscon就是來解決這個問題的。它把這堆系統(tǒng)控制寄存器抽象成一個統(tǒng)一的設備節(jié)點由內(nèi)核helper在底層創(chuàng)建一個全局共享的regmap實例。別的驅動想操作寄存器時不再自己ioremap而是通過syscon API去拿到這個regmap然后走regmap的讀寫接口。看到這里你應該明白了syscon本身不是一個功能驅動它更像一個寄存器倉庫管理員。誰需要用這段寄存器就到倉庫管理員那里登記一下領一把鑰匙struct regmap *用完了歸還。倉庫內(nèi)部用什么方式管理貨架、怎么做緩存、怎么加鎖調(diào)用者不需要關心。2.2 regmap不是簡單的read/write套殼很多初學者把regmap理解成封裝了read/write函數(shù)的寄存器操作工具這個理解沒錯但低估了它的含金量。regmap真正的價值在于分了兩層緩存層可以配置cache_type把寄存器值緩存在內(nèi)存里避免頻繁訪問慢速總線比如I2C。物理層通過regmap_config里注冊的reg_read、reg_write函數(shù)指針對接實際總線可以是MMIO、I2C、SPI甚至可以是自定義的回調(diào)。static const struct regmap_config my_syscon_config { .reg_bits 32, .val_bits 32, .reg_stride 4, .max_register 0x3ff, .cache_type REGCACHE_RBTREE, };對于一個regmap實例幾乎所有操作都收斂成幾個通用函數(shù)regmap_read(regmap, reg, val)讀單個寄存器。regmap_write(regmap, reg, val)寫單個寄存器。regmap_update_bits(regmap, reg, mask, val)讀-改-寫保證并發(fā)安全。regmap_field_read/write操作寄存器里某個bit域不用手動移位并掩碼。syscon在底層創(chuàng)建regmap時會自動從設備樹節(jié)點的reg屬性里解析地址和長度并且根據(jù)reg-io-width屬性設置寄存器位寬一般不需要驅動開發(fā)者手動配置那些初始化參數(shù)。這也是syscon API能短小精悍的原因——它把最繁瑣的配置都干掉了。另外注意一個細節(jié)syscon創(chuàng)建的regmap默認是沒有打開cache的。因為系統(tǒng)控制寄存器往往需要及時反映硬件狀態(tài)如果開了緩存又沒處理好失效邏輯讀到的可能是舊值。這一點在后面的設備樹坑里會詳細展開。3. MFD syscon 合體流程從probe到子設備拿到regmap3.1 一條完整的注冊鏈路MFD和syscon經(jīng)常一起出現(xiàn)因為很多MFD芯片本身就是多個功能模塊共享一大段寄存器空間的典型。它們合體后的注冊鏈路大致是這樣的內(nèi)核在設備模型初始化階段或devm_platform_iomap_resource()被調(diào)用時MFD主驅動先probe。主驅動解析設備樹找到compatible syscon的節(jié)點調(diào)用syscon_node_to_regmap()獲得統(tǒng)一regmap。主驅動用這個regmap繼續(xù)初始化芯片的基礎功能讀版本號、響應軟復位、初始化中斷控制寄存器。主驅動注冊MFD的子設備通過mfd_cell或設備樹子節(jié)點把資源、中斷域傳遞下去。子驅動probe時再次通過syscon API拿到同一個regmap然后各自操作屬于自己的寄存器區(qū)間。這種設計最關鍵的一點是所有子驅動共享同一個regmap實例而不是各自創(chuàng)建一份。這樣不僅節(jié)省內(nèi)存還能保證并發(fā)安全——regmap內(nèi)部自帶了spinlock或mutex多個驅動同時讀寫同一段寄存器不會打架。以實際代碼為例。假設一個PMIC主驅動的probe里有這樣的初始化static int pmic_main_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; struct regmap_irq_chip_data *irq_data; unsigned int version; int ret; /* 通過設備樹phandle找到syscon節(jié)點對應的regmap */ regmap syscon_regmap_lookup_by_phandle(dev-of_node, pmic,regmap); if (IS_ERR(regmap)) return PTR_ERR(regmap); /* 讀取芯片版本寄存器的bit[4:0] */ ret regmap_read(regmap, PMIC_VERSION_REG, version); if (ret) return ret; dev_info(dev, PMIC version: 0x%x\n, version 0x1f); /* 在這里注冊regmap irq chip為子設備提供中斷 */ ret devm_regmap_add_irq_chip(dev, regmap, irq, IRQF_ONESHOT, 0, pmic_irq_chip, irq_data); if (ret) return ret; /* 注冊MFD子設備 */ return devm_mfd_add_devices(dev, PLATFORM_DEVID_NONE, pmic_cells, ARRAY_SIZE(pmic_cells), NULL, 0, irq_data); }再來看子驅動側比如ADC子驅動。它的probe里不需要重復初始化regmap直接查phandle拿現(xiàn)成的regmap就行static int pmic_adc_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; regmap syscon_regmap_lookup_by_phandle(dev-of_node, syscon); if (IS_ERR(regmap)) return PTR_ERR(regmap); /* 利用regmap_field取得某個ADC轉換結果位域 */ adc_data-field devm_regmap_field_alloc(dev, regmap, adc_field_config); if (IS_ERR(adc_data-field)) return PTR_ERR(adc_data-field); return 0; }這種模式的好處顯而易見主驅動負責大而全的基礎工作子驅動負責小而專的業(yè)務邏輯。寄存器映射、中斷分發(fā)這些容易出錯的部分被MFD和syscon徹底封裝掉了。3.2 simple-mfd與syscon配合的設備樹解法在設備樹層面一個常見的組合是compatible syscon, simple-mfdpmic: pmic20000000 { compatible syscon, simple-mfd; reg 0x20000000 0x1000; #address-cells 1; #size-cells 1; adc0 { compatible vendor,pmic-adc; reg 0x0 0x100; interrupts 5 IRQ_TYPE_LEVEL_HIGH; /* 子驅動拿到同一顆芯片的regmap */ syscon pmic; }; gpio100 { compatible vendor,pmic-gpio; reg 0x100 0x100; gpio-controller; #gpio-cells 2; }; };這里syscon負責把這顆芯片的寄存器空間變成統(tǒng)一regmapsimple-mfd則告訴內(nèi)核這個節(jié)點下面還有子設備需要of_platform_populate()把它們都創(chuàng)建出來。兩者疊加之后一個節(jié)點同時完成了寄存器倉庫和子設備掛載兩個工作。需要提醒一下simple-mfdsyscon的寫法在內(nèi)核社區(qū)有過一些爭論。某些維護者認為simple-mfd節(jié)點的子設備不應該共用父節(jié)點的regmap字段而應該通過phandle顯式傳遞。但從實際項目來看這種寫法在大量SoC平臺都工作正常只要子設備驅動里用syscon_regmap_lookup_by_phandle()明確引用父節(jié)點而不是隱式依賴就會很安全。3.3 中斷與寄存器regmap_irq_chip讓父設備更穩(wěn)定MFD芯片的另一個復雜點在中斷。一顆PMIC通常只有一個中斷輸出引腳但內(nèi)部可能掛了十幾個中斷源ADC完成中斷、過壓保護中斷、看門狗超時中斷、按鍵檢測中斷……如果這些都要子驅動各自去處理原始中斷那父設備的中斷引腳早就被搶破了。Linux內(nèi)核的regmap_irq_chip方案可以完美處理這件事。它利用regmap讀寫能力直接操作中斷狀態(tài)寄存器和屏蔽寄存器把單一物理中斷拆成多個虛擬中斷并建立一個irq domain讓子設備通過platform_get_irq()拿到屬于自己的中斷號。static const struct regmap_irq pmic_irqs[] { REGMAP_IRQ_REG(PMIC_IRQ_ADC_DONE, 0x10, BIT(0)), REGMAP_IRQ_REG(PMIC_IRQ_OVP, 0x10, BIT(1)), REGMAP_IRQ_REG(PMIC_IRQ_WDOG, 0x10, BIT(2)), }; static const struct regmap_irq_chip pmic_irq_chip { .name pmic-irq, .status_base 0x10, .mask_base 0x12, .unmask_base 0x13, .ack_base 0x11, .num_irqs ARRAY_SIZE(pmic_irqs), .irqs pmic_irqs, };實現(xiàn)這種機制之后子驅動像處理普通外設中斷一樣注冊request_threaded_irq()就可以寄存器層面的狀態(tài)判斷、中斷清除全部由regmap_irq_chip自動完成。這既簡化了子驅動又保證了中斷響應的一致性。4. 驅動側最常用的syscon API選型與用法4.1 查找regmap的三個API對比syscon相關API里日常打交道最多的就是下面這三個API參數(shù)適用場景返回說明syscon_node_to_regmap()struct device_node *np已知節(jié)點指針直接獲取該節(jié)點對應的regmap成功返回struct regmap *失敗返回ERR_PTRsyscon_regmap_lookup_by_compatible()const char *compatible不知道具體節(jié)點只知道compatible字符串同上syscon_regmap_lookup_by_phandle()struct device_node *np,const char *property子驅動通過設備樹屬性引用父syscon節(jié)點同上三者的關系可以用一句話概括syscon_node_to_regmap()是底層實現(xiàn)后兩個是它的封裝。實際開發(fā)中我推薦優(yōu)先使用syscon_regmap_lookup_by_phandle()因為它在設備樹里顯式聲明了依賴關系可讀性最強也方便后續(xù)維護的人一眼看出這個驅動在用哪個syscon節(jié)點。一個容易忽略的細節(jié)這幾個函數(shù)返回的都是ERR_PTR判斷失敗時一定要用IS_ERR()不能直接比較NULL。很多新手在probe里寫regmap syscon_regmap_lookup_by_phandle(np, syscon); if (!regmap) return -EINVAL;這樣寫一旦返回ERR_PTR(-EPROBE_DEFER)會被當成成功后面繼續(xù)操作就會訪問非法指針內(nèi)核直接oops。正確的寫法是regmap syscon_regmap_lookup_by_phandle(np, syscon); if (IS_ERR(regmap)) { ret PTR_ERR(regmap); if (ret -EPROBE_DEFER) return ret; dev_err(dev, failed to get syscon regmap: %d\n, ret); return ret; }4.2 讀寫寄存器regmap_update_bits與regmap_field實操拿到regmap之后具體的寄存器操作也有講究。直接regmap_write()寫一個整值寄存器是最簡單的情況但實際項目里更多時候要求只改某個寄存器里的某幾個bit其他bit保持不變。這時候如果用read-modify-write需要自己加鎖、自己移位非常容易寫錯。regmap_update_bits()就是為這種場景準備的/* 在寄存器0x20的bit[7:5]寫入新的分頻系數(shù) */ ret regmap_update_bits(regmap, 0x20, 0xe0, div 5);參數(shù)含義分別是regmap、寄存器地址、掩碼哪幾位會被改動、新值已經(jīng)左移對齊到位域上。regmap內(nèi)部會處理讀改寫和并發(fā)保護比自己手動操作可靠得多。更進一步的方案是regmap_field。它的作用是預先描述一個位域之后操作這個位域只需要一句regmap_field_write()完全不用管移位和掩碼。static const struct reg_field version_field REG_FIELD(0x00, 0, 4); field devm_regmap_field_alloc(dev, regmap, version_field); if (IS_ERR(field)) return PTR_ERR(field); ret regmap_field_read(field, version);假如寄存器地址是0x00bit[0]到bit[4]存的是版本號用REG_FIELD(reg, lsb, msb)聲明之后regmap_field_read()讀出來的就直接是版本號數(shù)值不需要知道它在哪個bit、也不需要手動移位。平時我寫MFD子驅動凡是涉及芯片功能配置的地方都傾向用regmap_field。它還有一個好處是讓寄存器布局變得更加集中和顯眼后續(xù)查硬件手冊對照代碼時效率高很多。4.3 一個可供抄作業(yè)的例子下面用一段完整的最小示例演示子驅動里如何拿到syscon regmap并完成讀版本號更新bit域兩步典型操作static int demo_probe(struct platform_device *pdev) { struct device *dev pdev-dev; struct regmap *regmap; struct regmap_field *cfg_field; unsigned int version; int ret; regmap syscon_regmap_lookup_by_phandle(dev-of_node, syscon); if (IS_ERR(regmap)) return dev_err_probe(dev, PTR_ERR(regmap), failed to get syscon regmap\n); ret regmap_read(regmap, 0x00, version); if (ret) return ret; dev_info(dev, chip version: 0x%x\n, version); cfg_field devm_regmap_field_alloc(dev, regmap, REG_FIELD(0x20, 1, 3)); if (IS_ERR(cfg_field)) return PTR_ERR(cfg_field); /* 開啟某個功能位同時保留其他bit不變 */ ret regmap_field_write(cfg_field, 0x5); if (ret) return ret; return 0; }dev_err_probe()是內(nèi)核5.2以后比較推薦的錯誤返回方式它既能打印日志又能在-EPROBE_DEFER時靜默處理避免啟動階段刷屏。如果你維護的內(nèi)核版本較老沒有這個函數(shù)也可以自己用IS_ERR加條件判斷實現(xiàn)同樣的邏輯。5. 設備樹里容易被忽視的坑5.1 compatible的順序問題compatible屬性是有順序語義的。內(nèi)核在匹配驅動時會按順序比較第一個字符串。所以compatible syscon, simple-mfd和compatible simple-mfd, syscon效果完全不同。syscon框架在of_syscon_register()里會遍歷compatible屬性找到包含syscon的字符串才會執(zhí)行注冊邏輯。如果把simple-mfd放在前面某些內(nèi)核版本在遍歷到第一個字符串時可能不會繼續(xù)查找syscon導致syscon注冊失敗。正確做法是把syscon放在第一個compatible syscon, simple-mfd;這一點在文檔里經(jīng)常被忽略但在實際排障中能省下很多時間。如果你發(fā)現(xiàn)子驅動調(diào)用syscon_regmap_lookup_by_phandle()返回-EINVAL先檢查一下這個順序。5.2 reg重疊問題syscon的管理粒度是節(jié)點。兩個不同的設備樹節(jié)點即使reg指向同一段物理地址也會被syscon創(chuàng)建成兩個獨立regmap實例。這意味著同一塊寄存器可能被兩個驅動同時訪問卻沒有任何同步機制。我見過一個項目兩個模塊分別定義了syscon節(jié)點指向同一段寄存器區(qū)域各自操作自己的bit。結果A模塊寫入的數(shù)據(jù)被B模塊的緩存覆蓋問題極其隱蔽用調(diào)試器看硬件寄存器完全正常但軟件讀出來總是不對。正解是整個系統(tǒng)里同一段物理寄存器區(qū)域只允許一個syscon節(jié)點。其他模塊通過phandle引用這個唯一節(jié)點獲取regmap。所以設備樹里看到重復的syscon定義不要猶豫先合并再往下查。5.3 cache與只讀寄存器如果你在子驅動里自建regmap并打開cache會遇到一類典型問題寄存器由硬件自動更新比如中斷狀態(tài)寄存器、ADC結果寄存器但regmap緩存不會自動失效驅動讀到的永遠是緩存里的舊值。syscon默認regmap是不開cache的cache_type REGCACHE_NONE所以直接用syscon場景下這個問題不常見。但如果你在MFD主驅動里自定義了regmap且開了cache必須對硬件自動更新的寄存器做特殊處理要么在讀取時設置regmap_bypass標志跳過緩存要么把這些寄存器設置為volatile讓regmap每次都走物理總線讀取要么在硬件更新后手動調(diào)用regmap_cache_only(false)并flush。在配置regmap_config時如果確定某些寄存器是硬件自動更新的可以在volatile_reg回調(diào)里返回true這是最干凈的方案。5.4 probe順序與EPROBE_DEFERsimple-mfdsyscon場景下子設備的probe順序并不嚴格。如果子驅動依賴主MFD的regmap_irq_chip已經(jīng)注冊完畢而設備樹順序恰好讓子設備先probe就會遇到中斷資源不存在的問題。這種情況下子驅動不能直接將-ENXIO返回了事而應該返回-EPROBE_DEFER告訴內(nèi)核我還沒準備好過一會兒再試我一次。內(nèi)核會在后續(xù)時機重新觸發(fā)probe直到依賴條件滿足。判斷一個錯誤是否應該返回-EPROBE_DEFER有個簡單標準如果這個資源是由另一個驅動/框架注冊的并且名字里帶devm_或irq_domain大概率需要-EPROBE_DEFER。比如platform_get_irq()返回-ENXIO時先別急著報錯確認中斷域是否已注冊如果沒注冊就返回-EPROBE_DEFER。6. 調(diào)試經(jīng)驗和一次真實排障6.1 用debugfs把regmap扒開看內(nèi)核默認開啟CONFIG_DEBUG_FS和CONFIG_REGMAP_DEBUG后每個regmap實例都會在/sys/kernel/debug/regmap/目錄下生成一個子目錄。目錄名通常是設備名加序號里面有registers當前所有寄存器的值。access每個寄存器的可讀可寫權限表。range寄存器地址范圍信息。遇到驅動讀出來的寄存器值和硬件手冊對不上第一步就去看這里cat /sys/kernel/debug/regmap/*/registers輸出大概是00: 00000010 04: 00000000 08: 00000001這能快速告訴你是驅動讀錯了地址還是物理總線上的值本身就不對。如果地址范圍里沒有你要看的寄存器那多半是max_register配置太小了regmap直接拒絕越界訪問。6.2 devmem交叉驗證debugfs只能反映軟件層面的regmap視角要驗證硬件真實狀態(tài)還需要一把物理標尺。在嵌入式Linux的busybox環(huán)境里通常有devmem工具# 查看物理地址0x20000020處的32位值 devmem 0x20000020 32這個命令繞過regmap直接讀物理地址。如果devmem讀出來的值與debugfs里regmap顯示的不一致問題基本可以鎖定在regmap緩存或者寄存器地址映射方向如果兩邊一致但和硬件手冊預期不符那就要檢查設備樹里的reg地址、reg-io-width是否與芯片選型匹配了。devmem讀出來的物理地址必須和reg屬性完全對應如果syscon節(jié)點有多個reg段還要確認你讀的是哪一段。這里沒有捷徑只能對著芯片手冊逐項核對。6.3 共享regmap的釋放坑syscon返回的regmap是所有驅動共享的負責創(chuàng)建它的一般是syscon框架或MFD主驅動。子驅動在remove時千萬不要去調(diào)用regmap_exit()或devm_regmap_exit()之類的東西這個regmap并不歸你管。我踩過一次很隱蔽的坑某子驅動在remove里加了regmap_exit(regmap)試圖清理資源。結果另一個正在運行的驅動拿著同一個regmap指針下一次regmap_read直接崩潰而且現(xiàn)場看起來完全像硬件故障。排查了整整一個下午最后在代碼review里發(fā)現(xiàn)是這個熱心的release函數(shù)干的好事。關于共享對象原則很簡單誰創(chuàng)建誰釋放。通過syscon API拿到的regmap生命周期由syscon框架統(tǒng)一管理子驅動只需使用即可。6.4 probe失敗排查清單最后整理一份排查清單純經(jīng)驗總結按出現(xiàn)頻率排序現(xiàn)象常見原因定位手段syscon_regmap_lookup_by_phandle返回-EINVAL設備樹節(jié)點compatible順序不對或屬性沒寫檢查/proc/device-tree下對應節(jié)點的compatible屬性返回-EPROBE_DEFERsyscon節(jié)點尚未完成注冊確認節(jié)點沒有被status disabled禁用regmap_read返回-EIO寄存器地址超過max_register查看debugfs regmap目錄下的range讀到的值一直不變緩存未失效檢查volatile_reg配置用devmem交叉驗證中斷一直不觸發(fā)irq domain尚未注冊查看/proc/interrupts確認子驅動中斷號是否映射成功probe反復重入父設備和子設備probe順序沖突確認返回了-EPROBE_DEFER而不是-ENXIO做MFD syscon開發(fā)最大的經(jīng)驗其實就一句話不要試圖繞過框架自己管理底層寄存器。MFD已經(jīng)把芯片拆分的骨架搭好了syscon把寄存器訪問的內(nèi)存管理做透了我們要做的只是把業(yè)務邏輯裝進合適的殼里。真正難搞的問題往往不是代碼寫不出來而是沒有理解框架為什么這樣設計。只要能想明白誰創(chuàng)建、誰使用、誰釋放這三個問題整個驅動架構就會清晰很多。