hpt366: fix HPT370 DMA timeouts
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:
parent
aefe647572
commit
c018f1ee5c
|
@ -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[] = {
|
||||
|
|
Loading…
Reference in New Issue