On 01/05/2010 06:25 AM, Alan Cox wrote:
Indeed, which is why I suspect that a global change to handle this
controller may not be a good idea. Overriding sff_exec_command for this
driver to not do the altstatus read (just wait 600ns, maybe) might be
the best solution for now.
Old IDE does 400nS and no read. We know that works. At least for all the
standard PATA controllers. Thats an incredibly strong argument for doing
command issue that way for non MMIO controllers.
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.
The MMIO case is muddy and probably simply does not matter because no
sane hardware implementation is not going to handle it internally.
It's not muddy, the rules for MMIO are quite clear, as is kernel
practice for drivers driving MMIO-based hardware.
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.
Jeff
--
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
