hpt366: fix HPT370 DMA timeouts
authorSergei Shtylyov <sshtylyov@ru.mvista.com>
Sat, 18 Apr 2009 15:42:19 +0000 (17:42 +0200)
committerBartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Sat, 18 Apr 2009 15:42:19 +0000 (17:42 +0200)
The big driver change in 2.4.19-rc1 introduced a regression for many HPT370[A]
chips -- DMA stopped to work completely, only causing endless timeouts...

The culprit has been identified (at last!): it turned to be the code resetting
the DMA state machine before each transfer. Stop doing it now as this counter-
measure has clearly caused more harm than good.

This should fix the kernel.org bug #7703.

Signed-off-by: Sergei Shtylyov <sshtylyov@ru.mvista.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
drivers/ide/hpt366.c

index a0eb87f59134141340181afe21c12d615d0a4484..cea1ac222a90bc148aa430ceaf557e595afe7981 100644 (file)
  *   the register setting lists into the table indexed by the clock selected
  * - set the correct hwif->ultra_mask for each individual chip
  * - add Ultra and MW DMA mode filtering for the HPT37[24] based SATA cards
+ * - stop resetting HPT370's state machine before each DMA transfer as that has
+ *   caused more harm than good
  *     Sergei Shtylyov, <sshtylyov@ru.mvista.com> or <source@mvista.com>
  */
 
 #define DRV_NAME "hpt366"
 
 /* various tuning parameters */
-#define HPT_RESET_STATE_ENGINE
+#undef HPT_RESET_STATE_ENGINE
 #undef HPT_DELAY_INTERRUPT
 
 static const char *quirk_drives[] = {