Re: [PATCH 1/3] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33cards

From: Jeff Garzik
Date: Sat Feb 13 2010 - 17:39:50 EST


On 02/13/2010 08:35 AM, Bartlomiej Zolnierkiewicz wrote:
From: Bartlomiej Zolnierkiewicz<bzolnier@xxxxxxxxx>
Subject: [PATCH] pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards

On Monday 04 January 2010 02:30:24 pm Russell King wrote:

Found the problem - getting rid of the read of the alt status register
after the command has been written fixes the UDMA CRC errors on write:

@@ -676,7 +676,8 @@ void ata_sff_exec_command(struct ata_port *ap, const struct
ata_taskfile *tf)
DPRINTK("ata%u: cmd 0x%X\n", ap->print_id, tf->command);

iowrite8(tf->command, ap->ioaddr.command_addr);
- ata_sff_pause(ap);
+ ndelay(400);
+// ata_sff_pause(ap);
}
EXPORT_SYMBOL_GPL(ata_sff_exec_command);


This rather makes sense. The PDC20247 handles the UDMA part of the
protocol. It has no way to tell the PDC20246 to wait while it suspends
UDMA, so that a normal register access can take place - the 246 ploughs
on with the register access without any regard to the state of the 247.

If the drive immediately starts the UDMA protocol after a write to the
command register (as it probably will for the DMA WRITE command), then
we'll be accessing the taskfile in the middle of the UDMA setup, which
can't be good. It's certainly a violation of the ATA specs.

Fix it by adding custom ->sff_exec_command method for UDMA33 chipsets.

Debugged-by: Russell King<rmk@xxxxxxxxxxxxxxxx>
Signed-off-by: Bartlomiej Zolnierkiewicz<bzolnier@xxxxxxxxx>
---
drivers/ata/pata_pdc202xx_old.c | 13 ++++++++++++-
1 file changed, 12 insertions(+), 1 deletion(-)

applied


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/