點(diǎn)擊打開鏈接

最近在工作中使用irq時(shí)遇到如下問題，根據(jù)log顯示應(yīng)該是什么所謂的不平橫問題，先前也沒有仔細(xì)研究這個(gè)問題，只是定位到是enable_irq函數(shù)調(diào)用所致。
因?yàn)樵陧?xiàng)目中使用的中斷是gpio中斷，該中斷在項(xiàng)目中的實(shí)現(xiàn)方式為多個(gè)gpio中斷共享一個(gè)真實(shí)的物理中斷，因此當(dāng)這個(gè)真實(shí)的物理中斷發(fā)生后由系統(tǒng)（就是另一個(gè)哥們寫的irq驅(qū)動(dòng)）查詢到底是連接到這個(gè)物理中斷上的哪一個(gè)具體的gpio產(chǎn)生的了中斷（通過gpio的寄存器位）。這個(gè)過程可以認(rèn)為是一次底層的中斷回調(diào)過程。在這次回調(diào)過程中，這哥們的驅(qū)動(dòng)會(huì)首先屏蔽掉（disable）這個(gè)實(shí)際的物理中斷，然后開始查詢共享這個(gè)物理中斷的所有g(shù)pio，當(dāng)找到后便會(huì)調(diào)用在這個(gè)虛擬的gpio中斷上用戶注冊的中斷回調(diào)函數(shù)，這個(gè)回調(diào)函數(shù)可以理解為上層回調(diào)，當(dāng)這個(gè)回調(diào)函數(shù)完畢后便返回到底層回調(diào)函數(shù)中，然后重新enable那個(gè)唯一的實(shí)際物理中斷。
至此針對這個(gè)gpio的中斷回調(diào)處理過程全部完成。由此我們也可以發(fā)現(xiàn)，對于某個(gè)使用gpio中斷的驅(qū)動(dòng)而言，在進(jìn)出中斷回調(diào)函數(shù)過程中完全可以不去關(guān)心中斷的屏蔽和打開，因?yàn)轵?qū)動(dòng)的回調(diào)函數(shù)（相對認(rèn)為是上層的）是由底層的那個(gè)物理中斷的回調(diào)函數(shù)調(diào)用的，而這個(gè)底層的中斷回調(diào)函數(shù)在進(jìn)出的過程中關(guān)閉和打開這個(gè)物理中斷。所以我在使用過程中沒有在中斷處理函數(shù)的開始調(diào)用disable_irq,也沒有在中斷退出時(shí)調(diào)用enable_irq相關(guān)函數(shù)。程序完全可以正確執(zhí)行。
測試中一個(gè)偶然的錯(cuò)誤讓我發(fā)現(xiàn)了一個(gè)新的知識(shí)，一次調(diào)試一個(gè)電容屏的驅(qū)動(dòng)時(shí)，由于移植中沒有仔細(xì)檢查，發(fā)現(xiàn)該驅(qū)動(dòng)的probe調(diào)用后總是出現(xiàn)如下警告，但是并不影響使用。后來檢查過程中發(fā)現(xiàn)，是因?yàn)樵趐robe的最后調(diào)用了一次enable_irq所致。由于我很清楚上述gpio中斷的實(shí)現(xiàn)原理，所以放心刪掉那個(gè)enable_irq動(dòng)作解決了問題。
------------[ 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 ]---


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


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


disable_irq_nosync(irq_num);
enable_irq(irq_num);


我的I2C驅(qū)動(dòng)可能還有些問題，比如當(dāng)用i2c_transfer函數(shù)進(jìn)行傳輸時(shí)，如果mesgs參數(shù)包含多個(gè)消息組，而第一組消息發(fā)送時(shí)如果發(fā)生no slaver responed時(shí)，我應(yīng)該放棄本次傳輸，并且釋放總線，但是現(xiàn)在看來似乎沒有釋放總線，而且后續(xù)的傳輸也沒有結(jié)束。這會(huì)引起一些錯(cuò)誤，并引起延時(shí)。這個(gè)還需要進(jìn)一步優(yōu)化，或者找出真正的問題。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。