10.4. 中斷共享

10.4.?中斷共享

中斷沖突的概念幾乎是 PC 體系的同義詞. 過去, 在 PC 上的 IRQ 線不能服務(wù)多于一個設(shè)備, 并且它們從不足夠. 結(jié)果, 失望的用戶花費(fèi)大量時間開著它們的計算機(jī), 盡力找到一個方法來使它們所有的外設(shè)一起工作.

現(xiàn)代的硬件, 當(dāng)然, 已經(jīng)設(shè)計來允許中斷共享; PCI 總線要求它. 因此, Linux 內(nèi)核支持在所有總線上中斷共享, 甚至是那些(例如 ISA 總線)傳統(tǒng)上不被支持的. 2.6 內(nèi)核的設(shè)備驅(qū)動應(yīng)當(dāng)編寫來使用共享中斷, 如果目標(biāo)硬件能夠支持這個操作模式. 幸運(yùn)的是, 使用共享中斷在大部分時間是容易的.

10.4.1.?安裝一個共享的處理者

共享中斷通過 request_irq 來安裝就像不共享的一樣, 但是有 2 個不同:

• SA_SHIRQ 位必須在 flags 參數(shù)中指定, 當(dāng)請求中斷時.

• dev_id 參數(shù)必須是獨(dú)特的. 任何模塊地址空間的指針都行, 但是 dev_id 明確地不能設(shè)置為 NULL.

內(nèi)核保持著一個與中斷相關(guān)聯(lián)的共享處理者列表, 并且 dev_id 可認(rèn)為是區(qū)別它們的簽名. 如果 2 個驅(qū)動要在同一個中斷上注冊 NULL 作為它們的簽名, 在卸載時事情可能就亂了, 在中斷到的時候引發(fā)內(nèi)核 oops. 由于這個理由, 如果在注冊共享中斷時傳給了一個 NULL dev_id , 現(xiàn)代內(nèi)核會大聲抱怨. 當(dāng)請求一個共享的中斷, request_irq 成功, 如果下列之一是真:

• 中斷線空閑.

• 所有這條線的已經(jīng)注冊的處理者也指定共享這個 IRQ.

無論何時 2 個或多個驅(qū)動在共享中斷線, 并且硬件中斷在這條線上中斷處理器, 內(nèi)核為這個中斷調(diào)用每個注冊的處理者, 傳遞它的 dev_id 給每個. 因此, 一個共享的處理者必須能夠識別它自己的中斷并且應(yīng)當(dāng)快速退出當(dāng)它自己的設(shè)備沒有被中斷時. 確認(rèn)返回 IRQ_NONE 無論何時你的處理者被調(diào)用并且發(fā)現(xiàn)設(shè)備沒被中斷.

如果你需要探測你的設(shè)備, 在請求 IRQ 線之前, 內(nèi)核無法幫你. 沒有探測函數(shù)可給共享處理者使用. 標(biāo)準(zhǔn)的探測機(jī)制有效如果使用的線是空閑的, 但是如果這條線已經(jīng)被另一個有共享能力的驅(qū)動持有, 探測失敗, 即便你的驅(qū)動已正常工作. 幸運(yùn)的是, 大部分設(shè)計為中斷共享的硬件能夠告知處理器它在使用哪個中斷, 因此減少明顯的探測的需要.

釋放處理者以正常方式進(jìn)行, 使用 free_irq. 這里 dev_id 參數(shù)用來從這個中斷的共享處理者列表中選擇正確的處理者來釋放. 這就是為什么 dev_id 指針必須是獨(dú)特的.

一個使用共享處理者的驅(qū)動需要小心多一件事: 它不能使用 enable_irq 或者 disable_irq. 如果它用了, 對其他共享這條線的設(shè)備就亂了; 禁止另一個設(shè)備的中斷即便短時間也可能產(chǎn)生延時, 這對這個設(shè)備和它的用戶是有問題的. 通常, 程序員必須記住, 他的驅(qū)動不擁有這個 IRQ, 并且它的行為應(yīng)當(dāng)比它擁有這個中斷線更加"社會性".

