Alan wrote:
The IRQ delivery is async to the I/O so this makes a lot of sense for all
cases.
I don't think that's true unless the controller is doing something funky
as in SET XFERMODE. Can you enlighten me?
I'm with Tejun on this one. The posted patch simply adds extra bus transactions
to poll for a late BUSY bit. Yes, some devices are late posting the BUSY bit,
but the vast majority are not.
For other cases where this is needed, I'm not so sure.
Alan, I confess that I really don't understand this example (below).
Can you try again, with something concrete enough for a rusty old
IDE hacker to understand?
Thanks
This leads to suprising sequences like
device raises IRQ
kernel blocks device IRQ at chip
kernel reads to post the block
kernel does other stuff
IRQ message finally arrives
IRQ taken
--
Mark Lord
Real-Time Remedies Inc.
mlord@xxxxxxxxx
-
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
