一、前言

本文主要的議題是作為一個(gè)普通的驅(qū)動(dòng)工程師，在撰寫(xiě)自己負(fù)責(zé)的驅(qū)動(dòng)的時(shí)候，如何向Linux Kernel中的中斷子系統(tǒng)注冊(cè)中斷處理函數(shù)？為了理解注冊(cè)中斷的接口，必須了解一些中斷線程化（threaded interrupt handler）的基礎(chǔ)知識(shí)，這些在第二章描述。第三章主要描述了驅(qū)動(dòng)申請(qǐng) interrupt line接口API request_threaded_irq的規(guī)格。第四章是進(jìn)入request_threaded_irq的實(shí)現(xiàn)細(xì)節(jié)，分析整個(gè)代碼的執(zhí)行過(guò)程。

二、和中斷相關(guān)的linux實(shí)時(shí)性分析以及中斷線程化的背景介紹

1、非搶占式linux內(nèi)核的實(shí)時(shí)性

在遙遠(yuǎn)的過(guò)去，linux2.4之前的內(nèi)核是不支持搶占特性的，具體可以參考下圖：

事情的開(kāi)始源自高優(yōu)先級(jí)任務(wù)（橘色block）由于要等待外部事件（例如網(wǎng)絡(luò)數(shù)據(jù)）而進(jìn)入睡眠，調(diào)度器調(diào)度了某個(gè)低優(yōu)先級(jí)的任務(wù)（紫色block）執(zhí)行。該低優(yōu)先級(jí)任務(wù)歡暢的執(zhí)行，直到觸發(fā)了一次系統(tǒng)調(diào)用（例如通過(guò)read()文件接口讀取磁盤(pán)上的文件等）而進(jìn)入了內(nèi)核態(tài)。仍然是熟悉的配方，仍然是熟悉的味道，低優(yōu)先級(jí)任務(wù)正在執(zhí)行不會(huì)變化，只不過(guò)從user space切換到了kernel space。外部事件總是在你不想讓它來(lái)的時(shí)候到來(lái)，T0時(shí)刻，高優(yōu)先級(jí)任務(wù)等待的那個(gè)中斷事件發(fā)生了。

中斷雖然發(fā)生了，但軟件不一定立刻響應(yīng)，可能由于在內(nèi)核態(tài)執(zhí)行的某些操作不希望被外部事件打斷而主動(dòng)關(guān)閉了中斷（或是關(guān)閉了CPU的中斷，或者M(jìn)ASK了該IRQ number），這時(shí)候，中斷信號(hào)沒(méi)有立刻得到響應(yīng)，軟件仍然在內(nèi)核態(tài)執(zhí)行低優(yōu)先級(jí)任務(wù)系統(tǒng)調(diào)用的代碼。在T1時(shí)刻，內(nèi)核態(tài)代碼由于退出臨界區(qū)而打開(kāi)中斷（注意：上圖中的比例是不協(xié)調(diào)的，一般而言，linux kernel不會(huì)有那么長(zhǎng)的關(guān)中斷時(shí)間，上面主要是為了表示清楚，同理，從中斷觸發(fā)到具體中斷服務(wù)程序的執(zhí)行也沒(méi)有那么長(zhǎng)，都是為了表述清楚），中斷一旦打開(kāi)，立刻跳轉(zhuǎn)到了異常向量地址，interrupt handler搶占了低優(yōu)先級(jí)任務(wù)的執(zhí)行，進(jìn)入中斷上下文（雖然這時(shí)候的current task是低優(yōu)先級(jí)任務(wù)，但是中斷上下文和它沒(méi)有任何關(guān)系）。

從CPU開(kāi)始處理中斷到具體中斷服務(wù)程序被執(zhí)行還需要一個(gè)分發(fā)的過(guò)程。這個(gè)期間系統(tǒng)要做的主要操作包括確定HW interrupt ID，確定IRQ Number，ack或者mask中斷，調(diào)用中斷服務(wù)程序等。T0到T2之間的delay被稱為中斷延遲（Interrupt Latency），主要包括兩部分，一部分是HW造成的delay（硬件的中斷系統(tǒng)識(shí)別外部的中斷事件并signal到CPU），另外一部分是軟件原因（內(nèi)核代碼中由于要保護(hù)臨界區(qū)而關(guān)閉中斷引起的）。

該中斷的服務(wù)程序執(zhí)行完畢（在其執(zhí)行過(guò)程中，T3時(shí)刻，會(huì)喚醒高優(yōu)先級(jí)任務(wù)，讓它從sleep狀態(tài)進(jìn)入runable狀態(tài)），返回低優(yōu)先級(jí)任務(wù)的系統(tǒng)調(diào)用現(xiàn)場(chǎng)，這時(shí)候并不存在一個(gè)搶占點(diǎn)，低優(yōu)先級(jí)任務(wù)要完成系統(tǒng)調(diào)用之后，在返回用戶空間的時(shí)候才出現(xiàn)搶占點(diǎn)。漫長(zhǎng)的等待之后，T4時(shí)刻，調(diào)度器調(diào)度高優(yōu)先級(jí)任務(wù)執(zhí)行。有一個(gè)術(shù)語(yǔ)叫做任務(wù)響應(yīng)時(shí)間（Task Response Time）用來(lái)描述T3到T4之間的delay。

