※ 引述《roylee17 (把我id還我阿......)》之銘言：
: ※ 引述《musicguitar ()》之銘言：
: : 想請問.
: : 如果使用一個share的interrupt.也就是除了我自己的裝置會觸發這個中斷
: : 其他裝置也會觸發.
: : (實際上這個是X86裡的IRQ9.ACPI interrupt,我需要知道GPE0 觸發訊號)
=====================================================================
再敘一下問題:
你的裝置跟系統裡的其他裝置會共用 IRQ9.ACPI 這個 interrupt line.
因為是共用, 是否該考慮 mutual exclusive lock 的問題?
: : 我是否需要做spin lock或是semaphore去做lock的動作.
: 需要 lock 與否，是取決你要存取的資料是否共享
: 而不是因為 irq 是不是共用
首先, 共用的現象是存在的, 至少共用了 interrupt-request line
造成 irq-request flag raised.
考慮的問題就是:
1. 如果你的 device 跟 共用那條 request line 的系統裝置 "同時"
都產生中斷請求, 何者會先被處理? 先處理的會不會影響另者不
會被處理或者造成失誤?
2. "同時" 的含義包含在前者發生中斷且已進入 ISR 處理, 但尚未離
開 ISR 程式, 後來者就 "同時" 也已產生中斷請求.
3. 急速連續請求, 也會發生同一裝置在 ISR 處理時 "同時發生" 下
一個請求.
PC 的 ACPI 是可變換/設定 訊號來源線接續 及 產出中斷的 IRQ-n,
系統通常是自動錯開分配, 除非強制共用一個 IRQ-N , PC硬體現在很
便宜, 可以擴充串接幾個 Programmable Interrupt Controller, 很少
像往日透過 I/O bus 共用同一條 interrupt line. 要共用同一條線就
要考慮 edge trigger 還是 level trigger, 這涉及到 "同時" 發生時
能否檢測到兩(多)個中斷請求. 若是分離的請求線, 但使用同一個 IRQ
-n 輸出向量入口, 因不同輸入線容易讀出判斷較不容易混淆.
X86 中斷的機制是 CPU 會接受中斷一定是處於 EI Flag 狀態, 一旦接
受就轉入 DI , 這就是一種防止ISR 再進入(re-entrant)的硬體 lock
機制. 如果是單核單處理機, 最簡單的 software mutual exclusive
lock implementation 就是 DI/EI
就互斥共用鎖定言, ISR 程式在未結束前不做 EI 就是擋住共用或下一
個同時的中斷請求闖進來, 避免造成 shared ISR 用到的 register/
stack/data-memory 引起相互干擾的混亂.
: : 因為我在kernel 2.6.32使用這兩個lock都會出現kernel error(類似kernel bug)的訊息.
: : 我的ISR所做的事是去動作I2C.讀取device的暫存器.
: ^^^^^^^^^^^^^^^^^^
: 除了你的 ISR 外，有其他的 code flow 會存取這個暫存器嗎？
: 另外，ISR 中，不適用 semaphore
: 或是其他需要 process context 的同步機制
ISR 理論上已是 OS Kernel 最底層的工作, 不會再叫用其他程式
頂多就是 set event flag.
: spin lock 應該是沒問題的(需不需要是另外一回事)
: 如果你的 lock 是自己建的，記得初始化
: 如果是 lock 系統中現有的某個 lock，
: 那要檢查一下整個 lock 的使用情況，
: 你有沒有 double lock/unlock
: error message 可以貼上來
: : 另外.我曾在kernel 2.6.29中.semaphore不會出現error.只有spin lock會!
: : 所以我覺得奇怪.ISR中.到底需不需要再做lock的動作.
: : 因為我一lock就當機了!!!所以我現在是把lock都拿掉了!!
: : 不知道會不會出問題...
若請求不夠密集不是太快, 只要不隨意進行 EI 就很難有麻煩.
※ 編輯: ggg12345 來自: 140.115.4.12 (03/04 20:53)
※ 編輯: ggg12345 來自: 140.115.4.12 (03/05 12:39)