AcoSail/kernel_optimize_test
8
0
Fork 0
forked from luck/tmp_suning_uos_patched
Code Pull Requests Activity

hpt366: fix HPT370 DMA timeouts

Browse Source 
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>
This commit is contained in:
Sergei Shtylyov 2009-04-18 17:42:19 +02:00 committed by Bartlomiej Zolnierkiewicz
parent aefe647572
commit c018f1ee5c
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
drivers/ide/hpt366.c
View File

@ -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>
*/
@ -133,7 +135,7 @@
#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[] = {