2、搶占式linux內(nèi)核的實(shí)時(shí)性

2.6內(nèi)核和2.4內(nèi)核顯著的不同是提供了一個(gè)CONFIG_PREEMPT的選項(xiàng)，打開(kāi)該選項(xiàng)后，linux kernel就支持了內(nèi)核代碼的搶占（當(dāng)然不能在臨界區(qū)），其行為如下：

T0到T3的操作都是和上一節(jié)的描述一樣的，不同的地方是在T4。對(duì)于2.4內(nèi)核，只有返回用戶空間的時(shí)候才有搶占點(diǎn)出現(xiàn)，但是對(duì)于搶占式內(nèi)核而言，即便是從中斷上下文返回內(nèi)核空間的進(jìn)程上下文，只要內(nèi)核代碼不在臨界區(qū)內(nèi)，就可以發(fā)生調(diào)度，讓最高優(yōu)先級(jí)的任務(wù)調(diào)度執(zhí)行。

在非搶占式linux內(nèi)核中，一個(gè)任務(wù)的內(nèi)核態(tài)是不可以被其他進(jìn)程搶占的。這里并不是說(shuō)kernel space不可以被搶占，只是說(shuō)進(jìn)程通過(guò)系統(tǒng)調(diào)用陷入到內(nèi)核的時(shí)候，不可以被其他的進(jìn)程搶占。實(shí)際上，中斷上下文當(dāng)然可以搶占進(jìn)程上下文（無(wú)論是內(nèi)核態(tài)還是用戶態(tài)），更進(jìn)一步，中斷上下文是擁有至高無(wú)上的權(quán)限，它甚至可以搶占其他的中斷上下文。引入搶占式內(nèi)核后，系統(tǒng)的平均任務(wù)響應(yīng)時(shí)間會(huì)縮短，但是，實(shí)時(shí)性更關(guān)注的是：無(wú)論在任何的負(fù)載情況下，任務(wù)響應(yīng)時(shí)間是確定的。因此，更需要關(guān)注的是worst-case的任務(wù)響應(yīng)時(shí)間。這里有兩個(gè)因素會(huì)影響worst case latency：

（1）為了同步，內(nèi)核中總有些代碼需要持有自旋鎖資源，或者顯式的調(diào)用preempt_disable來(lái)禁止搶占，這時(shí)候不允許搶占

（2）中斷上下文（并非只是中斷handler，還包括softirq、timer、tasklet）總是可以搶占進(jìn)程上下文

因此，即便是打開(kāi)了PREEMPT的選項(xiàng)，實(shí)際上linux系統(tǒng)的任務(wù)響應(yīng)時(shí)間仍然是不確定的。一方面內(nèi)核代碼的臨界區(qū)非常多，我們需要找到，系統(tǒng)中持有鎖，或者禁止搶占的最大的時(shí)間片。另外一方面，在上圖的T4中，能順利的調(diào)度高優(yōu)先級(jí)任務(wù)并非易事，這時(shí)候可能有觸發(fā)的軟中斷，也可能有新來(lái)的中斷，也可能某些driver的tasklet要執(zhí)行，只有在沒(méi)有任何bottom half的任務(wù)要執(zhí)行的時(shí)候，調(diào)度器才會(huì)啟動(dòng)調(diào)度。

3、進(jìn)一步提高linux內(nèi)核的實(shí)時(shí)性

通過(guò)上一個(gè)小節(jié)的描述，相信大家都確信中斷對(duì)linux 實(shí)時(shí)性的最大的敵人。那么怎么破？我曾經(jīng)接觸過(guò)一款RTOS，它的中斷handler非常簡(jiǎn)單，就是發(fā)送一個(gè)inter-task message到該driver thread，對(duì)任何的一個(gè)驅(qū)動(dòng)都是如此處理。這樣，每個(gè)中斷上下文都變得非常簡(jiǎn)短，而且每個(gè)中斷都是一致的。在這樣的設(shè)計(jì)中，外設(shè)中斷的處理線程化了，然后，系統(tǒng)設(shè)計(jì)師要仔細(xì)的為每個(gè)系統(tǒng)中的task分配優(yōu)先級(jí)，確保整個(gè)系統(tǒng)的實(shí)時(shí)性。

在Linux kernel中，一個(gè)外設(shè)的中斷處理被分成top half和bottom half，top half進(jìn)行最關(guān)鍵，最基本的處理，而比較耗時(shí)的操作被放到bottom half（softirq、tasklet）中延遲執(zhí)行。雖然bottom half被延遲執(zhí)行，但始終都是先于進(jìn)程執(zhí)行的。為何不讓這些耗時(shí)的bottom half和普通進(jìn)程公平競(jìng)爭(zhēng)呢？因此，linux kernel借鑒了RTOS的某些特性，對(duì)那些耗時(shí)的驅(qū)動(dòng)interrupt handler進(jìn)行線程化處理，在內(nèi)核的搶占點(diǎn)上，讓線程（無(wú)論是內(nèi)核線程還是用戶空間創(chuàng)建的線程，還是驅(qū)動(dòng)的interrupt thread）在一個(gè)舞臺(tái)上競(jìng)爭(zhēng)CPU。

