Alan Cox wrote: >> The problem is that controllers queue IRQ till the end of transfer and >> raise it right after the last transfer completes. If >> WQ-active-ignore-IRQ flag is set at that point && we're not holding the >> lock, the IRQ handler will ignore the IRQ without clearing it, so we get >> nobody-cared right after the last transfer. So, the last transfer and >> clearing of WQ-active-ignore-IRQ flag should be atomic w.r.t. the IRQ >> handler. > > There does seem to be an alternative. In the pio handler we do > > clear_bit(COMPLETION_RUN, ->flags); > xfer bytes > if (test_and_set_bit(COMPLETION_RUN, ->flags) == 0) > run_completion_routine(); > ->active-ignore-irq = 0; > > and in the IRQ case after checking we are not active-ignore-IRQ we > similarly do > > if (test_and_set_bit(COMPLETION_RUN, ->flags) == 0) > run_completion_routine_irq(); > > Now if we are unlucky and the IRQ gets in between the last byte of > transfer and clearing the active ignore IRQ flag we will still run the > completion handler I don't really get this. What happens if the IRQ is shared and the other device raises interrupt while the data transfer is still in progress? What prevents it from running the completion routine? -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
