Jeff Garzik wrote:
Tejun Heo wrote:
20us delay is not enough for some controllers and they end up not
sending the second H2D FIS to clear SRST resulting in softreset
failure. This problem has been spotted and diagnosed with SATA trace
by JMicron on sata_nv.
This patch makes ata_bus_softreset() use msleep(1) instead of
udelay(20) between SRST set and clear.
Signed-off-by: Tejun Heo <htejun@xxxxxxxxx>
Cc: Justin Tsai <justin@xxxxxxxxxxx>
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index 753b015..007020e 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -2414,15 +2414,15 @@ static unsigned int ata_bus_softreset(st
/* software reset. causes dev0 to be selected */
if (ap->flags & ATA_FLAG_MMIO) {
writeb(ap->ctl, (void __iomem *) ioaddr->ctl_addr);
- udelay(20); /* FIXME: flush */
+ msleep(1); /* FIXME: flush */
writeb(ap->ctl | ATA_SRST, (void __iomem *) ioaddr->ctl_addr);
- udelay(20); /* FIXME: flush */
+ msleep(1); /* FIXME: flush */
writeb(ap->ctl, (void __iomem *) ioaddr->ctl_addr);
} else {
outb(ap->ctl, ioaddr->ctl_addr);
- udelay(10);
+ msleep(1);
outb(ap->ctl | ATA_SRST, ioaddr->ctl_addr);
- udelay(10);
+ msleep(1);
outb(ap->ctl, ioaddr->ctl_addr);
I'm gonna NAK this one. The controller is operating out of spec
(hardware bug) if this is necessary.
The effect of msleep(1) is really msleep(10) or msleep(100) depending on
the length of a timer tick. That's just far too long a length of time
to be asserting SRST, especially for PATA.
I suppose you can create a jmicron_soft_reset() inside ahci.c...
The problem actually has been spotted on sata_nv. It is suggested that
this is dependent on what type of device is attached to the controller.
This problem seems to be caused if the device is slow to ack the first
H2D Register FIS. So, we really don't know which controllers are
affected by this.
How about doing msleep(1) if it's SATA?
--
tejun
-
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