三、request_threaded_irq的接口規(guī)格

1、輸入?yún)?shù)描述

2、輸出參數(shù)描述

0表示成功執(zhí)行，負(fù)數(shù)表示各種錯(cuò)誤原因。

3、Interrupt type flags

四、request_threaded_irq代碼分析

1、request_threaded_irq主流程

int request_threaded_irq(unsigned int irq, irq_handler_t handler,
             irq_handler_t thread_fn, unsigned long irqflags,
             const char *devname, void *dev_id)
{ 
    if ((irqflags & IRQF_SHARED) && !dev_id)－－－－－－－－－（1）
        return -EINVAL;

    desc = irq_to_desc(irq); －－－－－－－－－－－－－－－－－（2）
    if (!desc)         return -EINVAL;

    if (!irq_settings_can_request(desc) || －－－－－－－－－－－－（3）
        WARN_ON(irq_settings_is_per_cpu_devid(desc)))
        return -EINVAL;

    if (!handler) { －－－－－－－－－－－－－－－－－－－－－－（4）
        if (!thread_fn)
            return -EINVAL;
        handler = irq_default_primary_handler;
    }

    action = kzalloc(sizeof(struct irqaction), GFP_KERNEL);

    action->handler = handler;
    action->thread_fn = thread_fn;
    action->flags = irqflags;
    action->name = devname;
    action->dev_id = dev_id;

    chip_bus_lock(desc);
    retval = __setup_irq(irq, desc, action); －－－－－－－－－－－（5）
    chip_bus_sync_unlock(desc);
}

（1）對(duì)于那些需要共享的中斷，在request irq的時(shí)候需要給出dev id，否則會(huì)出錯(cuò)退出。為何對(duì)于IRQF_SHARED的中斷必須要給出dev id呢？實(shí)際上，在共享的情況下，一個(gè)IRQ number對(duì)應(yīng)若干個(gè)irqaction，當(dāng)操作irqaction的時(shí)候，僅僅給出IRQ number就不是非常的足夠了，這時(shí)候，需要一個(gè)ID表示具體的irqaction，這里就是dev_id的作用了。我們舉一個(gè)例子：

void free_irq(unsigned int irq, void *dev_id)

當(dāng)釋放一個(gè)IRQ資源的時(shí)候，不但要給出IRQ number，還要給出device ID。只有這樣，才能精準(zhǔn)的把要釋放的那個(gè)irqaction 從irq action list上移除。dev_id在中斷處理中有沒(méi)有作用呢？我們來(lái)看看source code：

irqreturn_t handle_irq_event_percpu(struct irq_desc *desc, struct irqaction *action)
{

    do {
        irqreturn_t res; 
        res = action->handler(irq, action->dev_id);

……
        action = action->next;
    } while (action);

……
}

linux interrupt framework雖然支持中斷共享，但是它并不會(huì)協(xié)助解決識(shí)別問(wèn)題，它只會(huì)遍歷該IRQ number上注冊(cè)的irqaction的callback函數(shù)，這樣，雖然只是一個(gè)外設(shè)產(chǎn)生的中斷，linux kernel還是把所有共享的那些中斷handler都逐個(gè)調(diào)用執(zhí)行。為了讓系統(tǒng)的performance不受影響，irqaction的callback函數(shù)必須在函數(shù)的最開(kāi)始進(jìn)行判斷，是否是自己的硬件設(shè)備產(chǎn)生了中斷（讀取硬件的寄存器），如果不是，盡快的退出。

需要注意的是，這里dev_id并不能在中斷觸發(fā)的時(shí)候用來(lái)標(biāo)識(shí)需要調(diào)用哪一個(gè)irqaction的callback函數(shù)，通過(guò)上面的代碼也可以看出，dev_id有些類(lèi)似一個(gè)參數(shù)傳遞的過(guò)程，可以把具體driver的一些硬件信息，組合成一個(gè)structure，在觸發(fā)中斷的時(shí)候可以把這個(gè)structure傳遞給中斷處理函數(shù)。

（2）通過(guò)IRQ number獲取對(duì)應(yīng)的中斷描述符。在引入CONFIG_SPARSE_IRQ選項(xiàng)后，這個(gè)轉(zhuǎn)換變得不是那么簡(jiǎn)單了。在過(guò)去，我們會(huì)以IRQ number為index，從irq_desc這個(gè)全局?jǐn)?shù)組中直接獲取中斷描述符。如果配置CONFIG_SPARSE_IRQ選項(xiàng)，則需要從radix tree中搜索。CONFIG_SPARSE_IRQ選項(xiàng)的更詳細(xì)的介紹請(qǐng)參考IRQ number和中斷描述符

