> To which old-IDE do you refer? :) This specific area of functionality > varies from 2.4.x to 2.6.x. Old-Old-IDE even picks and chooses whether > or not to wait depending on protocol (PIO or not), something that has > changed in the more recent old-IDE code. Which is irrelevant to the discussion. > It's not muddy, the rules for MMIO are quite clear, as is kernel > practice for drivers driving MMIO-based hardware. The IDE layer shows the SI3112 doesn't have this problem so we shouldn't cripple it with Jeff paranoia. > Any PATA MMIO controller on a PCI card -- pata_pdc2027x comes to mind -- > must handle this situation, because the PCI posting situation varies > depending on where you slot in your PCI card. That's not something a > controller can really handle internally. Of course it can. The controller can implement a 400nS delay internally if it gets a back to back command write and a read of a tf register state. Nobody implementing an MMIO controller is going to not do that because avoiding an artificial posting stall is a big performance win. Compared to the big chunk of logic they all have for fifo draining interlocks its nothing. Without that its going to be cheaper to operate PIO cycles not MMIO cycles ! My SI controllers at least don't seem to need any kind of posting protection in MMIO mode. They seem to be handling it all internally somehow - Try rdtsc/write to cmd/rdtsc/read status/rdtsc Alan -- 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
