Re: Quick question about libata and hdparm

[Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>]

On Tuesday 21 April 2009 07:32:58 Rogério Brito wrote:
> Hi Alan, Bart and Co.
> 
> On Apr 20 2009, Alan Cox wrote:
> > > DISCLAIMER: I'm not handling this bugreport, this is best
> > > done by pata_pdc202xx_old Maintainer or libata Maintainer.
> > 
> > Be that as it may thanks - thats well spotted and definitely a bug.
> 
> Well, I just compiled the kernel both with libata and with the usual IDE
> drivers.
> 
> Unfortunately, it seems that Bart's patch isn't enough. OTOH, when I use
> the older IDE drive, it seems to work OK, as the attached dmesgs show
> (BTW, you may notice that there's something fishy with X, but that's
> another story).

Incremental patch (a certain theory to verify).
---
 drivers/ata/pata_pdc202xx_old.c |    4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

Index: b/drivers/ata/pata_pdc202xx_old.c
===================================================================
--- a/drivers/ata/pata_pdc202xx_old.c
+++ b/drivers/ata/pata_pdc202xx_old.c
@@ -163,9 +163,11 @@ static void pdc2026x_bmdma_start(struct 
 	else
 		iowrite8(ioread8(clock) & ~sel66, clock);
 
+	/* FIXME: this thrashes internal UDMA timings previously set by
+	   controller on SET FEATURES - XFER MODE command "snooping" */
 	/* The DMA clocks may have been trashed by a reset. FIXME: make conditional
 	   and move to qc_issue ? */
-	pdc202xx_set_dmamode(ap, qc->dev);
+	/* pdc202xx_set_dmamode(ap, qc->dev); */
 
 	/* Cases the state machine will not complete correctly without help */
 	if ((tf->flags & ATA_TFLAG_LBA48) ||  tf->protocol == ATAPI_PROT_DMA) {