一、前言

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

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

1、非搶占式linux內核的實時性

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

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

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

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

該中斷的服務程序執行完畢（在其執行過程中，T3時刻，會喚醒高優先級任務，讓它從sleep狀態進入runable狀態），返回低優先級任務的系統調用現場，這時候並不存在一個搶占點，低優先級任務要完成系統調用之後，在返回用戶空間的時候才出現搶占點。漫長的等待之後，T4時刻，調度器調度高優先級任務執行。有一個術語叫做任務響應時間（Task Response Time）用來描述T3到T4之間的delay。

2、搶占式linux內核的實時性

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

T0到T3的操作都是和上一節的描述一樣的，不同的地方是在T4。對於2.4內核，只有返回用戶空間的時候才有搶占點出現，但是對於搶占式內核而言，即便是從中斷上下文返回內核空間的進程上下文，只要內核代碼不在臨界區內，就可以發生調度，讓最高優先級的任務調度執行。

在非搶占式linux內核中，一個任務的內核態是不可以被其他進程搶占的。這裏並不是說kernel space不可以被搶占，只是說進程通過系統調用陷入到內核的時候，不可以被其他的進程搶占。實際上，中斷上下文當然可以搶占進程上下文（無論是內核態還是用戶態），更進一步，中斷上下文是擁有至高無上的權限，它甚至可以搶占其他的中斷上下文。引入搶占式內核後，系統的平均任務響應時間會縮短，但是，實時性更關註的是：無論在任何的負載情況下，任務響應時間是確定的。因此，更需要關註的是worst-case的任務響應時間。這裏有兩個因素會影響worst case latency：

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

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

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

3、進一步提高linux內核的實時性

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

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

三、request_threaded_irq的接口規格

1、輸入參數描述

輸入參數
描述

irq
要註冊handler的那個IRQ number。這裏要註冊的handler包括兩個，一個是傳統意義的中斷handler，我們稱之primary handler，另外一個是threaded interrupt handler

handler
primary handler。需要註意的是primary handler和threaded interrupt handler不能同時為空，否則會出錯

thread_fn
threaded interrupt handler。如果該參數不是NULL，那麽系統會創建一個kernel thread，調用的function就是thread_fn

irqflags
參見本章第三節

devname

dev_id
參見第四章，第一節中的描述。

2、輸出參數描述

0表示成功執行，負數表示各種錯誤原因。

3、Interrupt type flags

flag定義
描述

IRQF_TRIGGER_XXX
描述該interrupt line觸發類型的flag

IRQF_DISABLED
首先要說明的是這是一個廢棄的flag，在新的內核中，該flag沒有任何的作用了。具體可以參考：Disabling IRQF_DISABLED
舊的內核（2.6.35版本之前）認為有兩種interrupt handler：slow handler和fast handle。在request irq的時候，對於fast handler，需要傳遞IRQF_DISABLED的參數，確保其中斷處理過程中是關閉CPU的中斷，因為是fast handler，執行很快，即便是關閉CPU中斷不會影響系統的性能。但是，並不是每一種外設中斷的handler都是那麽快（例如磁盤），因此就有 slow handler的概念，說明其在中斷處理過程中會耗時比較長。對於這種情況，在執行interrupt handler的時候不能關閉CPU中斷，否則對系統的performance會有影響。
新的內核已經不區分slow handler和fast handle，都是fast handler，都是需要關閉CPU中斷的，那些需要後續處理的內容推到threaded interrupt handler中去執行。

IRQF_SHARED

