Commit b02aae9c authored by Rene Herman's avatar Rene Herman Committed by Ingo Molnar
Browse files

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: default avatarRene Herman <rene.herman@gmail.com>
Signed-off-by: default avatarIngo Molnar <mingo@elte.hu>
Signed-off-by: default avatarThomas Gleixner <tglx@linutronix.de>
parent 4c6b8b4d

Documentation/kernel-parameters.txt

+8 −0
Original line number Diff line number Diff line
@@ -794,6 +794,14 @@ and is between 256 and 4096 characters. It is defined in the file 
			for translation below 32 bit and if not available

			then look in the higher range.



	io_delay=	[X86-32,X86-64] I/O delay method

		standard

			Standard port 0x80 delay

		alternate

			Alternate port 0xed delay

		udelay

			Simple two microsecond delay



	io7=		[HW] IO7 for Marvel based alpha systems

			See comment before marvel_specify_io7 in

			arch/alpha/kernel/core_marvel.c.

arch/x86/Kconfig.debug

+9 −0
Original line number Diff line number Diff line
@@ -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

arch/x86/boot/compressed/misc_32.c

+4 −4
Original line number Diff line number Diff line
@@ -276,10 +276,10 @@ static void putstr(const char *s) 
	RM_SCREEN_INFO.orig_y = y;



	pos = (x + cols * y) * 2;	/* Update cursor position */

	outb_p(14, vidport);

	outb_p(0xff & (pos >> 9), vidport+1);

	outb_p(15, vidport);

	outb_p(0xff & (pos >> 1), vidport+1);

	outb(14, vidport);

	outb(0xff & (pos >> 9), vidport+1);

	outb(15, vidport);

	outb(0xff & (pos >> 1), vidport+1);

}



static void* memset(void* s, int c, unsigned n)

arch/x86/boot/compressed/misc_64.c

+4 −4
Original line number Diff line number Diff line
@@ -269,10 +269,10 @@ static void putstr(const char *s) 
	RM_SCREEN_INFO.orig_y = y;



	pos = (x + cols * y) * 2;	/* Update cursor position */

	outb_p(14, vidport);

	outb_p(0xff & (pos >> 9), vidport+1);

	outb_p(15, vidport);

	outb_p(0xff & (pos >> 1), vidport+1);

	outb(14, vidport);

	outb(0xff & (pos >> 9), vidport+1);

	outb(15, vidport);

	outb(0xff & (pos >> 1), vidport+1);

}



static void* memset(void* s, int c, unsigned n)

arch/x86/kernel/Makefile_32

+1 −1
Original line number Diff line number Diff line
@@ -8,7 +8,7 @@ CPPFLAGS_vmlinux.lds += -Ui386 
obj-y	:= process_32.o signal_32.o entry_32.o traps_32.o irq_32.o \

		ptrace_32.o time_32.o ioport_32.o ldt_32.o setup_32.o i8259_32.o sys_i386_32.o \

		pci-dma_32.o i386_ksyms_32.o i387_32.o bootflag.o e820_32.o\

		quirks.o i8237.o topology.o alternative.o i8253.o tsc_32.o

		quirks.o i8237.o topology.o alternative.o i8253.o tsc_32.o io_delay.o



obj-$(CONFIG_STACKTRACE)	+= stacktrace.o

obj-y				+= cpu/

CRA Git | Maintained and supported by SUSTech CRA and CCSE