summaryrefslogtreecommitdiffstats
path: root/firmware/ess
diff options
context:
space:
mode:
authorFinn Thain <fthain@telegraphics.com.au>2016-10-10 00:46:52 -0400
committerMartin K. Petersen <martin.petersen@oracle.com>2016-11-08 17:29:48 -0500
commit4822827a69d7cd3bc5a07b7637484ebd2cf88db6 (patch)
treef34e1a764d477da5cd1fdc0bf08bd737e95c9a71 /firmware/ess
parentd4408dd7ecff6ed3561f155923738474c585f31d (diff)
downloadlinux-4822827a69d7cd3bc5a07b7637484ebd2cf88db6.tar.gz
linux-4822827a69d7cd3bc5a07b7637484ebd2cf88db6.tar.bz2
linux-4822827a69d7cd3bc5a07b7637484ebd2cf88db6.zip
scsi: ncr5380: Increase register polling limit
If NCR5380_poll_politely() is called under irq lock, the polling time limit is clamped to avoid a spike in interrupt latency. When not under irq lock, the same polling time limit acts as the worst case delay between schedule() calls. During PDMA (under irq lock) I've found that the 10 ms time limit is sometimes too short, and leads to the error message, sd 0:0:0:0: [sda] tag#1 macscsi_pread: !REQ and !ACK This particular target identifies itself as a QUANTUM DAYTONA514S. It seems to be slower to assert ACK than the other targets I've tested. This patch solves the problem by increasing the polling timeout. Signed-off-by: Finn Thain <fthain@telegraphics.com.au> Reviewed-by: Hannes Reinecke <hare@suse.com> Tested-by: Ondrej Zary <linux@rainbow-software.org> Tested-by: Michael Schmitz <schmitzmic@gmail.com> Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
Diffstat (limited to 'firmware/ess')
0 files changed, 0 insertions, 0 deletions