今天在跟marvell溝通問題的時候，覺得有些地方的代碼看得不夠仔細，于是細看了一下。發(fā)現(xiàn)了幾個請求中斷的函數(shù)。

request_threaded_irq，這個函數(shù)在內(nèi)核中有注釋，參數(shù)有好多，大概參數(shù)有handler，這是要指定的中斷處理函數(shù)，thread_fn是要在內(nèi)核線程中調(diào)用的函數(shù)，還有申請中斷的flag,有SHARED共享，共享時dev_id不能為空，因為要在釋放irq時區(qū)別共享的中斷，這個dev_id一般為某個info，ONESHOT（這個線程函數(shù)thread_fn執(zhí)行前關閉這個中斷）。

當handler為空時，使用默認的處理，看到代碼里申請內(nèi)核線程方式的中斷的時候直接把handler置為NULL，中斷發(fā)生應該是直接把thread_fn扔到內(nèi)核線程中讓它去調(diào)用，申請時用了ONESHOT，也就是調(diào)用thread_fn時關閉了這個中斷。這種扔到內(nèi)核線程的方法其實很不錯，放到了下半部去處理。讓我想起了前段時候給marvell提的問題，看到他們在中斷處理中用了mutex_lock互斥鎖，當時別人也沒有仔細看，說這個不行，讓我提個問題，結果marvell的工程師說這是在下半部里面，才發(fā)現(xiàn)，啊，確實是在下半部里，大家都傻B了。

再看看request_irq,原來這個函數(shù)是對request_thread_irq的封裝，它給request_thread_irq的thread_fn參數(shù)傳進了一個NULL，也就是只申請中斷處理函數(shù)，不要thread_fn，看來這樣確實有點合適啊，哈哈。

扯來扯去，扯了一大篇了，哈哈。

今天弄高通8的問題，rpc啊，弄得不知道它用rpc傳了些啥數(shù)據(jù)，蛋疼。。。

對了，今天早上去的時候還想弄弄那個觸摸屏按鍵的長按問題，本來前段時間把那個驅(qū)動的代碼基本重寫了一遍，后來發(fā)現(xiàn)還是沒有實現(xiàn)這個功能，今天早上又突發(fā)奇想，在evkeybit上或了一個EV_REP，想試試行不行，沒找到手機，所以就沒有試，哈哈。不過這個功能也不是特別需要吧。

總結

以上是生活随笔為你收集整理的request_threaded_irq()的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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