（3）并非系統(tǒng)中所有的IRQ number都可以request，有些中斷描述符被標(biāo)記為IRQ_NOREQUEST，標(biāo)識(shí)該IRQ number不能被其他的驅(qū)動(dòng)request。一般而言，這些IRQ number有特殊的作用，例如用于級(jí)聯(lián)的那個(gè)IRQ number是不能request。irq_settings_can_request函數(shù)就是判斷一個(gè)IRQ是否可以被request。

irq_settings_is_per_cpu_devid函數(shù)用來(lái)判斷一個(gè)中斷描述符是否需要傳遞per cpu的device ID。per cpu的中斷上面已經(jīng)描述的很清楚了，這里不再細(xì)述。如果一個(gè)中斷描述符對(duì)應(yīng)的中斷 ID是per cpu的，那么在申請(qǐng)其handler的時(shí)候就有兩種情況，一種是傳遞統(tǒng)一的dev_id參數(shù)（傳入request_threaded_irq的最后一個(gè)參數(shù)），另外一種情況是針對(duì)每個(gè)CPU，傳遞不同的dev_id參數(shù)。在這種情況下，我們需要調(diào)用request_percpu_irq接口函數(shù)而不是request_threaded_irq。

（4）傳入request_threaded_irq的primary handler和threaded handler參數(shù)有下面四種組合：

（5）這部分的代碼很簡(jiǎn)單，分配struct irqaction，賦值，調(diào)用__setup_irq進(jìn)行實(shí)際的注冊(cè)過(guò)程。這里要羅嗦幾句的是鎖的操作，在內(nèi)核中，有很多函數(shù)，有的是需要調(diào)用者自己加鎖保護(hù)的，有些是不需要加鎖保護(hù)的。對(duì)于這些場(chǎng)景，linux kernel采取了統(tǒng)一的策略：基本函數(shù)名字是一樣的，只不過(guò)需要調(diào)用者自己加鎖保護(hù)的那個(gè)函數(shù)需要增加__的前綴，例如內(nèi)核有有下面兩個(gè)函數(shù)：setup_irq和__setup_irq。這里，我們?cè)趕etup irq的時(shí)候已經(jīng)調(diào)用chip_bus_lock進(jìn)行保護(hù)，因此使用lock free的版本__setup_irq。

chip_bus_lock定義如下：

static inline void chip_bus_lock(struct irq_desc *desc)
{
    if (unlikely(desc->irq_data.chip->irq_bus_lock))
        desc->irq_data.chip->irq_bus_lock(&desc->irq_data);
}

大部分的interrupt controller并沒(méi)有定義irq_bus_lock這個(gè)callback函數(shù)，因此chip_bus_lock這個(gè)函數(shù)對(duì)大多數(shù)的中斷控制器而言是沒(méi)有實(shí)際意義的。但是，有些interrupt controller是連接到慢速總線上的，例如一個(gè)i2c接口的IO expander芯片（這種芯片往往也提供若干有中斷功能的GPIO，因此也是一個(gè)interrupt controller），在訪問(wèn)這種interrupt controller的時(shí)候需要lock住那個(gè)慢速bus（只能有一個(gè)client在使用I2C bus）。

2、注冊(cè)irqaction

（1）nested IRQ的處理代碼

在看具體的代碼之前，我們首先要理解什么是nested IRQ。nested IRQ不是cascade IRQ，在GIC代碼分析中我們有描述過(guò)cascade IRQ這個(gè)概念，主要用在interrupt controller級(jí)聯(lián)的情況下。為了方便大家理解，我還是給出一個(gè)具體的例子吧，具體的HW block請(qǐng)參考下圖：

上圖是一個(gè)兩個(gè)GIC級(jí)聯(lián)的例子，所有的HW block封裝在了一個(gè)SOC chip中。為了方便描述，我們先進(jìn)行編號(hào)：Secondary GIC的IRQ number是A，外設(shè)1的IRQ number是B，外設(shè)2的IRQ number是C。對(duì)于上面的硬件，linux kernel處理如下：

（a）IRQ A的中斷描述符被設(shè)定為不能注冊(cè)irqaction（不能注冊(cè)specific interrupt handler，或者叫中斷服務(wù)程序）

（b）IRQ A的highlevel irq-events handler（處理interrupt flow control）負(fù)責(zé)進(jìn)行IRQ number的映射，在其irq domain上翻譯出具體外設(shè)的IRQ number，并重新定向到外設(shè)IRQ number對(duì)應(yīng)的highlevel irq-events handler。

（c）所有外設(shè)驅(qū)動(dòng)的中斷正常request irq，可以任意選擇線程化的handler，或者只注冊(cè)primary handler。

需要注意的是，對(duì)root GIC和Secondary GIC寄存器的訪問(wèn)非常快，因此ack、mask、EOI等操作也非?？臁?/p>

