Re: + via-pata-controller-xfer-fixes.patch added to -mm tree

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



[email protected] 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 <[email protected]>


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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux