※ 引述《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)