akpm@xxxxxxxx wrote:
The patch titled
VIA PATA controller xfer fixes
has been added to the -mm tree. Its filename is
via-pata-controller-xfer-fixes.patch
See http://www.zip.com.au/~akpm/linux/patches/stuff/added-to-mm.txt to find
out what to do about this
------------------------------------------------------
Subject: VIA PATA controller xfer fixes
From: matthieu castet <castet.matthieu@xxxxxxx>
On via controller(vt8235) and pata via, some ATAPI devices (CDR-6S48) fail
in the xfer mode initialisation. This make the boot slow and the drive
unsuable.
It seems the interrupt for xfer mode is done before the drive is ready, so
the current libata code skip the interrupt. But no new interrupt is done
by the controller, so the xfer mode fails.
A quirk is to wait for 10 us (by step of 1 us) and see if the device
becomes ready in the case of SETFEATURES_XFER feature. The problem seems
pata_via only, so the quirk is put in the pata_via interrupt handler as
Tejun Heo request.
It won't affect working devices, as we don't wait if the device is already
ready. It will adds an extra ata_altstatus in order to avoid to duplicate
ata_host_intr, but only in the case of SETFEATURES_XFER (with should happen
only few times).
Sorry for the lack of changelog in my previous mail, I tought the old
changelog + move it in pata via interrupt was enought. And sorry again, I
sent you a bad patch (I forgot a quitl refresh).
Data point #1:
Here I quote from drivers/ide generic code ide_config_drive_speed() in
ide-iops.c:
/*
* Allow status to settle, then read it again.
* A few rare drives vastly violate the 400ns spec here,
* so we'll wait up to 10usec for a "good" status
* rather than expensively fail things immediately.
* This fix courtesy of Matthew Faupel & Niccolo Rigacci.
*/
for (i = 0; i < 10; i++) {
udelay(1);
if (OK_STAT((stat = hwif->INB(IDE_STATUS_REG)),
DRIVE_READY, BUSY_STAT|DRQ_STAT|ERR_STAT)) {
error = 0;
break;
}
}
And there is similar logic in ide_wait_stat(). wait_drive_not_busy() in
ide-taskfile.c waits for up to 1 ms.
Data point #2:
libata was originally based on the "highly correct" (or one version
thereof) programming sequences found in Hale Landis's free ATADRVR
(http://www.ata-atapi.com/). Hale's ATADRVR, which was MS-DOS based and
not threaded or asynchronous at all, did the following after every
command execution (sent taskfile to hardware):
if (device is ATAPI)
sleep(150 ms)
Overall, I've no clue what to do on older PATA hardware, so my
"insightful" suggestions are largely (a) follow drivers/ide code and/or
(b) listen to any old fogies with deep historical knowledge.
-
: 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
