Messages in this thread | | | Date | Sat, 24 Jun 2006 18:36:56 -0400 | From | Jeff Garzik <> | Subject | Re: + 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/
| |