summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorSergei Shtylyov <sshtylyov@ru.mvista.com>2009-04-18 17:42:19 +0200
committerGreg Kroah-Hartman <gregkh@suse.de>2009-05-02 10:24:24 -0700
commit877facd0ce77d172f6d54eb5f503c82d8f6d8526 (patch)
tree278639742b47b3b8feb57414fad4119fa67ca2e7
parent561bbe9e42cd6b0d0148ac5d36e07b90c8065fa3 (diff)
downloadlwn-877facd0ce77d172f6d54eb5f503c82d8f6d8526.tar.gz
lwn-877facd0ce77d172f6d54eb5f503c82d8f6d8526.zip
hpt366: fix HPT370 DMA timeouts
upstream commit: c018f1ee5cf81e58b93d9e93a2ee39cad13dc1ac 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> Signed-off-by: Chris Wright <chrisw@sous-sol.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
-rw-r--r--drivers/ide/pci/hpt366.c4
1 files changed, 3 insertions, 1 deletions
diff --git a/drivers/ide/pci/hpt366.c b/drivers/ide/pci/hpt366.c
index c37ab1743819..7e443a33529b 100644
--- a/drivers/ide/pci/hpt366.c
+++ b/drivers/ide/pci/hpt366.c
@@ -114,6 +114,8 @@
* 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>
*/
@@ -134,7 +136,7 @@
#define DRV_NAME "hpt366"
/* various tuning parameters */
-#define HPT_RESET_STATE_ENGINE
+#undef HPT_RESET_STATE_ENGINE
#undef HPT_DELAY_INTERRUPT
#define HPT_SERIALIZE_IO 0