lkml.org 
[lkml]   [2006]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: + via-pata-controller-xfer-fixes.patch added to -mm tree
akpm@osdl.org 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@free.fr>
>
>
> 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.

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

\
 
 \ /
  Last update: 2006-06-25 00:39    [from the cache]
©2003-2011 Jasper Spaans