我們?cè)倏纯戳硗庖粋€(gè)interrupt controller級(jí)聯(lián)的情況：

IO expander HW block提供了有中斷功能的GPIO，因此它也是一個(gè)interrupt controller，有它自己的irq domain和irq chip。上圖中外設(shè)1和外設(shè)2使用了IO expander上有中斷功能的GPIO，它們有屬于自己的IRQ number以及中斷描述符。IO expander HW block的IRQ line連接到SOC內(nèi)部的interrupt controller上，因此，這也是一個(gè)interrupt controller級(jí)聯(lián)的情況，對(duì)于這種情況，我們是否可以采用和上面GIC級(jí)聯(lián)的處理方式呢？

不行，對(duì)于GIC級(jí)聯(lián)的情況，如果secondary GIC上的外設(shè)1產(chǎn)生了中斷，整個(gè)關(guān)中斷的時(shí)間是IRQ A的中斷描述符的highlevel irq-events handler處理時(shí)間＋I(xiàn)RQ B的的中斷描述符的highlevel irq-events handler處理時(shí)間＋外設(shè)1的primary handler的處理時(shí)間。所幸對(duì)root GIC和Secondary GIC寄存器的訪問(wèn)非常快，因此整個(gè)關(guān)中斷的時(shí)間也不是非常的長(zhǎng)。但是如果是IO expander這個(gè)情況，如果采取和上面GIC級(jí)聯(lián)的處理方式一樣的話，關(guān)中斷的時(shí)間非常長(zhǎng)。我們還是用外設(shè)1產(chǎn)生的中斷為例子好了。這時(shí)候，由于IRQ B的的中斷描述符的highlevel irq-events handler處理設(shè)計(jì)I2C的操作，因此時(shí)間非常的長(zhǎng)，這時(shí)候，對(duì)于整個(gè)系統(tǒng)的實(shí)時(shí)性而言是致命的打擊。對(duì)這種硬件情況，linux kernel處理如下：

（a）IRQ A的中斷描述符的highlevel irq-events handler根據(jù)實(shí)際情況進(jìn)行設(shè)定，并且允許注冊(cè)irqaction。對(duì)于連接到IO expander上的外設(shè)，它是沒(méi)有real time的要求的（否則也不會(huì)接到IO expander上），因此一般會(huì)進(jìn)行線程化處理。由于threaded handler中涉及I2C操作，因此要設(shè)定IRQF_ONESHOT的flag。

（b）在IRQ A的中斷描述符的threaded interrupt handler中進(jìn)行進(jìn)行IRQ number的映射，在IO expander irq domain上翻譯出具體外設(shè)的IRQ number，并直接調(diào)用handle_nested_irq函數(shù)處理該IRQ。

（c）外設(shè)對(duì)應(yīng)的中斷描述符設(shè)定IRQ_NESTED_THREAD的flag，表明這是一個(gè)nested IRQ。nested IRQ沒(méi)有highlevel irq-events handler，也沒(méi)有primary handler，它的threaded interrupt handler是附著在其parent IRQ的threaded handler上的。

具體的nested IRQ的處理代碼如下：

static int __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
{

……
    nested = irq_settings_is_nested_thread(desc);
    if (nested) {
        if (!new->thread_fn) {
            ret = -EINVAL;
            goto out_mput;
        }
        new->handler = irq_nested_primary_handler;
    } else { 
……
    }

……

}

如果一個(gè)中斷描述符是nested thread type的，說(shuō)明這個(gè)中斷描述符應(yīng)該設(shè)定threaded interrupt handler（當(dāng)然，內(nèi)核是不會(huì)單獨(dú)創(chuàng)建一個(gè)thread的，它是借著其parent IRQ的interrupt thread執(zhí)行），否則就會(huì)出錯(cuò)返回。對(duì)于primary handler，它應(yīng)該沒(méi)有機(jī)會(huì)被調(diào)用到，當(dāng)然為了調(diào)試，kernel將其設(shè)定為irq_nested_primary_handler，以便在調(diào)用的時(shí)候打印一些信息，讓工程師直到發(fā)生了什么狀況。

（2）forced irq threading處理

具體的forced irq threading的處理代碼如下：

static int __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
{

……
    nested = irq_settings_is_nested_thread(desc);
    if (nested) { 
……
    } else {
        if (irq_settings_can_thread(desc))
            irq_setup_forced_threading(new);
    }

……

}

forced irq threading其實(shí)就是將系統(tǒng)中所有可以被線程化的中斷handler全部線程化，即便你在request irq的時(shí)候，設(shè)定的是primary handler，而不是threaded handler。當(dāng)然那些不能被線程化的中斷（標(biāo)注了IRQF_NO_THREAD的中斷，例如系統(tǒng)timer）還是排除在外的。irq_settings_can_thread函數(shù)就是判斷一個(gè)中斷是否可以被線程化，如果可以的話，則調(diào)用irq_setup_forced_threading在set irq的時(shí)候強(qiáng)制進(jìn)行線程化。具體代碼如下：