10.4.2.?運(yùn)行處理者

如同前面建議的, 當(dāng)內(nèi)核收到一個中斷, 所有的注冊的處理者被調(diào)用. 一個共享的處理者必須能夠在它需要的處理的中斷和其他設(shè)備產(chǎn)生的中斷之間區(qū)分.

使用 shared=1 選項來加載 short 安裝了下列處理者來代替缺省的:

irqreturn_t short_sh_interrupt(int irq, void *dev_id, struct pt_regs *regs) 
{
        int value, written;
        struct timeval tv;
        /* If it wasn't short, return immediately */
        value = inb(short_base);
        if (!(value & 0x80))
                return IRQ_NONE;
        /* clear the interrupting bit */
        outb(value & 0x7F, short_base);
        /* the rest is unchanged */
        do_gettimeofday(&tv);
        written = sprintf((char *)short_head,"%08u.%06u\n",
                          (int)(tv.tv_sec % 100000000), (int)(tv.tv_usec));
        short_incr_bp(&short_head, written);
        wake_up_interruptible(&short_queue); /* awake any reading process */
        return IRQ_HANDLED;
}

這里應(yīng)該有個解釋. 因為并口沒有"中斷掛起"位來檢查, 處理者使用 ACK 位作此目的. 如果這個位是高, 正報告的中斷是給 short, 并且這個處理者清除這個位.

處理者通過并口數(shù)據(jù)端口的清零來復(fù)位這個位 -- short 假設(shè)管腳 9 和 10 連在一起. 如果其他一個和 short 共享這個 IRQ 的設(shè)備產(chǎn)生一個中斷, short 看到它的線仍然非激活并且什么不作.

當(dāng)然, 一個功能齊全的驅(qū)動可能將工作劃分位前和后半部, 但是容易添加并且不會有任何影響實現(xiàn)共享的代碼. 一個真實驅(qū)動還可能使用 dev_id 參數(shù)來決定, 在很多可能的中, 哪個設(shè)備在中斷.

注意, 如果你使用打印機(jī)(代替跳線)來測試使用 short 的中斷管理, 這個共享的處理者不象所說的一樣工作,因為打印機(jī)協(xié)議不允許共享, 并且驅(qū)動不知道是否這個中斷是來自打印機(jī).

10.4.3.?/proc 接口和共享中斷

在系統(tǒng)中安裝共享處理者不影響 /proc/stat, 它甚至不知道處理者. 但是, /proc/interrupts 稍稍變化.

所有同一個中斷號的安裝的處理者出現(xiàn)在 /proc/interrupts 的同一行. 下列輸出( 從一個 x86_64 系統(tǒng))顯示了共享中斷處理是如何顯示的:

 CPU0
 0: 892335412 XT-PIC timer
 1: 453971 XT-PIC i8042
 2: 0 XT-PIC cascade
 5: 0 XT-PIC libata, ehci_hcd
 8: 0 XT-PIC rtc
 9: 0 XT-PIC acpi
 10: 11365067 XT-PIC ide2, uhci_hcd, uhci_hcd, SysKonnect SK-98xx, EMU10K1
 11: 4391962 XT-PIC uhci_hcd, uhci_hcd
 12: 224 XT-PIC i8042
 14: 2787721 XT-PIC ide0
 15: 203048 XT-PIC ide1
NMI: 41234
LOC: 892193503
ERR: 102
MIS: 0

這個系統(tǒng)有幾個共享中斷線. IRQ 5 用來給串行 ATA 和 IEEE 1394 控制器; IRQ 10 有幾個設(shè)備, 包括一個 IDE 控制器, 2 個 USB 控制器, 一個以太網(wǎng)接口, 以及一個聲卡; 并且 IRQ 11 也被 2 個 USB 控制器使用.