這是flag用來描述一個interrupt line是否允許在多個設備中共享。如果中斷控制器可以支持足夠多的interrupt source，那麽在兩個外設間共享一個interrupt request line是不推薦的，畢竟有一些額外的開銷（發生中斷的時候要逐個詢問是不是你的中斷，軟件上就是遍歷action list），因此外設的irq handler中最好是一開始就啟動判斷，看看是否是自己的中斷，如果不是，返回IRQ_NONE,表示這個中斷不歸我管。 早期PC時代，使用8259中斷控制器，級聯的8259最多支持15個外部中斷，但是PC外設那麽多，因此需要irq share。現在，ARM平臺上的系統設計很少會采用外設共享IRQ方式，畢竟一般ARM SOC提供的有中斷功能的GPIO非常的多，足夠用的。 當然，如果確實需要兩個外設共享IRQ，那也只能如此設計了。對於HW，中斷控制器的一個interrupt source的引腳要接到兩個外設的interrupt request line上，怎麽接？直接連接可以嗎？當然不行，對於低電平觸發的情況，我們可以考慮用與門連接中斷控制器和外設。

IRQF_PROBE_SHARED
IRQF_SHARED用來表示該interrupt action descriptor是允許和其他device共享一個interrupt line（IRQ number），但是實際上是否能夠share還是需要其他條件：例如觸發方式必須相同。有些驅動程序可能有這樣的調用場景：我只是想scan一個irq table，看看哪一個是OK的，這時候，如果即便是不能和其他的驅動程序share這個interrupt line，我也沒有關系，我就是想scan看看情況。這時候，caller其實可以預見sharing mismatche的發生，因此，不需要內核打印“Flags mismatch irq……“這樣冗余的信息

IRQF_PERCPU
在SMP的架構下，中斷有兩種mode，一種中斷是在所有processor之間共享的，也就是global的，一旦中斷產生，interrupt controller可以把這個中斷送達多個處理器。當然，在具體實現的時候不會同時將中斷送達多個CPU，一般是軟件和硬件協同處理，將中斷送達一個CPU處理。但是一段時間內產生的中斷可以平均（或者按照既定的策略）分配到一組CPU上。這種interrupt mode下，interrupt controller針對該中斷的operational register是global的，所有的CPU看到的都是一套寄存器，一旦一個CPU ack了該中斷，那麽其他的CPU看到的該interupt source的狀態也是已經ack的狀態。
和global對應的就是per cpu interrupt了，對於這種interrupt，不是processor之間共享的，而是特定屬於一個CPU的。例如GIC中interrupt ID等於30的中斷就是per cpu的（這個中斷event被用於各個CPU的local timer），這個中斷號雖然只有一個，但是，實際上控制該interrupt ID的寄存器有n組（如果系統中有n個processor），每個CPU看到的是不同的控制寄存器。在具體實現中，這些寄存器組有兩種形態，一種是banked，所有CPU操作同樣的寄存器地址，硬件系統會根據訪問的cpu定向到不同的寄存器，另外一種是non banked，也就是說，對於該interrupt source，每個cpu都有自己獨特的訪問地址。

IRQF_NOBALANCING
這也是和multi-processor相關的一個flag。對於那些可以在多個CPU之間共享的中斷，具體送達哪一個processor是有策略的，我們可以在多個CPU之間進行平衡。如果你不想讓你的中斷參與到irq balancing的過程中那麽就設定這個flag

IRQF_IRQPOLL

IRQF_ONESHOT
one shot本身的意思的只有一次的，結合到中斷這個場景，則表示中斷是一次性觸發的，不能嵌套。對於primary handler，當然是不會嵌套，但是對於threaded interrupt handler，我們有兩種選擇，一種是mask該interrupt source，另外一種是unmask該interrupt source。一旦mask住該interrupt source，那麽該interrupt source的中斷在整個threaded interrupt handler處理過程中都是不會再次觸發的，也就是one shot了。這種handler不需要考慮重入問題。
具體是否要設定one shot的flag是和硬件系統有關的，我們舉一個例子，比如電池驅動，電池裏面有一個電量計，是使用HDQ協議進行通信的，電池驅動會註冊一個threaded interrupt handler，在這個handler中，會通過HDQ協議和電量計進行通信。對於這個handler，通過HDQ進行通信是需要一個完整的HDQ交互過程，如果中間被打斷，整個通信過程會出問題，因此，這個handler就必須是one shot的。

IRQF_NO_SUSPEND
這個flag比較好理解，就是說在系統suspend的時候，不用disable這個中斷，如果disable，可能會導致系統不能正常的resume。