static void irq_setup_forced_threading(struct irqaction *new)
{
    if (!force_irqthreads)－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－（a）
        return;
    if (new->flags & (IRQF_NO_THREAD | IRQF_PERCPU | IRQF_ONESHOT))－－－－－－－（b）
        return;

    new->flags |= IRQF_ONESHOT; －－－－－－－－－－－－－－－－－－－－－－－－－（d）

    if (!new->thread_fn) {－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－（c）
        set_bit(IRQTF_FORCED_THREAD, &new->thread_flags);
        new->thread_fn = new->handler;
        new->handler = irq_default_primary_handler;
    }
}

（a）系統(tǒng)中有一個(gè)強(qiáng)制線程化的選項(xiàng)：CONFIG_IRQ_FORCED_THREADING，如果沒(méi)有打開(kāi)該選項(xiàng)，force_irqthreads總是0，因此irq_setup_forced_threading也就沒(méi)有什么作用，直接return了。如果打開(kāi)了CONFIG_IRQ_FORCED_THREADING，說(shuō)明系統(tǒng)支持強(qiáng)制線程化，但是具體是否對(duì)所有的中斷進(jìn)行強(qiáng)制線程化處理還是要看命令行參數(shù)threadirqs。如果kernel啟動(dòng)的時(shí)候沒(méi)有傳入該參數(shù)，那么同樣的，irq_setup_forced_threading也就沒(méi)有什么作用，直接return了。只有bootloader向內(nèi)核傳入threadirqs這個(gè)命令行參數(shù)，內(nèi)核才真正在啟動(dòng)過(guò)程中，進(jìn)行各個(gè)中斷的強(qiáng)制線程化的操作。

（b）看到IRQF_NO_THREAD選項(xiàng)你可能會(huì)奇怪，前面irq_settings_can_thread函數(shù)不是檢查過(guò)了嗎？為何還要重復(fù)檢查？其實(shí)一個(gè)中斷是否可以進(jìn)行線程化可以從兩個(gè)層面看：一個(gè)是從底層看，也就是從中斷描述符、從實(shí)際的中斷硬件拓?fù)涞确矫婵础Ａ硗庖粋€(gè)是從中斷子系統(tǒng)的用戶層面看，也就是各個(gè)外設(shè)在注冊(cè)自己的handler的時(shí)候是否想進(jìn)行線程化處理。所有的IRQF_XXX都是從用戶層面看的flag，因此如果用戶通過(guò)IRQF_NO_THREAD這個(gè)flag告知kernel，該interrupt不能被線程化，那么強(qiáng)制線程化的機(jī)制還是尊重用戶的選擇的。

PER CPU的中斷都是一些較為特殊的中斷，不是一般意義上的外設(shè)中斷，因此對(duì)PER CPU的中斷不強(qiáng)制進(jìn)行線程化。IRQF_ONESHOT選項(xiàng)說(shuō)明該中斷已經(jīng)被線程化了（而且是特殊的one shot類(lèi)型的），因此也是直接返回了。

（c）強(qiáng)制線程化只對(duì)那些沒(méi)有設(shè)定thread_fn的中斷進(jìn)行處理，這種中斷將全部的處理放在了primary interrupt handler中（當(dāng)然，如果中斷處理比較耗時(shí)，那么也可能會(huì)采用bottom half的機(jī)制），由于primary interrupt handler是全程關(guān)閉CPU中斷的，因此可能對(duì)系統(tǒng)的實(shí)時(shí)性造成影響，因此考慮將其強(qiáng)制線程化。struct irqaction中的thread_flags是和線程相關(guān)的flag，我們給它打上IRQTF_FORCED_THREAD的標(biāo)簽，表明該threaded handler是被強(qiáng)制threaded的。new->thread_fn = new->handler這段代碼表示將原來(lái)primary handler中的內(nèi)容全部放到threaded handler中處理，新的primary handler被設(shè)定為default handler。

（d）強(qiáng)制線程化是一個(gè)和實(shí)時(shí)性相關(guān)的選項(xiàng)，從我的角度來(lái)看是一個(gè)很不好的設(shè)計(jì)（個(gè)人觀點(diǎn)），各個(gè)驅(qū)動(dòng)工程師在撰寫(xiě)自己的驅(qū)動(dòng)代碼的時(shí)候已經(jīng)安排好了自己的上下文環(huán)境。有的是進(jìn)程上下文，有的是中斷上下文，在各自的上下文環(huán)境中，驅(qū)動(dòng)工程師又選擇了適合的內(nèi)核同步機(jī)制。但是，強(qiáng)制線程化導(dǎo)致原來(lái)運(yùn)行在中斷上下文的primary handler現(xiàn)在運(yùn)行在進(jìn)程上下文，這有可能導(dǎo)致一些難以跟蹤和定位的bug。

