• Bartlomiej Zolnierkiewicz's avatar
    pata_pdc202xx_old: fix UDMA mode for Promise UDMA33 cards · a75032e8
    Bartlomiej Zolnierkiewicz authored
    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: default avatarRussell King <rmk@arm.linux.org.uk>
    Signed-off-by: default avatarBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
    Signed-off-by: default avatarJeff Garzik <jgarzik@redhat.com>
    a75032e8
pata_pdc202xx_old.c 9.58 KB