Alan Cox wrote: >>> I'd say this is a non-starter. It solves nothing and means PIO in libata >>> is still basically unusable. >> It doesn't solve the problem completely but still helps, FWIW. I was > > Most transfers for PIO are a single 512 byte transfer per command.
Not for disks but, yeah, who uses PIO for disks. >> hoping we could lock only for the last transfer (word). Would it >> complicate ->data_xfer() too much? > > I don't think so. We need to complicate it far more to add 32bit > transfers. We also only have a few ->data_xfer implementations so its > easy to propogate the chance. > > Why do we need the lock on the last word transferred anyway. I'm missing > a detail here ? 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. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-ide" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