當(dāng)然，作為內(nèi)核的開(kāi)發(fā)者，既然同意將強(qiáng)制線程化這個(gè)特性并入linux kernel，相信他們有他們自己的考慮。我猜測(cè)這是和一些舊的驅(qū)動(dòng)代碼維護(hù)相關(guān)的。linux kernel中的中斷子系統(tǒng)的API的修改會(huì)引起非常大的震動(dòng)，因?yàn)閮?nèi)核中成千上萬(wàn)的驅(qū)動(dòng)都是需要調(diào)用舊的接口來(lái)申請(qǐng)linux kernel中斷子系統(tǒng)的服務(wù)，對(duì)每一個(gè)驅(qū)動(dòng)都進(jìn)行修改是一個(gè)非常耗時(shí)的工作，為了讓那些舊的驅(qū)動(dòng)代碼可以運(yùn)行在新的中斷子系統(tǒng)上，因此，在kernel中，實(shí)際上仍然提供了舊的request_irq接口函數(shù)，如下：

static inline int __must_check
request_irq(unsigned int irq, irq_handler_t handler, unsigned long flags,
        const char *name, void *dev)
{
    return request_threaded_irq(irq, handler, NULL, flags, name, dev);
}

接口是OK了，但是，新的中斷子系統(tǒng)的思路是將中斷處理分成primary handler和threaded handler，而舊的驅(qū)動(dòng)代碼一般是將中斷處理分成top half和bottom half，如何將這部分的不同抹平？linux kernel是這樣處理的（這是我個(gè)人的理解，不保證是正確的）：

（d-1）內(nèi)核為那些被強(qiáng)制線程化的中斷handler設(shè)定了IRQF_ONESHOT的標(biāo)識(shí)。這是因?yàn)樵谂f的中斷處理機(jī)制中，top half是不可重入的，強(qiáng)制線程化之后，強(qiáng)制設(shè)定IRQF_ONESHOT可以保證threaded handler是不會(huì)重入的。

（d-2）在那些被強(qiáng)制線程化的中斷線程中，disable bottom half的處理。這是因?yàn)樵谂f的中斷處理機(jī)制中，botton half是不可能搶占top half的執(zhí)行，強(qiáng)制線程化之后，應(yīng)該保持這一點(diǎn)。

（3）創(chuàng)建interrupt線程。代碼如下：

if (new->thread_fn && !nested) {
    struct task_struct *t;
    static const struct sched_param param = {
        .sched_priority = MAX_USER_RT_PRIO/2,
    };

    t = kthread_create(irq_thread, new, "irq/%d-%s", irq,－－－－－－－－－－－－－－－－－－（a）
               new->name);

    sched_setscheduler_nocheck(t, SCHED_FIFO, ?m);

    get_task_struct(t);－－－－－－－－－－－－－－－－－－－－－－－－－－－（b）
    new->thread = t;

    set_bit(IRQTF_AFFINITY, &new->thread_flags);－－－－－－－－－－－－－－－（c）
}

if (!alloc_cpumask_var(&mask, GFP_KERNEL)) {－－－－－－－－－－－－－－－－（d）
    ret = -ENOMEM;
    goto out_thread;
}
if (desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)－－－－－－－－－－－（e）
    new->flags &= ~IRQF_ONESHOT;

（a）調(diào)用kthread_create來(lái)創(chuàng)建一個(gè)內(nèi)核線程，并調(diào)用sched_setscheduler_nocheck來(lái)設(shè)定這個(gè)中斷線程的調(diào)度策略和調(diào)度優(yōu)先級(jí)。這些是和進(jìn)程管理相關(guān)的內(nèi)容，我們留到下一個(gè)專(zhuān)題再詳細(xì)描述吧。

（b）調(diào)用get_task_struct可以為這個(gè)threaded handler的task struct增加一次reference count，這樣，即便是該thread異常退出也可以保證它的task struct不會(huì)被釋放掉。這可以保證中斷系統(tǒng)的代碼不會(huì)訪問(wèn)到一些被釋放的內(nèi)存。irqaction的thread 成員被設(shè)定為剛剛創(chuàng)建的task，這樣，primary handler就知道喚醒哪一個(gè)中斷線程了。

（c）設(shè)定IRQTF_AFFINITY的標(biāo)志，在threaded handler中會(huì)檢查該標(biāo)志并進(jìn)行IRQ affinity的設(shè)定。

（d）分配一個(gè)cpu mask的變量的內(nèi)存，后面會(huì)使用到

（e）驅(qū)動(dòng)工程師是撰寫(xiě)具體外設(shè)驅(qū)動(dòng)的，他/她未必會(huì)了解到底層的一些具體的interrupt controller的信息。有些interrupt controller（例如MSI based interrupt）本質(zhì)上就是就是one shot的（通過(guò)IRQCHIP_ONESHOT_SAFE標(biāo)記），因此驅(qū)動(dòng)工程師設(shè)定的IRQF_ONESHOT其實(shí)是畫(huà)蛇添足，因此可以去掉。

（4）共享中斷的檢查。代碼如下：

old_ptr = &desc->action;
old = *old_ptr;

