一、前言

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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）對于那些需要共享的中斷，在request irq的時候需要給出dev id，否則會出錯退出。為何對于IRQF_SHARED的中斷必須要給出dev id呢？實際上，在共享的情況下，一個IRQ number對應若干個irqaction，當操作irqaction的時候，僅僅給出IRQ number就不是非常的足夠了，這時候，需要一個ID表示具體的irqaction，這里就是dev_id的作用了。我們舉一個例子：

void free_irq(unsigned int irq, void *dev_id)

當釋放一個IRQ資源的時候，不但要給出IRQ number，還要給出device ID。只有這樣，才能精準的把要釋放的那個irqaction 從irq action list上移除。dev_id在中斷處理中有沒有作用呢？我們來看看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雖然支持中斷共享，但是它并不會協(xié)助解決識別問題，它只會遍歷該IRQ number上注冊的irqaction的callback函數(shù)，這樣，雖然只是一個外設(shè)產(chǎn)生的中斷，linux kernel還是把所有共享的那些中斷handler都逐個調(diào)用執(zhí)行。為了讓系統(tǒng)的performance不受影響，irqaction的callback函數(shù)必須在函數(shù)的最開始進行判斷，是否是自己的硬件設(shè)備產(chǎn)生了中斷（讀取硬件的寄存器），如果不是，盡快的退出。

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

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

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

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

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

（5）這部分的代碼很簡單，分配struct irqaction，賦值，調(diào)用__setup_irq進行實際的注冊過程。這里要羅嗦幾句的是鎖的操作，在內(nèi)核中，有很多函數(shù)，有的是需要調(diào)用者自己加鎖保護的，有些是不需要加鎖保護的。對于這些場景，linux kernel采取了統(tǒng)一的策略：基本函數(shù)名字是一樣的，只不過需要調(diào)用者自己加鎖保護的那個函數(shù)需要增加__的前綴，例如內(nèi)核有有下面兩個函數(shù)：setup_irq和__setup_irq。這里，我們在setup irq的時候已經(jīng)調(diào)用chip_bus_lock進行保護，因此使用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并沒有定義irq_bus_lock這個callback函數(shù)，因此chip_bus_lock這個函數(shù)對大多數(shù)的中斷控制器而言是沒有實際意義的。但是，有些interrupt controller是連接到慢速總線上的，例如一個i2c接口的IO expander芯片（這種芯片往往也提供若干有中斷功能的GPIO，因此也是一個interrupt controller），在訪問這種interrupt controller的時候需要lock住那個慢速bus（只能有一個client在使用I2C bus）。

2、注冊irqaction

（1）nested IRQ的處理代碼

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

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

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

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

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

需要注意的是，對root GIC和Secondary GIC寄存器的訪問非?？?，因此ack、mask、EOI等操作也非常快。

我們再看看另外一個interrupt controller級聯(lián)的情況：

IO expander HW block提供了有中斷功能的GPIO，因此它也是一個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上，因此，這也是一個interrupt controller級聯(lián)的情況，對于這種情況，我們是否可以采用和上面GIC級聯(lián)的處理方式呢？

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

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

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

（c）外設(shè)對應的中斷描述符設(shè)定IRQ_NESTED_THREAD的flag，表明這是一個nested IRQ。nested IRQ沒有highlevel irq-events handler，也沒有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 { 
……
    }

……

}

如果一個中斷描述符是nested thread type的，說明這個中斷描述符應該設(shè)定threaded interrupt handler（當然，內(nèi)核是不會單獨創(chuàng)建一個thread的，它是借著其parent IRQ的interrupt thread執(zhí)行），否則就會出錯返回。對于primary handler，它應該沒有機會被調(diào)用到，當然為了調(diào)試，kernel將其設(shè)定為irq_nested_primary_handler，以便在調(diào)用的時候打印一些信息，讓工程師直到發(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其實就是將系統(tǒng)中所有可以被線程化的中斷handler全部線程化，即便你在request irq的時候，設(shè)定的是primary handler，而不是threaded handler。當然那些不能被線程化的中斷（標注了IRQF_NO_THREAD的中斷，例如系統(tǒng)timer）還是排除在外的。irq_settings_can_thread函數(shù)就是判斷一個中斷是否可以被線程化，如果可以的話，則調(diào)用irq_setup_forced_threading在set irq的時候強制進行線程化。具體代碼如下：

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)中有一個強制線程化的選項：CONFIG_IRQ_FORCED_THREADING，如果沒有打開該選項，force_irqthreads總是0，因此irq_setup_forced_threading也就沒有什么作用，直接return了。如果打開了CONFIG_IRQ_FORCED_THREADING，說明系統(tǒng)支持強制線程化，但是具體是否對所有的中斷進行強制線程化處理還是要看命令行參數(shù)threadirqs。如果kernel啟動的時候沒有傳入該參數(shù)，那么同樣的，irq_setup_forced_threading也就沒有什么作用，直接return了。只有bootloader向內(nèi)核傳入threadirqs這個命令行參數(shù)，內(nèi)核才真正在啟動過程中，進行各個中斷的強制線程化的操作。

