summaryrefslogtreecommitdiffstats
path: root/include/linux/libata.h
diff options
context:
space:
mode:
authorTejun Heo <tj@kernel.org>2010-01-19 10:49:19 +0900
committerJeff Garzik <jgarzik@redhat.com>2010-03-01 14:58:44 -0500
commit27943620cbd960f710a385ff4a538e14ed3f1922 (patch)
treefae161f49c10fa488f7a5891085961f284021544 /include/linux/libata.h
parentd88ec2e5c13261cf317b46832a7de216f6d06537 (diff)
downloadlinux-27943620cbd960f710a385ff4a538e14ed3f1922.tar.gz
linux-27943620cbd960f710a385ff4a538e14ed3f1922.tar.bz2
linux-27943620cbd960f710a385ff4a538e14ed3f1922.zip
libata: implement spurious irq handling for SFF and apply it to piix
Traditional IDE interface sucks in that it doesn't have a reliable IRQ pending bit, so if the controller raises IRQ while the driver is expecting it not to, the IRQ won't be cleared and eventually the IRQ line will be killed by interrupt subsystem. Some controllers have non-standard mechanism to indicate IRQ pending so that this condition can be detected and worked around. This patch adds an optional operation ->sff_irq_check() which will be called for each port from the ata_sff_interrupt() if an unexpected interrupt is received. If the operation returns %true, ->sff_check_status() and ->sff_irq_clear() will be cleared for the port. Note that this doesn't mark the interrupt as handled so it won't prevent IRQ subsystem from killing the IRQ if this mechanism fails to clear the spurious IRQ. This patch also implements ->sff_irq_check() for ata_piix. Note that this adds slight overhead to shared IRQ operation as IRQs which are destined for other controllers will trigger extra register accesses to check whether IDE interrupt is pending but this solves rare screaming IRQ cases and for some curious reason also helps weird BIOS related glitch on Samsung n130 as reported in bko#14314. http://bugzilla.kernel.org/show_bug.cgi?id=14314 * piix_base_ops dropped as suggested by Sergei. * Spurious IRQ detection doesn't kick in anymore if polling qc is in progress. This provides less protection but some controllers have possible data corruption issues if the wrong register is accessed while a command is in progress. Signed-off-by: Tejun Heo <tj@kernel.org> Reported-by: Johannes Stezenbach <js@sig21.net> Reported-by: Hans Werner <hwerner4@gmx.de> Cc: Alan Cox <alan@lxorguk.ukuu.org.uk> Cc: Sergei Shtylyov <sshtylyov@ru.mvista.com> Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Diffstat (limited to 'include/linux/libata.h')
-rw-r--r--include/linux/libata.h1
1 files changed, 1 insertions, 0 deletions
diff --git a/include/linux/libata.h b/include/linux/libata.h
index 73112250862c..5fb888462359 100644
--- a/include/linux/libata.h
+++ b/include/linux/libata.h
@@ -857,6 +857,7 @@ struct ata_port_operations {
unsigned int (*sff_data_xfer)(struct ata_device *dev,
unsigned char *buf, unsigned int buflen, int rw);
u8 (*sff_irq_on)(struct ata_port *);
+ bool (*sff_irq_check)(struct ata_port *);
void (*sff_irq_clear)(struct ata_port *);
void (*bmdma_setup)(struct ata_queued_cmd *qc);