if (old) {
    if (!((old->flags & new->flags) & IRQF_SHARED) ||－－－－－－－－－－－－－－－－－（a）
        ((old->flags ^ new->flags) & IRQF_TRIGGER_MASK) ||
        ((old->flags ^ new->flags) & IRQF_ONESHOT))
        goto mismatch;

    /* All handlers must agree on per-cpuness */
    if ((old->flags & IRQF_PERCPU) != (new->flags & IRQF_PERCPU))
        goto mismatch;

    /* add new interrupt at end of irq queue */
    do {－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－（b）
        thread_mask |= old->thread_mask;
        old_ptr = &old->next;
        old = *old_ptr;
    } while (old);
    shared = 1;
}

（a）old指向注冊(cè)之前的action list，如果不是NULL，那么說(shuō)明需要共享interrupt line。但是如果要共享，需要每一個(gè)irqaction都同意共享（IRQF_SHARED），每一個(gè)irqaction的觸發(fā)方式相同（都是level trigger或者都是edge trigger），相同的oneshot類(lèi)型的中斷（都是one shot或者都不是），per cpu類(lèi)型的相同中斷（都是per cpu的中斷或者都不是）。

（b）將該irqaction掛入隊(duì)列的尾部。

（5）thread mask的設(shè)定。代碼如下：

if (new->flags & IRQF_ONESHOT) {
        if (thread_mask == ~0UL) {－－－－－－－－－－－－－－－－－－－－－－－－（a）
            ret = -EBUSY;
            goto out_mask;
        }
        new->thread_mask = 1 << ffz(thread_mask);

    } else if (new->handler == irq_default_primary_handler &&
           !(desc->irq_data.chip->flags & IRQCHIP_ONESHOT_SAFE)) {－－－－－－－－（b）
        ret = -EINVAL;
        goto out_mask;
    }

對(duì)于one shot類(lèi)型的中斷，我們還需要設(shè)定thread mask。如果一個(gè)one shot類(lèi)型的中斷只有一個(gè)threaded handler（不支持共享），那么事情就很簡(jiǎn)單（臨時(shí)變量thread_mask等于0），該irqaction的thread_mask成員總是使用第一個(gè)bit來(lái)標(biāo)識(shí)該irqaction。但是，如果支持共享的話，事情變得有點(diǎn)復(fù)雜。我們假設(shè)這個(gè)one shot類(lèi)型的IRQ上有A，B和C三個(gè)irqaction，那么A，B和C三個(gè)irqaction的thread_mask成員會(huì)有不同的bit來(lái)標(biāo)識(shí)自己。例如A的thread_mask成員是0x01，B的是0x02，C的是0x04，如果有更多共享的irqaction（必須是oneshot類(lèi)型），那么其thread_mask成員會(huì)依次設(shè)定為0x08，0x10……

（a）在上面“共享中斷的檢查”這個(gè)section中，thread_mask變量保存了所有的屬于該interrupt line的thread_mask，這時(shí)候，如果thread_mask變量如果是全1，那么說(shuō)明irqaction list上已經(jīng)有了太多的irq action（大于32或者64，和具體系統(tǒng)和編譯器相關(guān)）。如果沒(méi)有滿，那么通過(guò)ffz函數(shù)找到第一個(gè)為0的bit作為該irq action的thread bit mask。

（b）irq_default_primary_handler的代碼如下：

static irqreturn_t irq_default_primary_handler(int irq, void *dev_id)
{
    return IRQ_WAKE_THREAD;
}

代碼非常的簡(jiǎn)單，返回IRQ_WAKE_THREAD，讓kernel喚醒threaded handler就OK了。使用irq_default_primary_handler雖然簡(jiǎn)單，但是有一個(gè)風(fēng)險(xiǎn)：如果是電平觸發(fā)的中斷，我們需要操作外設(shè)的寄存器才可以讓那個(gè)asserted的電平信號(hào)消失，否則它會(huì)一直持續(xù)。一般，我們都是直接在primary中操作外設(shè)寄存器（slow bus類(lèi)型的interrupt controller不行），盡早的clear interrupt，但是，對(duì)于irq_default_primary_handler，它僅僅是wakeup了threaded interrupt handler，并沒(méi)有clear interrupt，這樣，執(zhí)行完了primary handler，外設(shè)中斷仍然是asserted，一旦打開(kāi)CPU中斷，立刻觸發(fā)下一次的中斷，然后不斷的循環(huán)。因此，如果注冊(cè)中斷的時(shí)候沒(méi)有指定primary interrupt handler，并且沒(méi)有設(shè)定IRQF_ONESHOT，那么系統(tǒng)是會(huì)報(bào)錯(cuò)的。當(dāng)然，有一種情況可以豁免，當(dāng)?shù)讓拥膇rq chip是one shot safe的（IRQCHIP_ONESHOT_SAFE）。

（6）用戶IRQ flag和底層interrupt flag的同步（TODO）

原創(chuàng)文章，轉(zhuǎn)發(fā)請(qǐng)注明出處。蝸窩科技。http://www./linux_kenrel/request_threaded_irq.html

標(biāo)簽: request_threaded_irq

評(píng)論：