aboutsummaryrefslogtreecommitdiffstats
path: root/arch/x86/Kconfig.debug
diff options
context:
space:
mode:
authorRene Herman <rene.herman@gmail.com>2008-01-30 13:30:05 +0100
committerIngo Molnar <mingo@elte.hu>2008-01-30 13:30:05 +0100
commitb02aae9cf52956dfe1bec73f77f81a3d05d3902b (patch)
treece715a107c853960cc9541377aeae0ff31ac25f7 /arch/x86/Kconfig.debug
parent4c6b8b4d62fb4cb843c32db71e0a8301039908f3 (diff)
downloadkernel_goldelico_gta04-b02aae9cf52956dfe1bec73f77f81a3d05d3902b.zip
kernel_goldelico_gta04-b02aae9cf52956dfe1bec73f77f81a3d05d3902b.tar.gz
kernel_goldelico_gta04-b02aae9cf52956dfe1bec73f77f81a3d05d3902b.tar.bz2
x86: provide a DMI based port 0x80 I/O delay override.
x86: provide a DMI based port 0x80 I/O delay override. Certain (HP) laptops experience trouble from our port 0x80 I/O delay writes. This patch provides for a DMI based switch to the "alternate diagnostic port" 0xed (as used by some BIOSes as well) for these. David P. Reed confirmed that port 0xed works for him and provides a proper delay. The symptoms of _not_ working are a hanging machine, with "hwclock" use being a direct trigger. Earlier versions of this attempted to simply use udelay(2), with the 2 being a value tested to be a nicely conservative upper-bound with help from many on the linux-kernel mailinglist but that approach has two problems. First, pre-loops_per_jiffy calibration (which is post PIT init while some implementations of the PIT are actually one of the historically problematic devices that need the delay) udelay() isn't particularly well-defined. We could initialise loops_per_jiffy conservatively (and based on CPU family so as to not unduly delay old machines) which would sort of work, but... Second, delaying isn't the only effect that a write to port 0x80 has. It's also a PCI posting barrier which some devices may be explicitly or implicitly relying on. Alan Cox did a survey and found evidence that additionally some drivers may be racy on SMP without the bus locking outb. Switching to an inb() makes the timing too unpredictable and as such, this DMI based switch should be the safest approach for now. Any more invasive changes should get more rigid testing first. It's moreover only very few machines with the problem and a DMI based hack seems to fit that situation. This also introduces a command-line parameter "io_delay" to override the DMI based choice again: io_delay=<standard|alternate> where "standard" means using the standard port 0x80 and "alternate" port 0xed. This retains the udelay method as a config (CONFIG_UDELAY_IO_DELAY) and command-line ("io_delay=udelay") choice for testing purposes as well. This does not change the io_delay() in the boot code which is using the same port 0x80 I/O delay but those do not appear to be a problem as David P. Reed reported the problem was already gone after using the udelay version. He moreover reported that booting with "acpi=off" also fixed things and seeing as how ACPI isn't touched until after this DMI based I/O port switch I believe it's safe to leave the ones in the boot code be. The DMI strings from David's HP Pavilion dv9000z are in there already and we need to get/verify the DMI info from other machines with the problem, notably the HP Pavilion dv6000z. This patch is partly based on earlier patches from Pavel Machek and David P. Reed. Signed-off-by: Rene Herman <rene.herman@gmail.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Diffstat (limited to 'arch/x86/Kconfig.debug')
-rw-r--r--arch/x86/Kconfig.debug9
1 files changed, 9 insertions, 0 deletions
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 761ca7b..40aba67 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -112,4 +112,13 @@ config IOMMU_LEAK
Add a simple leak tracer to the IOMMU code. This is useful when you
are debugging a buggy device driver that leaks IOMMU mappings.
+config UDELAY_IO_DELAY
+ bool "Delay I/O through udelay instead of outb"
+ depends on DEBUG_KERNEL
+ help
+ Make inb_p/outb_p use udelay() based delays by default. Please note
+ that udelay() does not have the same bus-level side-effects that
+ the normal outb based delay does meaning this could cause drivers
+ to change behaviour and/or bugs to surface.
+
endmenu