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-ide" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
