1. 移植驅(qū)動(dòng)前先搞清楚中斷子系統(tǒng)到底在幫你做什么做驅(qū)動(dòng)移植最怕拿到一份源碼就開(kāi)干改改寄存器地址、換換時(shí)鐘頻率結(jié)果中斷死活不觸發(fā)或者一觸發(fā)就死機(jī)。我見(jiàn)過(guò)太多人卡在中斷上本質(zhì)問(wèn)題不是代碼寫錯(cuò)了而是對(duì)整個(gè)中斷子系統(tǒng)缺少一張地圖——不知道中斷從硬件引腳到CPU執(zhí)行回調(diào)函數(shù)中間到底經(jīng)過(guò)了哪些環(huán)節(jié)、每一層由誰(shuí)負(fù)責(zé)、移植時(shí)哪些東西必須跟著SoC變化、哪些東西是內(nèi)核幫你擋掉的。先說(shuō)個(gè)場(chǎng)景。你在A平臺(tái)的開(kāi)發(fā)板上跑得好好的驅(qū)動(dòng)換到B平臺(tái)系統(tǒng)起來(lái)后cat /proc/interrupts看不到你的中斷號(hào)或者能看到號(hào)但計(jì)數(shù)永遠(yuǎn)不漲又或者中斷風(fēng)暴直接把CPU打滿。這時(shí)候如果你腦子里沒(méi)有中斷子系統(tǒng)的整體框架排查起來(lái)就是瞎貓碰死耗子一會(huì)懷疑設(shè)備樹(shù)寫錯(cuò)了一會(huì)懷疑寄存器配置不對(duì)一會(huì)又懷疑是內(nèi)核版本差異。而實(shí)際上問(wèn)題可能只是中斷控制器Interrupt Controller的映射關(guān)系沒(méi)對(duì)上或者中斷類型電平觸發(fā)、邊沿觸發(fā)在硬件上根本配不出來(lái)。所以這篇我打算把Linux中斷子系統(tǒng)的整體框架掰開(kāi)揉碎講一遍并且站在“驅(qū)動(dòng)移植”的視角——重點(diǎn)不是你從頭寫一個(gè)中斷子系統(tǒng)而是當(dāng)你把驅(qū)動(dòng)從一個(gè)平臺(tái)搬到另一個(gè)平臺(tái)時(shí)哪些環(huán)節(jié)最容易出問(wèn)題、為什么出問(wèn)題、該怎么定位?？蚣芨忝靼琢艘浦策^(guò)程中的九成中斷問(wèn)題你都能自己判斷個(gè)大概。先給一張總覽圖后面逐個(gè)環(huán)節(jié)拆硬件中斷源外設(shè)→ 中斷控制器GIC等→ CPU的IRQ引腳內(nèi)核側(cè)irq domain負(fù)責(zé)把硬件中斷號(hào)翻譯成Linux內(nèi)部中斷號(hào)virqirq_desc每個(gè)virq對(duì)應(yīng)一個(gè)描述符存放回調(diào)函數(shù)、標(biāo)志位、線程化信息中斷流控層handle_irq系列處理不同觸發(fā)類型的中斷流驅(qū)動(dòng)回調(diào)request_irq/devm_request_irq注冊(cè)的handler最終被執(zhí)行通俗點(diǎn)說(shuō)中斷子系統(tǒng)就是一套“硬件中斷事件 → 內(nèi)核事件分發(fā) → 驅(qū)動(dòng)處理函數(shù)”的管道系統(tǒng)。移植驅(qū)動(dòng)的過(guò)程就是讓這套管道在你新的硬件平臺(tái)上重新暢通。2. 硬件中斷號(hào)怎么變成Linux的irq號(hào)從GIC到virq的映射邏輯2.1 GIC是絕大多數(shù)SoC中斷的起點(diǎn)無(wú)論是高通、海思、瑞芯微還是全志主流ARM SoC的中斷控制器基本都走ARM GICGeneric Interrupt Controller架構(gòu)。GIC的版本從GIC-400、GIC-500到GIC-600系列差異主要在支持的CPU核數(shù)、中斷數(shù)、親和性配置上但基本概念一致。GIC把中斷分為三類SGISoftware Generated Interrupt軟件觸發(fā)的中斷用于核間通信0~15號(hào)。PPIPrivate Peripheral Interrupt私有外設(shè)中斷每個(gè)CPU核獨(dú)享比如每個(gè)核的local timer16~31號(hào)。SPIShared Peripheral Interrupt共享外設(shè)中斷所有核都能收到32號(hào)往上一般到幾百號(hào)。在設(shè)備樹(shù)里你經(jīng)?？吹筋愃七@樣的節(jié)點(diǎn)uart0: serialff580000 { compatible rockchip,rk3399-uart; reg 0x0 0xff580000 0x0 0x100; interrupts GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH; };這里的GIC_SPI 115就是指SPI中斷硬件中斷號(hào)是115。注意這個(gè)115是GIC視角的硬件編號(hào)不是Linux內(nèi)部使用的irq號(hào)。從GIC的115到Linux的irq號(hào)中間隔著一個(gè)關(guān)鍵的數(shù)據(jù)結(jié)構(gòu)——irq domain。2.2 irq domain就是一張翻譯表在老版本內(nèi)核里硬件中斷號(hào)和Linux irq號(hào)經(jīng)常是線性對(duì)應(yīng)的irq 32 hw_irq之類的簡(jiǎn)單公式就能算出來(lái)。但后來(lái)中斷控制器層級(jí)變多、需要?jiǎng)討B(tài)分配內(nèi)核引入了irq domain機(jī)制。每一個(gè)中斷控制器注冊(cè)一個(gè)irq_domain通過(guò)irq_domain_ops里的map和translate回調(diào)實(shí)現(xiàn)硬件中斷號(hào)到virq的轉(zhuǎn)換。驅(qū)動(dòng)移植中最常見(jiàn)的一個(gè)問(wèn)題就是你板子上的外設(shè)中斷在設(shè)備樹(shù)里寫的硬件號(hào)是GIC視角的號(hào)而內(nèi)核跑起來(lái)之后你cat /proc/interrupts看到的號(hào)是virq。這兩者往往不一致。比如某外設(shè)硬件中斷號(hào)是211在/proc/interrupts里卻顯示為86這都是正常的由irq domain和分配順序決定。以經(jīng)典GIC驅(qū)動(dòng)為例注冊(cè)的irq_domain大概是這個(gè)流程gic_init_bases(...) - irq_domain_add_linear(gic-base, gic-irq_nr, gic_irq_domain_ops, gic)irq_domain_add_linear創(chuàng)建線性映射域gic_irq_domain_ops里核心是兩個(gè)回調(diào)gic_irq_domain_map把GIC硬件中斷號(hào)映射成irq_desc并設(shè)置irq_chipgic_irq_domain_translate解析設(shè)備樹(shù)interrupts屬性里的GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH三元組移植驅(qū)動(dòng)時(shí)你要清楚一件事設(shè)備樹(shù)里你寫的中斷號(hào)是給GIC翻譯用的翻譯完之后的virq才是驅(qū)動(dòng)里真正注冊(cè)使用的號(hào)。你在驅(qū)動(dòng)代碼里寫irq platform_get_irq(pdev, 0)拿到的是這個(gè)virq。2.3 移植中最常見(jiàn)的三類映射錯(cuò)誤第一類設(shè)備樹(shù)中斷號(hào)寫錯(cuò)。比如芯片手冊(cè)里說(shuō)某個(gè)外設(shè)中斷是SPI 118結(jié)果你寫成118后驅(qū)動(dòng)始終不觸發(fā)查手冊(cè)發(fā)現(xiàn)在另一個(gè)中斷控制器域下或者實(shí)際要減去偏移。尤其當(dāng)SoC內(nèi)部有多個(gè)中斷控制器級(jí)聯(lián)時(shí)設(shè)備樹(shù)里寫的號(hào)必須參照該控制器域的定義。第二類interrupt-parent指錯(cuò)。多控制器SoC上外設(shè)節(jié)點(diǎn)要用interrupt-parent指定掛在哪個(gè)中斷控制器下。如果漏寫或者指到錯(cuò)誤的父節(jié)點(diǎn)內(nèi)核會(huì)用默認(rèn)域的翻譯方式去解析出來(lái)的號(hào)可能對(duì)不上硬件實(shí)際接的那條線。第三類觸發(fā)類型不匹配。設(shè)備樹(shù)里寫IRQ_TYPE_LEVEL_HIGH但硬件外設(shè)的實(shí)際中斷輸出是低電平有效、需要IRQ_TYPE_LEVEL_LOW。這種問(wèn)題在/proc/interrupts里能看到中斷號(hào)但計(jì)數(shù)不漲因?yàn)殡娖揭恢睕](méi)被拉低中斷控制器采樣不到有效信號(hào)。3. 驅(qū)動(dòng)側(cè)的中斷注冊(cè)流程從request_irq到回調(diào)執(zhí)行的完整鏈路3.1 platform_get_irq與request_irq之間的微妙關(guān)系寫驅(qū)動(dòng)時(shí)標(biāo)準(zhǔn)流程一般是static int foo_probe(struct platform_device *pdev) { int irq; irq platform_get_irq(pdev, 0); if (irq 0) return irq; ret devm_request_threaded_irq(pdev-dev, irq, foo_irq_handler, foo_irq_thread_fn, IRQF_TRIGGER_HIGH, foo, dev); return ret; }很多人不清楚platform_get_irq到底做了什么。函數(shù)內(nèi)部經(jīng)歷大致是解析設(shè)備樹(shù)節(jié)點(diǎn) → 走of_irq_get→ 找到interrupt-parent對(duì)應(yīng)的irq domain→ 調(diào)用irq_create_of_mapping把硬件中斷號(hào)翻譯成virq→ 返回。注意platform_get_irq拿到virq后中斷還沒(méi)有真正被請(qǐng)求。驅(qū)動(dòng)此時(shí)只是拿到了一個(gè)“令牌”真正把我們的處理函數(shù)掛到中斷管道上是后續(xù)的request_irq或devm_request_irq完成的。移植時(shí)經(jīng)常遇到的情況probe里platform_get_irq返回-ENXIO也就是拿不到中斷號(hào)。排查思路按順序來(lái)設(shè)備樹(shù)節(jié)點(diǎn)是否存在interrupts屬性。設(shè)備樹(shù)節(jié)點(diǎn)是否設(shè)置了正確的interrupt-parent。對(duì)應(yīng)中斷控制器的驅(qū)動(dòng)是否已經(jīng)初始化完成probe順序問(wèn)題經(jīng)常被人忽略。of_irq_get解析時(shí)是否因?yàn)橛|發(fā)類型字段非法而失敗。3.2 top half和bottom half為什么你的回調(diào)不能干重活Linux中斷處理函數(shù)跑在中斷上下文它有幾個(gè)硬性約束不能睡眠、不能調(diào)用可能睡眠的APImutex_lock、kmalloc帶GFP_KERNEL都不行、不能做太耗時(shí)的操作。因?yàn)橹袛嗌舷挛睦顲PU不參與調(diào)度你在里面轉(zhuǎn)5毫秒整個(gè)系統(tǒng)就卡5毫秒。于是有了bottom half機(jī)制。傳統(tǒng)做法是tasklet現(xiàn)在更推薦用threaded irq也就是上面代碼里的devm_request_threaded_irq。這種模式下中斷觸發(fā)時(shí)先跑handler如果handler返回IRQ_WAKE_THREAD內(nèi)核會(huì)喚醒一個(gè)內(nèi)核線程去執(zhí)行thread_fn而thread_fn運(yùn)行在普通進(jìn)程上下文可以睡眠、可以加鎖、可以調(diào)用各種胖接口。移植驅(qū)動(dòng)的經(jīng)驗(yàn)之談如果外設(shè)中斷處理里要操作i2c或者spi總線讀取狀態(tài)寄存器就強(qiáng)烈建議用threaded irq。因?yàn)閕2c控制器本身也是中斷驅(qū)動(dòng)的中斷上下文里再去等它的中斷完成很容易死鎖而在線程化上下文里i2c傳輸可以正常睡眠等待。3.3 中斷標(biāo)志位IRQF_TRIGGER_*與設(shè)備樹(shù)觸發(fā)類型是一致的嗎request_irq里第四個(gè)參數(shù)IRQF_TRIGGER_HIGH/LOW/RISING/FALLING指定觸發(fā)類型。在設(shè)備樹(shù)已經(jīng)寫了觸發(fā)類型的前提下驅(qū)動(dòng)里再指定一次兩者到底聽(tīng)誰(shuí)的這里有坑。GIC這類現(xiàn)代中斷控制器設(shè)備樹(shù)里的觸發(fā)類型最終會(huì)下發(fā)到硬件層GIC配置對(duì)應(yīng)中斷的觸發(fā)方式和優(yōu)先級(jí)。驅(qū)動(dòng)里request_irq的IRQF_TRIGGER_*是Linux中斷子系統(tǒng)的軟件標(biāo)志但如果底層irq_chip已經(jīng)根據(jù)設(shè)備樹(shù)完成了硬件配置驅(qū)動(dòng)里的標(biāo)志可能被忽略或覆蓋不同內(nèi)核版本行為不一樣。我的建議設(shè)備樹(shù)里明確寫觸發(fā)類型驅(qū)動(dòng)里request_irq直接傳0或IRQF_TRIGGER_NONE不要讓兩個(gè)地方出現(xiàn)沖突。尤其移植時(shí)原始平臺(tái)設(shè)備樹(shù)寫的是IRQ_TYPE_EDGE_RISING新平臺(tái)換成IRQ_TYPE_LEVEL_HIGH而驅(qū)動(dòng)代碼里還保留老標(biāo)志這就會(huì)埋雷。4. 中斷控制器驅(qū)動(dòng)與irq_chip移植時(shí)真正要?jiǎng)拥兜牡胤?.1 irq_chip是中斷控制器在內(nèi)核里的抽象irq_chip封裝了中斷控制器的硬件操作包括irq_mask/irq_unmask屏蔽/使能某個(gè)中斷源irq_ack中斷應(yīng)答irq_set_type設(shè)置觸發(fā)類型irq_set_wake使能喚醒irq_set_affinity設(shè)置CPU親和性每個(gè)irq_desc里掛著一個(gè)irq_chip指針驅(qū)動(dòng)調(diào)用enable_irq、disable_irq、irq_set_irq_type時(shí)最終都會(huì)落到對(duì)應(yīng)irq_chip的回調(diào)上。在GIC驅(qū)動(dòng)的實(shí)現(xiàn)里gic_handle_irq是最核心的函數(shù)它做的事是讀GICC_IAR寄存器拿到硬件中斷號(hào) → 如果小于16SGI做核間處理如果是PPI/SPI調(diào)用generic_handle_irq分發(fā)到對(duì)應(yīng)virq的處理流程。移植驅(qū)動(dòng)到新平臺(tái)時(shí)如果新平臺(tái)的中斷控制器不是標(biāo)準(zhǔn)GIC比如有些國(guó)產(chǎn)SoC用了私有中斷控制器或者經(jīng)過(guò)了一層自定義的級(jí)聯(lián)封裝你就需要看這個(gè)芯片廠商是否提供了對(duì)應(yīng)的irq_chip實(shí)現(xiàn)。如果廠商沒(méi)提供驅(qū)動(dòng)里任何中斷都無(wú)法正常工作因?yàn)閕rq_set_type、irq_mask這些操作都沒(méi)有落點(diǎn)。4.2 irq domain層級(jí)級(jí)聯(lián)時(shí)怎么排查有些SoC內(nèi)部不止一個(gè)中斷控制器。典型例子主GIC外掛一個(gè)GPIO控制器而GPIO控制器本身又作為中斷控制器把多路GPIO中斷匯聚成一路SPI中斷送往GIC。這種層級(jí)關(guān)系在設(shè)備樹(shù)里表現(xiàn)為gpio2: gpioff790000 { compatible rockchip,gpio-bank; reg 0x0 0xff790000 0x0 0x100; interrupt-controller; #interrupt-cells 2; interrupts GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH; };此時(shí)一個(gè)外設(shè)掛了gpio2的第5號(hào)引腳作為中斷源foo_device { interrupt-parent gpio2; interrupts 5 IRQ_TYPE_EDGE_RISING; };of_irq_get解析時(shí)就會(huì)先走到gpio2的irq domain把5翻譯成gpio2域的virq與此同時(shí)gpio2本身作為中斷源又掛在GIC的116號(hào)上形成一個(gè)鏈外設(shè)中斷 → GPIO控制器 → GIC → CPU。移植時(shí)這種層級(jí)最容易出問(wèn)題。常見(jiàn)的坑interrupt-controller和#interrupt-cells屬性遺漏導(dǎo)致外設(shè)節(jié)點(diǎn)無(wú)法解析。GPIO控制器里某個(gè)引腳的中斷和別的外設(shè)沖突/proc/interrupts里能看到gpio底下所有中斷事件歸屬同一個(gè)virq計(jì)數(shù)。層次多了之后觸發(fā)類型可能被某一層的irq_chip改變。比如外設(shè)和GPIO控制器申請(qǐng)的是邊沿觸發(fā)但GPIO控制器匯入GIC時(shí)如果只支持電平觸發(fā)內(nèi)核會(huì)自動(dòng)做一次轉(zhuǎn)換嗎不會(huì)。所以你必須保證每層中斷控制器的觸發(fā)類型配置都合理否則邊緣觸發(fā)的外設(shè)在GIC層采樣不到。排查這種層級(jí)問(wèn)題時(shí)我一般會(huì)在設(shè)備樹(shù)里臨時(shí)加interrupts-extended來(lái)跳過(guò)中間層直接指定上層控制器快速確認(rèn)問(wèn)題是出在中間層還是最終層。4.3 percpu中斷和共享中斷在移植中的區(qū)別處理中斷還有一種分類方式是否per-CPU的以及是否可共享。PPI中斷比如每核的local timer就是per-CPU的。設(shè)備樹(shù)里你會(huì)看到類似arch_timer { interrupts GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_LOW); };注意這里中斷號(hào)是GIC_PPI 13而且多了一個(gè)GIC_CPU_MASK_SIMPLE(4)來(lái)指定中斷發(fā)給哪些CPU核。移植這種設(shè)備時(shí)如果有人把PPI當(dāng)成SPI去注冊(cè)或者request_percpu_irq和request_irq用混了就亂了。PPI必須用request_percpu_irq配合enable_percpu_irq處理函數(shù)里訪問(wèn)per-CPU變量也有一套固定寫法。而共享中斷IRQF_SHARED是多個(gè)設(shè)備共用一個(gè)中斷號(hào)。這類中斷在request_irq時(shí)必須傳入設(shè)備ID指針內(nèi)核觸發(fā)時(shí)會(huì)逐個(gè)調(diào)用注冊(cè)在同一virq上的handler直到某個(gè)handler返回IRQ_HANDLED。移植時(shí)如果驅(qū)動(dòng)里沒(méi)用IRQF_SHARED卻在設(shè)備樹(shù)里和別的設(shè)備共用了中斷號(hào)request_irq會(huì)直接失敗返回-EBUSY。5. 從硬件觸發(fā)到回調(diào)執(zhí)行的瞬間中斷流控層與desc處理流程5.1 handle_irq系列函數(shù)到底做了什么中斷流控層是不少人忽略的環(huán)節(jié)。在generic_handle_irq被調(diào)用后內(nèi)核會(huì)根據(jù)中斷的觸發(fā)類型和是否喚醒等屬性調(diào)用不同的流控函數(shù)。最?？吹降挠衕andle_level_irq電平觸發(fā)中斷走這個(gè)handle_edge_irq邊沿觸發(fā)中斷走這個(gè)handle_fasteoi_irqGIC這種支持EOIEnd of Interrupt的控制器走這個(gè)handle_simple_irq某些不做硬件屏蔽的控制器用這些函數(shù)的職責(zé)是管理中斷的屏蔽/使能狀態(tài)、處理中斷嵌套和pending狀態(tài)、調(diào)用irq_desc里注冊(cè)的action鏈也就是驅(qū)動(dòng)注冊(cè)的handler。移植時(shí)你不需要改這些流控函數(shù)但你必須理解它們的差異。最常見(jiàn)的現(xiàn)象電平觸發(fā)的中斷如果handler里沒(méi)做irq_ack或者中斷源沒(méi)有被真正清掉handle_level_irq會(huì)在handler返回后立刻再次觸發(fā)導(dǎo)致中斷風(fēng)暴。邊沿觸發(fā)的中斷則容易丟中斷如果中斷觸發(fā)時(shí)irq_desc正被屏蔽邊沿信號(hào)不會(huì)像電平信號(hào)那樣被鎖存恢復(fù)使能后可能就丟了。5.2 實(shí)測(cè)中最容易翻車的場(chǎng)景中斷風(fēng)暴與丟失中斷我實(shí)際移植一個(gè)網(wǎng)卡驅(qū)動(dòng)時(shí)遇到過(guò)這么一件事設(shè)備樹(shù)里寫的中斷觸發(fā)類型是IRQ_TYPE_LEVEL_HIGH但實(shí)際上網(wǎng)卡芯片的中斷輸出引腳在空閑時(shí)本來(lái)就是高電平只有產(chǎn)生中斷時(shí)才短暫拉低。結(jié)果驅(qū)動(dòng)一旦enable_irqGIC采樣到高電平就一直認(rèn)為有中斷中斷風(fēng)暴瞬間打滿CPU。當(dāng)時(shí)的排查過(guò)程很有代表性/proc/interrupts里該中斷的計(jì)數(shù)在瘋狂暴漲CPU0的si時(shí)間百分比飆到90%以上但驅(qū)動(dòng)里的handler卻進(jìn)得很少——因?yàn)轱L(fēng)暴中斷全被流控層攔截處理了。后來(lái)把設(shè)備樹(shù)里的觸發(fā)類型改成IRQ_TYPE_LEVEL_LOW一次問(wèn)題就沒(méi)了。另一個(gè)方向是丟中斷。用邊沿觸發(fā)時(shí)外設(shè)產(chǎn)生中斷的脈沖非常窄如果在GIC采樣到之前信號(hào)就消失了這個(gè)中斷就丟了。這類問(wèn)題在低速總線的外設(shè)上尤其明顯——外設(shè)快、主機(jī)慢兩個(gè)時(shí)鐘域之間的脈沖寬度不足。排查手段是在驅(qū)動(dòng)里做一次“虛假中斷檢測(cè)”handler里讀外設(shè)中斷狀態(tài)寄存器如果發(fā)現(xiàn)沒(méi)有對(duì)應(yīng)中斷標(biāo)志就返回IRQ_NONE讓內(nèi)核把該virq標(biāo)記為可疑中斷/proc/interrupts旁邊會(huì)出現(xiàn)[NMI]之類的錯(cuò)誤提示。5.3 irq_desc里的action鏈表多個(gè)handler怎么排隊(duì)一個(gè)virq可以掛多個(gè)action這正是共享中斷的實(shí)現(xiàn)基礎(chǔ)。request_irq時(shí)傳入的dev_id就是用來(lái)區(qū)分不同action的。當(dāng)handle_*_irq運(yùn)行時(shí)會(huì)遍歷irq_desc的action鏈表逐個(gè)調(diào)用handler直到有一個(gè)返回IRQ_HANDLED。這里有個(gè)性能考慮共享中斷鏈越長(zhǎng)每個(gè)中斷觸發(fā)需要遍歷的handler就越多。所以移植時(shí)如果發(fā)現(xiàn)某個(gè)中斷號(hào)和多個(gè)設(shè)備共享性能敏感的場(chǎng)景下最好在硬件層面錯(cuò)開(kāi)中斷源或者確認(rèn)每個(gè)handler開(kāi)頭都能快速判斷“這個(gè)中斷是不是我的”。6. 設(shè)備樹(shù)里中斷相關(guān)的關(guān)鍵屬性移植時(shí)逐項(xiàng)核對(duì)清單6.1 interrupt-parent、interrupts、interrupt-names的配合設(shè)備樹(shù)中斷屬性三板斧是interrupt-parent指定中斷控制器父節(jié)點(diǎn)告訴內(nèi)核該設(shè)備的某個(gè)引腳接到哪個(gè)中斷控制器的哪個(gè)輸入上。interrupts一般是中斷類型 中斷號(hào) 觸發(fā)類型或中斷號(hào) 觸發(fā)類型取決于父控制器的#interrupt-cells。interrupt-names給每個(gè)中斷起個(gè)名字配合platform_get_irq_byname使用。多中斷設(shè)備很常見(jiàn)比如一個(gè)觸摸屏控制器有觸摸中斷和喚醒中斷兩個(gè)引腳touch38 { interrupt-parent gpio1; interrupts 5 IRQ_TYPE_EDGE_FALLING, 6 IRQ_TYPE_EDGE_FALLING; interrupt-names touch, wakeup; };驅(qū)動(dòng)里用platform_get_irq_byname(pdev, touch)去拿對(duì)應(yīng)中斷號(hào)。移植時(shí)改名會(huì)導(dǎo)致platform_get_irq_byname返回-EINVAL而很多人排查時(shí)老是檢查interrupts卻忘了interrupt-names對(duì)應(yīng)不上。6.2 中斷控制器節(jié)點(diǎn)的關(guān)鍵屬性中斷控制器節(jié)點(diǎn)自身也有幾個(gè)屬性決定它如何被內(nèi)核識(shí)別interrupt-controller空屬性聲明該節(jié)點(diǎn)是一個(gè)中斷控制器。#interrupt-cells聲明子節(jié)點(diǎn)里interrupts需要幾個(gè)單元格來(lái)描述。GIC是3個(gè)類型、號(hào)、觸發(fā)方式GPIO控制器是2個(gè)引腳號(hào)、觸發(fā)方式。interrupts聲明這個(gè)中斷控制器本身接到上級(jí)控制器的哪個(gè)中斷上級(jí)聯(lián)時(shí)才有。interrupt-parent指向更上一級(jí)的控制器。移植新板子時(shí)如果外設(shè)中斷完全不可用我一般會(huì)先檢查控制器節(jié)點(diǎn)這4個(gè)屬性是否齊全。這里有個(gè)隱蔽的問(wèn)題部分SoC的設(shè)備樹(shù)里GPIO節(jié)點(diǎn)的interrupt-controller屬性會(huì)被注釋掉或者缺失因?yàn)镚PIO IP在芯片內(nèi)部不是傳統(tǒng)意義上的“中斷控制器”但驅(qū)動(dòng)里如果某個(gè)外設(shè)把它當(dāng)父控制器用解析就失敗。6.3 中斷映射失敗時(shí)內(nèi)核日志怎么看設(shè)備樹(shù)解析中斷失敗時(shí)串口日志里一般能看到類似could not get irq或failed to get interrupt resource的信息。但更早的解析錯(cuò)誤提示很模糊。定位手段一個(gè)是打開(kāi)動(dòng)態(tài)調(diào)試echo 1 /sys/kernel/debug/tracing/tracing_on echo irq:* /sys/kernel/debug/tracing/set_event另一個(gè)更直接的辦法是查/sys/kernel/debug/irq/irqs/下的每個(gè)irq_desc信息確認(rèn)設(shè)備樹(shù)映射后virq對(duì)應(yīng)的irq_chip是不是你預(yù)期的那顆控制器cat /sys/kernel/debug/irq/irqs/86如果irq_chip顯示的是gic而設(shè)備樹(shù)里你接的是gpio2的域說(shuō)明級(jí)聯(lián)映射沒(méi)有生效問(wèn)題基本出在interrupt-parent。7. 中斷號(hào)查詢與映射調(diào)試把/proc/interrupts讀成診斷書7.1 /proc/interrupts每一列怎么讀驅(qū)動(dòng)移植調(diào)中斷/proc/interrupts是第一現(xiàn)場(chǎng)。它的基本格式CPU0 CPU1 16: 1234 0 GICv3 49 Level arch_timer 86: 56789 321 gpio 20 Edge fdd40000.ethernet第一列是virq號(hào)后面每列是一個(gè)CPU核上該中斷觸發(fā)的次數(shù)然后是中斷控制器名稱和硬件內(nèi)部分組接著是硬件中斷號(hào)、觸發(fā)類型最后是request_irq時(shí)注冊(cè)的設(shè)備名。判斷標(biāo)準(zhǔn)計(jì)數(shù)一直為0中斷根本沒(méi)到控制器或沒(méi)被使能。計(jì)數(shù)暴漲觸發(fā)類型或清中斷邏輯有問(wèn)題。多個(gè)中斷源的計(jì)數(shù)都?xì)w到一個(gè)virq下共享中斷需要靠寄存器判斷是哪路外設(shè)。計(jì)數(shù)在兩個(gè)CPU核間來(lái)回跳動(dòng)說(shuō)明中斷被設(shè)置了親和性或GIC做了負(fù)載均衡正?，F(xiàn)象。7.2 驅(qū)動(dòng)注冊(cè)成功但中斷不觸發(fā)時(shí)的排查順序如果/proc/interrupts里能看到你的virq、設(shè)備名也對(duì)但計(jì)數(shù)一直0我一般按這個(gè)順序排查確認(rèn)外設(shè)確實(shí)產(chǎn)生了中斷信號(hào)。用示波器或者直接在驅(qū)動(dòng)里臨時(shí)寫一個(gè)測(cè)試IO觸發(fā)外設(shè)發(fā)送中斷后再讀外設(shè)的中斷狀態(tài)寄存器確認(rèn)硬件層面中斷標(biāo)志有沒(méi)有置起來(lái)。檢查中斷控制器的屏蔽狀態(tài)。/sys/kernel/debug/irq/irqs/86里能看到irq_data的state確認(rèn)IRQ_MASKED標(biāo)志是否置位。檢查觸發(fā)類型。/proc/interrupts里顯示的觸發(fā)類型是否和硬件實(shí)際信號(hào)匹配。檢查時(shí)鐘。沒(méi)有外設(shè)時(shí)鐘外設(shè)根本不會(huì)工作更不會(huì)產(chǎn)生中斷。這個(gè)聽(tīng)著很傻但確實(shí)在移植中踩過(guò)好多次。我的一個(gè)具體案例某傳感器中斷一直不觸發(fā)排查到最后發(fā)現(xiàn)設(shè)備樹(shù)里給它配的時(shí)鐘源沒(méi)有通過(guò)clk_prepare_enable打開(kāi)傳感器壓根沒(méi)跑起來(lái)自然不會(huì)有中斷。7.3 線程化中斷在/proc/interrupts里的表現(xiàn)線程化中斷在/proc/interrupts里會(huì)看到一個(gè)配套的內(nèi)核線程名字一般是irq/86-fdd40000.ethernet之類的。中斷觸發(fā)時(shí)handler只做快速處理真正的業(yè)務(wù)邏輯在irq/86-xxx線程里執(zhí)行。調(diào)這類問(wèn)題時(shí)除了看/proc/interrupts的計(jì)數(shù)變化還要看線程的調(diào)度狀態(tài)ps -eo pid,comm,state | grep irq/如果線程處于D狀態(tài)不可中斷睡眠長(zhǎng)期不返回多半是thread_fn里阻塞在了某個(gè)等待隊(duì)列或鎖上。這在移植時(shí)很常見(jiàn)因?yàn)樵计脚_(tái)的外設(shè)寄存器延遲和時(shí)序和新平臺(tái)不同原本毫秒級(jí)的等待變成幾十毫秒或者直接超時(shí)了。8. 移植后的中斷驗(yàn)證與踩坑復(fù)盤8.1 冒煙測(cè)試中斷鏈路的壓測(cè)腳本思路移植完之后我一般會(huì)做一個(gè)簡(jiǎn)單的冒煙驗(yàn)證不是只觸發(fā)一次中斷看看handler進(jìn)沒(méi)進(jìn)而是壓一輪高頻中斷# 模擬高頻中斷事件例如用perf觸發(fā)大量定時(shí)器中斷或者IRQ stress-ng --timer 32 --timeout 30 cat /proc/interrupts觀察幾個(gè)點(diǎn)中斷計(jì)數(shù)和中斷源觸發(fā)次數(shù)是否線性匹配允許少量合理丟失但不能差一個(gè)數(shù)量級(jí)。CPU的si軟中斷和hi硬中斷占比是否正常正常情況下不應(yīng)持續(xù)高位。驅(qū)動(dòng)handler是否出現(xiàn)超時(shí)報(bào)錯(cuò)內(nèi)核日志里有沒(méi)有IRQ handler type mismatch或nobody cared這類字樣。cat /proc/interrupts時(shí)如果發(fā)現(xiàn)某中斷觸發(fā)了可觀的次數(shù)但handler沒(méi)有任何反應(yīng)優(yōu)先懷疑IRQF_TRIGGER_*配置。如果使用threaded irq建議也在壓測(cè)期間觀察ps里對(duì)應(yīng)的irq/xxx線程的CPU占用率正常情況下它應(yīng)該能跟上中斷頻率。如果線程CPU占滿而實(shí)際業(yè)務(wù)沒(méi)完成說(shuō)明thread_fn里存在忙等或者頻繁輪詢的問(wèn)題移植時(shí)尤其要注意。8.2 兩種移植場(chǎng)景的處理差異原樣替換和跨內(nèi)核版本移植中斷相關(guān)代碼時(shí)有兩種典型場(chǎng)景一是原廠BSP提供了完整的內(nèi)核和驅(qū)動(dòng)你只是把某個(gè)外設(shè)驅(qū)動(dòng)移到自己的板卡上。這種情況基礎(chǔ)設(shè)施多半是好的重點(diǎn)檢查設(shè)備樹(shù)、時(shí)鐘、IO復(fù)用和中斷引腳。中斷相關(guān)代碼需要?jiǎng)拥目赡苄圆淮蟪荢oC中斷控制器本身變了。二是跨內(nèi)核版本移植比如把4.19的驅(qū)動(dòng)往6.1內(nèi)核上搬。這時(shí)中斷子系統(tǒng)API變化比較明顯最典型的是of_irq_get和platform_get_irq的返回值語(yǔ)義在老內(nèi)核里可能是0表示成功新內(nèi)核里0表示無(wú)效且失敗返回值是負(fù)數(shù)。如果你用老驅(qū)動(dòng)的判斷邏輯在新內(nèi)核上會(huì)誤判。devm_request_threaded_irq的引入時(shí)間、request_percpu_irq的語(yǔ)義變化。老內(nèi)核里handle_irq的入口行為和新內(nèi)核不同部分自定義irq_chip在舊平臺(tái)還能工作新平臺(tái)因?yàn)槿鄙賗rq_set_affinity或者irq_set_wake的調(diào)用上下文直接報(bào)錯(cuò)。這類場(chǎng)景下建議先把老驅(qū)動(dòng)的中斷請(qǐng)求段完整分析一遍確認(rèn)每一處API在當(dāng)前內(nèi)核版本下的行為再動(dòng)手改設(shè)備樹(shù)。8.3 我總結(jié)的七條中斷移植注意事項(xiàng)這幾條不是教科書上的原話是踩了不少坑之后我自己定的檢查順序先確認(rèn)硬件電氣連接再談軟件配置。GPIO復(fù)用的pinmux沒(méi)配好中斷引腳根本到不了控制器。設(shè)備樹(shù)里interrupt-parent一定顯式寫別依賴默認(rèn)值不同內(nèi)核版本的默認(rèn)解析邏輯很不一樣。觸發(fā)類型雙層核對(duì)設(shè)備樹(shù)寫一次request_irq里保持一致不要copy老代碼時(shí)帶上舊平臺(tái)的標(biāo)志。中斷處理函數(shù)里不要做總線操作除非你用threaded irq或者確認(rèn)總線控制器支持中斷上下文使用。移植后先跑高頻中斷壓力測(cè)試別只測(cè)一次觸發(fā)。中斷丟失和死鎖往往在高頻下才現(xiàn)原形。/sys/kernel/debug/irq/和/proc/interrupts配合使用一個(gè)看靜態(tài)配置一個(gè)看動(dòng)態(tài)計(jì)數(shù)。千萬(wàn)別在中斷handler里加調(diào)試打印尤其串口打印。串口本身也是中斷驅(qū)動(dòng)的中斷上下文里打串口很容易把系統(tǒng)鎖死要打印就記錄標(biāo)志位thread_fn里統(tǒng)一處理。9. 最后再補(bǔ)一個(gè)定位中斷問(wèn)題的野路子很多中斷問(wèn)題表面上是“驅(qū)動(dòng)注冊(cè)失敗”或者“中斷計(jì)數(shù)不對(duì)”實(shí)際根源在別的驅(qū)動(dòng)或者系統(tǒng)初始化順序上。比如之前遇到一次某個(gè)外設(shè)的probe成功、中斷注冊(cè)也成功但一使能外部中斷整機(jī)就重啟。查到最后發(fā)現(xiàn)是另一個(gè)驅(qū)動(dòng)把GIC的某種電源域關(guān)了導(dǎo)致GIC在處理該中斷時(shí)訪問(wèn)了未上電的寄存器直接觸發(fā)總線錯(cuò)誤。所以移植驅(qū)動(dòng)時(shí)如果中斷問(wèn)題怎么都查不通不妨回頭看看這幾件事該外設(shè)的電源域和reset GPIO在目標(biāo)平臺(tái)上的配置是否和原平臺(tái)一致。內(nèi)核里CONFIG_ARM_GIC_V3這類中斷控制器配置項(xiàng)是否和實(shí)際SoC匹配。配置不對(duì)的話中斷控制器可能只初始化了一部分。啟動(dòng)日志里GIC相關(guān)的初始化信息確認(rèn)它識(shí)別的中斷范圍是否覆蓋了你外設(shè)使用的硬件中斷號(hào)。中斷子系統(tǒng)是一個(gè)典型的“一榮俱榮、一損俱損”的鏈條。驅(qū)動(dòng)側(cè)代碼再正確只要中間任何一環(huán)沒(méi)對(duì)齊——硬件連接、設(shè)備樹(shù)解析、控制器配置、流控機(jī)制——整個(gè)鏈條就斷了。把這套框架裝進(jìn)腦子里移植時(shí)按圖索驥比盲目改代碼高效得多。