點擊打開鏈接

最近在工作中使用irq時遇到如下問題，根據log顯示應該是什么所謂的不平橫問題，先前也沒有仔細研究這個問題，只是定位到是enable_irq函數調用所致。
因為在項目中使用的中斷是gpio中斷，該中斷在項目中的實現方式為多個gpio中斷共享一個真實的物理中斷，因此當這個真實的物理中斷發生后由系統（就是另一個哥們寫的irq驅動）查詢到底是連接到這個物理中斷上的哪一個具體的gpio產生的了中斷（通過gpio的寄存器位）。這個過程可以認為是一次底層的中斷回調過程。在這次回調過程中，這哥們的驅動會首先屏蔽掉（disable）這個實際的物理中斷，然后開始查詢共享這個物理中斷的所有gpio，當找到后便會調用在這個虛擬的gpio中斷上用戶注冊的中斷回調函數，這個回調函數可以理解為上層回調，當這個回調函數完畢后便返回到底層回調函數中，然后重新enable那個唯一的實際物理中斷。
至此針對這個gpio的中斷回調處理過程全部完成。由此我們也可以發現，對于某個使用gpio中斷的驅動而言，在進出中斷回調函數過程中完全可以不去關心中斷的屏蔽和打開，因為驅動的回調函數（相對認為是上層的）是由底層的那個物理中斷的回調函數調用的，而這個底層的中斷回調函數在進出的過程中關閉和打開這個物理中斷。所以我在使用過程中沒有在中斷處理函數的開始調用disable_irq,也沒有在中斷退出時調用enable_irq相關函數。程序完全可以正確執行。
測試中一個偶然的錯誤讓我發現了一個新的知識，一次調試一個電容屏的驅動時，由于移植中沒有仔細檢查，發現該驅動的probe調用后總是出現如下警告，但是并不影響使用。后來檢查過程中發現，是因為在probe的最后調用了一次enable_irq所致。由于我很清楚上述gpio中斷的實現原理，所以放心刪掉那個enable_irq動作解決了問題。
------------[ cut here ]------------
WARNING: at kernel/irq/manage.c:225 __enable_irq+0x3b/0x57()
Unbalanced enable for IRQ 4
Modules linked in: svsknfdrvr [last unloaded: osal_linux]
Pid: 634, comm: ash Tainted: G W 2.6.28 #1
Call Trace:
[<c011a7f9>] warn_slowpath+0x76/0x8d
[<c012fac8>] profile_tick+0x2d/0x57
[<c011ed72>] irq_exit+0x32/0x34
[<c010f22c>] smp_apic_timer_interrupt+0x41/0x71
[<c01039ec>] apic_timer_interrupt+0x28/0x30
[<c011b2b4>] vprintk+0x1d3/0x300
[<c013a2af>] __setup_irq+0x11c/0x1f2
[<c013a177>] __enable_irq+0x3b/0x57
[<c013a506>] enable_irq+0x37/0x54
[<c68c9156>] svsknfdrvr_open+0x5e/0x65 [svsknfdrvr]
[<c016440a>] chrdev_open+0xce/0x1a4
[<c016433c>] chrdev_open+0x0/0x1a4
[<c01602f7>] __dentry_open+0xcc/0x23a
[<c016049a>] nameidata_to_filp+0x35/0x3f
[<c016b3c5>] do_filp_open+0x16f/0x6ef
[<c0278fd5>] tty_write+0x1a2/0x1c9
[<c0160128>] do_sys_open+0x42/0xcb
[<c0160201>] sys_open+0x23/0x2a
[<c0102e71>] sysenter_do_call+0x12/0x25
---[ end trace 4eaa2a86a8e2da22 ]---


最近針對這個問題我仔細研究了以下，又學到了新東西！
中斷的enable和disable一定要成對使用，否則機會被kernel檢測到unbalance而發出上述警告！
也就是調用一個enable之前一定曾經調用過至少一次disable！
可以想象在disable調用后會有一個計數器被加1，而在enable調用后這個計數器會減1.從而當計數器為0的時候若調用那個enable時就會導致上述警告發生。測試中我針對某個中斷連續調用相關的disable函數數次，然后再開始調用enable函數，發現當調用到大于diable次數時上述警告便會出現。這說明我的想法是對的。


由于太相信這個gpio中斷在使用中可以不去主動disable和enable。也導致我犯了一個嚴重錯誤，而且費了很大勁才解決。還是要多思考啊。。。
在設計這個電容屏的驅動時，我的設計為在其suspend函數中直接切斷電容屏的電源以省電，然后在resume函數中再從新上電。中斷觸發方式為下降沿觸發方式。測試發現，當在suspend中調用斷電操作后總會導致一個I2C讀取動作發生，而這個讀取動作是我在中斷處理函數的底半部中實現的動作。僅僅是電容屏的一個斷電動作怎么會導致這個動作發生呢？
想了好久，我笑了。。。。
下降沿觸發嘛～～ ?當電容屏斷電后當然沒有誰去保持那個中斷引腳為高電平了，它當然會恢復為默認的低電平了（該平臺的中斷默認為電平）。顯然這個過程會導致一個下降沿發生，這便會引起中斷處理函數被調用，從而引起底半部的工作隊列被執行，然后I2C讀取動作便發生了。可是這時候電容屏都斷電了，讀取當然要出錯了！
好了，問題已經找到，現在的問題就是如何讓這個下降沿不要發生，我靠這怎么可能？？？？？
那就只能想辦法讓系統不要理會這個下降沿。咋辦？
簡單，斷電前先disable中斷，resume完成后重新enable這個中斷就好了。。。哈哈
問題解決。
看來無論中斷的底層怎么做，我們盡量不要圖省事而減少一些必要的動作才對！
當然了，我們在自己的代碼中屏掉某個gpio中斷后，如果這個對應的gpio中斷再次產生，底層的那個實際物理中斷所注冊的中斷處理函數依然會運行，也依然會查詢所有的gpio中斷來判斷到底是哪個gpio發出的中斷，但是在找到這個具體的gpio后到底要不要執行這個gpio中斷上注冊的中斷回調函數，這還要看這個gpio中斷有沒有被用戶屏蔽掉，如果被用戶屏蔽了，那么，這個底層的物理中斷的回調函數就會直接返回而不會調用對應的gpio中斷上注冊的回調函數。基于這個原因，我在上面提到的思路才得以正確驗證。


disable_irq_nosync(irq_num);
enable_irq(irq_num);


我的I2C驅動可能還有些問題，比如當用i2c_transfer函數進行傳輸時，如果mesgs參數包含多個消息組，而第一組消息發送時如果發生no slaver responed時，我應該放棄本次傳輸，并且釋放總線，但是現在看來似乎沒有釋放總線，而且后續的傳輸也沒有結束。這會引起一些錯誤，并引起延時。這個還需要進一步優化，或者找出真正的問題。

總結

以上是生活随笔為你收集整理的unbalanced enable irq 问题的解决 以及共享的gpio中断引起的问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。