On 01/04/2010 01:06 PM, Russell King wrote:
On Mon, Jan 04, 2010 at 01:03:36PM -0500, Jeff Garzik wrote:
On 01/04/2010 12:30 PM, Russell King wrote:
On Mon, Jan 04, 2010 at 12:27:54PM -0500, Jeff Garzik wrote:
On 01/04/2010 12:02 PM, Alan Cox wrote:
(1b) The solution for MMIO controllers is a bit more complex: replace
the dummy AltStatus register read with something else.
If we had any SFF PATA controllers using MMIO. I can't find any. SATA is
different anyway. In fact we probably want to avoid such delays on a pure
SATA controller.
Early SATA controllers are just PATA controllers in disguise. All SFF
controllers want that 400ns delay. The 400ns delay should -not- be
avoided.
Note that ICH5 SATA is SFF, which only offers non-MMIO addressing; the
change I made is running there just fine:
Yes, your change should be fine for all non-MMIO SFF controllers, SATA
or PATA.
The AltStatus read is simply a dummy read, for MMIO controllers, to
ensure the previously-written taskfile registers make it to the
controller before the ndelay() begins execution.
Can we solve the problem by doing a read of the BMDMA status register?
As it is, the command register and alt status registers are in different
BARs on the controller, so reading from BAR 4 instead of 1/3 should have
the same effect?
Correct -- it does not matter which controller register is read, to
ensure the MMIO flush.
Standard MMIO flush / PCI posting rules, nothing unique to PATA at all
really. You can see examples of MMIO flushes all over the tree, such as
the cpw8_f() and cpw32_f() macros in drivers/net/8139cp.c.
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
