* 'avr32-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/hskinnemoen/avr32-2.6:
avr32: Fix bug in early resource allocation code
avr32: Build fix for CONFIG_BUG=n
avr32: Work around byteswap bug in gcc < 4.2
- directory with info about Linux on Intel 32 bit architecture.
ia64/
- directory with info about Linux on Intel 64 bit architecture.
-ide.txt
- - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
infiniband/
- directory with documents concerning Linux InfiniBand support.
initrd.txt
- documents the kernel probes debugging feature.
kref.txt
- docs on adding reference counters (krefs) to kernel objects.
-laptop-mode.txt
- - how to conserve battery power using laptop-mode.
laptops/
- directory with laptop related info and laptop driver documentation.
ldm.txt
- info on the Linux PCMCIA driver.
pi-futex.txt
- documentation on lightweight PI-futexes.
-pm.txt
- - info on Linux power management support.
pnp.txt
- Linux Plug and Play documentation.
-power_supply_class.txt
- - Tells userspace about battery, UPS, AC or DC power supply properties
power/
- directory with info on Linux PCI power management.
powerpc/
<chapter id="blkdev">
<title>Block Devices</title>
!Eblock/blk-core.c
+!Iblock/blk-core.c
!Eblock/blk-map.c
!Iblock/blk-sysfs.c
!Eblock/blk-settings.c
!Eblock/blk-exec.c
!Eblock/blk-barrier.c
!Eblock/blk-tag.c
+!Iblock/blk-tag.c
</chapter>
<chapter id="chrdev">
-Linux supports two methods of overriding the BIOS DSDT:
+Linux supports a method of overriding the BIOS DSDT:
CONFIG_ACPI_CUSTOM_DSDT builds the image into the kernel.
-CONFIG_ACPI_CUSTOM_DSDT_INITRD adds the image to the initrd.
-
-When to use these methods is described in detail on the
+When to use this method is described in detail on the
Linux/ACPI home page:
http://www.lesswatts.org/projects/acpi/overridingDSDT.php
-
-Note that if both options are used, the DSDT supplied
-by the INITRD method takes precedence.
-
-Documentation/initramfs-add-dsdt.sh is provided for convenience
-for use with the CONFIG_ACPI_CUSTOM_DSDT_INITRD method.
+++ /dev/null
-#!/bin/bash
-# Adds a DSDT file to the initrd (if it's an initramfs)
-# first argument is the name of archive
-# second argument is the name of the file to add
-# The file will be copied as /DSDT.aml
-
-# 20060126: fix "Premature end of file" with some old cpio (Roland Robic)
-# 20060205: this time it should really work
-
-# check the arguments
-if [ $# -ne 2 ]; then
- program_name=$(basename $0)
- echo "\
-$program_name: too few arguments
-Usage: $program_name initrd-name.img DSDT-to-add.aml
-Adds a DSDT file to an initrd (in initramfs format)
-
- initrd-name.img: filename of the initrd in initramfs format
- DSDT-to-add.aml: filename of the DSDT file to add
- " 1>&2
- exit 1
-fi
-
-# we should check it's an initramfs
-
-tempcpio=$(mktemp -d)
-# cleanup on exit, hangup, interrupt, quit, termination
-trap 'rm -rf $tempcpio' 0 1 2 3 15
-
-# extract the archive
-gunzip -c "$1" > "$tempcpio"/initramfs.cpio || exit 1
-
-# copy the DSDT file at the root of the directory so that we can call it "/DSDT.aml"
-cp -f "$2" "$tempcpio"/DSDT.aml
-
-# add the file
-cd "$tempcpio"
-(echo DSDT.aml | cpio --quiet -H newc -o -A -O "$tempcpio"/initramfs.cpio) || exit 1
-cd "$OLDPWD"
-
-# re-compress the archive
-gzip -c "$tempcpio"/initramfs.cpio > "$1"
-
---------------
0. The ide-cd relies on the ide disk driver. See
- Documentation/ide.txt for up-to-date information on the ide
+ Documentation/ide/ide.txt for up-to-date information on the ide
driver.
1. Make sure that the ide and ide-cd drivers are compiled into the
Depending on what type of IDE interface you have, you may need to
specify additional configuration options. See
- Documentation/ide.txt.
+ Documentation/ide/ide.txt.
2. You should also ensure that the iso9660 filesystem is either
compiled into the kernel or available as a loadable module. You
on the primary IDE interface are called `hda' and `hdb',
respectively. The drives on the secondary interface are called
`hdc' and `hdd'. (Interfaces at other locations get other letters
- in the third position; see Documentation/ide.txt.)
+ in the third position; see Documentation/ide/ide.txt.)
If you want your CDROM drive to be found automatically by the
driver, you should make sure your IDE interface uses either the
be jumpered as `master'. (If for some reason you cannot configure
your system in this manner, you can probably still use the driver.
You may have to pass extra configuration information to the kernel
- when you boot, however. See Documentation/ide.txt for more
+ when you boot, however. See Documentation/ide/ide.txt for more
information.)
4. Boot the system. If the drive is recognized, you should see a
This section discusses some common problems encountered when trying to
use the driver, and some possible solutions. Note that if you are
experiencing problems, you should probably also review
-Documentation/ide.txt for current information about the underlying
+Documentation/ide/ide.txt for current information about the underlying
IDE support code. Some of these items apply only to earlier versions
of the driver, but are mentioned here for completeness.
a. Drive is not detected during booting.
- Review the configuration instructions above and in
- Documentation/ide.txt, and check how your hardware is
+ Documentation/ide/ide.txt, and check how your hardware is
configured.
- If your drive is the only device on an IDE interface, it should
- If your IDE interface is not at the standard addresses of 0x170
or 0x1f0, you'll need to explicitly inform the driver using a
- lilo option. See Documentation/ide.txt. (This feature was
+ lilo option. See Documentation/ide/ide.txt. (This feature was
added around kernel version 1.3.30.)
- If the autoprobing is not finding your drive, you can tell the
Support for some interfaces needing extra initialization is
provided in later 1.3.x kernels. You may need to turn on
additional kernel configuration options to get them to work;
- see Documentation/ide.txt.
+ see Documentation/ide/ide.txt.
Even if support is not available for your interface, you may be
able to get it to work with the following procedure. First boot
be worked around by specifying the `serialize' option when
booting. Recent kernels should be able to detect the need for
this automatically in most cases, but the detection is not
- foolproof. See Documentation/ide.txt for more information
+ foolproof. See Documentation/ide/ide.txt for more information
about the `serialize' option and the CMD640B.
- Note that many MS-DOS CDROM drivers will work with such buggy
-Memory Controller
+Memory Resource Controller
+
+NOTE: The Memory Resource Controller has been generically been referred
+to as the memory controller in this document. Do not confuse memory controller
+used here with the memory controller that is used in hardware.
Salient features
a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
-c. Enable CONFIG_CGROUP_MEM_CONT
+c. Enable CONFIG_CGROUP_MEM_RES_CTLR
1. Prepare the cgroups
# mkdir -p /cgroups
Since now we're in the 0 cgroup,
We can alter the memory limit:
-# echo -n 4M > /cgroups/0/memory.limit_in_bytes
+# echo 4M > /cgroups/0/memory.limit_in_bytes
NOTE: We can use a suffix (k, K, m, M, g or G) to indicate values in kilo,
mega or gigabytes.
availability of memory on the system. The user is required to re-read
this file after a write to guarantee the value committed by the kernel.
-# echo -n 1 > memory.limit_in_bytes
+# echo 1 > memory.limit_in_bytes
# cat memory.limit_in_bytes
4096
The memory.force_empty gives an interface to drop *all* charges by force.
-# echo -n 1 > memory.force_empty
+# echo 1 > memory.force_empty
will drop all charges in cgroup. Currently, this is maintained for test.
--- /dev/null
+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.
+
--- /dev/null
+ Metronomefb
+ -----------
+Maintained by Jaya Kumar <jayakumar.lkml.gmail.com>
+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.
+
---------------------------
-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 <bzolnier@gmail.com>, Borislav Petkov
- <petkovbb@googlemail.com>
-
----------------------------
-
What: libata spindown skipping and warning
When: Dec 2008
Why: Some halt(8) implementations synchronize caches for and spin
-----------
laptop_mode is a knob that controls "laptop mode". All the things that are
-controlled by this knob are discussed in Documentation/laptop-mode.txt.
+controlled by this knob are discussed in Documentation/laptops/laptop-mode.txt.
block_dump
----------
block_dump enables block I/O debugging when set to a nonzero value. More
-information on block I/O debugging is in Documentation/laptop-mode.txt.
+information on block I/O debugging is in Documentation/laptops/laptop-mode.txt.
swap_token_timeout
------------------
This provides an overview of GPIO access conventions on Linux.
+These calls use the gpio_* naming prefix. No other calls should use that
+prefix, or the related __gpio_* prefix.
+
What is a GPIO?
===============
not care how it's implemented.)
That said, if the convention is supported on their platform, drivers should
-use it when possible. Platforms should declare GENERIC_GPIO support in
-Kconfig (boolean true), which multi-platform drivers can depend on when
-using the include file:
+use it when possible. Platforms must declare GENERIC_GPIO support in their
+Kconfig (boolean true), and provide an <asm/gpio.h> file. Drivers that can't
+work without standard GPIO calls should have Kconfig entries which depend
+on GENERIC_GPIO. The GPIO calls are available, either as "real code" or as
+optimized-away stubs, when drivers use the include file:
- #include <asm/gpio.h>
+ #include <linux/gpio.h>
If you stick to this convention then it'll be easier for other developers to
see what your code is doing, and help maintain it.
or support them in the same way; and any given board might use external
pullups (or pulldowns) so that the on-chip ones should not be used.
(When a circuit needs 5 kOhm, on-chip 100 kOhm resistors won't do.)
+Likewise drive strength (2 mA vs 20 mA) and voltage (1.8V vs 3.3V) is a
+platform-specific issue, as are models like (not) having a one-to-one
+correspondence between configurable pins and GPIOs.
There are other system-specific mechanisms that are not specified here,
like the aforementioned options for input de-glitching and wire-OR output.
- Hardware driver for Intel/AMD/VIA Random Number Generators (RNG)
- Copyright 2000,2001 Jeff Garzik <jgarzik@pobox.com>
- Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
-
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
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 <jgarzik@pobox.com>
+ Copyright 2000,2001 Philipp Rumpf <prumpf@mandrakesoft.com>
+
+
+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)
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
--- /dev/null
+00-INDEX
+ - this file
+ChangeLog.ide-cd.1994-2004
+ - ide-cd changelog
+ChangeLog.ide-floppy.1996-2002
+ - ide-floppy changelog
+ChangeLog.ide-tape.1995-2002
+ - ide-tape changelog
+ide-tape.txt
+ - info on the IDE ATAPI streaming tape driver
+ide.txt
+ - important info for users of ATA devices (IDE/EIDE disks and CD-ROMS).
git.samba.org / sfrench / cifs-2.6.git / commitdiff