From e32f7ee876ebbdec73e4c19dce559a20c2ab840e Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 10 Mar 2008 03:08:45 -0700 Subject: Input: add keyboard notifier documentation Document the keyboard notifier. Signed-off-by: Samuel Thibault Signed-off-by: Andrew Morton Signed-off-by: Jiri Kosina SIgned-off-by: Dmitry Torokhov --- Documentation/input/notifier.txt | 52 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 52 insertions(+) create mode 100644 Documentation/input/notifier.txt (limited to 'Documentation') diff --git a/Documentation/input/notifier.txt b/Documentation/input/notifier.txt new file mode 100644 index 00000000000..95172ca6f3d --- /dev/null +++ b/Documentation/input/notifier.txt @@ -0,0 +1,52 @@ +Keyboard notifier + +One can use register_keyboard_notifier to get called back on keyboard +events (see kbd_keycode() function for details). The passed structure is +keyboard_notifier_param: + +- 'vc' always provide the VC for which the keyboard event applies; +- 'down' is 1 for a key press event, 0 for a key release; +- 'shift' is the current modifier state, mask bit indexes are KG_*; +- 'value' depends on the type of event. + +- KBD_KEYCODE events are always sent before other events, value is the keycode. +- KBD_UNBOUND_KEYCODE events are sent if the keycode is not bound to a keysym. + value is the keycode. +- KBD_UNICODE events are sent if the keycode -> keysym translation produced a + unicode character. value is the unicode value. +- KBD_KEYSYM events are sent if the keycode -> keysym translation produced a + non-unicode character. value is the keysym. +- KBD_POST_KEYSYM events are sent after the treatment of non-unicode keysyms. + That permits one to inspect the resulting LEDs for instance. + +For each kind of event but the last, the callback may return NOTIFY_STOP in +order to "eat" the event: the notify loop is stopped and the keyboard event is +dropped. + +In a rough C snippet, we have: + +kbd_keycode(keycode) { + ... + params.value = keycode; + if (notifier_call_chain(KBD_KEYCODE,¶ms) == NOTIFY_STOP) + || !bound) { + notifier_call_chain(KBD_UNBOUND_KEYCODE,¶ms); + return; + } + + if (unicode) { + param.value = unicode; + if (notifier_call_chain(KBD_UNICODE,¶ms) == NOTIFY_STOP) + return; + emit unicode; + return; + } + + params.value = keysym; + if (notifier_call_chain(KBD_KEYSYM,¶ms) == NOTIFY_STOP) + return; + apply keysym; + notifier_call_chain(KBD_POST_KEYSYM,¶ms); +} + +NOTE: This notifier is usually called from interrupt context. -- cgit v1.2.3 From 75d08c78931aa3992791cc4a5615ed1dd61eea92 Mon Sep 17 00:00:00 2001 From: Jiri Kosina Date: Thu, 13 Mar 2008 16:13:59 -0400 Subject: Input: document i8042.noloop Document 'noloop' kernel parameter of i8042 controller driver. Pointed out in #10236. Signed-off-by: Jiri Kosina Signed-off-by: Dmitry Torokhov --- Documentation/kernel-parameters.txt | 2 ++ 1 file changed, 2 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 533e67febf8..09118a04594 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -735,6 +735,8 @@ and is between 256 and 4096 characters. It is defined in the file (Don't attempt to blink the leds) i8042.noaux [HW] Don't check for auxiliary (== mouse) port i8042.nokbd [HW] Don't check/create keyboard port + i8042.noloop [HW] Disable the AUX Loopback command while probing + for the AUX port i8042.nomux [HW] Don't check presence of an active multiplexing controller i8042.nopnp [HW] Don't use ACPIPnP / PnPBIOS to discover KBD/AUX -- cgit v1.2.3 From 2af3e6017e53065ddf40bb19190a29199b7ffee3 Mon Sep 17 00:00:00 2001 From: Adrian Bunk Date: Thu, 6 Mar 2008 16:02:42 +0100 Subject: The ps2esdi driver was marked as BROKEN more than two years ago due to being no longer working for some time. A driver that had been marked as BROKEN for such a long time seems to be unlikely to be revived in the forseeable future. But if anyone wants to ever revive this driver, the code is still present in the older kernel releases. Signed-off-by: Adrian Bunk Acked-by: Alan Cox Cc: Jens Axboe Signed-off-by: Andrew Morton Signed-off-by: Jens Axboe --- Documentation/mca.txt | 17 +++++------------ 1 file changed, 5 insertions(+), 12 deletions(-) (limited to 'Documentation') diff --git a/Documentation/mca.txt b/Documentation/mca.txt index aabce4ad90f..510375d4209 100644 --- a/Documentation/mca.txt +++ b/Documentation/mca.txt @@ -143,14 +143,7 @@ MCA Device Drivers Currently, there are a number of MCA-specific device drivers. -1) PS/2 ESDI - drivers/block/ps2esdi.c - include/linux/ps2esdi.h - Uses major number 36, and should use /dev files /dev/eda, /dev/edb. - Supports two drives, but only one controller. May use the - command-line args "ed=cyl,head,sec" and "tp720". - -2) PS/2 SCSI +1) PS/2 SCSI drivers/scsi/ibmmca.c drivers/scsi/ibmmca.h The driver for the IBM SCSI subsystem. Includes both integrated @@ -159,25 +152,25 @@ Currently, there are a number of MCA-specific device drivers. machine with a front-panel display (i.e. model 95), you can use "ibmmcascsi=display" to enable a drive activity indicator. -3) 3c523 +2) 3c523 drivers/net/3c523.c drivers/net/3c523.h 3Com 3c523 Etherlink/MC ethernet driver. -4) SMC Ultra/MCA and IBM Adapter/A +3) SMC Ultra/MCA and IBM Adapter/A drivers/net/smc-mca.c drivers/net/smc-mca.h Driver for the MCA version of the SMC Ultra and various other OEM'ed and work-alike cards (Elite, Adapter/A, etc). -5) NE/2 +4) NE/2 driver/net/ne2.c driver/net/ne2.h The NE/2 is the MCA version of the NE2000. This may not work with clones that have a different adapter id than the original NE/2. -6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and +5) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Adapter/A and Reply Sound Blaster/SCSI (SCSI part) Better support for these cards than the driver for ISA. Supports multiple cards with IRQ sharing. -- cgit v1.2.3 From de7c6d15e354bc94a846f03749819768c331280a Mon Sep 17 00:00:00 2001 From: Jaya Kumar Date: Wed, 19 Mar 2008 17:01:10 -0700 Subject: fbdev: defio and Metronomefb Implement support for the E-Ink Metronome controller. It provides an mmapable interface to the controller using defio support. It was tested with a gumstix pxa255 with Vizplex media using Xfbdev and various X clients such as xeyes, xpdf, xloadimage. This patch also fixes the following bug: Defio would cause a hang on write access to the framebuffer as the page fault would be called ad-infinitum. It fixes fb_defio by setting the mapping to be used by page_mkclean. Signed-off-by: Jaya Kumar Cc: "Antonino A. Daplas" Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/fb/cmap_xfbdev.txt | 53 ++++++++++++++++++++++++++++++++++++++++ Documentation/fb/metronomefb.txt | 38 ++++++++++++++++++++++++++++ 2 files changed, 91 insertions(+) create mode 100644 Documentation/fb/cmap_xfbdev.txt create mode 100644 Documentation/fb/metronomefb.txt (limited to 'Documentation') diff --git a/Documentation/fb/cmap_xfbdev.txt b/Documentation/fb/cmap_xfbdev.txt new file mode 100644 index 00000000000..55e1f0a3d2b --- /dev/null +++ b/Documentation/fb/cmap_xfbdev.txt @@ -0,0 +1,53 @@ +Understanding fbdev's cmap +-------------------------- + +These notes explain how X's dix layer uses fbdev's cmap structures. + +*. example of relevant structures in fbdev as used for a 3-bit grayscale cmap +struct fb_var_screeninfo { + .bits_per_pixel = 8, + .grayscale = 1, + .red = { 4, 3, 0 }, + .green = { 0, 0, 0 }, + .blue = { 0, 0, 0 }, +} +struct fb_fix_screeninfo { + .visual = FB_VISUAL_STATIC_PSEUDOCOLOR, +} +for (i = 0; i < 8; i++) + info->cmap.red[i] = (((2*i)+1)*(0xFFFF))/16; +memcpy(info->cmap.green, info->cmap.red, sizeof(u16)*8); +memcpy(info->cmap.blue, info->cmap.red, sizeof(u16)*8); + +*. X11 apps do something like the following when trying to use grayscale. +for (i=0; i < 8; i++) { + char colorspec[64]; + memset(colorspec,0,64); + sprintf(colorspec, "rgb:%x/%x/%x", i*36,i*36,i*36); + if (!XParseColor(outputDisplay, testColormap, colorspec, &wantedColor)) + printf("Can't get color %s\n",colorspec); + XAllocColor(outputDisplay, testColormap, &wantedColor); + grays[i] = wantedColor; +} +There's also named equivalents like gray1..x provided you have an rgb.txt. + +Somewhere in X's callchain, this results in a call to X code that handles the +colormap. For example, Xfbdev hits the following: + +xc-011010/programs/Xserver/dix/colormap.c: + +FindBestPixel(pentFirst, size, prgb, channel) + +dr = (long) pent->co.local.red - prgb->red; +dg = (long) pent->co.local.green - prgb->green; +db = (long) pent->co.local.blue - prgb->blue; +sq = dr * dr; +UnsignedToBigNum (sq, &sum); +BigNumAdd (&sum, &temp, &sum); + +co.local.red are entries that were brought in through FBIOGETCMAP which come +directly from the info->cmap.red that was listed above. The prgb is the rgb +that the app wants to match to. The above code is doing what looks like a least +squares matching function. That's why the cmap entries can't be set to the left +hand side boundaries of a color range. + diff --git a/Documentation/fb/metronomefb.txt b/Documentation/fb/metronomefb.txt new file mode 100644 index 00000000000..b9a2e7b7e83 --- /dev/null +++ b/Documentation/fb/metronomefb.txt @@ -0,0 +1,38 @@ + Metronomefb + ----------- +Maintained by Jaya Kumar +Last revised: Nov 20, 2007 + +Metronomefb is a driver for the Metronome display controller. The controller +is from E-Ink Corporation. It is intended to be used to drive the E-Ink +Vizplex display media. E-Ink hosts some details of this controller and the +display media here http://www.e-ink.com/products/matrix/metronome.html . + +Metronome is interfaced to the host CPU through the AMLCD interface. The +host CPU generates the control information and the image in a framebuffer +which is then delivered to the AMLCD interface by a host specific method. +Currently, that's implemented for the PXA's LCDC controller. The display and +error status are each pulled through individual GPIOs. + +Metronomefb was written for the PXA255/gumstix/lyre combination and +therefore currently has board set specific code in it. If other boards based on +other architectures are available, then the host specific code can be separated +and abstracted out. + +Metronomefb requires waveform information which is delivered via the AMLCD +interface to the metronome controller. The waveform information is expected to +be delivered from userspace via the firmware class interface. The waveform file +can be compressed as long as your udev or hotplug script is aware of the need +to uncompress it before delivering it. metronomefb will ask for waveform.wbf +which would typically go into /lib/firmware/waveform.wbf depending on your +udev/hotplug setup. I have only tested with a single waveform file which was +originally labeled 23P01201_60_WT0107_MTC. I do not know what it stands for. +Caution should be exercised when manipulating the waveform as there may be +a possibility that it could have some permanent effects on the display media. +I neither have access to nor know exactly what the waveform does in terms of +the physical media. + +Metronomefb uses the deferred IO interface so that it can provide a memory +mappable frame buffer. It has been tested with tinyx (Xfbdev). It is known +to work at this time with xeyes, xclock, xloadimage, xpdf. + -- cgit v1.2.3 From ad1c53bcdb831e14b1313ad694d5053ae0349393 Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Sat, 22 Mar 2008 16:40:21 +0100 Subject: ide: Documentation/ide/ide.txt fixes * "hdx=cyls,heads,sects,wpcom,irq" should be "hdx=cyls,heads,sects". * "hdx=" is for "x" from 'a' to 'u', "idex=" is for "x" from '0' to '9'. * "idex=noautotune" is long gone. * Obsoleted "ide0=" parameters were already removed from the documentation. Signed-off-by: Bartlomiej Zolnierkiewicz --- Documentation/ide/ide.txt | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt index e3b3425328b..d4877a9e60f 100644 --- a/Documentation/ide/ide.txt +++ b/Documentation/ide/ide.txt @@ -105,7 +105,7 @@ Drives are normally found by auto-probing and/or examining the CMOS/BIOS data. For really weird situations, the apparent (fdisk) geometry can also be specified on the kernel "command line" using LILO. The format of such lines is: - hdx=cyls,heads,sects,wpcom,irq + hdx=cyls,heads,sects or hdx=cdrom where hdx can be any of hda through hdh, Three values are required @@ -214,9 +214,9 @@ driver using the "options=" keyword to insmod, while replacing any ',' with Summary of ide driver parameters for kernel command line -------------------------------------------------------- - "hdx=" is recognized for all "x" from "a" to "h", such as "hdc". + "hdx=" is recognized for all "x" from "a" to "u", such as "hdc". - "idex=" is recognized for all "x" from "0" to "3", such as "ide1". + "idex=" is recognized for all "x" from "0" to "9", such as "ide1". "hdx=noprobe" : drive may be present, but do not probe for it @@ -233,8 +233,6 @@ Summary of ide driver parameters for kernel command line "hdx=remap63" : remap the drive: add 63 to all sector numbers (for DM OnTrack) - "idex=noautotune" : driver will NOT attempt to tune interface speed - "hdx=autotune" : driver will attempt to tune interface speed to the fastest PIO mode supported, if possible for this drive only. @@ -282,10 +280,6 @@ Summary of ide driver parameters for kernel command line "ide=reverse" : formerly called to pci sub-system, but now local. -The following are valid ONLY on ide0, which usually corresponds -to the first ATA interface found on the particular host, and the defaults for -the base,ctl ports must not be altered. - "ide=doubler" : probe/support IDE doublers on Amiga There may be more options than shown -- use the source, Luke! -- cgit v1.2.3 From 15220d9b5a7e6f4ff251350b285674ed676e0d3d Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Sat, 22 Mar 2008 16:40:21 +0100 Subject: ide: mark "hdx=[driver_name]" and "hdx=scsi" kernel parameters as obsoleted Mark "hdx=[driver_name]" and "hdx=scsi" kernel parameters as obsoleted (nowadays device-driver binding can be changed at runtime through sysfs and it can also be dealt with using per device driver parameters). Signed-off-by: Bartlomiej Zolnierkiewicz --- Documentation/ide/ide.txt | 4 ---- 1 file changed, 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt index d4877a9e60f..3f4db0018ed 100644 --- a/Documentation/ide/ide.txt +++ b/Documentation/ide/ide.txt @@ -242,10 +242,6 @@ Summary of ide driver parameters for kernel command line "hdx=nodma" : disallow DMA - "hdx=scsi" : the return of the ide-scsi flag, this is useful for - allowing ide-floppy, ide-tape, and ide-cdrom|writers - to use ide-scsi emulation on a device specific option. - "idebus=xx" : inform IDE driver of VESA/PCI bus speed in MHz, where "xx" is between 20 and 66 inclusive, used when tuning chipset PIO modes. -- cgit v1.2.3 From d708c40da83a86551556999e924e27fdc43dad71 Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Sat, 22 Mar 2008 16:40:22 +0100 Subject: ide: mark "hdx=remap" and "hdx=remap63" kernel parameters as obsoleted Mark "hdx=remap" and "hdx=remap63" kernel parameters as obsoleted (they are layering violation and should be dealt with in the same way as done by libata - device-mapper should be used instead). Signed-off-by: Bartlomiej Zolnierkiewicz --- Documentation/ide/ide.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/ide/ide.txt b/Documentation/ide/ide.txt index 3f4db0018ed..818676aad45 100644 --- a/Documentation/ide/ide.txt +++ b/Documentation/ide/ide.txt @@ -228,11 +228,6 @@ Summary of ide driver parameters for kernel command line "hdx=cyl,head,sect" : disk drive is present, with specified geometry - "hdx=remap" : remap access of sector 0 to sector 1 (for EZDrive) - - "hdx=remap63" : remap the drive: add 63 to all sector numbers - (for DM OnTrack) - "hdx=autotune" : driver will attempt to tune interface speed to the fastest PIO mode supported, if possible for this drive only. -- cgit v1.2.3 From ca4e2ab5b2764562fe3d41b95b27e6bbd4733d66 Mon Sep 17 00:00:00 2001 From: Bartlomiej Zolnierkiewicz Date: Sat, 22 Mar 2008 16:44:27 +0100 Subject: Revert "ide-tape: schedule driver for removal after 6 months" This reverts commit d48567dd43868b3d2e1fcc33ee76dc2d38a1ddeb. Borislav is working on ide-tape "light" version instead. Cc: Borislav Petkov Signed-off-by: Bartlomiej Zolnierkiewicz --- Documentation/feature-removal-schedule.txt | 10 ---------- 1 file changed, 10 deletions(-) (limited to 'Documentation') diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index c1d1fd0c299..bf0e3df8e7a 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -172,16 +172,6 @@ Who: Len Brown --------------------------- -What: ide-tape driver -When: July 2008 -Files: drivers/ide/ide-tape.c -Why: This driver might not have any users anymore and maintaining it for no - reason is an effort no one wants to make. -Who: Bartlomiej Zolnierkiewicz , Borislav Petkov - - ---------------------------- - What: libata spindown skipping and warning When: Dec 2008 Why: Some halt(8) implementations synchronize caches for and spin -- cgit v1.2.3 From 1312848e92a0686cb5124aa86ea58d55ba795742 Mon Sep 17 00:00:00 2001 From: Pavel Machek Date: Mon, 24 Mar 2008 12:29:43 -0700 Subject: kernel-parameters.txt: document memmap option better Provide example for memmap exclude option (it is slightly strange and non-trivial) and provide nice small HOWTO for people with bad memory. Signed-off-by: Jan-Simon Moeller Signed-off-by: Pavel Machek Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 650b0d8aa89..508e2a2c986 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -1130,6 +1130,10 @@ and is between 256 and 4096 characters. It is defined in the file memmap=nn[KMG]$ss[KMG] [KNL,ACPI] Mark specific memory as reserved. Region of memory to be used, from ss to ss+nn. + Example: Exclude memory from 0x18690000-0x1869ffff + memmap=64K$0x18690000 + or + memmap=0x10000$0x18690000 meye.*= [HW] Set MotionEye Camera parameters See Documentation/video4linux/meye.txt. -- cgit v1.2.3 From 537878d2c988fa12bbfaec19ee060c7603a48230 Mon Sep 17 00:00:00 2001 From: David Brownell Date: Mon, 24 Mar 2008 12:29:51 -0700 Subject: hw_random doc updates Update documentation for the hw_random support to be current: - Documentation/hw_random.txt has been updated to reflect the current code: it's a framework now, a "core" with a small sysfs interface, that hardware-specific drivers plug in to. Text specific to Intel hardware is now at the end. - Kconfig now references the Documentation/hw_random.txt file and better explains what this really does. Both chunks of documentation now higlight the fact that the kernel entropy pool is maintained by "rngd", and this driver has nothing directly to do with that important task. Signed-off-by: David Brownell Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/hw_random.txt | 59 ++++++++++++++++++++++++++++++--------------- 1 file changed, 40 insertions(+), 19 deletions(-) (limited to 'Documentation') diff --git a/Documentation/hw_random.txt b/Documentation/hw_random.txt index bb58c36b584..690f52550c8 100644 --- a/Documentation/hw_random.txt +++ b/Documentation/hw_random.txt @@ -1,33 +1,26 @@ - Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) - Copyright 2000,2001 Jeff Garzik - Copyright 2000,2001 Philipp Rumpf - Introduction: - The hw_random device driver is software that makes use of a + The hw_random framework is software that makes use of a special hardware feature on your CPU or motherboard, - a Random Number Generator (RNG). + a Random Number Generator (RNG). The software has two parts: + a core providing the /dev/hw_random character device and its + sysfs support, plus a hardware-specific driver that plugs + into that core. - In order to make effective use of this device driver, you + To make the most effective use of these mechanisms, you should download the support software as well. Download the latest version of the "rng-tools" package from the hw_random driver's official Web site: http://sourceforge.net/projects/gkernel/ -About the Intel RNG hardware, from the firmware hub datasheet: - - The Firmware Hub integrates a Random Number Generator (RNG) - using thermal noise generated from inherently random quantum - mechanical properties of silicon. When not generating new random - bits the RNG circuitry will enter a low power state. Intel will - provide a binary software driver to give third party software - access to our RNG for use as a security feature. At this time, - the RNG is only to be used with a system in an OS-present state. + Those tools use /dev/hw_random to fill the kernel entropy pool, + which is used internally and exported by the /dev/urandom and + /dev/random special files. Theory of operation: - Character driver. Using the standard open() + CHARACTER DEVICE. Using the standard open() and read() system calls, you can read random data from the hardware RNG device. This data is NOT CHECKED by any fitness tests, and could potentially be bogus (if the @@ -36,9 +29,37 @@ Theory of operation: a security-conscious person would run fitness tests on the data before assuming it is truly random. - /dev/hwrandom is char device major 10, minor 183. + The rng-tools package uses such tests in "rngd", and lets you + run them by hand with a "rngtest" utility. + + /dev/hw_random is char device major 10, minor 183. + + CLASS DEVICE. There is a /sys/class/misc/hw_random node with + two unique attributes, "rng_available" and "rng_current". The + "rng_available" attribute lists the hardware-specific drivers + available, while "rng_current" lists the one which is currently + connected to /dev/hw_random. If your system has more than one + RNG available, you may change the one used by writing a name from + the list in "rng_available" into "rng_current". + +========================================================================== + + Hardware driver for Intel/AMD/VIA Random Number Generators (RNG) + Copyright 2000,2001 Jeff Garzik + Copyright 2000,2001 Philipp Rumpf + + +About the Intel RNG hardware, from the firmware hub datasheet: + + The Firmware Hub integrates a Random Number Generator (RNG) + using thermal noise generated from inherently random quantum + mechanical properties of silicon. When not generating new random + bits the RNG circuitry will enter a low power state. Intel will + provide a binary software driver to give third party software + access to our RNG for use as a security feature. At this time, + the RNG is only to be used with a system in an OS-present state. -Driver notes: +Intel RNG Driver notes: * FIXME: support poll(2) -- cgit v1.2.3 From c0c20fb5a8f2e2eddf7f0e5467c7511fee907903 Mon Sep 17 00:00:00 2001 From: Nick Andrew Date: Tue, 4 Mar 2008 15:05:40 -0800 Subject: x86: Documentation/i386/IO-APIC.txt: fix description The description of the interrupt routing doesn't match the (nice) diagram. Signed-off-by: Nick Andrew Signed-off-by: Andrew Morton Signed-off-by: Ingo Molnar Signed-off-by: Thomas Gleixner --- Documentation/i386/IO-APIC.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/i386/IO-APIC.txt b/Documentation/i386/IO-APIC.txt index f95166645d2..30b4c714fbe 100644 --- a/Documentation/i386/IO-APIC.txt +++ b/Documentation/i386/IO-APIC.txt @@ -70,7 +70,7 @@ Every PCI card emits a PCI IRQ, which can be INTA, INTB, INTC or INTD: These INTA-D PCI IRQs are always 'local to the card', their real meaning depends on which slot they are in. If you look at the daisy chaining diagram, -a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ2 of +a card in slot4, issuing INTA IRQ, it will end up as a signal on PIRQ4 of the PCI chipset. Most cards issue INTA, this creates optimal distribution between the PIRQ lines. (distributing IRQ sources properly is not a necessity, PCI IRQs can be shared at will, but it's a good for performance -- cgit v1.2.3 From 5abbcf29928966b28d70f8a0da424f55582f8603 Mon Sep 17 00:00:00 2001 From: Marcin Slusarz Date: Sun, 23 Mar 2008 21:06:30 +0100 Subject: x86, documentation: nmi_watchdog=2 works on x86_64 Signed-off-by: Marcin Slusarz Cc: Peter Zijlstra Signed-off-by: Ingo Molnar --- Documentation/nmi_watchdog.txt | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/nmi_watchdog.txt b/Documentation/nmi_watchdog.txt index c025a4561c1..757c729ee42 100644 --- a/Documentation/nmi_watchdog.txt +++ b/Documentation/nmi_watchdog.txt @@ -23,8 +23,7 @@ kernel debugging options, such as Kernel Stack Meter or Kernel Tracer, may implicitly disable the NMI watchdog.] For x86-64, the needed APIC is always compiled in, and the NMI watchdog is -always enabled with I/O-APIC mode (nmi_watchdog=1). Currently, local APIC -mode (nmi_watchdog=2) does not work on x86-64. +always enabled with I/O-APIC mode (nmi_watchdog=1). Using local APIC (nmi_watchdog=2) needs the first performance register, so you can't use it for other purposes (such as high precision performance -- cgit v1.2.3 From b488f22d70f1c2451618b9991b9665d2c6b31e2b Mon Sep 17 00:00:00 2001 From: Tim Ansell Date: Mon, 11 Feb 2008 18:13:42 +1030 Subject: lguest: Add puppies which where previously missing. lguest doesn't have features, it has puppies! Signed-off-by: Timothy R Ansell Signed-off-by: Rusty Russell --- Documentation/lguest/lguest.txt | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'Documentation') diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt index 722d4e7fbeb..78fd14b658c 100644 --- a/Documentation/lguest/lguest.txt +++ b/Documentation/lguest/lguest.txt @@ -1,6 +1,7 @@ -Rusty's Remarkably Unreliable Guide to Lguest - - or, A Young Coder's Illustrated Hypervisor -http://lguest.ozlabs.org + __ + (___()'`; Rusty's Remarkably Unreliable Guide to Lguest + /, /` - or, A Young Coder's Illustrated Hypervisor + \\"--\\ http://lguest.ozlabs.org Lguest is designed to be a minimal hypervisor for the Linux kernel, for Linux developers and users to experiment with virtualization with the -- cgit v1.2.3 From 9b7a448e2b23101a776ddf639c9037d47244f7ab Mon Sep 17 00:00:00 2001 From: Paul Bolle Date: Tue, 11 Mar 2008 13:36:14 +0100 Subject: lguest: lguest.txt documentation fix Mention the config options for the Virtio drivers and move the Virtualization menu to the toplevel. Signed-off-by: Paul Bolle Signed-off-by: Rusty Russell --- Documentation/lguest/lguest.txt | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) (limited to 'Documentation') diff --git a/Documentation/lguest/lguest.txt b/Documentation/lguest/lguest.txt index 78fd14b658c..29510dc5151 100644 --- a/Documentation/lguest/lguest.txt +++ b/Documentation/lguest/lguest.txt @@ -42,12 +42,16 @@ Running Lguest: CONFIG_PHYSICAL_ALIGN=0x100000) "Device Drivers": + "Block devices" + "Virtio block driver (EXPERIMENTAL)" = M/Y "Network device support" "Universal TUN/TAP device driver support" = M/Y - (CONFIG_TUN=m) - "Virtualization" - "Linux hypervisor example code" = M/Y - (CONFIG_LGUEST=m) + "Virtio network driver (EXPERIMENTAL)" = M/Y + (CONFIG_VIRTIO_BLK=m, CONFIG_VIRTIO_NET=m and CONFIG_TUN=m) + + "Virtualization" + "Linux hypervisor example code" = M/Y + (CONFIG_LGUEST=m) - A tool called "lguest" is available in this directory: type "make" to build it. If you didn't build your kernel in-tree, use "make -- cgit v1.2.3 From e18b094f0faa4889b06a112da17230a10b88c815 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Fri, 28 Mar 2008 11:05:52 -0500 Subject: lguest: Don't need comment terminator before disk section. Signed-off-by: Rusty Russell --- Documentation/lguest/lguest.c | 1 - 1 file changed, 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index bec5a32e409..d45c7f682b1 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -1383,7 +1383,6 @@ struct vblk_info * Launcher triggers interrupt to Guest. */ int done_fd; }; -/*:*/ /*L:210 * The Disk -- cgit v1.2.3 From a6bd8e13034dd7d60b6f14217096efa192d0adc1 Mon Sep 17 00:00:00 2001 From: Rusty Russell Date: Fri, 28 Mar 2008 11:05:53 -0500 Subject: lguest: comment documentation update. Took some cycles to re-read the Lguest Journey end-to-end, fix some rot and tighten some phrases. Only comments change. No new jokes, but a couple of recycled old jokes. Signed-off-by: Rusty Russell --- Documentation/lguest/lguest.c | 69 ++++++++++++++++++++++++------------------- 1 file changed, 38 insertions(+), 31 deletions(-) (limited to 'Documentation') diff --git a/Documentation/lguest/lguest.c b/Documentation/lguest/lguest.c index d45c7f682b1..4c1fc65a8b3 100644 --- a/Documentation/lguest/lguest.c +++ b/Documentation/lguest/lguest.c @@ -1,7 +1,7 @@ /*P:100 This is the Launcher code, a simple program which lays out the - * "physical" memory for the new Guest by mapping the kernel image and the - * virtual devices, then reads repeatedly from /dev/lguest to run the Guest. -:*/ + * "physical" memory for the new Guest by mapping the kernel image and + * the virtual devices, then opens /dev/lguest to tell the kernel + * about the Guest and control it. :*/ #define _LARGEFILE64_SOURCE #define _GNU_SOURCE #include @@ -43,7 +43,7 @@ #include "linux/virtio_console.h" #include "linux/virtio_ring.h" #include "asm-x86/bootparam.h" -/*L:110 We can ignore the 38 include files we need for this program, but I do +/*L:110 We can ignore the 39 include files we need for this program, but I do * want to draw attention to the use of kernel-style types. * * As Linus said, "C is a Spartan language, and so should your naming be." I @@ -320,7 +320,7 @@ static unsigned long map_elf(int elf_fd, const Elf32_Ehdr *ehdr) err(1, "Reading program headers"); /* Try all the headers: there are usually only three. A read-only one, - * a read-write one, and a "note" section which isn't loadable. */ + * a read-write one, and a "note" section which we don't load. */ for (i = 0; i < ehdr->e_phnum; i++) { /* If this isn't a loadable segment, we ignore it */ if (phdr[i].p_type != PT_LOAD) @@ -387,7 +387,7 @@ static unsigned long load_kernel(int fd) if (memcmp(hdr.e_ident, ELFMAG, SELFMAG) == 0) return map_elf(fd, &hdr); - /* Otherwise we assume it's a bzImage, and try to unpack it */ + /* Otherwise we assume it's a bzImage, and try to load it. */ return load_bzimage(fd); } @@ -433,12 +433,12 @@ static unsigned long load_initrd(const char *name, unsigned long mem) return len; } -/* Once we know how much memory we have, we can construct simple linear page +/* Once we know how much memory we have we can construct simple linear page * tables which set virtual == physical which will get the Guest far enough * into the boot to create its own. * * We lay them out of the way, just below the initrd (which is why we need to - * know its size). */ + * know its size here). */ static unsigned long setup_pagetables(unsigned long mem, unsigned long initrd_size) { @@ -850,7 +850,8 @@ static void handle_console_output(int fd, struct virtqueue *vq) * * Handling output for network is also simple: we get all the output buffers * and write them (ignoring the first element) to this device's file descriptor - * (stdout). */ + * (/dev/net/tun). + */ static void handle_net_output(int fd, struct virtqueue *vq) { unsigned int head, out, in; @@ -924,7 +925,7 @@ static void enable_fd(int fd, struct virtqueue *vq) write(waker_fd, &vq->dev->fd, sizeof(vq->dev->fd)); } -/* Resetting a device is fairly easy. */ +/* When the Guest asks us to reset a device, it's is fairly easy. */ static void reset_device(struct device *dev) { struct virtqueue *vq; @@ -1003,8 +1004,8 @@ static void handle_input(int fd) if (select(devices.max_infd+1, &fds, NULL, NULL, &poll) == 0) break; - /* Otherwise, call the device(s) which have readable - * file descriptors and a method of handling them. */ + /* Otherwise, call the device(s) which have readable file + * descriptors and a method of handling them. */ for (i = devices.dev; i; i = i->next) { if (i->handle_input && FD_ISSET(i->fd, &fds)) { int dev_fd; @@ -1015,8 +1016,7 @@ static void handle_input(int fd) * should no longer service it. Networking and * console do this when there's no input * buffers to deliver into. Console also uses - * it when it discovers that stdin is - * closed. */ + * it when it discovers that stdin is closed. */ FD_CLR(i->fd, &devices.infds); /* Tell waker to ignore it too, by sending a * negative fd number (-1, since 0 is a valid @@ -1033,7 +1033,8 @@ static void handle_input(int fd) * * All devices need a descriptor so the Guest knows it exists, and a "struct * device" so the Launcher can keep track of it. We have common helper - * routines to allocate and manage them. */ + * routines to allocate and manage them. + */ /* The layout of the device page is a "struct lguest_device_desc" followed by a * number of virtqueue descriptors, then two sets of feature bits, then an @@ -1078,7 +1079,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, struct virtqueue **i, *vq = malloc(sizeof(*vq)); void *p; - /* First we need some pages for this virtqueue. */ + /* First we need some memory for this virtqueue. */ pages = (vring_size(num_descs, getpagesize()) + getpagesize() - 1) / getpagesize(); p = get_pages(pages); @@ -1122,7 +1123,7 @@ static void add_virtqueue(struct device *dev, unsigned int num_descs, } /* The first half of the feature bitmask is for us to advertise features. The - * second half if for the Guest to accept features. */ + * second half is for the Guest to accept features. */ static void add_feature(struct device *dev, unsigned bit) { u8 *features = get_feature_bits(dev); @@ -1151,7 +1152,9 @@ static void set_config(struct device *dev, unsigned len, const void *conf) } /* This routine does all the creation and setup of a new device, including - * calling new_dev_desc() to allocate the descriptor and device memory. */ + * calling new_dev_desc() to allocate the descriptor and device memory. + * + * See what I mean about userspace being boring? */ static struct device *new_device(const char *name, u16 type, int fd, bool (*handle_input)(int, struct device *)) { @@ -1492,7 +1495,10 @@ static int io_thread(void *_dev) while (read(vblk->workpipe[0], &c, 1) == 1) { /* We acknowledge each request immediately to reduce latency, * rather than waiting until we've done them all. I haven't - * measured to see if it makes any difference. */ + * measured to see if it makes any difference. + * + * That would be an interesting test, wouldn't it? You could + * also try having more than one I/O thread. */ while (service_io(dev)) write(vblk->done_fd, &c, 1); } @@ -1500,7 +1506,7 @@ static int io_thread(void *_dev) } /* Now we've seen the I/O thread, we return to the Launcher to see what happens - * when the thread tells us it's completed some I/O. */ + * when that thread tells us it's completed some I/O. */ static bool handle_io_finish(int fd, struct device *dev) { char c; @@ -1572,11 +1578,12 @@ static void setup_block_file(const char *filename) * more work. */ pipe(vblk->workpipe); - /* Create stack for thread and run it */ + /* Create stack for thread and run it. Since stack grows upwards, we + * point the stack pointer to the end of this region. */ stack = malloc(32768); /* SIGCHLD - We dont "wait" for our cloned thread, so prevent it from * becoming a zombie. */ - if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1) + if (clone(io_thread, stack + 32768, CLONE_VM | SIGCHLD, dev) == -1) err(1, "Creating clone"); /* We don't need to keep the I/O thread's end of the pipes open. */ @@ -1586,14 +1593,14 @@ static void setup_block_file(const char *filename) verbose("device %u: virtblock %llu sectors\n", devices.device_num, le64_to_cpu(conf.capacity)); } -/* That's the end of device setup. :*/ +/* That's the end of device setup. */ -/* Reboot */ +/*L:230 Reboot is pretty easy: clean up and exec() the Launcher afresh. */ static void __attribute__((noreturn)) restart_guest(void) { unsigned int i; - /* Closing pipes causes the waker thread and io_threads to die, and + /* Closing pipes causes the Waker thread and io_threads to die, and * closing /dev/lguest cleans up the Guest. Since we don't track all * open fds, we simply close everything beyond stderr. */ for (i = 3; i < FD_SETSIZE; i++) @@ -1602,7 +1609,7 @@ static void __attribute__((noreturn)) restart_guest(void) err(1, "Could not exec %s", main_args[0]); } -/*L:220 Finally we reach the core of the Launcher, which runs the Guest, serves +/*L:220 Finally we reach the core of the Launcher which runs the Guest, serves * its input and output, and finally, lays it to rest. */ static void __attribute__((noreturn)) run_guest(int lguest_fd) { @@ -1643,7 +1650,7 @@ static void __attribute__((noreturn)) run_guest(int lguest_fd) err(1, "Resetting break"); } } -/* +/*L:240 * This is the end of the Launcher. The good news: we are over halfway * through! The bad news: the most fiendish part of the code still lies ahead * of us. @@ -1690,8 +1697,8 @@ int main(int argc, char *argv[]) * device receive input from a file descriptor, we keep an fdset * (infds) and the maximum fd number (max_infd) with the head of the * list. We also keep a pointer to the last device. Finally, we keep - * the next interrupt number to hand out (1: remember that 0 is used by - * the timer). */ + * the next interrupt number to use for devices (1: remember that 0 is + * used by the timer). */ FD_ZERO(&devices.infds); devices.max_infd = -1; devices.lastdev = NULL; @@ -1792,8 +1799,8 @@ int main(int argc, char *argv[]) lguest_fd = tell_kernel(pgdir, start); /* We fork off a child process, which wakes the Launcher whenever one - * of the input file descriptors needs attention. Otherwise we would - * run the Guest until it tries to output something. */ + * of the input file descriptors needs attention. We call this the + * Waker, and we'll cover it in a moment. */ waker_fd = setup_waker(lguest_fd); /* Finally, run the Guest. This doesn't return. */ -- cgit v1.2.3 From 7731ce63d9a863c987dd87b0425451fff0e6cdc8 Mon Sep 17 00:00:00 2001 From: "Rafael J. Wysocki" Date: Sun, 30 Mar 2008 02:19:07 +0100 Subject: ACPI PM: Restore the 2.6.24 suspend ordering MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Some time ago it turned out that our suspend code ordering broke some NVidia-based systems that hung if _PTS was executed with one of the PCI devices, specifically a USB controller, in a low power state. Then, it was noticed that the suspend code ordering was not compliant with ACPI 1.0, although it was compliant with ACPI 2.0 (and later), and it was argued that the code had to be changed for that reason (ref. http://bugzilla.kernel.org/show_bug.cgi?id=9528). So we did, but evidently we did wrong, because it's now turning out that some systems have been broken by this change. Refs: http://bugzilla.kernel.org/show_bug.cgi?id=10340 https://bugzilla.novell.com/show_bug.cgi?id=374217#c16 [ I said at that time that something like this might happend, but the majority of people involved thought that it was improbable due to the necessity to preserve the compliance of hardware with ACPI 1.0. ] This actually is a quite serious regression from 2.6.24. Moreover, the ACPI 1.0 ordering of suspend code introduced another issue that I have only noticed recently. Namely, if the suspend of one of devices fails, the already suspended devices will be resumed without executing _WAK before, which leads to problems on some systems (for example, in such situations thermal management is broken on my HP nx6325). Consequently, it also breaks suspend debugging on the affected systems. Note also, that the requirement to execute _PTS before suspending devices does not really make sense, because the device in question may be put into a low power state at run time for a reason unrelated to a system-wide suspend. For the reasons outlined above, the change of the suspend ordering should be reverted, which is done by the patch below. [ Felix Möller: "I am the reporter from the original Novell Bug: https://bugzilla.novell.com/show_bug.cgi?id=374217 I just tried current git head (two hours ago) with the patch (the one from the beginning of this thread) from Rafael and without it. With the patch my MacBook does suspend without it does not." ] Signed-off-by: Rafael J. Wysocki Tested-by: Felix Möller Signed-off-by: Linus Torvalds --- Documentation/kernel-parameters.txt | 5 ----- 1 file changed, 5 deletions(-) (limited to 'Documentation') diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 508e2a2c986..4cd1a5da80a 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -170,11 +170,6 @@ and is between 256 and 4096 characters. It is defined in the file acpi_irq_isa= [HW,ACPI] If irq_balance, mark listed IRQs used by ISA Format: ,... - acpi_new_pts_ordering [HW,ACPI] - Enforce the ACPI 2.0 ordering of the _PTS control - method wrt putting devices into low power states - default: pre ACPI 2.0 ordering of _PTS - acpi_no_auto_ssdt [HW,ACPI] Disable automatic loading of SSDT acpi_os_name= [HW,ACPI] Tell ACPI BIOS the name of the OS -- cgit v1.2.3 From e8d49f3a6fec38cc83ae3221c3df0649d021c30c Mon Sep 17 00:00:00 2001 From: Dmitri Vorobiev Date: Wed, 2 Apr 2008 13:04:45 -0700 Subject: Fix typos in Documentation/unaligned-memory-access.txt This patch deletes a couple of superfluous word occurrences in the document Documentation/unaligned-memory-access.txt. Thanks to Sebastien Dugue for the remark about English usage. Signed-off-by: Dmitri Vorobiev Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/unaligned-memory-access.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation') diff --git a/Documentation/unaligned-memory-access.txt b/Documentation/unaligned-memory-access.txt index 6223eace3c0..b0472ac5226 100644 --- a/Documentation/unaligned-memory-access.txt +++ b/Documentation/unaligned-memory-access.txt @@ -57,7 +57,7 @@ here; a summary of the common scenarios is presented below: unaligned access to be corrected. - Some architectures are not capable of unaligned memory access, but will silently perform a different memory access to the one that was requested, - resulting a a subtle code bug that is hard to detect! + resulting in a subtle code bug that is hard to detect! It should be obvious from the above that if your code causes unaligned memory accesses to happen, your code will not work correctly on certain @@ -209,7 +209,7 @@ memory and you wish to avoid unaligned access, its usage is as follows: u32 value = get_unaligned((u32 *) data); -These macros work work for memory accesses of any length (not just 32 bits as +These macros work for memory accesses of any length (not just 32 bits as in the examples above). Be aware that when compared to standard access of aligned memory, using these macros to access unaligned memory can be costly in terms of performance. -- cgit v1.2.3 From f2b2ea692ec01768c77a4f532dcd060316460122 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Wed, 2 Apr 2008 13:04:46 -0700 Subject: doc: fix typo in SubmittingPatches Signed-off-by: Jim Meyering Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- Documentation/SubmittingPatches | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation') diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index 08a1ed1cb5d..47a539c7642 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -512,7 +512,7 @@ They provide type safety, have no length limitations, no formatting limitations, and under gcc they are as cheap as macros. Macros should only be used for cases where a static inline is clearly -suboptimal [there a few, isolated cases of this in fast paths], +suboptimal [there are a few, isolated cases of this in fast paths], or where it is impossible to use a static inline function [such as string-izing]. -- cgit v1.2.3