IRQF_FORCE_RESUME
在系統resume的過程中，強制必須進行enable的動作，即便是設定了IRQF_NO_SUSPEND這個flag。這是和特定的硬件行為相關的。

IRQF_NO_THREAD
有些low level的interrupt是不能線程化的（例如系統timer的中斷），這個flag就是起這個作用的。另外，有些級聯的interrupt controller對應的IRQ也是不能線程化的（例如secondary GIC對應的IRQ），它的線程化可能會影響一大批附屬於該interrupt controller的外設的中斷響應延遲。

IRQF_EARLY_RESUME

IRQF_TIMER

四、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雖然支持中斷共享，但是它並不會協助解決識別問題，它只會遍歷該IRQ number上註冊的irqaction的callback函數，這樣，雖然只是一個外設產生的中斷，linux kernel還是把所有共享的那些中斷handler都逐個調用執行。為了讓系統的performance不受影響，irqaction的callback函數必須在函數的最開始進行判斷，是否是自己的硬件設備產生了中斷（讀取硬件的寄存器），如果不是，盡快的退出。

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

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

（3）並非系統中所有的IRQ number都可以request，有些中斷描述符被標記為IRQ_NOREQUEST，標識該IRQ number不能被其他的驅動request。一般而言，這些IRQ number有特殊的作用，例如用於級聯的那個IRQ number是不能request。irq_settings_can_request函數就是判斷一個IRQ是否可以被request。

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

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

primary handler
threaded handler
描述

NULL
NULL
函數出錯，返回-EINVAL

設定
設定
正常流程。中斷處理被合理的分配到primary handler和threaded handler中。

設定
NULL
中斷處理都是在primary handler中完成

NULL
設定
這種情況下，系統會幫忙設定一個default的primary handler：irq_default_primary_handler，協助喚醒threaded handler線程

（5）這部分的代碼很簡單，分配struct irqaction，賦值，調用__setup_irq進行實際的註冊過程。這裏要羅嗦幾句的是鎖的操作，在內核中，有很多函數，有的是需要調用者自己加鎖保護的，有些是不需要加鎖保護的。對於這些場景，linux kernel采取了統一的策略：基本函數名字是一樣的，只不過需要調用者自己加鎖保護的那個函數需要增加__的前綴，例如內核有有下面兩個函數：setup_irq和__setup_irq。這裏，我們在setup irq的時候已經調用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函數，因此chip_bus_lock這個函數對大多數的中斷控制器而言是沒有實際意義的。但是，有些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級聯的情況下。為了方便大家理解，我還是給出一個具體的例子吧，具體的HW block請參考下圖：

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

（a）IRQ A的中斷描述符被設定為不能註冊irqaction（不能註冊specific interrupt handler，或者叫中斷服務程序）

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

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

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

我們再看看另外一個interrupt controller級聯的情況：

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

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

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

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

（c）外設對應的中斷描述符設定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的，說明這個中斷描述符應該設定threaded interrupt handler（當然，內核是不會單獨創建一個thread的，它是借著其parent IRQ的interrupt thread執行），否則就會出錯返回。對於primary handler，它應該沒有機會被調用到，當然為了調試，kernel將其設定為irq_nested_primary_handler，以便在調用的時候打印一些信息，讓工程師直到發生了什麽狀況。

（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其實就是將系統中所有可以被線程化的中斷handler全部線程化，即便你在request irq的時候，設定的是primary handler，而不是threaded handler。當然那些不能被線程化的中斷（標註了IRQF_NO_THREAD的中斷，例如系統timer）還是排除在外的。irq_settings_can_thread函數就是判斷一個中斷是否可以被線程化，如果可以的話，則調用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）系統中有一個強制線程化的選項：CONFIG_IRQ_FORCED_THREADING，如果沒有打開該選項，force_irqthreads總是0，因此irq_setup_forced_threading也就沒有什麽作用，直接return了。如果打開了CONFIG_IRQ_FORCED_THREADING，說明系統支持強制線程化，但是具體是否對所有的中斷進行強制線程化處理還是要看命令行參數threadirqs。如果kernel啟動的時候沒有傳入該參數，那麽同樣的，irq_setup_forced_threading也就沒有什麽作用，直接return了。只有bootloader向內核傳入threadirqs這個命令行參數，內核才真正在啟動過程中，進行各個中斷的強制線程化的操作。

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

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

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

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

