[lkml]   [2006]   [Jun]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: + via-pata-controller-xfer-fixes.patch added to -mm tree 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 to find
    > out what to do about this
    > ------------------------------------------------------
    > Subject: VIA PATA controller xfer fixes
    > From: matthieu castet <>
    > 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

    * 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++) {
    if (OK_STAT((stat = hwif->INB(IDE_STATUS_REG)),
    error = 0;

    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
    ( 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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-25 00:39    [W:0.027 / U:44.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site