（b）看到IRQF_NO_THREAD選項你可能會奇怪，前面irq_settings_can_thread函數(shù)不是檢查過了嗎？為何還要重復檢查？其實一個中斷是否可以進行線程化可以從兩個層面看：一個是從底層看，也就是從中斷描述符、從實際的中斷硬件拓撲等方面看。另外一個是從中斷子系統(tǒng)的用戶層面看，也就是各個外設(shè)在注冊自己的handler的時候是否想進行線程化處理。所有的IRQF_XXX都是從用戶層面看的flag，因此如果用戶通過IRQF_NO_THREAD這個flag告知kernel，該interrupt不能被線程化，那么強制線程化的機制還是尊重用戶的選擇的。

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

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

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

當然，作為內(nèi)核的開發(fā)者，既然同意將強制線程化這個特性并入linux kernel，相信他們有他們自己的考慮。我猜測這是和一些舊的驅(qū)動代碼維護相關(guān)的。linux kernel中的中斷子系統(tǒng)的API的修改會引起非常大的震動，因為內(nèi)核中成千上萬的驅(qū)動都是需要調(diào)用舊的接口來申請linux kernel中斷子系統(tǒng)的服務(wù)，對每一個驅(qū)動都進行修改是一個非常耗時的工作，為了讓那些舊的驅(qū)動代碼可以運行在新的中斷子系統(tǒng)上，因此，在kernel中，實際上仍然提供了舊的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ū)動代碼一般是將中斷處理分成top half和bottom half，如何將這部分的不同抹平？linux kernel是這樣處理的（這是我個人的理解，不保證是正確的）：

（d-1）內(nèi)核為那些被強制線程化的中斷handler設(shè)定了IRQF_ONESHOT的標識。這是因為在舊的中斷處理機制中，top half是不可重入的，強制線程化之后，強制設(shè)定IRQF_ONESHOT可以保證threaded handler是不會重入的。

（d-2）在那些被強制線程化的中斷線程中，disable bottom half的處理。這是因為在舊的中斷處理機制中，botton half是不可能搶占top half的執(zhí)行，強制線程化之后，應該保持這一點。

（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來創(chuàng)建一個內(nèi)核線程，并調(diào)用sched_setscheduler_nocheck來設(shè)定這個中斷線程的調(diào)度策略和調(diào)度優(yōu)先級。這些是和進程管理相關(guān)的內(nèi)容，我們留到下一個專題再詳細描述吧。

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

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

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

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

（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指向注冊之前的action list，如果不是NULL，那么說明需要共享interrupt line。但是如果要共享，需要每一個irqaction都同意共享（IRQF_SHARED），每一個irqaction的觸發(fā)方式相同（都是level trigger或者都是edge trigger），相同的oneshot類型的中斷（都是one shot或者都不是），per cpu類型的相同中斷（都是per cpu的中斷或者都不是）。

（b）將該irqaction掛入隊列的尾部。

（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;
    }

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

（a）在上面“共享中斷的檢查”這個section中，thread_mask變量保存了所有的屬于該interrupt line的thread_mask，這時候，如果thread_mask變量如果是全1，那么說明irqaction list上已經(jīng)有了太多的irq action（大于32或者64，和具體系統(tǒng)和編譯器相關(guān)）。如果沒有滿，那么通過ffz函數(shù)找到第一個為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;
}

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

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

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

標簽: request_threaded_irq

評論：