當然，作為內核的開發者，既然同意將強制線程化這個特性並入linux kernel，相信他們有他們自己的考慮。我猜測這是和一些舊的驅動代碼維護相關的。linux kernel中的中斷子系統的API的修改會引起非常大的震動，因為內核中成千上萬的驅動都是需要調用舊的接口來申請linux kernel中斷子系統的服務，對每一個驅動都進行修改是一個非常耗時的工作，為了讓那些舊的驅動代碼可以運行在新的中斷子系統上，因此，在kernel中，實際上仍然提供了舊的request_irq接口函數，如下：

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了，但是，新的中斷子系統的思路是將中斷處理分成primary handler和threaded handler，而舊的驅動代碼一般是將中斷處理分成top half和bottom half，如何將這部分的不同抹平？linux kernel是這樣處理的（這是我個人的理解，不保證是正確的）：

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

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

（3）創建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）調用kthread_create來創建一個內核線程，並調用sched_setscheduler_nocheck來設定這個中斷線程的調度策略和調度優先級。這些是和進程管理相關的內容，我們留到下一個專題再詳細描述吧。

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

（c）設定IRQTF_AFFINITY的標誌，在threaded handler中會檢查該標誌並進行IRQ affinity的設定。

（d）分配一個cpu mask的變量的內存，後面會使用到

（e）驅動工程師是撰寫具體外設驅動的，他/她未必會了解到底層的一些具體的interrupt controller的信息。有些interrupt controller（例如MSI based interrupt）本質上就是就是one shot的（通過IRQCHIP_ONESHOT_SAFE標記），因此驅動工程師設定的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的觸發方式相同（都是level trigger或者都是edge trigger），相同的oneshot類型的中斷（都是one shot或者都不是），per cpu類型的相同中斷（都是per cpu的中斷或者都不是）。

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

（5）thread mask的設定。代碼如下：

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類型的中斷，我們還需要設定thread mask。如果一個one shot類型的中斷只有一個threaded handler（不支持共享），那麽事情就很簡單（臨時變量thread_mask等於0），該irqaction的thread_mask成員總是使用第一個bit來標識該irqaction。但是，如果支持共享的話，事情變得有點復雜。我們假設這個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成員會依次設定為0x08，0x10……

（a）在上面“共享中斷的檢查”這個section中，thread_mask變量保存了所有的屬於該interrupt line的thread_mask，這時候，如果thread_mask變量如果是全1，那麽說明irqaction list上已經有了太多的irq action（大於32或者64，和具體系統和編譯器相關）。如果沒有滿，那麽通過ffz函數找到第一個為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雖然簡單，但是有一個風險：如果是電平觸發的中斷，我們需要操作外設的寄存器才可以讓那個asserted的電平信號消失，否則它會一直持續。一般，我們都是直接在primary中操作外設寄存器（slow bus類型的interrupt controller不行），盡早的clear interrupt，但是，對於irq_default_primary_handler，它僅僅是wakeup了threaded interrupt handler，並沒有clear interrupt，這樣，執行完了primary handler，外設中斷仍然是asserted，一旦打開CPU中斷，立刻觸發下一次的中斷，然後不斷的循環。因此，如果註冊中斷的時候沒有指定primary interrupt handler，並且沒有設定IRQF_ONESHOT，那麽系統是會報錯的。當然，有一種情況可以豁免，當底層的irq chip是one shot safe的（IRQCHIP_ONESHOT_SAFE）。

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

原創文章，轉發請註明出處。蝸窩科技。http://www.wowotech.net/linux_kenrel/request_threaded_irq.html

Linux kernel中斷子系統之（五）：驅動申請中斷API