diff options
Diffstat (limited to 'Documentation')
249 files changed, 3554 insertions, 3788 deletions
diff --git a/Documentation/ABI/obsolete/devfs b/Documentation/ABI/removed/devfs index b8b87399bc8f..8195c4e0d0a1 100644 --- a/Documentation/ABI/obsolete/devfs +++ b/Documentation/ABI/removed/devfs @@ -1,13 +1,12 @@ What: devfs -Date: July 2005 +Date: July 2005 (scheduled), finally removed in kernel v2.6.18 Contact: Greg Kroah-Hartman <gregkh@suse.de> Description: devfs has been unmaintained for a number of years, has unfixable races, contains a naming policy within the kernel that is against the LSB, and can be replaced by using udev. - The files fs/devfs/*, include/linux/devfs_fs*.h will be removed, + The files fs/devfs/*, include/linux/devfs_fs*.h were removed, along with the the assorted devfs function calls throughout the kernel tree. Users: - diff --git a/Documentation/ABI/testing/sysfs-power b/Documentation/ABI/testing/sysfs-power new file mode 100644 index 000000000000..d882f8093871 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-power @@ -0,0 +1,88 @@ +What: /sys/power/ +Date: August 2006 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power directory will contain files that will + provide a unified interface to the power management + subsystem. + +What: /sys/power/state +Date: August 2006 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/state file controls the system power state. + Reading from this file returns what states are supported, + which is hard-coded to 'standby' (Power-On Suspend), 'mem' + (Suspend-to-RAM), and 'disk' (Suspend-to-Disk). + + Writing to this file one of these strings causes the system to + transition into that state. Please see the file + Documentation/power/states.txt for a description of each of + these states. + +What: /sys/power/disk +Date: August 2006 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/disk file controls the operating mode of the + suspend-to-disk mechanism. Reading from this file returns + the name of the method by which the system will be put to + sleep on the next suspend. There are four methods supported: + 'firmware' - means that the memory image will be saved to disk + by some firmware, in which case we also assume that the + firmware will handle the system suspend. + 'platform' - the memory image will be saved by the kernel and + the system will be put to sleep by the platform driver (e.g. + ACPI or other PM registers). + 'shutdown' - the memory image will be saved by the kernel and + the system will be powered off. + 'reboot' - the memory image will be saved by the kernel and + the system will be rebooted. + + The suspend-to-disk method may be chosen by writing to this + file one of the accepted strings: + + 'firmware' + 'platform' + 'shutdown' + 'reboot' + + It will only change to 'firmware' or 'platform' if the system + supports that. + +What: /sys/power/image_size +Date: August 2006 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/image_size file controls the size of the image + created by the suspend-to-disk mechanism. It can be written a + string representing a non-negative integer that will be used + as an upper limit of the image size, in bytes. The kernel's + suspend-to-disk code will do its best to ensure the image size + will not exceed this number. However, if it turns out to be + impossible, the kernel will try to suspend anyway using the + smallest image possible. In particular, if "0" is written to + this file, the suspend image will be as small as possible. + + Reading from this file will display the current image size + limit, which is set to 500 MB by default. + +What: /sys/power/pm_trace +Date: August 2006 +Contact: Rafael J. Wysocki <rjw@sisk.pl> +Description: + The /sys/power/pm_trace file controls the code which saves the + last PM event point in the RTC across reboots, so that you can + debug a machine that just hangs during suspend (or more + commonly, during resume). Namely, the RTC is only used to save + the last PM event point if this file contains '1'. Initially + it contains '0' which may be changed to '1' by writing a + string representing a nonzero integer into it. + + To use this debugging feature you should attempt to suspend + the machine, then reboot it and run + + dmesg -s 1000000 | grep 'hash matches' + + CAUTION: Using it will cause your machine's real-time (CMOS) + clock to be set to a random invalid time after a resume. diff --git a/Documentation/CodingStyle b/Documentation/CodingStyle index 6d2412ec91ed..29c18966b050 100644 --- a/Documentation/CodingStyle +++ b/Documentation/CodingStyle @@ -532,6 +532,40 @@ appears outweighs the potential value of the hint that tells gcc to do something it would have done anyway. + Chapter 16: Function return values and names + +Functions can return values of many different kinds, and one of the +most common is a value indicating whether the function succeeded or +failed. Such a value can be represented as an error-code integer +(-Exxx = failure, 0 = success) or a "succeeded" boolean (0 = failure, +non-zero = success). + +Mixing up these two sorts of representations is a fertile source of +difficult-to-find bugs. If the C language included a strong distinction +between integers and booleans then the compiler would find these mistakes +for us... but it doesn't. To help prevent such bugs, always follow this +convention: + + If the name of a function is an action or an imperative command, + the function should return an error-code integer. If the name + is a predicate, the function should return a "succeeded" boolean. + +For example, "add work" is a command, and the add_work() function returns 0 +for success or -EBUSY for failure. In the same way, "PCI device present" is +a predicate, and the pci_dev_present() function returns 1 if it succeeds in +finding a matching device or 0 if it doesn't. + +All EXPORTed functions must respect this convention, and so should all +public functions. Private (static) functions need not, but it is +recommended that they do. + +Functions whose return value is the actual result of a computation, rather +than an indication of whether the computation succeeded, are not subject to +this rule. Generally they indicate failure by returning some out-of-range +result. Typical examples would be functions that return pointers; they use +NULL or the ERR_PTR mechanism to report failure. + + Appendix I: References diff --git a/Documentation/DMA-mapping.txt b/Documentation/DMA-mapping.txt index 63392c9132b4..028614cdd062 100644 --- a/Documentation/DMA-mapping.txt +++ b/Documentation/DMA-mapping.txt @@ -107,7 +107,7 @@ The query is performed via a call to pci_set_dma_mask(): int pci_set_dma_mask(struct pci_dev *pdev, u64 device_mask); -The query for consistent allocations is performed via a a call to +The query for consistent allocations is performed via a call to pci_set_consistent_dma_mask(): int pci_set_consistent_dma_mask(struct pci_dev *pdev, u64 device_mask); @@ -117,7 +117,7 @@ device_mask is a bit mask describing which bits of a PCI address your device supports. It returns zero if your card can perform DMA properly on the machine given the address mask you provided. -If it returns non-zero, your device can not perform DMA properly on +If it returns non-zero, your device cannot perform DMA properly on this platform, and attempting to do so will result in undefined behavior. You must either use a different mask, or not use DMA. diff --git a/Documentation/DocBook/kernel-api.tmpl b/Documentation/DocBook/kernel-api.tmpl index f8fe882e33dc..2b5ac604948c 100644 --- a/Documentation/DocBook/kernel-api.tmpl +++ b/Documentation/DocBook/kernel-api.tmpl @@ -158,6 +158,7 @@ X!Ilib/string.c !Emm/filemap.c !Emm/memory.c !Emm/vmalloc.c +!Imm/page_alloc.c !Emm/mempool.c !Emm/page-writeback.c !Emm/truncate.c @@ -181,27 +182,6 @@ X!Ilib/string.c </sect1> </chapter> - <chapter id="proc"> - <title>The proc filesystem</title> - - <sect1><title>sysctl interface</title> -!Ekernel/sysctl.c - </sect1> - - <sect1><title>proc filesystem interface</title> -!Ifs/proc/base.c - </sect1> - </chapter> - - <chapter id="debugfs"> - <title>The debugfs filesystem</title> - - <sect1><title>debugfs interface</title> -!Efs/debugfs/inode.c -!Efs/debugfs/file.c - </sect1> - </chapter> - <chapter id="vfs"> <title>The Linux VFS</title> <sect1><title>The Filesystem types</title> @@ -234,6 +214,50 @@ X!Ilib/string.c </sect1> </chapter> + <chapter id="proc"> + <title>The proc filesystem</title> + + <sect1><title>sysctl interface</title> +!Ekernel/sysctl.c + </sect1> + + <sect1><title>proc filesystem interface</title> +!Ifs/proc/base.c + </sect1> + </chapter> + + <chapter id="sysfs"> + <title>The Filesystem for Exporting Kernel Objects</title> +!Efs/sysfs/file.c +!Efs/sysfs/symlink.c +!Efs/sysfs/bin.c + </chapter> + + <chapter id="debugfs"> + <title>The debugfs filesystem</title> + + <sect1><title>debugfs interface</title> +!Efs/debugfs/inode.c +!Efs/debugfs/file.c + </sect1> + </chapter> + + <chapter id="relayfs"> + <title>relay interface support</title> + + <para> + Relay interface support + is designed to provide an efficient mechanism for tools and + facilities to relay large amounts of data from kernel space to + user space. + </para> + + <sect1><title>relay interface</title> +!Ekernel/relay.c +!Ikernel/relay.c + </sect1> + </chapter> + <chapter id="netcore"> <title>Linux Networking</title> <sect1><title>Networking Base Types</title> @@ -302,8 +326,13 @@ X!Ekernel/module.c !Ekernel/irq/manage.c </sect1> + <sect1><title>DMA Channels</title> +!Ekernel/dma.c + </sect1> + <sect1><title>Resources Management</title> !Ikernel/resource.c +!Ekernel/resource.c </sect1> <sect1><title>MTRR Handling</title> @@ -349,13 +378,6 @@ X!Earch/i386/kernel/mca.c </sect1> </chapter> - <chapter id="sysfs"> - <title>The Filesystem for Exporting Kernel Objects</title> -!Efs/sysfs/file.c -!Efs/sysfs/symlink.c -!Efs/sysfs/bin.c - </chapter> - <chapter id="security"> <title>Security Framework</title> !Esecurity/security.c @@ -386,6 +408,7 @@ X!Iinclude/linux/device.h --> !Edrivers/base/driver.c !Edrivers/base/core.c +!Edrivers/base/class.c !Edrivers/base/firmware_class.c !Edrivers/base/transport_class.c !Edrivers/base/dmapool.c @@ -437,6 +460,11 @@ X!Edrivers/pnp/system.c !Eblock/ll_rw_blk.c </chapter> + <chapter id="chrdev"> + <title>Char devices</title> +!Efs/char_dev.c + </chapter> + <chapter id="miscdev"> <title>Miscellaneous Devices</title> !Edrivers/char/misc.c diff --git a/Documentation/DocBook/libata.tmpl b/Documentation/DocBook/libata.tmpl index 065e8dc23e3a..07a635590b36 100644 --- a/Documentation/DocBook/libata.tmpl +++ b/Documentation/DocBook/libata.tmpl @@ -14,7 +14,7 @@ </authorgroup> <copyright> - <year>2003-2005</year> + <year>2003-2006</year> <holder>Jeff Garzik</holder> </copyright> @@ -1400,7 +1400,7 @@ and other resources, etc. <listitem> <para> When it's known that HBA is in ready state but ATA/ATAPI - device in in unknown state, reset only device. + device is in unknown state, reset only device. </para> </listitem> diff --git a/Documentation/DocBook/usb.tmpl b/Documentation/DocBook/usb.tmpl index 320af25de3a2..143e5ff7deb8 100644 --- a/Documentation/DocBook/usb.tmpl +++ b/Documentation/DocBook/usb.tmpl @@ -43,59 +43,52 @@ <para>A Universal Serial Bus (USB) is used to connect a host, such as a PC or workstation, to a number of peripheral - devices. USB uses a tree structure, with the host at the + devices. USB uses a tree structure, with the host as the root (the system's master), hubs as interior nodes, and - peripheral devices as leaves (and slaves). + peripherals as leaves (and slaves). Modern PCs support several such trees of USB devices, usually one USB 2.0 tree (480 Mbit/sec each) with a few USB 1.1 trees (12 Mbit/sec each) that are used when you connect a USB 1.1 device directly to the machine's "root hub". </para> - <para>That master/slave asymmetry was designed in part for - ease of use. It is not physically possible to assemble - (legal) USB cables incorrectly: all upstream "to-the-host" - connectors are the rectangular type, matching the sockets on - root hubs, and the downstream type are the squarish type - (or they are built in to the peripheral). - Software doesn't need to deal with distributed autoconfiguration - since the pre-designated master node manages all that. - At the electrical level, bus protocol overhead is reduced by - eliminating arbitration and moving scheduling into host software. + <para>That master/slave asymmetry was designed-in for a number of + reasons, one being ease of use. It is not physically possible to + assemble (legal) USB cables incorrectly: all upstream "to the host" + connectors are the rectangular type (matching the sockets on + root hubs), and all downstream connectors are the squarish type + (or they are built into the peripheral). + Also, the host software doesn't need to deal with distributed + auto-configuration since the pre-designated master node manages all that. + And finally, at the electrical level, bus protocol overhead is reduced by + eliminating arbitration and moving scheduling into the host software. </para> - <para>USB 1.0 was announced in January 1996, and was revised + <para>USB 1.0 was announced in January 1996 and was revised as USB 1.1 (with improvements in hub specification and support for interrupt-out transfers) in September 1998. - USB 2.0 was released in April 2000, including high speed - transfers and transaction translating hubs (used for USB 1.1 + USB 2.0 was released in April 2000, adding high-speed + transfers and transaction-translating hubs (used for USB 1.1 and 1.0 backward compatibility). </para> - <para>USB support was added to Linux early in the 2.2 kernel series - shortly before the 2.3 development forked off. Updates - from 2.3 were regularly folded back into 2.2 releases, bringing - new features such as <filename>/sbin/hotplug</filename> support, - more drivers, and more robustness. - The 2.5 kernel series continued such improvements, and also - worked on USB 2.0 support, - higher performance, - better consistency between host controller drivers, - API simplification (to make bugs less likely), - and providing internal "kerneldoc" documentation. + <para>Kernel developers added USB support to Linux early in the 2.2 kernel + series, shortly before 2.3 development forked. Updates from 2.3 were + regularly folded back into 2.2 releases, which improved reliability and + brought <filename>/sbin/hotplug</filename> support as well more drivers. + Such improvements were continued in the 2.5 kernel series, where they added + USB 2.0 support, improved performance, and made the host controller drivers + (HCDs) more consistent. They also simplified the API (to make bugs less + likely) and added internal "kerneldoc" documentation. </para> <para>Linux can run inside USB devices as well as on the hosts that control the devices. - Because the Linux 2.x USB support evolved to support mass market - platforms such as Apple Macintosh or PC-compatible systems, - it didn't address design concerns for those types of USB systems. - So it can't be used inside mass-market PDAs, or other peripherals. - USB device drivers running inside those Linux peripherals + But USB device drivers running inside those peripherals don't do the same things as the ones running inside hosts, - and so they've been given a different name: - they're called <emphasis>gadget drivers</emphasis>. - This document does not present gadget drivers. + so they've been given a different name: + <emphasis>gadget drivers</emphasis>. + This document does not cover gadget drivers. </para> </chapter> @@ -103,17 +96,14 @@ <chapter id="host"> <title>USB Host-Side API Model</title> - <para>Within the kernel, - host-side drivers for USB devices talk to the "usbcore" APIs. - There are two types of public "usbcore" APIs, targetted at two different - layers of USB driver. Those are - <emphasis>general purpose</emphasis> drivers, exposed through - driver frameworks such as block, character, or network devices; - and drivers that are <emphasis>part of the core</emphasis>, - which are involved in managing a USB bus. - Such core drivers include the <emphasis>hub</emphasis> driver, - which manages trees of USB devices, and several different kinds - of <emphasis>host controller driver (HCD)</emphasis>, + <para>Host-side drivers for USB devices talk to the "usbcore" APIs. + There are two. One is intended for + <emphasis>general-purpose</emphasis> drivers (exposed through + driver frameworks), and the other is for drivers that are + <emphasis>part of the core</emphasis>. + Such core drivers include the <emphasis>hub</emphasis> driver + (which manages trees of USB devices) and several different kinds + of <emphasis>host controller drivers</emphasis>, which control individual busses. </para> @@ -122,21 +112,21 @@ <itemizedlist> - <listitem><para>USB supports four kinds of data transfer - (control, bulk, interrupt, and isochronous). Two transfer - types use bandwidth as it's available (control and bulk), - while the other two types of transfer (interrupt and isochronous) + <listitem><para>USB supports four kinds of data transfers + (control, bulk, interrupt, and isochronous). Two of them (control + and bulk) use bandwidth as it's available, + while the other two (interrupt and isochronous) are scheduled to provide guaranteed bandwidth. </para></listitem> <listitem><para>The device description model includes one or more "configurations" per device, only one of which is active at a time. - Devices that are capable of high speed operation must also support - full speed configurations, along with a way to ask about the - "other speed" configurations that might be used. + Devices that are capable of high-speed operation must also support + full-speed configurations, along with a way to ask about the + "other speed" configurations which might be used. </para></listitem> - <listitem><para>Configurations have one or more "interface", each + <listitem><para>Configurations have one or more "interfaces", each of which may have "alternate settings". Interfaces may be standardized by USB "Class" specifications, or may be specific to a vendor or device.</para> @@ -162,7 +152,7 @@ </para></listitem> <listitem><para>The Linux USB API supports synchronous calls for - control and bulk messaging. + control and bulk messages. It also supports asynchnous calls for all kinds of data transfer, using request structures called "URBs" (USB Request Blocks). </para></listitem> @@ -324,8 +314,7 @@ <emphasis>usbdevfs</emphasis> although it wasn't solving what <emphasis>devfs</emphasis> was. Every USB device will appear in usbfs, regardless of whether or - not it has a kernel driver; but only devices with kernel drivers - show up in devfs. + not it has a kernel driver. </para> <sect1> @@ -463,14 +452,25 @@ file in your Linux kernel sources. </para> - <para>Otherwise the main use for this file from programs - is to poll() it to get notifications of usb devices - as they're plugged or unplugged. - To see what changed, you'd need to read the file and - compare "before" and "after" contents, scan the filesystem, - or see its hotplug event. + <para>This file, in combination with the poll() system call, can + also be used to detect when devices are added or removed: +<programlisting>int fd; +struct pollfd pfd; + +fd = open("/proc/bus/usb/devices", O_RDONLY); +pfd = { fd, POLLIN, 0 }; +for (;;) { + /* The first time through, this call will return immediately. */ + poll(&pfd, 1, -1); + + /* To see what's changed, compare the file's previous and current + contents or scan the filesystem. (Scanning is more precise.) */ +}</programlisting> + Note that this behavior is intended to be used for informational + and debug purposes. It would be more appropriate to use programs + such as udev or HAL to initialize a device or start a user-mode + helper program, for instance. </para> - </sect1> <sect1> @@ -740,7 +740,7 @@ usbdev_ioctl (int fd, int ifno, unsigned request, void *param) <title>Synchronous I/O Support</title> <para>Synchronous requests involve the kernel blocking - until until the user mode request completes, either by + until the user mode request completes, either by finishing successfully or by reporting an error. In most cases this is the simplest way to use usbfs, although as noted above it does prevent performing I/O diff --git a/Documentation/DocBook/writing_usb_driver.tmpl b/Documentation/DocBook/writing_usb_driver.tmpl index 008a341234d0..07cd34c1940b 100644 --- a/Documentation/DocBook/writing_usb_driver.tmpl +++ b/Documentation/DocBook/writing_usb_driver.tmpl @@ -224,13 +224,8 @@ static int skel_probe(struct usb_interface *interface, Conversely, when the device is removed from the USB bus, the disconnect function is called with the device pointer. The driver needs to clean any private data that has been allocated at this time and to shut down any - pending urbs that are in the USB system. The driver also unregisters - itself from the devfs subsystem with the call: + pending urbs that are in the USB system. </para> - <programlisting> -/* remove our devfs node */ -devfs_unregister(skel->devfs); - </programlisting> <para> Now that the device is plugged into the system and the driver is bound to the device, any of the functions in the file_operations structure that diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 915ae8c986c6..d6f3dd1a3464 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -358,7 +358,8 @@ Here is a list of some of the different kernel trees available: quilt trees: - USB, PCI, Driver Core, and I2C, Greg Kroah-Hartman <gregkh@suse.de> kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/ - + - x86-64, partly i386, Andi Kleen <ak@suse.de> + ftp.firstfloor.org:/pub/ak/x86_64/quilt/ Bug Reporting ------------- @@ -374,6 +375,26 @@ of information is needed by the kernel developers to help track down the problem. +Managing bug reports +-------------------- + +One of the best ways to put into practice your hacking skills is by fixing +bugs reported by other people. Not only you will help to make the kernel +more stable, you'll learn to fix real world problems and you will improve +your skills, and other developers will be aware of your presence. Fixing +bugs is one of the best ways to earn merit amongst the developers, because +not many people like wasting time fixing other people's bugs. + +To work in the already reported bug reports, go to http://bugzilla.kernel.org. +If you want to be advised of the future bug reports, you can subscribe to the +bugme-new mailing list (only new bug reports are mailed here) or to the +bugme-janitor mailing list (every change in the bugzilla is mailed here) + + http://lists.osdl.org/mailman/listinfo/bugme-new + http://lists.osdl.org/mailman/listinfo/bugme-janitors + + + Mailing lists ------------- diff --git a/Documentation/IPMI.txt b/Documentation/IPMI.txt index 0256805b548f..0e3924ecd76b 100644 --- a/Documentation/IPMI.txt +++ b/Documentation/IPMI.txt @@ -326,9 +326,12 @@ for events, they will all receive all events that come in. For receiving commands, you have to individually register commands you want to receive. Call ipmi_register_for_cmd() and supply the netfn -and command name for each command you want to receive. Only one user -may be registered for each netfn/cmd, but different users may register -for different commands. +and command name for each command you want to receive. You also +specify a bitmask of the channels you want to receive the command from +(or use IPMI_CHAN_ALL for all channels if you don't care). Only one +user may be registered for each netfn/cmd/channel, but different users +may register for different commands, or the same command if the +channel bitmasks do not overlap. From userland, equivalent IOCTLs are provided to do these functions. @@ -361,6 +364,7 @@ You can change this at module load time (for a module) with: regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,... regshifts=<shift1>,<shift2>,... slave_addrs=<addr1>,<addr2>,... + force_kipmid=<enable1>,<enable2>,... Each of these except si_trydefaults is a list, the first item for the first interface, second item for the second interface, etc. @@ -406,7 +410,13 @@ The slave_addrs specifies the IPMI address of the local BMC. This is usually 0x20 and the driver defaults to that, but in case it's not, it can be specified when the driver starts up. -When compiled into the kernel, the addresses can be specified on the +The force_ipmid parameter forcefully enables (if set to 1) or disables +(if set to 0) the kernel IPMI daemon. Normally this is auto-detected +by the driver, but systems with broken interrupts might need an enable, +or users that don't want the daemon (don't need the performance, don't +want the CPU hit) can disable it. + +When compiled into the kernel, the parameters can be specified on the kernel command line as: ipmi_si.type=<type1>,<type2>... @@ -416,6 +426,7 @@ kernel command line as: ipmi_si.regsizes=<size1>,<size2>,... ipmi_si.regshifts=<shift1>,<shift2>,... ipmi_si.slave_addrs=<addr1>,<addr2>,... + ipmi_si.force_kipmid=<enable1>,<enable2>,... It works the same as the module parameters of the same names. @@ -457,12 +468,12 @@ BMCs specified on the smb_addr line will be detected. Setting smb_dbg_probe to 1 will enable debugging of the probing and detection process for BMCs on the SMBusses. -Discovering the IPMI compilant BMC on the SMBus can cause devices +Discovering the IPMI compliant BMC on the SMBus can cause devices on the I2C bus to fail. The SMBus driver writes a "Get Device ID" IPMI message as a block write to the I2C bus and waits for a response. This action can be detrimental to some I2C devices. It is highly recommended that the known I2c address be given to the SMBus driver in the smb_addr -parameter. The default adrress range will not be used when a smb_addr +parameter. The default address range will not be used when a smb_addr parameter is provided. When compiled into the kernel, the addresses can be specified on the diff --git a/Documentation/MSI-HOWTO.txt b/Documentation/MSI-HOWTO.txt index 3ec6c720b016..c70306abb7b2 100644 --- a/Documentation/MSI-HOWTO.txt +++ b/Documentation/MSI-HOWTO.txt @@ -267,7 +267,7 @@ y = The number of MSI capable devices populated in the system. vector reserved to avoid the case where some MSI-X capable drivers may attempt to claim all available vector resources. -z = The number of MSI-X capable devices pupulated in the system. +z = The number of MSI-X capable devices populated in the system. This policy ensures that maximum (x - y) is distributed evenly among MSI-X capable devices. diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index 1d50cf0c905e..f4dffadbcb00 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -221,3 +221,41 @@ over a rather long period of time, but improvements are always welcome! disable irq on a given acquisition of that lock will result in deadlock as soon as the RCU callback happens to interrupt that acquisition's critical section. + +13. SRCU (srcu_read_lock(), srcu_read_unlock(), and synchronize_srcu()) + may only be invoked from process context. Unlike other forms of + RCU, it -is- permissible to block in an SRCU read-side critical + section (demarked by srcu_read_lock() and srcu_read_unlock()), + hence the "SRCU": "sleepable RCU". Please note that if you + don't need to sleep in read-side critical sections, you should + be using RCU rather than SRCU, because RCU is almost always + faster and easier to use than is SRCU. + + Also unlike other forms of RCU, explicit initialization + and cleanup is required via init_srcu_struct() and + cleanup_srcu_struct(). These are passed a "struct srcu_struct" + that defines the scope of a given SRCU domain. Once initialized, + the srcu_struct is passed to srcu_read_lock(), srcu_read_unlock() + and synchronize_srcu(). A given synchronize_srcu() waits only + for SRCU read-side critical sections governed by srcu_read_lock() + and srcu_read_unlock() calls that have been passd the same + srcu_struct. This property is what makes sleeping read-side + critical sections tolerable -- a given subsystem delays only + its own updates, not those of other subsystems using SRCU. + Therefore, SRCU is less prone to OOM the system than RCU would + be if RCU's read-side critical sections were permitted to + sleep. + + The ability to sleep in read-side critical sections does not + come for free. First, corresponding srcu_read_lock() and + srcu_read_unlock() calls must be passed the same srcu_struct. + Second, grace-period-detection overhead is amortized only + over those updates sharing a given srcu_struct, rather than + being globally amortized as they are for other forms of RCU. + Therefore, SRCU should be used in preference to rw_semaphore + only in extremely read-intensive situations, or in situations + requiring SRCU's read-side deadlock immunity or low read-side + realtime latency. + + Note that, rcu_assign_pointer() and rcu_dereference() relate to + SRCU just as they do to other forms of RCU. diff --git a/Documentation/RCU/rcu.txt b/Documentation/RCU/rcu.txt index 02e27bf1d365..f84407cba816 100644 --- a/Documentation/RCU/rcu.txt +++ b/Documentation/RCU/rcu.txt @@ -45,7 +45,8 @@ o How can I see where RCU is currently used in the Linux kernel? Search for "rcu_read_lock", "rcu_read_unlock", "call_rcu", "rcu_read_lock_bh", "rcu_read_unlock_bh", "call_rcu_bh", - "synchronize_rcu", and "synchronize_net". + "srcu_read_lock", "srcu_read_unlock", "synchronize_rcu", + "synchronize_net", and "synchronize_srcu". o What guidelines should I follow when writing code that uses RCU? diff --git a/Documentation/RCU/torture.txt b/Documentation/RCU/torture.txt index a4948591607d..25a3c3f7d378 100644 --- a/Documentation/RCU/torture.txt +++ b/Documentation/RCU/torture.txt @@ -28,6 +28,15 @@ nreaders This is the number of RCU reading threads supported. To properly exercise RCU implementations with preemptible read-side critical sections. +nfakewriters This is the number of RCU fake writer threads to run. Fake + writer threads repeatedly use the synchronous "wait for + current readers" function of the interface selected by + torture_type, with a delay between calls to allow for various + different numbers of writers running in parallel. + nfakewriters defaults to 4, which provides enough parallelism + to trigger special cases caused by multiple writers, such as + the synchronize_srcu() early return optimization. + stat_interval The number of seconds between output of torture statistics (via printk()). Regardless of the interval, statistics are printed when the module is unloaded. @@ -44,9 +53,12 @@ test_no_idle_hz Whether or not to test the ability of RCU to operate in a kernel that disables the scheduling-clock interrupt to idle CPUs. Boolean parameter, "1" to test, "0" otherwise. -torture_type The type of RCU to test: "rcu" for the rcu_read_lock() - API, "rcu_bh" for the rcu_read_lock_bh() API, and "srcu" - for the "srcu_read_lock()" API. +torture_type The type of RCU to test: "rcu" for the rcu_read_lock() API, + "rcu_sync" for rcu_read_lock() with synchronous reclamation, + "rcu_bh" for the rcu_read_lock_bh() API, "rcu_bh_sync" for + rcu_read_lock_bh() with synchronous reclamation, "srcu" for + the "srcu_read_lock()" API, and "sched" for the use of + preempt_disable() together with synchronize_sched(). verbose Enable debug printk()s. Default is disabled. @@ -118,6 +130,21 @@ o "Free-Block Circulation": Shows the number of torture structures as it is only incremented if a torture structure's counter somehow gets incremented farther than it should. +Different implementations of RCU can provide implementation-specific +additional information. For example, SRCU provides the following: + + srcu-torture: rtc: f8cf46a8 ver: 355 tfle: 0 rta: 356 rtaf: 0 rtf: 346 rtmbe: 0 + srcu-torture: Reader Pipe: 559738 939 0 0 0 0 0 0 0 0 0 + srcu-torture: Reader Batch: 560434 243 0 0 0 0 0 0 0 0 + srcu-torture: Free-Block Circulation: 355 354 353 352 351 350 349 348 347 346 0 + srcu-torture: per-CPU(idx=1): 0(0,1) 1(0,1) 2(0,0) 3(0,1) + +The first four lines are similar to those for RCU. The last line shows +the per-CPU counter state. The numbers in parentheses are the values +of the "old" and "current" counters for the corresponding CPU. The +"idx" value maps the "old" and "current" values to the underlying array, +and is useful for debugging. + USAGE diff --git a/Documentation/RCU/whatisRCU.txt b/Documentation/RCU/whatisRCU.txt index 318df44259b3..e0d6d99b8f9b 100644 --- a/Documentation/RCU/whatisRCU.txt +++ b/Documentation/RCU/whatisRCU.txt @@ -582,7 +582,7 @@ The rcu_read_lock() and rcu_read_unlock() primitive read-acquire and release a global reader-writer lock. The synchronize_rcu() primitive write-acquires this same lock, then immediately releases it. This means that once synchronize_rcu() exits, all RCU read-side -critical sections that were in progress before synchonize_rcu() was +critical sections that were in progress before synchronize_rcu() was called are guaranteed to have completed -- there is no way that synchronize_rcu() would have been able to write-acquire the lock otherwise. @@ -750,7 +750,7 @@ Or, for those who prefer a side-by-side listing: Either way, the differences are quite small. Read-side locking moves to rcu_read_lock() and rcu_read_unlock, update-side locking moves from -from a reader-writer lock to a simple spinlock, and a synchronize_rcu() +a reader-writer lock to a simple spinlock, and a synchronize_rcu() precedes the kfree(). However, there is one potential catch: the read-side and update-side @@ -778,6 +778,8 @@ Markers for RCU read-side critical sections: rcu_read_unlock rcu_read_lock_bh rcu_read_unlock_bh + srcu_read_lock + srcu_read_unlock RCU pointer/list traversal: @@ -804,6 +806,7 @@ RCU grace period: synchronize_net synchronize_sched synchronize_rcu + synchronize_srcu call_rcu call_rcu_bh diff --git a/Documentation/SubmitChecklist b/Documentation/SubmitChecklist index a10bfb6ecd9f..7ac61f60037a 100644 --- a/Documentation/SubmitChecklist +++ b/Documentation/SubmitChecklist @@ -61,3 +61,8 @@ kernel patches. Documentation/kernel-parameters.txt. 18: All new module parameters are documented with MODULE_PARM_DESC() + +19: All new userspace interfaces are documented in Documentation/ABI/. + See Documentation/ABI/README for more information. + +20: Check that it all passes `make headers_check'. diff --git a/Documentation/SubmittingDrivers b/Documentation/SubmittingDrivers index 6bd30fdd0786..58bead05eabb 100644 --- a/Documentation/SubmittingDrivers +++ b/Documentation/SubmittingDrivers @@ -59,11 +59,11 @@ Copyright: The copyright owner must agree to use of GPL. are the same person/entity. If not, the name of the person/entity authorizing use of GPL should be listed in case it's necessary to verify the will of - the copright owner. + the copyright owner. Interfaces: If your driver uses existing interfaces and behaves like other drivers in the same class it will be much more likely - to be accepted than if it invents gratuitous new ones. + to be accepted than if it invents gratuitous new ones. If you need to implement a common API over Linux and NT drivers do it in userspace. @@ -88,7 +88,7 @@ Clarity: It helps if anyone can see how to fix the driver. It helps it will go in the bitbucket. Control: In general if there is active maintainance of a driver by - the author then patches will be redirected to them unless + the author then patches will be redirected to them unless they are totally obvious and without need of checking. If you want to be the contact and update point for the driver it is a good idea to state this in the comments, @@ -100,7 +100,7 @@ What Criteria Do Not Determine Acceptance Vendor: Being the hardware vendor and maintaining the driver is often a good thing. If there is a stable working driver from other people already in the tree don't expect 'we are the - vendor' to get your driver chosen. Ideally work with the + vendor' to get your driver chosen. Ideally work with the existing driver author to build a single perfect driver. Author: It doesn't matter if a large Linux company wrote the driver, @@ -116,17 +116,13 @@ Linux kernel master tree: ftp.??.kernel.org:/pub/linux/kernel/... ?? == your country code, such as "us", "uk", "fr", etc. -Linux kernel mailing list: +Linux kernel mailing list: linux-kernel@vger.kernel.org [mail majordomo@vger.kernel.org to subscribe] Linux Device Drivers, Third Edition (covers 2.6.10): http://lwn.net/Kernel/LDD3/ (free version) -Kernel traffic: - Weekly summary of kernel list activity (much easier to read) - http://www.kerneltraffic.org/kernel-traffic/ - LWN.net: Weekly summary of kernel development activity - http://lwn.net/ 2.6 API changes: @@ -145,11 +141,8 @@ KernelNewbies: Linux USB project: http://www.linux-usb.org/ -How to NOT write kernel driver by arjanv@redhat.com - http://people.redhat.com/arjanv/olspaper.pdf +How to NOT write kernel driver by Arjan van de Ven: + http://www.fenrus.org/how-to-not-write-a-device-driver-paper.pdf Kernel Janitor: http://janitor.kernelnewbies.org/ - --- -Last updated on 17 Nov 2005. diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches index d42ab4c9e893..302d148c2e18 100644 --- a/Documentation/SubmittingPatches +++ b/Documentation/SubmittingPatches @@ -173,15 +173,15 @@ For small patches you may want to CC the Trivial Patch Monkey trivial@kernel.org managed by Adrian Bunk; which collects "trivial" patches. Trivial patches must qualify for one of the following rules: Spelling fixes in documentation - Spelling fixes which could break grep(1). + Spelling fixes which could break grep(1) Warning fixes (cluttering with useless warnings is bad) Compilation fixes (only if they are actually correct) Runtime fixes (only if they actually fix things) - Removing use of deprecated functions/macros (eg. check_region). + Removing use of deprecated functions/macros (eg. check_region) Contact detail and documentation fixes Non-portable code replaced by portable code (even in arch-specific, since people copy, as long as it's trivial) - Any fix by the author/maintainer of the file. (ie. patch monkey + Any fix by the author/maintainer of the file (ie. patch monkey in re-transmission mode) URL: <http://www.kernel.org/pub/linux/kernel/people/bunk/trivial/> @@ -209,6 +209,19 @@ Exception: If your mailer is mangling patches then someone may ask you to re-send them using MIME. +WARNING: Some mailers like Mozilla send your messages with +---- message header ---- +Content-Type: text/plain; charset=us-ascii; format=flowed +---- message header ---- +The problem is that "format=flowed" makes some of the mailers +on receiving side to replace TABs with spaces and do similar +changes. Thus the patches from you can look corrupted. + +To fix this just make your mozilla defaults/pref/mailnews.js file to look like: +pref("mailnews.send_plaintext_flowed", false); // RFC 2646======= +pref("mailnews.display.disable_format_flowed_support", true); + + 7) E-mail size. @@ -245,13 +258,13 @@ updated change. It is quite common for Linus to "drop" your patch without comment. That's the nature of the system. If he drops your patch, it could be due to -* Your patch did not apply cleanly to the latest kernel version +* Your patch did not apply cleanly to the latest kernel version. * Your patch was not sufficiently discussed on linux-kernel. -* A style issue (see section 2), -* An e-mail formatting issue (re-read this section) -* A technical problem with your change -* He gets tons of e-mail, and yours got lost in the shuffle -* You are being annoying (See Figure 1) +* A style issue (see section 2). +* An e-mail formatting issue (re-read this section). +* A technical problem with your change. +* He gets tons of e-mail, and yours got lost in the shuffle. +* You are being annoying. When in doubt, solicit comments on linux-kernel mailing list. @@ -476,10 +489,10 @@ SECTION 3 - REFERENCES Andrew Morton, "The perfect patch" (tpp). <http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt> -Jeff Garzik, "Linux kernel patch submission format." +Jeff Garzik, "Linux kernel patch submission format". <http://linux.yyz.us/patch-format.html> -Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". +Greg Kroah-Hartman, "How to piss off a kernel subsystem maintainer". <http://www.kroah.com/log/2005/03/31/> <http://www.kroah.com/log/2005/07/08/> <http://www.kroah.com/log/2005/10/19/> @@ -488,9 +501,9 @@ Greg Kroah-Hartman "How to piss off a kernel subsystem maintainer". NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people! <http://marc.theaimsgroup.com/?l=linux-kernel&m=112112749912944&w=2> -Kernel Documentation/CodingStyle +Kernel Documentation/CodingStyle: <http://sosdg.org/~coywolf/lxr/source/Documentation/CodingStyle> -Linus Torvald's mail on the canonical patch format: +Linus Torvalds's mail on the canonical patch format: <http://lkml.org/lkml/2005/4/7/183> -- diff --git a/Documentation/accounting/getdelays.c b/Documentation/accounting/getdelays.c index 795ca3911cc5..b11792abd6b6 100644 --- a/Documentation/accounting/getdelays.c +++ b/Documentation/accounting/getdelays.c @@ -285,7 +285,7 @@ int main(int argc, char *argv[]) if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_REGISTER_CPUMASK, - &cpumask, sizeof(cpumask)); + &cpumask, strlen(cpumask) + 1); PRINTF("Sent register cpumask, retval %d\n", rc); if (rc < 0) { printf("error sending register cpumask\n"); @@ -315,7 +315,8 @@ int main(int argc, char *argv[]) } if (msg.n.nlmsg_type == NLMSG_ERROR || !NLMSG_OK((&msg.n), rep_len)) { - printf("fatal reply error, errno %d\n", errno); + struct nlmsgerr *err = NLMSG_DATA(&msg); + printf("fatal reply error, errno %d\n", err->error); goto done; } @@ -383,7 +384,7 @@ done: if (maskset) { rc = send_cmd(nl_sd, id, mypid, TASKSTATS_CMD_GET, TASKSTATS_CMD_ATTR_DEREGISTER_CPUMASK, - &cpumask, sizeof(cpumask)); + &cpumask, strlen(cpumask) + 1); printf("Sent deregister mask, retval %d\n", rc); if (rc < 0) err(rc, "error sending deregister cpumask\n"); diff --git a/Documentation/accounting/taskstats-struct.txt b/Documentation/accounting/taskstats-struct.txt new file mode 100644 index 000000000000..661c797eaf79 --- /dev/null +++ b/Documentation/accounting/taskstats-struct.txt @@ -0,0 +1,161 @@ +The struct taskstats +-------------------- + +This document contains an explanation of the struct taskstats fields. + +There are three different groups of fields in the struct taskstats: + +1) Common and basic accounting fields + If CONFIG_TASKSTATS is set, the taskstats inteface is enabled and + the common fields and basic accounting fields are collected for + delivery at do_exit() of a task. +2) Delay accounting fields + These fields are placed between + /* Delay accounting fields start */ + and + /* Delay accounting fields end */ + Their values are collected if CONFIG_TASK_DELAY_ACCT is set. +3) Extended accounting fields + These fields are placed between + /* Extended accounting fields start */ + and + /* Extended accounting fields end */ + Their values are collected if CONFIG_TASK_XACCT is set. + +Future extension should add fields to the end of the taskstats struct, and +should not change the relative position of each field within the struct. + + +struct taskstats { + +1) Common and basic accounting fields: + /* The version number of this struct. This field is always set to + * TAKSTATS_VERSION, which is defined in <linux/taskstats.h>. + * Each time the struct is changed, the value should be incremented. + */ + __u16 version; + + /* The exit code of a task. */ + __u32 ac_exitcode; /* Exit status */ + + /* The accounting flags of a task as defined in <linux/acct.h> + * Defined values are AFORK, ASU, ACOMPAT, ACORE, and AXSIG. + */ + __u8 ac_flag; /* Record flags */ + + /* The value of task_nice() of a task. */ + __u8 ac_nice; /* task_nice */ + + /* The name of the command that started this task. */ + char ac_comm[TS_COMM_LEN]; /* Command name */ + + /* The scheduling discipline as set in task->policy field. */ + __u8 ac_sched; /* Scheduling discipline */ + + __u8 ac_pad[3]; + __u32 ac_uid; /* User ID */ + __u32 ac_gid; /* Group ID */ + __u32 ac_pid; /* Process ID */ + __u32 ac_ppid; /* Parent process ID */ + + /* The time when a task begins, in [secs] since 1970. */ + __u32 ac_btime; /* Begin time [sec since 1970] */ + + /* The elapsed time of a task, in [usec]. */ + __u64 ac_etime; /* Elapsed time [usec] */ + + /* The user CPU time of a task, in [usec]. */ + __u64 ac_utime; /* User CPU time [usec] */ + + /* The system CPU time of a task, in [usec]. */ + __u64 ac_stime; /* System CPU time [usec] */ + + /* The minor page fault count of a task, as set in task->min_flt. */ + __u64 ac_minflt; /* Minor Page Fault Count */ + + /* The major page fault count of a task, as set in task->maj_flt. */ + __u64 ac_majflt; /* Major Page Fault Count */ + + +2) Delay accounting fields: + /* Delay accounting fields start + * + * All values, until the comment "Delay accounting fields end" are + * available only if delay accounting is enabled, even though the last + * few fields are not delays + * + * xxx_count is the number of delay values recorded + * xxx_delay_total is the corresponding cumulative delay in nanoseconds + * + * xxx_delay_total wraps around to zero on overflow + * xxx_count incremented regardless of overflow + */ + + /* Delay waiting for cpu, while runnable + * count, delay_total NOT updated atomically + */ + __u64 cpu_count; + __u64 cpu_delay_total; + + /* Following four fields atomically updated using task->delays->lock */ + + /* Delay waiting for synchronous block I/O to complete + * does not account for delays in I/O submission + */ + __u64 blkio_count; + __u64 blkio_delay_total; + + /* Delay waiting for page fault I/O (swap in only) */ + __u64 swapin_count; + __u64 swapin_delay_total; + + /* cpu "wall-clock" running time + * On some architectures, value will adjust for cpu time stolen + * from the kernel in involuntary waits due to virtualization. + * Value is cumulative, in nanoseconds, without a corresponding count + * and wraps around to zero silently on overflow + */ + __u64 cpu_run_real_total; + + /* cpu "virtual" running time + * Uses time intervals seen by the kernel i.e. no adjustment + * for kernel's involuntary waits due to virtualization. + * Value is cumulative, in nanoseconds, without a corresponding count + * and wraps around to zero silently on overflow + */ + __u64 cpu_run_virtual_total; + /* Delay accounting fields end */ + /* version 1 ends here */ + + +3) Extended accounting fields + /* Extended accounting fields start */ + + /* Accumulated RSS usage in duration of a task, in MBytes-usecs. + * The current rss usage is added to this counter every time + * a tick is charged to a task's system time. So, at the end we + * will have memory usage multiplied by system time. Thus an + * average usage per system time unit can be calculated. + */ + __u64 coremem; /* accumulated RSS usage in MB-usec */ + + /* Accumulated virtual memory usage in duration of a task. + * Same as acct_rss_mem1 above except that we keep track of VM usage. + */ + __u64 virtmem; /* accumulated VM usage in MB-usec */ + + /* High watermark of RSS usage in duration of a task, in KBytes. */ + __u64 hiwater_rss; /* High-watermark of RSS usage */ + + /* High watermark of VM usage in duration of a task, in KBytes. */ + __u64 hiwater_vm; /* High-water virtual memory usage */ + + /* The following four fields are I/O statistics of a task. */ + __u64 read_char; /* bytes read */ + __u64 write_char; /* bytes written */ + __u64 read_syscalls; /* read syscalls */ + __u64 write_syscalls; /* write syscalls */ + + /* Extended accounting fields end */ + +} diff --git a/Documentation/aoe/todo.txt b/Documentation/aoe/todo.txt index 7fee1e1165bc..c09dfad4aed8 100644 --- a/Documentation/aoe/todo.txt +++ b/Documentation/aoe/todo.txt @@ -7,7 +7,7 @@ not been observed, but it would be nice to eliminate any potential for deadlock under memory pressure. Because ATA over Ethernet is not fragmented by the kernel's IP code, -the destructore member of the struct sk_buff is available to the aoe +the destructor member of the struct sk_buff is available to the aoe driver. By using a mempool for allocating all but the first few sk_buffs, and by registering a destructor, we should be able to efficiently allocate sk_buffs without introducing any potential for diff --git a/Documentation/arm/SA1100/serial_UART b/Documentation/arm/SA1100/serial_UART index aea2e91ca0ef..a63966f1d083 100644 --- a/Documentation/arm/SA1100/serial_UART +++ b/Documentation/arm/SA1100/serial_UART @@ -24,8 +24,8 @@ The SA1100 serial port had its major/minor numbers officially assigned: > 7 = /dev/cusa2 Callout device for ttySA2 > -If you're not using devfs, you must create those inodes in /dev -on the root filesystem used by your SA1100-based device: +You must create those inodes in /dev on the root filesystem used +by your SA1100-based device: mknod ttySA0 c 204 5 mknod ttySA1 c 204 6 diff --git a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt index 000e3d7a78b2..26422f0f9080 100644 --- a/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt +++ b/Documentation/arm/Samsung-S3C24XX/EB2410ITX.txt @@ -38,7 +38,7 @@ MTD --- The NAND and NOR support has been merged from the linux-mtd project. - Any prolbems, see http://www.linux-mtd.infradead.org/ for more + Any problems, see http://www.linux-mtd.infradead.org/ for more information or up-to-date versions of linux-mtd. diff --git a/Documentation/arm/Samsung-S3C24XX/GPIO.txt b/Documentation/arm/Samsung-S3C24XX/GPIO.txt index 0822764ec270..8caea8c237ee 100644 --- a/Documentation/arm/Samsung-S3C24XX/GPIO.txt +++ b/Documentation/arm/Samsung-S3C24XX/GPIO.txt @@ -24,7 +24,7 @@ Headers header include/asm-arm/arch-s3c2410/hardware.h which can be included by #include <asm/arch/hardware.h> - A useful ammount of documentation can be found in the hardware + A useful amount of documentation can be found in the hardware header on how the GPIO functions (and others) work. Whilst a number of these functions do make some checks on what diff --git a/Documentation/arm/Samsung-S3C24XX/Overview.txt b/Documentation/arm/Samsung-S3C24XX/Overview.txt index 3e46d2a31158..dda7ecdde87b 100644 --- a/Documentation/arm/Samsung-S3C24XX/Overview.txt +++ b/Documentation/arm/Samsung-S3C24XX/Overview.txt @@ -80,7 +80,7 @@ Machines Adding New Machines ------------------- - The archicture has been designed to support as many machines as can + The architecture has been designed to support as many machines as can be configured for it in one kernel build, and any future additions should keep this in mind before altering items outside of their own machine files. diff --git a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt index cb82a7fc7901..295d971a15ed 100644 --- a/Documentation/arm/Samsung-S3C24XX/S3C2412.txt +++ b/Documentation/arm/Samsung-S3C24XX/S3C2412.txt @@ -80,7 +80,7 @@ RTC Watchdog -------- - The watchdog harware is the same as the S3C2410, and is supported by + The watchdog hardware is the same as the S3C2410, and is supported by the s3c2410_wdt driver. diff --git a/Documentation/block/as-iosched.txt b/Documentation/block/as-iosched.txt index 6f47332c883d..e2a66f8143c5 100644 --- a/Documentation/block/as-iosched.txt +++ b/Documentation/block/as-iosched.txt @@ -99,8 +99,8 @@ contrast, many write requests may be dispatched to the disk controller at a time during a write batch. It is this characteristic that can make the anticipatory scheduler perform anomalously with controllers supporting TCQ, or with hardware striped RAID devices. Setting the antic_expire -queue paramter (see below) to zero disables this behavior, and the anticipatory -scheduler behaves essentially like the deadline scheduler. +queue parameter (see below) to zero disables this behavior, and the +anticipatory scheduler behaves essentially like the deadline scheduler. When read anticipation is enabled (antic_expire is not zero), reads are dispatched to the disk controller one at a time. diff --git a/Documentation/block/barrier.txt b/Documentation/block/barrier.txt index 03971518b222..a272c3db8094 100644 --- a/Documentation/block/barrier.txt +++ b/Documentation/block/barrier.txt @@ -25,7 +25,7 @@ of the following three ways. i. For devices which have queue depth greater than 1 (TCQ devices) and support ordered tags, block layer can just issue the barrier as an ordered request and the lower level driver, controller and drive -itself are responsible for making sure that the ordering contraint is +itself are responsible for making sure that the ordering constraint is met. Most modern SCSI controllers/drives should support this. NOTE: SCSI ordered tag isn't currently used due to limitation in the @@ -42,7 +42,7 @@ iii. Devices which have queue depth of 1. This is a degenerate case of ii. Just keeping issue order suffices. Ancient SCSI controllers/drives and IDE drives are in this category. -2. Forced flushing to physcial medium +2. Forced flushing to physical medium Again, if you're not gonna do synchronization with disk drives (dang, it sounds even more appealing now!), the reason you use I/O barriers @@ -56,7 +56,7 @@ There are four cases, i. No write-back cache. Keeping requests ordered is enough. ii. Write-back cache but no flush operation. There's no way to -gurantee physical-medium commit order. This kind of devices can't to +guarantee physical-medium commit order. This kind of devices can't to I/O barriers. iii. Write-back cache and flush operation but no FUA (forced unit diff --git a/Documentation/block/biodoc.txt b/Documentation/block/biodoc.txt index f989a9e839b4..34bf8f60d8f8 100644 --- a/Documentation/block/biodoc.txt +++ b/Documentation/block/biodoc.txt @@ -135,7 +135,7 @@ Some new queue property settings: Sets two variables that limit the size of the request. - The request queue's max_sectors, which is a soft size in - in units of 512 byte sectors, and could be dynamically varied + units of 512 byte sectors, and could be dynamically varied by the core kernel. - The request queue's max_hw_sectors, which is a hard limit @@ -783,7 +783,7 @@ all the outstanding requests. There's a third helper to do that: blk_queue_invalidate_tags(request_queue_t *q) - Clear the internal block tag queue and readd all the pending requests + Clear the internal block tag queue and re-add all the pending requests to the request queue. The driver will receive them again on the next request_fn run, just like it did the first time it encountered them. @@ -890,7 +890,7 @@ Aside: Kvec i/o: - Ben LaHaise's aio code uses a slighly different structure instead + Ben LaHaise's aio code uses a slightly different structure instead of kiobufs, called a kvec_cb. This contains an array of <page, offset, len> tuples (very much like the networking code), together with a callback function and data pointer. This is embedded into a brw_cb structure when passed @@ -988,7 +988,7 @@ elevator_exit_fn Allocate and free any elevator specific storage for a queue. 4.2 Request flows seen by I/O schedulers -All requests seens by I/O schedulers strictly follow one of the following three +All requests seen by I/O schedulers strictly follow one of the following three flows. set_req_fn -> @@ -1203,6 +1203,6 @@ temporarily map a bio into the virtual address space. and Linus' comments - Jan 2001) 9.2 Discussions about kiobuf and bh design on lkml between sct, linus, alan et al - Feb-March 2001 (many of the initial thoughts that led to bio were -brought up in this discusion thread) +brought up in this discussion thread) 9.3 Discussions on mempool on lkml - Dec 2001. diff --git a/Documentation/block/deadline-iosched.txt b/Documentation/block/deadline-iosched.txt index c918b3a6022d..be08ffd1e9b8 100644 --- a/Documentation/block/deadline-iosched.txt +++ b/Documentation/block/deadline-iosched.txt @@ -23,11 +23,11 @@ you can do so by typing: read_expire (in ms) ----------- -The goal of the deadline io scheduler is to attempt to guarentee a start +The goal of the deadline io scheduler is to attempt to guarantee a start service time for a request. As we focus mainly on read latencies, this is tunable. When a read request first enters the io scheduler, it is assigned a deadline that is the current time + the read_expire value in units of -miliseconds. +milliseconds. write_expire (in ms) diff --git a/Documentation/cciss.txt b/Documentation/cciss.txt index 9c629ffa0e58..f74affe5c829 100644 --- a/Documentation/cciss.txt +++ b/Documentation/cciss.txt @@ -80,7 +80,7 @@ the /proc filesystem entry which the "block" side of the driver creates as the SCSI core may not yet be initialized (because the driver is a block driver) and attempting to register it with the SCSI core in such a case would cause a hang. This is best done via an initialization script -(typically in /etc/init.d, but could vary depending on distibution). +(typically in /etc/init.d, but could vary depending on distribution). For example: for x in /proc/driver/cciss/cciss[0-9]* @@ -152,7 +152,7 @@ side during the SCSI error recovery process, the cciss driver only implements the first two of these actions, aborting the command, and resetting the device. Additionally, most tape drives will not oblige in aborting commands, and sometimes it appears they will not even -obey a reset coommand, though in most circumstances they will. In +obey a reset command, though in most circumstances they will. In the case that the command cannot be aborted and the device cannot be reset, the device will be set offline. diff --git a/Documentation/computone.txt b/Documentation/computone.txt index b1cf59b84d97..5e2a0c76bfa0 100644 --- a/Documentation/computone.txt +++ b/Documentation/computone.txt @@ -199,30 +199,6 @@ boxes this will leave gaps in the sequence of device names. ip2mkdev uses Linux tty naming conventions: ttyF0 - ttyF255 for normal devices, and cuf0 - cuf255 for callout devices. -If you are using devfs, existing devices are automatically created within -the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout -devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will -create symbolic links in /dev from the old conventional names to the newer -devfs names as follows: - - /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 - /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 - /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 - /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 - -Only devices for existing ports and boards will be created. - -IMPORTANT NOTE: The naming convention used for devfs by this driver -was changed from 1.2.12 to 1.2.13. The old naming convention was to -use ttf/%d for the tty device and cuf/%d for the cua device. That -has been changed to conform to an agreed-upon standard of placing -all the tty devices under tts. The device names are now tts/F%d for -the tty device and cua/F%d for the cua devices. If you were using -the older devfs names, you must update for the newer convention. - -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - 4. USING THE DRIVERS @@ -256,57 +232,15 @@ cut out and run as "ip2mkdev" to create the necessary device files. To use the ip2mkdev script, you must have procfs enabled and the proc file system mounted on /proc. -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - - -6. DEVFS - -DEVFS is the DEVice File System available as an add on package for the -2.2.x kernels and available as a configuration option in 2.3.46 and higher. -Devfs allows for the automatic creation and management of device names -under control of the device drivers themselves. The Devfs namespace is -hierarchical and reduces the clutter present in the normal flat /dev -namespace. Devfs names and conventional device names may be intermixed. -A userspace daemon, devfsd, exists to allow for automatic creation and -management of symbolic links from the devfs name space to the conventional -names. More details on devfs can be found on the DEVFS home site at -<http://www.atnf.csiro.au/~rgooch/linux/> or in the file kernel -documentation files, .../linux/Documentation/filesystems/devfs/README. - -If you are using devfs, existing devices are automatically created within -the devfs name space. Normal devices will be tts/F0 - tts/F255 and callout -devices will be cua/F0 - cua/F255. With devfs installed, ip2mkdev will -create symbolic links in /dev from the old conventional names to the newer -devfs names as follows: - - /dev/ip2ipl[n] -> /dev/ip2/ipl[n] n = 0 - 3 - /dev/ip2stat[n] -> /dev/ip2/stat[n] n = 0 - 3 - /dev/ttyF[n] -> /dev/tts/F[n] n = 0 - 255 - /dev/cuf[n] -> /dev/cua/F[n] n = 0 - 255 - -Only devices for existing ports and boards will be created. - -IMPORTANT NOTE: The naming convention used for devfs by this driver -was changed from 1.2.12 to 1.2.13. The old naming convention was to -use ttf/%d for the tty device and cuf/%d for the cua device. That -has been changed to conform to an agreed-upon standard of placing -all the tty devices under tts. The device names are now tts/F%d for -the tty device and cua/F%d for the cua devices. If you were using -the older devfs names, you must update for the newer convention. - -You do not need to run ip2mkdev if you are using devfs and only want to -use the devfs native device names. - -7. NOTES +6. NOTES This is a release version of the driver, but it is impossible to test it in all configurations of Linux. If there is any anomalous behaviour that does not match the standard serial port's behaviour please let us know. -8. ip2mkdev shell script +7. ip2mkdev shell script Previously, this script was simply attached here. It is now attached as a shar archive to make it easier to extract the script from the documentation. diff --git a/Documentation/cpu-freq/cpufreq-stats.txt b/Documentation/cpu-freq/cpufreq-stats.txt index 6a82948ff4bd..53d62c1e1c94 100644 --- a/Documentation/cpu-freq/cpufreq-stats.txt +++ b/Documentation/cpu-freq/cpufreq-stats.txt @@ -1,5 +1,5 @@ - CPU frequency and voltage scaling statictics in the Linux(TM) kernel + CPU frequency and voltage scaling statistics in the Linux(TM) kernel L i n u x c p u f r e q - s t a t s d r i v e r @@ -18,8 +18,8 @@ Contents 1. Introduction cpufreq-stats is a driver that provices CPU frequency statistics for each CPU. -This statistics is provided in /sysfs as a bunch of read_only interfaces. This -interface (when configured) will appear in a seperate directory under cpufreq +These statistics are provided in /sysfs as a bunch of read_only interfaces. This +interface (when configured) will appear in a separate directory under cpufreq in /sysfs (<sysfs root>/devices/system/cpu/cpuX/cpufreq/stats/) for each CPU. Various statistics will form read_only files under this directory. @@ -53,7 +53,7 @@ drwxr-xr-x 3 root root 0 May 14 15:58 .. This gives the amount of time spent in each of the frequencies supported by this CPU. The cat output will have "<frequency> <time>" pair in each line, which will mean this CPU spent <time> usertime units of time at <frequency>. Output -will have one line for each of the supported freuencies. usertime units here +will have one line for each of the supported frequencies. usertime units here is 10mS (similar to other time exported in /proc). -------------------------------------------------------------------------------- @@ -115,7 +115,7 @@ basic statistics which includes time_in_state and total_trans. "CPU frequency translation statistics details" (CONFIG_CPU_FREQ_STAT_DETAILS) provides fine grained cpufreq stats by trans_table. The reason for having a -seperate config option for trans_table is: +separate config option for trans_table is: - trans_table goes against the traditional /sysfs rule of one value per interface. It provides a whole bunch of value in a 2 dimensional matrix form. diff --git a/Documentation/cpu-freq/governors.txt b/Documentation/cpu-freq/governors.txt index f4b8dc4237e6..6a9c55bd556b 100644 --- a/Documentation/cpu-freq/governors.txt +++ b/Documentation/cpu-freq/governors.txt @@ -57,7 +57,7 @@ selected for each specific use. Basically, it's the following flow graph: -CPU can be set to switch independetly | CPU can only be set +CPU can be set to switch independently | CPU can only be set within specific "limits" | to specific frequencies "CPUfreq policy" @@ -109,7 +109,7 @@ directory. 2.4 Ondemand ------------ -The CPUfreq govenor "ondemand" sets the CPU depending on the +The CPUfreq governor "ondemand" sets the CPU depending on the current usage. To do this the CPU must have the capability to switch the frequency very quickly. There are a number of sysfs file accessible parameters: @@ -137,11 +137,11 @@ have to be made in a row before the CPU frequency is actually lower. If set to '1' then the frequency decreases as quickly as it increases, if set to '2' it decreases at half the rate of the increase. -ignore_nice_load: this parameter takes a value of '0' or '1', when set -to '0' (its default) then all processes are counted towards towards the -'cpu utilisation' value. When set to '1' then processes that are +ignore_nice_load: this parameter takes a value of '0' or '1'. When +set to '0' (its default), all processes are counted towards the +'cpu utilisation' value. When set to '1', the processes that are run with a 'nice' value will not count (and thus be ignored) in the -overal usage calculation. This is useful if you are running a CPU +overall usage calculation. This is useful if you are running a CPU intensive calculation on your laptop that you do not care how long it takes to complete as you can 'nice' it and prevent it from taking part in the deciding process of whether to increase your CPU frequency. diff --git a/Documentation/cpusets.txt b/Documentation/cpusets.txt index 76b44290c154..842f0d1ab216 100644 --- a/Documentation/cpusets.txt +++ b/Documentation/cpusets.txt @@ -217,11 +217,11 @@ exclusive cpuset. Also, the use of a Linux virtual file system (vfs) to represent the cpuset hierarchy provides for a familiar permission and name space for cpusets, with a minimum of additional kernel code. -The cpus file in the root (top_cpuset) cpuset is read-only. -It automatically tracks the value of cpu_online_map, using a CPU -hotplug notifier. If and when memory nodes can be hotplugged, -we expect to make the mems file in the root cpuset read-only -as well, and have it track the value of node_online_map. +The cpus and mems files in the root (top_cpuset) cpuset are +read-only. The cpus file automatically tracks the value of +cpu_online_map using a CPU hotplug notifier, and the mems file +automatically tracks the value of node_online_map using the +cpuset_track_online_nodes() hook. 1.4 What are exclusive cpusets ? diff --git a/Documentation/cputopology.txt b/Documentation/cputopology.txt index 2b28e9ec4e3a..b61cb9564023 100644 --- a/Documentation/cputopology.txt +++ b/Documentation/cputopology.txt @@ -26,7 +26,7 @@ The type of **_id is int. The type of siblings is cpumask_t. To be consistent on all architectures, the 4 attributes should have -deafult values if their values are unavailable. Below is the rule. +default values if their values are unavailable. Below is the rule. 1) physical_package_id: If cpu has no physical package id, -1 is the default value. 2) core_id: If cpu doesn't support multi-core, its core id is 0. diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt index 941343a7a265..2c0d631de0cf 100644 --- a/Documentation/dell_rbu.txt +++ b/Documentation/dell_rbu.txt @@ -4,7 +4,7 @@ for updating BIOS images on Dell servers and desktops. Scope: This document discusses the functionality of the rbu driver only. -It does not cover the support needed from aplications to enable the BIOS to +It does not cover the support needed from applications to enable the BIOS to update itself with the image downloaded in to the memory. Overview: @@ -16,8 +16,8 @@ OpenManage and Dell Update packages (DUP). Libsmbios can also be used to update BIOS on Dell systems go to http://linux.dell.com/libsmbios/ for details. -Dell_RBU driver supports BIOS update using the monilothic image and packetized -image methods. In case of moniolithic the driver allocates a contiguous chunk +Dell_RBU driver supports BIOS update using the monolithic image and packetized +image methods. In case of monolithic the driver allocates a contiguous chunk of physical pages having the BIOS image. In case of packetized the app using the driver breaks the image in to packets of fixed sizes and the driver would place each packet in contiguous physical memory. The driver also @@ -41,7 +41,7 @@ The driver supports two types of update mechanism; monolithic and packetized. These update mechanism depends upon the BIOS currently running on the system. Most of the Dell systems support a monolithic update where the BIOS image is copied to a single contiguous block of physical memory. -In case of packet mechanism the single memory can be broken in smaller chuks +In case of packet mechanism the single memory can be broken in smaller chunks of contiguous memory and the BIOS image is scattered in these packets. By default the driver uses monolithic memory for the update type. This can be @@ -52,11 +52,11 @@ echo packet > /sys/devices/platform/dell_rbu/image_type In packet update mode the packet size has to be given before any packets can be downloaded. It is done as below echo XXXX > /sys/devices/platform/dell_rbu/packet_size -In the packet update mechanism, the user neesd to create a new file having +In the packet update mechanism, the user needs to create a new file having packets of data arranged back to back. It can be done as follows The user creates packets header, gets the chunk of the BIOS image and -placs it next to the packetheader; now, the packetheader + BIOS image chunk -added to geather should match the specified packet_size. This makes one +places it next to the packetheader; now, the packetheader + BIOS image chunk +added together should match the specified packet_size. This makes one packet, the user needs to create more such packets out of the entire BIOS image file and then arrange all these packets back to back in to one single file. @@ -93,8 +93,8 @@ read back the image downloaded. NOTE: This driver requires a patch for firmware_class.c which has the modified request_firmware_nowait function. -Also after updating the BIOS image an user mdoe application neeeds to execute -code which message the BIOS update request to the BIOS. So on the next reboot -the BIOS knows about the new image downloaded and it updates it self. -Also don't unload the rbu drive if the image has to be updated. +Also after updating the BIOS image a user mode application needs to execute +code which sends the BIOS update request to the BIOS. So on the next reboot +the BIOS knows about the new image downloaded and it updates itself. +Also don't unload the rbu driver if the image has to be updated. diff --git a/Documentation/devices.txt b/Documentation/devices.txt index 66c725f530f3..28c4f79662c2 100644 --- a/Documentation/devices.txt +++ b/Documentation/devices.txt @@ -2005,7 +2005,7 @@ Your cooperation is appreciated. 116 char Advanced Linux Sound Driver (ALSA) 116 block MicroMemory battery backed RAM adapter (NVRAM) - Supports 16 boards, 15 paritions each. + Supports 16 boards, 15 partitions each. Requested by neilb at cse.unsw.edu.au. 0 = /dev/umem/d0 Whole of first board @@ -2543,6 +2543,9 @@ Your cooperation is appreciated. 64 = /dev/usb/rio500 Diamond Rio 500 65 = /dev/usb/usblcd USBLCD Interface (info@usblcd.de) 66 = /dev/usb/cpad0 Synaptics cPad (mouse/LCD) + 67 = /dev/usb/adutux0 1st Ontrak ADU device + ... + 76 = /dev/usb/adutux10 10th Ontrak ADU device 96 = /dev/usb/hiddev0 1st USB HID device ... 111 = /dev/usb/hiddev15 16th USB HID device @@ -3091,7 +3094,7 @@ Your cooperation is appreciated. This major is reserved to assist the expansion to a larger number space. No device nodes with this major should ever be created on the filesystem. - (This is probaly not true anymore, but I'll leave it + (This is probably not true anymore, but I'll leave it for now /Torben) ---LARGE MAJORS!!!!!--- @@ -3202,7 +3205,7 @@ for a session; this includes virtual consoles, serial ports, and pseudoterminals (PTYs). All terminal devices share a common set of capabilities known as line -diciplines; these include the common terminal line dicipline as well +disciplines; these include the common terminal line discipline as well as SLIP and PPP modes. All terminal devices are named similarly; this section explains the @@ -3282,7 +3285,7 @@ port TTY, for which no alternate device would exist. Pseudoterminals (PTYs) Pseudoterminals, or PTYs, are used to create login sessions or provide -other capabilities requiring a TTY line dicipline (including SLIP or +other capabilities requiring a TTY line discipline (including SLIP or PPP capability) to arbitrary data-generation processes. Each PTY has a master side, named /dev/pty[p-za-e][0-9a-f], and a slave side, named /dev/tty[p-za-e][0-9a-f]. The kernel arbitrates the use of PTYs by diff --git a/Documentation/driver-model/class.txt b/Documentation/driver-model/class.txt index 2d1d893a5e5d..548505f14aa4 100644 --- a/Documentation/driver-model/class.txt +++ b/Documentation/driver-model/class.txt @@ -12,7 +12,7 @@ device. The following device classes have been identified: Each device class defines a set of semantics and a programming interface that devices of that class adhere to. Device drivers are the -implemention of that programming interface for a particular device on +implementation of that programming interface for a particular device on a particular bus. Device classes are agnostic with respect to what bus a device resides diff --git a/Documentation/driver-model/driver.txt b/Documentation/driver-model/driver.txt index 59806c9761f7..82132169d47a 100644 --- a/Documentation/driver-model/driver.txt +++ b/Documentation/driver-model/driver.txt @@ -178,7 +178,7 @@ the driver to that device. A driver's probe() may return a negative errno value to indicate that the driver did not bind to this device, in which case it should have -released all reasources it allocated. +released all resources it allocated. int (*remove) (struct device * dev); diff --git a/Documentation/driver-model/overview.txt b/Documentation/driver-model/overview.txt index 2050c9ffc629..07236ed968da 100644 --- a/Documentation/driver-model/overview.txt +++ b/Documentation/driver-model/overview.txt @@ -57,7 +57,7 @@ the two. The PCI bus layer freely accesses the fields of struct device. It knows about the structure of struct pci_dev, and it should know the structure of struct -device. Individual PCI device drivers that have been converted the the current +device. Individual PCI device drivers that have been converted to the current driver model generally do not and should not touch the fields of struct device, unless there is a strong compelling reason to do so. diff --git a/Documentation/dvb/avermedia.txt b/Documentation/dvb/avermedia.txt index 8bab8461a4af..e44c009ac6c5 100644 --- a/Documentation/dvb/avermedia.txt +++ b/Documentation/dvb/avermedia.txt @@ -45,9 +45,9 @@ Assumptions and Introduction by circuitry on the card and is often presented uncompressed. For a PAL TV signal encoded at a resolution of 768x576 24-bit color pixels over 25 frames per second - a fair amount of data - is generated and must be proceesed by the PC before it can be + is generated and must be processed by the PC before it can be displayed on the video monitor screen. Some Analogue TV cards - for PC's have onboard MPEG2 encoders which permit the raw + for PCs have onboard MPEG2 encoders which permit the raw digital data stream to be presented to the PC in an encoded and compressed form - similar to the form that is used in Digital TV. diff --git a/Documentation/dvb/cards.txt b/Documentation/dvb/cards.txt index 9e10092440e1..ca58e339d85f 100644 --- a/Documentation/dvb/cards.txt +++ b/Documentation/dvb/cards.txt @@ -5,7 +5,7 @@ Hardware supported by the linuxtv.org DVB drivers frontends (i.e. tuner / demodulator units) used, usually without changing the product name, revision number or specs. Some cards are also available in versions with different frontends for - DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed seperately. + DVB-S/DVB-C/DVB-T. Thus the frontend drivers are listed separately. Note 1: There is no guarantee that every frontend driver works out of the box with every card, because of different wiring. diff --git a/Documentation/dvb/ci.txt b/Documentation/dvb/ci.txt index 95f0e73b2135..531239b29082 100644 --- a/Documentation/dvb/ci.txt +++ b/Documentation/dvb/ci.txt @@ -32,7 +32,7 @@ This application requires the following to function properly as of now. descrambler to function, eg: $ ca_zap channels.conf "TMC" - (d) Hopeflly Enjoy your favourite subscribed channel as you do with + (d) Hopefully enjoy your favourite subscribed channel as you do with a FTA card. (3) Currently ca_zap, and dst_test, both are meant for demonstration @@ -65,7 +65,7 @@ Modules that have been tested by this driver at present are ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ With the High Level CI approach any new card with almost any random architecture can be implemented with this style, the definitions -insidethe switch statement can be easily adapted for any card, thereby +inside the switch statement can be easily adapted for any card, thereby eliminating the need for any additional ioctls. The disadvantage is that the driver/hardware has to manage the rest. For diff --git a/Documentation/dvb/faq.txt b/Documentation/dvb/faq.txt index a42132d60dc8..dbcedf5833ee 100644 --- a/Documentation/dvb/faq.txt +++ b/Documentation/dvb/faq.txt @@ -5,7 +5,7 @@ Some very frequently asked questions about linuxtv-dvb It's not a bug, it's a feature. Because the frontends have significant power requirements (and hence get very hot), they are powered down if they are unused (i.e. if the frontend device - is closed). The dvb-core.o module paramter "dvb_shutdown_timeout" + is closed). The dvb-core.o module parameter "dvb_shutdown_timeout" allow you to change the timeout (default 5 seconds). Setting the timeout to 0 disables the timeout feature. @@ -138,7 +138,7 @@ Some very frequently asked questions about linuxtv-dvb - v4l2-common: common functions for Video4Linux-2 drivers - - v4l1-compat: backward compatiblity layer for Video4Linux-1 legacy + - v4l1-compat: backward compatibility layer for Video4Linux-1 legacy applications - dvb-core: DVB core module. This provides you with the @@ -153,7 +153,7 @@ Some very frequently asked questions about linuxtv-dvb - video-buf: capture helper module for the saa7146_vv driver. This one is responsible to handle capture buffers. - - dvb-ttpci: The main driver for AV7110 based, full-featued + - dvb-ttpci: The main driver for AV7110 based, full-featured DVB-S/C/T cards eof diff --git a/Documentation/ecryptfs.txt b/Documentation/ecryptfs.txt new file mode 100644 index 000000000000..01d8a08351ac --- /dev/null +++ b/Documentation/ecryptfs.txt @@ -0,0 +1,77 @@ +eCryptfs: A stacked cryptographic filesystem for Linux + +eCryptfs is free software. Please see the file COPYING for details. +For documentation, please see the files in the doc/ subdirectory. For +building and installation instructions please see the INSTALL file. + +Maintainer: Phillip Hellewell +Lead developer: Michael A. Halcrow <mhalcrow@us.ibm.com> +Developers: Michael C. Thompson + Kent Yoder +Web Site: http://ecryptfs.sf.net + +This software is currently undergoing development. Make sure to +maintain a backup copy of any data you write into eCryptfs. + +eCryptfs requires the userspace tools downloadable from the +SourceForge site: + +http://sourceforge.net/projects/ecryptfs/ + +Userspace requirements include: + - David Howells' userspace keyring headers and libraries (version + 1.0 or higher), obtainable from + http://people.redhat.com/~dhowells/keyutils/ + - Libgcrypt + + +NOTES + +In the beta/experimental releases of eCryptfs, when you upgrade +eCryptfs, you should copy the files to an unencrypted location and +then copy the files back into the new eCryptfs mount to migrate the +files. + + +MOUNT-WIDE PASSPHRASE + +Create a new directory into which eCryptfs will write its encrypted +files (i.e., /root/crypt). Then, create the mount point directory +(i.e., /mnt/crypt). Now it's time to mount eCryptfs: + +mount -t ecryptfs /root/crypt /mnt/crypt + +You should be prompted for a passphrase and a salt (the salt may be +blank). + +Try writing a new file: + +echo "Hello, World" > /mnt/crypt/hello.txt + +The operation will complete. Notice that there is a new file in +/root/crypt that is at least 12288 bytes in size (depending on your +host page size). This is the encrypted underlying file for what you +just wrote. To test reading, from start to finish, you need to clear +the user session keyring: + +keyctl clear @u + +Then umount /mnt/crypt and mount again per the instructions given +above. + +cat /mnt/crypt/hello.txt + + +NOTES + +eCryptfs version 0.1 should only be mounted on (1) empty directories +or (2) directories containing files only created by eCryptfs. If you +mount a directory that has pre-existing files not created by eCryptfs, +then behavior is undefined. Do not run eCryptfs in higher verbosity +levels unless you are doing so for the sole purpose of debugging or +development, since secret values will be written out to the system log +in that case. + + +Mike Halcrow +mhalcrow@us.ibm.com diff --git a/Documentation/eisa.txt b/Documentation/eisa.txt index 8c8388da868a..6a099edadd62 100644 --- a/Documentation/eisa.txt +++ b/Documentation/eisa.txt @@ -18,7 +18,7 @@ The EISA infrastructure is made up of three parts : - The bus code implements most of the generic code. It is shared among all the architectures that the EISA code runs on. It - implements bus probing (detecting EISA cards avaible on the bus), + implements bus probing (detecting EISA cards available on the bus), allocates I/O resources, allows fancy naming through sysfs, and offers interfaces for driver to register. @@ -84,7 +84,7 @@ struct eisa_driver { id_table : an array of NULL terminated EISA id strings, followed by an empty string. Each string can - optionnaly be paired with a driver-dependant value + optionally be paired with a driver-dependant value (driver_data). driver : a generic driver, such as described in diff --git a/Documentation/exception.txt b/Documentation/exception.txt index 3cb39ade290e..2d5aded64247 100644 --- a/Documentation/exception.txt +++ b/Documentation/exception.txt @@ -10,7 +10,7 @@ int verify_area(int type, const void * addr, unsigned long size) function (which has since been replaced by access_ok()). This function verified that the memory area starting at address -addr and of size size was accessible for the operation specified +'addr' and of size 'size' was accessible for the operation specified in type (read or write). To do this, verify_read had to look up the virtual memory area (vma) that contained the address addr. In the normal case (correctly working program), this test was successful. diff --git a/Documentation/fb/fbcon.txt b/Documentation/fb/fbcon.txt index f373df12ed4c..99ea58e65eff 100644 --- a/Documentation/fb/fbcon.txt +++ b/Documentation/fb/fbcon.txt @@ -163,7 +163,7 @@ from the console layer before unloading the driver. The VGA driver cannot be unloaded if it is still bound to the console layer. (See Documentation/console/console.txt for more information). -This is more complicated in the case of the the framebuffer console (fbcon), +This is more complicated in the case of the framebuffer console (fbcon), because fbcon is an intermediate layer between the console and the drivers: console ---> fbcon ---> fbdev drivers ---> hardware diff --git a/Documentation/fb/intel810.txt b/Documentation/fb/intel810.txt index 4f0d6bc789ef..be3e7836abef 100644 --- a/Documentation/fb/intel810.txt +++ b/Documentation/fb/intel810.txt @@ -9,8 +9,9 @@ Intel 810/815 Framebuffer driver ================================================================ A. Introduction + This is a framebuffer driver for various Intel 810/815 compatible -graphics devices. These would include: + graphics devices. These include: Intel 810 Intel 810E @@ -21,136 +22,136 @@ graphics devices. These would include: B. Features - - Choice of using Discrete Video Timings, VESA Generalized Timing + - Choice of using Discrete Video Timings, VESA Generalized Timing Formula, or a framebuffer specific database to set the video mode - - Supports a variable range of horizontal and vertical resolution, and - vertical refresh rates if the VESA Generalized Timing Formula is + - Supports a variable range of horizontal and vertical resolution and + vertical refresh rates if the VESA Generalized Timing Formula is enabled. - - Supports color depths of 8, 16, 24 and 32 bits per pixel + - Supports color depths of 8, 16, 24 and 32 bits per pixel - Supports pseudocolor, directcolor, or truecolor visuals - - Full and optimized hardware acceleration at 8, 16 and 24 bpp + - Full and optimized hardware acceleration at 8, 16 and 24 bpp - Robust video state save and restore - - MTRR support + - MTRR support - Utilizes user-entered monitor specifications to automatically calculate required video mode parameters. - - Can concurrently run with xfree86 running with native i810 drivers + - Can concurrently run with xfree86 running with native i810 drivers - Hardware Cursor Support - Supports EDID probing either by DDC/I2C or through the BIOS C. List of available options - - a. "video=i810fb" + + a. "video=i810fb" enables the i810 driver Recommendation: required - - b. "xres:<value>" + + b. "xres:<value>" select horizontal resolution in pixels. (This parameter will be ignored if 'mode_option' is specified. See 'o' below). - Recommendation: user preference + Recommendation: user preference (default = 640) c. "yres:<value>" select vertical resolution in scanlines. If Discrete Video Timings is enabled, this will be ignored and computed as 3*xres/4. (This parameter will be ignored if 'mode_option' is specified. See 'o' - below) + below) Recommendation: user preference (default = 480) - - d. "vyres:<value>" + + d. "vyres:<value>" select virtual vertical resolution in scanlines. If (0) or none - is specified, this will be computed against maximum available memory. + is specified, this will be computed against maximum available memory. Recommendation: do not set (default = 480) e. "vram:<value>" - select amount of system RAM in MB to allocate for the video memory + select amount of system RAM in MB to allocate for the video memory Recommendation: 1 - 4 MB. (default = 4) - f. "bpp:<value>" - select desired pixel depth + f. "bpp:<value>" + select desired pixel depth Recommendation: 8 (default = 8) - g. "hsync1/hsync2:<value>" - select the minimum and maximum Horizontal Sync Frequency of the - monitor in KHz. If a using a fixed frequency monitor, hsync1 must + g. "hsync1/hsync2:<value>" + select the minimum and maximum Horizontal Sync Frequency of the + monitor in kHz. If using a fixed frequency monitor, hsync1 must be equal to hsync2. If EDID probing is successful, these will be ignored and values will be taken from the EDID block. Recommendation: check monitor manual for correct values - default (29/30) + (default = 29/30) - h. "vsync1/vsync2:<value>" + h. "vsync1/vsync2:<value>" select the minimum and maximum Vertical Sync Frequency of the monitor - in Hz. You can also use this option to lock your monitor's refresh + in Hz. You can also use this option to lock your monitor's refresh rate. If EDID probing is successful, these will be ignored and values will be taken from the EDID block. Recommendation: check monitor manual for correct values (default = 60/60) - IMPORTANT: If you need to clamp your timings, try to give some - leeway for computational errors (over/underflows). Example: if + IMPORTANT: If you need to clamp your timings, try to give some + leeway for computational errors (over/underflows). Example: if using vsync1/vsync2 = 60/60, make sure hsync1/hsync2 has at least a 1 unit difference, and vice versa. - i. "voffset:<value>" - select at what offset in MB of the logical memory to allocate the + i. "voffset:<value>" + select at what offset in MB of the logical memory to allocate the framebuffer memory. The intent is to avoid the memory blocks used by standard graphics applications (XFree86). The default - offset (16 MB for a 64MB aperture, 8 MB for a 32MB aperture) will - avoid XFree86's usage and allows up to 7MB/15MB of framebuffer - memory. Depending on your usage, adjust the value up or down, - (0 for maximum usage, 31/63 MB for the least amount). Note, an + offset (16 MB for a 64 MB aperture, 8 MB for a 32 MB aperture) will + avoid XFree86's usage and allows up to 7 MB/15 MB of framebuffer + memory. Depending on your usage, adjust the value up or down + (0 for maximum usage, 31/63 MB for the least amount). Note, an arbitrary setting may conflict with XFree86. Recommendation: do not set (default = 8 or 16 MB) - - j. "accel" - enable text acceleration. This can be enabled/reenabled anytime - by using 'fbset -accel true/false'. + + j. "accel" + enable text acceleration. This can be enabled/reenabled anytime + by using 'fbset -accel true/false'. Recommendation: enable - (default = not set) + (default = not set) - k. "mtrr" + k. "mtrr" enable MTRR. This allows data transfers to the framebuffer memory to occur in bursts which can significantly increase performance. - Not very helpful with the i810/i815 because of 'shared memory'. + Not very helpful with the i810/i815 because of 'shared memory'. Recommendation: do not set - (default = not set) + (default = not set) l. "extvga" if specified, secondary/external VGA output will always be enabled. Useful if the BIOS turns off the VGA port when no monitor is attached. - The external VGA monitor can then be attached without rebooting. + The external VGA monitor can then be attached without rebooting. Recommendation: do not set (default = not set) - - m. "sync" + + m. "sync" Forces the hardware engine to do a "sync" or wait for the hardware - to finish before starting another instruction. This will produce a + to finish before starting another instruction. This will produce a more stable setup, but will be slower. Recommendation: do not set @@ -162,6 +163,7 @@ C. List of available options Recommendation: do not set (default = not set) + o. <xres>x<yres>[-<bpp>][@<refresh>] The driver will now accept specification of boot mode option. If this is specified, the options 'xres' and 'yres' will be ignored. See @@ -183,8 +185,8 @@ append="video=i810fb:vram:2,xres:1024,yres:768,bpp:8,hsync1:30,hsync2:55, \ vsync1:50,vsync2:85,accel,mtrr" This will initialize the framebuffer to 1024x768 at 8bpp. The framebuffer -will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate -will be computed based on the hsync1/hsync2 and vsync1/vsync2 values. +will use 2 MB of System RAM. MTRR support will be enabled. The refresh rate +will be computed based on the hsync1/hsync2 and vsync1/vsync2 values. IMPORTANT: You must include hsync1, hsync2, vsync1 and vsync2 to enable video modes @@ -194,10 +196,10 @@ vsync1 and vsync2 parameters. These parameters will be taken from the EDID block. E. Module options - - The module parameters are essentially similar to the kernel -parameters. The main difference is that you need to include a Boolean value -(1 for TRUE, and 0 for FALSE) for those options which don't need a value. + +The module parameters are essentially similar to the kernel +parameters. The main difference is that you need to include a Boolean value +(1 for TRUE, and 0 for FALSE) for those options which don't need a value. Example, to enable MTRR, include "mtrr=1". @@ -214,62 +216,62 @@ Or just add the following to /etc/modprobe.conf options i810fb vram=2 xres=1024 bpp=16 hsync1=30 hsync2=55 vsync1=50 \ vsync2=85 accel=1 mtrr=1 -and just do a +and just do a modprobe i810fb F. Setup - a. Do your usual method of configuring the kernel. - + a. Do your usual method of configuring the kernel. + make menuconfig/xconfig/config - b. Under "Code Maturity Options", enable "Prompt for experimental/ - incomplete code/drivers". + b. Under "Code maturity level options" enable "Prompt for development + and/or incomplete code/drivers". c. Enable agpgart support for the Intel 810/815 on-board graphics. - This is required. The option is under "Character Devices" + This is required. The option is under "Character Devices". d. Under "Graphics Support", select "Intel 810/815" either statically or as a module. Choose "use VESA Generalized Timing Formula" if - you need to maximize the capability of your display. To be on the - safe side, you can leave this unselected. - + you need to maximize the capability of your display. To be on the + safe side, you can leave this unselected. + e. If you want support for DDC/I2C probing (Plug and Play Displays), set 'Enable DDC Support' to 'y'. To make this option appear, set 'use VESA Generalized Timing Formula' to 'y'. - f. If you want a framebuffer console, enable it under "Console - Drivers" + f. If you want a framebuffer console, enable it under "Console + Drivers". + + g. Compile your kernel. + + h. Load the driver as described in sections D and E. - g. Compile your kernel. - - h. Load the driver as described in section D and E. - i. Try the DirectFB (http://www.directfb.org) + the i810 gfxdriver patch to see the chipset in action (or inaction :-). G. Acknowledgment: - + 1. Geert Uytterhoeven - his excellent howto and the virtual - framebuffer driver code made this possible. + framebuffer driver code made this possible. - 2. Jeff Hartmann for his agpgart code. + 2. Jeff Hartmann for his agpgart code. 3. The X developers. Insights were provided just by reading the XFree86 source code. 4. Intel(c). For this value-oriented chipset driver and for - providing documentation. + providing documentation. 5. Matt Sottek. His inputs and ideas helped in making some - optimizations possible. + optimizations possible. H. Home Page: A more complete, and probably updated information is provided at -http://i810fb.sourceforge.net. + http://i810fb.sourceforge.net. ########################### Tony diff --git a/Documentation/fb/intelfb.txt b/Documentation/fb/intelfb.txt index c12d39a23c3d..da5ee74219e8 100644 --- a/Documentation/fb/intelfb.txt +++ b/Documentation/fb/intelfb.txt @@ -1,16 +1,19 @@ -Intel 830M/845G/852GM/855GM/865G/915G Framebuffer driver +Intel 830M/845G/852GM/855GM/865G/915G/945G Framebuffer driver ================================================================ A. Introduction - This is a framebuffer driver for various Intel 810/815 compatible + This is a framebuffer driver for various Intel 8xx/9xx compatible graphics devices. These would include: Intel 830M - Intel 810E845G + Intel 845G Intel 852GM Intel 855GM Intel 865G Intel 915G + Intel 915GM + Intel 945G + Intel 945GM B. List of available options @@ -78,19 +81,27 @@ C. Kernel booting Separate each option/option-pair by commas (,) and the option from its value with an equals sign (=) as in the following: -video=i810fb:option1,option2=value2 +video=intelfb:option1,option2=value2 Sample Usage ------------ In /etc/lilo.conf, add the line: -append="video=intelfb:800x600-32@75,accel,hwcursor,vram=8" +append="video=intelfb:mode=800x600-32@75,accel,hwcursor,vram=8" This will initialize the framebuffer to 800x600 at 32bpp and 75Hz. The framebuffer will use 8 MB of System RAM. hw acceleration of text and cursor will be enabled. +Remarks +------- + +If setting this parameter doesn't work (you stay in a 80x25 text-mode), +you might need to set the "vga=<mode>" parameter too - see vesafb.txt +in this directory. + + D. Module options The module parameters are essentially similar to the kernel diff --git a/Documentation/fb/sisfb.txt b/Documentation/fb/sisfb.txt index 3b50c517a08d..2e68e503e72f 100644 --- a/Documentation/fb/sisfb.txt +++ b/Documentation/fb/sisfb.txt @@ -72,7 +72,7 @@ information. Additionally, "modinfo sisfb" gives an overview over all supported options including some explanation. The desired display mode can be specified using the keyword "mode" with -a parameter in one of the follwing formats: +a parameter in one of the following formats: - XxYxDepth or - XxY-Depth or - XxY-Depth@Rate or diff --git a/Documentation/fb/sstfb.txt b/Documentation/fb/sstfb.txt index 628d7ffa8769..df27f5bf15db 100644 --- a/Documentation/fb/sstfb.txt +++ b/Documentation/fb/sstfb.txt @@ -48,12 +48,12 @@ Module Usage Module insertion: # insmod sstfb.o - you should see some strange output frome the board: + you should see some strange output from the board: a big blue square, a green and a red small squares and a vertical - white rectangle. why ? the function's name is self explanatory : + white rectangle. why? the function's name is self-explanatory: "sstfb_test()"... (if you don't have a second monitor, you'll have to plug your monitor - directely to the 2D videocard to see what you're typing) + directly to the 2D videocard to see what you're typing) # con2fb /dev/fbx /dev/ttyx bind a tty to the new frame buffer. if you already have a frame buffer driver, the voodoo fb will likely be /dev/fb1. if not, @@ -72,12 +72,12 @@ Module Usage Kernel/Modules Options - You can pass some otions to sstfb module, and via the kernel command - line when the driver is compiled in : + You can pass some options to the sstfb module, and via the kernel + command line when the driver is compiled in: for module : insmod sstfb.o option1=value1 option2=value2 ... in kernel : video=sstfb:option1,option2:value2,option3 ... - sstfb supports the folowing options : + sstfb supports the following options : Module Kernel Description @@ -95,11 +95,11 @@ inverse=1 inverse Supposed to enable inverse console. clipping=1 clipping Enable or disable clipping. clipping=0 noclipping With clipping enabled, all offscreen - reads and writes are disgarded. + reads and writes are discarded. Default: enable clipping. gfxclk=x gfxclk:x Force graphic clock frequency (in MHz). - Be carefull with this option, it may be + Be careful with this option, it may be DANGEROUS. Default: auto 50Mhz for Voodoo 1, @@ -137,23 +137,23 @@ Bugs - The driver is 16 bpp only, 24/32 won't work. - The driver is not your_favorite_toy-safe. this includes SMP... [Actually from inspection it seems to be safe - Alan] - - when using XFree86 FBdev (X over fbdev) you may see strange color + - When using XFree86 FBdev (X over fbdev) you may see strange color patterns at the border of your windows (the pixels lose the lowest - byte -> basicaly the blue component nd some of the green) . I'm unable + byte -> basically the blue component and some of the green). I'm unable to reproduce this with XFree86-3.3, but one of the testers has this - problem with XFree86-4. apparently recent Xfree86-4.x solve this + problem with XFree86-4. Apparently recent Xfree86-4.x solve this problem. - I didn't really test changing the palette, so you may find some weird things when playing with that. - - Sometimes the driver will not recognise the DAC , and the - initialisation will fail. this is specificaly true for - voodoo 2 boards , but it should be solved in recent versions. please - contact me . - - the 24/32 is not likely to work anytime soon , knowing that the - hardware does ... unusual thigs in 24/32 bpp - - When used with anther video board, current limitations of linux - console subsystem can cause some troubles, specificaly, you should - disable software scrollback , as it can oops badly ... + - Sometimes the driver will not recognise the DAC, and the + initialisation will fail. This is specifically true for + voodoo 2 boards, but it should be solved in recent versions. Please + contact me. + - The 24/32 is not likely to work anytime soon, knowing that the + hardware does ... unusual things in 24/32 bpp. + - When used with another video board, current limitations of the linux + console subsystem can cause some troubles, specifically, you should + disable software scrollback, as it can oops badly ... Todo @@ -161,7 +161,7 @@ Todo - Buy more coffee. - test/port to other arch. - try to add panning using tweeks with front and back buffer . - - try to implement accel on voodoo2 , this board can actualy do a + - try to implement accel on voodoo2, this board can actually do a lot in 2D even if it was sold as a 3D only board ... ghoz. diff --git a/Documentation/feature-removal-schedule.txt b/Documentation/feature-removal-schedule.txt index 552507fe9a7e..24f3c63b3017 100644 --- a/Documentation/feature-removal-schedule.txt +++ b/Documentation/feature-removal-schedule.txt @@ -6,6 +6,21 @@ be removed from this file. --------------------------- +What: /sys/devices/.../power/state + dev->power.power_state + dpm_runtime_{suspend,resume)() +When: July 2007 +Why: Broken design for runtime control over driver power states, confusing + driver-internal runtime power management with: mechanisms to support + system-wide sleep state transitions; event codes that distinguish + different phases of swsusp "sleep" transitions; and userspace policy + inputs. This framework was never widely used, and most attempts to + use it were broken. Drivers should instead be exposing domain-specific + interfaces either to kernel or to userspace. +Who: Pavel Machek <pavel@suse.cz> + +--------------------------- + What: RAW driver (CONFIG_RAW_DRIVER) When: December 2005 Why: declared obsolete since kernel 2.6.3 @@ -14,14 +29,6 @@ Who: Adrian Bunk <bunk@stusta.de> --------------------------- -What: drivers that were depending on OBSOLETE_OSS_DRIVER - (config options already removed) -When: before 2.6.19 -Why: OSS drivers with ALSA replacements -Who: Adrian Bunk <bunk@stusta.de> - ---------------------------- - What: raw1394: requests of type RAW1394_REQ_ISO_SEND, RAW1394_REQ_ISO_LISTEN When: November 2006 Why: Deprecated in favour of the new ioctl-based rawiso interface, which is @@ -31,17 +38,8 @@ Who: Jody McIntyre <scjody@modernduck.com> --------------------------- -What: sbp2: module parameter "force_inquiry_hack" -When: July 2006 -Why: Superceded by parameter "workarounds". Both parameters are meant to be - used ad-hoc and for single devices only, i.e. not in modprobe.conf, - therefore the impact of this feature replacement should be low. -Who: Stefan Richter <stefanr@s5r6.in-berlin.de> - ---------------------------- - What: Video4Linux API 1 ioctls and video_decoder.h from Video devices. -When: July 2006 +When: December 2006 Why: V4L1 AP1 was replaced by V4L2 API. during migration from 2.4 to 2.6 series. The old API have lots of drawbacks and don't provide enough means to work with all video and audio standards. The newer API is @@ -55,6 +53,18 @@ Who: Mauro Carvalho Chehab <mchehab@brturbo.com.br> --------------------------- +What: sys_sysctl +When: January 2007 +Why: The same information is available through /proc/sys and that is the + interface user space prefers to use. And there do not appear to be + any existing user in user space of sys_sysctl. The additional + maintenance overhead of keeping a set of binary names gets + in the way of doing a good job of maintaining this interface. + +Who: Eric Biederman <ebiederm@xmission.com> + +--------------------------- + What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl]) When: November 2005 Files: drivers/pcmcia/: pcmcia_ioctl.c @@ -104,15 +114,6 @@ Who: Arjan van de Ven --------------------------- -What: START_ARRAY ioctl for md -When: July 2006 -Files: drivers/md/md.c -Why: Not reliable by design - can fail when most needed. - Alternatives exist -Who: NeilBrown <neilb@suse.de> - ---------------------------- - What: eepro100 network driver When: January 2007 Why: replaced by the e100 driver @@ -175,7 +176,7 @@ Who: Greg Kroah-Hartman <gregkh@suse.de> --------------------------- What: USB driver API moves to EXPORT_SYMBOL_GPL -When: Febuary 2008 +When: February 2008 Files: include/linux/usb.h, drivers/usb/core/driver.c Why: The USB subsystem has changed a lot over time, and it has been possible to create userspace USB drivers using usbfs/libusb/gadgetfs @@ -202,50 +203,6 @@ Who: Nick Piggin <npiggin@suse.de> --------------------------- -What: Support for the MIPS EV96100 evaluation board -When: September 2006 -Why: Does no longer build since at least November 15, 2003, apparently - no userbase left. -Who: Ralf Baechle <ralf@linux-mips.org> - ---------------------------- - -What: Support for the Momentum / PMC-Sierra Jaguar ATX evaluation board -When: September 2006 -Why: Does no longer build since quite some time, and was never popular, - due to the platform being replaced by successor models. Apparently - no user base left. It also is one of the last users of - WANT_PAGE_VIRTUAL. -Who: Ralf Baechle <ralf@linux-mips.org> - ---------------------------- - -What: Support for the Momentum Ocelot, Ocelot 3, Ocelot C and Ocelot G -When: September 2006 -Why: Some do no longer build and apparently there is no user base left - for these platforms. -Who: Ralf Baechle <ralf@linux-mips.org> - ---------------------------- - -What: Support for MIPS Technologies' Altas and SEAD evaluation board -When: September 2006 -Why: Some do no longer build and apparently there is no user base left - for these platforms. Hardware out of production since several years. -Who: Ralf Baechle <ralf@linux-mips.org> - ---------------------------- - -What: Support for the IT8172-based platforms, ITE 8172G and Globespan IVR -When: September 2006 -Why: Code does no longer build since at least 2.6.0, apparently there is - no user base left for these platforms. Hardware out of production - since several years and hardly a trace of the manufacturer left on - the net. -Who: Ralf Baechle <ralf@linux-mips.org> - ---------------------------- - What: Interrupt only SA_* flags When: Januar 2007 Why: The interrupt related SA_* flags are replaced by IRQF_* to move them @@ -294,3 +251,32 @@ Why: The frame diverter is included in most distribution kernels, but is It is not clear if anyone is still using it. Who: Stephen Hemminger <shemminger@osdl.org> +--------------------------- + + +What: PHYSDEVPATH, PHYSDEVBUS, PHYSDEVDRIVER in the uevent environment +When: Oktober 2008 +Why: The stacking of class devices makes these values misleading and + inconsistent. + Class devices should not carry any of these properties, and bus + devices have SUBSYTEM and DRIVER as a replacement. +Who: Kay Sievers <kay.sievers@suse.de> + +--------------------------- + +What: i2c-isa +When: December 2006 +Why: i2c-isa is a non-sense and doesn't fit in the device driver + model. Drivers relying on it are better implemented as platform + drivers. +Who: Jean Delvare <khali@linux-fr.org> + +--------------------------- + +What: ftape +When: 2.6.20 +Why: Orphaned for ages. SMP bugs long unfixed. Few users left + in the world. +Who: Jeff Garzik <jeff@garzik.org> + +--------------------------- diff --git a/Documentation/filesystems/00-INDEX b/Documentation/filesystems/00-INDEX index 16dec61d7671..3c384c0cf86e 100644 --- a/Documentation/filesystems/00-INDEX +++ b/Documentation/filesystems/00-INDEX @@ -26,8 +26,6 @@ cramfs.txt - info on the cram filesystem for small storage (ROMs etc). dentry-locking.txt - info on the RCU-based dcache locking model. -devfs/ - - directory containing devfs documentation. directory-locking - info about the locking scheme used for directory operations. dlmfs.txt diff --git a/Documentation/filesystems/Locking b/Documentation/filesystems/Locking index 247d7f619aa2..eb1a6cad21e6 100644 --- a/Documentation/filesystems/Locking +++ b/Documentation/filesystems/Locking @@ -356,10 +356,9 @@ The last two are called only from check_disk_change(). prototypes: loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); - ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t); ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); - ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, - loff_t); + ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); + ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned int, diff --git a/Documentation/filesystems/befs.txt b/Documentation/filesystems/befs.txt index 877a7b1d46ec..67391a15949a 100644 --- a/Documentation/filesystems/befs.txt +++ b/Documentation/filesystems/befs.txt @@ -7,7 +7,7 @@ WARNING Make sure you understand that this is alpha software. This means that the implementation is neither complete nor well-tested. -I DISCLAIM ALL RESPONSIBILTY FOR ANY POSSIBLE BAD EFFECTS OF THIS CODE! +I DISCLAIM ALL RESPONSIBILITY FOR ANY POSSIBLE BAD EFFECTS OF THIS CODE! LICENSE ===== @@ -22,7 +22,7 @@ He has been working on the code since Aug 13, 2001. See the changelog for details. Original Author: Makoto Kato <m_kato@ga2.so-net.ne.jp> -His orriginal code can still be found at: +His original code can still be found at: <http://hp.vector.co.jp/authors/VA008030/bfs/> Does anyone know of a more current email address for Makoto? He doesn't respond to the address given above... @@ -39,7 +39,7 @@ Which is it, BFS or BEFS? ================ Be, Inc said, "BeOS Filesystem is officially called BFS, not BeFS". But Unixware Boot Filesystem is called bfs, too. And they are already in -the kernel. Because of this nameing conflict, on Linux the BeOS +the kernel. Because of this naming conflict, on Linux the BeOS filesystem is called befs. HOW TO INSTALL @@ -57,7 +57,7 @@ if the patching step fails (i.e. there are rejected hunks), you can try to figure it out yourself (it shouldn't be hard), or mail the maintainer (Will Dyson <will_dyson@pobox.com>) for help. -step 2. Configuretion & make kernel +step 2. Configuration & make kernel The linux kernel has many compile-time options. Most of them are beyond the scope of this document. I suggest the Kernel-HOWTO document as a good general diff --git a/Documentation/filesystems/configfs/configfs.txt b/Documentation/filesystems/configfs/configfs.txt index c4ff96b7c4e0..c3a7afb5eabf 100644 --- a/Documentation/filesystems/configfs/configfs.txt +++ b/Documentation/filesystems/configfs/configfs.txt @@ -1,5 +1,5 @@ -configfs - Userspace-driven kernel object configuation. +configfs - Userspace-driven kernel object configuration. Joel Becker <joel.becker@oracle.com> @@ -254,7 +254,7 @@ using the group _init() functions on the group. Finally, when userspace calls rmdir(2) on the item or group, ct_group_ops->drop_item() is called. As a config_group is also a -config_item, it is not necessary for a seperate drop_group() method. +config_item, it is not necessary for a separate drop_group() method. The subsystem must config_item_put() the reference that was initialized upon item allocation. If a subsystem has no work to do, it may omit the ct_group_ops->drop_item() method, and configfs will call @@ -406,7 +406,7 @@ that condition is met. Far better would be an explicit action notifying the subsystem that the config_item is ready to go. More importantly, an explicit action allows -the subsystem to provide feedback as to whether the attibutes are +the subsystem to provide feedback as to whether the attributes are initialized in a way that makes sense. configfs provides this as committable items. @@ -422,7 +422,7 @@ support mkdir(2) or rmdir(2) either. It only allows rename(2). The "pending" directory does allow mkdir(2) and rmdir(2). An item is created in the "pending" directory. Its attributes can be modified at will. Userspace commits the item by renaming it into the "live" -directory. At this point, the subsystem recieves the ->commit_item() +directory. At this point, the subsystem receives the ->commit_item() callback. If all required attributes are filled to satisfaction, the method returns zero and the item is moved to the "live" directory. diff --git a/Documentation/filesystems/directory-locking b/Documentation/filesystems/directory-locking index 34380d4fbce3..d7099a9266fb 100644 --- a/Documentation/filesystems/directory-locking +++ b/Documentation/filesystems/directory-locking @@ -82,7 +82,7 @@ own descendent. Moreover, there is exactly one cross-directory rename Consider the object blocking the cross-directory rename. One of its descendents is locked by cross-directory rename (otherwise we -would again have an infinite set of of contended objects). But that +would again have an infinite set of contended objects). But that means that cross-directory rename is taking locks out of order. Due to (2) the order hadn't changed since we had acquired filesystem lock. But locking rules for cross-directory rename guarantee that we do not diff --git a/Documentation/filesystems/dlmfs.txt b/Documentation/filesystems/dlmfs.txt index 9afab845a906..c50bbb2d52b4 100644 --- a/Documentation/filesystems/dlmfs.txt +++ b/Documentation/filesystems/dlmfs.txt @@ -68,7 +68,7 @@ request for an already acquired lock will not generate another DLM call. Userspace programs are assumed to handle their own local locking. -Two levels of locks are supported - Shared Read, and Exlcusive. +Two levels of locks are supported - Shared Read, and Exclusive. Also supported is a Trylock operation. For information on the libo2dlm interface, please see o2dlm.h, diff --git a/Documentation/filesystems/ext2.txt b/Documentation/filesystems/ext2.txt index 3dd2872416a1..4333e836c495 100644 --- a/Documentation/filesystems/ext2.txt +++ b/Documentation/filesystems/ext2.txt @@ -205,7 +205,7 @@ Reserved Space In ext2, there is a mechanism for reserving a certain number of blocks for a particular user (normally the super-user). This is intended to -allow for the system to continue functioning even if non-priveleged users +allow for the system to continue functioning even if non-privileged users fill up all the space available to them (this is independent of filesystem quotas). It also keeps the filesystem from filling up entirely which helps combat fragmentation. diff --git a/Documentation/filesystems/files.txt b/Documentation/filesystems/files.txt index 8c206f4e0250..133e213ebb72 100644 --- a/Documentation/filesystems/files.txt +++ b/Documentation/filesystems/files.txt @@ -55,7 +55,7 @@ the fdtable structure - 2. Reading of the fdtable as described above must be protected by rcu_read_lock()/rcu_read_unlock(). -3. For any update to the the fd table, files->file_lock must +3. For any update to the fd table, files->file_lock must be held. 4. To look up the file structure given an fd, a reader diff --git a/Documentation/filesystems/gfs2.txt b/Documentation/filesystems/gfs2.txt new file mode 100644 index 000000000000..593004b6bbab --- /dev/null +++ b/Documentation/filesystems/gfs2.txt @@ -0,0 +1,43 @@ +Global File System +------------------ + +http://sources.redhat.com/cluster/ + +GFS is a cluster file system. It allows a cluster of computers to +simultaneously use a block device that is shared between them (with FC, +iSCSI, NBD, etc). GFS reads and writes to the block device like a local +file system, but also uses a lock module to allow the computers coordinate +their I/O so file system consistency is maintained. One of the nifty +features of GFS is perfect consistency -- changes made to the file system +on one machine show up immediately on all other machines in the cluster. + +GFS uses interchangable inter-node locking mechanisms. Different lock +modules can plug into GFS and each file system selects the appropriate +lock module at mount time. Lock modules include: + + lock_nolock -- allows gfs to be used as a local file system + + lock_dlm -- uses a distributed lock manager (dlm) for inter-node locking + The dlm is found at linux/fs/dlm/ + +In addition to interfacing with an external locking manager, a gfs lock +module is responsible for interacting with external cluster management +systems. Lock_dlm depends on user space cluster management systems found +at the URL above. + +To use gfs as a local file system, no external clustering systems are +needed, simply: + + $ mkfs -t gfs2 -p lock_nolock -j 1 /dev/block_device + $ mount -t gfs2 /dev/block_device /dir + +GFS2 is not on-disk compatible with previous versions of GFS. + +The following man pages can be found at the URL above: + gfs2_fsck to repair a filesystem + gfs2_grow to expand a filesystem online + gfs2_jadd to add journals to a filesystem online + gfs2_tool to manipulate, examine and tune a filesystem + gfs2_quota to examine and change quota values in a filesystem + mount.gfs2 to help mount(8) mount a filesystem + mkfs.gfs2 to make a filesystem diff --git a/Documentation/filesystems/ntfs.txt b/Documentation/filesystems/ntfs.txt index 638cbd3d2b00..35f105b29e3e 100644 --- a/Documentation/filesystems/ntfs.txt +++ b/Documentation/filesystems/ntfs.txt @@ -13,7 +13,7 @@ Table of contents - Using NTFS volume and stripe sets - The Device-Mapper driver - The Software RAID / MD driver - - Limitiations when using the MD driver + - Limitations when using the MD driver - ChangeLog @@ -43,7 +43,7 @@ There is plenty of additional information on the linux-ntfs web site at http://linux-ntfs.sourceforge.net/ The web site has a lot of additional information, such as a comprehensive -FAQ, documentation on the NTFS on-disk format, informaiton on the Linux-NTFS +FAQ, documentation on the NTFS on-disk format, information on the Linux-NTFS userspace utilities, etc. @@ -383,14 +383,14 @@ Software RAID / MD driver. For which you need to set up your /etc/raidtab appropriately (see man 5 raidtab). Linear volume sets, i.e. linear raid, as well as stripe sets, i.e. raid level -0, have been tested and work fine (though see section "Limitiations when using +0, have been tested and work fine (though see section "Limitations when using the MD driver with NTFS volumes" especially if you want to use linear raid). Even though untested, there is no reason why mirrors, i.e. raid level 1, and stripes with parity, i.e. raid level 5, should not work, too. You have to use the "persistent-superblock 0" option for each raid-disk in the NTFS volume/stripe you are configuring in /etc/raidtab as the persistent -superblock used by the MD driver would damange the NTFS volume. +superblock used by the MD driver would damage the NTFS volume. Windows by default uses a stripe chunk size of 64k, so you probably want the "chunk-size 64k" option for each raid-disk, too. @@ -435,7 +435,7 @@ setup correctly to avoid the possibility of causing damage to the data on the ntfs volume. -Limitiations when using the Software RAID / MD driver +Limitations when using the Software RAID / MD driver ----------------------------------------------------- Using the md driver will not work properly if any of your NTFS partitions have diff --git a/Documentation/filesystems/proc.txt b/Documentation/filesystems/proc.txt index 99902ae6804e..3355e6920105 100644 --- a/Documentation/filesystems/proc.txt +++ b/Documentation/filesystems/proc.txt @@ -39,6 +39,8 @@ Table of Contents 2.9 Appletalk 2.10 IPX 2.11 /proc/sys/fs/mqueue - POSIX message queues filesystem + 2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score + 2.13 /proc/<pid>/oom_score - Display current oom-killer score ------------------------------------------------------------------------------ Preface @@ -408,7 +410,7 @@ VmallocChunk: 111088 kB this memory, making it slower to access than lowmem. LowTotal: LowFree: Lowmem is memory which can be used for everything that - highmem can be used for, but it is also availble for the + highmem can be used for, but it is also available for the kernel's use for its own data structures. Among many other things, it is where everything from the Slab is allocated. Bad things happen when you're out of lowmem. @@ -1124,11 +1126,15 @@ debugging information is displayed on console. NMI switch that most IA32 servers have fires unknown NMI up, for example. If a system hangs up, try pressing the NMI switch. -[NOTE] - This function and oprofile share a NMI callback. Therefore this function - cannot be enabled when oprofile is activated. - And NMI watchdog will be disabled when the value in this file is set to - non-zero. +nmi_watchdog +------------ + +Enables/Disables the NMI watchdog on x86 systems. When the value is non-zero +the NMI watchdog is enabled and will continuously test all online cpus to +determine whether or not they are still functioning properly. + +Because the NMI watchdog shares registers with oprofile, by disabling the NMI +watchdog, oprofile may have more registers to utilize. 2.4 /proc/sys/vm - The virtual memory subsystem @@ -1249,7 +1255,7 @@ to allocate (but not use) more memory than is actually available. address space are refused. Used for a typical system. It ensures a seriously wild allocation fails while allowing overcommit to reduce swap usage. root is allowed to - allocate slighly more memory in this mode. This is the + allocate slightly more memory in this mode. This is the default. 1 - Always overcommit. Appropriate for some scientific @@ -1582,7 +1588,7 @@ Enable the strict RFC793 interpretation of the TCP urgent pointer field. The default is to use the BSD compatible interpretation of the urgent pointer pointing to the first byte after the urgent data. The RFC793 interpretation is to have it point to the last byte of urgent data. Enabling this option may -lead to interoperatibility problems. Disabled by default. +lead to interoperability problems. Disabled by default. tcp_syncookies -------------- @@ -1727,7 +1733,7 @@ error_burst and error_cost These parameters are used to limit how many ICMP destination unreachable to send from the host in question. ICMP destination unreachable messages are -sent when we can not reach the next hop, while trying to transmit a packet. +sent when we cannot reach the next hop while trying to transmit a packet. It will also print some error messages to kernel logs if someone is ignoring our ICMP redirects. The higher the error_cost factor is, the fewer destination unreachable and error messages will be let through. Error_burst @@ -1851,7 +1857,7 @@ proxy_qlen Maximum queue length of the delayed proxy arp timer. (see proxy_delay). -app_solcit +app_solicit ---------- Determines the number of requests to send to the user level ARP daemon. Use 0 @@ -1958,6 +1964,22 @@ a queue must be less or equal then msg_max. maximum message size value (it is every message queue's attribute set during its creation). +2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score +------------------------------------------------------ + +This file can be used to adjust the score used to select which processes +should be killed in an out-of-memory situation. Giving it a high score will +increase the likelihood of this process being killed by the oom-killer. Valid +values are in the range -16 to +15, plus the special value -17, which disables +oom-killing altogether for this process. + +2.13 /proc/<pid>/oom_score - Display current oom-killer score +------------------------------------------------------------- + +------------------------------------------------------------------------------ +This file can be used to check the current score used by the oom-killer is for +any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which +process should be killed in an out-of-memory situation. ------------------------------------------------------------------------------ Summary diff --git a/Documentation/filesystems/spufs.txt b/Documentation/filesystems/spufs.txt index 8edc3952eff4..982645a1981d 100644 --- a/Documentation/filesystems/spufs.txt +++ b/Documentation/filesystems/spufs.txt @@ -84,7 +84,7 @@ FILES /ibox The second SPU to CPU communication mailbox. This file is similar to the first mailbox file, but can be read in blocking I/O mode, and the - poll familiy of system calls can be used to wait for it. The possible + poll family of system calls can be used to wait for it. The possible operations on an open ibox file are: read(2) @@ -105,7 +105,7 @@ FILES /wbox - The CPU to SPU communation mailbox. It is write-only can can be written + The CPU to SPU communation mailbox. It is write-only and can be written in units of 32 bits. If the mailbox is full, write() will block and poll can be used to wait for it becoming empty again. The possible operations on an open wbox file are: write(2) If a count smaller than @@ -359,7 +359,7 @@ ERRORS EFAULT npc is not a valid pointer or status is neither NULL nor a valid pointer. - EINTR A signal occured while spu_run was in progress. The npc value + EINTR A signal occurred while spu_run was in progress. The npc value has been updated to the new program counter value if necessary. EINVAL fd is not a file descriptor returned from spu_create(2). diff --git a/Documentation/filesystems/sysfs.txt b/Documentation/filesystems/sysfs.txt index 89b1d196ca80..4b5ca26e5048 100644 --- a/Documentation/filesystems/sysfs.txt +++ b/Documentation/filesystems/sysfs.txt @@ -238,7 +238,7 @@ Top Level Directory Layout The sysfs directory arrangement exposes the relationship of kernel data structures. -The top level sysfs diretory looks like: +The top level sysfs directory looks like: block/ bus/ diff --git a/Documentation/filesystems/tmpfs.txt b/Documentation/filesystems/tmpfs.txt index 1773106976a2..6dd050878a20 100644 --- a/Documentation/filesystems/tmpfs.txt +++ b/Documentation/filesystems/tmpfs.txt @@ -39,7 +39,7 @@ tmpfs has the following uses: tmpfs /dev/shm tmpfs defaults 0 0 Remember to create the directory that you intend to mount tmpfs on - if necessary (/dev/shm is automagically created if you use devfs). + if necessary. This mount is _not_ needed for SYSV shared memory. The internal mount is used for that. (In the 2.3 kernel versions it was @@ -63,7 +63,7 @@ size: The limit of allocated bytes for this tmpfs instance. The nr_blocks: The same as size, but in blocks of PAGE_CACHE_SIZE. nr_inodes: The maximum number of inodes for this instance. The default is half of the number of your physical RAM pages, or (on a - a machine with highmem) the number of lowmem RAM pages, + machine with highmem) the number of lowmem RAM pages, whichever is the lower. These parameters accept a suffix k, m or g for kilo, mega and giga and diff --git a/Documentation/filesystems/vfat.txt b/Documentation/filesystems/vfat.txt index 2001abbc60e6..069cb1094300 100644 --- a/Documentation/filesystems/vfat.txt +++ b/Documentation/filesystems/vfat.txt @@ -35,7 +35,7 @@ iocharset=name -- Character set to use for converting between the you should consider the following option instead. utf8=<bool> -- UTF-8 is the filesystem safe version of Unicode that - is used by the console. It can be be enabled for the + is used by the console. It can be enabled for the filesystem with this option. If 'uni_xlate' gets set, UTF-8 gets disabled. diff --git a/Documentation/filesystems/vfs.txt b/Documentation/filesystems/vfs.txt index 1cb7e8be927a..7737bfd03cf8 100644 --- a/Documentation/filesystems/vfs.txt +++ b/Documentation/filesystems/vfs.txt @@ -410,7 +410,7 @@ otherwise noted. put_link: called by the VFS to release resources allocated by follow_link(). The cookie returned by follow_link() is passed - to to this method as the last parameter. It is used by + to this method as the last parameter. It is used by filesystems such as NFS where page cache is not stable (i.e. page that was installed when the symbolic link walk started might not be in the page cache at the end of the @@ -699,9 +699,9 @@ This describes how the VFS can manipulate an open file. As of kernel struct file_operations { loff_t (*llseek) (struct file *, loff_t, int); ssize_t (*read) (struct file *, char __user *, size_t, loff_t *); - ssize_t (*aio_read) (struct kiocb *, char __user *, size_t, loff_t); ssize_t (*write) (struct file *, const char __user *, size_t, loff_t *); - ssize_t (*aio_write) (struct kiocb *, const char __user *, size_t, loff_t); + ssize_t (*aio_read) (struct kiocb *, const struct iovec *, unsigned long, loff_t); + ssize_t (*aio_write) (struct kiocb *, const struct iovec *, unsigned long, loff_t); int (*readdir) (struct file *, void *, filldir_t); unsigned int (*poll) (struct file *, struct poll_table_struct *); int (*ioctl) (struct inode *, struct file *, unsigned int, unsigned long); diff --git a/Documentation/fujitsu/frv/mmu-layout.txt b/Documentation/fujitsu/frv/mmu-layout.txt index 11dcc5679887..db10250df6be 100644 --- a/Documentation/fujitsu/frv/mmu-layout.txt +++ b/Documentation/fujitsu/frv/mmu-layout.txt @@ -233,7 +233,7 @@ related kernel services: (*) __debug_mmu.iamr[] (*) __debug_mmu.damr[] - These receive the current IAMR and DAMR contents. These can be viewed with with the _amr + These receive the current IAMR and DAMR contents. These can be viewed with the _amr GDB macro: (gdb) _amr diff --git a/Documentation/highuid.txt b/Documentation/highuid.txt index 2c33926b9099..76034d9dbfc0 100644 --- a/Documentation/highuid.txt +++ b/Documentation/highuid.txt @@ -57,7 +57,7 @@ What's left to be done for 32-bit UIDs on all Linux architectures: Other filesystems have not been checked yet. -- The ncpfs and smpfs filesystems can not presently use 32-bit UIDs in +- The ncpfs and smpfs filesystems cannot presently use 32-bit UIDs in all ioctl()s. Some new ioctl()s have been added with 32-bit UIDs, but more are needed. (as well as new user<->kernel data structures) diff --git a/Documentation/hrtimers.txt b/Documentation/hrtimers.txt index 7620ff735faf..ce31f65e12e7 100644 --- a/Documentation/hrtimers.txt +++ b/Documentation/hrtimers.txt @@ -10,7 +10,7 @@ back and forth trying to integrate high-resolution and high-precision features into the existing timer framework, and after testing various such high-resolution timer implementations in practice, we came to the conclusion that the timer wheel code is fundamentally not suitable for -such an approach. We initially didnt believe this ('there must be a way +such an approach. We initially didn't believe this ('there must be a way to solve this'), and spent a considerable effort trying to integrate things into the timer wheel, but we failed. In hindsight, there are several reasons why such integration is hard/impossible: @@ -27,7 +27,7 @@ several reasons why such integration is hard/impossible: high-res timers. - the unpredictable [O(N)] overhead of cascading leads to delays which - necessiate a more complex handling of high resolution timers, which + necessitate a more complex handling of high resolution timers, which in turn decreases robustness. Such a design still led to rather large timing inaccuracies. Cascading is a fundamental property of the timer wheel concept, it cannot be 'designed out' without unevitably @@ -58,7 +58,7 @@ several reasons why such integration is hard/impossible: The primary users of precision timers are user-space applications that utilize nanosleep, posix-timers and itimer interfaces. Also, in-kernel users like drivers and subsystems which require precise timed events -(e.g. multimedia) can benefit from the availability of a seperate +(e.g. multimedia) can benefit from the availability of a separate high-resolution timer subsystem as well. While this subsystem does not offer high-resolution clock sources just @@ -68,7 +68,7 @@ The increasing demand for realtime and multimedia applications along with other potential users for precise timers gives another reason to separate the "timeout" and "precise timer" subsystems. -Another potential benefit is that such a seperation allows even more +Another potential benefit is that such a separation allows even more special-purpose optimization of the existing timer wheel for the low resolution and low precision use cases - once the precision-sensitive APIs are separated from the timer wheel and are migrated over to @@ -96,8 +96,8 @@ file systems. The rbtree is solely used for time sorted ordering, while a separate list is used to give the expiry code fast access to the queued timers, without having to walk the rbtree. -(This seperate list is also useful for later when we'll introduce -high-resolution clocks, where we need seperate pending and expired +(This separate list is also useful for later when we'll introduce +high-resolution clocks, where we need separate pending and expired queues while keeping the time-order intact.) Time-ordered enqueueing is not purely for the purposes of diff --git a/Documentation/hwmon/it87 b/Documentation/hwmon/it87 index 9555be1ed999..e783fd62e308 100644 --- a/Documentation/hwmon/it87 +++ b/Documentation/hwmon/it87 @@ -13,12 +13,25 @@ Supported chips: from Super I/O config space (8 I/O ports) Datasheet: Publicly available at the ITE website http://www.ite.com.tw/ + * IT8716F + Prefix: 'it8716' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Publicly available at the ITE website + http://www.ite.com.tw/product_info/file/pc/IT8716F_V0.3.ZIP + * IT8718F + Prefix: 'it8718' + Addresses scanned: from Super I/O config space (8 I/O ports) + Datasheet: Publicly available at the ITE website + http://www.ite.com.tw/product_info/file/pc/IT8718F_V0.2.zip + http://www.ite.com.tw/product_info/file/pc/IT8718F_V0%203_(for%20C%20version).zip * SiS950 [clone of IT8705F] Prefix: 'it87' Addresses scanned: from Super I/O config space (8 I/O ports) Datasheet: No longer be available -Author: Christophe Gauthron <chrisg@0-in.com> +Authors: + Christophe Gauthron <chrisg@0-in.com> + Jean Delvare <khali@linux-fr.org> Module Parameters @@ -43,26 +56,46 @@ Module Parameters Description ----------- -This driver implements support for the IT8705F, IT8712F and SiS950 chips. - -This driver also supports IT8712F, which adds SMBus access, and a VID -input, used to report the Vcore voltage of the Pentium processor. -The IT8712F additionally features VID inputs. +This driver implements support for the IT8705F, IT8712F, IT8716F, +IT8718F and SiS950 chips. These chips are 'Super I/O chips', supporting floppy disks, infrared ports, joysticks and other miscellaneous stuff. For hardware monitoring, they include an 'environment controller' with 3 temperature sensors, 3 fan rotation speed sensors, 8 voltage sensors, and associated alarms. +The IT8712F and IT8716F additionally feature VID inputs, used to report +the Vcore voltage of the processor. The early IT8712F have 5 VID pins, +the IT8716F and late IT8712F have 6. They are shared with other functions +though, so the functionality may not be available on a given system. +The driver dumbly assume it is there. + +The IT8718F also features VID inputs (up to 8 pins) but the value is +stored in the Super-I/O configuration space. Due to technical limitations, +this value can currently only be read once at initialization time, so +the driver won't notice and report changes in the VID value. The two +upper VID bits share their pins with voltage inputs (in5 and in6) so you +can't have both on a given board. + +The IT8716F, IT8718F and later IT8712F revisions have support for +2 additional fans. They are not yet supported by the driver. + +The IT8716F and IT8718F, and late IT8712F and IT8705F also have optional +16-bit tachometer counters for fans 1 to 3. This is better (no more fan +clock divider mess) but not compatible with the older chips and +revisions. For now, the driver only uses the 16-bit mode on the +IT8716F and IT8718F. + Temperatures are measured in degrees Celsius. An alarm is triggered once when the Overtemperature Shutdown limit is crossed. Fan rotation speeds are reported in RPM (rotations per minute). An alarm is -triggered if the rotation speed has dropped below a programmable limit. Fan -readings can be divided by a programmable divider (1, 2, 4 or 8) to give the -readings more range or accuracy. Not all RPM values can accurately be -represented, so some rounding is done. With a divider of 2, the lowest -representable value is around 2600 RPM. +triggered if the rotation speed has dropped below a programmable limit. When +16-bit tachometer counters aren't used, fan readings can be divided by +a programmable divider (1, 2, 4 or 8) to give the readings more range or +accuracy. With a divider of 2, the lowest representable value is around +2600 RPM. Not all RPM values can accurately be represented, so some rounding +is done. Voltage sensors (also known as IN sensors) report their values in volts. An alarm is triggered if the voltage has crossed a programmable minimum or @@ -71,9 +104,9 @@ zero'; this is important for negative voltage measurements. All voltage inputs can measure voltages between 0 and 4.08 volts, with a resolution of 0.016 volt. The battery voltage in8 does not have limit registers. -The VID lines (IT8712F only) encode the core voltage value: the voltage -level your processor should work with. This is hardcoded by the mainboard -and/or processor itself. It is a value in volts. +The VID lines (IT8712F/IT8716F/IT8718F) encode the core voltage value: +the voltage level your processor should work with. This is hardcoded by +the mainboard and/or processor itself. It is a value in volts. If an alarm triggers, it will remain triggered until the hardware register is read at least once. This means that the cause for the alarm may already diff --git a/Documentation/hwmon/k8temp b/Documentation/hwmon/k8temp new file mode 100644 index 000000000000..bab445ab0f52 --- /dev/null +++ b/Documentation/hwmon/k8temp @@ -0,0 +1,52 @@ +Kernel driver k8temp +==================== + +Supported chips: + * AMD K8 CPU + Prefix: 'k8temp' + Addresses scanned: PCI space + Datasheet: http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/32559.pdf + +Author: Rudolf Marek +Contact: Rudolf Marek <r.marek@sh.cvut.cz> + +Description +----------- + +This driver permits reading temperature sensor(s) embedded inside AMD K8 CPUs. +Official documentation says that it works from revision F of K8 core, but +in fact it seems to be implemented for all revisions of K8 except the first +two revisions (SH-B0 and SH-B3). + +There can be up to four temperature sensors inside single CPU. The driver +will auto-detect the sensors and will display only temperatures from +implemented sensors. + +Mapping of /sys files is as follows: + +temp1_input - temperature of Core 0 and "place" 0 +temp2_input - temperature of Core 0 and "place" 1 +temp3_input - temperature of Core 1 and "place" 0 +temp4_input - temperature of Core 1 and "place" 1 + +Temperatures are measured in degrees Celsius and measurement resolution is +1 degree C. It is expected that future CPU will have better resolution. The +temperature is updated once a second. Valid temperatures are from -49 to +206 degrees C. + +Temperature known as TCaseMax was specified for processors up to revision E. +This temperature is defined as temperature between heat-spreader and CPU +case, so the internal CPU temperature supplied by this driver can be higher. +There is no easy way how to measure the temperature which will correlate +with TCaseMax temperature. + +For newer revisions of CPU (rev F, socket AM2) there is a mathematically +computed temperature called TControl, which must be lower than TControlMax. + +The relationship is following: + +temp1_input - TjOffset*2 < TControlMax, + +TjOffset is not yet exported by the driver, TControlMax is usually +70 degrees C. The rule of the thumb -> CPU temperature should not cross +60 degrees C too much. diff --git a/Documentation/hwmon/vt1211 b/Documentation/hwmon/vt1211 new file mode 100644 index 000000000000..77fa633b97a8 --- /dev/null +++ b/Documentation/hwmon/vt1211 @@ -0,0 +1,206 @@ +Kernel driver vt1211 +==================== + +Supported chips: + * VIA VT1211 + Prefix: 'vt1211' + Addresses scanned: none, address read from Super-I/O config space + Datasheet: Provided by VIA upon request and under NDA + +Authors: Juerg Haefliger <juergh@gmail.com> + +This driver is based on the driver for kernel 2.4 by Mark D. Studebaker and +its port to kernel 2.6 by Lars Ekman. + +Thanks to Joseph Chan and Fiona Gatt from VIA for providing documentation and +technical support. + + +Module Parameters +----------------- + +* uch_config: int Override the BIOS default universal channel (UCH) + configuration for channels 1-5. + Legal values are in the range of 0-31. Bit 0 maps to + UCH1, bit 1 maps to UCH2 and so on. Setting a bit to 1 + enables the thermal input of that particular UCH and + setting a bit to 0 enables the voltage input. + +* int_mode: int Override the BIOS default temperature interrupt mode. + The only possible value is 0 which forces interrupt + mode 0. In this mode, any pending interrupt is cleared + when the status register is read but is regenerated as + long as the temperature stays above the hysteresis + limit. + +Be aware that overriding BIOS defaults might cause some unwanted side effects! + + +Description +----------- + +The VIA VT1211 Super-I/O chip includes complete hardware monitoring +capabilities. It monitors 2 dedicated temperature sensor inputs (temp1 and +temp2), 1 dedicated voltage (in5) and 2 fans. Additionally, the chip +implements 5 universal input channels (UCH1-5) that can be individually +programmed to either monitor a voltage or a temperature. + +This chip also provides manual and automatic control of fan speeds (according +to the datasheet). The driver only supports automatic control since the manual +mode doesn't seem to work as advertised in the datasheet. In fact I couldn't +get manual mode to work at all! Be aware that automatic mode hasn't been +tested very well (due to the fact that my EPIA M10000 doesn't have the fans +connected to the PWM outputs of the VT1211 :-(). + +The following table shows the relationship between the vt1211 inputs and the +sysfs nodes. + +Sensor Voltage Mode Temp Mode Default Use (from the datasheet) +------ ------------ --------- -------------------------------- +Reading 1 temp1 Intel thermal diode +Reading 3 temp2 Internal thermal diode +UCH1/Reading2 in0 temp3 NTC type thermistor +UCH2 in1 temp4 +2.5V +UCH3 in2 temp5 VccP (processor core) +UCH4 in3 temp6 +5V +UCH5 in4 temp7 +12V ++3.3V in5 Internal VCC (+3.3V) + + +Voltage Monitoring +------------------ + +Voltages are sampled by an 8-bit ADC with a LSB of ~10mV. The supported input +range is thus from 0 to 2.60V. Voltage values outside of this range need +external scaling resistors. This external scaling needs to be compensated for +via compute lines in sensors.conf, like: + +compute inx @*(1+R1/R2), @/(1+R1/R2) + +The board level scaling resistors according to VIA's recommendation are as +follows. And this is of course totally dependent on the actual board +implementation :-) You will have to find documentation for your own +motherboard and edit sensors.conf accordingly. + + Expected +Voltage R1 R2 Divider Raw Value +----------------------------------------------- ++2.5V 2K 10K 1.2 2083 mV +VccP --- --- 1.0 1400 mV (1) ++5V 14K 10K 2.4 2083 mV ++12V 47K 10K 5.7 2105 mV ++3.3V (int) 2K 3.4K 1.588 3300 mV (2) ++3.3V (ext) 6.8K 10K 1.68 1964 mV + +(1) Depending on the CPU (1.4V is for a VIA C3 Nehemiah). +(2) R1 and R2 for 3.3V (int) are internal to the VT1211 chip and the driver + performs the scaling and returns the properly scaled voltage value. + +Each measured voltage has an associated low and high limit which triggers an +alarm when crossed. + + +Temperature Monitoring +---------------------- + +Temperatures are reported in millidegree Celsius. Each measured temperature +has a high limit which triggers an alarm if crossed. There is an associated +hysteresis value with each temperature below which the temperature has to drop +before the alarm is cleared (this is only true for interrupt mode 0). The +interrupt mode can be forced to 0 in case the BIOS doesn't do it +automatically. See the 'Module Parameters' section for details. + +All temperature channels except temp2 are external. Temp2 is the VT1211 +internal thermal diode and the driver does all the scaling for temp2 and +returns the temperature in millidegree Celsius. For the external channels +temp1 and temp3-temp7, scaling depends on the board implementation and needs +to be performed in userspace via sensors.conf. + +Temp1 is an Intel-type thermal diode which requires the following formula to +convert between sysfs readings and real temperatures: + +compute temp1 (@-Offset)/Gain, (@*Gain)+Offset + +According to the VIA VT1211 BIOS porting guide, the following gain and offset +values should be used: + +Diode Type Offset Gain +---------- ------ ---- +Intel CPU 88.638 0.9528 + 65.000 0.9686 *) +VIA C3 Ezra 83.869 0.9528 +VIA C3 Ezra-T 73.869 0.9528 + +*) This is the formula from the lm_sensors 2.10.0 sensors.conf file. I don't +know where it comes from or how it was derived, it's just listed here for +completeness. + +Temp3-temp7 support NTC thermistors. For these channels, the driver returns +the voltages as seen at the individual pins of UCH1-UCH5. The voltage at the +pin (Vpin) is formed by a voltage divider made of the thermistor (Rth) and a +scaling resistor (Rs): + +Vpin = 2200 * Rth / (Rs + Rth) (2200 is the ADC max limit of 2200 mV) + +The equation for the thermistor is as follows (google it if you want to know +more about it): + +Rth = Ro * exp(B * (1 / T - 1 / To)) (To is 298.15K (25C) and Ro is the + nominal resistance at 25C) + +Mingling the above two equations and assuming Rs = Ro and B = 3435 yields the +following formula for sensors.conf: + +compute tempx 1 / (1 / 298.15 - (` (2200 / @ - 1)) / 3435) - 273.15, + 2200 / (1 + (^ (3435 / 298.15 - 3435 / (273.15 + @)))) + + +Fan Speed Control +----------------- + +The VT1211 provides 2 programmable PWM outputs to control the speeds of 2 +fans. Writing a 2 to any of the two pwm[1-2]_enable sysfs nodes will put the +PWM controller in automatic mode. There is only a single controller that +controls both PWM outputs but each PWM output can be individually enabled and +disabled. + +Each PWM has 4 associated distinct output duty-cycles: full, high, low and +off. Full and off are internally hard-wired to 255 (100%) and 0 (0%), +respectively. High and low can be programmed via +pwm[1-2]_auto_point[2-3]_pwm. Each PWM output can be associated with a +different thermal input but - and here's the weird part - only one set of +thermal thresholds exist that controls both PWMs output duty-cycles. The +thermal thresholds are accessible via pwm[1-2]_auto_point[1-4]_temp. Note +that even though there are 2 sets of 4 auto points each, they map to the same +registers in the VT1211 and programming one set is sufficient (actually only +the first set pwm1_auto_point[1-4]_temp is writable, the second set is +read-only). + +PWM Auto Point PWM Output Duty-Cycle +------------------------------------------------ +pwm[1-2]_auto_point4_pwm full speed duty-cycle (hard-wired to 255) +pwm[1-2]_auto_point3_pwm high speed duty-cycle +pwm[1-2]_auto_point2_pwm low speed duty-cycle +pwm[1-2]_auto_point1_pwm off duty-cycle (hard-wired to 0) + +Temp Auto Point Thermal Threshold +--------------------------------------------- +pwm[1-2]_auto_point4_temp full speed temp +pwm[1-2]_auto_point3_temp high speed temp +pwm[1-2]_auto_point2_temp low speed temp +pwm[1-2]_auto_point1_temp off temp + +Long story short, the controller implements the following algorithm to set the +PWM output duty-cycle based on the input temperature: + +Thermal Threshold Output Duty-Cycle + (Rising Temp) (Falling Temp) +---------------------------------------------------------- + full speed duty-cycle full speed duty-cycle +full speed temp + high speed duty-cycle full speed duty-cycle +high speed temp + low speed duty-cycle high speed duty-cycle +low speed temp + off duty-cycle low speed duty-cycle +off temp diff --git a/Documentation/hwmon/w83627ehf b/Documentation/hwmon/w83627ehf new file mode 100644 index 000000000000..fae3b781d82d --- /dev/null +++ b/Documentation/hwmon/w83627ehf @@ -0,0 +1,85 @@ +Kernel driver w83627ehf +======================= + +Supported chips: + * Winbond W83627EHF/EHG (ISA access ONLY) + Prefix: 'w83627ehf' + Addresses scanned: ISA address retrieved from Super I/O registers + Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83627EHF_%20W83627EHGb.pdf + +Authors: + Jean Delvare <khali@linux-fr.org> + Yuan Mu (Winbond) + Rudolf Marek <r.marek@sh.cvut.cz> + +Description +----------- + +This driver implements support for the Winbond W83627EHF and W83627EHG +super I/O chips. We will refer to them collectively as Winbond chips. + +The chips implement three temperature sensors, five fan rotation +speed sensors, ten analog voltage sensors, alarms with beep warnings (control +unimplemented), and some automatic fan regulation strategies (plus manual +fan control mode). + +Temperatures are measured in degrees Celsius and measurement resolution is 1 +degC for temp1 and 0.5 degC for temp2 and temp3. An alarm is triggered when +the temperature gets higher than high limit; it stays on until the temperature +falls below the Hysteresis value. + +Fan rotation speeds are reported in RPM (rotations per minute). An alarm is +triggered if the rotation speed has dropped below a programmable limit. Fan +readings can be divided by a programmable divider (1, 2, 4, 8, 16, 32, 64 or +128) to give the readings more range or accuracy. The driver sets the most +suitable fan divisor itself. Some fans might not be present because they +share pins with other functions. + +Voltage sensors (also known as IN sensors) report their values in millivolts. +An alarm is triggered if the voltage has crossed a programmable minimum +or maximum limit. + +The driver supports automatic fan control mode known as Thermal Cruise. +In this mode, the chip attempts to keep the measured temperature in a +predefined temperature range. If the temperature goes out of range, fan +is driven slower/faster to reach the predefined range again. + +The mode works for fan1-fan4. Mapping of temperatures to pwm outputs is as +follows: + +temp1 -> pwm1 +temp2 -> pwm2 +temp3 -> pwm3 +prog -> pwm4 (the programmable setting is not supported by the driver) + +/sys files +---------- + +pwm[1-4] - this file stores PWM duty cycle or DC value (fan speed) in range: + 0 (stop) to 255 (full) + +pwm[1-4]_enable - this file controls mode of fan/temperature control: + * 1 Manual Mode, write to pwm file any value 0-255 (full speed) + * 2 Thermal Cruise + +Thermal Cruise mode +------------------- + +If the temperature is in the range defined by: + +pwm[1-4]_target - set target temperature, unit millidegree Celcius + (range 0 - 127000) +pwm[1-4]_tolerance - tolerance, unit millidegree Celcius (range 0 - 15000) + +there are no changes to fan speed. Once the temperature leaves the interval, +fan speed increases (temp is higher) or decreases if lower than desired. +There are defined steps and times, but not exported by the driver yet. + +pwm[1-4]_min_output - minimum fan speed (range 1 - 255), when the temperature + is below defined range. +pwm[1-4]_stop_time - how many milliseconds [ms] must elapse to switch + corresponding fan off. (when the temperature was below + defined range). + +Note: last two functions are influenced by other control bits, not yet exported + by the driver, so a change might not have any effect. diff --git a/Documentation/hwmon/w83791d b/Documentation/hwmon/w83791d index 83a3836289c2..19b2ed739fa1 100644 --- a/Documentation/hwmon/w83791d +++ b/Documentation/hwmon/w83791d @@ -5,7 +5,7 @@ Supported chips: * Winbond W83791D Prefix: 'w83791d' Addresses scanned: I2C 0x2c - 0x2f - Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791Da.pdf + Datasheet: http://www.winbond-usa.com/products/winbond_products/pdfs/PCIC/W83791D_W83791Gb.pdf Author: Charles Spirakis <bezaur@gmail.com> @@ -20,6 +20,9 @@ Credits: Chunhao Huang <DZShen@Winbond.com.tw>, Rudolf Marek <r.marek@sh.cvut.cz> +Additional contributors: + Sven Anders <anders@anduras.de> + Module Parameters ----------------- @@ -46,7 +49,8 @@ Module Parameters Description ----------- -This driver implements support for the Winbond W83791D chip. +This driver implements support for the Winbond W83791D chip. The W83791G +chip appears to be the same as the W83791D but is lead free. Detection of the chip can sometimes be foiled because it can be in an internal state that allows no clean access (Bank with ID register is not @@ -71,34 +75,36 @@ Voltage sensors (also known as IN sensors) report their values in millivolts. An alarm is triggered if the voltage has crossed a programmable minimum or maximum limit. -Alarms are provided as output from a "realtime status register". The -following bits are defined: - -bit - alarm on: -0 - Vcore -1 - VINR0 -2 - +3.3VIN -3 - 5VDD -4 - temp1 -5 - temp2 -6 - fan1 -7 - fan2 -8 - +12VIN -9 - -12VIN -10 - -5VIN -11 - fan3 -12 - chassis -13 - temp3 -14 - VINR1 -15 - reserved -16 - tart1 -17 - tart2 -18 - tart3 -19 - VSB -20 - VBAT -21 - fan4 -22 - fan5 -23 - reserved +The bit ordering for the alarm "realtime status register" and the +"beep enable registers" are different. + +in0 (VCORE) : alarms: 0x000001 beep_enable: 0x000001 +in1 (VINR0) : alarms: 0x000002 beep_enable: 0x002000 <== mismatch +in2 (+3.3VIN): alarms: 0x000004 beep_enable: 0x000004 +in3 (5VDD) : alarms: 0x000008 beep_enable: 0x000008 +in4 (+12VIN) : alarms: 0x000100 beep_enable: 0x000100 +in5 (-12VIN) : alarms: 0x000200 beep_enable: 0x000200 +in6 (-5VIN) : alarms: 0x000400 beep_enable: 0x000400 +in7 (VSB) : alarms: 0x080000 beep_enable: 0x010000 <== mismatch +in8 (VBAT) : alarms: 0x100000 beep_enable: 0x020000 <== mismatch +in9 (VINR1) : alarms: 0x004000 beep_enable: 0x004000 +temp1 : alarms: 0x000010 beep_enable: 0x000010 +temp2 : alarms: 0x000020 beep_enable: 0x000020 +temp3 : alarms: 0x002000 beep_enable: 0x000002 <== mismatch +fan1 : alarms: 0x000040 beep_enable: 0x000040 +fan2 : alarms: 0x000080 beep_enable: 0x000080 +fan3 : alarms: 0x000800 beep_enable: 0x000800 +fan4 : alarms: 0x200000 beep_enable: 0x200000 +fan5 : alarms: 0x400000 beep_enable: 0x400000 +tart1 : alarms: 0x010000 beep_enable: 0x040000 <== mismatch +tart2 : alarms: 0x020000 beep_enable: 0x080000 <== mismatch +tart3 : alarms: 0x040000 beep_enable: 0x100000 <== mismatch +case_open : alarms: 0x001000 beep_enable: 0x001000 +user_enable : alarms: -------- beep_enable: 0x800000 + +*** NOTE: It is the responsibility of user-space code to handle the fact +that the beep enable and alarm bits are in different positions when using that +feature of the chip. When an alarm goes off, you can be warned by a beeping signal through your computer speaker. It is possible to enable all beeping globally, or only @@ -109,5 +115,6 @@ often will do no harm, but will return 'old' values. W83791D TODO: --------------- -Provide a patch for per-file alarms as discussed on the mailing list +Provide a patch for per-file alarms and beep enables as defined in the hwmon + documentation (Documentation/hwmon/sysfs-interface) Provide a patch for smart-fan control (still need appropriate motherboard/fans) diff --git a/Documentation/i2c/busses/i2c-viapro b/Documentation/i2c/busses/i2c-viapro index 16775663b9f5..25680346e0ac 100644 --- a/Documentation/i2c/busses/i2c-viapro +++ b/Documentation/i2c/busses/i2c-viapro @@ -7,9 +7,12 @@ Supported adapters: * VIA Technologies, Inc. VT82C686A/B Datasheet: Sometimes available at the VIA website - * VIA Technologies, Inc. VT8231, VT8233, VT8233A, VT8235, VT8237R + * VIA Technologies, Inc. VT8231, VT8233, VT8233A Datasheet: available on request from VIA + * VIA Technologies, Inc. VT8235, VT8237R, VT8237A, VT8251 + Datasheet: available on request and under NDA from VIA + Authors: Kyösti Mälkki <kmalkki@cc.hut.fi>, Mark D. Studebaker <mdsxyz123@yahoo.com>, @@ -39,6 +42,8 @@ Your lspci -n listing must show one of these : device 1106:8235 (VT8231 function 4) device 1106:3177 (VT8235) device 1106:3227 (VT8237R) + device 1106:3337 (VT8237A) + device 1106:3287 (VT8251) If none of these show up, you should look in the BIOS for settings like enable ACPI / SMBus or even USB. diff --git a/Documentation/i2c/i2c-stub b/Documentation/i2c/i2c-stub index d6dcb138abf5..9cc081e69764 100644 --- a/Documentation/i2c/i2c-stub +++ b/Documentation/i2c/i2c-stub @@ -6,9 +6,12 @@ This module is a very simple fake I2C/SMBus driver. It implements four types of SMBus commands: write quick, (r/w) byte, (r/w) byte data, and (r/w) word data. +You need to provide a chip address as a module parameter when loading +this driver, which will then only react to SMBus commands to this address. + No hardware is needed nor associated with this module. It will accept write -quick commands to all addresses; it will respond to the other commands (also -to all addresses) by reading from or writing to an array in memory. It will +quick commands to one address; it will respond to the other commands (also +to one address) by reading from or writing to an array in memory. It will also spam the kernel logs for every command it handles. A pointer register with auto-increment is implemented for all byte @@ -21,6 +24,11 @@ The typical use-case is like this: 3. load the target sensors chip driver module 4. observe its behavior in the kernel log +PARAMETERS: + +int chip_addr: + The SMBus address to emulate a chip at. + CAVEATS: There are independent arrays for byte/data and word/data commands. Depending @@ -33,6 +41,9 @@ If the hardware for your driver has banked registers (e.g. Winbond sensors chips) this module will not work well - although it could be extended to support that pretty easily. +Only one chip address is supported - although this module could be +extended to support more. + If you spam it hard enough, printk can be lossy. This module really wants something like relayfs. diff --git a/Documentation/ia64/efirtc.txt b/Documentation/ia64/efirtc.txt index ede2c1e51cd7..057e6bebda8f 100644 --- a/Documentation/ia64/efirtc.txt +++ b/Documentation/ia64/efirtc.txt @@ -26,7 +26,7 @@ to initialize the system view of the time during boot. Because we wanted to minimize the impact on existing user-level apps using the CMOS clock, we decided to expose an API that was very similar to the one used today with the legacy RTC driver (driver/char/rtc.c). However, because -EFI provides a simpler services, not all all ioctl() are available. Also +EFI provides a simpler services, not all ioctl() are available. Also new ioctl()s have been introduced for things that EFI provides but not the legacy. diff --git a/Documentation/ia64/fsys.txt b/Documentation/ia64/fsys.txt index 28da181f9966..59dd689d9b86 100644 --- a/Documentation/ia64/fsys.txt +++ b/Documentation/ia64/fsys.txt @@ -165,7 +165,7 @@ complicated cases. * Signal handling The delivery of (asynchronous) signals must be delayed until fsys-mode -is exited. This is acomplished with the help of the lower-privilege +is exited. This is accomplished with the help of the lower-privilege transfer trap: arch/ia64/kernel/process.c:do_notify_resume_user() checks whether the interrupted task was in fsys-mode and, if so, sets PSR.lp and returns immediately. When fsys-mode is exited via the diff --git a/Documentation/ia64/mca.txt b/Documentation/ia64/mca.txt index a71cc6a67ef7..f097c60cba1b 100644 --- a/Documentation/ia64/mca.txt +++ b/Documentation/ia64/mca.txt @@ -12,7 +12,7 @@ by locks is indeterminate, including linked lists. --- The complicated ia64 MCA process. All of this is mandated by Intel's -specification for ia64 SAL, error recovery and and unwind, it is not as +specification for ia64 SAL, error recovery and unwind, it is not as if we have a choice here. * MCA occurs on one cpu, usually due to a double bit memory error. @@ -94,7 +94,7 @@ if we have a choice here. INIT is less complicated than MCA. Pressing the nmi button or using the equivalent command on the management console sends INIT to all -cpus. SAL picks one one of the cpus as the monarch and the rest are +cpus. SAL picks one of the cpus as the monarch and the rest are slaves. All the OS INIT handlers are entered at approximately the same time. The OS monarch prints the state of all tasks and returns, after which the slaves return and the system resumes. diff --git a/Documentation/ia64/serial.txt b/Documentation/ia64/serial.txt index f51eb4bc2ff1..040b9773209f 100644 --- a/Documentation/ia64/serial.txt +++ b/Documentation/ia64/serial.txt @@ -124,6 +124,13 @@ TROUBLESHOOTING SERIAL CONSOLE PROBLEMS - Add entry to /etc/securetty for console tty. + No ACPI serial devices found in 2.6.17 or later: + + - Turn on CONFIG_PNP and CONFIG_PNPACPI. Prior to 2.6.17, ACPI + serial devices were discovered by 8250_acpi. In 2.6.17, + 8250_acpi was replaced by the combination of 8250_pnp and + CONFIG_PNPACPI. + [1] http://www.dig64.org/specifications/DIG64_PCDPv20.pdf diff --git a/Documentation/ibm-acpi.txt b/Documentation/ibm-acpi.txt index 8b3fd82b2ce7..71aa40345272 100644 --- a/Documentation/ibm-acpi.txt +++ b/Documentation/ibm-acpi.txt @@ -450,7 +450,7 @@ his laptop (the location of sensors may vary on other models): No commands can be written to this file. -EXPERIMENTAL: Embedded controller reigster dump -- /proc/acpi/ibm/ecdump +EXPERIMENTAL: Embedded controller register dump -- /proc/acpi/ibm/ecdump ------------------------------------------------------------------------ This feature is marked EXPERIMENTAL because the implementation diff --git a/Documentation/ide.txt b/Documentation/ide.txt index 29866fbfb229..0bf38baa2db9 100644 --- a/Documentation/ide.txt +++ b/Documentation/ide.txt @@ -281,7 +281,7 @@ Summary of ide driver parameters for kernel command line "idex=serialize" : do not overlap operations on idex. Please note that you will have to specify this option for - both the respecitve primary and secondary channel + both the respective primary and secondary channel to take effect. "idex=four" : four drives on idex and ide(x^1) share same ports diff --git a/Documentation/input/amijoy.txt b/Documentation/input/amijoy.txt index 3b8b2d43a68e..4f0e89df5c51 100644 --- a/Documentation/input/amijoy.txt +++ b/Documentation/input/amijoy.txt @@ -79,10 +79,10 @@ JOY0DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 JOY1DAT Y7 Y6 Y5 Y4 Y3 Y2 Y1 Y0 X7 X6 X5 X4 X3 X2 X1 X0 0=LEFT CONTROLLER PAIR, 1=RIGHT CONTROLLER PAIR. - (4 counters total).The bit usage for both left and right + (4 counters total). The bit usage for both left and right addresses is shown below. Each 6 bit counter (Y7-Y2,X7-X2) is clocked by 2 of the signals input from the mouse serial - stream. Starting with first bit recived: + stream. Starting with first bit received: +-------------------+-----------------------------------------+ | Serial | Bit Name | Description | diff --git a/Documentation/input/atarikbd.txt b/Documentation/input/atarikbd.txt index 8fb896c74114..1e7e5853ba4c 100644 --- a/Documentation/input/atarikbd.txt +++ b/Documentation/input/atarikbd.txt @@ -10,7 +10,7 @@ provides a convenient connection point for a mouse and switch-type joysticks. The ikbd processor also maintains a time-of-day clock with one second resolution. The ikbd has been designed to be general enough that it can be used with a -ariety of new computer products. Product variations in a number of +variety of new computer products. Product variations in a number of keyswitches, mouse resolution, etc. can be accommodated. The ikbd communicates with the main processor over a high speed bi-directional serial interface. It can function in a variety of modes to facilitate @@ -30,7 +30,7 @@ is obtained by ORing 0x80 with the make code. The special codes 0xF6 through 0xFF are reserved for use as follows: 0xF6 status report 0xF7 absolute mouse position record - 0xF8-0xFB relative mouse position records(lsbs determind by + 0xF8-0xFB relative mouse position records (lsbs determined by mouse button states) 0xFC time-of-day 0xFD joystick report (both sticks) @@ -84,7 +84,7 @@ selected. 4.2 Absolute Position reporting The ikbd can also maintain absolute mouse position. Commands exist for -reseting the mouse position, setting X/Y scaling, and interrogating the +resetting the mouse position, setting X/Y scaling, and interrogating the current mouse position. 4.3 Mouse Cursor Key Mode @@ -406,7 +406,7 @@ INTERROGATION MODE. 9.18 SET JOYSTICK MONITORING 0x17 - rate ; time between samples in hundreths of a second + rate ; time between samples in hundredths of a second Returns: (in packets of two as long as in mode) %000000xy ; where y is JOYSTICK1 Fire button ; and x is JOYSTICK0 Fire button @@ -522,7 +522,7 @@ controller memory. The time between data bytes must be less than 20ms. 0x20 ; memory access { data } ; 6 data bytes starting at ADR -This comand permits the host to read from the ikbd controller memory. +This command permits the host to read from the ikbd controller memory. 9.26 CONTROLLER EXECUTE diff --git a/Documentation/input/cs461x.txt b/Documentation/input/cs461x.txt index 6181747a14d8..afe0d6543e09 100644 --- a/Documentation/input/cs461x.txt +++ b/Documentation/input/cs461x.txt @@ -27,7 +27,7 @@ This driver have the basic support for PCI devices only; there is no ISA or PnP ISA cards supported. AFAIK the ns558 have support for Crystal ISA and PnP ISA series. -The driver works witn ALSA drivers simultaneously. For exmple, the xracer +The driver works with ALSA drivers simultaneously. For example, the xracer uses joystick as input device and PCM device as sound output in one time. There are no sound or input collisions detected. The source code have comments about them; but I've found the joystick can be initialized diff --git a/Documentation/input/ff.txt b/Documentation/input/ff.txt index c7e10eaff203..085eb15b45b7 100644 --- a/Documentation/input/ff.txt +++ b/Documentation/input/ff.txt @@ -1,78 +1,48 @@ Force feedback for Linux. By Johann Deneux <deneux@ifrance.com> on 2001/04/22. +Updated by Anssi Hannula <anssi.hannula@gmail.com> on 2006/04/09. You may redistribute this file. Please remember to include shape.fig and interactive.fig as well. ---------------------------------------------------------------------------- -0. Introduction +1. Introduction ~~~~~~~~~~~~~~~ This document describes how to use force feedback devices under Linux. The goal is not to support these devices as if they were simple input-only devices (as it is already the case), but to really enable the rendering of force effects. -At the moment, only I-Force devices are supported, and not officially. That -means I had to find out how the protocol works on my own. Of course, the -information I managed to grasp is far from being complete, and I can not -guarranty that this driver will work for you. -This document only describes the force feedback part of the driver for I-Force -devices. Please read joystick.txt before reading further this document. +This document only describes the force feedback part of the Linux input +interface. Please read joystick.txt and input.txt before reading further this +document. 2. Instructions to the user ~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Here are instructions on how to compile and use the driver. In fact, this -driver is the normal iforce, input and evdev drivers written by Vojtech -Pavlik, plus additions to support force feedback. +To enable force feedback, you have to: + +1. have your kernel configured with evdev and a driver that supports your + device. +2. make sure evdev module is loaded and /dev/input/event* device files are + created. Before you start, let me WARN you that some devices shake violently during the initialisation phase. This happens for example with my "AVB Top Shot Pegasus". To stop this annoying behaviour, move you joystick to its limits. Anyway, you -should keep a hand on your device, in order to avoid it to brake down if +should keep a hand on your device, in order to avoid it to break down if something goes wrong. -At the kernel's compilation: - - Enable IForce/Serial - - Enable Event interface - -Compile the modules, install them. - -You also need inputattach. - -You then need to insert the modules into the following order: -% modprobe joydev -% modprobe serport # Only for serial -% modprobe iforce -% modprobe evdev -% ./inputattach -ifor $2 & # Only for serial -If you are using USB, you don't need the inputattach step. - -Please check that you have all the /dev/input entries needed: -cd /dev -rm js* -mkdir input -mknod input/js0 c 13 0 -mknod input/js1 c 13 1 -mknod input/js2 c 13 2 -mknod input/js3 c 13 3 -ln -s input/js0 js0 -ln -s input/js1 js1 -ln -s input/js2 js2 -ln -s input/js3 js3 - -mknod input/event0 c 13 64 -mknod input/event1 c 13 65 -mknod input/event2 c 13 66 -mknod input/event3 c 13 67 +If you have a serial iforce device, you need to start inputattach. See +joystick.txt for details. 2.1 Does it work ? ~~~~~~~~~~~~~~~~~~ There is an utility called fftest that will allow you to test the driver. % fftest /dev/input/eventXX -3. Instructions to the developper +3. Instructions to the developer ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ - All interactions are done using the event API. That is, you can use ioctl() +All interactions are done using the event API. That is, you can use ioctl() and write() on /dev/input/eventXX. - This information is subject to change. +This information is subject to change. 3.1 Querying device capabilities ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -86,18 +56,29 @@ int ioctl(int file_descriptor, int request, unsigned long *features); Returns the features supported by the device. features is a bitfield with the following bits: -- FF_X has an X axis (usually joysticks) -- FF_Y has an Y axis (usually joysticks) -- FF_WHEEL has a wheel (usually sterring wheels) - FF_CONSTANT can render constant force effects -- FF_PERIODIC can render periodic effects (sine, triangle, square...) +- FF_PERIODIC can render periodic effects with the following waveforms: + - FF_SQUARE square waveform + - FF_TRIANGLE triangle waveform + - FF_SINE sine waveform + - FF_SAW_UP sawtooth up waveform + - FF_SAW_DOWN sawtooth down waveform + - FF_CUSTOM custom waveform - FF_RAMP can render ramp effects - FF_SPRING can simulate the presence of a spring -- FF_FRICTION can simulate friction +- FF_FRICTION can simulate friction - FF_DAMPER can simulate damper effects -- FF_RUMBLE rumble effects (normally the only effect supported by rumble - pads) +- FF_RUMBLE rumble effects - FF_INERTIA can simulate inertia +- FF_GAIN gain is adjustable +- FF_AUTOCENTER autocenter is adjustable + +Note: In most cases you should use FF_PERIODIC instead of FF_RUMBLE. All + devices that support FF_RUMBLE support FF_PERIODIC (square, triangle, + sine) and the other way around. + +Note: The exact syntax FF_CUSTOM is undefined for the time being as no driver + supports it yet. int ioctl(int fd, EVIOCGEFFECTS, int *n); @@ -108,7 +89,7 @@ Returns the number of effects the device can keep in its memory. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ #include <linux/input.h> #include <sys/ioctl.h> - + int ioctl(int file_descriptor, int request, struct ff_effect *effect); "request" must be EVIOCSFF. @@ -120,6 +101,9 @@ to the unique id assigned by the driver. This data is required for performing some operations (removing an effect, controlling the playback). This if field must be set to -1 by the user in order to tell the driver to allocate a new effect. + +Effects are file descriptor specific. + See <linux/input.h> for a description of the ff_effect struct. You should also find help in a few sketches, contained in files shape.fig and interactive.fig. You need xfig to visualize these files. @@ -128,8 +112,8 @@ You need xfig to visualize these files. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ int ioctl(int fd, EVIOCRMFF, effect.id); -This makes room for new effects in the device's memory. Please note this won't -stop the effect if it was playing. +This makes room for new effects in the device's memory. Note that this also +stops the effect if it was playing. 3.4 Controlling the playback of effects ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ @@ -149,22 +133,21 @@ Control of playing is done with write(). Below is an example: play.type = EV_FF; play.code = effect.id; play.value = 3; - + write(fd, (const void*) &play, sizeof(play)); ... /* Stop an effect */ stop.type = EV_FF; stop.code = effect.id; stop.value = 0; - + write(fd, (const void*) &play, sizeof(stop)); 3.5 Setting the gain ~~~~~~~~~~~~~~~~~~~~ Not all devices have the same strength. Therefore, users should set a gain factor depending on how strong they want effects to be. This setting is -persistent across access to the driver, so you should not care about it if -you are writing games, as another utility probably already set this for you. +persistent across access to the driver. /* Set the gain of the device int gain; /* between 0 and 100 */ @@ -204,11 +187,14 @@ type of device, not all parameters can be dynamically updated. For example, the direction of an effect cannot be updated with iforce devices. In this case, the driver stops the effect, up-load it, and restart it. +Therefore it is recommended to dynamically change direction while the effect +is playing only when it is ok to restart the effect with a replay count of 1. 3.8 Information about the status of effects ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Every time the status of an effect is changed, an event is sent. The values and meanings of the fields of the event are as follows: + struct input_event { /* When the status of the effect changed */ struct timeval time; @@ -225,3 +211,9 @@ struct input_event { FF_STATUS_STOPPED The effect stopped playing FF_STATUS_PLAYING The effect started to play + +NOTE: Status feedback is only supported by iforce driver. If you have + a really good reason to use this, please contact + linux-joystick@atrey.karlin.mff.cuni.cz or anssi.hannula@gmail.com + so that support for it can be added to the rest of the drivers. + diff --git a/Documentation/input/gameport-programming.txt b/Documentation/input/gameport-programming.txt index 1ba3d322e0ac..14e0a8b70225 100644 --- a/Documentation/input/gameport-programming.txt +++ b/Documentation/input/gameport-programming.txt @@ -18,8 +18,8 @@ Make sure struct gameport is initialized to 0 in all other fields. The gameport generic code will take care of the rest. If your hardware supports more than one io address, and your driver can -choose which one program the hardware to, starting from the more exotic -addresses is preferred, because the likelyhood of clashing with the standard +choose which one to program the hardware to, starting from the more exotic +addresses is preferred, because the likelihood of clashing with the standard 0x201 address is smaller. Eg. if your driver supports addresses 0x200, 0x208, 0x210 and 0x218, then diff --git a/Documentation/input/input.txt b/Documentation/input/input.txt index 47137e75fdb8..ff8cea0225f9 100644 --- a/Documentation/input/input.txt +++ b/Documentation/input/input.txt @@ -68,8 +68,8 @@ will be available as a character device on major 13, minor 63: crw-r--r-- 1 root root 13, 63 Mar 28 22:45 mice - This device has to be created, unless you use devfs, in which case it's -created automatically. The commands to do create it by hand are: + This device has to be created. + The commands to create it by hand are: cd /dev mkdir input @@ -154,7 +154,7 @@ about it. 3.2 Event handlers ~~~~~~~~~~~~~~~~~~ - Event handlers distrubite the events from the devices to userland and + Event handlers distribute the events from the devices to userland and kernel, as needed. 3.2.1 keybdev @@ -230,7 +230,7 @@ generated in the kernel straight to the program, with timestamps. The API is still evolving, but should be useable now. It's described in section 5. - This should be the way for GPM and X to get keyboard and mouse mouse + This should be the way for GPM and X to get keyboard and mouse events. It allows for multihead in X without any specific multihead kernel support. The event codes are the same on all architectures and are hardware independent. @@ -279,7 +279,7 @@ struct input_event { }; 'time' is the timestamp, it returns the time at which the event happened. -Type is for example EV_REL for relative momement, REL_KEY for a keypress or +Type is for example EV_REL for relative moment, REL_KEY for a keypress or release. More types are defined in include/linux/input.h. 'code' is event code, for example REL_X or KEY_BACKSPACE, again a complete @@ -289,24 +289,3 @@ list is in include/linux/input.h. EV_REL, absolute new value for EV_ABS (joysticks ...), or 0 for EV_KEY for release, 1 for keypress and 2 for autorepeat. -6. Contacts -~~~~~~~~~~~ - This effort has its home page at: - - http://www.suse.cz/development/input/ - -You'll find both the latest HID driver and the complete Input driver -there as well as information how to access the CVS repository for -latest revisions of the drivers. - - There is also a mailing list for this: - - majordomo@atrey.karlin.mff.cuni.cz - -Send "subscribe linux-input" to subscribe to it. - -The input changes are also being worked on as part of the LinuxConsole -project, see: - - http://sourceforge.net/projects/linuxconsole/ - diff --git a/Documentation/input/joystick-parport.txt b/Documentation/input/joystick-parport.txt index d537c48cc6d0..ede5f33daad3 100644 --- a/Documentation/input/joystick-parport.txt +++ b/Documentation/input/joystick-parport.txt @@ -456,8 +456,8 @@ uses the following kernel/module command line: 8 | Sony PSX DDR controller 9 | SNES mouse - The exact type of the PSX controller type is autoprobed when used so -hot swapping should work (but is not recomended). + The exact type of the PSX controller type is autoprobed when used, so +hot swapping should work (but is not recommended). Should you want to use more than one of parallel ports at once, you can use gamecon.map2 and gamecon.map3 as additional command line parameters for two @@ -465,8 +465,8 @@ more parallel ports. There are two options specific to PSX driver portion. gamecon.psx_delay sets the command delay when talking to the controllers. The default of 25 should -work but you can try lowering it for better performace. If your pads don't -respond try raising it untill they work. Setting the type to 8 allows the +work but you can try lowering it for better performance. If your pads don't +respond try raising it until they work. Setting the type to 8 allows the driver to be used with Dance Dance Revolution or similar games. Arrow keys are registered as key presses instead of X and Y axes. diff --git a/Documentation/input/joystick.txt b/Documentation/input/joystick.txt index 841c353297e6..389de9bd9878 100644 --- a/Documentation/input/joystick.txt +++ b/Documentation/input/joystick.txt @@ -60,7 +60,7 @@ and install it before going on. 2.2 Device nodes ~~~~~~~~~~~~~~~~ -For applications to be able to use the joysticks, in you don't use devfs, +For applications to be able to use the joysticks, you'll have to manually create these nodes in /dev: cd /dev diff --git a/Documentation/input/yealink.txt b/Documentation/input/yealink.txt index 0962c5c948be..0a8c97e87d47 100644 --- a/Documentation/input/yealink.txt +++ b/Documentation/input/yealink.txt @@ -87,13 +87,13 @@ Line 3 Format : 888888888888 Format description: - From a user space perspective the world is seperated in "digits" and "icons". + From a userspace perspective the world is separated into "digits" and "icons". A digit can have a character set, an icon can only be ON or OFF. Format specifier '8' : Generic 7 segment digit with individual addressable segments - Reduced capabillity 7 segm digit, when segments are hard wired together. + Reduced capability 7 segm digit, when segments are hard wired together. '1' : 2 segments digit only able to produce a 1. 'e' : Most significant day of the month digit, able to produce at least 1 2 3. diff --git a/Documentation/ioctl/hdio.txt b/Documentation/ioctl/hdio.txt index 11c9be49f37c..c19efdeace2c 100644 --- a/Documentation/ioctl/hdio.txt +++ b/Documentation/ioctl/hdio.txt @@ -203,7 +203,7 @@ HDIO_SET_MULTCOUNT change IDE blockmode Source code comments read: - This is tightly woven into the driver->do_special can not + This is tightly woven into the driver->do_special cannot touch. DON'T do it again until a total personality rewrite is committed. diff --git a/Documentation/isdn/INTERFACE.fax b/Documentation/isdn/INTERFACE.fax index 7e5731319e30..9c8c6d914ec7 100644 --- a/Documentation/isdn/INTERFACE.fax +++ b/Documentation/isdn/INTERFACE.fax @@ -26,7 +26,7 @@ Structure T30_s description: If the HL-driver receives ISDN_CMD_FAXCMD, all needed information is in this struct set by the LL. To signal information to the LL, the HL-driver has to set the - the parameters and use ISDN_STAT_FAXIND. + parameters and use ISDN_STAT_FAXIND. (Please refer to INTERFACE) Structure T30_s: diff --git a/Documentation/isdn/README.hysdn b/Documentation/isdn/README.hysdn index 56cc59df1fb7..eeca11f00ccd 100644 --- a/Documentation/isdn/README.hysdn +++ b/Documentation/isdn/README.hysdn @@ -1,6 +1,6 @@ $Id: README.hysdn,v 1.3.6.1 2001/02/10 14:41:19 kai Exp $ The hysdn driver has been written by -by Werner Cornelius (werner@isdn4linux.de or werner@titro.de) +Werner Cornelius (werner@isdn4linux.de or werner@titro.de) for Hypercope GmbH Aachen Germany. Hypercope agreed to publish this driver under the GNU General Public License. diff --git a/Documentation/java.txt b/Documentation/java.txt index e4814c213301..c768dc63b34e 100644 --- a/Documentation/java.txt +++ b/Documentation/java.txt @@ -22,7 +22,7 @@ other program after you have done the following: the kernel (CONFIG_BINFMT_MISC) and set it up properly. If you choose to compile it as a module, you will have to insert it manually with modprobe/insmod, as kmod - can not easily be supported with binfmt_misc. + cannot easily be supported with binfmt_misc. Read the file 'binfmt_misc.txt' in this directory to know more about the configuration process. diff --git a/Documentation/kbuild/kconfig-language.txt b/Documentation/kbuild/kconfig-language.txt index 003fccc14d24..125093c3ef76 100644 --- a/Documentation/kbuild/kconfig-language.txt +++ b/Documentation/kbuild/kconfig-language.txt @@ -1,7 +1,7 @@ Introduction ------------ -The configuration database is collection of configuration options +The configuration database is a collection of configuration options organized in a tree structure: +- Code maturity level options @@ -110,7 +110,7 @@ applicable everywhere (see syntax). the indentation level, this means it ends at the first line which has a smaller indentation than the first line of the help text. "---help---" and "help" do not differ in behaviour, "---help---" is - used to help visually seperate configuration logic from help within + used to help visually separate configuration logic from help within the file as an aid to developers. @@ -226,7 +226,7 @@ menuconfig: "menuconfig" <symbol> <config options> -This is similiar to the simple config entry above, but it also gives a +This is similar to the simple config entry above, but it also gives a hint to front ends, that all suboptions should be displayed as a separate list of options. diff --git a/Documentation/kbuild/makefiles.txt b/Documentation/kbuild/makefiles.txt index b7d6abb501a6..50f4eddf899c 100644 --- a/Documentation/kbuild/makefiles.txt +++ b/Documentation/kbuild/makefiles.txt @@ -390,7 +390,7 @@ more details, with real examples. The kernel may be built with several different versions of $(CC), each supporting a unique set of features and options. kbuild provide basic support to check for valid options for $(CC). - $(CC) is useally the gcc compiler, but other alternatives are + $(CC) is usually the gcc compiler, but other alternatives are available. as-option @@ -421,6 +421,11 @@ more details, with real examples. The second argument is optional, and if supplied will be used if first argument is not supported. + as-instr + as-instr checks if the assembler reports a specific instruction + and then outputs either option1 or option2 + C escapes are supported in the test instruction + cc-option cc-option is used to check if $(CC) supports a given option, and not supported to use an optional second option. diff --git a/Documentation/kbuild/modules.txt b/Documentation/kbuild/modules.txt index 2e7702e94a78..769ee05ee4d1 100644 --- a/Documentation/kbuild/modules.txt +++ b/Documentation/kbuild/modules.txt @@ -43,7 +43,7 @@ are not planned to be included in the kernel tree. What is covered within this file is mainly information to authors of modules. The author of an external module should supply a makefile that hides most of the complexity, so one only has to type -'make' to build the module. A complete example will be present in +'make' to build the module. A complete example will be presented in chapter 4, "Creating a kbuild file for an external module". @@ -61,6 +61,7 @@ when building an external module. make -C <path-to-kernel> M=`pwd` For the running kernel use: + make -C /lib/modules/`uname -r`/build M=`pwd` For the above command to succeed, the kernel must have been @@ -130,10 +131,10 @@ when building an external module. To make sure the kernel contains the information required to build external modules the target 'modules_prepare' must be used. - 'module_prepare' exists solely as a simple way to prepare + 'modules_prepare' exists solely as a simple way to prepare a kernel source tree for building external modules. Note: modules_prepare will not build Module.symvers even if - CONFIG_MODULEVERSIONING is set. Therefore a full kernel build + CONFIG_MODVERSIONS is set. Therefore a full kernel build needs to be executed to make module versioning work. --- 2.5 Building separate files for a module @@ -450,7 +451,7 @@ kernel refuses to load the module. Module.symvers contains a list of all exported symbols from a kernel build. ---- 7.1 Symbols fron the kernel (vmlinux + modules) +--- 7.1 Symbols from the kernel (vmlinux + modules) During a kernel build, a file named Module.symvers will be generated. Module.symvers contains all exported symbols from the kernel and diff --git a/Documentation/kdump/kdump.txt b/Documentation/kdump/kdump.txt index 08bafa8c1caa..99f2d4d4bf7d 100644 --- a/Documentation/kdump/kdump.txt +++ b/Documentation/kdump/kdump.txt @@ -249,7 +249,7 @@ If die() is called, and it happens to be a thread with pid 0 or 1, or die() is called inside interrupt context or die() is called and panic_on_oops is set, the system will boot into the dump-capture kernel. -On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system system will boot into the dump-capture kernel. +On powererpc systems when a soft-reset is generated, die() is called by all cpus and the system will boot into the dump-capture kernel. For testing purposes, you can trigger a crash by using "ALT-SysRq-c", "echo c > /proc/sysrq-trigger or write a module to force the panic. diff --git a/Documentation/kernel-docs.txt b/Documentation/kernel-docs.txt index 99d24f2943ee..b53bccbd9727 100644 --- a/Documentation/kernel-docs.txt +++ b/Documentation/kernel-docs.txt @@ -290,17 +290,6 @@ Description: Very nice 92 pages GPL book on the topic of modules programming. Lots of examples. - * Title: "Device File System (devfs) Overview" - Author: Richard Gooch. - URL: http://www.atnf.csiro.au/people/rgooch/linux/docs/devfs.html - Keywords: filesystem, /dev, devfs, dynamic devices, major/minor - allocation, device management. - Description: Document describing Richard Gooch's controversial - devfs, which allows for dynamic devices, only shows present - devices in /dev, gets rid of major/minor numbers allocation - problems, and allows for hundreds of identical devices (which some - USB systems might demand soon). - * Title: "I/O Event Handling Under Linux" Author: Richard Gooch. URL: http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 766abdab94e7..ff571f9298e0 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -110,6 +110,13 @@ be entered as an environment variable, whereas its absence indicates that it will appear as a kernel argument readable via /proc/cmdline by programs running once the system is up. +The number of kernel parameters is not limited, but the length of the +complete command line (parameters including spaces etc.) is limited to +a fixed number of characters. This limit depends on the architecture +and is between 256 and 4096 characters. It is defined in the file +./include/asm/setup.h as COMMAND_LINE_SIZE. + + 53c7xx= [HW,SCSI] Amiga SCSI controllers See header of drivers/scsi/53c7xx.c. See also Documentation/scsi/ncr53c7xx.txt. @@ -282,9 +289,6 @@ running once the system is up. autotest [IA64] - awe= [HW,OSS] AWE32/SB32/AWE64 wave table synth - Format: <io>,<memsize>,<isapnp> - aztcd= [HW,CD] Aztech CD268 CDROM driver Format: <io>,0x79 (?) @@ -348,9 +352,9 @@ running once the system is up. clock= [BUGS=IA-32, HW] gettimeofday clocksource override. [Deprecated] - Forces specified clocksource (if avaliable) to be used + Forces specified clocksource (if available) to be used when calculating gettimeofday(). If specified - clocksource is not avalible, it defaults to PIT. + clocksource is not available, it defaults to PIT. Format: { pit | tsc | cyclone | pmtmr } disable_8254_timer @@ -529,10 +533,6 @@ running once the system is up. Default value is 0. Value can be changed at runtime via /selinux/enforce. - es1370= [HW,OSS] - Format: <lineout>[,<micbias>] - See also header of sound/oss/es1370.c. - es1371= [HW,OSS] Format: <spdif>,[<nomix>,[<amplifier>]] See also header of sound/oss/es1371.c. @@ -573,11 +573,6 @@ running once the system is up. gscd= [HW,CD] Format: <io> - gt96100eth= [NET] MIPS GT96100 Advanced Communication Controller - - gus= [HW,OSS] - Format: <io>,<irq>,<dma>,<dma16> - gvp11= [HW,SCSI] hashdist= [KNL,NUMA] Large hashes allocated during boot @@ -606,8 +601,8 @@ running once the system is up. noirqbalance [IA-32,SMP,KNL] Disable kernel irq balancing i8042.direct [HW] Put keyboard port into non-translated mode - i8042.dumbkbd [HW] Pretend that controlled can only read data from - keyboard and can not control its state + i8042.dumbkbd [HW] Pretend that controller can only read data from + keyboard and cannot control its state (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 @@ -836,12 +831,6 @@ running once the system is up. (machvec) in a generic kernel. Example: machvec=hpzx1_swiotlb - mad16= [HW,OSS] Format: - <io>,<irq>,<dma>,<dma16>,<mpu_io>,<mpu_irq>,<joystick> - - maui= [HW,OSS] - Format: <io>,<irq> - max_loop= [LOOP] Maximum number of loopback devices that can be mounted Format: <1-256> @@ -1109,9 +1098,6 @@ running once the system is up. opl3= [HW,OSS] Format: <io> - opl3sa= [HW,OSS] - Format: <io>,<irq>,<dma>,<dma2>,<mpu_io>,<mpu_irq> - opl3sa2= [HW,OSS] Format: <io>,<irq>,<dma>,<dma2>,<mss_io>,<mpu_io>,<ymode>,<loopback>[,<isapnp>,<multiple] @@ -1240,7 +1226,11 @@ running once the system is up. bootloader. This is currently used on IXP2000 systems where the bus has to be configured a certain way for adjunct CPUs. - + noearly [X86] Don't do any early type 1 scanning. + This might help on some broken boards which + machine check when some devices' config space + is read. But various workarounds are disabled + and some IOMMU drivers will not work. pcmv= [HW,PCMCIA] BadgePAD 4 pd. [PARIDE] @@ -1322,7 +1312,7 @@ running once the system is up. pt. [PARIDE] See Documentation/paride.txt. - quiet= [KNL] Disable log messages + quiet [KNL] Disable most log messages r128= [HW,DRM] @@ -1348,10 +1338,6 @@ running once the system is up. rcu.qlowmark= [KNL,BOOT] Set threshold of queued RCU callbacks below which batch limiting is re-enabled. - rcu.rsinterval= [KNL,BOOT,SMP] Set the number of additional - RCU callbacks to queued before forcing reschedule - on all cpus. - rdinit= [KNL] Format: <full_path> Run specified binary instead of /init from the ramdisk, @@ -1359,7 +1345,7 @@ running once the system is up. reboot= [BUGS=IA-32,BUGS=ARM,BUGS=IA-64] Rebooting mode Format: <reboot_mode>[,<reboot_mode2>[,...]] - See arch/*/kernel/reboot.c. + See arch/*/kernel/reboot.c or arch/*/kernel/process.c reserve= [KNL,BUGS] Force the kernel to ignore some iomem area @@ -1368,6 +1354,9 @@ running once the system is up. Reserves a hole at the top of the kernel virtual address space. + reset_devices [KNL] Force drivers to reset the underlying device + during initialization. + resume= [SWSUSP] Specify the partition device for software suspend @@ -1443,9 +1432,6 @@ running once the system is up. sg_def_reserved_size= [SCSI] - sgalaxy= [HW,OSS] - Format: <io>,<irq>,<dma>,<dma2>,<sgbase> - shapers= [NET] Maximal number of shapers. @@ -1586,9 +1572,6 @@ running once the system is up. snd-ymfpci= [HW,ALSA] - sonicvibes= [HW,OSS] - Format: <reverb> - sonycd535= [HW,CD] Format: <io>[,<irq>] diff --git a/Documentation/keys.txt b/Documentation/keys.txt index e373f0212843..3da586bc7859 100644 --- a/Documentation/keys.txt +++ b/Documentation/keys.txt @@ -671,7 +671,7 @@ The keyctl syscall functions are: Note that this setting is inherited across fork/exec. - [1] The default default is: the thread keyring if there is one, otherwise + [1] The default is: the thread keyring if there is one, otherwise the process keyring if there is one, otherwise the session keyring if there is one, otherwise the user default session keyring. @@ -708,14 +708,14 @@ The keyctl syscall functions are: If the specified key is 0, then any assumed authority will be divested. - The assumed authorititive key is inherited across fork and exec. + The assumed authoritative key is inherited across fork and exec. =============== KERNEL SERVICES =============== -The kernel services for key managment are fairly simple to deal with. They can +The kernel services for key management are fairly simple to deal with. They can be broken down into two areas: keys and key types. Dealing with keys is fairly straightforward. Firstly, the kernel service diff --git a/Documentation/kobject.txt b/Documentation/kobject.txt index 949f7b5a2053..e44855513b3d 100644 --- a/Documentation/kobject.txt +++ b/Documentation/kobject.txt @@ -51,7 +51,7 @@ more complex object types. It provides a set of basic fields that almost all complex data types share. kobjects are intended to be embedded in larger data structures and replace fields they duplicate. -1.2 Defintion +1.2 Definition struct kobject { char name[KOBJ_NAME_LEN]; diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt index 2c3b1eae4280..ba26201d5023 100644 --- a/Documentation/kprobes.txt +++ b/Documentation/kprobes.txt @@ -151,9 +151,9 @@ So that you can load and unload Kprobes-based instrumentation modules, make sure "Loadable module support" (CONFIG_MODULES) and "Module unloading" (CONFIG_MODULE_UNLOAD) are set to "y". -You may also want to ensure that CONFIG_KALLSYMS and perhaps even -CONFIG_KALLSYMS_ALL are set to "y", since kallsyms_lookup_name() -is a handy, version-independent way to find a function's address. +Also make sure that CONFIG_KALLSYMS and perhaps even CONFIG_KALLSYMS_ALL +are set to "y", since kallsyms_lookup_name() is used by the in-kernel +kprobe address resolution code. If you need to insert a probe in the middle of a function, you may find it useful to "Compile the kernel with debug info" (CONFIG_DEBUG_INFO), @@ -179,6 +179,27 @@ occurs during execution of kp->pre_handler or kp->post_handler, or during single-stepping of the probed instruction, Kprobes calls kp->fault_handler. Any or all handlers can be NULL. +NOTE: +1. With the introduction of the "symbol_name" field to struct kprobe, +the probepoint address resolution will now be taken care of by the kernel. +The following will now work: + + kp.symbol_name = "symbol_name"; + +(64-bit powerpc intricacies such as function descriptors are handled +transparently) + +2. Use the "offset" field of struct kprobe if the offset into the symbol +to install a probepoint is known. This field is used to calculate the +probepoint. + +3. Specify either the kprobe "symbol_name" OR the "addr". If both are +specified, kprobe registration will fail with -EINVAL. + +4. With CISC architectures (such as i386 and x86_64), the kprobes code +does not validate if the kprobe.addr is at an instruction boundary. +Use "offset" with caution. + register_kprobe() returns 0 on success, or a negative errno otherwise. User's pre-handler (kp->pre_handler): @@ -225,6 +246,12 @@ control to Kprobes.) If the probed function is declared asmlinkage, fastcall, or anything else that affects how args are passed, the handler's declaration must match. +NOTE: A macro JPROBE_ENTRY is provided to handle architecture-specific +aliasing of jp->entry. In the interest of portability, it is advised +to use: + + jp->entry = JPROBE_ENTRY(handler); + register_jprobe() returns 0 on success, or a negative errno otherwise. 4.3 register_kretprobe @@ -251,6 +278,11 @@ of interest: - ret_addr: the return address - rp: points to the corresponding kretprobe object - task: points to the corresponding task struct + +The regs_return_value(regs) macro provides a simple abstraction to +extract the return value from the appropriate register as defined by +the architecture's ABI. + The handler's return value is currently ignored. 4.4 unregister_*probe @@ -369,7 +401,6 @@ stack trace and selected i386 registers when do_fork() is called. #include <linux/kernel.h> #include <linux/module.h> #include <linux/kprobes.h> -#include <linux/kallsyms.h> #include <linux/sched.h> /*For each probe you need to allocate a kprobe structure*/ @@ -403,18 +434,14 @@ int handler_fault(struct kprobe *p, struct pt_regs *regs, int trapnr) return 0; } -int init_module(void) +static int __init kprobe_init(void) { int ret; kp.pre_handler = handler_pre; kp.post_handler = handler_post; kp.fault_handler = handler_fault; - kp.addr = (kprobe_opcode_t*) kallsyms_lookup_name("do_fork"); - /* register the kprobe now */ - if (!kp.addr) { - printk("Couldn't find %s to plant kprobe\n", "do_fork"); - return -1; - } + kp.symbol_name = "do_fork"; + if ((ret = register_kprobe(&kp) < 0)) { printk("register_kprobe failed, returned %d\n", ret); return -1; @@ -423,12 +450,14 @@ int init_module(void) return 0; } -void cleanup_module(void) +static void __exit kprobe_exit(void) { unregister_kprobe(&kp); printk("kprobe unregistered\n"); } +module_init(kprobe_init) +module_exit(kprobe_exit) MODULE_LICENSE("GPL"); ----- cut here ----- @@ -463,7 +492,6 @@ the arguments of do_fork(). #include <linux/fs.h> #include <linux/uio.h> #include <linux/kprobes.h> -#include <linux/kallsyms.h> /* * Jumper probe for do_fork. @@ -485,17 +513,13 @@ long jdo_fork(unsigned long clone_flags, unsigned long stack_start, } static struct jprobe my_jprobe = { - .entry = (kprobe_opcode_t *) jdo_fork + .entry = JPROBE_ENTRY(jdo_fork) }; -int init_module(void) +static int __init jprobe_init(void) { int ret; - my_jprobe.kp.addr = (kprobe_opcode_t *) kallsyms_lookup_name("do_fork"); - if (!my_jprobe.kp.addr) { - printk("Couldn't find %s to plant jprobe\n", "do_fork"); - return -1; - } + my_jprobe.kp.symbol_name = "do_fork"; if ((ret = register_jprobe(&my_jprobe)) <0) { printk("register_jprobe failed, returned %d\n", ret); @@ -506,12 +530,14 @@ int init_module(void) return 0; } -void cleanup_module(void) +static void __exit jprobe_exit(void) { unregister_jprobe(&my_jprobe); printk("jprobe unregistered\n"); } +module_init(jprobe_init) +module_exit(jprobe_exit) MODULE_LICENSE("GPL"); ----- cut here ----- @@ -530,16 +556,13 @@ report failed calls to sys_open(). #include <linux/kernel.h> #include <linux/module.h> #include <linux/kprobes.h> -#include <linux/kallsyms.h> static const char *probed_func = "sys_open"; /* Return-probe handler: If the probed function fails, log the return value. */ static int ret_handler(struct kretprobe_instance *ri, struct pt_regs *regs) { - // Substitute the appropriate register name for your architecture -- - // e.g., regs->rax for x86_64, regs->gpr[3] for ppc64. - int retval = (int) regs->eax; + int retval = regs_return_value(regs); if (retval < 0) { printk("%s returns %d\n", probed_func, retval); } @@ -552,15 +575,11 @@ static struct kretprobe my_kretprobe = { .maxactive = 20 }; -int init_module(void) +static int __init kretprobe_init(void) { int ret; - my_kretprobe.kp.addr = - (kprobe_opcode_t *) kallsyms_lookup_name(probed_func); - if (!my_kretprobe.kp.addr) { - printk("Couldn't find %s to plant return probe\n", probed_func); - return -1; - } + my_kretprobe.kp.symbol_name = (char *)probed_func; + if ((ret = register_kretprobe(&my_kretprobe)) < 0) { printk("register_kretprobe failed, returned %d\n", ret); return -1; @@ -569,7 +588,7 @@ int init_module(void) return 0; } -void cleanup_module(void) +static void __exit kretprobe_exit(void) { unregister_kretprobe(&my_kretprobe); printk("kretprobe unregistered\n"); @@ -578,6 +597,8 @@ void cleanup_module(void) my_kretprobe.nmissed, probed_func); } +module_init(kretprobe_init) +module_exit(kretprobe_exit) MODULE_LICENSE("GPL"); ----- cut here ----- @@ -590,3 +611,5 @@ messages.) For additional information on Kprobes, refer to the following URLs: http://www-106.ibm.com/developerworks/library/l-kprobes.html?ca=dgr-lnxw42Kprobe http://www.redhat.com/magazine/005mar05/features/kprobes/ +http://www-users.cs.umn.edu/~boutcher/kprobes/ +http://www.linuxsymposium.org/2006/linuxsymposium_procv2.pdf (pages 101-115) diff --git a/Documentation/laptop-mode.txt b/Documentation/laptop-mode.txt index 5696e879449b..c487186eb2b9 100644 --- a/Documentation/laptop-mode.txt +++ b/Documentation/laptop-mode.txt @@ -152,7 +152,7 @@ loaded on demand while the application executes) and sequentially accessed data DO_REMOUNTS: The control script automatically remounts any mounted journaled filesystems -with approriate commit interval options. When this option is set to 0, this +with appropriate commit interval options. When this option is set to 0, this feature is disabled. DO_REMOUNT_NOATIME: diff --git a/Documentation/lockdep-design.txt b/Documentation/lockdep-design.txt index 00d93605bfd3..dab123db5a4f 100644 --- a/Documentation/lockdep-design.txt +++ b/Documentation/lockdep-design.txt @@ -36,6 +36,28 @@ The validator tracks lock-class usage history into 5 separate state bits: - 'ever used' [ == !unused ] +When locking rules are violated, these 4 state bits are presented in the +locking error messages, inside curlies. A contrived example: + + modprobe/2287 is trying to acquire lock: + (&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24 + + but task is already holding lock: + (&sio_locks[i].lock){--..}, at: [<c02867fd>] mutex_lock+0x21/0x24 + + +The bit position indicates hardirq, softirq, hardirq-read, +softirq-read respectively, and the character displayed in each +indicates: + + '.' acquired while irqs enabled + '+' acquired in irq context + '-' acquired in process context with irqs disabled + '?' read-acquired both with irqs enabled and in irq context + +Unused mutexes cannot be part of the cause of an error. + + Single-lock state rules: ------------------------ @@ -111,7 +133,7 @@ cases there is an inherent "natural" ordering between the two objects (defined by the properties of the hierarchy), and the kernel grabs the locks in this fixed order on each of the objects. -An example of such an object hieararchy that results in "nested locking" +An example of such an object hierarchy that results in "nested locking" is that of a "whole disk" block-dev object and a "partition" block-dev object; the partition is "part of" the whole device and as long as one always takes the whole disk lock as a higher lock than the partition @@ -136,11 +158,11 @@ enum bdev_bd_mutex_lock_class In this case the locking is done on a bdev object that is known to be a partition. -The validator treats a lock that is taken in such a nested fasion as a +The validator treats a lock that is taken in such a nested fashion as a separate (sub)class for the purposes of validation. Note: When changing code to use the _nested() primitives, be careful and -check really thoroughly that the hiearchy is correctly mapped; otherwise +check really thoroughly that the hierarchy is correctly mapped; otherwise you can get false positives or false negatives. Proof of 100% correctness: @@ -148,7 +170,7 @@ Proof of 100% correctness: The validator achieves perfect, mathematical 'closure' (proof of locking correctness) in the sense that for every simple, standalone single-task -locking sequence that occured at least once during the lifetime of the +locking sequence that occurred at least once during the lifetime of the kernel, the validator proves it with a 100% certainty that no combination and timing of these locking sequences can cause any class of lock related deadlock. [*] diff --git a/Documentation/m68k/kernel-options.txt b/Documentation/m68k/kernel-options.txt index d5d3f064f552..1c41db21d3c1 100644 --- a/Documentation/m68k/kernel-options.txt +++ b/Documentation/m68k/kernel-options.txt @@ -415,7 +415,7 @@ switch to another mode once Linux has started. The first 3 parameters of this sub-option should be obvious: <xres>, <yres> and <depth> give the dimensions of the screen and the number of -planes (depth). The depth is is the logarithm to base 2 of the number +planes (depth). The depth is the logarithm to base 2 of the number of colors possible. (Or, the other way round: The number of colors is 2^depth). diff --git a/Documentation/mca.txt b/Documentation/mca.txt index 60913354cb7d..aabce4ad90f9 100644 --- a/Documentation/mca.txt +++ b/Documentation/mca.txt @@ -177,7 +177,7 @@ Currently, there are a number of MCA-specific device drivers. with clones that have a different adapter id than the original NE/2. -6) Future Domain MCS-600/700, OEM'd IBM Fast SCSI Aapter/A and +6) 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. diff --git a/Documentation/md.txt b/Documentation/md.txt index 0668f9dc9d29..2202f5dc8ac2 100644 --- a/Documentation/md.txt +++ b/Documentation/md.txt @@ -62,7 +62,7 @@ be reconstructed (due to no parity). For this reason, md will normally refuse to start such an array. This requires the sysadmin to take action to explicitly start the array -desipite possible corruption. This is normally done with +despite possible corruption. This is normally done with mdadm --assemble --force .... This option is not really available if the array has the root @@ -154,11 +154,12 @@ contains further md-specific information about the device. All md devices contain: level - a text file indicating the 'raid level'. This may be a standard - numerical level prefixed by "RAID-" - e.g. "RAID-5", or some - other name such as "linear" or "multipath". + a text file indicating the 'raid level'. e.g. raid0, raid1, + raid5, linear, multipath, faulty. If no raid level has been set yet (array is still being - assembled), this file will be empty. + assembled), the value will reflect whatever has been written + to it, which may be a name like the above, or may be a number + such as '0', '5', etc. raid_disks a text file with a simple number indicating the number of devices @@ -174,7 +175,7 @@ All md devices contain: raid levels that involve striping (1,4,5,6,10). The address space of the array is conceptually divided into chunks and consecutive chunks are striped onto neighbouring devices. - The size should be atleast PAGE_SIZE (4k) and should be a power + The size should be at least PAGE_SIZE (4k) and should be a power of 2. This can only be set while assembling an array component_size @@ -192,14 +193,6 @@ All md devices contain: 1.2 (newer format in varying locations) or "none" indicating that the kernel isn't managing metadata at all. - level - The raid 'level' for this array. The name will often (but not - always) be the same as the name of the module that implements the - level. To be auto-loaded the module must have an alias - md-$LEVEL e.g. md-raid5 - This can be written only while the array is being assembled, not - after it is started. - layout The "layout" for the array for the particular level. This is simply a number that is interpretted differently by different @@ -221,8 +214,8 @@ All md devices contain: safe_mode_delay When an md array has seen no write requests for a certain period of time, it will be marked as 'clean'. When another write - request arrive, the array is marked as 'dirty' before the write - commenses. This is known as 'safe_mode'. + request arrives, the array is marked as 'dirty' before the write + commences. This is known as 'safe_mode'. The 'certain period' is controlled by this file which stores the period as a number of seconds. The default is 200msec (0.200). Writing a value of 0 disables safemode. @@ -314,8 +307,8 @@ Each directory contains: This applies only to raid1 arrays. spare - device is working, but not a full member. This includes spares that are in the process - of being recoverred to - This list make grow in future. + of being recovered to + This list may grow in future. This can be written to. Writing "faulty" simulates a failure on the device. Writing "remove" removes the device from the array. @@ -337,7 +330,7 @@ Each directory contains: This gives the role that the device has in the array. It will either be 'none' if the device is not active in the array (i.e. is a spare or has failed) or an integer less than the - 'raid_disks' number for the array indicating which possition + 'raid_disks' number for the array indicating which position it currently fills. This can only be set while assembling an array. A device for which this is set is assumed to be working. @@ -360,7 +353,7 @@ in the array. These are named rdNN -where 'NN' is the possition in the array, starting from 0. +where 'NN' is the position in the array, starting from 0. So for a 3 drive array there will be rd0, rd1, rd2. These are symbolic links to the appropriate 'dev-XXX' entry. Thus, for example, @@ -410,6 +403,15 @@ also have than sectors, this my be larger than the number of actual errors by a factor of the number of sectors in a page. + bitmap_set_bits + If the array has a write-intent bitmap, then writing to this + attribute can set bits in the bitmap, indicating that a resync + would need to check the corresponding blocks. Either individual + numbers or start-end pairs can be written. Multiple numbers + can be separated by a space. + Note that the numbers are 'bit' numbers, not 'block' numbers. + They should be scaled by the bitmap_chunksize. + Each active md device may also have attributes specific to the personality module that manages it. These are specific to the implementation of the module and could diff --git a/Documentation/memory-barriers.txt b/Documentation/memory-barriers.txt index 46b9b389df35..994355b0cd19 100644 --- a/Documentation/memory-barriers.txt +++ b/Documentation/memory-barriers.txt @@ -670,7 +670,7 @@ effectively random order, despite the write barrier issued by CPU 1: In the above example, CPU 2 perceives that B is 7, despite the load of *C -(which would be B) coming after the the LOAD of C. +(which would be B) coming after the LOAD of C. If, however, a data dependency barrier were to be placed between the load of C and the load of *C (ie: B) on CPU 2: @@ -1915,7 +1915,7 @@ Whilst most CPUs do imply a data dependency barrier on the read when a memory access depends on a read, not all do, so it may not be relied on. Other CPUs may also have split caches, but must coordinate between the various -cachelets for normal memory accesss. The semantics of the Alpha removes the +cachelets for normal memory accesses. The semantics of the Alpha removes the need for coordination in absence of memory barriers. diff --git a/Documentation/mono.txt b/Documentation/mono.txt index 807a0c7b4737..e8e1758e87da 100644 --- a/Documentation/mono.txt +++ b/Documentation/mono.txt @@ -26,7 +26,7 @@ other program after you have done the following: the kernel (CONFIG_BINFMT_MISC) and set it up properly. If you choose to compile it as a module, you will have to insert it manually with modprobe/insmod, as kmod - can not be easily supported with binfmt_misc. + cannot be easily supported with binfmt_misc. Read the file 'binfmt_misc.txt' in this directory to know more about the configuration process. diff --git a/Documentation/networking/3c509.txt b/Documentation/networking/3c509.txt index 867a99f88c68..0643e3b7168c 100644 --- a/Documentation/networking/3c509.txt +++ b/Documentation/networking/3c509.txt @@ -126,7 +126,7 @@ packets faster than they can be removed from the card. This should be rare or impossible in normal operation. Possible causes of this error report are: - a "green" mode enabled that slows the processor down when there is no - keyboard activitiy. + keyboard activity. - some other device or device driver hogging the bus or disabling interrupts. Check /proc/interrupts for excessive interrupt counts. The timer tick diff --git a/Documentation/networking/NAPI_HOWTO.txt b/Documentation/networking/NAPI_HOWTO.txt index 54376e8249c1..93af3e87c65b 100644 --- a/Documentation/networking/NAPI_HOWTO.txt +++ b/Documentation/networking/NAPI_HOWTO.txt @@ -35,7 +35,7 @@ Legend: packets out of the rx ring. Note from this that the lower the load the more we could clean up the rxring "Ndone" == is the converse of "Done". Note again, that the higher -the load the more times we couldnt clean up the rxring. +the load the more times we couldn't clean up the rxring. Observe that: when the NIC receives 890Kpackets/sec only 17 rx interrupts are generated. diff --git a/Documentation/networking/arcnet-hardware.txt b/Documentation/networking/arcnet-hardware.txt index 30a5f01403d3..731de411513c 100644 --- a/Documentation/networking/arcnet-hardware.txt +++ b/Documentation/networking/arcnet-hardware.txt @@ -139,7 +139,7 @@ And now to the cabling. What you can connect together: 5. An active hub to passive hub. -Remember, that you can not connect two passive hubs together. The power loss +Remember that you cannot connect two passive hubs together. The power loss implied by such a connection is too high for the net to operate reliably. An example of a typical ARCnet network: diff --git a/Documentation/networking/bonding.txt b/Documentation/networking/bonding.txt index afac780445cd..de809e58092f 100644 --- a/Documentation/networking/bonding.txt +++ b/Documentation/networking/bonding.txt @@ -192,6 +192,17 @@ or, for backwards compatibility, the option value. E.g., arp_interval Specifies the ARP link monitoring frequency in milliseconds. + + The ARP monitor works by periodically checking the slave + devices to determine whether they have sent or received + traffic recently (the precise criteria depends upon the + bonding mode, and the state of the slave). Regular traffic is + generated via ARP probes issued for the addresses specified by + the arp_ip_target option. + + This behavior can be modified by the arp_validate option, + below. + If ARP monitoring is used in an etherchannel compatible mode (modes 0 and 2), the switch should be configured in a mode that evenly distributes packets across all links. If the @@ -213,6 +224,54 @@ arp_ip_target maximum number of targets that can be specified is 16. The default value is no IP addresses. +arp_validate + + Specifies whether or not ARP probes and replies should be + validated in the active-backup mode. This causes the ARP + monitor to examine the incoming ARP requests and replies, and + only consider a slave to be up if it is receiving the + appropriate ARP traffic. + + Possible values are: + + none or 0 + + No validation is performed. This is the default. + + active or 1 + + Validation is performed only for the active slave. + + backup or 2 + + Validation is performed only for backup slaves. + + all or 3 + + Validation is performed for all slaves. + + For the active slave, the validation checks ARP replies to + confirm that they were generated by an arp_ip_target. Since + backup slaves do not typically receive these replies, the + validation performed for backup slaves is on the ARP request + sent out via the active slave. It is possible that some + switch or network configurations may result in situations + wherein the backup slaves do not receive the ARP requests; in + such a situation, validation of backup slaves must be + disabled. + + This option is useful in network configurations in which + multiple bonding hosts are concurrently issuing ARPs to one or + more targets beyond a common switch. Should the link between + the switch and target fail (but not the switch itself), the + probe traffic generated by the multiple bonding instances will + fool the standard ARP monitor into considering the links as + still up. Use of the arp_validate option can resolve this, as + the ARP monitor will only consider ARP requests and replies + associated with its own instance of bonding. + + This option was added in bonding version 3.1.0. + downdelay Specifies the time, in milliseconds, to wait before disabling @@ -964,7 +1023,7 @@ Changing a Bond's Configuration files located in /sys/class/net/<bond name>/bonding The names of these files correspond directly with the command- -line parameters described elsewhere in in this file, and, with the +line parameters described elsewhere in this file, and, with the exception of arp_ip_target, they accept the same values. To see the current setting, simply cat the appropriate file. diff --git a/Documentation/networking/cs89x0.txt b/Documentation/networking/cs89x0.txt index 188beb7d6a17..64896470e279 100644 --- a/Documentation/networking/cs89x0.txt +++ b/Documentation/networking/cs89x0.txt @@ -227,7 +227,7 @@ configuration options are available on the command line: * media=rj45 - specify media type or media=bnc or media=aui - or medai=auto + or media=auto * duplex=full - specify forced half/full/autonegotiate duplex or duplex=half or duplex=auto @@ -584,7 +584,7 @@ of four ways after installing and or configuring the CS8900/20-based adapter: 1.) The system does not boot properly (or at all). - 2.) The driver can not communicate with the adapter, reporting an "Adapter + 2.) The driver cannot communicate with the adapter, reporting an "Adapter not found" error message. 3.) You cannot connect to the network or the driver will not load. @@ -684,7 +684,7 @@ ethernet@crystal.cirrus.com) and request that you be registered for automatic software-update notification. Cirrus Logic maintains a web page at http://www.cirrus.com with the -the latest drivers and technical publications. +latest drivers and technical publications. 6.4 Current maintainer diff --git a/Documentation/networking/cxgb.txt b/Documentation/networking/cxgb.txt index 76324638626b..20a887615c4a 100644 --- a/Documentation/networking/cxgb.txt +++ b/Documentation/networking/cxgb.txt @@ -56,7 +56,7 @@ FEATURES ethtool -C eth0 rx-usecs 100 - You may also provide a timer latency value while disabling adpative-rx: + You may also provide a timer latency value while disabling adaptive-rx: ethtool -C <interface> adaptive-rx off rx-usecs <microseconds> @@ -172,7 +172,7 @@ PERFORMANCE smaller window prevents congestion and facilitates better pacing, especially if/when MAC level flow control does not work well or when it is not supported on the machine. Experimentation may be necessary to attain - the correct value. This method is provided as a starting point fot the + the correct value. This method is provided as a starting point for the correct receive buffer size. Setting the min, max, and default receive buffer (RX_WINDOW) size is performed in the same manner as single connection. diff --git a/Documentation/networking/decnet.txt b/Documentation/networking/decnet.txt index e6c39c5831f5..badb7480ea62 100644 --- a/Documentation/networking/decnet.txt +++ b/Documentation/networking/decnet.txt @@ -82,7 +82,7 @@ ethernet address of your ethernet card has to be set according to the DECnet address of the node in order for it to be autoconfigured (and then appear in /proc/net/decnet_dev). There is a utility available at the above FTP sites called dn2ethaddr which can compute the correct ethernet -address to use. The address can be set by ifconfig either before at +address to use. The address can be set by ifconfig either before or at the time the device is brought up. If you are using RedHat you can add the line: diff --git a/Documentation/networking/dl2k.txt b/Documentation/networking/dl2k.txt index d460492037ef..10e8490fa406 100644 --- a/Documentation/networking/dl2k.txt +++ b/Documentation/networking/dl2k.txt @@ -173,7 +173,7 @@ Installing the Driver Parameter Description ===================== -You can install this driver without any addtional parameter. However, if you +You can install this driver without any additional parameter. However, if you are going to have extensive functions then it is necessary to set extra parameter. Below is a list of the command line parameters supported by the Linux device @@ -222,7 +222,7 @@ rx_timeout=n - Rx DMA wait time for an interrupt. reach timeout of n * 640 nano seconds. Set proper rx_coalesce and rx_timeout can reduce congestion collapse and overload which - has been a bottlenect for high speed network. + has been a bottleneck for high speed network. For example, rx_coalesce=10 rx_timeout=800. that is, hardware assert only 1 interrupt diff --git a/Documentation/networking/dmfe.txt b/Documentation/networking/dmfe.txt index 046363552d09..b1b7499dd9d3 100644 --- a/Documentation/networking/dmfe.txt +++ b/Documentation/networking/dmfe.txt @@ -34,7 +34,7 @@ Next you should configure your network interface with a command similar to : ifconfig eth0 172.22.3.18 ^^^^^^^^^^^ - Your IP Adress + Your IP Address Then you may have to modify the default routing table with command : diff --git a/Documentation/networking/driver.txt b/Documentation/networking/driver.txt index a9ad58b49cc5..4f7da5a2bf4f 100644 --- a/Documentation/networking/driver.txt +++ b/Documentation/networking/driver.txt @@ -37,7 +37,7 @@ Transmit path guidelines: ... } - And then at the end of your TX reclaimation event handling: + And then at the end of your TX reclamation event handling: if (netif_queue_stopped(dp->dev) && TX_BUFFS_AVAIL(dp) > (MAX_SKB_FRAGS + 1)) diff --git a/Documentation/networking/e1000.txt b/Documentation/networking/e1000.txt index 71fe15af356c..5c0a5cc03998 100644 --- a/Documentation/networking/e1000.txt +++ b/Documentation/networking/e1000.txt @@ -350,7 +350,7 @@ Additional Configurations As an example, if you install the e1000 driver for two PRO/1000 adapters (eth0 and eth1) and set the speed and duplex to 10full and 100half, add - the following to modules.conf or or modprobe.conf: + the following to modules.conf or modprobe.conf: alias eth0 e1000 alias eth1 e1000 diff --git a/Documentation/networking/fib_trie.txt b/Documentation/networking/fib_trie.txt index f50d0c673c57..0723db7f8495 100644 --- a/Documentation/networking/fib_trie.txt +++ b/Documentation/networking/fib_trie.txt @@ -79,7 +79,7 @@ trie_rebalance() resize() Analyzes a tnode and optimizes the child array size by either inflating - or shrinking it repeatedly until it fullfills the criteria for optimal + or shrinking it repeatedly until it fulfills the criteria for optimal level compression. This part follows the original paper pretty closely and there may be some room for experimentation here. diff --git a/Documentation/networking/gen_stats.txt b/Documentation/networking/gen_stats.txt index c3297f79c137..70e6275b757a 100644 --- a/Documentation/networking/gen_stats.txt +++ b/Documentation/networking/gen_stats.txt @@ -79,8 +79,8 @@ Rate Estimator: 0) Prepare an estimator attribute. Most likely this would be in user space. The value of this TLV should contain a tc_estimator structure. - As usual, such a TLV nees to be 32 bit aligned and therefore the - length needs to be appropriately set etc. The estimator interval + As usual, such a TLV needs to be 32 bit aligned and therefore the + length needs to be appropriately set, etc. The estimator interval and ewma log need to be converted to the appropriate values. tc_estimator.c::tc_setup_estimator() is advisable to be used as the conversion routine. It does a few clever things. It takes a time @@ -103,8 +103,8 @@ In the kernel when setting up: else failed -From now on, everytime you dump my_rate_est_stats it will contain -uptodate info. +From now on, every time you dump my_rate_est_stats it will contain +up-to-date info. Once you are done, call gen_kill_estimator(my_basicstats, my_rate_est_stats) Make sure that my_basicstats and my_rate_est_stats diff --git a/Documentation/networking/ip-sysctl.txt b/Documentation/networking/ip-sysctl.txt index 935e298f674a..fd3c0c012351 100644 --- a/Documentation/networking/ip-sysctl.txt +++ b/Documentation/networking/ip-sysctl.txt @@ -495,7 +495,7 @@ icmp_errors_use_inbound_ifaddr - BOOLEAN Note that if no primary address exists for the interface selected, then the primary address of the first non-loopback interface that - has one will be used regarldess of this setting. + has one will be used regardless of this setting. Default: 0 @@ -787,7 +787,7 @@ accept_ra_defrtr - BOOLEAN disabled if accept_ra is disabled. accept_ra_pinfo - BOOLEAN - Learn Prefix Inforamtion in Router Advertisement. + Learn Prefix Information in Router Advertisement. Functional default: enabled if accept_ra is enabled. disabled if accept_ra is disabled. diff --git a/Documentation/networking/netconsole.txt b/Documentation/networking/netconsole.txt index 53618fb1a717..1caa6c734691 100644 --- a/Documentation/networking/netconsole.txt +++ b/Documentation/networking/netconsole.txt @@ -52,6 +52,6 @@ messages is high, but should have no other impact. Netconsole was designed to be as instantaneous as possible, to enable the logging of even the most critical kernel bugs. It works from IRQ contexts as well, and does not enable interrupts while -sending packets. Due to these unique needs, configuration can not +sending packets. Due to these unique needs, configuration cannot be more automatic, and some fundamental limitations will remain: only IP networks, UDP packets and ethernet devices are supported. diff --git a/Documentation/networking/netif-msg.txt b/Documentation/networking/netif-msg.txt index 18ad4cea6259..c967ddb90d0b 100644 --- a/Documentation/networking/netif-msg.txt +++ b/Documentation/networking/netif-msg.txt @@ -40,7 +40,7 @@ History Per-interface rather than per-driver message level setting. More selective control over the type of messages emitted. - The netif_msg recommandation adds these features with only a minor + The netif_msg recommendation adds these features with only a minor complexity and code size increase. The recommendation is the following points diff --git a/Documentation/networking/operstates.txt b/Documentation/networking/operstates.txt index 4a21d9bb836b..c9074f9b78bb 100644 --- a/Documentation/networking/operstates.txt +++ b/Documentation/networking/operstates.txt @@ -2,7 +2,7 @@ 1. Introduction Linux distinguishes between administrative and operational state of an -interface. Admininstrative state is the result of "ip link set dev +interface. Administrative state is the result of "ip link set dev <dev> up or down" and reflects whether the administrator wants to use the device for traffic. diff --git a/Documentation/networking/packet_mmap.txt b/Documentation/networking/packet_mmap.txt index aaf99d5f0dad..12a008a5c221 100644 --- a/Documentation/networking/packet_mmap.txt +++ b/Documentation/networking/packet_mmap.txt @@ -66,7 +66,7 @@ the following process: [setup] socket() -------> creation of the capture socket setsockopt() ---> allocation of the circular buffer (ring) - mmap() ---------> maping of the allocated buffer to the + mmap() ---------> mapping of the allocated buffer to the user process [capture] poll() ---------> to wait for incoming packets @@ -93,7 +93,7 @@ The destruction of the socket and all associated resources is done by a simple call to close(fd). Next I will describe PACKET_MMAP settings and it's constraints, -also the maping of the circular buffer in the user process and +also the mapping of the circular buffer in the user process and the use of this buffer. -------------------------------------------------------------------------------- @@ -153,8 +153,8 @@ we will get the following buffer structure: A frame can be of any size with the only condition it can fit in a block. A block can only hold an integer number of frames, or in other words, a frame cannot -be spawn accross two blocks so there are some datails you have to take into -account when choosing the frame_size. See "Maping and use of the circular +be spawned accross two blocks, so there are some details you have to take into +account when choosing the frame_size. See "Mapping and use of the circular buffer (ring)". @@ -215,8 +215,8 @@ called pg_vec, its size limits the number of blocks that can be allocated. block #1 -kmalloc allocates any number of bytes of phisically contiguous memory from -a pool of pre-determined sizes. This pool of memory is mantained by the slab +kmalloc allocates any number of bytes of physically contiguous memory from +a pool of pre-determined sizes. This pool of memory is maintained by the slab allocator which is at the end the responsible for doing the allocation and hence which imposes the maximum memory that kmalloc can allocate. @@ -262,7 +262,7 @@ i386 architecture: <pagesize> = 4096 bytes <max-order> = 11 -and a value for <frame size> of 2048 byteas. These parameters will yield +and a value for <frame size> of 2048 bytes. These parameters will yield <block number> = 131072/4 = 32768 blocks <block size> = 4096 << 11 = 8 MiB. @@ -278,7 +278,7 @@ an i386 kernel's memory size is limited to 1GiB. All memory allocations are not freed until the socket is closed. The memory allocations are done with GFP_KERNEL priority, this basically means that the allocation can wait and swap other process' memory in order to allocate -the nececessary memory, so normally limits can be reached. +the necessary memory, so normally limits can be reached. Other constraints ------------------- @@ -296,7 +296,7 @@ the following (from include/linux/if_packet.h): - struct tpacket_hdr - pad to TPACKET_ALIGNMENT=16 - struct sockaddr_ll - - Gap, chosen so that packet data (Start+tp_net) alignes to + - Gap, chosen so that packet data (Start+tp_net) aligns to TPACKET_ALIGNMENT=16 - Start+tp_mac: [ Optional MAC header ] - Start+tp_net: Packet data, aligned to TPACKET_ALIGNMENT=16. @@ -311,14 +311,14 @@ the following (from include/linux/if_packet.h): tp_frame_size must be a multiple of TPACKET_ALIGNMENT tp_frame_nr must be exactly frames_per_block*tp_block_nr -Note that tp_block_size should be choosed to be a power of two or there will +Note that tp_block_size should be chosen to be a power of two or there will be a waste of memory. -------------------------------------------------------------------------------- -+ Maping and use of the circular buffer (ring) ++ Mapping and use of the circular buffer (ring) -------------------------------------------------------------------------------- -The maping of the buffer in the user process is done with the conventional +The mapping of the buffer in the user process is done with the conventional mmap function. Even the circular buffer is compound of several physically discontiguous blocks of memory, they are contiguous to the user space, hence just one call to mmap is needed: diff --git a/Documentation/networking/pktgen.txt b/Documentation/networking/pktgen.txt index 44f2f769e865..c8eee23be8c0 100644 --- a/Documentation/networking/pktgen.txt +++ b/Documentation/networking/pktgen.txt @@ -7,7 +7,7 @@ Date: 041221 Enable CONFIG_NET_PKTGEN to compile and build pktgen.o either in kernel or as module. Module is preferred. insmod pktgen if needed. Once running -pktgen creates a thread on each CPU where each thread has affinty it's CPU. +pktgen creates a thread on each CPU where each thread has affinity to its CPU. Monitoring and controlling is done via /proc. Easiest to select a suitable a sample script and configure. @@ -18,7 +18,7 @@ root 129 0.3 0.0 0 0 ? SW 2003 523:20 [pktgen/0] root 130 0.3 0.0 0 0 ? SW 2003 509:50 [pktgen/1] -For montoring and control pktgen creates: +For monitoring and control pktgen creates: /proc/net/pktgen/pgctrl /proc/net/pktgen/kpktgend_X /proc/net/pktgen/ethX @@ -32,7 +32,7 @@ Running: Stopped: eth1 Result: OK: max_before_softirq=10000 -Most important the devices assigend to thread. Note! A device can only belong +Most important the devices assigned to thread. Note! A device can only belong to one thread. @@ -100,6 +100,7 @@ Examples: are: IPSRC_RND #IP Source is random (between min/max), IPDST_RND, UDPSRC_RND, UDPDST_RND, MACSRC_RND, MACDST_RND + MPLS_RND, VID_RND, SVID_RND pgset "udp_src_min 9" set UDP source port min, If < udp_src_max, then cycle through the port range. @@ -125,13 +126,28 @@ Examples: pgset "mpls 0" turn off mpls (or any invalid argument works too!) + pgset "vlan_id 77" set VLAN ID 0-4095 + pgset "vlan_p 3" set priority bit 0-7 (default 0) + pgset "vlan_cfi 0" set canonical format identifier 0-1 (default 0) + + pgset "svlan_id 22" set SVLAN ID 0-4095 + pgset "svlan_p 3" set priority bit 0-7 (default 0) + pgset "svlan_cfi 0" set canonical format identifier 0-1 (default 0) + + pgset "vlan_id 9999" > 4095 remove vlan and svlan tags + pgset "svlan 9999" > 4095 remove svlan tag + + + pgset "tos XX" set former IPv4 TOS field (e.g. "tos 28" for AF11 no ECN, default 00) + pgset "traffic_class XX" set former IPv6 TRAFFIC CLASS (e.g. "traffic_class B8" for EF no ECN, default 00) + pgset stop aborts injection. Also, ^C aborts generator. Example scripts =============== -A collection of small tutorial scripts for pktgen is in expamples dir. +A collection of small tutorial scripts for pktgen is in examples dir. pktgen.conf-1-1 # 1 CPU 1 dev pktgen.conf-1-2 # 1 CPU 2 dev diff --git a/Documentation/networking/s2io.txt b/Documentation/networking/s2io.txt index bd528ffbeb4b..4bde53e85f3f 100644 --- a/Documentation/networking/s2io.txt +++ b/Documentation/networking/s2io.txt @@ -126,7 +126,7 @@ However, you may want to set PCI latency timer to 248. #setpci -d 17d5:* LATENCY_TIMER=f8 For detailed description of the PCI registers, please see Xframe User Guide. b. Use 2-buffer mode. This results in large performance boost on -on certain platforms(eg. SGI Altix, IBM xSeries). +certain platforms(eg. SGI Altix, IBM xSeries). c. Ensure Receive Checksum offload is enabled. Use "ethtool -K ethX" command to set/verify this option. d. Enable NAPI feature(in kernel configuration Device Drivers ---> Network diff --git a/Documentation/networking/sk98lin.txt b/Documentation/networking/sk98lin.txt index 7837c53fd5fe..4e1cc745ec63 100644 --- a/Documentation/networking/sk98lin.txt +++ b/Documentation/networking/sk98lin.txt @@ -180,7 +180,7 @@ To set the driver parameters in this file, proceed as follows: 1. Insert a line of the form : options sk98lin ... For "...", the same syntax is required as described for the command - line paramaters of modprobe below. + line parameters of modprobe below. 2. To activate the new parameters, either reboot your computer or unload and reload the driver. @@ -320,7 +320,7 @@ Parameter: Moderation Values: None, Static, Dynamic Default: None -Interrupt moderation is employed to limit the maxmimum number of interrupts +Interrupt moderation is employed to limit the maximum number of interrupts the driver has to serve. That is, one or more interrupts (which indicate any transmit or receive packet to be processed) are queued until the driver processes them. When queued interrupts are to be served, is determined by the @@ -364,9 +364,9 @@ Parameter: IntsPerSec Values: 30...40000 (interrupts per second) Default: 2000 -This parameter is only used, if either static or dynamic interrupt moderation -is used on a network adapter card. Using this paramter if no moderation is -applied, will lead to no action performed. +This parameter is only used if either static or dynamic interrupt moderation +is used on a network adapter card. Using this parameter if no moderation is +applied will lead to no action performed. This parameter determines the length of any interrupt moderation interval. Assuming that static interrupt moderation is to be used, an 'IntsPerSec' @@ -484,7 +484,7 @@ If any problems occur during the installation process, check the following list: -Problem: The SK-98xx adapter can not be found by the driver. +Problem: The SK-98xx adapter cannot be found by the driver. Solution: In /proc/pci search for the following entry: 'Ethernet controller: SysKonnect SK-98xx ...' If this entry exists, the SK-98xx or SK-98xx V2.0 adapter has @@ -497,12 +497,12 @@ Solution: In /proc/pci search for the following entry: www.syskonnect.com Some COMPAQ machines have problems dealing with PCI under Linux. - Linux. This problem is described in the 'PCI howto' document + This problem is described in the 'PCI howto' document (included in some distributions or available from the web, e.g. at 'www.linux.org'). -Problem: Programs such as 'ifconfig' or 'route' can not be found or the +Problem: Programs such as 'ifconfig' or 'route' cannot be found or the error message 'Operation not permitted' is displayed. Reason: You are not logged in as user 'root'. Solution: Logout and login as 'root' or change to 'root' via 'su'. diff --git a/Documentation/networking/skfp.txt b/Documentation/networking/skfp.txt index 3a419ed42f81..abfddf81e34a 100644 --- a/Documentation/networking/skfp.txt +++ b/Documentation/networking/skfp.txt @@ -81,7 +81,7 @@ Makes my life much easier :-) If you run into problems during installation, check those items: -Problem: The FDDI adapter can not be found by the driver. +Problem: The FDDI adapter cannot be found by the driver. Reason: Look in /proc/pci for the following entry: 'FDDI network controller: SysKonnect SK-FDDI-PCI ...' If this entry exists, then the FDDI adapter has been @@ -99,7 +99,7 @@ Reason: Look in /proc/pci for the following entry: Problem: You want to use your computer as a router between multiple IP subnetworks (using multiple adapters), but - you can not reach computers in other subnetworks. + you cannot reach computers in other subnetworks. Reason: Either the router's kernel is not configured for IP forwarding or there is a problem with the routing table and gateway configuration in at least one of the diff --git a/Documentation/networking/slicecom.txt b/Documentation/networking/slicecom.txt index 59cfd95121fb..2f04c9267f89 100644 --- a/Documentation/networking/slicecom.txt +++ b/Documentation/networking/slicecom.txt @@ -89,7 +89,7 @@ red: green: meaning: - - no frame-sync, no signal received, or signal SNAFU. - on "Everything is OK" -on on Recepion is ok, but the remote end sends Remote Alarm +on on Reception is ok, but the remote end sends Remote Alarm on - The interface is unconfigured ----------------------------------------------------------------- @@ -257,12 +257,12 @@ which begin with '//' are the comments. // No alarms - Everything OK // // LOS - Loss Of Signal - No signal sensed on the input -// AIS - Alarm Indication Signal - The remot side sends '11111111'-s, +// AIS - Alarm Indication Signal - The remote side sends '11111111'-s, // it tells, that there's an error condition, or it's not // initialised. // AUXP - Auxiliary Pattern Indication - 01010101.. received. // LFA - Loss of Frame Alignment - no frame sync received. -// RRA - Receive Remote Alarm - the remote end's OK, but singnals error cond. +// RRA - Receive Remote Alarm - the remote end's OK, but signals error cond. // LMFA - Loss of CRC4 Multiframe Alignment - no CRC4 multiframe sync. // NMF - No Multiframe alignment Found after 400 msec - no such alarm using // no-crc4 or crc4 framing, see below. @@ -364,6 +364,6 @@ Treat them very carefully, these can cause much trouble! # echo >lbireg 0x1d 0x21 - - Swithing the loop off: + - Switching the loop off: # echo >lbireg 0x1d 0x00 diff --git a/Documentation/networking/smctr.txt b/Documentation/networking/smctr.txt index 4c866f5a0ee4..9af25b810c1f 100644 --- a/Documentation/networking/smctr.txt +++ b/Documentation/networking/smctr.txt @@ -11,7 +11,7 @@ This driver is rather simple to use. Select Y to Token Ring adapter support in the kernel configuration. A choice for SMC Token Ring adapters will appear. This drives supports all SMC ISA/MCA adapters. Choose this option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it staticly answer Y instead. +you would like to compile it statically answer Y instead. This driver supports multiple adapters without the need to load multiple copies of the driver. You should be able to load up to 7 adapters without any kernel diff --git a/Documentation/networking/tcp.txt b/Documentation/networking/tcp.txt index 0fa300425575..0121edc3ba06 100644 --- a/Documentation/networking/tcp.txt +++ b/Documentation/networking/tcp.txt @@ -62,7 +62,7 @@ if needed and you will get the expected protocol. If you ask for an unknown congestion method, then the sysctl attempt will fail. If you remove a tcp congestion control module, then you will get the next -available one. Since reno can not be built as a module, and can not be +available one. Since reno cannot be built as a module, and cannot be deleted, it will always be available. How the new TCP output machine [nyi] works. diff --git a/Documentation/networking/tms380tr.txt b/Documentation/networking/tms380tr.txt index 179e527b9da1..c169a57bc925 100644 --- a/Documentation/networking/tms380tr.txt +++ b/Documentation/networking/tms380tr.txt @@ -24,7 +24,7 @@ This driver is rather simple to use. Select Y to Token Ring adapter support in the kernel configuration. A choice for SysKonnect Token Ring adapters will appear. This drives supports all SysKonnect ISA and PCI adapters. Choose this option. I personally recommend compiling the driver as a module (M), but if you -you would like to compile it staticly answer Y instead. +you would like to compile it statically answer Y instead. This driver supports multiple adapters without the need to load multiple copies of the driver. You should be able to load up to 7 adapters without any kernel diff --git a/Documentation/networking/vortex.txt b/Documentation/networking/vortex.txt index 6091e5f6794f..6356d3faed36 100644 --- a/Documentation/networking/vortex.txt +++ b/Documentation/networking/vortex.txt @@ -359,13 +359,13 @@ steps you should take: Eliminate some variables: try different cards, different computers, different cables, different ports on the switch/hub, - different versions of the kernel or ofthe driver, etc. + different versions of the kernel or of the driver, etc. - OK, it's a driver problem. You need to generate a report. Typically this is an email to the maintainer and/or linux-net@vger.kernel.org. The maintainer's - email address will be inthe driver source or in the MAINTAINERS file. + email address will be in the driver source or in the MAINTAINERS file. - The contents of your report will vary a lot depending upon the problem. If it's a kernel crash then you should refer to the diff --git a/Documentation/networking/wan-router.txt b/Documentation/networking/wan-router.txt index c96897aa08b6..0cf654147634 100644 --- a/Documentation/networking/wan-router.txt +++ b/Documentation/networking/wan-router.txt @@ -148,7 +148,7 @@ NEW IN THIS RELEASE for async connections. o Added the PPPCONFIG utility - Used to configure the PPPD dameon for the + Used to configure the PPPD daemon for the WANPIPE Async PPP and standard serial port. The wancfg calls the pppconfig to configure the pppd. @@ -214,7 +214,7 @@ PRODUCT COMPONENTS AND RELATED FILES /usr/local/wanrouter/patches/kdrivers: Sources of the latest WANPIPE device drivers. These are used to UPGRADE the linux kernel to the newest - version if the kernel source has already been pathced with + version if the kernel source has already been patched with WANPIPE drivers. /usr/local/wanrouter/samples: @@ -350,7 +350,7 @@ REVISION HISTORY Available as a patch. 2.0.6 Aug 17, 1999 Increased debugging in statup scripts - Fixed insallation bugs from 2.0.5 + Fixed installation bugs from 2.0.5 Kernel patch works for both 2.2.10 and 2.2.11 kernels. There is no functional difference between the two packages @@ -434,11 +434,11 @@ beta3-2.1.4 Jul 2000 o X25 M_BIT Problem fix. change. beta1-2.1.5 Nov 15 2000 - o Fixed the MulitPort PPP Support for kernels 2.2.16 and above. + o Fixed the MultiPort PPP Support for kernels 2.2.16 and above. 2.2.X kernels only o Secured the driver UDP debugging calls - - All illegal netowrk debugging calls are reported to + - All illegal network debugging calls are reported to the log. - Defined a set of allowed commands, all other denied. @@ -451,7 +451,7 @@ beta1-2.1.5 Nov 15 2000 o Keyboard Led Monitor/Debugger - A new utilty /usr/sbin/wpkbdmon uses keyboard leds - to convey operatinal statistic information of the + to convey operational statistic information of the Sangoma WANPIPE cards. NUM_LOCK = Line State (On=connected, Off=disconnected) CAPS_LOCK = Tx data (On=transmitting, Off=no tx data) @@ -470,7 +470,7 @@ beta1-2.1.5 Nov 15 2000 o Fixed the Frame Relay and Chdlc network interfaces so they are compatible with libpcap libraries. Meaning, tcpdump, snort, ethereal, and all other packet sniffers and debuggers work on - all WANPIPE netowrk interfaces. + all WANPIPE network interfaces. - Set the network interface encoding type to ARPHRD_PPP. This tell the sniffers that data obtained from the network interface is in pure IP format. @@ -570,7 +570,7 @@ bata1-2.2.1 Feb 09 2001 Option to COMPILE WANPIPE modules against the currently running kernel, thus no need for manual kernel and module - re-compilatin. + re-compilation. o Updates and Bug Fixes to wancfg utility. diff --git a/Documentation/nfsroot.txt b/Documentation/nfsroot.txt index 3cc953cb288f..719f9a9d60c0 100644 --- a/Documentation/nfsroot.txt +++ b/Documentation/nfsroot.txt @@ -11,7 +11,7 @@ Updated 2006 by Horms <horms@verge.net.au> In order to use a diskless system, such as an X-terminal or printer server for example, it is necessary for the root filesystem to be present on a non-disk device. This may be an initramfs (see Documentation/filesystems/ -ramfs-rootfs-initramfs.txt), a ramdisk (see Documenation/initrd.txt) or a +ramfs-rootfs-initramfs.txt), a ramdisk (see Documentation/initrd.txt) or a filesystem mounted via NFS. The following text describes on how to use NFS for the root filesystem. For the rest of this text 'client' means the diskless system, and 'server' means the NFS server. diff --git a/Documentation/nommu-mmap.txt b/Documentation/nommu-mmap.txt index b88ebe4d808c..7714f57caad5 100644 --- a/Documentation/nommu-mmap.txt +++ b/Documentation/nommu-mmap.txt @@ -116,6 +116,9 @@ FURTHER NOTES ON NO-MMU MMAP (*) A list of all the mappings on the system is visible through /proc/maps in no-MMU mode. + (*) A list of all the mappings in use by a process is visible through + /proc/<pid>/maps in no-MMU mode. + (*) Supplying MAP_FIXED or a requesting a particular mapping address will result in an error. @@ -125,6 +128,49 @@ FURTHER NOTES ON NO-MMU MMAP error will result if they don't. This is most likely to be encountered with character device files, pipes, fifos and sockets. + +========================== +INTERPROCESS SHARED MEMORY +========================== + +Both SYSV IPC SHM shared memory and POSIX shared memory is supported in NOMMU +mode. The former through the usual mechanism, the latter through files created +on ramfs or tmpfs mounts. + + +======= +FUTEXES +======= + +Futexes are supported in NOMMU mode if the arch supports them. An error will +be given if an address passed to the futex system call lies outside the +mappings made by a process or if the mapping in which the address lies does not +support futexes (such as an I/O chardev mapping). + + +============= +NO-MMU MREMAP +============= + +The mremap() function is partially supported. It may change the size of a +mapping, and may move it[*] if MREMAP_MAYMOVE is specified and if the new size +of the mapping exceeds the size of the slab object currently occupied by the +memory to which the mapping refers, or if a smaller slab object could be used. + +MREMAP_FIXED is not supported, though it is ignored if there's no change of +address and the object does not need to be moved. + +Shared mappings may not be moved. Shareable mappings may not be moved either, +even if they are not currently shared. + +The mremap() function must be given an exact match for base address and size of +a previously mapped object. It may not be used to create holes in existing +mappings, move parts of existing mappings or resize parts of mappings. It must +act on a complete mapping. + +[*] Not currently supported. + + ============================================ PROVIDING SHAREABLE CHARACTER DEVICE SUPPORT ============================================ diff --git a/Documentation/pci-error-recovery.txt b/Documentation/pci-error-recovery.txt index 634d3e5b5756..6650af432523 100644 --- a/Documentation/pci-error-recovery.txt +++ b/Documentation/pci-error-recovery.txt @@ -172,7 +172,7 @@ is STEP 6 (Permanent Failure). >>> a value of 0xff on read, and writes will be dropped. If the device >>> driver attempts more than 10K I/O's to a frozen adapter, it will >>> assume that the device driver has gone into an infinite loop, and ->>> it will panic the the kernel. There doesn't seem to be any other +>>> it will panic the kernel. There doesn't seem to be any other >>> way of stopping a device driver that insists on spinning on I/O. STEP 2: MMIO Enabled diff --git a/Documentation/pcieaer-howto.txt b/Documentation/pcieaer-howto.txt new file mode 100644 index 000000000000..16c251230c82 --- /dev/null +++ b/Documentation/pcieaer-howto.txt @@ -0,0 +1,253 @@ + The PCI Express Advanced Error Reporting Driver Guide HOWTO + T. Long Nguyen <tom.l.nguyen@intel.com> + Yanmin Zhang <yanmin.zhang@intel.com> + 07/29/2006 + + +1. Overview + +1.1 About this guide + +This guide describes the basics of the PCI Express Advanced Error +Reporting (AER) driver and provides information on how to use it, as +well as how to enable the drivers of endpoint devices to conform with +PCI Express AER driver. + +1.2 Copyright © Intel Corporation 2006. + +1.3 What is the PCI Express AER Driver? + +PCI Express error signaling can occur on the PCI Express link itself +or on behalf of transactions initiated on the link. PCI Express +defines two error reporting paradigms: the baseline capability and +the Advanced Error Reporting capability. The baseline capability is +required of all PCI Express components providing a minimum defined +set of error reporting requirements. Advanced Error Reporting +capability is implemented with a PCI Express advanced error reporting +extended capability structure providing more robust error reporting. + +The PCI Express AER driver provides the infrastructure to support PCI +Express Advanced Error Reporting capability. The PCI Express AER +driver provides three basic functions: + +- Gathers the comprehensive error information if errors occurred. +- Reports error to the users. +- Performs error recovery actions. + +AER driver only attaches root ports which support PCI-Express AER +capability. + + +2. User Guide + +2.1 Include the PCI Express AER Root Driver into the Linux Kernel + +The PCI Express AER Root driver is a Root Port service driver attached +to the PCI Express Port Bus driver. If a user wants to use it, the driver +has to be compiled. Option CONFIG_PCIEAER supports this capability. It +depends on CONFIG_PCIEPORTBUS, so pls. set CONFIG_PCIEPORTBUS=y and +CONFIG_PCIEAER = y. + +2.2 Load PCI Express AER Root Driver +There is a case where a system has AER support in BIOS. Enabling the AER +Root driver and having AER support in BIOS may result unpredictable +behavior. To avoid this conflict, a successful load of the AER Root driver +requires ACPI _OSC support in the BIOS to allow the AER Root driver to +request for native control of AER. See the PCI FW 3.0 Specification for +details regarding OSC usage. Currently, lots of firmwares don't provide +_OSC support while they use PCI Express. To support such firmwares, +forceload, a parameter of type bool, could enable AER to continue to +be initiated although firmwares have no _OSC support. To enable the +walkaround, pls. add aerdriver.forceload=y to kernel boot parameter line +when booting kernel. Note that forceload=n by default. + +2.3 AER error output +When a PCI-E AER error is captured, an error message will be outputed to +console. If it's a correctable error, it is outputed as a warning. +Otherwise, it is printed as an error. So users could choose different +log level to filter out correctable error messages. + +Below shows an example. ++------ PCI-Express Device Error -----+ +Error Severity : Uncorrected (Fatal) +PCIE Bus Error type : Transaction Layer +Unsupported Request : First +Requester ID : 0500 +VendorID=8086h, DeviceID=0329h, Bus=05h, Device=00h, Function=00h +TLB Header: +04000001 00200a03 05010000 00050100 + +In the example, 'Requester ID' means the ID of the device who sends +the error message to root port. Pls. refer to pci express specs for +other fields. + + +3. Developer Guide + +To enable AER aware support requires a software driver to configure +the AER capability structure within its device and to provide callbacks. + +To support AER better, developers need understand how AER does work +firstly. + +PCI Express errors are classified into two types: correctable errors +and uncorrectable errors. This classification is based on the impacts +of those errors, which may result in degraded performance or function +failure. + +Correctable errors pose no impacts on the functionality of the +interface. The PCI Express protocol can recover without any software +intervention or any loss of data. These errors are detected and +corrected by hardware. Unlike correctable errors, uncorrectable +errors impact functionality of the interface. Uncorrectable errors +can cause a particular transaction or a particular PCI Express link +to be unreliable. Depending on those error conditions, uncorrectable +errors are further classified into non-fatal errors and fatal errors. +Non-fatal errors cause the particular transaction to be unreliable, +but the PCI Express link itself is fully functional. Fatal errors, on +the other hand, cause the link to be unreliable. + +When AER is enabled, a PCI Express device will automatically send an +error message to the PCIE root port above it when the device captures +an error. The Root Port, upon receiving an error reporting message, +internally processes and logs the error message in its PCI Express +capability structure. Error information being logged includes storing +the error reporting agent's requestor ID into the Error Source +Identification Registers and setting the error bits of the Root Error +Status Register accordingly. If AER error reporting is enabled in Root +Error Command Register, the Root Port generates an interrupt if an +error is detected. + +Note that the errors as described above are related to the PCI Express +hierarchy and links. These errors do not include any device specific +errors because device specific errors will still get sent directly to +the device driver. + +3.1 Configure the AER capability structure + +AER aware drivers of PCI Express component need change the device +control registers to enable AER. They also could change AER registers, +including mask and severity registers. Helper function +pci_enable_pcie_error_reporting could be used to enable AER. See +section 3.3. + +3.2. Provide callbacks + +3.2.1 callback reset_link to reset pci express link + +This callback is used to reset the pci express physical link when a +fatal error happens. The root port aer service driver provides a +default reset_link function, but different upstream ports might +have different specifications to reset pci express link, so all +upstream ports should provide their own reset_link functions. + +In struct pcie_port_service_driver, a new pointer, reset_link, is +added. + +pci_ers_result_t (*reset_link) (struct pci_dev *dev); + +Section 3.2.2.2 provides more detailed info on when to call +reset_link. + +3.2.2 PCI error-recovery callbacks + +The PCI Express AER Root driver uses error callbacks to coordinate +with downstream device drivers associated with a hierarchy in question +when performing error recovery actions. + +Data struct pci_driver has a pointer, err_handler, to point to +pci_error_handlers who consists of a couple of callback function +pointers. AER driver follows the rules defined in +pci-error-recovery.txt except pci express specific parts (e.g. +reset_link). Pls. refer to pci-error-recovery.txt for detailed +definitions of the callbacks. + +Below sections specify when to call the error callback functions. + +3.2.2.1 Correctable errors + +Correctable errors pose no impacts on the functionality of +the interface. The PCI Express protocol can recover without any +software intervention or any loss of data. These errors do not +require any recovery actions. The AER driver clears the device's +correctable error status register accordingly and logs these errors. + +3.2.2.2 Non-correctable (non-fatal and fatal) errors + +If an error message indicates a non-fatal error, performing link reset +at upstream is not required. The AER driver calls error_detected(dev, +pci_channel_io_normal) to all drivers associated within a hierarchy in +question. for example, +EndPoint<==>DownstreamPort B<==>UpstreamPort A<==>RootPort. +If Upstream port A captures an AER error, the hierarchy consists of +Downstream port B and EndPoint. + +A driver may return PCI_ERS_RESULT_CAN_RECOVER, +PCI_ERS_RESULT_DISCONNECT, or PCI_ERS_RESULT_NEED_RESET, depending on +whether it can recover or the AER driver calls mmio_enabled as next. + +If an error message indicates a fatal error, kernel will broadcast +error_detected(dev, pci_channel_io_frozen) to all drivers within +a hierarchy in question. Then, performing link reset at upstream is +necessary. As different kinds of devices might use different approaches +to reset link, AER port service driver is required to provide the +function to reset link. Firstly, kernel looks for if the upstream +component has an aer driver. If it has, kernel uses the reset_link +callback of the aer driver. If the upstream component has no aer driver +and the port is downstream port, we will use the aer driver of the +root port who reports the AER error. As for upstream ports, +they should provide their own aer service drivers with reset_link +function. If error_detected returns PCI_ERS_RESULT_CAN_RECOVER and +reset_link returns PCI_ERS_RESULT_RECOVERED, the error handling goes +to mmio_enabled. + +3.3 helper functions + +3.3.1 int pci_find_aer_capability(struct pci_dev *dev); +pci_find_aer_capability locates the PCI Express AER capability +in the device configuration space. If the device doesn't support +PCI-Express AER, the function returns 0. + +3.3.2 int pci_enable_pcie_error_reporting(struct pci_dev *dev); +pci_enable_pcie_error_reporting enables the device to send error +messages to root port when an error is detected. Note that devices +don't enable the error reporting by default, so device drivers need +call this function to enable it. + +3.3.3 int pci_disable_pcie_error_reporting(struct pci_dev *dev); +pci_disable_pcie_error_reporting disables the device to send error +messages to root port when an error is detected. + +3.3.4 int pci_cleanup_aer_uncorrect_error_status(struct pci_dev *dev); +pci_cleanup_aer_uncorrect_error_status cleanups the uncorrectable +error status register. + +3.4 Frequent Asked Questions + +Q: What happens if a PCI Express device driver does not provide an +error recovery handler (pci_driver->err_handler is equal to NULL)? + +A: The devices attached with the driver won't be recovered. If the +error is fatal, kernel will print out warning messages. Please refer +to section 3 for more information. + +Q: What happens if an upstream port service driver does not provide +callback reset_link? + +A: Fatal error recovery will fail if the errors are reported by the +upstream ports who are attached by the service driver. + +Q: How does this infrastructure deal with driver that is not PCI +Express aware? + +A: This infrastructure calls the error callback functions of the +driver when an error happens. But if the driver is not aware of +PCI Express, the device might not report its own errors to root +port. + +Q: What modifications will that driver need to make it compatible +with the PCI Express AER Root driver? + +A: It could call the helper functions to enable AER in devices and +cleanup uncorrectable status register. Pls. refer to section 3.3. + diff --git a/Documentation/pi-futex.txt b/Documentation/pi-futex.txt index 5d61dacd21f6..9a5bc8651c29 100644 --- a/Documentation/pi-futex.txt +++ b/Documentation/pi-futex.txt @@ -118,4 +118,4 @@ properties of futexes, and all four combinations are possible: futex, robust-futex, PI-futex, robust+PI-futex. More details about priority inheritance can be found in -Documentation/rtmutex.txt. +Documentation/rt-mutex.txt. diff --git a/Documentation/pm.txt b/Documentation/pm.txt index 79c0f32a760e..da8589a0e07d 100644 --- a/Documentation/pm.txt +++ b/Documentation/pm.txt @@ -18,10 +18,10 @@ enabled by default). If a working ACPI implementation is found, the ACPI driver will override and disable APM, otherwise the APM driver will be used. -No sorry, you can not have both ACPI and APM enabled and running at +No, sorry, you cannot have both ACPI and APM enabled and running at once. Some people with broken ACPI or broken APM implementations would like to use both to get a full set of working features, but you -simply can not mix and match the two. Only one power management +simply cannot mix and match the two. Only one power management interface can be in control of the machine at once. Think about it.. User-space Daemons @@ -106,7 +106,7 @@ void pm_unregister_all(pm_callback cback); * * Returns: 0 if the request is successful * EINVAL if the request is not supported - * EBUSY if the device is now busy and can not handle the request + * EBUSY if the device is now busy and cannot handle the request * ENOMEM if the device was unable to handle the request due to memory * * Details: The device request callback will be called before the diff --git a/Documentation/pnp.txt b/Documentation/pnp.txt index 9529c9c9fd59..9ff966bf76e6 100644 --- a/Documentation/pnp.txt +++ b/Documentation/pnp.txt @@ -222,7 +222,7 @@ static struct pnp_driver serial_pnp_driver = { .remove = serial_pnp_remove, }; -* name and id_table can not be NULL. +* name and id_table cannot be NULL. 4.) register the driver ex: diff --git a/Documentation/power/devices.txt b/Documentation/power/devices.txt index fba1e05c47c7..d0e79d5820a5 100644 --- a/Documentation/power/devices.txt +++ b/Documentation/power/devices.txt @@ -1,208 +1,553 @@ +Most of the code in Linux is device drivers, so most of the Linux power +management code is also driver-specific. Most drivers will do very little; +others, especially for platforms with small batteries (like cell phones), +will do a lot. + +This writeup gives an overview of how drivers interact with system-wide +power management goals, emphasizing the models and interfaces that are +shared by everything that hooks up to the driver model core. Read it as +background for the domain-specific work you'd do with any specific driver. + + +Two Models for Device Power Management +====================================== +Drivers will use one or both of these models to put devices into low-power +states: + + System Sleep model: + Drivers can enter low power states as part of entering system-wide + low-power states like "suspend-to-ram", or (mostly for systems with + disks) "hibernate" (suspend-to-disk). + + This is something that device, bus, and class drivers collaborate on + by implementing various role-specific suspend and resume methods to + cleanly power down hardware and software subsystems, then reactivate + them without loss of data. + + Some drivers can manage hardware wakeup events, which make the system + leave that low-power state. This feature may be disabled using the + relevant /sys/devices/.../power/wakeup file; enabling it may cost some + power usage, but let the whole system enter low power states more often. + + Runtime Power Management model: + Drivers may also enter low power states while the system is running, + independently of other power management activity. Upstream drivers + will normally not know (or care) if the device is in some low power + state when issuing requests; the driver will auto-resume anything + that's needed when it gets a request. + + This doesn't have, or need much infrastructure; it's just something you + should do when writing your drivers. For example, clk_disable() unused + clocks as part of minimizing power drain for currently-unused hardware. + Of course, sometimes clusters of drivers will collaborate with each + other, which could involve task-specific power management. + +There's not a lot to be said about those low power states except that they +are very system-specific, and often device-specific. Also, that if enough +drivers put themselves into low power states (at "runtime"), the effect may be +the same as entering some system-wide low-power state (system sleep) ... and +that synergies exist, so that several drivers using runtime pm might put the +system into a state where even deeper power saving options are available. + +Most suspended devices will have quiesced all I/O: no more DMA or irqs, no +more data read or written, and requests from upstream drivers are no longer +accepted. A given bus or platform may have different requirements though. + +Examples of hardware wakeup events include an alarm from a real time clock, +network wake-on-LAN packets, keyboard or mouse activity, and media insertion +or removal (for PCMCIA, MMC/SD, USB, and so on). + + +Interfaces for Entering System Sleep States +=========================================== +Most of the programming interfaces a device driver needs to know about +relate to that first model: entering a system-wide low power state, +rather than just minimizing power consumption by one device. + + +Bus Driver Methods +------------------ +The core methods to suspend and resume devices reside in struct bus_type. +These are mostly of interest to people writing infrastructure for busses +like PCI or USB, or because they define the primitives that device drivers +may need to apply in domain-specific ways to their devices: -Device Power Management +struct bus_type { + ... + int (*suspend)(struct device *dev, pm_message_t state); + int (*suspend_late)(struct device *dev, pm_message_t state); + int (*resume_early)(struct device *dev); + int (*resume)(struct device *dev); +}; -Device power management encompasses two areas - the ability to save -state and transition a device to a low-power state when the system is -entering a low-power state; and the ability to transition a device to -a low-power state while the system is running (and independently of -any other power management activity). +Bus drivers implement those methods as appropriate for the hardware and +the drivers using it; PCI works differently from USB, and so on. Not many +people write bus drivers; most driver code is a "device driver" that +builds on top of bus-specific framework code. + +For more information on these driver calls, see the description later; +they are called in phases for every device, respecting the parent-child +sequencing in the driver model tree. Note that as this is being written, +only the suspend() and resume() are widely available; not many bus drivers +leverage all of those phases, or pass them down to lower driver levels. + + +/sys/devices/.../power/wakeup files +----------------------------------- +All devices in the driver model have two flags to control handling of +wakeup events, which are hardware signals that can force the device and/or +system out of a low power state. These are initialized by bus or device +driver code using device_init_wakeup(dev,can_wakeup). + +The "can_wakeup" flag just records whether the device (and its driver) can +physically support wakeup events. When that flag is clear, the sysfs +"wakeup" file is empty, and device_may_wakeup() returns false. + +For devices that can issue wakeup events, a separate flag controls whether +that device should try to use its wakeup mechanism. The initial value of +device_may_wakeup() will be true, so that the device's "wakeup" file holds +the value "enabled". Userspace can change that to "disabled" so that +device_may_wakeup() returns false; or change it back to "enabled" (so that +it returns true again). + + +EXAMPLE: PCI Device Driver Methods +----------------------------------- +PCI framework software calls these methods when the PCI device driver bound +to a device device has provided them: + +struct pci_driver { + ... + int (*suspend)(struct pci_device *pdev, pm_message_t state); + int (*suspend_late)(struct pci_device *pdev, pm_message_t state); + + int (*resume_early)(struct pci_device *pdev); + int (*resume)(struct pci_device *pdev); +}; +Drivers will implement those methods, and call PCI-specific procedures +like pci_set_power_state(), pci_enable_wake(), pci_save_state(), and +pci_restore_state() to manage PCI-specific mechanisms. (PCI config space +could be saved during driver probe, if it weren't for the fact that some +systems rely on userspace tweaking using setpci.) Devices are suspended +before their bridges enter low power states, and likewise bridges resume +before their devices. + + +Upper Layers of Driver Stacks +----------------------------- +Device drivers generally have at least two interfaces, and the methods +sketched above are the ones which apply to the lower level (nearer PCI, USB, +or other bus hardware). The network and block layers are examples of upper +level interfaces, as is a character device talking to userspace. + +Power management requests normally need to flow through those upper levels, +which often use domain-oriented requests like "blank that screen". In +some cases those upper levels will have power management intelligence that +relates to end-user activity, or other devices that work in cooperation. + +When those interfaces are structured using class interfaces, there is a +standard way to have the upper layer stop issuing requests to a given +class device (and restart later): + +struct class { + ... + int (*suspend)(struct device *dev, pm_message_t state); + int (*resume)(struct device *dev); +}; -Methods +Those calls are issued in specific phases of the process by which the +system enters a low power "suspend" state, or resumes from it. + + +Calling Drivers to Enter System Sleep States +============================================ +When the system enters a low power state, each device's driver is asked +to suspend the device by putting it into state compatible with the target +system state. That's usually some version of "off", but the details are +system-specific. Also, wakeup-enabled devices will usually stay partly +functional in order to wake the system. + +When the system leaves that low power state, the device's driver is asked +to resume it. The suspend and resume operations always go together, and +both are multi-phase operations. + +For simple drivers, suspend might quiesce the device using the class code +and then turn its hardware as "off" as possible with late_suspend. The +matching resume calls would then completely reinitialize the hardware +before reactivating its class I/O queues. + +More power-aware drivers drivers will use more than one device low power +state, either at runtime or during system sleep states, and might trigger +system wakeup events. + + +Call Sequence Guarantees +------------------------ +To ensure that bridges and similar links needed to talk to a device are +available when the device is suspended or resumed, the device tree is +walked in a bottom-up order to suspend devices. A top-down order is +used to resume those devices. + +The ordering of the device tree is defined by the order in which devices +get registered: a child can never be registered, probed or resumed before +its parent; and can't be removed or suspended after that parent. + +The policy is that the device tree should match hardware bus topology. +(Or at least the control bus, for devices which use multiple busses.) + + +Suspending Devices +------------------ +Suspending a given device is done in several phases. Suspending the +system always includes every phase, executing calls for every device +before the next phase begins. Not all busses or classes support all +these callbacks; and not all drivers use all the callbacks. + +The phases are seen by driver notifications issued in this order: + + 1 class.suspend(dev, message) is called after tasks are frozen, for + devices associated with a class that has such a method. This + method may sleep. + + Since I/O activity usually comes from such higher layers, this is + a good place to quiesce all drivers of a given type (and keep such + code out of those drivers). + + 2 bus.suspend(dev, message) is called next. This method may sleep, + and is often morphed into a device driver call with bus-specific + parameters and/or rules. + + This call should handle parts of device suspend logic that require + sleeping. It probably does work to quiesce the device which hasn't + been abstracted into class.suspend() or bus.suspend_late(). + + 3 bus.suspend_late(dev, message) is called with IRQs disabled, and + with only one CPU active. Until the bus.resume_early() phase + completes (see later), IRQs are not enabled again. This method + won't be exposed by all busses; for message based busses like USB, + I2C, or SPI, device interactions normally require IRQs. This bus + call may be morphed into a driver call with bus-specific parameters. + + This call might save low level hardware state that might otherwise + be lost in the upcoming low power state, and actually put the + device into a low power state ... so that in some cases the device + may stay partly usable until this late. This "late" call may also + help when coping with hardware that behaves badly. + +The pm_message_t parameter is currently used to refine those semantics +(described later). + +At the end of those phases, drivers should normally have stopped all I/O +transactions (DMA, IRQs), saved enough state that they can re-initialize +or restore previous state (as needed by the hardware), and placed the +device into a low-power state. On many platforms they will also use +clk_disable() to gate off one or more clock sources; sometimes they will +also switch off power supplies, or reduce voltages. Drivers which have +runtime PM support may already have performed some or all of the steps +needed to prepare for the upcoming system sleep state. + +When any driver sees that its device_can_wakeup(dev), it should make sure +to use the relevant hardware signals to trigger a system wakeup event. +For example, enable_irq_wake() might identify GPIO signals hooked up to +a switch or other external hardware, and pci_enable_wake() does something +similar for PCI's PME# signal. + +If a driver (or bus, or class) fails it suspend method, the system won't +enter the desired low power state; it will resume all the devices it's +suspended so far. + +Note that drivers may need to perform different actions based on the target +system lowpower/sleep state. At this writing, there are only platform +specific APIs through which drivers could determine those target states. + + +Device Low Power (suspend) States +--------------------------------- +Device low-power states aren't very standard. One device might only handle +"on" and "off, while another might support a dozen different versions of +"on" (how many engines are active?), plus a state that gets back to "on" +faster than from a full "off". + +Some busses define rules about what different suspend states mean. PCI +gives one example: after the suspend sequence completes, a non-legacy +PCI device may not perform DMA or issue IRQs, and any wakeup events it +issues would be issued through the PME# bus signal. Plus, there are +several PCI-standard device states, some of which are optional. + +In contrast, integrated system-on-chip processors often use irqs as the +wakeup event sources (so drivers would call enable_irq_wake) and might +be able to treat DMA completion as a wakeup event (sometimes DMA can stay +active too, it'd only be the CPU and some peripherals that sleep). + +Some details here may be platform-specific. Systems may have devices that +can be fully active in certain sleep states, such as an LCD display that's +refreshed using DMA while most of the system is sleeping lightly ... and +its frame buffer might even be updated by a DSP or other non-Linux CPU while +the Linux control processor stays idle. + +Moreover, the specific actions taken may depend on the target system state. +One target system state might allow a given device to be very operational; +another might require a hard shut down with re-initialization on resume. +And two different target systems might use the same device in different +ways; the aforementioned LCD might be active in one product's "standby", +but a different product using the same SOC might work differently. + + +Meaning of pm_message_t.event +----------------------------- +Parameters to suspend calls include the device affected and a message of +type pm_message_t, which has one field: the event. If driver does not +recognize the event code, suspend calls may abort the request and return +a negative errno. However, most drivers will be fine if they implement +PM_EVENT_SUSPEND semantics for all messages. + +The event codes are used to refine the goal of suspending the device, and +mostly matter when creating or resuming system memory image snapshots, as +used with suspend-to-disk: + + PM_EVENT_SUSPEND -- quiesce the driver and put hardware into a low-power + state. When used with system sleep states like "suspend-to-RAM" or + "standby", the upcoming resume() call will often be able to rely on + state kept in hardware, or issue system wakeup events. When used + instead with suspend-to-disk, few devices support this capability; + most are completely powered off. + + PM_EVENT_FREEZE -- quiesce the driver, but don't necessarily change into + any low power mode. A system snapshot is about to be taken, often + followed by a call to the driver's resume() method. Neither wakeup + events nor DMA are allowed. + + PM_EVENT_PRETHAW -- quiesce the driver, knowing that the upcoming resume() + will restore a suspend-to-disk snapshot from a different kernel image. + Drivers that are smart enough to look at their hardware state during + resume() processing need that state to be correct ... a PRETHAW could + be used to invalidate that state (by resetting the device), like a + shutdown() invocation would before a kexec() or system halt. Other + drivers might handle this the same way as PM_EVENT_FREEZE. Neither + wakeup events nor DMA are allowed. + +To enter "standby" (ACPI S1) or "Suspend to RAM" (STR, ACPI S3) states, or +the similarly named APM states, only PM_EVENT_SUSPEND is used; for "Suspend +to Disk" (STD, hibernate, ACPI S4), all of those event codes are used. + +There's also PM_EVENT_ON, a value which never appears as a suspend event +but is sometimes used to record the "not suspended" device state. + + +Resuming Devices +---------------- +Resuming is done in multiple phases, much like suspending, with all +devices processing each phase's calls before the next phase begins. + +The phases are seen by driver notifications issued in this order: + + 1 bus.resume_early(dev) is called with IRQs disabled, and with + only one CPU active. As with bus.suspend_late(), this method + won't be supported on busses that require IRQs in order to + interact with devices. + + This reverses the effects of bus.suspend_late(). + + 2 bus.resume(dev) is called next. This may be morphed into a device + driver call with bus-specific parameters; implementations may sleep. + + This reverses the effects of bus.suspend(). + + 3 class.resume(dev) is called for devices associated with a class + that has such a method. Implementations may sleep. + + This reverses the effects of class.suspend(), and would usually + reactivate the device's I/O queue. + +At the end of those phases, drivers should normally be as functional as +they were before suspending: I/O can be performed using DMA and IRQs, and +the relevant clocks are gated on. The device need not be "fully on"; it +might be in a runtime lowpower/suspend state that acts as if it were. + +However, the details here may again be platform-specific. For example, +some systems support multiple "run" states, and the mode in effect at +the end of resume() might not be the one which preceded suspension. +That means availability of certain clocks or power supplies changed, +which could easily affect how a driver works. + + +Drivers need to be able to handle hardware which has been reset since the +suspend methods were called, for example by complete reinitialization. +This may be the hardest part, and the one most protected by NDA'd documents +and chip errata. It's simplest if the hardware state hasn't changed since +the suspend() was called, but that can't always be guaranteed. + +Drivers must also be prepared to notice that the device has been removed +while the system was powered off, whenever that's physically possible. +PCMCIA, MMC, USB, Firewire, SCSI, and even IDE are common examples of busses +where common Linux platforms will see such removal. Details of how drivers +will notice and handle such removals are currently bus-specific, and often +involve a separate thread. -The methods to suspend and resume devices reside in struct bus_type: -struct bus_type { - ... - int (*suspend)(struct device * dev, pm_message_t state); - int (*resume)(struct device * dev); -}; +Note that the bus-specific runtime PM wakeup mechanism can exist, and might +be defined to share some of the same driver code as for system wakeup. For +example, a bus-specific device driver's resume() method might be used there, +so it wouldn't only be called from bus.resume() during system-wide wakeup. +See bus-specific information about how runtime wakeup events are handled. -Each bus driver is responsible implementing these methods, translating -the call into a bus-specific request and forwarding the call to the -bus-specific drivers. For example, PCI drivers implement suspend() and -resume() methods in struct pci_driver. The PCI core is simply -responsible for translating the pointers to PCI-specific ones and -calling the low-level driver. - -This is done to a) ease transition to the new power management methods -and leverage the existing PM code in various bus drivers; b) allow -buses to implement generic and default PM routines for devices, and c) -make the flow of execution obvious to the reader. - - -System Power Management - -When the system enters a low-power state, the device tree is walked in -a depth-first fashion to transition each device into a low-power -state. The ordering of the device tree is guaranteed by the order in -which devices get registered - children are never registered before -their ancestors, and devices are placed at the back of the list when -registered. By walking the list in reverse order, we are guaranteed to -suspend devices in the proper order. - -Devices are suspended once with interrupts enabled. Drivers are -expected to stop I/O transactions, save device state, and place the -device into a low-power state. Drivers may sleep, allocate memory, -etc. at will. - -Some devices are broken and will inevitably have problems powering -down or disabling themselves with interrupts enabled. For these -special cases, they may return -EAGAIN. This will put the device on a -list to be taken care of later. When interrupts are disabled, before -we enter the low-power state, their drivers are called again to put -their device to sleep. - -On resume, the devices that returned -EAGAIN will be called to power -themselves back on with interrupts disabled. Once interrupts have been -re-enabled, the rest of the drivers will be called to resume their -devices. On resume, a driver is responsible for powering back on each -device, restoring state, and re-enabling I/O transactions for that -device. +System Devices +-------------- System devices follow a slightly different API, which can be found in include/linux/sysdev.h drivers/base/sys.c -System devices will only be suspended with interrupts disabled, and -after all other devices have been suspended. On resume, they will be -resumed before any other devices, and also with interrupts disabled. +System devices will only be suspended with interrupts disabled, and after +all other devices have been suspended. On resume, they will be resumed +before any other devices, and also with interrupts disabled. +That is, IRQs are disabled, the suspend_late() phase begins, then the +sysdev_driver.suspend() phase, and the system enters a sleep state. Then +the sysdev_driver.resume() phase begins, followed by the resume_early() +phase, after which IRQs are enabled. -Runtime Power Management - -Many devices are able to dynamically power down while the system is -still running. This feature is useful for devices that are not being -used, and can offer significant power savings on a running system. - -In each device's directory, there is a 'power' directory, which -contains at least a 'state' file. Reading from this file displays what -power state the device is currently in. Writing to this file initiates -a transition to the specified power state, which must be a decimal in -the range 1-3, inclusive; or 0 for 'On'. +Code to actually enter and exit the system-wide low power state sometimes +involves hardware details that are only known to the boot firmware, and +may leave a CPU running software (from SRAM or flash memory) that monitors +the system and manages its wakeup sequence. -The PM core will call the ->suspend() method in the bus_type object -that the device belongs to if the specified state is not 0, or -->resume() if it is. -Nothing will happen if the specified state is the same state the -device is currently in. - -If the device is already in a low-power state, and the specified state -is another, but different, low-power state, the ->resume() method will -first be called to power the device back on, then ->suspend() will be -called again with the new state. - -The driver is responsible for saving the working state of the device -and putting it into the low-power state specified. If this was -successful, it returns 0, and the device's power_state field is -updated. - -The driver must take care to know whether or not it is able to -properly resume the device, including all step of reinitialization -necessary. (This is the hardest part, and the one most protected by -NDA'd documents). - -The driver must also take care not to suspend a device that is -currently in use. It is their responsibility to provide their own -exclusion mechanisms. - -The runtime power transition happens with interrupts enabled. If a -device cannot support being powered down with interrupts, it may -return -EAGAIN (as it would during a system power management -transition), but it will _not_ be called again, and the transaction -will fail. - -There is currently no way to know what states a device or driver -supports a priori. This will change in the future. - -pm_message_t meaning - -pm_message_t has two fields. event ("major"), and flags. If driver -does not know event code, it aborts the request, returning error. Some -drivers may need to deal with special cases based on the actual type -of suspend operation being done at the system level. This is why -there are flags. - -Event codes are: - -ON -- no need to do anything except special cases like broken -HW. - -# NOTIFICATION -- pretty much same as ON? - -FREEZE -- stop DMA and interrupts, and be prepared to reinit HW from -scratch. That probably means stop accepting upstream requests, the -actual policy of what to do with them being specific to a given -driver. It's acceptable for a network driver to just drop packets -while a block driver is expected to block the queue so no request is -lost. (Use IDE as an example on how to do that). FREEZE requires no -power state change, and it's expected for drivers to be able to -quickly transition back to operating state. - -SUSPEND -- like FREEZE, but also put hardware into low-power state. If -there's need to distinguish several levels of sleep, additional flag -is probably best way to do that. - -Transitions are only from a resumed state to a suspended state, never -between 2 suspended states. (ON -> FREEZE or ON -> SUSPEND can happen, -FREEZE -> SUSPEND or SUSPEND -> FREEZE can not). - -All events are: - -[NOTE NOTE NOTE: If you are driver author, you should not care; you -should only look at event, and ignore flags.] - -#Prepare for suspend -- userland is still running but we are going to -#enter suspend state. This gives drivers chance to load firmware from -#disk and store it in memory, or do other activities taht require -#operating userland, ability to kmalloc GFP_KERNEL, etc... All of these -#are forbiden once the suspend dance is started.. event = ON, flags = -#PREPARE_TO_SUSPEND - -Apm standby -- prepare for APM event. Quiesce devices to make life -easier for APM BIOS. event = FREEZE, flags = APM_STANDBY - -Apm suspend -- same as APM_STANDBY, but it we should probably avoid -spinning down disks. event = FREEZE, flags = APM_SUSPEND - -System halt, reboot -- quiesce devices to make life easier for BIOS. event -= FREEZE, flags = SYSTEM_HALT or SYSTEM_REBOOT - -System shutdown -- at least disks need to be spun down, or data may be -lost. Quiesce devices, just to make life easier for BIOS. event = -FREEZE, flags = SYSTEM_SHUTDOWN - -Kexec -- turn off DMAs and put hardware into some state where new -kernel can take over. event = FREEZE, flags = KEXEC - -Powerdown at end of swsusp -- very similar to SYSTEM_SHUTDOWN, except wake -may need to be enabled on some devices. This actually has at least 3 -subtypes, system can reboot, enter S4 and enter S5 at the end of -swsusp. event = FREEZE, flags = SWSUSP and one of SYSTEM_REBOOT, -SYSTEM_SHUTDOWN, SYSTEM_S4 - -Suspend to ram -- put devices into low power state. event = SUSPEND, -flags = SUSPEND_TO_RAM - -Freeze for swsusp snapshot -- stop DMA and interrupts. No need to put -devices into low power mode, but you must be able to reinitialize -device from scratch in resume method. This has two flavors, its done -once on suspending kernel, once on resuming kernel. event = FREEZE, -flags = DURING_SUSPEND or DURING_RESUME - -Device detach requested from /sys -- deinitialize device; proably same as -SYSTEM_SHUTDOWN, I do not understand this one too much. probably event -= FREEZE, flags = DEV_DETACH. - -#These are not really events sent: -# -#System fully on -- device is working normally; this is probably never -#passed to suspend() method... event = ON, flags = 0 -# -#Ready after resume -- userland is now running, again. Time to free any -#memory you ate during prepare to suspend... event = ON, flags = -#READY_AFTER_RESUME -# +Runtime Power Management +======================== +Many devices are able to dynamically power down while the system is still +running. This feature is useful for devices that are not being used, and +can offer significant power savings on a running system. These devices +often support a range of runtime power states, which might use names such +as "off", "sleep", "idle", "active", and so on. Those states will in some +cases (like PCI) be partially constrained by a bus the device uses, and will +usually include hardware states that are also used in system sleep states. + +However, note that if a driver puts a device into a runtime low power state +and the system then goes into a system-wide sleep state, it normally ought +to resume into that runtime low power state rather than "full on". Such +distinctions would be part of the driver-internal state machine for that +hardware; the whole point of runtime power management is to be sure that +drivers are decoupled in that way from the state machine governing phases +of the system-wide power/sleep state transitions. + + +Power Saving Techniques +----------------------- +Normally runtime power management is handled by the drivers without specific +userspace or kernel intervention, by device-aware use of techniques like: + + Using information provided by other system layers + - stay deeply "off" except between open() and close() + - if transceiver/PHY indicates "nobody connected", stay "off" + - application protocols may include power commands or hints + + Using fewer CPU cycles + - using DMA instead of PIO + - removing timers, or making them lower frequency + - shortening "hot" code paths + - eliminating cache misses + - (sometimes) offloading work to device firmware + + Reducing other resource costs + - gating off unused clocks in software (or hardware) + - switching off unused power supplies + - eliminating (or delaying/merging) IRQs + - tuning DMA to use word and/or burst modes + + Using device-specific low power states + - using lower voltages + - avoiding needless DMA transfers + +Read your hardware documentation carefully to see the opportunities that +may be available. If you can, measure the actual power usage and check +it against the budget established for your project. + + +Examples: USB hosts, system timer, system CPU +---------------------------------------------- +USB host controllers make interesting, if complex, examples. In many cases +these have no work to do: no USB devices are connected, or all of them are +in the USB "suspend" state. Linux host controller drivers can then disable +periodic DMA transfers that would otherwise be a constant power drain on the +memory subsystem, and enter a suspend state. In power-aware controllers, +entering that suspend state may disable the clock used with USB signaling, +saving a certain amount of power. + +The controller will be woken from that state (with an IRQ) by changes to the +signal state on the data lines of a given port, for example by an existing +peripheral requesting "remote wakeup" or by plugging a new peripheral. The +same wakeup mechanism usually works from "standby" sleep states, and on some +systems also from "suspend to RAM" (or even "suspend to disk") states. +(Except that ACPI may be involved instead of normal IRQs, on some hardware.) + +System devices like timers and CPUs may have special roles in the platform +power management scheme. For example, system timers using a "dynamic tick" +approach don't just save CPU cycles (by eliminating needless timer IRQs), +but they may also open the door to using lower power CPU "idle" states that +cost more than a jiffie to enter and exit. On x86 systems these are states +like "C3"; note that periodic DMA transfers from a USB host controller will +also prevent entry to a C3 state, much like a periodic timer IRQ. + +That kind of runtime mechanism interaction is common. "System On Chip" (SOC) +processors often have low power idle modes that can't be entered unless +certain medium-speed clocks (often 12 or 48 MHz) are gated off. When the +drivers gate those clocks effectively, then the system idle task may be able +to use the lower power idle modes and thereby increase battery life. + +If the CPU can have a "cpufreq" driver, there also may be opportunities +to shift to lower voltage settings and reduce the power cost of executing +a given number of instructions. (Without voltage adjustment, it's rare +for cpufreq to save much power; the cost-per-instruction must go down.) + + +/sys/devices/.../power/state files +================================== +For now you can also test some of this functionality using sysfs. + + DEPRECATED: USE "power/state" ONLY FOR DRIVER TESTING, AND + AVOID USING dev->power.power_state IN DRIVERS. + + THESE WILL BE REMOVED. IF THE "power/state" FILE GETS REPLACED, + IT WILL BECOME SOMETHING COUPLED TO THE BUS OR DRIVER. + +In each device's directory, there is a 'power' directory, which contains +at least a 'state' file. The value of this field is effectively boolean, +PM_EVENT_ON or PM_EVENT_SUSPEND. + + * Reading from this file displays a value corresponding to + the power.power_state.event field. All nonzero values are + displayed as "2", corresponding to a low power state; zero + is displayed as "0", corresponding to normal operation. + + * Writing to this file initiates a transition using the + specified event code number; only '0', '2', and '3' are + accepted (without a newline); '2' and '3' are both + mapped to PM_EVENT_SUSPEND. + +On writes, the PM core relies on that recorded event code and the device/bus +capabilities to determine whether it uses a partial suspend() or resume() +sequence to change things so that the recorded event corresponds to the +numeric parameter. + + - If the bus requires the irqs-disabled suspend_late()/resume_early() + phases, writes fail because those operations are not supported here. + + - If the recorded value is the expected value, nothing is done. + + - If the recorded value is nonzero, the device is partially resumed, + using the bus.resume() and/or class.resume() methods. + + - If the target value is nonzero, the device is partially suspended, + using the class.suspend() and/or bus.suspend() methods and the + PM_EVENT_SUSPEND message. + +Drivers have no way to tell whether their suspend() and resume() calls +have come through the sysfs power/state file or as part of entering a +system sleep state, except that when accessed through sysfs the normal +parent/child sequencing rules are ignored. Drivers (such as bus, bridge, +or hub drivers) which expose child devices may need to enforce those rules +on their own. diff --git a/Documentation/power/pci.txt b/Documentation/power/pci.txt index 73fc87e5dc38..24edf25b3bb7 100644 --- a/Documentation/power/pci.txt +++ b/Documentation/power/pci.txt @@ -326,7 +326,7 @@ A reference implementation This is a typical implementation. Drivers can slightly change the order of the operations in the implementation, ignore some operations or add -more deriver specific operations in it, but drivers should do something like +more driver specific operations in it, but drivers should do something like this on the whole. 5. Resources diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt index 823b2cf6e3dc..9ea2208b43b5 100644 --- a/Documentation/power/swsusp.txt +++ b/Documentation/power/swsusp.txt @@ -156,7 +156,7 @@ instead set the PF_NOFREEZE process flag when creating the thread (and be very carefull). -Q: What is the difference between between "platform", "shutdown" and +Q: What is the difference between "platform", "shutdown" and "firmware" in /sys/power/disk? A: @@ -175,8 +175,8 @@ reliable. Q: I do not understand why you have such strong objections to idea of selective suspend. -A: Do selective suspend during runtime power managment, that's okay. But -its useless for suspend-to-disk. (And I do not see how you could use +A: Do selective suspend during runtime power management, that's okay. But +it's useless for suspend-to-disk. (And I do not see how you could use it for suspend-to-ram, I hope you do not want that). Lets see, so you suggest to @@ -211,7 +211,7 @@ slowness may not matter to you. It can always be fixed later. For devices like disk it does matter, you do not want to spindown for FREEZE. -Q: After resuming, system is paging heavilly, leading to very bad interactivity. +Q: After resuming, system is paging heavily, leading to very bad interactivity. A: Try running diff --git a/Documentation/power/tricks.txt b/Documentation/power/tricks.txt index c6d58d3da133..3b26bb502a4a 100644 --- a/Documentation/power/tricks.txt +++ b/Documentation/power/tricks.txt @@ -9,7 +9,7 @@ If you want to trick swsusp/S3 into working, you might want to try: * turn off APIC and preempt -* use ext2. At least it has working fsck. [If something seemes to go +* use ext2. At least it has working fsck. [If something seems to go wrong, force fsck when you have a chance] * turn off modules diff --git a/Documentation/power/userland-swsusp.txt b/Documentation/power/userland-swsusp.txt index 94058220aaf0..64755e9285db 100644 --- a/Documentation/power/userland-swsusp.txt +++ b/Documentation/power/userland-swsusp.txt @@ -91,7 +91,7 @@ unfreeze user space processes frozen by SNAPSHOT_UNFREEZE if they are still frozen when the device is being closed). Currently it is assumed that the userland utilities reading/writing the -snapshot image from/to the kernel will use a swap parition, called the resume +snapshot image from/to the kernel will use a swap partition, called the resume partition, as storage space. However, this is not really required, as they can use, for example, a special (blank) suspend partition or a file on a partition that is unmounted before SNAPSHOT_ATOMIC_SNAPSHOT and mounted afterwards. diff --git a/Documentation/power/video.txt b/Documentation/power/video.txt index d859faa3a463..2b358498d095 100644 --- a/Documentation/power/video.txt +++ b/Documentation/power/video.txt @@ -16,7 +16,7 @@ problem for S1 standby, because hardware should retain its state over that. We either have to run video BIOS during early resume, or interpret it -using vbetool later, or maybe nothing is neccessary on particular +using vbetool later, or maybe nothing is necessary on particular system because video state is preserved. Unfortunately different methods work on different systems, and no known method suits all of them. diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt index 5c0ba235f5a5..27b457c09729 100644 --- a/Documentation/powerpc/booting-without-of.txt +++ b/Documentation/powerpc/booting-without-of.txt @@ -145,7 +145,7 @@ it with special cases. in case you are entering the kernel with MMU enabled and a non-1:1 mapping. - r5 : NULL (as to differenciate with method a) + r5 : NULL (as to differentiate with method a) Note about SMP entry: Either your firmware puts your other CPUs in some sleep loop or spin loop in ROM where you can get @@ -245,7 +245,7 @@ the block to RAM before passing it to the kernel. --------- The kernel is entered with r3 pointing to an area of memory that is - roughtly described in include/asm-powerpc/prom.h by the structure + roughly described in include/asm-powerpc/prom.h by the structure boot_param_header: struct boot_param_header { @@ -335,7 +335,7 @@ struct boot_param_header { "compact" format for the tree itself that is however not backward compatible. You should always generate a structure of the highest version defined at the time of your implementation. Currently - that is version 16, unless you explicitely aim at being backward + that is version 16, unless you explicitly aim at being backward compatible. - last_comp_version @@ -418,9 +418,9 @@ zero terminated string and is mandatory for version 1 to 3 of the format definition (as it is in Open Firmware). Version 0x10 makes it optional as it can generate it from the unit name defined below. -There is also a "unit name" that is used to differenciate nodes with +There is also a "unit name" that is used to differentiate nodes with the same name at the same level, it is usually made of the node -name's, the "@" sign, and a "unit address", which definition is +names, the "@" sign, and a "unit address", which definition is specific to the bus type the node sits on. The unit name doesn't exist as a property per-se but is included in @@ -550,11 +550,11 @@ Here's the basic structure of a single node: * [child nodes if any] * token OF_DT_END_NODE (that is 0x00000002) -So the node content can be summmarised as a start token, a full path, -a list of properties, a list of child node and an end token. Every +So the node content can be summarised as a start token, a full path, +a list of properties, a list of child nodes, and an end token. Every child node is a full node structure itself as defined above. -4) Device tree 'strings" block +4) Device tree "strings" block In order to save space, property names, which are generally redundant, are stored separately in the "strings" block. This block is simply the @@ -573,7 +573,7 @@ implementation of Open Firmware or an implementation compatible with the Open Firmware client interface, those properties will be created by the trampoline code in the kernel's prom_init() file. For example, that's where you'll have to add code to detect your board model and -set the platform number. However, when using the flatenned device-tree +set the platform number. However, when using the flattened device-tree entry point, there is no prom_init() pass, and thus you have to provide those properties yourself. @@ -630,12 +630,11 @@ like address space bits, you'll have to add a bus translator to the prom_parse.c file of the recent kernels for your bus type. The "reg" property only defines addresses and sizes (if #size-cells -is -non-0) within a given bus. In order to translate addresses upward +is non-0) within a given bus. In order to translate addresses upward (that is into parent bus addresses, and possibly into cpu physical addresses), all busses must contain a "ranges" property. If the "ranges" property is missing at a given level, it's assumed that -translation isn't possible. The format of the "ranges" proprety for a +translation isn't possible. The format of the "ranges" property for a bus is a list of: bus address, parent bus address, size @@ -689,7 +688,7 @@ is present). 4) Note about node and property names and character set ------------------------------------------------------- -While open firmware provides more flexibe usage of 8859-1, this +While open firmware provides more flexible usage of 8859-1, this specification enforces more strict rules. Nodes and properties should be comprised only of ASCII characters 'a' to 'z', '0' to '9', ',', '.', '_', '+', '#', '?', and '-'. Node names additionally @@ -732,12 +731,12 @@ address which can extend beyond that limit. that typically get driven by the same platform code in the kernel, you would use a different "model" property but put a value in "compatible". The kernel doesn't directly use that - value (see /chosen/linux,platform for how the kernel choses a + value (see /chosen/linux,platform for how the kernel chooses a platform type) but it is generally useful. The root node is also generally where you add additional properties specific to your board like the serial number if any, that sort of - thing. it is recommended that if you add any "custom" property whose + thing. It is recommended that if you add any "custom" property whose name may clash with standard defined ones, you prefix them with your vendor name and a comma. @@ -817,7 +816,7 @@ address which can extend beyond that limit. your board. It's a list of addresses/sizes concatenated together, with the number of cells of each defined by the #address-cells and #size-cells of the root node. For example, - with both of these properties beeing 2 like in the example given + with both of these properties being 2 like in the example given earlier, a 970 based machine with 6Gb of RAM could typically have a "reg" property here that looks like: @@ -970,7 +969,7 @@ device-tree in another format. The currently supported formats are: - "asm": assembly language file. This is a file that can be sourced by gas to generate a device-tree "blob". That file can then simply be added to your Makefile. Additionally, the - assembly file exports some symbols that can be use + assembly file exports some symbols that can be used. The syntax of the dtc tool is @@ -984,10 +983,10 @@ generated. Supported versions are 1,2,3 and 16. The default is currently version 3 but that may change in the future to version 16. Additionally, dtc performs various sanity checks on the tree, like the -uniqueness of linux,phandle properties, validity of strings, etc... +uniqueness of linux, phandle properties, validity of strings, etc... The format of the .dts "source" file is "C" like, supports C and C++ -style commments. +style comments. / { } @@ -1069,13 +1068,13 @@ while all this has been defined and implemented. around. It contains no internal offsets or pointers for this purpose. - - An example of code for iterating nodes & retreiving properties + - An example of code for iterating nodes & retrieving properties directly from the flattened tree format can be found in the kernel file arch/ppc64/kernel/prom.c, look at scan_flat_dt() function, - it's usage in early_init_devtree(), and the corresponding various + its usage in early_init_devtree(), and the corresponding various early_init_dt_scan_*() callbacks. That code can be re-used in a GPL bootloader, and as the author of that code, I would be happy - do discuss possible free licencing to any vendor who wishes to + to discuss possible free licencing to any vendor who wishes to integrate all or part of this code into a non-GPL bootloader. @@ -1441,6 +1440,258 @@ platforms are moved over to use the flattened-device-tree model. descriptor-types-mask = <012b0ebf>; }; + h) Board Control and Status (BCSR) + + Required properties: + + - device_type : Should be "board-control" + - reg : Offset and length of the register set for the device + + Example: + + bcsr@f8000000 { + device_type = "board-control"; + reg = <f8000000 8000>; + }; + + i) Freescale QUICC Engine module (QE) + This represents qe module that is installed on PowerQUICC II Pro. + Hopefully it will merge backward compatibility with CPM/CPM2. + Basically, it is a bus of devices, that could act more or less + as a complete entity (UCC, USB etc ). All of them should be siblings on + the "root" qe node, using the common properties from there. + The description below applies to the the qe of MPC8360 and + more nodes and properties would be extended in the future. + + i) Root QE device + + Required properties: + - device_type : should be "qe"; + - model : precise model of the QE, Can be "QE", "CPM", or "CPM2" + - reg : offset and length of the device registers. + - bus-frequency : the clock frequency for QUICC Engine. + + Recommended properties + - brg-frequency : the internal clock source frequency for baud-rate + generators in Hz. + + Example: + qe@e0100000 { + #address-cells = <1>; + #size-cells = <1>; + #interrupt-cells = <2>; + device_type = "qe"; + model = "QE"; + ranges = <0 e0100000 00100000>; + reg = <e0100000 480>; + brg-frequency = <0>; + bus-frequency = <179A7B00>; + } + + + ii) SPI (Serial Peripheral Interface) + + Required properties: + - device_type : should be "spi". + - compatible : should be "fsl_spi". + - mode : the spi operation mode, it can be "cpu" or "qe". + - reg : Offset and length of the register set for the device + - interrupts : <a b> where a is the interrupt number and b is a + field that represents an encoding of the sense and level + information for the interrupt. This should be encoded based on + the information in section 2) depending on the type of interrupt + controller you have. + - interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + + Example: + spi@4c0 { + device_type = "spi"; + compatible = "fsl_spi"; + reg = <4c0 40>; + interrupts = <82 0>; + interrupt-parent = <700>; + mode = "cpu"; + }; + + + iii) USB (Universal Serial Bus Controller) + + Required properties: + - device_type : should be "usb". + - compatible : could be "qe_udc" or "fhci-hcd". + - mode : the could be "host" or "slave". + - reg : Offset and length of the register set for the device + - interrupts : <a b> where a is the interrupt number and b is a + field that represents an encoding of the sense and level + information for the interrupt. This should be encoded based on + the information in section 2) depending on the type of interrupt + controller you have. + - interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + + Example(slave): + usb@6c0 { + device_type = "usb"; + compatible = "qe_udc"; + reg = <6c0 40>; + interrupts = <8b 0>; + interrupt-parent = <700>; + mode = "slave"; + }; + + + iv) UCC (Unified Communications Controllers) + + Required properties: + - device_type : should be "network", "hldc", "uart", "transparent" + "bisync" or "atm". + - compatible : could be "ucc_geth" or "fsl_atm" and so on. + - model : should be "UCC". + - device-id : the ucc number(1-8), corresponding to UCCx in UM. + - reg : Offset and length of the register set for the device + - interrupts : <a b> where a is the interrupt number and b is a + field that represents an encoding of the sense and level + information for the interrupt. This should be encoded based on + the information in section 2) depending on the type of interrupt + controller you have. + - interrupt-parent : the phandle for the interrupt controller that + services interrupts for this device. + - pio-handle : The phandle for the Parallel I/O port configuration. + - rx-clock : represents the UCC receive clock source. + 0x00 : clock source is disabled; + 0x1~0x10 : clock source is BRG1~BRG16 respectively; + 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. + - tx-clock: represents the UCC transmit clock source; + 0x00 : clock source is disabled; + 0x1~0x10 : clock source is BRG1~BRG16 respectively; + 0x11~0x28: clock source is QE_CLK1~QE_CLK24 respectively. + + Required properties for network device_type: + - mac-address : list of bytes representing the ethernet address. + - phy-handle : The phandle for the PHY connected to this controller. + + Example: + ucc@2000 { + device_type = "network"; + compatible = "ucc_geth"; + model = "UCC"; + device-id = <1>; + reg = <2000 200>; + interrupts = <a0 0>; + interrupt-parent = <700>; + mac-address = [ 00 04 9f 00 23 23 ]; + rx-clock = "none"; + tx-clock = "clk9"; + phy-handle = <212000>; + pio-handle = <140001>; + }; + + + v) Parallel I/O Ports + + This node configures Parallel I/O ports for CPUs with QE support. + The node should reside in the "soc" node of the tree. For each + device that using parallel I/O ports, a child node should be created. + See the definition of the Pin configuration nodes below for more + information. + + Required properties: + - device_type : should be "par_io". + - reg : offset to the register set and its length. + - num-ports : number of Parallel I/O ports + + Example: + par_io@1400 { + reg = <1400 100>; + #address-cells = <1>; + #size-cells = <0>; + device_type = "par_io"; + num-ports = <7>; + ucc_pin@01 { + ...... + }; + + + vi) Pin configuration nodes + + Required properties: + - linux,phandle : phandle of this node; likely referenced by a QE + device. + - pio-map : array of pin configurations. Each pin is defined by 6 + integers. The six numbers are respectively: port, pin, dir, + open_drain, assignment, has_irq. + - port : port number of the pin; 0-6 represent port A-G in UM. + - pin : pin number in the port. + - dir : direction of the pin, should encode as follows: + + 0 = The pin is disabled + 1 = The pin is an output + 2 = The pin is an input + 3 = The pin is I/O + + - open_drain : indicates the pin is normal or wired-OR: + + 0 = The pin is actively driven as an output + 1 = The pin is an open-drain driver. As an output, the pin is + driven active-low, otherwise it is three-stated. + + - assignment : function number of the pin according to the Pin Assignment + tables in User Manual. Each pin can have up to 4 possible functions in + QE and two options for CPM. + - has_irq : indicates if the pin is used as source of exteral + interrupts. + + Example: + ucc_pin@01 { + linux,phandle = <140001>; + pio-map = < + /* port pin dir open_drain assignment has_irq */ + 0 3 1 0 1 0 /* TxD0 */ + 0 4 1 0 1 0 /* TxD1 */ + 0 5 1 0 1 0 /* TxD2 */ + 0 6 1 0 1 0 /* TxD3 */ + 1 6 1 0 3 0 /* TxD4 */ + 1 7 1 0 1 0 /* TxD5 */ + 1 9 1 0 2 0 /* TxD6 */ + 1 a 1 0 2 0 /* TxD7 */ + 0 9 2 0 1 0 /* RxD0 */ + 0 a 2 0 1 0 /* RxD1 */ + 0 b 2 0 1 0 /* RxD2 */ + 0 c 2 0 1 0 /* RxD3 */ + 0 d 2 0 1 0 /* RxD4 */ + 1 1 2 0 2 0 /* RxD5 */ + 1 0 2 0 2 0 /* RxD6 */ + 1 4 2 0 2 0 /* RxD7 */ + 0 7 1 0 1 0 /* TX_EN */ + 0 8 1 0 1 0 /* TX_ER */ + 0 f 2 0 1 0 /* RX_DV */ + 0 10 2 0 1 0 /* RX_ER */ + 0 0 2 0 1 0 /* RX_CLK */ + 2 9 1 0 3 0 /* GTX_CLK - CLK10 */ + 2 8 2 0 1 0>; /* GTX125 - CLK9 */ + }; + + vii) Multi-User RAM (MURAM) + + Required properties: + - device_type : should be "muram". + - mode : the could be "host" or "slave". + - ranges : Should be defined as specified in 1) to describe the + translation of MURAM addresses. + - data-only : sub-node which defines the address area under MURAM + bus that can be allocated as data/parameter + + Example: + + muram@10000 { + device_type = "muram"; + ranges = <0 00010000 0000c000>; + + data-only@0{ + reg = <0 c000>; + }; + }; More devices will be defined as this spec matures. diff --git a/Documentation/powerpc/eeh-pci-error-recovery.txt b/Documentation/powerpc/eeh-pci-error-recovery.txt index 3764dd4b12cb..4530d1bf0286 100644 --- a/Documentation/powerpc/eeh-pci-error-recovery.txt +++ b/Documentation/powerpc/eeh-pci-error-recovery.txt @@ -90,7 +90,7 @@ EEH-isolated, there is a firmware call it can make to determine if this is the case. If so, then the device driver should put itself into a consistent state (given that it won't be able to complete any pending work) and start recovery of the card. Recovery normally -would consist of reseting the PCI device (holding the PCI #RST +would consist of resetting the PCI device (holding the PCI #RST line high for two seconds), followed by setting up the device config space (the base address registers (BAR's), latency timer, cache line size, interrupt line, and so on). This is followed by a @@ -116,7 +116,7 @@ At this time, a generic EEH recovery mechanism has been implemented, so that individual device drivers do not need to be modified to support EEH recovery. This generic mechanism piggy-backs on the PCI hotplug infrastructure, and percolates events up through the userspace/udev -infrastructure. Followiing is a detailed description of how this is +infrastructure. Following is a detailed description of how this is accomplished. EEH must be enabled in the PHB's very early during the boot process, diff --git a/Documentation/powerpc/hvcs.txt b/Documentation/powerpc/hvcs.txt index 1e38166f4e54..f93462c5db25 100644 --- a/Documentation/powerpc/hvcs.txt +++ b/Documentation/powerpc/hvcs.txt @@ -259,7 +259,7 @@ This index of '2' means that in order to connect to vty-server adapter It should be noted that due to the system hotplug I/O capabilities of a system the /dev/hvcs* entry that interacts with a particular vty-server -adapter is not guarenteed to remain the same across system reboots. Look +adapter is not guaranteed to remain the same across system reboots. Look in the Q & A section for more on this issue. --------------------------------------------------------------------------- diff --git a/Documentation/prio_tree.txt b/Documentation/prio_tree.txt index 2fbb0c49bc5b..3aa68f9a117b 100644 --- a/Documentation/prio_tree.txt +++ b/Documentation/prio_tree.txt @@ -88,7 +88,7 @@ path which is not desirable. Hence, we do not optimize the height of the heap-and-size indexed overflow-sub-trees using prio_tree->index_bits. Instead the overflow sub-trees are indexed using full BITS_PER_LONG bits of size_index. This may lead to skewed sub-trees because most of the -higher significant bits of the size_index are likely to be be 0 (zero). In +higher significant bits of the size_index are likely to be 0 (zero). In the example above, all 3 overflow-sub-trees are skewed. This may marginally affect the performance. However, processes rarely map many vmas with the same start_vm_pgoff but different end_vm_pgoffs. Therefore, we normally diff --git a/Documentation/rocket.txt b/Documentation/rocket.txt index a10678004451..1d8582990435 100644 --- a/Documentation/rocket.txt +++ b/Documentation/rocket.txt @@ -97,7 +97,7 @@ a range of I/O addresses for it to use. The first RocketPort card requires a 68-byte contiguous block of I/O addresses, starting at one of the following: 0x100h, 0x140h, 0x180h, 0x200h, 0x240h, 0x280h, 0x300h, 0x340h, 0x380h. This I/O address must be reflected in the DIP -switiches of *all* of the Rocketport cards. +switches of *all* of the Rocketport cards. The second, third, and fourth RocketPort cards require a 64-byte contiguous block of I/O addresses, starting at one of the following @@ -107,7 +107,7 @@ second, third, and fourth Rocketport cards (if present) are set via software control. The DIP switch settings for the I/O address must be set to the value of the first Rocketport cards. -In order to destinguish each of the card from the others, each card +In order to distinguish each of the card from the others, each card must have a unique board ID set on the dip switches. The first Rocketport board must be set with the DIP switches corresponding to the first board, the second board must be set with the DIP switches @@ -120,7 +120,7 @@ conflict with any other cards in the system, including other RocketPort cards. Below, you will find a list of commonly used I/O address ranges which may be in use by other devices in your system. On a Linux system, "cat /proc/ioports" will also be helpful in -identifying what I/O addresses are being used by devics on your +identifying what I/O addresses are being used by devices on your system. Remember, the FIRST RocketPort uses 68 I/O addresses. So, if you set it diff --git a/Documentation/rpc-cache.txt b/Documentation/rpc-cache.txt index 5f757c8cf979..8a382bea6808 100644 --- a/Documentation/rpc-cache.txt +++ b/Documentation/rpc-cache.txt @@ -24,7 +24,7 @@ The common code handles such things as: - general cache lookup with correct locking - supporting 'NEGATIVE' as well as positive entries - allowing an EXPIRED time on cache items, and removing - items after they expire, and are no longe in-use. + items after they expire, and are no longer in-use. - making requests to user-space to fill in cache entries - allowing user-space to directly set entries in the cache - delaying RPC requests that depend on as-yet incomplete @@ -53,7 +53,7 @@ Creating a Cache structure void cache_put(struct kref *) This is called when the last reference to an item is - is dropped. The pointer passed is to the 'ref' field + dropped. The pointer passed is to the 'ref' field in the cache_head. cache_put should release any references create by 'cache_init' and, if CACHE_VALID is set, any references created by cache_update. diff --git a/Documentation/rt-mutex-design.txt b/Documentation/rt-mutex-design.txt index c472ffacc2f6..4b736d24da7a 100644 --- a/Documentation/rt-mutex-design.txt +++ b/Documentation/rt-mutex-design.txt @@ -333,11 +333,11 @@ cmpxchg is basically the following function performed atomically: unsigned long _cmpxchg(unsigned long *A, unsigned long *B, unsigned long *C) { - unsigned long T = *A; - if (*A == *B) { - *A = *C; - } - return T; + unsigned long T = *A; + if (*A == *B) { + *A = *C; + } + return T; } #define cmpxchg(a,b,c) _cmpxchg(&a,&b,&c) @@ -582,7 +582,7 @@ contention). try_to_take_rt_mutex is used every time the task tries to grab a mutex in the slow path. The first thing that is done here is an atomic setting of the "Has Waiters" flag of the mutex's owner field. Yes, this could really -be false, because if the the mutex has no owner, there are no waiters and +be false, because if the mutex has no owner, there are no waiters and the current task also won't have any waiters. But we don't have the lock yet, so we assume we are going to be a waiter. The reason for this is to play nice for those architectures that do have CMPXCHG. By setting this flag @@ -735,7 +735,7 @@ do have CMPXCHG, that check is done in the fast path, but it is still needed in the slow path too. If a waiter of a mutex woke up because of a signal or timeout between the time the owner failed the fast path CMPXCHG check and the grabbing of the wait_lock, the mutex may not have any waiters, thus the -owner still needs to make this check. If there are no waiters than the mutex +owner still needs to make this check. If there are no waiters then the mutex owner field is set to NULL, the wait_lock is released and nothing more is needed. diff --git a/Documentation/s390/3270.txt b/Documentation/s390/3270.txt index 0a044e647d2d..7a5c73a7ed7f 100644 --- a/Documentation/s390/3270.txt +++ b/Documentation/s390/3270.txt @@ -111,9 +111,7 @@ Here are the installation steps in detail: config3270.sh. Inspect the output script it produces, /tmp/mkdev3270, and then run that script. This will create the necessary character special device files and make the necessary - changes to /etc/inittab. If you have selected DEVFS, the driver - itself creates the device files, and /tmp/mkdev3270 only changes - /etc/inittab. + changes to /etc/inittab. Then notify /sbin/init that /etc/inittab has changed, by issuing the telinit command with the q operand: diff --git a/Documentation/s390/Debugging390.txt b/Documentation/s390/Debugging390.txt index 844c03fe7921..4dd25ee549e9 100644 --- a/Documentation/s390/Debugging390.txt +++ b/Documentation/s390/Debugging390.txt @@ -8,8 +8,8 @@ Overview of Document: ===================== This document is intended to give an good overview of how to debug -Linux for s/390 & z/Architecture it isn't intended as a complete reference & not a -tutorial on the fundamentals of C & assembly, it dosen't go into +Linux for s/390 & z/Architecture. It isn't intended as a complete reference & not a +tutorial on the fundamentals of C & assembly. It doesn't go into 390 IO in any detail. It is intended to complement the documents in the reference section below & any other worthwhile references you get. @@ -88,7 +88,7 @@ s/390 z/Architecture 0 0 Reserved ( must be 0 ) otherwise specification exception occurs. 1 1 Program Event Recording 1 PER enabled, - PER is used to facilititate debugging e.g. single stepping. + PER is used to facilitate debugging e.g. single stepping. 2-4 2-4 Reserved ( must be 0 ). @@ -163,7 +163,7 @@ s/390 z/Architecture 1 1 64 bit 32 1=31 bit addressing mode 0=24 bit addressing mode (for backward - compatibility ), linux always runs with this bit set to 1 + compatibility), linux always runs with this bit set to 1 33-64 Instruction address. 33-63 Reserved must be 0 @@ -188,7 +188,7 @@ Bytes 0-512 ( 200 hex ) on s/390 & 0-512,4096-4544,4604-5119 currently on z/Arch are used by the processor itself for holding such information as exception indications & entry points for exceptions. Bytes after 0xc00 hex are used by linux for per processor globals on s/390 & z/Architecture -( there is a gap on z/Architecure too currently between 0xc00 & 1000 which linux uses ). +( there is a gap on z/Architecture too currently between 0xc00 & 1000 which linux uses ). The closest thing to this on traditional architectures is the interrupt vector table. This is a good thing & does simplify some of the kernel coding however it means that we now cannot catch stray NULL pointers in the @@ -239,7 +239,7 @@ they go to 64 Bit. On 390 our limitations & strengths make us slightly different. For backward compatibility we are only allowed use 31 bits (2GB) -of our 32 bit addresses,however, we use entirely separate address +of our 32 bit addresses, however, we use entirely separate address spaces for the user & kernel. This means we can support 2GB of non Extended RAM on s/390, & more @@ -317,9 +317,9 @@ Each process/thread under Linux for S390 has its own kernel task_struct defined in linux/include/linux/sched.h The S390 on initialisation & resuming of a process on a cpu sets the __LC_KERNEL_STACK variable in the spare prefix area for this cpu -( which we use for per processor globals). +(which we use for per-processor globals). -The kernel stack pointer is intimately tied with the task stucture for +The kernel stack pointer is intimately tied with the task structure for each processor as follows. s/390 @@ -354,7 +354,7 @@ static inline struct task_struct * get_current(void) } i.e. just anding the current kernel stack pointer with the mask -8192. -Thankfully because Linux dosen't have support for nested IO interrupts +Thankfully because Linux doesn't have support for nested IO interrupts & our devices have large buffers can survive interrupts being shut for short amounts of time we don't need a separate stack for interrupts. @@ -366,8 +366,8 @@ Register Usage & Stackframes on Linux for s/390 & z/Architecture Overview: --------- This is the code that gcc produces at the top & the bottom of -each function, it usually is fairly consistent & similar from -function to function & if you know its layout you can probalby +each function. It usually is fairly consistent & similar from +function to function & if you know its layout you can probably make some headway in finding the ultimate cause of a problem after a crash without a source level debugger. @@ -394,7 +394,7 @@ i.e they aren't in registers & they aren't static. back-chain: This is a pointer to the stack pointer before entering a framed functions ( see frameless function ) prologue got by -deferencing the address of the current stack pointer, +dereferencing the address of the current stack pointer, i.e. got by accessing the 32 bit value at the stack pointers current location. @@ -724,7 +724,7 @@ This is useful for debugging because 1) You can double check whether the files you expect to be included are the ones that are being included ( e.g. double check that you aren't going to the i386 asm directory ). 2) Check that macro definitions aren't clashing with typedefs, -3) Check that definitons aren't being used before they are being included. +3) Check that definitions aren't being used before they are being included. 4) Helps put the line emitting the error under the microscope if it contains macros. For convenience the Linux kernel's makefile will do preprocessing automatically for you @@ -840,12 +840,11 @@ using the strip command to make it a more reasonable size to boot it. A source/assembly mixed dump of the kernel can be done with the line objdump --source vmlinux > vmlinux.lst -Also if the file isn't compiled -g this will output as much debugging information -as it can ( e.g. function names ), however, this is very slow as it spends lots -of time searching for debugging info, the following self explanitory line should be used -instead if the code isn't compiled -g. +Also, if the file isn't compiled -g, this will output as much debugging information +as it can (e.g. function names). This is very slow as it spends lots +of time searching for debugging info. The following self explanatory line should be used +instead if the code isn't compiled -g, as it is much faster: objdump --disassemble-all --syms vmlinux > vmlinux.lst -as it is much faster As hard drive space is valuble most of us use the following approach. 1) Look at the emitted psw on the console to find the crash address in the kernel. @@ -861,7 +860,7 @@ Linux source tree. 6) rm /arch/s390/kernel/signal.o 7) make /arch/s390/kernel/signal.o 8) watch the gcc command line emitted -9) type it in again or alernatively cut & paste it on the console adding the -g option. +9) type it in again or alternatively cut & paste it on the console adding the -g option. 10) objdump --source arch/s390/kernel/signal.o > signal.lst This will output the source & the assembly intermixed, as the snippet below shows This will unfortunately output addresses which aren't the same @@ -913,8 +912,8 @@ If you wanted to know does ping work but didn't have the source strace ping -c 1 127.0.0.1 & then look at the man pages for each of the syscalls below, ( In fact this is sometimes easier than looking at some spagetti -source which conditionally compiles for several architectures ) -Not everything that it throws out needs to make sense immeadiately +source which conditionally compiles for several architectures ). +Not everything that it throws out needs to make sense immediately. Just looking quickly you can see that it is making up a RAW socket for the ICMP protocol. @@ -974,8 +973,9 @@ through the pipe for each line containing the string open. Example 3 --------- -Getting sophistocated -telnetd crashes on & I don't know why +Getting sophisticated +telnetd crashes & I don't know why + Steps ----- 1) Replace the following line in /etc/inetd.conf @@ -1085,8 +1085,7 @@ Notes ----- Addresses & values in the VM debugger are always hex never decimal Address ranges are of the format <HexValue1>-<HexValue2> or <HexValue1>.<HexValue2> -e.g. The address range 0x2000 to 0x3000 can be described described as -2000-3000 or 2000.1000 +e.g. The address range 0x2000 to 0x3000 can be described as 2000-3000 or 2000.1000 The VM Debugger is case insensitive. @@ -1311,7 +1310,7 @@ for finding out when a particular variable changes. An alternative way of finding the STD of a currently running process is to do the following, ( this method is more complex but -could be quite convient if you aren't updating the kernel much & +could be quite convenient if you aren't updating the kernel much & so your kernel structures will stay constant for a reasonable period of time ). @@ -1413,7 +1412,7 @@ SMP Specific commands To find out how many cpus you have Q CPUS displays all the CPU's available to your virtual machine To find the cpu that the current cpu VM debugger commands are being directed at do -Q CPU to change the current cpu cpu VM debugger commands are being directed at do +Q CPU to change the current cpu VM debugger commands are being directed at do CPU <desired cpu no> On a SMP guest issue a command to all CPUs try prefixing the command with cpu all. @@ -1674,8 +1673,8 @@ channel is idle & the second for device end ( secondary status ) sometimes you g concurrently, you check how the IO went on by issuing a TEST SUBCHANNEL at each interrupt, from which you receive an Interruption response block (IRB). If you get channel & device end status in the IRB without channel checks etc. your IO probably went okay. If you didn't you -probably need a doctorto examine the IRB & extended status word etc. -If an error occurs more sophistocated control units have a facitity known as +probably need a doctor to examine the IRB & extended status word etc. +If an error occurs, more sophistocated control units have a facitity known as concurrent sense this means that if an error occurs Extended sense information will be presented in the Extended status word in the IRB if not you have to issue a subsequent SENSE CCW command after the test subchannel. @@ -1704,7 +1703,7 @@ concentrate on data processing. IOP's can use one or more links ( known as channel paths ) to talk to each IO device. It first checks for path availability & chooses an available one, then starts ( & sometimes terminates IO ). -There are two types of channel path ESCON & the Paralell IO interface. +There are two types of channel path: ESCON & the Parallel IO interface. IO devices are attached to control units, control units provide the logic to interface the channel paths & channel path IO protocols to @@ -1743,11 +1742,11 @@ controllers or a control unit which connects to 1000 3270 terminals ). The 390 IO systems come in 2 flavours the current 390 machines support both -The Older 360 & 370 Interface,sometimes called the paralell I/O interface, +The Older 360 & 370 Interface,sometimes called the Parallel I/O interface, sometimes called Bus-and Tag & sometimes Original Equipment Manufacturers Interface (OEMI). -This byte wide paralell channel path/bus has parity & data on the "Bus" cable +This byte wide Parallel channel path/bus has parity & data on the "Bus" cable & control lines on the "Tag" cable. These can operate in byte multiplex mode for sharing between several slow devices or burst mode & monopolize the channel for the whole burst. Upto 256 devices can be addressed on one of these cables. These cables are @@ -1777,7 +1776,7 @@ Consoles 3270 & 3215 ( a teletype emulated under linux for a line mode console ) DASD's direct access storage devices ( otherwise known as hard disks ). Tape Drives. CTC ( Channel to Channel Adapters ), -ESCON or Paralell Cables used as a very high speed serial link +ESCON or Parallel Cables used as a very high speed serial link between 2 machines. We use 2 cables under linux to do a bi-directional serial link. @@ -1803,8 +1802,8 @@ OSA 7C09 ON OSA 7C09 SUBCHANNEL = 0001 OSA 7C14 ON OSA 7C14 SUBCHANNEL = 0002 OSA 7C15 ON OSA 7C15 SUBCHANNEL = 0003 -If you have a guest with certain priviliges you may be able to see devices -which don't belong to you to avoid this do add the option V. +If you have a guest with certain privileges you may be able to see devices +which don't belong to you. To avoid this, add the option V. e.g. Q V OSA @@ -1837,7 +1836,7 @@ RDRLIST RECEIVE / LOG TXT A1 ( replace 8) filel & press F11 to look at it -You should see someting like. +You should see something like: 00020942' SSCH B2334000 0048813C CC 0 SCH 0000 DEV 7C08 CPA 000FFDF0 PARM 00E2C9C4 KEY 0 FPI C0 LPM 80 @@ -1916,7 +1915,7 @@ Assembly -------- info registers: displays registers other than floating point. info all-registers: displays floating points as well. -disassemble: dissassembles +disassemble: disassembles e.g. disassemble without parameters will disassemble the current function disassemble $pc $pc+10 @@ -1935,7 +1934,7 @@ undisplay : undo's display's info breakpoints: shows all current breakpoints -info stack: shows stack back trace ( if this dosent work too well, I'll show you the +info stack: shows stack back trace ( if this doesn't work too well, I'll show you the stacktrace by hand below ). info locals: displays local variables. @@ -2045,13 +2044,13 @@ what gdb does when the victim receives certain signals. list: e.g. list lists current function source -list 1,10 list first 10 lines of curret file. +list 1,10 list first 10 lines of current file. list test.c:1,10 directory: Adds directories to be searched for source if gdb cannot find the source. -(note it is a bit sensititive about slashes ) +(note it is a bit sensititive about slashes) e.g. To add the root of the filesystem to the searchpath do directory // @@ -2123,9 +2122,9 @@ p/x (*(**$sp+56))&0x7fffffff Disassembling instructions without debug info --------------------------------------------- -gdb typically compains if there is a lack of debugging -symbols in the disassemble command with -"No function contains specified address." to get around +gdb typically complains if there is a lack of debugging +symbols in the disassemble command with +"No function contains specified address." To get around this do x/<number lines to disassemble>xi <address> e.g. @@ -2184,7 +2183,7 @@ ps -aux | grep gdb kill -SIGSEGV <gdb's pid> or alternatively use killall -SIGSEGV gdb if you have the killall command. Now look at the core dump. -./gdb ./gdb core +./gdb core Displays the following GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. @@ -2316,7 +2315,7 @@ Showing us the shared libraries init uses where they are in memory /proc/1/mem is the current running processes memory which you can read & write to like a file. strace uses this sometimes as it is a bit faster than the -rather inefficent ptrace interface for peeking at DATA. +rather inefficient ptrace interface for peeking at DATA. cat status @@ -2446,7 +2445,7 @@ displays the following lines as it executes them. + RELSTATUS=release + MACHTYPE=i586-pc-linux-gnu -perl -d <scriptname> runs the perlscript in a fully intercative debugger +perl -d <scriptname> runs the perlscript in a fully interactive debugger <like gdb>. Type 'h' in the debugger for help. @@ -2477,7 +2476,7 @@ Lcrash is a perfectly normal program,however, it requires 2 additional files, Kerntypes which is built using a patch to the linux kernel sources in the linux root directory & the System.map. -Kerntypes is an an objectfile whose sole purpose in life +Kerntypes is an objectfile whose sole purpose in life is to provide stabs debug info to lcrash, to do this Kerntypes is built from kerntypes.c which just includes the most commonly referenced header files used when debugging, lcrash can then read the diff --git a/Documentation/s390/cds.txt b/Documentation/s390/cds.txt index f0be389c7116..d80e5733827d 100644 --- a/Documentation/s390/cds.txt +++ b/Documentation/s390/cds.txt @@ -133,7 +133,7 @@ determine the device driver owning the device that raised the interrupt. In order not to introduce a new I/O concept to the common Linux code, Linux/390 preserves the IRQ concept and semantically maps the ESA/390 subchannels to Linux as IRQs. This allows Linux/390 to support up to 64k -different IRQs, uniquely representig a single device each. +different IRQs, uniquely representing a single device each. Up to kernel 2.4, Linux/390 used to provide interfaces via the IRQ (subchannel). For internal use of the common I/O layer, these are still there. However, @@ -143,7 +143,7 @@ During its startup the Linux/390 system checks for peripheral devices. Each of those devices is uniquely defined by a so called subchannel by the ESA/390 channel subsystem. While the subchannel numbers are system generated, each subchannel also takes a user defined attribute, the so called device number. -Both subchannel number and device number can not exceed 65535. During driverfs +Both subchannel number and device number cannot exceed 65535. During driverfs initialisation, the information about control unit type and device types that imply specific I/O commands (channel command words - CCWs) in order to operate the device are gathered. Device drivers can retrieve this set of hardware @@ -177,11 +177,11 @@ This routine returns the characteristics for the device specified. The function is meant to be called with an irq handler in place; that is, at earliest during set_online() processing. -While the request is procesed synchronously, the device interrupt +While the request is processed synchronously, the device interrupt handler is called for final ending status. In case of error situations the interrupt handler may recover appropriately. The device irq handler can recognize the corresponding interrupts by the interruption parameter be -0x00524443.The ccw_device must not be locked prior to calling read_dev_chars(). +0x00524443. The ccw_device must not be locked prior to calling read_dev_chars(). The function may be called enabled or disabled. @@ -325,7 +325,7 @@ with the following CCW flags values defined : CCW_FLAG_DC - data chaining CCW_FLAG_CC - command chaining -CCW_FLAG_SLI - suppress incorrct length +CCW_FLAG_SLI - suppress incorrect length CCW_FLAG_SKIP - skip CCW_FLAG_PCI - PCI CCW_FLAG_IDA - indirect addressing @@ -348,7 +348,7 @@ The ccw_device_start() function returns : not online. When the I/O request completes, the CDS first level interrupt handler will -accumalate the status in a struct irb and then call the device interrupt handler. +accumulate the status in a struct irb and then call the device interrupt handler. The intparm field will contain the value the device driver has associated with a particular I/O request. If a pending device status was recognized, intparm will be set to 0 (zero). This may happen during I/O initiation or delayed @@ -433,7 +433,7 @@ puts the CPU into I/O disabled state by preserving the current PSW flags. The device driver is allowed to issue the next ccw_device_start() call from within its interrupt handler already. It is not required to schedule a -bottom-half, unless an non deterministicly long running error recovery procedure +bottom-half, unless an non deterministically long running error recovery procedure or similar needs to be scheduled. During I/O processing the Linux/390 generic I/O device driver support has already obtained the IRQ lock, i.e. the handler must not try to obtain it again when calling ccw_device_start() or we end in a diff --git a/Documentation/s390/crypto/crypto-API.txt b/Documentation/s390/crypto/crypto-API.txt index 78a77624a716..29dee792c887 100644 --- a/Documentation/s390/crypto/crypto-API.txt +++ b/Documentation/s390/crypto/crypto-API.txt @@ -61,9 +61,9 @@ Example: z990 crypto instruction for SHA1 algorithm is available -> when the sha1 algorithm is requested through the crypto API (which has a module autoloader) the z990 module will be loaded. -TBD: a userspace module probin mechanism +TBD: a userspace module probing mechanism something like 'probe sha1 sha1_z990 sha1' in modprobe.conf - -> try module sha1_z990, if it fails to load load standard module sha1 + -> try module sha1_z990, if it fails to load standard module sha1 the 'probe' statement is currently not supported in modprobe.conf diff --git a/Documentation/s390/driver-model.txt b/Documentation/s390/driver-model.txt index efb674eda4d4..62c082387aea 100644 --- a/Documentation/s390/driver-model.txt +++ b/Documentation/s390/driver-model.txt @@ -157,7 +157,7 @@ notify: This function is called by the common I/O layer for some state changes * In online state, device detached (CIO_GONE) or last path gone (CIO_NO_PATH). The driver must return !0 to keep the device; for return code 0, the device will be deleted as usual (also when no - notify function is registerd). If the driver wants to keep the + notify function is registered). If the driver wants to keep the device, it is moved into disconnected state. * In disconnected state, device operational again (CIO_OPER). The common I/O layer performs some sanity checks on device number and @@ -262,7 +262,7 @@ attribute 'online' which can be 0 or 1. ----------- The netiucv driver creates an attribute 'connection' under -bus/iucv/drivers/netiucv. Piping to this attibute creates a new netiucv +bus/iucv/drivers/netiucv. Piping to this attribute creates a new netiucv connection to the specified host. Netiucv connections show up under devices/iucv/ as "netiucv<ifnum>". The interface diff --git a/Documentation/s390/monreader.txt b/Documentation/s390/monreader.txt index d843bb04906e..beeaa4b24427 100644 --- a/Documentation/s390/monreader.txt +++ b/Documentation/s390/monreader.txt @@ -83,7 +83,7 @@ This loads the module and sets the DCSS name to "MYDCSS". NOTE: ----- -This API provides no interface to control the *MONITOR service, e.g. specifiy +This API provides no interface to control the *MONITOR service, e.g. specify which data should be collected. This can be done by the CP command MONITOR (Class E privileged), see "CP Command and Utility Reference". diff --git a/Documentation/s390/s390dbf.txt b/Documentation/s390/s390dbf.txt index e321a8ed2a2d..000230cd26db 100644 --- a/Documentation/s390/s390dbf.txt +++ b/Documentation/s390/s390dbf.txt @@ -11,7 +11,7 @@ where log records can be stored efficiently in memory, where each component (e.g. device drivers) can have one separate debug log. One purpose of this is to inspect the debug logs after a production system crash in order to analyze the reason for the crash. -If the system still runs but only a subcomponent which uses dbf failes, +If the system still runs but only a subcomponent which uses dbf fails, it is possible to look at the debug logs on a live system via the Linux debugfs filesystem. The debug feature may also very useful for kernel and driver development. @@ -65,7 +65,7 @@ Predefined views for hex/ascii, sprintf and raw binary data are provided. It is also possible to define other views. The content of a view can be inspected simply by reading the corresponding debugfs file. -All debug logs have an an actual debug level (range from 0 to 6). +All debug logs have an actual debug level (range from 0 to 6). The default level is 3. Event and Exception functions have a 'level' parameter. Only debug entries with a level that is lower or equal than the actual level are written to the log. This means, when @@ -83,8 +83,8 @@ Example: It is also possible to deactivate the debug feature globally for every debug log. You can change the behavior using 2 sysctl parameters in /proc/sys/s390dbf: -There are currently 2 possible triggers, which stop the debug feature -globally. The first possbility is to use the "debug_active" sysctl. If +There are currently 2 possible triggers, which stop the debug feature +globally. The first possibility is to use the "debug_active" sysctl. If set to 1 the debug feature is running. If "debug_active" is set to 0 the debug feature is turned off. The second trigger which stops the debug feature is an kernel oops. @@ -468,7 +468,7 @@ The hex_ascii view shows the data field in hex and ascii representation The raw view returns a bytestream as the debug areas are stored in memory. The sprintf view formats the debug entries in the same way as the sprintf -function would do. The sprintf event/expection functions write to the +function would do. The sprintf event/exception functions write to the debug entry a pointer to the format string (size = sizeof(long)) and for each vararg a long value. So e.g. for a debug entry with a format string plus two varargs one would need to allocate a (3 * sizeof(long)) @@ -556,7 +556,7 @@ The input_proc can be used to implement functionality when it is written to the view (e.g. like with 'echo "0" > /sys/kernel/debug/s390dbf/dasd/level). For header_proc there can be used the default function -debug_dflt_header_fn() which is defined in in debug.h. +debug_dflt_header_fn() which is defined in debug.h. and which produces the same header output as the predefined views. E.g: 00 00964419409:440761 2 - 00 88023ec diff --git a/Documentation/sched-coding.txt b/Documentation/sched-coding.txt index 2b75ef67c9fe..cbd8db752acf 100644 --- a/Documentation/sched-coding.txt +++ b/Documentation/sched-coding.txt @@ -15,7 +15,7 @@ Main Scheduling Methods void load_balance(runqueue_t *this_rq, int idle) Attempts to pull tasks from one cpu to another to balance cpu usage, if needed. This method is called explicitly if the runqueues are - inbalanced or periodically by the timer tick. Prior to calling, + imbalanced or periodically by the timer tick. Prior to calling, the current runqueue must be locked and interrupts disabled. void schedule() diff --git a/Documentation/sched-design.txt b/Documentation/sched-design.txt index 9d04e7bbf45f..1605bf0cba8b 100644 --- a/Documentation/sched-design.txt +++ b/Documentation/sched-design.txt @@ -93,9 +93,9 @@ and the goal is also to add a few new things: Design ====== -the core of the new scheduler are the following mechanizms: +The core of the new scheduler contains the following mechanisms: - - *two*, priority-ordered 'priority arrays' per CPU. There is an 'active' + - *two* priority-ordered 'priority arrays' per CPU. There is an 'active' array and an 'expired' array. The active array contains all tasks that are affine to this CPU and have timeslices left. The expired array contains all tasks which have used up their timeslices - but this array diff --git a/Documentation/scsi/ChangeLog.1992-1997 b/Documentation/scsi/ChangeLog.1992-1997 index dc88ee2ab73d..6faad7e6417c 100644 --- a/Documentation/scsi/ChangeLog.1992-1997 +++ b/Documentation/scsi/ChangeLog.1992-1997 @@ -1214,7 +1214,7 @@ Thu Jul 21 10:37:39 1994 Eric Youngdale (eric@esp22) * sr.c(sr_open): Do not allow opens with write access. -Mon Jul 18 09:51:22 1994 1994 Eric Youngdale (eric@esp22) +Mon Jul 18 09:51:22 1994 Eric Youngdale (eric@esp22) * Linux 1.1.31 released. diff --git a/Documentation/scsi/NinjaSCSI.txt b/Documentation/scsi/NinjaSCSI.txt index 041780f428ac..3229b64cf24e 100644 --- a/Documentation/scsi/NinjaSCSI.txt +++ b/Documentation/scsi/NinjaSCSI.txt @@ -24,7 +24,7 @@ SCSI device: I-O data CDPS-PX24 (CD-ROM drive) You can also use "cardctl" program (this program is in pcmcia-cs source code) to get more info. -# cat /var/log/messgaes +# cat /var/log/messages ... Jan 2 03:45:06 lindberg cardmgr[78]: unsupported card in socket 1 Jan 2 03:45:06 lindberg cardmgr[78]: product info: "WBT", "NinjaSCSI-3", "R1.0" @@ -36,18 +36,18 @@ Socket 1: product info: "IO DATA", "CBSC16 ", "1" -[2] Get Linux kernel source, and extract it to /usr/src. - Because NinjaSCSI driver requiers some SCSI header files in Linux kernel - source. - I recomend rebuilding your kernel. This eliminate some versioning problem. +[2] Get the Linux kernel source, and extract it to /usr/src. + Because the NinjaSCSI driver requires some SCSI header files in Linux + kernel source, I recommend rebuilding your kernel; this eliminates + some versioning problems. $ cd /usr/src $ tar -zxvf linux-x.x.x.tar.gz $ cd linux $ make config ... -[3] If you use this driver with Kernel 2.2, Unpack pcmcia-cs in some directory - and make & install. This driver requies pcmcia-cs header file. +[3] If you use this driver with Kernel 2.2, unpack pcmcia-cs in some directory + and make & install. This driver requires the pcmcia-cs header file. $ cd /usr/src $ tar zxvf cs-pcmcia-cs-3.x.x.tar.gz ... @@ -59,10 +59,10 @@ $ emacs Makefile ... $ make -[5] Copy nsp_cs.o to suitable plase, like /lib/modules/<Kernel version>/pcmcia/ . +[5] Copy nsp_cs.ko to suitable place, like /lib/modules/<Kernel version>/pcmcia/ . [6] Add these lines to /etc/pcmcia/config . - If you yse pcmcia-cs-3.1.8 or later, we can use "nsp_cs.conf" file. + If you use pcmcia-cs-3.1.8 or later, we can use "nsp_cs.conf" file. So, you don't need to edit file. Just copy to /etc/pcmcia/ . ------------------------------------- diff --git a/Documentation/scsi/aacraid.txt b/Documentation/scsi/aacraid.txt index ee03678c8029..3367130e64f6 100644 --- a/Documentation/scsi/aacraid.txt +++ b/Documentation/scsi/aacraid.txt @@ -4,7 +4,7 @@ Introduction ------------------------- The aacraid driver adds support for Adaptec (http://www.adaptec.com) RAID controllers. This is a major rewrite from the original -Adaptec supplied driver. It has signficantly cleaned up both the code +Adaptec supplied driver. It has significantly cleaned up both the code and the running binary size (the module is less than half the size of the original). diff --git a/Documentation/scsi/aic79xx.txt b/Documentation/scsi/aic79xx.txt index 382b439b439e..904d49e90ef2 100644 --- a/Documentation/scsi/aic79xx.txt +++ b/Documentation/scsi/aic79xx.txt @@ -81,7 +81,7 @@ The following information is available in this file: an SDTR with an offset of 0 to be sure the target knows we are async. This works around a firmware defect in the Quantum Atlas 10K. - - Implement controller susupend and resume. + - Implement controller suspend and resume. - Clear PCI error state during driver attach so that we don't disable memory mapped I/O due to a stray write by some other driver probe that occurred before we @@ -94,7 +94,7 @@ The following information is available in this file: - Add support for scsi_report_device_reset() found in 2.5.X kernels. - Add 7901B support. - - Simplify handling of the packtized lun Rev A workaround. + - Simplify handling of the packetized lun Rev A workaround. - Correct and simplify handling of the ignore wide residue message. The previous code would fail to report a residual if the transaction data length was even and we received diff --git a/Documentation/scsi/aic7xxx.txt b/Documentation/scsi/aic7xxx.txt index 3481fcded4c2..9b894f116d95 100644 --- a/Documentation/scsi/aic7xxx.txt +++ b/Documentation/scsi/aic7xxx.txt @@ -160,7 +160,7 @@ The following information is available in this file: 6.2.34 (May 5th, 2003) - Fix locking regression instroduced in 6.2.29 that - could cuase a lock order reversal between the io_request_lock + could cause a lock order reversal between the io_request_lock and our per-softc lock. This was only possible on RH9, SuSE, and kernel.org 2.4.X kernels. diff --git a/Documentation/scsi/aic7xxx_old.txt b/Documentation/scsi/aic7xxx_old.txt index 79e5ac6cb6ff..c92f4473193b 100644 --- a/Documentation/scsi/aic7xxx_old.txt +++ b/Documentation/scsi/aic7xxx_old.txt @@ -102,7 +102,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD The hardware RAID devices sold by Adaptec are *NOT* supported by this driver (and will people please stop emailing me about them, they are a totally separate beast from the bare SCSI controllers and this driver - can not be retrofitted in any sane manner to support the hardware RAID + cannot be retrofitted in any sane manner to support the hardware RAID features on those cards - Doug Ledford). @@ -241,7 +241,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD that instead of dumping the register contents on the card, this option dumps the contents of the sequencer program RAM. This gives the ability to verify that the instructions downloaded to the - card's sequencer are indeed what they are suppossed to be. Again, + card's sequencer are indeed what they are supposed to be. Again, unless you have documentation to tell you how to interpret these numbers, then it is totally useless. @@ -317,7 +317,7 @@ linux-1.1.x and fairly stable since linux-1.2.x, and are also in FreeBSD initial DEVCONFIG values for each of your aic7xxx controllers as they are listed, and also record what the machine is detecting as the proper termination on your controllers. NOTE: the order in - which the initial DEVCONFIG values are printed out is not gauranteed + which the initial DEVCONFIG values are printed out is not guaranteed to be the same order as the SCSI controllers are registered. The above option and this option both work on the order of the SCSI controllers as they are registered, so make sure you match the right diff --git a/Documentation/scsi/dc395x.txt b/Documentation/scsi/dc395x.txt index ae3b79a2d275..88219f96633d 100644 --- a/Documentation/scsi/dc395x.txt +++ b/Documentation/scsi/dc395x.txt @@ -20,7 +20,7 @@ Parameters ---------- The driver uses the settings from the EEPROM set in the SCSI BIOS setup. If there is no EEPROM, the driver uses default values. -Both can be overriden by command line parameters (module or kernel +Both can be overridden by command line parameters (module or kernel parameters). The following parameters are available: diff --git a/Documentation/scsi/dpti.txt b/Documentation/scsi/dpti.txt index 6e45e70243e5..f36dc0e7c8da 100644 --- a/Documentation/scsi/dpti.txt +++ b/Documentation/scsi/dpti.txt @@ -48,7 +48,7 @@ * Implemented suggestions from Alan Cox * Added calculation of resid for sg layer * Better error handling - * Added checking underflow condtions + * Added checking underflow conditions * Added DATAPROTECT checking * Changed error return codes * Fixed pointer bug in bus reset routine diff --git a/Documentation/scsi/ibmmca.txt b/Documentation/scsi/ibmmca.txt index d16ce5b540f4..35f6b8ed2295 100644 --- a/Documentation/scsi/ibmmca.txt +++ b/Documentation/scsi/ibmmca.txt @@ -229,7 +229,7 @@ In a second step of the driver development, the following improvement has been applied: The first approach limited the number of devices to 7, far - fewer than the 15 that it could usem then it just maped ldn -> + fewer than the 15 that it could use, then it just mapped ldn -> (ldn/8,ldn%8) for pun,lun. We ended up with a real mishmash of puns and luns, but it all seemed to work. @@ -254,12 +254,12 @@ device to be existant, but it has no ldn assigned, it gets a ldn out of 7 to 14. The numbers are assigned in cyclic order. Therefore it takes 8 dynamical reassignments on the SCSI-devices, until a certain device - loses its ldn again. This assures, that dynamical remapping is avoided + loses its ldn again. This assures that dynamical remapping is avoided during intense I/O between up to 15 SCSI-devices (means pun,lun - combinations). A further advantage of this method is, that people who + combinations). A further advantage of this method is that people who build their kernel without probing on all luns will get what they expect, because the driver just won't assign everything with lun>0 when - multpile lun probing is inactive. + multiple lun probing is inactive. 2.4 SCSI-Device Order --------------------- @@ -309,9 +309,9 @@ 2.6 Abort & Reset Commands -------------------------- These are implemented with busy waiting for interrupt to arrive. - ibmmca_reset() and ibmmca_abort() do not work sufficently well - up to now and need still a lot of development work. But, this seems - to be even a problem with other SCSI-low level drivers, too. However, + ibmmca_reset() and ibmmca_abort() do not work sufficiently well + up to now and need still a lot of development work. This seems + to be a problem with other low-level SCSI drivers too, however this should be no excuse. 2.7 Disk Geometry @@ -684,8 +684,8 @@ not like sending commands to non-existing SCSI-devices and will react with a command error as a sign of protest. While this error is not present on IBM SCSI Adapter w/cache, it appears on IBM Integrated SCSI - Adapters. Therefore, I implemented a workarround to forgive those - adapters their protests, but it is marked up in the statisctis, so + Adapters. Therefore, I implemented a workaround to forgive those + adapters their protests, but it is marked up in the statistics, so after a successful boot, you can see in /proc/scsi/ibmmca/<host_number> how often the command errors have been forgiven to the SCSI-subsystem. If the number is bigger than 0, you have a SCSI subsystem of older @@ -778,15 +778,15 @@ not accept this, as they stick quite near to ANSI-SCSI and report a COMMAND_ERROR message which causes the driver to panic. The main problem was located around the INQUIRY command. Now, for all the - mentioned commands, the buffersize, sent to the adapter is at + mentioned commands, the buffersize sent to the adapter is at maximum 255 which seems to be a quite reasonable solution. - TEST_UNIT_READY gets a buffersize of 0 to make sure, that no + TEST_UNIT_READY gets a buffersize of 0 to make sure that no data is transferred in order to avoid any possible command failure. - 2) On unsuccessful TEST_UNIT_READY, the midlevel-driver has to send - a REQUEST_SENSE in order to see, where the problem is located. This + 2) On unsuccessful TEST_UNIT_READY, the mid-level driver has to send + a REQUEST_SENSE in order to see where the problem is located. This REQUEST_SENSE may have various length in its answer-buffer. IBM - SCSI-subsystems report a command failure, if the returned buffersize - is different from the sent buffersize, but this can be supressed by + SCSI-subsystems report a command failure if the returned buffersize + is different from the sent buffersize, but this can be suppressed by a special bit, which is now done and problems seem to be solved. 2) Code adaption to all kernel-releases. Now, the 3.2 code compiles on 2.0.x, 2.1.x, 2.2.x and 2.3.x kernel releases without any code-changes. @@ -1086,7 +1086,7 @@ Q: "Reset SCSI-devices at boottime" halts the system at boottime, why? A: This is only tested with the IBM SCSI Adapter w/cache. It is not - yet prooved to run on other adapters, however you may be lucky. + yet proven to run on other adapters, however you may be lucky. In version 3.1d this has been hugely improved and should work better, now. Normally you really won't need to activate this flag in the kernel configuration, as all post 1989 SCSI-devices should accept @@ -1104,7 +1104,7 @@ The parameter 'normal' sets the new industry standard, starting from pun 0, scanning up to pun 6. This allows you to change your opinion still after having already compiled the kernel. - Q: Why I cannot find the IBM MCA SCSI support in the config menue? + Q: Why can't I find IBM MCA SCSI support in the config menu? A: You have to activate MCA bus support, first. Q: Where can I find the latest info about this driver? A: See the file MAINTAINERS for the current WWW-address, which offers @@ -1156,7 +1156,7 @@ Guide) what has to be done for reset, we still share the bad shape of the reset functions with all other low level SCSI-drivers. Astonishingly, reset works in most cases quite ok, but the harddisks - won't run in synchonous mode anymore after a reset, until you reboot. + won't run in synchronous mode anymore after a reset, until you reboot. Q: Why does my XXX w/Cache adapter not use read-prefetch? A: Ok, that is not completely possible. If a cache is present, the adapter tries to use it internally. Explicitly, one can use the cache diff --git a/Documentation/scsi/megaraid.txt b/Documentation/scsi/megaraid.txt index ff864c0f494c..3c7cea51e687 100644 --- a/Documentation/scsi/megaraid.txt +++ b/Documentation/scsi/megaraid.txt @@ -4,11 +4,11 @@ Overview: -------- -Different classes of controllers from LSI Logic, accept and respond to the +Different classes of controllers from LSI Logic accept and respond to the user applications in a similar way. They understand the same firmware control commands. Furthermore, the applications also can treat different classes of the controllers uniformly. Hence it is logical to have a single module that -interefaces with the applications on one side and all the low level drivers +interfaces with the applications on one side and all the low level drivers on the other. The advantages, though obvious, are listed for completeness: diff --git a/Documentation/scsi/ncr53c8xx.txt b/Documentation/scsi/ncr53c8xx.txt index 822d2aca3700..58ad8db333d9 100644 --- a/Documentation/scsi/ncr53c8xx.txt +++ b/Documentation/scsi/ncr53c8xx.txt @@ -70,7 +70,7 @@ Written by Gerard Roudier <groudier@free.fr> 15. SCSI problem troubleshooting 15.1 Problem tracking 15.2 Understanding hardware error reports -16. Synchonous transfer negotiation tables +16. Synchronous transfer negotiation tables 16.1 Synchronous timings for 53C875 and 53C860 Ultra-SCSI controllers 16.2 Synchronous timings for fast SCSI-2 53C8XX controllers 17. Serial NVRAM support (by Richard Waltham) @@ -96,10 +96,10 @@ The original driver has been written for 386bsd and FreeBSD by: It is now available as a bundle of 2 drivers: - ncr53c8xx generic driver that supports all the SYM53C8XX family including - the ealiest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and + the earliest 810 rev. 1, the latest 896 (2 channel LVD SCSI controller) and the new 895A (1 channel LVD SCSI controller). - sym53c8xx enhanced driver (a.k.a. 896 drivers) that drops support of oldest - chips in order to gain advantage of new features, as LOAD/STORE intructions + chips in order to gain advantage of new features, as LOAD/STORE instructions available since the 810A and hardware phase mismatch available with the 896 and the 895A. @@ -207,7 +207,7 @@ The 896 and the 895A allows handling of the phase mismatch context from SCRIPTS (avoids the phase mismatch interrupt that stops the SCSI processor until the C code has saved the context of the transfer). Implementing this without using LOAD/STORE instructions would be painfull -and I did'nt even want to try it. +and I didn't even want to try it. The 896 chip supports 64 bit PCI transactions and addressing, while the 895A supports 32 bit PCI transactions and 64 bit addressing. @@ -631,8 +631,8 @@ string variable using 'insmod'. A boot setup command for the ncr53c8xx (sym53c8xx) driver begins with the driver name "ncr53c8xx="(sym53c8xx). The kernel syntax parser then expects -an optionnal list of integers separated with comma followed by an optional -list of comma-separated strings. Example of boot setup command under lilo +an optional list of integers separated with comma followed by an optional +list of comma-separated strings. Example of boot setup command under lilo prompt: lilo: linux root=/dev/hda2 ncr53c8xx=tags:4,sync:10,debug:0x200 @@ -778,7 +778,7 @@ port address 0x1400. Some scsi boards use a 875 (ultra wide) and only supply narrow connectors. If you have connected a wide device with a 50 pins to 68 pins cable converter, any accepted wide negotiation will break further data transfers. - In such a case, using "wide:0" in the bootup command will be helpfull. + In such a case, using "wide:0" in the bootup command will be helpful. 10.2.14 Differential mode diff:0 never set up diff mode @@ -899,7 +899,7 @@ boot setup can be: ncr53c8xx=safe:y,mpar:y ncr53c8xx=safe:y -My personnal system works flawlessly with the following equivalent setup: +My personal system works flawlessly with the following equivalent setup: ncr53c8xx=mpar:y,spar:y,disc:y,specf:1,fsn:n,ultra:2,fsn:n,revprob:n,verb:1\ tags:32,sync:12,debug:0,burst:7,led:1,wide:1,settle:2,diff:0,irqm:0 @@ -1151,7 +1151,7 @@ Driver files: New driver versions are made available separately in order to allow testing changes and new features prior to including them into the linux kernel -distribution. The following URL provides informations on latest avalaible +distribution. The following URL provides information on latest available patches: ftp://ftp.tux.org/pub/people/gerard-roudier/README @@ -1382,7 +1382,7 @@ SCSI standards, chip cores functionnals and internal driver data structures. You are not required to decode and understand them, unless you want to help maintain the driver code. -16. Synchonous transfer negotiation tables +16. Synchronous transfer negotiation tables Tables below have been created by calling the routine the driver uses for synchronisation negotiation timing calculation and chip setting. diff --git a/Documentation/scsi/osst.txt b/Documentation/scsi/osst.txt index ce574e7791ab..f536907e241d 100644 --- a/Documentation/scsi/osst.txt +++ b/Documentation/scsi/osst.txt @@ -56,8 +56,7 @@ Compile your kernel and install the modules. Now, your osst driver is inside the kernel or available as a module, depending on your choice during kernel config. You may still need to create -the device nodes by calling the Makedevs.sh script (see below) manually, -unless you use a devfs kernel, where this won't be needed. +the device nodes by calling the Makedevs.sh script (see below) manually. To load your module, you may use the command modprobe osst diff --git a/Documentation/scsi/ppa.txt b/Documentation/scsi/ppa.txt index 5d9223bc1bd5..067ac394e0b2 100644 --- a/Documentation/scsi/ppa.txt +++ b/Documentation/scsi/ppa.txt @@ -3,7 +3,7 @@ General Iomega ZIP drive page for Linux: http://www.torque.net/~campbell/ -Driver achive for old drivers: +Driver archive for old drivers: http://www.torque.net/~campbell/ppa/ Linux Parport page (parallel port) diff --git a/Documentation/scsi/scsi-changer.txt b/Documentation/scsi/scsi-changer.txt index c132687b017a..d74bbd29eb3a 100644 --- a/Documentation/scsi/scsi-changer.txt +++ b/Documentation/scsi/scsi-changer.txt @@ -31,7 +31,7 @@ changers. But it allows to handle nearly all possible cases. It knows media transport - this one shuffles around the media, i.e. the transport arm. Also known as "picker". storage - a slot which can hold a media. - import/export - the same as above, but is accessable from outside, + import/export - the same as above, but is accessible from outside, i.e. there the operator (you !) can use this to fill in and remove media from the changer. Sometimes named "mailslot". diff --git a/Documentation/scsi/scsi_eh.txt b/Documentation/scsi/scsi_eh.txt index ce767b90bb0d..b964eef2f62f 100644 --- a/Documentation/scsi/scsi_eh.txt +++ b/Documentation/scsi/scsi_eh.txt @@ -160,7 +160,7 @@ ways. - Fine-grained EH callbacks LLDD can implement fine-grained EH callbacks and let SCSI midlayer drive error handling and call appropriate callbacks. - This will be dicussed further in [2-1]. + This will be discussed further in [2-1]. - eh_strategy_handler() callback This is one big callback which should perform whole error @@ -194,7 +194,7 @@ lower layers and lower layers are ready to process or fail the scmd again. To achieve these goals, EH performs recovery actions with increasing -severity. Some actions are performed by issueing SCSI commands and +severity. Some actions are performed by issuing SCSI commands and others are performed by invoking one of the following fine-grained hostt EH callbacks. Callbacks may be omitted and omitted ones are considered to fail always. diff --git a/Documentation/scsi/st.txt b/Documentation/scsi/st.txt index 20e30cf31877..5ff65b184265 100644 --- a/Documentation/scsi/st.txt +++ b/Documentation/scsi/st.txt @@ -249,7 +249,7 @@ BOOT TIME CONFIGURATION If the driver is compiled into the kernel, the same parameters can be also set using, e.g., the LILO command line. The preferred syntax is -is to use the same keyword used when loading as module but prepended +to use the same keyword used when loading as module but prepended with 'st.'. For instance, to set the maximum number of scatter/gather segments, the parameter 'st.max_sg_segs=xx' should be used (xx is the number of scatter/gather segments). @@ -369,7 +369,7 @@ MTSETDRVBUFFER the device dependent address. It is recommended to set this flag unless there are tapes using the device dependent (from the old times) (global) - MT_ST_SYSV sets the SYSV sematics (mode) + MT_ST_SYSV sets the SYSV semantics (mode) MT_ST_NOWAIT enables immediate mode (i.e., don't wait for the command to finish) for some commands (e.g., rewind) MT_ST_DEBUGGING debugging (global; debugging must be diff --git a/Documentation/scsi/sym53c8xx_2.txt b/Documentation/scsi/sym53c8xx_2.txt index 7f516cdcd262..26c8a08ca3ea 100644 --- a/Documentation/scsi/sym53c8xx_2.txt +++ b/Documentation/scsi/sym53c8xx_2.txt @@ -67,7 +67,7 @@ under Linux is contained in 2 files named sym_glue.h and sym_glue.c. Other drivers files are intended not to depend on the Operating System on which the driver is used. -The history of this driver can be summerized as follows: +The history of this driver can be summarized as follows: 1993: ncr driver written for 386bsd and FreeBSD by: Wolfgang Stanglmeier <wolf@cologne.de> @@ -684,7 +684,7 @@ Field H : SCNTL3 Scsi Control Register 3 Contains the setting of timing values for both asynchronous and synchronous data transfers. Field I : SCNTL4 Scsi Control Register 4 - Only meaninful for 53C1010 Ultra3 controllers. + Only meaningful for 53C1010 Ultra3 controllers. Understanding Fields J, K, L and dumps requires to have good knowledge of SCSI standards, chip cores functionnals and internal driver data structures. diff --git a/Documentation/scsi/tmscsim.txt b/Documentation/scsi/tmscsim.txt index df7a02bfb5bf..8b2168aa4fc7 100644 --- a/Documentation/scsi/tmscsim.txt +++ b/Documentation/scsi/tmscsim.txt @@ -27,7 +27,7 @@ Tekram DC390(T) adapter. This is where the name comes from: tm = Tekram scsi = SCSI driver, m = AMD (?) as opposed to w for the DC390W/U/F (NCR53c8X5, X=2/7) driver. Yes, there was also a driver for the latter, tmscsiw, which supported DC390W/U/F adapters. It's not maintained any more, -as the ncr53c8xx is perfectly supporting these adpaters since some time. +as the ncr53c8xx is perfectly supporting these adapters since some time. The driver first appeared in April 1996, exclusively supported the DC390 and has been enhanced since then in various steps. In May 1998 support for @@ -381,7 +381,7 @@ Please see http://www.garloff.de/kurt/linux/dc390/problems.html replaced by the dev index of your scanner). You may try to reset your SCSI bus afterwards (echo "RESET" >/proc/scsi/tmscsim/?). The problem seems to be solved as of 2.0d18, thanks to Andreas Rick. -* If there is a valid partition table, the driver will use it for determing +* If there is a valid partition table, the driver will use it for determining the mapping. If there's none, a reasonable mapping (Symbios-like) will be assumed. Other operating systems may not like this mapping, though it's consistent with the BIOS' behaviour. Old DC390 drivers ignored the diff --git a/Documentation/seclvl.txt b/Documentation/seclvl.txt deleted file mode 100644 index 97274d122d0e..000000000000 --- a/Documentation/seclvl.txt +++ /dev/null @@ -1,97 +0,0 @@ -BSD Secure Levels Linux Security Module -Michael A. Halcrow <mike@halcrow.us> - - -Introduction - -Under the BSD Secure Levels security model, sets of policies are -associated with levels. Levels range from -1 to 2, with -1 being the -weakest and 2 being the strongest. These security policies are -enforced at the kernel level, so not even the superuser is able to -disable or circumvent them. This hardens the machine against attackers -who gain root access to the system. - - -Levels and Policies - -Level -1 (Permanently Insecure): - - Cannot increase the secure level - -Level 0 (Insecure): - - Cannot ptrace the init process - -Level 1 (Default): - - /dev/mem and /dev/kmem are read-only - - IMMUTABLE and APPEND extended attributes, if set, may not be unset - - Cannot load or unload kernel modules - - Cannot write directly to a mounted block device - - Cannot perform raw I/O operations - - Cannot perform network administrative tasks - - Cannot setuid any file - -Level 2 (Secure): - - Cannot decrement the system time - - Cannot write to any block device, whether mounted or not - - Cannot unmount any mounted filesystems - - -Compilation - -To compile the BSD Secure Levels LSM, seclvl.ko, enable the -SECURITY_SECLVL configuration option. This is found under Security -options -> BSD Secure Levels in the kernel configuration menu. - - -Basic Usage - -Once the machine is in a running state, with all the necessary modules -loaded and all the filesystems mounted, you can load the seclvl.ko -module: - -# insmod seclvl.ko - -The module defaults to secure level 1, except when compiled directly -into the kernel, in which case it defaults to secure level 0. To raise -the secure level to 2, the administrator writes ``2'' to the -seclvl/seclvl file under the sysfs mount point (assumed to be /sys in -these examples): - -# echo -n "2" > /sys/seclvl/seclvl - -Alternatively, you can initialize the module at secure level 2 with -the initlvl module parameter: - -# insmod seclvl.ko initlvl=2 - -At this point, it is impossible to remove the module or reduce the -secure level. If the administrator wishes to have the option of doing -so, he must provide a module parameter, sha1_passwd, that specifies -the SHA1 hash of the password that can be used to reduce the secure -level to 0. - -To generate this SHA1 hash, the administrator can use OpenSSL: - -# echo -n "boogabooga" | openssl sha1 -abeda4e0f33defa51741217592bf595efb8d289c - -In order to use password-instigated secure level reduction, the SHA1 -crypto module must be loaded or compiled into the kernel: - -# insmod sha1.ko - -The administrator can then insmod the seclvl module, including the -SHA1 hash of the password: - -# insmod seclvl.ko - sha1_passwd=abeda4e0f33defa51741217592bf595efb8d289c - -To reduce the secure level, write the password to seclvl/passwd under -your sysfs mount point: - -# echo -n "boogabooga" > /sys/seclvl/passwd - -The September 2004 edition of Sys Admin Magazine has an article about -the BSD Secure Levels LSM. I encourage you to refer to that article -for a more in-depth treatment of this security module: - -http://www.samag.com/documents/s=9304/sam0409a/0409a.htm diff --git a/Documentation/sh/kgdb.txt b/Documentation/sh/kgdb.txt index 5b04f7f306fc..05b4ba89d28c 100644 --- a/Documentation/sh/kgdb.txt +++ b/Documentation/sh/kgdb.txt @@ -69,7 +69,7 @@ might specify the halt option: kgdb=halt -Boot the TARGET machinem, which will appear to hang. +Boot the TARGET machine, which will appear to hang. On your DEVELOPMENT machine, cd to the source directory and run the gdb program. (This is likely to be a cross GDB which runs on your host but diff --git a/Documentation/sh/new-machine.txt b/Documentation/sh/new-machine.txt index eb2dd2e6993b..73988e0d112b 100644 --- a/Documentation/sh/new-machine.txt +++ b/Documentation/sh/new-machine.txt @@ -41,11 +41,6 @@ Board-specific code: | .. more boards here ... -It should also be noted that each board is required to have some certain -headers. At the time of this writing, io.h is the only thing that needs -to be provided for each board, and can generally just reference generic -functions (with the exception of isa_port2addr). - Next, for companion chips: . `-- arch @@ -104,12 +99,13 @@ and then populate that with sub-directories for each member of the family. Both the Solution Engine and the hp6xx boards are an example of this. After you have setup your new arch/sh/boards/ directory, remember that you -also must add a directory in include/asm-sh for headers localized to this -board. In order to interoperate seamlessly with the build system, it's best -to have this directory the same as the arch/sh/boards/ directory name, -though if your board is again part of a family, the build system has ways -of dealing with this, and you can feel free to name the directory after -the family member itself. +should also add a directory in include/asm-sh for headers localized to this +board (if there are going to be more than one). In order to interoperate +seamlessly with the build system, it's best to have this directory the same +as the arch/sh/boards/ directory name, though if your board is again part of +a family, the build system has ways of dealing with this (via incdir-y +overloading), and you can feel free to name the directory after the family +member itself. There are a few things that each board is required to have, both in the arch/sh/boards and the include/asm-sh/ heirarchy. In order to better @@ -122,6 +118,7 @@ might look something like: * arch/sh/boards/vapor/setup.c - Setup code for imaginary board */ #include <linux/init.h> +#include <asm/rtc.h> /* for board_time_init() */ const char *get_system_type(void) { @@ -152,79 +149,57 @@ int __init platform_setup(void) } Our new imaginary board will also have to tie into the machvec in order for it -to be of any use. Currently the machvec is slowly on its way out, but is still -required for the time being. As such, let us take a look at what needs to be -done for the machvec assignment. +to be of any use. machvec functions fall into a number of categories: - I/O functions to IO memory (inb etc) and PCI/main memory (readb etc). - - I/O remapping functions (ioremap etc) - - some initialisation functions - - a 'heartbeat' function - - some miscellaneous flags - -The tree can be built in two ways: - - as a fully generic build. All drivers are linked in, and all functions - go through the machvec - - as a machine specific build. In this case only the required drivers - will be linked in, and some macros may be redefined to not go through - the machvec where performance is important (in particular IO functions). - -There are three ways in which IO can be performed: - - none at all. This is really only useful for the 'unknown' machine type, - which us designed to run on a machine about which we know nothing, and - so all all IO instructions do nothing. - - fully custom. In this case all IO functions go to a machine specific - set of functions which can do what they like - - a generic set of functions. These will cope with most situations, - and rely on a single function, mv_port2addr, which is called through the - machine vector, and converts an IO address into a memory address, which - can be read from/written to directly. - -Thus adding a new machine involves the following steps (I will assume I am -adding a machine called vapor): - - - add a new file include/asm-sh/vapor/io.h which contains prototypes for + - I/O mapping functions (ioport_map, ioport_unmap, etc). + - a 'heartbeat' function. + - PCI and IRQ initialization routines. + - Consistent allocators (for boards that need special allocators, + particularly for allocating out of some board-specific SRAM for DMA + handles). + +There are machvec functions added and removed over time, so always be sure to +consult include/asm-sh/machvec.h for the current state of the machvec. + +The kernel will automatically wrap in generic routines for undefined function +pointers in the machvec at boot time, as machvec functions are referenced +unconditionally throughout most of the tree. Some boards have incredibly +sparse machvecs (such as the dreamcast and sh03), whereas others must define +virtually everything (rts7751r2d). + +Adding a new machine is relatively trivial (using vapor as an example): + +If the board-specific definitions are quite minimalistic, as is the case for +the vast majority of boards, simply having a single board-specific header is +sufficient. + + - add a new file include/asm-sh/vapor.h which contains prototypes for any machine specific IO functions prefixed with the machine name, for example vapor_inb. These will be needed when filling out the machine vector. - This is the minimum that is required, however there are ample - opportunities to optimise this. In particular, by making the prototypes - inline function definitions, it is possible to inline the function when - building machine specific versions. Note that the machine vector - functions will still be needed, so that a module built for a generic - setup can be loaded. - - - add a new file arch/sh/boards/vapor/mach.c. This contains the definition - of the machine vector. When building the machine specific version, this - will be the real machine vector (via an alias), while in the generic - version is used to initialise the machine vector, and then freed, by - making it initdata. This should be defined as: - - struct sh_machine_vector mv_vapor __initmv = { - .mv_name = "vapor", - } - ALIAS_MV(vapor) - - - finally add a file arch/sh/boards/vapor/io.c, which contains - definitions of the machine specific io functions. - -A note about initialisation functions. Three initialisation functions are -provided in the machine vector: - - mv_arch_init - called very early on from setup_arch - - mv_init_irq - called from init_IRQ, after the generic SH interrupt - initialisation - - mv_init_pci - currently not used - -Any other remaining functions which need to be called at start up can be -added to the list using the __initcalls macro (or module_init if the code -can be built as a module). Many generic drivers probe to see if the device -they are targeting is present, however this may not always be appropriate, -so a flag can be added to the machine vector which will be set on those -machines which have the hardware in question, reducing the probe to a -single conditional. + Note that these prototypes are generated automatically by setting + __IO_PREFIX to something sensible. A typical example would be: + + #define __IO_PREFIX vapor + #include <asm/io_generic.h> + + somewhere in the board-specific header. Any boards being ported that still + have a legacy io.h should remove it entirely and switch to the new model. + + - Add machine vector definitions to the board's setup.c. At a bare minimum, + this must be defined as something like: + + struct sh_machine_vector mv_vapor __initmv = { + .mv_name = "vapor", + }; + ALIAS_MV(vapor) + + - finally add a file arch/sh/boards/vapor/io.c, which contains definitions of + the machine specific io functions (if there are enough to warrant it). 3. Hooking into the Build System ================================ @@ -303,4 +278,3 @@ which will in turn copy the defconfig for this board, run it through oldconfig (prompting you for any new options since the time of creation), and start you on your way to having a functional kernel for your new board. - diff --git a/Documentation/sh/register-banks.txt b/Documentation/sh/register-banks.txt new file mode 100644 index 000000000000..a6719f2f6594 --- /dev/null +++ b/Documentation/sh/register-banks.txt @@ -0,0 +1,33 @@ + Notes on register bank usage in the kernel + ========================================== + +Introduction +------------ + +The SH-3 and SH-4 CPU families traditionally include a single partial register +bank (selected by SR.RB, only r0 ... r7 are banked), whereas other families +may have more full-featured banking or simply no such capabilities at all. + +SR.RB banking +------------- + +In the case of this type of banking, banked registers are mapped directly to +r0 ... r7 if SR.RB is set to the bank we are interested in, otherwise ldc/stc +can still be used to reference the banked registers (as r0_bank ... r7_bank) +when in the context of another bank. The developer must keep the SR.RB value +in mind when writing code that utilizes these banked registers, for obvious +reasons. Userspace is also not able to poke at the bank1 values, so these can +be used rather effectively as scratch registers by the kernel. + +Presently the kernel uses several of these registers. + + - r0_bank, r1_bank (referenced as k0 and k1, used for scratch + registers when doing exception handling). + - r2_bank (used to track the EXPEVT/INTEVT code) + - Used by do_IRQ() and friends for doing irq mapping based off + of the interrupt exception vector jump table offset + - r6_bank (global interrupt mask) + - The SR.IMASK interrupt handler makes use of this to set the + interrupt priority level (used by local_irq_enable()) + - r7_bank (current) + diff --git a/Documentation/sound/alsa/ALSA-Configuration.txt b/Documentation/sound/alsa/ALSA-Configuration.txt index e6b57dd46a4f..138673a907f5 100644 --- a/Documentation/sound/alsa/ALSA-Configuration.txt +++ b/Documentation/sound/alsa/ALSA-Configuration.txt @@ -57,11 +57,6 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. - Default: 1 - For auto-loading more than one card, specify this option together with snd-card-X aliases. - device_mode - - permission mask for dynamic sound device filesystem - - This is available only when DEVFS is enabled - - Default: 0666 - - E.g.: device_mode=0660 Module snd-pcm-oss @@ -1268,8 +1263,8 @@ Prior to version 0.9.0rc4 options had a 'snd_' prefix. This was removed. Note: on some notebooks the buffer address cannot be detected automatically, or causes hang-up during initialization. - In such a case, specify the buffer top address explicity via - buffer_top option. + In such a case, specify the buffer top address explicitly via + the buffer_top option. For example, Sony F250: buffer_top=0x25a800 Sony F270: buffer_top=0x272800 @@ -1887,7 +1882,7 @@ options snd-ens1371 index=1 # OSS/Free portion alias sound-slot-0 snd-interwave alias sound-slot-1 snd-ens1371 ------ /etc/moprobe.conf +----- /etc/modprobe.conf In this example, the interwave card is always loaded as the first card (index 0) and ens1371 as the second (index 1). @@ -1915,21 +1910,6 @@ Please note that the device mapping above may be varied via the module options of snd-pcm-oss module. -DEVFS support -============= - -The ALSA driver fully supports the devfs extension. -You should add lines below to your devfsd.conf file: - -LOOKUP snd MODLOAD ACTION snd -REGISTER ^sound/.* PERMISSIONS root.audio 660 -REGISTER ^snd/.* PERMISSIONS root.audio 660 - -Warning: These lines assume that you have the audio group in your system. - Otherwise replace audio word with another group name (root for - example). - - Proc interfaces (/proc/asound) ============================== diff --git a/Documentation/sound/alsa/Audiophile-Usb.txt b/Documentation/sound/alsa/Audiophile-Usb.txt index b535c2a198f8..e40cce83327c 100644 --- a/Documentation/sound/alsa/Audiophile-Usb.txt +++ b/Documentation/sound/alsa/Audiophile-Usb.txt @@ -126,7 +126,7 @@ Here is a list of supported device_setup values for this device: - Alsa driver default mode - maintains backward compatibility with setups that do not use this parameter by not introducing any change - - results sometimes in corrupted sound as decribed earlier + - results sometimes in corrupted sound as described earlier * device_setup=0x01 - 16bits 48kHz mode with Di disabled - Ai,Ao,Do can be used at the same time diff --git a/Documentation/sound/alsa/CMIPCI.txt b/Documentation/sound/alsa/CMIPCI.txt index 1872e24442a4..4b2b15387056 100644 --- a/Documentation/sound/alsa/CMIPCI.txt +++ b/Documentation/sound/alsa/CMIPCI.txt @@ -16,11 +16,11 @@ As default, ALSA driver assigns the first PCM device (i.e. hw:0,0 for card#0) for front and 4/6ch playbacks, while the second PCM device (hw:0,1) is assigned to the second DAC for rear playback. -There are slight difference between two DACs. +There are slight differences between the two DACs: - The first DAC supports U8 and S16LE formats, while the second DAC supports only S16LE. -- The seconde DAC supports only two channel stereo. +- The second DAC supports only two channel stereo. Please note that the CM8x38 DAC doesn't support continuous playback rate but only fixed rates: 5512, 8000, 11025, 16000, 22050, 32000, @@ -76,7 +76,7 @@ in alsa-lib. For example, you can play a WAV file with 6 channels like % aplay -Dsurround51 sixchannels.wav -For programmin the 4/6 channel playback, you need to specify the PCM +For programming the 4/6 channel playback, you need to specify the PCM channels as you like and set the format S16LE. For example, for playback with 4 channels, diff --git a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl index 4807ef79a94d..077fbe25ebf4 100644 --- a/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl +++ b/Documentation/sound/alsa/DocBook/writing-an-alsa-driver.tmpl @@ -5486,7 +5486,7 @@ struct _snd_pcm_runtime { <chapter id="power-management"> <title>Power Management</title> <para> - If the chip is supposed to work with with suspend/resume + If the chip is supposed to work with suspend/resume functions, you need to add the power-management codes to the driver. The additional codes for the power-management should be <function>ifdef</function>'ed with diff --git a/Documentation/sound/alsa/MIXART.txt b/Documentation/sound/alsa/MIXART.txt index 5cb970612870..ef42c44fa1f2 100644 --- a/Documentation/sound/alsa/MIXART.txt +++ b/Documentation/sound/alsa/MIXART.txt @@ -31,7 +31,7 @@ With a miXart8AES/EBU there is in addition 1 stereo digital input Formats ------- U8, S16_LE, S16_BE, S24_3LE, S24_3BE, FLOAT_LE, FLOAT_BE -Sample rates : 8000 - 48000 Hz continously +Sample rates : 8000 - 48000 Hz continuously Playback -------- @@ -39,7 +39,7 @@ For instance the playback devices are configured to have max. 4 substreams performing hardware mixing. This could be changed to a maximum of 24 substreams if wished. Mono files will be played on the left and right channel. Each channel -can be muted for each stream to use 8 analog/digital outputs seperately. +can be muted for each stream to use 8 analog/digital outputs separately. Capture ------- @@ -97,4 +97,4 @@ COPYRIGHT ========= Copyright (c) 2003 Digigram SA <alsa@digigram.com> -Distributalbe under GPL. +Distributable under GPL. diff --git a/Documentation/sound/alsa/Procfile.txt b/Documentation/sound/alsa/Procfile.txt index 1fe48846d78f..f738b296440a 100644 --- a/Documentation/sound/alsa/Procfile.txt +++ b/Documentation/sound/alsa/Procfile.txt @@ -71,7 +71,7 @@ The status of MIDI I/O is found in midi* files. It shows the device name and the received/transmitted bytes through the MIDI device. When the card is equipped with AC97 codecs, there are codec97#* -subdirectories (desribed later). +subdirectories (described later). When the OSS mixer emulation is enabled (and the module is loaded), oss_mixer file appears here, too. This shows the current mapping of @@ -161,12 +161,12 @@ seq/drivers Lists the currently available ALSA sequencer drivers. seq/clients - Shows the list of currently available sequencer clinets and + Shows the list of currently available sequencer clients and ports. The connection status and the running status are shown in this file, too. seq/queues - Lists the currently allocated/running sequener queues. + Lists the currently allocated/running sequencer queues. seq/timer Lists the currently allocated/running sequencer timers. @@ -182,10 +182,10 @@ When the problem is related with PCM, first try to turn on xrun_debug mode. This will give you the kernel messages when and where xrun happened. -If it's really a bug, report it with the following information +If it's really a bug, report it with the following information: - the name of the driver/card, show in /proc/asound/cards - - the reigster dump, if available (e.g. card*/cmipci) + - the register dump, if available (e.g. card*/cmipci) when it's a PCM problem, diff --git a/Documentation/sound/oss/AWE32 b/Documentation/sound/oss/AWE32 deleted file mode 100644 index cb179bfeb522..000000000000 --- a/Documentation/sound/oss/AWE32 +++ /dev/null @@ -1,76 +0,0 @@ - Installing and using Creative AWE midi sound under Linux. - -This documentation is devoted to the Creative Sound Blaster AWE32, AWE64 and -SB32. - -1) Make sure you have an ORIGINAL Creative SB32, AWE32 or AWE64 card. This - is important, because the driver works only with real Creative cards. - -2) The first thing you need to do is re-compile your kernel with support for - your sound card. Run your favourite tool to configure the kernel and when - you get to the "Sound" menu you should enable support for the following: - - Sound card support, - OSS sound modules, - 100% Sound Blaster compatibles (SB16/32/64, ESS, Jazz16) support, - AWE32 synth - - If your card is "Plug and Play" you will also need to enable these two - options, found under the "Plug and Play configuration" menu: - - Plug and Play support - ISA Plug and Play support - - Now compile and install the kernel in normal fashion. If you don't know - how to do this you can find instructions for this in the README file - located in the root directory of the kernel source. - -3) Before you can start playing midi files you will have to load a sound - bank file. The utility needed for doing this is called "sfxload", and it - is one of the utilities found in a package called "awesfx". If this - package is not available in your distribution you can download the AWE - snapshot from Creative Labs Open Source website: - - http://www.opensource.creative.com/snapshot.html - - Once you have unpacked the AWE snapshot you will see a "awesfx" - directory. Follow the instructions in awesfx/docs/INSTALL to install the - utilities in this package. After doing this, sfxload should be installed - as: - - /usr/local/bin/sfxload - - To enable AWE general midi synthesis you should also get the sound bank - file for general midi from: - - http://members.xoom.com/yar/synthgm.sbk.gz - - Copy it to a directory of your choice, and unpack it there. - -4) Edit /etc/modprobe.conf, and insert the following lines at the end of the - file: - - alias sound-slot-0 sb - alias sound-service-0-1 awe_wave - install awe_wave /sbin/modprobe --first-time -i awe_wave && /usr/local/bin/sfxload PATH_TO_SOUND_BANK_FILE - - You will of course have to change "PATH_TO_SOUND_BANK_FILE" to the full - path of of the sound bank file. That will enable the Sound Blaster and AWE - wave synthesis. To play midi files you should get one of these programs if - you don't already have them: - - Playmidi: http://playmidi.openprojects.net - - AWEMidi Player (drvmidi) Included in the previously mentioned AWE - snapshot. - - You will probably have to pass the "-e" switch to playmidi to have it use - your midi device. drvmidi should work without switches. - - If something goes wrong please e-mail me. All comments and suggestions are - welcome. - - Yaroslav Rosomakho (alons55@dialup.ptt.ru) - http://www.yar.opennet.ru - -Last Updated: Feb 3 2001 diff --git a/Documentation/sound/oss/CMI8338 b/Documentation/sound/oss/CMI8338 deleted file mode 100644 index 387d058c3f95..000000000000 --- a/Documentation/sound/oss/CMI8338 +++ /dev/null @@ -1,85 +0,0 @@ -Audio driver for CM8338/CM8738 chips by Chen-Li Tien - - -HARDWARE SUPPORTED -================================================================================ -C-Media CMI8338 -C-Media CMI8738 -On-board C-Media chips - - -STEPS TO BUILD DRIVER -================================================================================ - - 1. Backup the Config.in and Makefile in the sound driver directory - (/usr/src/linux/driver/sound). - The Configure.help provide help when you config driver in step - 4, please backup the original one (/usr/src/linux/Document) and - copy this file. - The cmpci is document for the driver in detail, please copy it - to /usr/src/linux/Document/sound so you can refer it. Backup if - there is already one. - - 2. Extract the tar file by 'tar xvzf cmpci-xx.tar.gz' in the above - directory. - - 3. Change directory to /usr/src/linux - - 4. Config cm8338 driver by 'make menuconfig', 'make config' or - 'make xconfig' command. - - 5. Please select Sound Card (CONFIG_SOUND=m) support and CMPCI - driver (CONFIG_SOUND_CMPCI=m) as modules. Resident mode not tested. - For driver option, please refer 'DRIVER PARAMETER' - - 6. Compile the kernel if necessary. - - 7. Compile the modules by 'make modules'. - - 8. Install the modules by 'make modules_install' - - -INSTALL DRIVER -================================================================================ - - 1. Before first time to run the driver, create module dependency by - 'depmod -a' - - 2. To install the driver manually, enter 'modprobe cmpci'. - - 3. Driver installation for various distributions: - - a. Slackware 4.0 - Add the 'modprobe cmpci' command in your /etc/rc.d/rc.modules - file.so you can start the driver automatically each time booting. - - b. Caldera OpenLinux 2.2 - Use LISA to load the cmpci module. - - c. RedHat 6.0 and S.u.S.E. 6.1 - Add following command in /etc/conf.modules: - - alias sound cmpci - - also visit http://www.cmedia.com.tw for installation instruction. - -DRIVER PARAMETER -================================================================================ - - Some functions for the cm8738 can be configured in Kernel Configuration - or modules parameters. Set these parameters to 1 to enable. - - mpuio: I/O ports base for MPU-401, 0 if disabled. - fmio: I/O ports base for OPL-3, 0 if disabled. - spdif_inverse:Inverse the S/PDIF-in signal, this depends on your - CD-ROM or DVD-ROM. - spdif_loop: Enable S/PDIF loop, this route S/PDIF-in to S/PDIF-out - directly. - speakers: Number of speakers used. - use_line_as_rear:Enable this if you want to use line-in as - rear-out. - use_line_as_bass:Enable this if you want to use line-in as - bass-out. - joystick: Enable joystick. You will need to install Linux joystick - driver. - diff --git a/Documentation/sound/oss/INSTALL.awe b/Documentation/sound/oss/INSTALL.awe deleted file mode 100644 index 310f42ca1e83..000000000000 --- a/Documentation/sound/oss/INSTALL.awe +++ /dev/null @@ -1,134 +0,0 @@ -================================================================ - INSTALLATION OF AWE32 SOUND DRIVER FOR LINUX - Takashi Iwai <iwai@ww.uni-erlangen.de> -================================================================ - ----------------------------------------------------------------- -* Attention to SB-PnP Card Users - -If you're using PnP cards, the initialization of PnP is required -before loading this driver. You have now three options: - 1. Use isapnptools. - 2. Use in-kernel isapnp support. - 3. Initialize PnP on DOS/Windows, then boot linux by loadlin. -In this document, only the case 1 case is treated. - ----------------------------------------------------------------- -* Installation on Red Hat 5.0 Sound Driver - -Please use install-rh.sh under RedHat5.0 directory. -DO NOT USE install.sh below. -See INSTALL.RH for more details. - ----------------------------------------------------------------- -* Installation/Update by Shell Script - - 1. Become root - - % su - - 2. If you have never configured the kernel tree yet, run make config - once (to make dependencies and symlinks). - - # cd /usr/src/linux - # make xconfig - - 3. Run install.sh script - - # sh ./install.sh - - 4. Configure your kernel - - (for Linux 2.[01].x user) - # cd /usr/src/linux - # make xconfig (or make menuconfig) - - (for Linux 1.2.x user) - # cd /usr/src/linux - # make config - - Answer YES to both "lowlevel drivers" and "AWE32 wave synth" items - in Sound menu. ("lowlevel drivers" will appear only in 2.x - kernel.) - - 5. Make your kernel (and modules), and install them as usual. - - 5a. make kernel image - # make zImage - - 5b. make modules and install them - # make modules && make modules_install - - 5c. If you're using lilo, copy the kernel image and run lilo. - Otherwise, copy the kernel image to suitable directory or - media for your system. - - 6. Reboot the kernel if necessary. - - If you updated only the modules, you don't have to reboot - the system. Just remove the old sound modules here. - in - # rmmod sound.o (linux-2.0 or OSS/Free) - # rmmod awe_wave.o (linux-2.1) - - 7. If your AWE card is a PnP and not initialized yet, you'll have to - do it by isapnp tools. Otherwise, skip to 8. - - This section described only a brief explanation. For more - details, please see the AWE64-Mini-HOWTO or isapnp tools FAQ. - - 7a. If you have no isapnp.conf file, generate it by pnpdump. - Otherwise, skip to 7d. - # pnpdump > /etc/isapnp.conf - - 7b. Edit isapnp.conf file. Comment out the appropriate - lines containing desirable I/O ports, DMA and IRQs. - Don't forget to enable (ACT Y) line. - - 7c. Add two i/o ports (0xA20 and 0xE20) in WaveTable part. - ex) - (CONFIGURE CTL0048/58128 (LD 2 - # ANSI string -->WaveTable<-- - (IO 0 (BASE 0x0620)) - (IO 1 (BASE 0x0A20)) - (IO 2 (BASE 0x0E20)) - (ACT Y) - )) - - 7d. Load the config file. - CAUTION: This will reset all PnP cards! - - # isapnp /etc/isapnp.conf - - 8. Load the sound module (if you configured it as a module): - - for 2.0 kernel or OSS/Free monolithic module: - - # modprobe sound.o - - for 2.1 kernel: - - # modprobe sound - # insmod uart401 - # insmod sb io=0x220 irq=5 dma=1 dma16=5 mpu_io=0x330 - (These values depend on your settings.) - # insmod awe_wave - (Be sure to load awe_wave after sb!) - - See Documentation/sound/oss/AWE32 for - more details. - - 9. (only for obsolete systems) If you don't have /dev/sequencer - device file, make it according to Readme.linux file on - /usr/src/linux/drivers/sound. (Run a shell script included in - that file). <-- This file no longer exists in the recent kernels! - - 10. OK, load your own soundfont file, and enjoy MIDI! - - % sfxload synthgm.sbk - % drvmidi foo.mid - - 11. For more advanced use (eg. dynamic loading, virtual bank and - etc.), please read the awedrv FAQ or the instructions in awesfx - and awemidi packages. - -Good luck! diff --git a/Documentation/sound/oss/MAD16 b/Documentation/sound/oss/MAD16 deleted file mode 100644 index 865dbd848742..000000000000 --- a/Documentation/sound/oss/MAD16 +++ /dev/null @@ -1,56 +0,0 @@ -(This recipe has been edited to update the configuration symbols, - and change over to modprobe.conf for 2.6) - -From: Shaw Carruthers <shaw@shawc.demon.co.uk> - -I have been using mad16 sound for some time now with no problems, current -kernel 2.1.89 - -lsmod shows: - -mad16 5176 0 -sb 22044 0 [mad16] -uart401 5576 0 [mad16 sb] -ad1848 14176 1 [mad16] -sound 61928 0 [mad16 sb uart401 ad1848] - -.config has: - -CONFIG_SOUND=m -CONFIG_SOUND_ADLIB=m -CONFIG_SOUND_MAD16=m -CONFIG_SOUND_YM3812=m - -modprobe.conf has: - -alias char-major-14-* mad16 -options sb mad16=1 -options mad16 io=0x530 irq=7 dma=0 dma16=1 && /usr/local/bin/aumix -w 15 -p 20 -m 0 -1 0 -2 0 -3 0 -i 0 - - -To get the built in mixer to work this needs to be: - -options adlib_card io=0x388 # FM synthesizer -options sb mad16=1 -options mad16 io=0x530 irq=7 dma=0 dma16=1 mpu_io=816 mpu_irq=5 && /usr/local/bin/aumix -w 15 -p 20 -m 0 -1 0 -2 0 -3 0 -i 0 - -The addition of the "mpu_io=816 mpu_irq=5" to the mad16 options line is - ------------------------------------------------------------------------- -The mad16 module in addition supports the following options: - -option: meaning: default: -joystick=0,1 disabled, enabled disabled -cdtype=0x00,0x02,0x04, disabled, Sony CDU31A, disabled - 0x06,0x08,0x0a Mitsumi, Panasonic, - Secondary IDE, Primary IDE -cdport=0x340,0x320, 0x340 - 0x330,0x360 -cdirq=0,3,5,7,9,10,11 disabled, IRQ3, ... disabled -cddma=0,5,6,7 disabled, DMA5, ... DMA5 for Mitsumi or IDE -cddma=0,1,2,3 disabled, DMA1, ... DMA3 for Sony or Panasonic -opl4=0,1 OPL3, OPL4 OPL3 - -for more details see linux/drivers/sound/mad16.c - -Rui Sousa diff --git a/Documentation/sound/oss/Maestro b/Documentation/sound/oss/Maestro deleted file mode 100644 index 4a80eb3f8e00..000000000000 --- a/Documentation/sound/oss/Maestro +++ /dev/null @@ -1,123 +0,0 @@ - An OSS/Lite Driver for the ESS Maestro family of sound cards - - Zach Brown, December 1999 - -Driver Status and Availability ------------------------------- - -The most recent version of this driver will hopefully always be available at - http://www.zabbo.net/maestro/ - -I will try and maintain the most recent stable version of the driver -in both the stable and development kernel lines. - -ESS Maestro Chip Family ------------------------ - -There are 3 main variants of the ESS Maestro PCI sound chip. The first -is the Maestro 1. It was originally produced by Platform Tech as the -'AGOGO'. It can be recognized by Platform Tech's PCI ID 0x1285 with -0x0100 as the device ID. It was put on some sound boards and a few laptops. -ESS bought the design and cleaned it up as the Maestro 2. This starts -their marking with the ESS vendor ID 0x125D and the 'year' device IDs. -The Maestro 2 claims 0x1968 while the Maestro 2e has 0x1978. - -The various families of Maestro are mostly identical as far as this -driver is concerned. It doesn't touch the DSP parts that differ (though -it could for FM synthesis). - -Driver OSS Behavior --------------------- - -This OSS driver exports /dev/mixer and /dev/dsp to applications, which -mostly adhere to the OSS spec. This driver doesn't register itself -with /dev/sndstat, so don't expect information to appear there. - -The /dev/dsp device exported behaves almost as expected. Playback is -supported in all the various lovely formats. 8/16bit stereo/mono from -8khz to 48khz, and mmap()ing for playback behaves. Capture/recording -is limited due to oddities with the Maestro hardware. One can only -record in 16bit stereo. For recording the maestro uses non interleaved -stereo buffers so that mmap()ing the incoming data does not result in -a ring buffer of LRLR data. mmap()ing of the read buffers is therefore -disallowed until this can be cleaned up. - -/dev/mixer is an interface to the AC'97 codec on the Maestro. It is -worth noting that there are a variety of AC'97s that can be wired to -the Maestro. Which is used is entirely up to the hardware implementor. -This should only be visible to the user by the presence, or lack, of -'Bass' and 'Treble' sliders in the mixer. Not all AC'97s have them. - -The driver doesn't support MIDI or FM playback at the moment. Typically -the Maestro is wired to an MPU MIDI chip, but some hardware implementations -don't. We need to assemble a white list of hardware implementations that -have MIDI wired properly before we can claim to support it safely. - -Compiling and Installing ------------------------- - -With the drivers inclusion into the kernel, compiling and installing -is the same as most OSS/Lite modular sound drivers. Compilation -of the driver is enabled through the CONFIG_SOUND_MAESTRO variable -in the config system. - -It may be modular or statically linked. If it is modular it should be -installed with the rest of the modules for the kernel on the system. -Typically this will be in /lib/modules/ somewhere. 'alias sound maestro' -should also be added to your module configs (typically /etc/conf.modules) -if you're using modular OSS/Lite sound and want to default to using a -maestro chip. - -As this is a PCI device, the module does not need to be informed of -any IO or IRQ resources it should use, it devines these from the -system. Sometimes, on sucky PCs, the BIOS fails to allocated resources -for the maestro. This will result in a message like: - maestro: PCI subsystem reports IRQ 0, this might not be correct. -from the kernel. Should this happen the sound chip most likely will -not operate correctly. To solve this one has to dig through their BIOS -(typically entered by hitting a hot key at boot time) and figure out -what magic needs to happen so that the BIOS will reward the maestro with -an IRQ. This operation is incredibly system specific, so you're on your -own. Sometimes the magic lies in 'PNP Capable Operating System' settings. - -There are very few options to the driver. One is 'debug' which will -tell the driver to print minimal debugging information as it runs. This -can be collected with 'dmesg' or through the klogd daemon. - -The other, more interesting option, is 'dsps_order'. Typically at -install time the driver will only register one available /dev/dsp device -for its use. The 'dsps_order' module parameter allows for more devices -to be allocated, as a power of two. Up to 4 devices can be registered -( dsps_order=2 ). These devices act as fully distinct units and use -separate channels in the maestro. - -Power Management ----------------- - -As of version 0.14, this driver has a minimal understanding of PCI -Power Management. If it finds a valid power management capability -on the PCI device it will attempt to use the power management -functions of the maestro. It will only do this on Maestro 2Es and -only on machines that are known to function well. You can -force the use of power management by setting the 'use_pm' module -option to 1, or can disable it entirely by setting it to 0. - -When using power management, the driver does a few things -differently. It will keep the chip in a lower power mode -when the module is inserted but /dev/dsp is not open. This -allows the mixer to function but turns off the clocks -on other parts of the chip. When /dev/dsp is opened the chip -is brought into full power mode, and brought back down -when it is closed. It also powers down the chip entirely -when the module is removed or the machine is shutdown. This -can have nonobvious consequences. CD audio may not work -after a power managing driver is removed. Also, software that -doesn't understand power management may not be able to talk -to the powered down chip until the machine goes through a hard -reboot to bring it back. - -.. more details .. ------------------- - -drivers/sound/maestro.c contains comments that hopefully explain -the maestro implementation. diff --git a/Documentation/sound/oss/Maestro3 b/Documentation/sound/oss/Maestro3 deleted file mode 100644 index a113718e8034..000000000000 --- a/Documentation/sound/oss/Maestro3 +++ /dev/null @@ -1,92 +0,0 @@ - An OSS/Lite Driver for the ESS Maestro3 family of sound chips - - Zach Brown, January 2001 - -Driver Status and Availability ------------------------------- - -The most recent version of this driver will hopefully always be available at - http://www.zabbo.net/maestro3/ - -I will try and maintain the most recent stable version of the driver -in both the stable and development kernel lines. - -Historically I've sucked pretty hard at actually doing that, however. - -ESS Maestro3 Chip Family ------------------------ - -The 'Maestro3' is much like the Maestro2 chip. The noted improvement -is the removal of the silicon in the '2' that did PCM mixing. All that -work is now done through a custom DSP called the ASSP, the Asynchronus -Specific Signal Processor. - -The 'Allegro' is a baby version of the Maestro3. I'm not entirely clear -on the extent of the differences, but the driver supports them both :) - -The 'Allegro' shows up as PCI ID 0x1988 and the Maestro3 as 0x1998, -both under ESS's vendor ID of 0x125D. The Maestro3 can also show up as -0x199a when hardware strapping is used. - -The chip can also act as a multi function device. The modem IDs follow -the audio multimedia device IDs. (so the modem part of an Allegro shows -up as 0x1989) - -Driver OSS Behavior --------------------- - -This OSS driver exports /dev/mixer and /dev/dsp to applications, which -mostly adhere to the OSS spec. This driver doesn't register itself -with /dev/sndstat, so don't expect information to appear there. - -The /dev/dsp device exported behaves as expected. Playback is -supported in all the various lovely formats. 8/16bit stereo/mono from -8khz to 48khz, with both read()/write(), and mmap(). - -/dev/mixer is an interface to the AC'97 codec on the Maestro3. It is -worth noting that there are a variety of AC'97s that can be wired to -the Maestro3. Which is used is entirely up to the hardware implementor. -This should only be visible to the user by the presence, or lack, of -'Bass' and 'Treble' sliders in the mixer. Not all AC'97s have them. -The Allegro has an onchip AC'97. - -The driver doesn't support MIDI or FM playback at the moment. - -Compiling and Installing ------------------------- - -With the drivers inclusion into the kernel, compiling and installing -is the same as most OSS/Lite modular sound drivers. Compilation -of the driver is enabled through the CONFIG_SOUND_MAESTRO3 variable -in the config system. - -It may be modular or statically linked. If it is modular it should be -installed with the rest of the modules for the kernel on the system. -Typically this will be in /lib/modules/ somewhere. 'alias sound-slot-0 -maestro3' should also be added to your module configs (typically -/etc/modprobe.conf) if you're using modular OSS/Lite sound and want to -default to using a maestro3 chip. - -There are very few options to the driver. One is 'debug' which will -tell the driver to print minimal debugging information as it runs. This -can be collected with 'dmesg' or through the klogd daemon. - -One is 'external_amp', which tells the driver to attempt to enable -an external amplifier. This defaults to '1', you can tell the driver -not to bother enabling such an amplifier by setting it to '0'. - -And the last is 'gpio_pin', which tells the driver which GPIO pin number -the external amp uses (0-15), The Allegro uses 8 by default, all others 1. -If everything loads correctly and seems to be working but you get no sound, -try tweaking this value. - -Systems known to need a different value - Panasonic ToughBook CF-72: gpio_pin=13 - -Power Management ----------------- - -This driver has a minimal understanding of PCI Power Management. It will -try and power down the chip when the system is suspended, and power -it up with it is resumed. It will also try and power down the chip -when the machine is shut down. diff --git a/Documentation/sound/oss/NEWS b/Documentation/sound/oss/NEWS deleted file mode 100644 index a81e0ef72ae9..000000000000 --- a/Documentation/sound/oss/NEWS +++ /dev/null @@ -1,42 +0,0 @@ -Linux 2.4 Sound Changes -2000-September-25 -Christoph Hellwig, <hch@infradead.org> - - - -=== isapnp support - -The Linux 2.4 Kernel does have reliable in-kernel isapnp support. -Some drivers (sb.o, ad1816.o awe_wave.o) do now support automatically -detecting and configuring isapnp devices. -If you have a not yet supported isapnp soundcard, mail me the content -of '/proc/isapnp' on your system and some information about your card -and its driver(s) so I can try to get isapnp working for it. - - - -=== soundcard resources on kernel commandline - -Before Linux 2.4 you had to specify the resources for sounddrivers -statically linked into the kernel at compile time -(in make config/menuconfig/xconfig). In Linux 2.4 the resources are -now specified at the boot-time kernel commandline (e.g. the lilo -'append=' line or everything that's after the kernel name in grub). -Read the Configure.help entry for your card for the parameters. - - -=== softoss is gone - -In Linux 2.4 the softoss in-kernel software synthesizer is no more aviable. -Use a user space software synthesizer like timidity instead. - - - -=== /dev/sndstat and /proc/sound are gone - -In older Linux versions those files exported some information about the -OSS/Free configuration to userspace. In Linux 2.3 they were removed because -they did not support the growing number of pci soundcards and there were -some general problems with this interface. - - diff --git a/Documentation/sound/oss/OPL3-SA b/Documentation/sound/oss/OPL3-SA deleted file mode 100644 index 66a91835d918..000000000000 --- a/Documentation/sound/oss/OPL3-SA +++ /dev/null @@ -1,52 +0,0 @@ -OPL3-SA1 sound driver (opl3sa.o) - ---- -Note: This howto only describes how to setup the OPL3-SA1 chip; this info -does not apply to the SA2, SA3, or SA4. ---- - -The Yamaha OPL3-SA1 sound chip is usually found built into motherboards, and -it's a decent little chip offering a WSS mode, a SB Pro emulation mode, MPU401 -and OPL3 FM Synth capabilities. - -You can enable inclusion of the driver via CONFIG_SOUND_OPL3SA1=m, or -CONFIG_SOUND_OPL3SA1=y through 'make config/xconfig/menuconfig'. - -You'll need to know all of the relevant info (irq, dma, and io port) for the -chip's WSS mode, since that is the mode the kernel sound driver uses, and of -course you'll also need to know about where the MPU401 and OPL3 ports and -IRQs are if you want to use those. - -Here's the skinny on how to load it as a module: - - modprobe opl3sa io=0x530 irq=11 dma=0 dma2=1 mpu_io=0x330 mpu_irq=5 - -Module options in detail: - - io: This is the WSS's port base. - irq: This is the WSS's IRQ. - dma: This is the WSS's DMA line. In my BIOS setup screen this was - listed as "WSS Play DMA" - dma2: This is the WSS's secondary DMA line. My BIOS calls it the - "WSS capture DMA" - - mpu_io: This is the MPU401's port base. - mpu_irq: This is the MPU401's IRQ. - -If you'd like to use the OPL3 FM Synthesizer, make sure you enable -CONFIG_SOUND_YM3812 (in 'make config'). That'll build the opl3.o module. - -Then a simple 'insmod opl3 io=0x388', and you now have FM Synth. - -You can also use the SoftOSS software synthesizer instead of the builtin OPL3. -Here's how: - -Say 'y' or 'm' to "SoftOSS software wave table engine" in make config. - -If you said yes, the software synth is available once you boot your new -kernel. - -If you chose to build it as a module, just insmod the resulting softoss2.o - -Questions? Comments? -<stiker@northlink.com> diff --git a/Documentation/sound/oss/README.awe b/Documentation/sound/oss/README.awe deleted file mode 100644 index 80054cd8fcde..000000000000 --- a/Documentation/sound/oss/README.awe +++ /dev/null @@ -1,218 +0,0 @@ -================================================================ - AWE32 Sound Driver for Linux / FreeBSD - version 0.4.3; Nov. 1, 1998 - - Takashi Iwai <iwai@ww.uni-erlangen.de> -================================================================ - -* GENERAL NOTES - -This is a sound driver extension for SoundBlaster AWE32 and other -compatible cards (AWE32-PnP, SB32, SB32-PnP, AWE64 & etc) to enable -the wave synth operations. The driver is provided for Linux 1.2.x -and 2.[012].x kernels, as well as FreeBSD, on Intel x86 and DEC -Alpha systems. - -This driver was written by Takashi Iwai <iwai@ww.uni-erlangen.de>, -and provided "as is". The original source (awedrv-0.4.3.tar.gz) and -binary packages are available on the following URL: - http://bahamut.mm.t.u-tokyo.ac.jp/~iwai/awedrv/ -Note that since the author is apart from this web site, the update is -not frequent now. - - -* NOTE TO LINUX USERS - -To enable this driver on linux-2.[01].x kernels, you need turn on -"AWE32 synth" options in sound menu when configure your linux kernel -and modules. The precise installation procedure is described in the -AWE64-Mini-HOWTO and linux-kernel/Documetation/sound/AWE32. - -If you're using PnP cards, the card must be initialized before loading -the sound driver. There're several options to do this: - - Initialize the card via ISA PnP tools, and load the sound module. - - Initialize the card on DOS, and load linux by loadlin.exe - - Use PnP kernel driver (for Linux-2.x.x) -The detailed instruction for the solution using isapnp tools is found -in many documents like above. A brief instruction is also included in -the installation document of this package. -For PnP driver project, please refer to the following URL: - http://www-jcr.lmh.ox.ac.uk/~pnp/ - - -* USING THE DRIVER - -The awedrv has several different playing modes to realize easy channel -allocation for MIDI songs. To hear the exact sound quality, you need -to obtain the extended sequencer program, drvmidi or playmidi-2.5. - -For playing MIDI files, you *MUST* load the soundfont file on the -driver previously by sfxload utility. Otherwise you'll here no sounds -at all! All the utilities and driver source packages are found in the -above URL. The sfxload program is included in the package -awesfx-0.4.3.tgz. Binary packages are available there, too. See the -instruction in each package for installation. - -Loading a soundfont file is very simple. Just execute the command - - % sfxload synthgm.sbk - -Then, sfxload transfers the file "synthgm.sbk" to the driver. -Both SF1 and SF2 formats are accepted. - -Now you can hear midi musics by a midi player. - - % drvmidi foo.mid - -If you run MIDI player after MOD player, you need to load soundfont -files again, since MOD player programs clear the previous loaded -samples by their own data. - -If you have only 512kb on the sound card, I recommend to use dynamic -sample loading via -L option of drvmidi. 2MB GM/GS soundfont file is -available in most midi files. - - % sfxload synthgm - % drvmidi -L 2mbgmgs foo.mid - -This makes a big difference (believe me)! For more details, please -refer to the FAQ list which is available on the URL above. - -The current chorus, reverb and equalizer status can be changed by -aweset utility program (included in awesfx package). Note that -some awedrv-native programs (like drvmidi and xmp) will change the -current settings by themselves. The aweset program is effective -only for other programs like playmidi. - -Enjoy. - - -* COMPILE FLAGS - -Compile conditions are defined in awe_config.h. - -[Compatibility Conditions] -The following flags are defined automatically when using installation -shell script. - -- AWE_MODULE_SUPPORT - indicates your Linux kernel supports module for each sound card - (in recent 2.1 or 2.2 kernels and unofficial patched 2.0 kernels - as distributed in the RH5.0 package). - This flag is automatically set when you're using 2.1.x kernels. - You can pass the base address and memory size via the following - module options, - io = base I/O port address (eg. 0x620) - memsize = DRAM size in kilobytes (eg. 512) - As default, AWE driver probes these values automatically. - - -[Hardware Conditions] -You DON'T have to define the following two values. -Define them only when the driver couldn't detect the card properly. - -- AWE_DEFAULT_BASE_ADDR (default: not defined) - specifies the base port address of your AWE32 card. - 0 means to autodetect the address. - -- AWE_DEFAULT_MEM_SIZE (default: not defined) - specifies the memory size of your AWE32 card in kilobytes. - -1 means to autodetect its size. - - -[Sample Table Size] -From ver.0.4.0, sample tables are allocated dynamically (except -Linux-1.2.x system), so you need NOT to touch these parameters. -Linux-1.2.x users may need to increase these values to appropriate size -if the sound card is equipped with more DRAM. - -- AWE_MAX_SF_LISTS, AWE_MAX_SAMPLES, AWE_MAX_INFOS - - -[Other Conditions] - -- AWE_ALWAYS_INIT_FM (default: not defined) - indicates the AWE driver always initialize FM passthrough even - without DRAM on board. Emu8000 chip has a restriction for playing - samples on DRAM that at least two channels must be occupied as - passthrough channels. - -- AWE_DEBUG_ON (default: defined) - turns on debugging messages if defined. - -- AWE_HAS_GUS_COMPATIBILITY (default: defined) - Enables GUS compatibility mode if defined, reading GUS patches and - GUS control commands. Define this option to use GMOD or other - GUS module players. - -- CONFIG_AWE32_MIDIEMU (default: defined) - Adds a MIDI emulation device by Emu8000 wavetable. The emulation - device can be accessed as an external MIDI, and sends the MIDI - control codes directly. XG and GS sysex/NRPN are accepted. - No MIDI input is supported. - -- CONFIG_AWE32_MIXER (default: not defined) - Adds a mixer device for AWE32 bass/treble equalizer control. - You can access this device using /dev/mixer?? (usually mixer01). - -- AWE_USE_NEW_VOLUME_CALC (default: defined) - Use the new method to calculate the volume change as compatible - with DOS/Win drivers. This option can be toggled via aweset - program, or drvmidi player. - -- AWE_CHECK_VTARGET (default: defined) - Check the current volume target value when searching for an - empty channel to allocate a new voice. This is experimentally - implemented in this version. (probably, this option doesn't - affect the sound quality severely...) - -- AWE_ALLOW_SAMPLE_SHARING (default: defined) - Allow sample sharing for differently loaded patches. - This function is available only together with awesfx-0.4.3p3. - Note that this is still an experimental option. - -- DEF_FM_CHORUS_DEPTH (default: 0x10) - The default strength to be sent to the chorus effect engine. - From 0 to 0xff. Larger numbers may often cause weird sounds. - -- DEF_FM_REVERB_DEPTH (default: 0x10) - The default strength to be sent to the reverb effect engine. - From 0 to 0xff. Larger numbers may often cause weird sounds. - - -* ACKNOWLEDGMENTS - -Thanks to Witold Jachimczyk (witek@xfactor.wpi.edu) for much advice -on programming of AWE32. Much code is brought from his AWE32-native -MOD player, ALMP. -The port of awedrv to FreeBSD is done by Randall Hopper -(rhh@ct.picker.com). -The new volume calculation routine was derived from Mark Weaver's -ADIP compatible routines. -I also thank linux-awe-ml members for their efforts -to reboot their system many times :-) - - -* TODO'S - -- Complete DOS/Win compatibility -- DSP-like output - - -* COPYRIGHT - -Copyright (C) 1996-1998 Takashi Iwai - -This program is free software; you can redistribute it and/or modify -it under the terms of the GNU General Public License as published by -the Free Software Foundation; either version 2 of the License, or -(at your option) any later version. - -This program is distributed in the hope that it will be useful, -but WITHOUT ANY WARRANTY; without even the implied warranty of -MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -GNU General Public License for more details. - -You should have received a copy of the GNU General Public License -along with this program; if not, write to the Free Software -Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. diff --git a/Documentation/sound/oss/Wavefront b/Documentation/sound/oss/Wavefront deleted file mode 100644 index 16f57ea43052..000000000000 --- a/Documentation/sound/oss/Wavefront +++ /dev/null @@ -1,339 +0,0 @@ - An OSS/Free Driver for WaveFront soundcards - (Turtle Beach Maui, Tropez, Tropez Plus) - - Paul Barton-Davis, July 1998 - - VERSION 0.2.5 - -Driver Status -------------- - -Requires: Kernel 2.1.106 or later (the driver is included with kernels -2.1.109 and above) - -As of 7/22/1998, this driver is currently in *BETA* state. This means -that it compiles and runs, and that I use it on my system (Linux -2.1.106) with some reasonably demanding applications and uses. I -believe the code is approaching an initial "finished" state that -provides bug-free support for the Tropez Plus. - -Please note that to date, the driver has ONLY been tested on a Tropez -Plus. I would very much like to hear (and help out) people with Tropez -and Maui cards, since I think the driver can support those cards as -well. - -Finally, the driver has not been tested (or even compiled) as a static -(non-modular) part of the kernel. Alan Cox's good work in modularizing -OSS/Free for Linux makes this rather unnecessary. - -Some Questions --------------- - -********************************************************************** -0) What does this driver do that the maui driver did not ? -********************************************************************** - -* can fully initialize a WaveFront card from cold boot - no DOS - utilities needed -* working patch/sample/program loading and unloading (the maui - driver didn't document how to make this work, and assumed - user-level preparation of the patch data for writing - to the board. ick.) -* full user-level access to all WaveFront commands -* for the Tropez Plus, (primitive) control of the YSS225 FX processor -* Virtual MIDI mode supported - 2 MIDI devices accessible via the - WaveFront's MPU401/UART emulation. One - accesses the WaveFront synth, the other accesses the - external MIDI connector. Full MIDI read/write semantics - for both devices. -* OSS-compliant /dev/sequencer interface for the WaveFront synth, - including native and GUS-format patch downloading. -* semi-intelligent patch management (prototypical at this point) - -********************************************************************** -1) What to do about MIDI interfaces ? -********************************************************************** - -The Tropez Plus (and perhaps other WF cards) can in theory support up -to 2 physical MIDI interfaces. One of these is connected to the -ICS2115 chip (the WaveFront synth itself) and is controlled by -MPU/UART-401 emulation code running as part of the WaveFront OS. The -other is controlled by the CS4232 chip present on the board. However, -physical access to the CS4232 connector is difficult, and it is -unlikely (though not impossible) that you will want to use it. - -An older version of this driver introduced an additional kernel config -variable which controlled whether or not the CS4232 MIDI interface was -configured. Because of Alan Cox's work on modularizing the sound -drivers, and now backporting them to 2.0.34 kernels, there seems to be -little reason to support "static" configuration variables, and so this -has been abandoned in favor of *only* module parameters. Specifying -"mpuio" and "mpuirq" for the cs4232 parameter will result in the -CS4232 MIDI interface being configured; leaving them unspecified will -leave it unconfigured (and thus unusable). - -BTW, I have heard from one Tropez+ user that the CS4232 interface is -more reliable than the ICS2115 one. I have had no problems with the -latter, and I don't have the right cable to test the former one -out. Reports welcome. - -********************************************************************** -2) Why does line XXX of the code look like this .... ? -********************************************************************** - -Either because it's not finished yet, or because you're a better coder -than I am, or because you don't understand some aspect of how the card -or the code works. - -I absolutely welcome comments, criticisms and suggestions about the -design and implementation of the driver. - -********************************************************************** -3) What files are included ? -********************************************************************** - - drivers/sound/README.wavefront -- this file - - drivers/sound/wavefront.patch -- patches for the 2.1.106 sound drivers - needed to make the rest of this work - DO NOT USE IF YOU'VE APPLIED THEM - BEFORE, OR HAVE 2.1.109 OR ABOVE - - drivers/sound/wavfront.c -- the driver - drivers/sound/ys225.h -- data declarations for FX config - drivers/sound/ys225.c -- data definitions for FX config - drivers/sound/wf_midi.c -- the "uart401" driver - to support virtual MIDI mode. - include/wavefront.h -- the header file - Documentation/sound/oss/Tropez+ -- short docs on configuration - -********************************************************************** -4) How do I compile/install/use it ? -********************************************************************** - -PART ONE: install the source code into your sound driver directory - - cd <top-of-your-2.1.106-code-base-e.g.-/usr/src/linux> - tar -zxvf <where-you-put/wavefront.tar.gz> - -PART TWO: apply the patches - - DO THIS ONLY IF YOU HAVE A KERNEL VERSION BELOW 2.1.109 - AND HAVE NOT ALREADY INSTALLED THE PATCH(ES). - - cd drivers/sound - patch < wavefront.patch - -PART THREE: configure your kernel - - cd <top of your kernel tree> - make xconfig (or whichever config option you use) - - - choose YES for Sound Support - - choose MODULE (M) for OSS Sound Modules - - choose MODULE(M) to YM3812/OPL3 support - - choose MODULE(M) for WaveFront support - - choose MODULE(M) for CS4232 support - - - choose "N" for everything else (unless you have other - soundcards you want support for) - - - make boot - . - . - . - <whatever you normally do for a kernel install> - make modules - . - . - . - make modules_install - -Here's my autoconf.h SOUND section: - -/* - * Sound - */ -#define CONFIG_SOUND 1 -#undef CONFIG_SOUND_OSS -#define CONFIG_SOUND_OSS_MODULE 1 -#undef CONFIG_SOUND_PAS -#undef CONFIG_SOUND_SB -#undef CONFIG_SOUND_ADLIB -#undef CONFIG_SOUND_GUS -#undef CONFIG_SOUND_MPU401 -#undef CONFIG_SOUND_PSS -#undef CONFIG_SOUND_MSS -#undef CONFIG_SOUND_SSCAPE -#undef CONFIG_SOUND_TRIX -#undef CONFIG_SOUND_MAD16 -#undef CONFIG_SOUND_WAVEFRONT -#define CONFIG_SOUND_WAVEFRONT_MODULE 1 -#undef CONFIG_SOUND_CS4232 -#define CONFIG_SOUND_CS4232_MODULE 1 -#undef CONFIG_SOUND_MAUI -#undef CONFIG_SOUND_SGALAXY -#undef CONFIG_SOUND_OPL3SA1 -#undef CONFIG_SOUND_SOFTOSS -#undef CONFIG_SOUND_YM3812 -#define CONFIG_SOUND_YM3812_MODULE 1 -#undef CONFIG_SOUND_VMIDI -#undef CONFIG_SOUND_UART6850 -/* - * Additional low level sound drivers - */ -#undef CONFIG_LOWLEVEL_SOUND - -************************************************************ -6) How do I configure my card ? -************************************************************ - -You need to edit /etc/modprobe.conf. Here's mine (edited to show the -relevant details): - - # Sound system - alias char-major-14-* wavefront - alias synth0 wavefront - alias mixer0 cs4232 - alias audio0 cs4232 - install wavefront /sbin/modprobe cs4232 && /sbin/modprobe -i wavefront && /sbin/modprobe opl3 - options wavefront io=0x200 irq=9 - options cs4232 synthirq=9 synthio=0x200 io=0x530 irq=5 dma=1 dma2=0 - options opl3 io=0x388 - -Things to note: - - the wavefront options "io" and "irq" ***MUST*** match the "synthio" - and "synthirq" cs4232 options. - - you can do without the opl3 module if you don't - want to use the OPL/[34] FM synth on the soundcard - - the opl3 io parameter is conventionally not adjustable. - In theory, any not-in-use IO port address would work, but - just use 0x388 and stick with the crowd. - -********************************************************************** -7) What about firmware ? -********************************************************************** - -Turtle Beach have not given me permission to distribute their firmware -for the ICS2115. However, if you have a WaveFront card, then you -almost certainly have the firmware, and if not, its freely available -on their website, at: - - http://www.tbeach.com/tbs/downloads/scardsdown.htm#tropezplus - -The file is called WFOS2001.MOT (for the Tropez+). - -This driver, however, doesn't use the pure firmware as distributed, -but instead relies on a somewhat processed form of it. You can -generate this very easily. Following an idea from Andrew Veliath's -Pinnacle driver, the following flex program will generate the -processed version: - ----- cut here ------------------------- -%option main -%% -^S[28].*\r$ printf ("%c%.*s", yyleng-1,yyleng-1,yytext); -<<EOF>> { fputc ('\0', stdout); return; } -\n {} -. {} ----- cut here ------------------------- - -To use it, put the above in file (say, ws.l) compile it like this: - - shell> flex -ows.c ws.l - shell> cc -o ws ws.c - -and then use it like this: - - ws < my-copy-of-the-oswf.mot-file > /etc/sound/wavefront.os - -If you put it somewhere else, you'll always have to use the wf_ospath -module parameter (see below) or alter the source code. - -********************************************************************** -7) How do I get it working ? -********************************************************************** - -Optionally, you can reboot with the "new" kernel (even though the only -changes have really been made to a module). - -Then, as root do: - - modprobe wavefront - -You should get something like this in /var/log/messages: - - WaveFront: firmware 1.20 already loaded. - -or - - WaveFront: no response to firmware probe, assume raw. - -then: - - WaveFront: waiting for memory configuration ... - WaveFront: hardware version 1.64 - WaveFront: available DRAM 8191k - WaveFront: 332 samples used (266 real, 13 aliases, 53 multi), 180 empty - WaveFront: 128 programs slots in use - WaveFront: 256 patch slots filled, 142 in use - -The whole process takes about 16 seconds, the longest waits being -after reporting the hardware version (during the firmware download), -and after reporting program status (during patch status inquiry). Its -shorter (about 10 secs) if the firmware is already loaded (i.e. only -warm reboots since the last firmware load). - -The "available DRAM" line will vary depending on how much added RAM -your card has. Mine has 8MB. - -To check basically functionality, use play(1) or splay(1) to send a -.WAV or other audio file through the audio portion. Then use playmidi -to play a General MIDI file. Try the "-D 0" to hear the -difference between sending MIDI to the WaveFront and using the OPL/3, -which is the default (I think ...). If you have an external synth(s) -hooked to the soundcard, you can use "-e" to route to the -external synth(s) (in theory, -D 1 should work as well, but I think -there is a bug in playmidi which prevents this from doing what it -should). - -********************************************************************** -8) What are the module parameters ? -********************************************************************** - -Its best to read wavefront.c for this, but here is a summary: - -integers: - wf_raw - if set, ignore apparent presence of firmware - loaded onto the ICS2115, reset the whole - board, and initialize it from scratch. (default = 0) - - fx_raw - if set, always initialize the YSS225 processor - on the Tropez plus. (default = 1) - - < The next 4 are basically for kernel hackers to allow - tweaking the driver for testing purposes. > - - wait_usecs - loop timer used when waiting for - status conditions on the board. - The default is 150. - - debug_default - debugging flags. See sound/wavefront.h - for WF_DEBUG_* values. Default is zero. - Setting this allows you to debug the - driver during module installation. -strings: - ospath - path to get to the pre-processed OS firmware. - (default: /etc/sound/wavefront.os) - -********************************************************************** -9) Who should I contact if I have problems? -********************************************************************** - -Just me: Paul Barton-Davis <pbd@op.net> - - diff --git a/Documentation/sound/oss/es1370 b/Documentation/sound/oss/es1370 deleted file mode 100644 index 7b38b1a096a3..000000000000 --- a/Documentation/sound/oss/es1370 +++ /dev/null @@ -1,70 +0,0 @@ -/proc/sound, /dev/sndstat -------------------------- - -/proc/sound and /dev/sndstat is not supported by the -driver. To find out whether the driver succeeded loading, -check the kernel log (dmesg). - - -ALaw/uLaw sample formats ------------------------- - -This driver does not support the ALaw/uLaw sample formats. -ALaw is the default mode when opening a sound device -using OSS/Free. The reason for the lack of support is -that the hardware does not support these formats, and adding -conversion routines to the kernel would lead to very ugly -code in the presence of the mmap interface to the driver. -And since xquake uses mmap, mmap is considered important :-) -and no sane application uses ALaw/uLaw these days anyway. -In short, playing a Sun .au file as follows: - -cat my_file.au > /dev/dsp - -does not work. Instead, you may use the play script from -Chris Bagwell's sox-12.14 package (available from the URL -below) to play many different audio file formats. -The script automatically determines the audio format -and does do audio conversions if necessary. -http://home.sprynet.com/sprynet/cbagwell/projects.html - - -Blocking vs. nonblocking IO ---------------------------- - -Unlike OSS/Free this driver honours the O_NONBLOCK file flag -not only during open, but also during read and write. -This is an effort to make the sound driver interface more -regular. Timidity has problems with this; a patch -is available from http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html. -(Timidity patched will also run on OSS/Free). - - -MIDI UART ---------- - -The driver supports a simple MIDI UART interface, with -no ioctl's supported. - - -MIDI synthesizer ----------------- - -This soundcard does not have any hardware MIDI synthesizer; -MIDI synthesis has to be done in software. To allow this -the driver/soundcard supports two PCM (/dev/dsp) interfaces. -The second one goes to the mixer "synth" setting and supports -only a limited set of sampling rates (44100, 22050, 11025, 5512). -By setting lineout to 1 on the driver command line -(eg. insmod es1370 lineout=1) it is even possible on some -cards to convert the LINEIN jack into a second LINEOUT jack, thus -making it possible to output four independent audio channels! - -There is a freely available software package that allows -MIDI file playback on this soundcard called Timidity. -See http://www.cgs.fi/~tt/timidity/. - - - -Thomas Sailer -t.sailer@alumni.ethz.ch diff --git a/Documentation/sound/oss/rme96xx b/Documentation/sound/oss/rme96xx deleted file mode 100644 index 87d7b7b65fa1..000000000000 --- a/Documentation/sound/oss/rme96xx +++ /dev/null @@ -1,767 +0,0 @@ -Beta release of the rme96xx (driver for RME 96XX cards like the -"Hammerfall" and the "Hammerfall light") - -Important: The driver module has to be installed on a freshly rebooted system, -otherwise the driver might not be able to acquire its buffers. - -features: - - - OSS programming interface (i.e. runs with standard OSS soundsoftware) - - OSS/Multichannel interface (OSS multichannel is done by just aquiring - more than 2 channels). The driver does not use more than one device - ( yet .. this feature may be implemented later ) - - more than one RME card supported - -The driver uses a specific multichannel interface, which I will document -when the driver gets stable. (take a look at the defines in rme96xx.h, -which adds blocked multichannel formats i.e instead of -lrlrlrlr --> llllrrrr etc. - -Use the "rmectrl" programm to look at the status of the card .. -or use xrmectrl, a GUI interface for the ctrl program. - -What you can do with the rmectrl program is to set the stereo device for -OSS emulation (e.g. if you use SPDIF out). - -You do: - -./ctrl offset 24 24 - -which makes the stereo device use channels 25 and 26. - -Guenter Geiger <geiger@epy.co.at> - -copy the first part of the attached source code into rmectrl.c -and the second part into xrmectrl (or get the program from -http://gige.xdv.org/pages/soft/pages/rme) - -to compile: gcc -o rmectrl rmectrl.c ------------------------------- snip ------------------------------------ - -#include <stdio.h> -#include <sys/types.h> -#include <sys/stat.h> -#include <sys/ioctl.h> -#include <fcntl.h> -#include <linux/soundcard.h> -#include <math.h> -#include <unistd.h> -#include <stdlib.h> -#include "rme96xx.h" - -/* - remctrl.c - (C) 2000 Guenter Geiger <geiger@debian.org> - HP20020201 - Heiko Purnhagen <purnhage@tnt.uni-hannover.de> -*/ - -/* # define DEVICE_NAME "/dev/mixer" */ -# define DEVICE_NAME "/dev/mixer1" - - -void usage(void) -{ - fprintf(stderr,"usage: rmectrl [/dev/mixer<n>] [command [options]]\n\n"); - fprintf(stderr,"where command is one of:\n"); - fprintf(stderr," help show this help\n"); - fprintf(stderr," status show status bits\n"); - fprintf(stderr," control show control bits\n"); - fprintf(stderr," mix show mixer/offset status\n"); - fprintf(stderr," master <n> set sync master\n"); - fprintf(stderr," pro <n> set spdif out pro\n"); - fprintf(stderr," emphasis <n> set spdif out emphasis\n"); - fprintf(stderr," dolby <n> set spdif out no audio\n"); - fprintf(stderr," optout <n> set spdif out optical\n"); - fprintf(stderr," wordclock <n> set sync wordclock\n"); - fprintf(stderr," spdifin <n> set spdif in (0=optical,1=coax,2=intern)\n"); - fprintf(stderr," syncref <n> set sync source (0=ADAT1,1=ADAT2,2=ADAT3,3=SPDIF)\n"); - fprintf(stderr," adat1cd <n> set ADAT1 on internal CD\n"); - fprintf(stderr," offset <devnr> <in> <out> set dev (0..3) offset (0..25)\n"); - exit(-1); -} - - -int main(int argc, char* argv[]) -{ - int cards; - int ret; - int i; - double ft; - int fd, fdwr; - int param,orig; - rme_status_t stat; - rme_ctrl_t ctrl; - char *device; - int argidx; - - if (argc < 2) - usage(); - - if (*argv[1]=='/') { - device = argv[1]; - argidx = 2; - } - else { - device = DEVICE_NAME; - argidx = 1; - } - - fprintf(stdout,"mixer device %s\n",device); - if ((fd = open(device,O_RDONLY)) < 0) { - fprintf(stdout,"opening device failed\n"); - exit(-1); - } - - if ((fdwr = open(device,O_WRONLY)) < 0) { - fprintf(stdout,"opening device failed\n"); - exit(-1); - } - - if (argc < argidx+1) - usage(); - - if (!strcmp(argv[argidx],"help")) - usage(); - if (!strcmp(argv[argidx],"-h")) - usage(); - if (!strcmp(argv[argidx],"--help")) - usage(); - - if (!strcmp(argv[argidx],"status")) { - ioctl(fd,SOUND_MIXER_PRIVATE2,&stat); - fprintf(stdout,"stat.irq %d\n",stat.irq); - fprintf(stdout,"stat.lockmask %d\n",stat.lockmask); - fprintf(stdout,"stat.sr48 %d\n",stat.sr48); - fprintf(stdout,"stat.wclock %d\n",stat.wclock); - fprintf(stdout,"stat.bufpoint %d\n",stat.bufpoint); - fprintf(stdout,"stat.syncmask %d\n",stat.syncmask); - fprintf(stdout,"stat.doublespeed %d\n",stat.doublespeed); - fprintf(stdout,"stat.tc_busy %d\n",stat.tc_busy); - fprintf(stdout,"stat.tc_out %d\n",stat.tc_out); - fprintf(stdout,"stat.crystalrate %d (0=64k 3=96k 4=88.2k 5=48k 6=44.1k 7=32k)\n",stat.crystalrate); - fprintf(stdout,"stat.spdif_error %d\n",stat.spdif_error); - fprintf(stdout,"stat.bufid %d\n",stat.bufid); - fprintf(stdout,"stat.tc_valid %d\n",stat.tc_valid); - exit (0); - } - - if (!strcmp(argv[argidx],"control")) { - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - fprintf(stdout,"ctrl.start %d\n",ctrl.start); - fprintf(stdout,"ctrl.latency %d (0=64 .. 7=8192)\n",ctrl.latency); - fprintf(stdout,"ctrl.master %d\n",ctrl.master); - fprintf(stdout,"ctrl.ie %d\n",ctrl.ie); - fprintf(stdout,"ctrl.sr48 %d\n",ctrl.sr48); - fprintf(stdout,"ctrl.spare %d\n",ctrl.spare); - fprintf(stdout,"ctrl.doublespeed %d\n",ctrl.doublespeed); - fprintf(stdout,"ctrl.pro %d\n",ctrl.pro); - fprintf(stdout,"ctrl.emphasis %d\n",ctrl.emphasis); - fprintf(stdout,"ctrl.dolby %d\n",ctrl.dolby); - fprintf(stdout,"ctrl.opt_out %d\n",ctrl.opt_out); - fprintf(stdout,"ctrl.wordclock %d\n",ctrl.wordclock); - fprintf(stdout,"ctrl.spdif_in %d (0=optical,1=coax,2=intern)\n",ctrl.spdif_in); - fprintf(stdout,"ctrl.sync_ref %d (0=ADAT1,1=ADAT2,2=ADAT3,3=SPDIF)\n",ctrl.sync_ref); - fprintf(stdout,"ctrl.spdif_reset %d\n",ctrl.spdif_reset); - fprintf(stdout,"ctrl.spdif_select %d\n",ctrl.spdif_select); - fprintf(stdout,"ctrl.spdif_clock %d\n",ctrl.spdif_clock); - fprintf(stdout,"ctrl.spdif_write %d\n",ctrl.spdif_write); - fprintf(stdout,"ctrl.adat1_cd %d\n",ctrl.adat1_cd); - exit (0); - } - - if (!strcmp(argv[argidx],"mix")) { - rme_mixer mix; - int i; - - for (i=0; i<4; i++) { - mix.devnr = i; - ioctl(fd,SOUND_MIXER_PRIVATE1,&mix); - if (mix.devnr == i) { - fprintf(stdout,"devnr %d\n",mix.devnr); - fprintf(stdout,"mix.i_offset %2d (0-25)\n",mix.i_offset); - fprintf(stdout,"mix.o_offset %2d (0-25)\n",mix.o_offset); - } - } - exit (0); - } - -/* the control flags */ - - if (argc < argidx+2) - usage(); - - if (!strcmp(argv[argidx],"master")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("master = %d\n",val); - ctrl.master = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"pro")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("pro = %d\n",val); - ctrl.pro = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"emphasis")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("emphasis = %d\n",val); - ctrl.emphasis = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"dolby")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("dolby = %d\n",val); - ctrl.dolby = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"optout")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("optout = %d\n",val); - ctrl.opt_out = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"wordclock")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("wordclock = %d\n",val); - ctrl.wordclock = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"spdifin")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("spdifin = %d\n",val); - ctrl.spdif_in = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"syncref")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("syncref = %d\n",val); - ctrl.sync_ref = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - - if (!strcmp(argv[argidx],"adat1cd")) { - int val = atoi(argv[argidx+1]); - ioctl(fd,SOUND_MIXER_PRIVATE3,&ctrl); - printf("adat1cd = %d\n",val); - ctrl.adat1_cd = val; - ioctl(fdwr,SOUND_MIXER_PRIVATE3,&ctrl); - exit (0); - } - -/* setting offset */ - - if (argc < argidx+4) - usage(); - - if (!strcmp(argv[argidx],"offset")) { - rme_mixer mix; - - mix.devnr = atoi(argv[argidx+1]); - - mix.i_offset = atoi(argv[argidx+2]); - mix.o_offset = atoi(argv[argidx+3]); - ioctl(fdwr,SOUND_MIXER_PRIVATE1,&mix); - fprintf(stdout,"devnr %d\n",mix.devnr); - fprintf(stdout,"mix.i_offset to %d\n",mix.i_offset); - fprintf(stdout,"mix.o_offset to %d\n",mix.o_offset); - exit (0); - } - - usage(); - exit (0); /* to avoid warning */ -} - - ----------------------------- <snip> -------------------------------- -#!/usr/bin/wish - -# xrmectrl -# (C) 2000 Guenter Geiger <geiger@debian.org> -# HP20020201 - Heiko Purnhagen <purnhage@tnt.uni-hannover.de> - -#set defaults "-relief ridged" -set CTRLPROG "./rmectrl" -if {$argc} { - set CTRLPROG "$CTRLPROG $argv" -} -puts "CTRLPROG $CTRLPROG" - -frame .butts -button .butts.exit -text "Exit" -command "exit" -relief ridge -#button .butts.state -text "State" -command "get_all" - -pack .butts.exit -side left -pack .butts -side bottom - - -# -# STATUS -# - -frame .status - -# Sampling Rate - -frame .status.sr -label .status.sr.text -text "Sampling Rate" -justify left -radiobutton .status.sr.441 -selectcolor red -text "44.1 kHz" -width 10 -anchor nw -variable srate -value 44100 -font times -radiobutton .status.sr.480 -selectcolor red -text "48 kHz" -width 10 -anchor nw -variable srate -value 48000 -font times -radiobutton .status.sr.882 -selectcolor red -text "88.2 kHz" -width 10 -anchor nw -variable srate -value 88200 -font times -radiobutton .status.sr.960 -selectcolor red -text "96 kHz" -width 10 -anchor nw -variable srate -value 96000 -font times - -pack .status.sr.text .status.sr.441 .status.sr.480 .status.sr.882 .status.sr.960 -side top -padx 3 - -# Lock - -frame .status.lock -label .status.lock.text -text "Lock" -justify left -checkbutton .status.lock.adat1 -selectcolor red -text "ADAT1" -anchor nw -width 10 -variable adatlock1 -font times -checkbutton .status.lock.adat2 -selectcolor red -text "ADAT2" -anchor nw -width 10 -variable adatlock2 -font times -checkbutton .status.lock.adat3 -selectcolor red -text "ADAT3" -anchor nw -width 10 -variable adatlock3 -font times - -pack .status.lock.text .status.lock.adat1 .status.lock.adat2 .status.lock.adat3 -side top -padx 3 - -# Sync - -frame .status.sync -label .status.sync.text -text "Sync" -justify left -checkbutton .status.sync.adat1 -selectcolor red -text "ADAT1" -anchor nw -width 10 -variable adatsync1 -font times -checkbutton .status.sync.adat2 -selectcolor red -text "ADAT2" -anchor nw -width 10 -variable adatsync2 -font times -checkbutton .status.sync.adat3 -selectcolor red -text "ADAT3" -anchor nw -width 10 -variable adatsync3 -font times - -pack .status.sync.text .status.sync.adat1 .status.sync.adat2 .status.sync.adat3 -side top -padx 3 - -# Timecode - -frame .status.tc -label .status.tc.text -text "Timecode" -justify left -checkbutton .status.tc.busy -selectcolor red -text "busy" -anchor nw -width 10 -variable tcbusy -font times -checkbutton .status.tc.out -selectcolor red -text "out" -anchor nw -width 10 -variable tcout -font times -checkbutton .status.tc.valid -selectcolor red -text "valid" -anchor nw -width 10 -variable tcvalid -font times - -pack .status.tc.text .status.tc.busy .status.tc.out .status.tc.valid -side top -padx 3 - -# SPDIF In - -frame .status.spdif -label .status.spdif.text -text "SPDIF In" -justify left -label .status.spdif.sr -text "--.- kHz" -anchor n -width 10 -font times -checkbutton .status.spdif.error -selectcolor red -text "Input Lock" -anchor nw -width 10 -variable spdiferr -font times - -pack .status.spdif.text .status.spdif.sr .status.spdif.error -side top -padx 3 - -pack .status.sr .status.lock .status.sync .status.tc .status.spdif -side left -fill x -anchor n -expand 1 - - -# -# CONTROL -# - -proc setprof {} { - global CTRLPROG - global spprof - exec $CTRLPROG pro $spprof -} - -proc setemph {} { - global CTRLPROG - global spemph - exec $CTRLPROG emphasis $spemph -} - -proc setnoaud {} { - global CTRLPROG - global spnoaud - exec $CTRLPROG dolby $spnoaud -} - -proc setoptical {} { - global CTRLPROG - global spoptical - exec $CTRLPROG optout $spoptical -} - -proc setspdifin {} { - global CTRLPROG - global spdifin - exec $CTRLPROG spdifin [expr $spdifin - 1] -} - -proc setsyncsource {} { - global CTRLPROG - global syncsource - exec $CTRLPROG syncref [expr $syncsource -1] -} - - -proc setmaster {} { - global CTRLPROG - global master - exec $CTRLPROG master $master -} - -proc setwordclock {} { - global CTRLPROG - global wordclock - exec $CTRLPROG wordclock $wordclock -} - -proc setadat1cd {} { - global CTRLPROG - global adat1cd - exec $CTRLPROG adat1cd $adat1cd -} - - -frame .control - -# SPDIF In & SPDIF Out - - -frame .control.spdif - -frame .control.spdif.in -label .control.spdif.in.text -text "SPDIF In" -justify left -radiobutton .control.spdif.in.input1 -text "Optical" -anchor nw -width 13 -variable spdifin -value 1 -command setspdifin -selectcolor blue -font times -radiobutton .control.spdif.in.input2 -text "Coaxial" -anchor nw -width 13 -variable spdifin -value 2 -command setspdifin -selectcolor blue -font times -radiobutton .control.spdif.in.input3 -text "Intern " -anchor nw -width 13 -variable spdifin -command setspdifin -value 3 -selectcolor blue -font times - -checkbutton .control.spdif.in.adat1cd -text "ADAT1 Intern" -anchor nw -width 13 -variable adat1cd -command setadat1cd -selectcolor blue -font times - -pack .control.spdif.in.text .control.spdif.in.input1 .control.spdif.in.input2 .control.spdif.in.input3 .control.spdif.in.adat1cd - -label .control.spdif.space - -frame .control.spdif.out -label .control.spdif.out.text -text "SPDIF Out" -justify left -checkbutton .control.spdif.out.pro -text "Professional" -anchor nw -width 13 -variable spprof -command setprof -selectcolor blue -font times -checkbutton .control.spdif.out.emphasis -text "Emphasis" -anchor nw -width 13 -variable spemph -command setemph -selectcolor blue -font times -checkbutton .control.spdif.out.dolby -text "NoAudio" -anchor nw -width 13 -variable spnoaud -command setnoaud -selectcolor blue -font times -checkbutton .control.spdif.out.optout -text "Optical Out" -anchor nw -width 13 -variable spoptical -command setoptical -selectcolor blue -font times - -pack .control.spdif.out.optout .control.spdif.out.dolby .control.spdif.out.emphasis .control.spdif.out.pro .control.spdif.out.text -side bottom - -pack .control.spdif.in .control.spdif.space .control.spdif.out -side top -fill y -padx 3 -expand 1 - -# Sync Mode & Sync Source - -frame .control.sync -frame .control.sync.mode -label .control.sync.mode.text -text "Sync Mode" -justify left -checkbutton .control.sync.mode.master -text "Master" -anchor nw -width 13 -variable master -command setmaster -selectcolor blue -font times -checkbutton .control.sync.mode.wc -text "Wordclock" -anchor nw -width 13 -variable wordclock -command setwordclock -selectcolor blue -font times - -pack .control.sync.mode.text .control.sync.mode.master .control.sync.mode.wc - -label .control.sync.space - -frame .control.sync.src -label .control.sync.src.text -text "Sync Source" -justify left -radiobutton .control.sync.src.input1 -text "ADAT1" -anchor nw -width 13 -variable syncsource -value 1 -command setsyncsource -selectcolor blue -font times -radiobutton .control.sync.src.input2 -text "ADAT2" -anchor nw -width 13 -variable syncsource -value 2 -command setsyncsource -selectcolor blue -font times -radiobutton .control.sync.src.input3 -text "ADAT3" -anchor nw -width 13 -variable syncsource -command setsyncsource -value 3 -selectcolor blue -font times -radiobutton .control.sync.src.input4 -text "SPDIF" -anchor nw -width 13 -variable syncsource -command setsyncsource -value 4 -selectcolor blue -font times - -pack .control.sync.src.input4 .control.sync.src.input3 .control.sync.src.input2 .control.sync.src.input1 .control.sync.src.text -side bottom - -pack .control.sync.mode .control.sync.space .control.sync.src -side top -fill y -padx 3 -expand 1 - -label .control.space -text "" -width 10 - -# Buffer Size - -frame .control.buf -label .control.buf.text -text "Buffer Size (Latency)" -justify left -radiobutton .control.buf.b1 -selectcolor red -text "64 (1.5 ms)" -width 13 -anchor nw -variable ssrate -value 1 -font times -radiobutton .control.buf.b2 -selectcolor red -text "128 (3 ms)" -width 13 -anchor nw -variable ssrate -value 2 -font times -radiobutton .control.buf.b3 -selectcolor red -text "256 (6 ms)" -width 13 -anchor nw -variable ssrate -value 3 -font times -radiobutton .control.buf.b4 -selectcolor red -text "512 (12 ms)" -width 13 -anchor nw -variable ssrate -value 4 -font times -radiobutton .control.buf.b5 -selectcolor red -text "1024 (23 ms)" -width 13 -anchor nw -variable ssrate -value 5 -font times -radiobutton .control.buf.b6 -selectcolor red -text "2048 (46 ms)" -width 13 -anchor nw -variable ssrate -value 6 -font times -radiobutton .control.buf.b7 -selectcolor red -text "4096 (93 ms)" -width 13 -anchor nw -variable ssrate -value 7 -font times -radiobutton .control.buf.b8 -selectcolor red -text "8192 (186 ms)" -width 13 -anchor nw -variable ssrate -value 8 -font times - -pack .control.buf.text .control.buf.b1 .control.buf.b2 .control.buf.b3 .control.buf.b4 .control.buf.b5 .control.buf.b6 .control.buf.b7 .control.buf.b8 -side top -padx 3 - -# Offset - -frame .control.offset - -frame .control.offset.in -label .control.offset.in.text -text "Offset In" -justify left -label .control.offset.in.off0 -text "dev\#0: -" -anchor nw -width 10 -font times -label .control.offset.in.off1 -text "dev\#1: -" -anchor nw -width 10 -font times -label .control.offset.in.off2 -text "dev\#2: -" -anchor nw -width 10 -font times -label .control.offset.in.off3 -text "dev\#3: -" -anchor nw -width 10 -font times - -pack .control.offset.in.text .control.offset.in.off0 .control.offset.in.off1 .control.offset.in.off2 .control.offset.in.off3 - -label .control.offset.space - -frame .control.offset.out -label .control.offset.out.text -text "Offset Out" -justify left -label .control.offset.out.off0 -text "dev\#0: -" -anchor nw -width 10 -font times -label .control.offset.out.off1 -text "dev\#1: -" -anchor nw -width 10 -font times -label .control.offset.out.off2 -text "dev\#2: -" -anchor nw -width 10 -font times -label .control.offset.out.off3 -text "dev\#3: -" -anchor nw -width 10 -font times - -pack .control.offset.out.off3 .control.offset.out.off2 .control.offset.out.off1 .control.offset.out.off0 .control.offset.out.text -side bottom - -pack .control.offset.in .control.offset.space .control.offset.out -side top -fill y -padx 3 -expand 1 - - -pack .control.spdif .control.sync .control.space .control.buf .control.offset -side left -fill both -anchor n -expand 1 - - -label .statustext -text Status -justify center -relief ridge -label .controltext -text Control -justify center -relief ridge - -label .statusspace -label .controlspace - -pack .statustext .status .statusspace .controltext .control .controlspace -side top -anchor nw -fill both -expand 1 - - -proc get_bit {output sstr} { - set idx1 [string last [concat $sstr 1] $output] - set idx1 [expr $idx1 != -1] - return $idx1 -} - -proc get_val {output sstr} { - set val [string wordend $output [string last $sstr $output]] - set val [string range $output $val [expr $val+1]] - return $val -} - -proc get_val2 {output sstr} { - set val [string wordend $output [string first $sstr $output]] - set val [string range $output $val [expr $val+2]] - return $val -} - -proc get_control {} { - global spprof - global spemph - global spnoaud - global spoptical - global spdifin - global ssrate - global master - global wordclock - global syncsource - global CTRLPROG - - set f [open "| $CTRLPROG control" r+] - set ooo [read $f 1000] - close $f -# puts $ooo - - set spprof [ get_bit $ooo "pro"] - set spemph [ get_bit $ooo "emphasis"] - set spnoaud [ get_bit $ooo "dolby"] - set spoptical [ get_bit $ooo "opt_out"] - set spdifin [ expr [ get_val $ooo "spdif_in"] + 1] - set ssrate [ expr [ get_val $ooo "latency"] + 1] - set master [ expr [ get_val $ooo "master"]] - set wordclock [ expr [ get_val $ooo "wordclock"]] - set syncsource [ expr [ get_val $ooo "sync_ref"] + 1] -} - -proc get_status {} { - global srate - global ctrlcom - - global adatlock1 - global adatlock2 - global adatlock3 - - global adatsync1 - global adatsync2 - global adatsync3 - - global tcbusy - global tcout - global tcvalid - - global spdiferr - global crystal - global .status.spdif.text - global CTRLPROG - - - set f [open "| $CTRLPROG status" r+] - set ooo [read $f 1000] - close $f -# puts $ooo - -# samplerate - - set idx1 [string last "sr48 1" $ooo] - set idx2 [string last "doublespeed 1" $ooo] - if {$idx1 >= 0} { - set fact1 48000 - } else { - set fact1 44100 - } - - if {$idx2 >= 0} { - set fact2 2 - } else { - set fact2 1 - } - set srate [expr $fact1 * $fact2] -# ADAT lock - - set val [get_val $ooo lockmask] - set adatlock1 0 - set adatlock2 0 - set adatlock3 0 - if {[expr $val & 1]} { - set adatlock3 1 - } - if {[expr $val & 2]} { - set adatlock2 1 - } - if {[expr $val & 4]} { - set adatlock1 1 - } - -# ADAT sync - set val [get_val $ooo syncmask] - set adatsync1 0 - set adatsync2 0 - set adatsync3 0 - - if {[expr $val & 1]} { - set adatsync3 1 - } - if {[expr $val & 2]} { - set adatsync2 1 - } - if {[expr $val & 4]} { - set adatsync1 1 - } - -# TC busy - - set tcbusy [get_bit $ooo "busy"] - set tcout [get_bit $ooo "out"] - set tcvalid [get_bit $ooo "valid"] - set spdiferr [expr [get_bit $ooo "spdif_error"] == 0] - -# 000=64kHz, 100=88.2kHz, 011=96kHz -# 111=32kHz, 110=44.1kHz, 101=48kHz - - set val [get_val $ooo crystalrate] - - set crystal "--.- kHz" - if {$val == 0} { - set crystal "64 kHz" - } - if {$val == 4} { - set crystal "88.2 kHz" - } - if {$val == 3} { - set crystal "96 kHz" - } - if {$val == 7} { - set crystal "32 kHz" - } - if {$val == 6} { - set crystal "44.1 kHz" - } - if {$val == 5} { - set crystal "48 kHz" - } - .status.spdif.sr configure -text $crystal -} - -proc get_offset {} { - global inoffset - global outoffset - global CTRLPROG - - set f [open "| $CTRLPROG mix" r+] - set ooo [read $f 1000] - close $f -# puts $ooo - - if { [string match "*devnr*" $ooo] } { - set ooo [string range $ooo [string wordend $ooo [string first devnr $ooo]] end] - set val [get_val2 $ooo i_offset] - .control.offset.in.off0 configure -text "dev\#0: $val" - set val [get_val2 $ooo o_offset] - .control.offset.out.off0 configure -text "dev\#0: $val" - } else { - .control.offset.in.off0 configure -text "dev\#0: -" - .control.offset.out.off0 configure -text "dev\#0: -" - } - if { [string match "*devnr*" $ooo] } { - set ooo [string range $ooo [string wordend $ooo [string first devnr $ooo]] end] - set val [get_val2 $ooo i_offset] - .control.offset.in.off1 configure -text "dev\#1: $val" - set val [get_val2 $ooo o_offset] - .control.offset.out.off1 configure -text "dev\#1: $val" - } else { - .control.offset.in.off1 configure -text "dev\#1: -" - .control.offset.out.off1 configure -text "dev\#1: -" - } - if { [string match "*devnr*" $ooo] } { - set ooo [string range $ooo [string wordend $ooo [string first devnr $ooo]] end] - set val [get_val2 $ooo i_offset] - .control.offset.in.off2 configure -text "dev\#2: $val" - set val [get_val2 $ooo o_offset] - .control.offset.out.off2 configure -text "dev\#2: $val" - } else { - .control.offset.in.off2 configure -text "dev\#2: -" - .control.offset.out.off2 configure -text "dev\#2: -" - } - if { [string match "*devnr*" $ooo] } { - set ooo [string range $ooo [string wordend $ooo [string first devnr $ooo]] end] - set val [get_val2 $ooo i_offset] - .control.offset.in.off3 configure -text "dev\#3: $val" - set val [get_val2 $ooo o_offset] - .control.offset.out.off3 configure -text "dev\#3: $val" - } else { - .control.offset.in.off3 configure -text "dev\#3: -" - .control.offset.out.off3 configure -text "dev\#3: -" - } -} - - -proc get_all {} { -get_status -get_control -get_offset -} - -# main -while {1} { - after 200 - get_all - update -} diff --git a/Documentation/sound/oss/solo1 b/Documentation/sound/oss/solo1 deleted file mode 100644 index 6f53d407d027..000000000000 --- a/Documentation/sound/oss/solo1 +++ /dev/null @@ -1,70 +0,0 @@ -Recording ---------- - -Recording does not work on the author's card, but there -is at least one report of it working on later silicon. -The chip behaves differently than described in the data sheet, -likely due to a chip bug. Working around this would require -the help of ESS (for example by publishing an errata sheet), -but ESS has not done so so far. - -Also, the chip only supports 24 bit addresses for recording, -which means it cannot work on some Alpha mainboards. - - -/proc/sound, /dev/sndstat -------------------------- - -/proc/sound and /dev/sndstat is not supported by the -driver. To find out whether the driver succeeded loading, -check the kernel log (dmesg). - - -ALaw/uLaw sample formats ------------------------- - -This driver does not support the ALaw/uLaw sample formats. -ALaw is the default mode when opening a sound device -using OSS/Free. The reason for the lack of support is -that the hardware does not support these formats, and adding -conversion routines to the kernel would lead to very ugly -code in the presence of the mmap interface to the driver. -And since xquake uses mmap, mmap is considered important :-) -and no sane application uses ALaw/uLaw these days anyway. -In short, playing a Sun .au file as follows: - -cat my_file.au > /dev/dsp - -does not work. Instead, you may use the play script from -Chris Bagwell's sox-12.14 package (or later, available from the URL -below) to play many different audio file formats. -The script automatically determines the audio format -and does do audio conversions if necessary. -http://home.sprynet.com/sprynet/cbagwell/projects.html - - -Blocking vs. nonblocking IO ---------------------------- - -Unlike OSS/Free this driver honours the O_NONBLOCK file flag -not only during open, but also during read and write. -This is an effort to make the sound driver interface more -regular. Timidity has problems with this; a patch -is available from http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html. -(Timidity patched will also run on OSS/Free). - - -MIDI UART ---------- - -The driver supports a simple MIDI UART interface, with -no ioctl's supported. - - -MIDI synthesizer ----------------- - -The card has an OPL compatible FM synthesizer. - -Thomas Sailer -t.sailer@alumni.ethz.ch diff --git a/Documentation/sound/oss/sonicvibes b/Documentation/sound/oss/sonicvibes deleted file mode 100644 index 84dee2e0b37d..000000000000 --- a/Documentation/sound/oss/sonicvibes +++ /dev/null @@ -1,81 +0,0 @@ -/proc/sound, /dev/sndstat -------------------------- - -/proc/sound and /dev/sndstat is not supported by the -driver. To find out whether the driver succeeded loading, -check the kernel log (dmesg). - - -ALaw/uLaw sample formats ------------------------- - -This driver does not support the ALaw/uLaw sample formats. -ALaw is the default mode when opening a sound device -using OSS/Free. The reason for the lack of support is -that the hardware does not support these formats, and adding -conversion routines to the kernel would lead to very ugly -code in the presence of the mmap interface to the driver. -And since xquake uses mmap, mmap is considered important :-) -and no sane application uses ALaw/uLaw these days anyway. -In short, playing a Sun .au file as follows: - -cat my_file.au > /dev/dsp - -does not work. Instead, you may use the play script from -Chris Bagwell's sox-12.14 package (available from the URL -below) to play many different audio file formats. -The script automatically determines the audio format -and does do audio conversions if necessary. -http://home.sprynet.com/sprynet/cbagwell/projects.html - - -Blocking vs. nonblocking IO ---------------------------- - -Unlike OSS/Free this driver honours the O_NONBLOCK file flag -not only during open, but also during read and write. -This is an effort to make the sound driver interface more -regular. Timidity has problems with this; a patch -is available from http://www.ife.ee.ethz.ch/~sailer/linux/pciaudio.html. -(Timidity patched will also run on OSS/Free). - - -MIDI UART ---------- - -The driver supports a simple MIDI UART interface, with -no ioctl's supported. - - -MIDI synthesizer ----------------- - -The card both has an OPL compatible FM synthesizer as well as -a wavetable synthesizer. - -I haven't managed so far to get the OPL synth running. - -Using the wavetable synthesizer requires allocating -1-4MB of physically contiguous memory, which isn't possible -currently on Linux without ugly hacks like the bigphysarea -patch. Therefore, the driver doesn't support wavetable -synthesis. - - -No support from S3 ------------------- - -I do not get any support from S3. Therefore, the driver -still has many problems. For example, although the manual -states that the chip should be able to access the sample -buffer anywhere in 32bit address space, I haven't managed to -get it working with buffers above 16M. Therefore, the card -has the same disadvantages as ISA soundcards. - -Given that the card is also very noisy, and if you haven't -already bought it, you should strongly opt for one of the -comparatively priced Ensoniq products. - - -Thomas Sailer -t.sailer@alumni.ethz.ch diff --git a/Documentation/sound/oss/ultrasound b/Documentation/sound/oss/ultrasound index 32cd50478b36..eed331c738a3 100644 --- a/Documentation/sound/oss/ultrasound +++ b/Documentation/sound/oss/ultrasound @@ -19,7 +19,7 @@ db16 ??? no_wave_dma option This option defaults to a value of 0, which allows the Ultrasound wavetable -DSP to use DMA for for playback and downloading samples. This is the same +DSP to use DMA for playback and downloading samples. This is the same as the old behaviour. If set to 1, no DMA is needed for downloading samples, and allows owners of a GUS MAX to make use of simultaneous digital audio (/dev/dsp), MIDI, and wavetable playback. diff --git a/Documentation/sound/oss/vwsnd b/Documentation/sound/oss/vwsnd index a6ea0a1df9e4..4c6cbdb3c548 100644 --- a/Documentation/sound/oss/vwsnd +++ b/Documentation/sound/oss/vwsnd @@ -12,7 +12,7 @@ boxes. The Visual Workstation has an Analog Devices AD1843 "SoundComm" audio codec chip. The AD1843 is accessed through the Cobalt I/O ASIC, also -known as Lithium. This driver programs both both chips. +known as Lithium. This driver programs both chips. ============================================================================== QUICK CONFIGURATION diff --git a/Documentation/sparc/sbus_drivers.txt b/Documentation/sparc/sbus_drivers.txt index 4b9351624f13..8418d35484fc 100644 --- a/Documentation/sparc/sbus_drivers.txt +++ b/Documentation/sparc/sbus_drivers.txt @@ -25,8 +25,8 @@ the bits necessary to run your device. The most commonly used members of this structure, and their typical usage, will be detailed below. - Here is a piece of skeleton code for perofming a device -probe in an SBUS driverunder Linux: + Here is a piece of skeleton code for performing a device +probe in an SBUS driver under Linux: static int __devinit mydevice_probe_one(struct sbus_dev *sdev) { @@ -98,7 +98,7 @@ in your .remove method. Any memory allocated, registers mapped, IRQs registered, etc. must be undone by your .remove method so that all resources -of your device are relased by the time it returns. +of your device are released by the time it returns. You should _NOT_ use the for_each_sbus(), for_each_sbusdev(), and for_all_sbusdev() interfaces. They are deprecated, will be diff --git a/Documentation/spi/pxa2xx b/Documentation/spi/pxa2xx index 9c45f3df2e18..a1e0ee20f595 100644 --- a/Documentation/spi/pxa2xx +++ b/Documentation/spi/pxa2xx @@ -124,12 +124,12 @@ use a value of 8. The "pxa2xx_spi_chip.timeout_microsecs" fields is used to efficiently handle trailing bytes in the SSP receiver fifo. The correct value for this field is dependent on the SPI bus speed ("spi_board_info.max_speed_hz") and the specific -slave device. Please note the the PXA2xx SSP 1 does not support trailing byte +slave device. Please note that the PXA2xx SSP 1 does not support trailing byte timeouts and must busy-wait any trailing bytes. The "pxa2xx_spi_chip.enable_loopback" field is used to place the SSP porting into internal loopback mode. In this mode the SSP controller internally -connects the SSPTX pin the the SSPRX pin. This is useful for initial setup +connects the SSPTX pin to the SSPRX pin. This is useful for initial setup testing. The "pxa2xx_spi_chip.cs_control" field is used to point to a board specific @@ -208,7 +208,7 @@ DMA and PIO I/O Support ----------------------- The pxa2xx_spi driver support both DMA and interrupt driven PIO message transfers. The driver defaults to PIO mode and DMA transfers must enabled by -setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and and +setting the "enable_dma" flag in the "pxa2xx_spi_master" structure and ensuring that the "pxa2xx_spi_chip.dma_burst_size" field is non-zero. The DMA mode support both coherent and stream based DMA mappings. diff --git a/Documentation/spi/spi-summary b/Documentation/spi/spi-summary index 068732d32276..72795796b13d 100644 --- a/Documentation/spi/spi-summary +++ b/Documentation/spi/spi-summary @@ -262,7 +262,7 @@ NON-STATIC CONFIGURATIONS Developer boards often play by different rules than product boards, and one example is the potential need to hotplug SPI devices and/or controllers. -For those cases you might need to use use spi_busnum_to_master() to look +For those cases you might need to use spi_busnum_to_master() to look up the spi bus master, and will likely need spi_new_device() to provide the board info based on the board that was hotplugged. Of course, you'd later call at least spi_unregister_device() when that board is removed. @@ -322,7 +322,7 @@ As soon as it enters probe(), the driver may issue I/O requests to the SPI device using "struct spi_message". When remove() returns, the driver guarantees that it won't submit any more such messages. - - An spi_message is a sequence of of protocol operations, executed + - An spi_message is a sequence of protocol operations, executed as one atomic sequence. SPI driver controls include: + when bidirectional reads and writes start ... by how its diff --git a/Documentation/stable_kernel_rules.txt b/Documentation/stable_kernel_rules.txt index e409e5d07486..02a481225b0d 100644 --- a/Documentation/stable_kernel_rules.txt +++ b/Documentation/stable_kernel_rules.txt @@ -4,7 +4,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree: - It must be obviously correct and tested. - - It can not be bigger than 100 lines, with context. + - It cannot be bigger than 100 lines, with context. - It must fix only one thing. - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing). @@ -14,7 +14,7 @@ Rules on what kind of patches are accepted, and which ones are not, into the critical. - No "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided. - - It can not contain any "trivial" fixes in it (spelling changes, + - It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc). - It must be accepted by the relevant subsystem maintainer. - It must follow the Documentation/SubmittingPatches rules. diff --git a/Documentation/uml/UserModeLinux-HOWTO.txt b/Documentation/uml/UserModeLinux-HOWTO.txt index 544430e39980..b60590eca18f 100644 --- a/Documentation/uml/UserModeLinux-HOWTO.txt +++ b/Documentation/uml/UserModeLinux-HOWTO.txt @@ -157,7 +157,7 @@ 13. What to do when UML doesn't work 13.1 Strange compilation errors when you build from source - 13.2 UML hangs on boot after mounting devfs + 13.2 (obsolete) 13.3 A variety of panics and hangs with /tmp on a reiserfs filesystem 13.4 The compile fails with errors about conflicting types for 'open', 'dup', and 'waitpid' 13.5 UML doesn't work when /tmp is an NFS filesystem @@ -379,31 +379,6 @@ bug fixes and enhancements that have gone into subsequent releases. - If you build your own kernel, and want to boot it from one of the - filesystems distributed from this site, then, in nearly all cases, - devfs must be compiled into the kernel and mounted at boot time. The - exception is the SuSE filesystem. For this, devfs must either not be - in the kernel at all, or "devfs=nomount" must be on the kernel command - line. Any disagreement between the kernel and the filesystem being - booted about whether devfs is being used will result in the boot - getting no further than single-user mode. - - - If you don't want to use devfs, you can remove the need for it from a - filesystem by copying /dev from someplace, making a bunch of /dev/ubd - devices: - - - UML# for i in 0 1 2 3 4 5 6 7; do mknod ubd$i b 98 $i; done - - - - - and changing /etc/fstab and /etc/inittab to refer to the non-devfs - devices. - - - 22..22.. CCoommppiilliinngg aanndd iinnssttaalllliinngg kkeerrnneell mmoodduulleess UML modules are built in the same way as the native kernel (with the @@ -839,9 +814,7 @@ +o None - device=none - This causes the device to disappear. If you are using devfs, the - device will not appear in /dev. If not, then attempts to open it - will return -ENODEV. + This causes the device to disappear. @@ -1047,7 +1020,7 @@ Note that the IP address you assign to the host end of the tap device must be different than the IP you assign to the eth device inside UML. - If you are short on IPs and don't want to comsume two per UML, then + If you are short on IPs and don't want to consume two per UML, then you can reuse the host's eth IP address for the host ends of the tap devices. Internally, the UMLs must still get unique IPs for their eth devices. You can also give the UMLs non-routable IPs (192.168.x.x or @@ -2058,7 +2031,7 @@ there are multiple COWs associated with a backing file, a -d merge of one of them will invalidate all of the others. However, it is convenient if you're short of disk space, and it should also be - noticably faster than a non-destructive merge. + noticeably faster than a non-destructive merge. @@ -3898,29 +3871,6 @@ - 1133..22.. UUMMLL hhaannggss oonn bboooott aafftteerr mmoouunnttiinngg ddeevvffss - - The boot looks like this: - - - VFS: Mounted root (ext2 filesystem) readonly. - Mounted devfs on /dev - - - - - You're probably running a recent distribution on an old machine. I - saw this with the RH7.1 filesystem running on a Pentium. The shared - library loader, ld.so, was executing an instruction (cmove) which the - Pentium didn't support. That instruction was apparently added later. - If you run UML under the debugger, you'll see the hang caused by one - instruction causing an infinite SIGILL stream. - - - The fix is to boot UML on an older filesystem. - - - 1133..33.. AA vvaarriieettyy ooff ppaanniiccss aanndd hhaannggss wwiitthh //ttmmpp oonn aa rreeiisseerrffss ffiilleessyyss-- tteemm @@ -3953,9 +3903,9 @@ 1133..55.. UUMMLL ddooeessnn''tt wwoorrkk wwhheenn //ttmmpp iiss aann NNFFSS ffiilleessyysstteemm - This seems to be a similar situation with the resierfs problem above. + This seems to be a similar situation with the ReiserFS problem above. Some versions of NFS seems not to handle mmap correctly, which UML - depends on. The workaround is have /tmp be non-NFS directory. + depends on. The workaround is have /tmp be a non-NFS directory. 1133..66.. UUMMLL hhaannggss oonn bboooott wwhheenn ccoommppiilleedd wwiitthh ggpprrooff ssuuppppoorrtt @@ -4022,7 +3972,7 @@ nneett If you can connect to the host, and the host can connect to UML, but - you can not connect to any other machines, then you may need to enable + you cannot connect to any other machines, then you may need to enable IP Masquerading on the host. Usually this is only experienced when using private IP addresses (192.168.x.x or 10.x.x.x) for host/UML networking, rather than the public address space that your host is @@ -4671,7 +4621,7 @@ Chris Reahard built a specialized root filesystem for running a DNS server jailed inside UML. It's available from the download <http://user-mode-linux.sourceforge.net/dl-sf.html> page in the Jail - Filesysems section. + Filesystems section. diff --git a/Documentation/unshare.txt b/Documentation/unshare.txt index 90a5e9e5bef1..a8643513a5f6 100644 --- a/Documentation/unshare.txt +++ b/Documentation/unshare.txt @@ -260,7 +260,7 @@ items: a pointer to it. 7.4) Appropriately modify architecture specific code to register the - the new system call. + new system call. 8) Test Specification --------------------- diff --git a/Documentation/usb/URB.txt b/Documentation/usb/URB.txt index a49e5f2c2b46..8ffce746d496 100644 --- a/Documentation/usb/URB.txt +++ b/Documentation/usb/URB.txt @@ -184,7 +184,7 @@ you can pass information to the completion handler. Note that even when an error (or unlink) is reported, data may have been transferred. That's because USB transfers are packetized; it might take sixteen packets to transfer your 1KByte buffer, and ten of them might -have transferred succesfully before the completion was called. +have transferred successfully before the completion was called. NOTE: ***** WARNING ***** diff --git a/Documentation/usb/acm.txt b/Documentation/usb/acm.txt index 8ef45ea8f691..737d6104c3f3 100644 --- a/Documentation/usb/acm.txt +++ b/Documentation/usb/acm.txt @@ -49,20 +49,6 @@ Abstract Control Model (USB CDC ACM) specification. Unfortunately many modems and most ISDN TAs use proprietary interfaces and thus won't work with this drivers. Check for ACM compliance before buying. - The driver (with devfs) creates these devices in /dev/usb/acm: - - crw-r--r-- 1 root root 166, 0 Apr 1 10:49 0 - crw-r--r-- 1 root root 166, 1 Apr 1 10:49 1 - crw-r--r-- 1 root root 166, 2 Apr 1 10:49 2 - - And so on, up to 31, with the limit being possible to change in acm.c to up -to 256, so you can use up to 256 USB modems with one computer (you'll need -three USB cards for that, though). - - If you don't use devfs, then you can create device nodes with the same -minor/major numbers anywhere you want, but either the above location or -/dev/usb/ttyACM0 is preferred. - To use the modems you need these modules loaded: usbcore.ko diff --git a/Documentation/usb/error-codes.txt b/Documentation/usb/error-codes.txt index 867f4c38f356..9cf83e8c27b8 100644 --- a/Documentation/usb/error-codes.txt +++ b/Documentation/usb/error-codes.txt @@ -98,13 +98,13 @@ one or more packets could finish before an error stops further endpoint I/O. error, a failure to respond (often caused by device disconnect), or some other fault. --ETIMEDOUT (**) No response packet received within the prescribed +-ETIME (**) No response packet received within the prescribed bus turn-around time. This error may instead be reported as -EPROTO or -EILSEQ. - Note that the synchronous USB message functions - also use this code to indicate timeout expired - before the transfer completed. +-ETIMEDOUT Synchronous USB message functions use this code + to indicate timeout expired before the transfer + completed, and no other error was reported by HC. -EPIPE (**) Endpoint stalled. For non-control endpoints, reset this status with usb_clear_halt(). @@ -126,7 +126,7 @@ one or more packets could finish before an error stops further endpoint I/O. urb->transfer_flags. -ENODEV Device was removed. Often preceded by a burst of - other errors, since the hub driver does't detect + other errors, since the hub driver doesn't detect device removal events immediately. -EXDEV ISO transfer only partially completed @@ -145,7 +145,7 @@ one or more packets could finish before an error stops further endpoint I/O. hardware problems such as bad devices (including firmware) or cables. (**) This is also one of several codes that different kinds of host -controller use to to indicate a transfer has failed because of device +controller use to indicate a transfer has failed because of device disconnect. In the interval before the hub driver starts disconnect processing, devices may receive such fault reports for every request. @@ -163,6 +163,3 @@ usb_get_*/usb_set_*(): usb_control_msg(): usb_bulk_msg(): -ETIMEDOUT Timeout expired before the transfer completed. - In the future this code may change to -ETIME, - whose definition is a closer match to this sort - of error. diff --git a/Documentation/usb/hiddev.txt b/Documentation/usb/hiddev.txt index cd6fb4b58e1f..6a790754e963 100644 --- a/Documentation/usb/hiddev.txt +++ b/Documentation/usb/hiddev.txt @@ -118,7 +118,7 @@ index, the ioctl returns -1 and sets errno to -EINVAL. HIDIOCGDEVINFO - struct hiddev_devinfo (read) Gets a hiddev_devinfo structure which describes the device. -HIDIOCGSTRING - struct struct hiddev_string_descriptor (read/write) +HIDIOCGSTRING - struct hiddev_string_descriptor (read/write) Gets a string descriptor from the device. The caller must fill in the "index" field to indicate which descriptor should be returned. diff --git a/Documentation/usb/mtouchusb.txt b/Documentation/usb/mtouchusb.txt index cd806bfc8b81..e43cfffaa100 100644 --- a/Documentation/usb/mtouchusb.txt +++ b/Documentation/usb/mtouchusb.txt @@ -11,7 +11,7 @@ CHANGES Changed reset from standard USB dev reset to vendor reset Changed data sent to host from compensated to raw coordinates Eliminated vendor/product module params - Performed multiple successfull tests with an EXII-5010UC + Performed multiple successful tests with an EXII-5010UC SUPPORTED HARDWARE: @@ -38,7 +38,7 @@ This driver appears to be one of possible 2 Linux USB Input Touchscreen drivers. Although 3M produces a binary only driver available for download, I persist in updating this driver since I would like to use the touchscreen for embedded apps using QTEmbedded, DirectFB, etc. So I feel the -logical choice is to use Linux Imput. +logical choice is to use Linux Input. Currently there is no way to calibrate the device via this driver. Even if the device could be calibrated, the driver pulls to raw coordinate data from @@ -63,7 +63,7 @@ TODO: Implement a control urb again to handle requests to and from the device such as calibration, etc once/if it becomes available. -DISCLAMER: +DISCLAIMER: I am not a MicroTouch/3M employee, nor have I ever been. 3M does not support this driver! If you want touch drivers only supported within X, please go to: diff --git a/Documentation/usb/usb-serial.txt b/Documentation/usb/usb-serial.txt index 02b0f7beb6d1..8dc2bacc8f1f 100644 --- a/Documentation/usb/usb-serial.txt +++ b/Documentation/usb/usb-serial.txt @@ -13,7 +13,6 @@ CONFIGURATION Currently the driver can handle up to 256 different serial interfaces at one time. - If you are not using devfs: The major number that the driver uses is 188 so to use the driver, create the following nodes: mknod /dev/ttyUSB0 c 188 0 @@ -26,10 +25,6 @@ CONFIGURATION mknod /dev/ttyUSB254 c 188 254 mknod /dev/ttyUSB255 c 188 255 - If you are using devfs: - The devices supported by this driver will show up as - /dev/usb/tts/{0,1,...} - When the device is connected and recognized by the driver, the driver will print to the system log, which node(s) the device has been bound to. @@ -228,7 +223,7 @@ Cypress M8 CY4601 Family Serial Driver -Cypress HID->COM RS232 adapter Note: Cypress Semiconductor claims no affiliation with the - the hid->com device. + hid->com device. Most devices using chipsets under the CY4601 family should work with the driver. As long as they stay true to the CY4601 @@ -277,7 +272,7 @@ Digi AccelePort Driver work under SMP with the uhci driver. The driver is generally working, though we still have a few more ioctls - to implement and final testing and debugging to do. The paralled port + to implement and final testing and debugging to do. The parallel port on the USB 2 is supported as a serial to parallel converter; in other words, it appears as another USB serial port on Linux, even though physically it is really a parallel port. The Digi Acceleport USB 8 @@ -427,12 +422,17 @@ Options supported: debug - extra verbose debugging info (default: 0; nonzero enables) use_lowlatency - use low_latency flag to speed up tty layer - when reading from from the device. + when reading from the device. (default: 0; nonzero enables) See http://www.uuhaus.de/linux/palmconnect.html for up-to-date information on this driver. +AIRcable USB Dongle Bluetooth driver + If there is the cdc_acm driver loaded in the system, you will find that the + cdc_acm claims the device before AIRcable can. This is simply corrected + by unloading both modules and then loading the aircable module before + cdc_acm module Generic Serial driver diff --git a/Documentation/video4linux/CARDLIST.cx88 b/Documentation/video4linux/CARDLIST.cx88 index 00d9a1f2a54c..126e59d935cd 100644 --- a/Documentation/video4linux/CARDLIST.cx88 +++ b/Documentation/video4linux/CARDLIST.cx88 @@ -7,16 +7,16 @@ 6 -> AverTV Studio 303 (M126) [1461:000b] 7 -> MSI TV-@nywhere Master [1462:8606] 8 -> Leadtek Winfast DV2000 [107d:6620] - 9 -> Leadtek PVR 2000 [107d:663b,107d:663C] + 9 -> Leadtek PVR 2000 [107d:663b,107d:663c,107d:6632] 10 -> IODATA GV-VCP3/PCI [10fc:d003] 11 -> Prolink PlayTV PVR - 12 -> ASUS PVR-416 [1043:4823] + 12 -> ASUS PVR-416 [1043:4823,1461:c111] 13 -> MSI TV-@nywhere 14 -> KWorld/VStream XPert DVB-T [17de:08a6] 15 -> DViCO FusionHDTV DVB-T1 [18ac:db00] 16 -> KWorld LTV883RF 17 -> DViCO FusionHDTV 3 Gold-Q [18ac:d810,18ac:d800] - 18 -> Hauppauge Nova-T DVB-T [0070:9002,0070:9001] + 18 -> Hauppauge Nova-T DVB-T [0070:9002,0070:9001,0070:9000] 19 -> Conexant DVB-T reference design [14f1:0187] 20 -> Provideo PV259 [1540:2580] 21 -> DViCO FusionHDTV DVB-T Plus [18ac:db10,18ac:db11] @@ -41,7 +41,7 @@ 40 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid [0070:9400,0070:9402] 41 -> Hauppauge WinTV-HVR1100 DVB-T/Hybrid (Low Profile) [0070:9800,0070:9802] 42 -> digitalnow DNTV Live! DVB-T Pro [1822:0025,1822:0019] - 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1] + 43 -> KWorld/VStream XPert DVB-T with cx22702 [17de:08a1,12ab:2300] 44 -> DViCO FusionHDTV DVB-T Dual Digital [18ac:db50,18ac:db54] 45 -> KWorld HardwareMpegTV XPert [17de:0840] 46 -> DViCO FusionHDTV DVB-T Hybrid [18ac:db40,18ac:db44] @@ -51,3 +51,7 @@ 50 -> NPG Tech Real TV FM Top 10 [14f1:0842] 51 -> WinFast DTV2000 H [107d:665e] 52 -> Geniatech DVB-S [14f1:0084] + 53 -> Hauppauge WinTV-HVR3000 TriMode Analog/DVB-S/DVB-T [0070:1404] + 54 -> Norwood Micro TV Tuner + 55 -> Shenzhen Tungsten Ages Tech TE-DTV-250 / Swann OEM [c180:c980] + 56 -> Hauppauge WinTV-HVR1300 DVB-T/Hybrid MPEG Encoder [0070:9600,0070:9601,0070:9602] diff --git a/Documentation/video4linux/CARDLIST.saa7134 b/Documentation/video4linux/CARDLIST.saa7134 index 9068b669f5ee..53ce6a39083c 100644 --- a/Documentation/video4linux/CARDLIST.saa7134 +++ b/Documentation/video4linux/CARDLIST.saa7134 @@ -58,7 +58,7 @@ 57 -> Avermedia AVerTV GO 007 FM [1461:f31f] 58 -> ADS Tech Instant TV (saa7135) [1421:0350,1421:0351,1421:0370,1421:1370] 59 -> Kworld/Tevion V-Stream Xpert TV PVR7134 - 60 -> LifeView/Typhoon FlyDVB-T Duo Cardbus [5168:0502,4e42:0502] + 60 -> LifeView/Typhoon/Genius FlyDVB-T Duo Cardbus [5168:0502,4e42:0502,1489:0502] 61 -> Philips TOUGH DVB-T reference design [1131:2004] 62 -> Compro VideoMate TV Gold+II 63 -> Kworld Xpert TV PVR7134 @@ -83,7 +83,7 @@ 82 -> MSI TV@Anywhere plus [1462:6231] 83 -> Terratec Cinergy 250 PCI TV [153b:1160] 84 -> LifeView FlyDVB Trio [5168:0319] - 85 -> AverTV DVB-T 777 [1461:2c05] + 85 -> AverTV DVB-T 777 [1461:2c05,1461:2c05] 86 -> LifeView FlyDVB-T / Genius VideoWonder DVB-T [5168:0301,1489:0301] 87 -> ADS Instant TV Duo Cardbus PTV331 [0331:1421] 88 -> Tevion/KWorld DVB-T 220RF [17de:7201] @@ -94,3 +94,8 @@ 93 -> Medion 7134 Bridge #2 [16be:0005] 94 -> LifeView FlyDVB-T Hybrid Cardbus [5168:3306,5168:3502] 95 -> LifeView FlyVIDEO3000 (NTSC) [5169:0138] + 96 -> Medion Md8800 Quadro [16be:0007,16be:0008] + 97 -> LifeView FlyDVB-S /Acorp TV134DS [5168:0300,4e42:0300] + 98 -> Proteus Pro 2309 [0919:2003] + 99 -> AVerMedia TV Hybrid A16AR [1461:2c00] +100 -> Asus Europa2 OEM [1043:4860] diff --git a/Documentation/video4linux/README.pvrusb2 b/Documentation/video4linux/README.pvrusb2 index c73a32c34528..a4b7ae800866 100644 --- a/Documentation/video4linux/README.pvrusb2 +++ b/Documentation/video4linux/README.pvrusb2 @@ -155,7 +155,7 @@ Source file list / functional overview: pvrusb2-i2c-core.[ch] - This module provides an implementation of a kernel-friendly I2C adaptor driver, through which other external I2C client drivers (e.g. msp3400, tuner, lirc) may connect and - operate corresponding chips within the the pvrusb2 device. It is + operate corresponding chips within the pvrusb2 device. It is through here that other V4L modules can reach into this driver to operate specific pieces (and those modules are in turn driven by glue logic which is coordinated by pvrusb2-hdw, doled out by diff --git a/Documentation/video4linux/Zoran b/Documentation/video4linux/Zoran index 040a2c841ae9..deb218f77adb 100644 --- a/Documentation/video4linux/Zoran +++ b/Documentation/video4linux/Zoran @@ -144,7 +144,7 @@ tv broadcast formats all aver the world. The CCIR defines parameters needed for broadcasting the signal. The CCIR has defined different standards: A,B,D,E,F,G,D,H,I,K,K1,L,M,N,... -The CCIR says not much about about the colorsystem used !!! +The CCIR says not much about the colorsystem used !!! And talking about a colorsystem says not to much about how it is broadcast. The CCIR standards A,E,F are not used any more. diff --git a/Documentation/video4linux/bttv/Insmod-options b/Documentation/video4linux/bttv/Insmod-options index fc94ff235ffa..bb7c2cac7917 100644 --- a/Documentation/video4linux/bttv/Insmod-options +++ b/Documentation/video4linux/bttv/Insmod-options @@ -54,6 +54,12 @@ bttv.o dropouts. chroma_agc=0/1 AGC of chroma signal, off by default. adc_crush=0/1 Luminance ADC crush, on by default. + i2c_udelay= Allow reduce I2C speed. Default is 5 usecs + (meaning 66,67 Kbps). The default is the + maximum supported speed by kernel bitbang + algoritm. You may use lower numbers, if I2C + messages are lost (16 is known to work on + all supported cards). bttv_gpio=0/1 gpiomask= diff --git a/Documentation/video4linux/cx2341x/README.hm12 b/Documentation/video4linux/cx2341x/README.hm12 new file mode 100644 index 000000000000..0e213ed095e6 --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.hm12 @@ -0,0 +1,116 @@ +The cx23416 can produce (and the cx23415 can also read) raw YUV output. The +format of a YUV frame is specific to this chip and is called HM12. 'HM' stands +for 'Hauppauge Macroblock', which is a misnomer as 'Conexant Macroblock' would +be more accurate. + +The format is YUV 4:2:0 which uses 1 Y byte per pixel and 1 U and V byte per +four pixels. + +The data is encoded as two macroblock planes, the first containing the Y +values, the second containing UV macroblocks. + +The Y plane is divided into blocks of 16x16 pixels from left to right +and from top to bottom. Each block is transmitted in turn, line-by-line. + +So the first 16 bytes are the first line of the top-left block, the +second 16 bytes are the second line of the top-left block, etc. After +transmitting this block the first line of the block on the right to the +first block is transmitted, etc. + +The UV plane is divided into blocks of 16x8 UV values going from left +to right, top to bottom. Each block is transmitted in turn, line-by-line. + +So the first 16 bytes are the first line of the top-left block and +contain 8 UV value pairs (16 bytes in total). The second 16 bytes are the +second line of 8 UV pairs of the top-left block, etc. After transmitting +this block the first line of the block on the right to the first block is +transmitted, etc. + +The code below is given as an example on how to convert HM12 to separate +Y, U and V planes. This code assumes frames of 720x576 (PAL) pixels. + +The width of a frame is always 720 pixels, regardless of the actual specified +width. + +-------------------------------------------------------------------------- + +#include <stdio.h> +#include <stdlib.h> +#include <string.h> + +static unsigned char frame[576*720*3/2]; +static unsigned char framey[576*720]; +static unsigned char frameu[576*720 / 4]; +static unsigned char framev[576*720 / 4]; + +static void de_macro_y(unsigned char* dst, unsigned char *src, int dstride, int w, int h) +{ + unsigned int y, x, i; + + // descramble Y plane + // dstride = 720 = w + // The Y plane is divided into blocks of 16x16 pixels + // Each block in transmitted in turn, line-by-line. + for (y = 0; y < h; y += 16) { + for (x = 0; x < w; x += 16) { + for (i = 0; i < 16; i++) { + memcpy(dst + x + (y + i) * dstride, src, 16); + src += 16; + } + } + } +} + +static void de_macro_uv(unsigned char *dstu, unsigned char *dstv, unsigned char *src, int dstride, int w, int h) +{ + unsigned int y, x, i; + + // descramble U/V plane + // dstride = 720 / 2 = w + // The U/V values are interlaced (UVUV...). + // Again, the UV plane is divided into blocks of 16x16 UV values. + // Each block in transmitted in turn, line-by-line. + for (y = 0; y < h; y += 16) { + for (x = 0; x < w; x += 8) { + for (i = 0; i < 16; i++) { + int idx = x + (y + i) * dstride; + + dstu[idx+0] = src[0]; dstv[idx+0] = src[1]; + dstu[idx+1] = src[2]; dstv[idx+1] = src[3]; + dstu[idx+2] = src[4]; dstv[idx+2] = src[5]; + dstu[idx+3] = src[6]; dstv[idx+3] = src[7]; + dstu[idx+4] = src[8]; dstv[idx+4] = src[9]; + dstu[idx+5] = src[10]; dstv[idx+5] = src[11]; + dstu[idx+6] = src[12]; dstv[idx+6] = src[13]; + dstu[idx+7] = src[14]; dstv[idx+7] = src[15]; + src += 16; + } + } + } +} + +/*************************************************************************/ +int main(int argc, char **argv) +{ + FILE *fin; + int i; + + if (argc == 1) fin = stdin; + else fin = fopen(argv[1], "r"); + + if (fin == NULL) { + fprintf(stderr, "cannot open input\n"); + exit(-1); + } + while (fread(frame, sizeof(frame), 1, fin) == 1) { + de_macro_y(framey, frame, 720, 720, 576); + de_macro_uv(frameu, framev, frame + 720 * 576, 720 / 2, 720 / 2, 576 / 2); + fwrite(framey, sizeof(framey), 1, stdout); + fwrite(framev, sizeof(framev), 1, stdout); + fwrite(frameu, sizeof(frameu), 1, stdout); + } + fclose(fin); + return 0; +} + +-------------------------------------------------------------------------- diff --git a/Documentation/video4linux/cx2341x/README.vbi b/Documentation/video4linux/cx2341x/README.vbi new file mode 100644 index 000000000000..5807cf156173 --- /dev/null +++ b/Documentation/video4linux/cx2341x/README.vbi @@ -0,0 +1,45 @@ + +Format of embedded V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data +========================================================= + +This document describes the V4L2_MPEG_STREAM_VBI_FMT_IVTV format of the VBI data +embedded in an MPEG-2 program stream. This format is in part dictated by some +hardware limitations of the ivtv driver (the driver for the Conexant cx23415/6 +chips), in particular a maximum size for the VBI data. Anything longer is cut +off when the MPEG stream is played back through the cx23415. + +The advantage of this format is it is very compact and that all VBI data for +all lines can be stored while still fitting within the maximum allowed size. + +The stream ID of the VBI data is 0xBD. The maximum size of the embedded data is +4 + 43 * 36, which is 4 bytes for a header and 2 * 18 VBI lines with a 1 byte +header and a 42 bytes payload each. Anything beyond this limit is cut off by +the cx23415/6 firmware. Besides the data for the VBI lines we also need 36 bits +for a bitmask determining which lines are captured and 4 bytes for a magic cookie, +signifying that this data package contains V4L2_MPEG_STREAM_VBI_FMT_IVTV VBI data. +If all lines are used, then there is no longer room for the bitmask. To solve this +two different magic numbers were introduced: + +'itv0': After this magic number two unsigned longs follow. Bits 0-17 of the first +unsigned long denote which lines of the first field are captured. Bits 18-31 of +the first unsigned long and bits 0-3 of the second unsigned long are used for the +second field. + +'ITV0': This magic number assumes all VBI lines are captured, i.e. it implicitly +implies that the bitmasks are 0xffffffff and 0xf. + +After these magic cookies (and the 8 byte bitmask in case of cookie 'itv0') the +captured VBI lines start: + +For each line the least significant 4 bits of the first byte contain the data type. +Possible values are shown in the table below. The payload is in the following 42 +bytes. + +Here is the list of possible data types: + +#define IVTV_SLICED_TYPE_TELETEXT 0x1 // Teletext (uses lines 6-22 for PAL) +#define IVTV_SLICED_TYPE_CC 0x4 // Closed Captions (line 21 NTSC) +#define IVTV_SLICED_TYPE_WSS 0x5 // Wide Screen Signal (line 23 PAL) +#define IVTV_SLICED_TYPE_VPS 0x7 // Video Programming System (PAL) (line 16) + +Hans Verkuil <hverkuil@xs4all.nl> diff --git a/Documentation/video4linux/cx2341x/fw-decoder-api.txt b/Documentation/video4linux/cx2341x/fw-decoder-api.txt index 9df4fb3ea0f2..78bf5f21e513 100644 --- a/Documentation/video4linux/cx2341x/fw-decoder-api.txt +++ b/Documentation/video4linux/cx2341x/fw-decoder-api.txt @@ -102,7 +102,7 @@ Param[0] Name CX2341X_DEC_GET_XFER_INFO Enum 9/0x09 Description - This API call may be used to detect an end of stream condtion. + This API call may be used to detect an end of stream condition. Result[0] Stream type Result[1] diff --git a/Documentation/video4linux/cx2341x/fw-encoder-api.txt b/Documentation/video4linux/cx2341x/fw-encoder-api.txt index 001c68644b08..15df0df57ddd 100644 --- a/Documentation/video4linux/cx2341x/fw-encoder-api.txt +++ b/Documentation/video4linux/cx2341x/fw-encoder-api.txt @@ -280,7 +280,7 @@ Param[0] Param[1] Unknown, but leaving this to 0 seems to work best. Indications are that this might have to do with USB support, although passing anything but 0 - onl breaks things. + only breaks things. ------------------------------------------------------------------------------- diff --git a/Documentation/video4linux/cx2341x/fw-osd-api.txt b/Documentation/video4linux/cx2341x/fw-osd-api.txt index da98ae30a37a..0a602f3e601b 100644 --- a/Documentation/video4linux/cx2341x/fw-osd-api.txt +++ b/Documentation/video4linux/cx2341x/fw-osd-api.txt @@ -97,7 +97,7 @@ Result[0] Result[1] top left vertical offset Result[2] - bottom right hotizontal offset + bottom right horizontal offset Result[3] bottom right vertical offset diff --git a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt index 93fec32a1188..faccee68f603 100644 --- a/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt +++ b/Documentation/video4linux/cx88/hauppauge-wintv-cx88-ir.txt @@ -30,7 +30,7 @@ provide for a handler) GP_SAMPLE register is at 0x35C058 Bits are then right shifted into the GP_SAMPLE register at the specified -rate; you get an interrupt when a full DWORD is recieved. +rate; you get an interrupt when a full DWORD is received. You need to recover the actual RC5 bits out of the (oversampled) IR sensor bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment. diff --git a/Documentation/video4linux/et61x251.txt b/Documentation/video4linux/et61x251.txt index cd584f20a997..1bdee8f85b9a 100644 --- a/Documentation/video4linux/et61x251.txt +++ b/Documentation/video4linux/et61x251.txt @@ -80,7 +80,7 @@ Some of the features of the driver are: high compression quality (see also "Notes for V4L2 application developers" paragraph); - full support for the capabilities of every possible image sensors that can - be connected to the ET61X[12]51 bridges, including, for istance, red, green, + be connected to the ET61X[12]51 bridges, including, for instance, red, green, blue and global gain adjustments and exposure control (see "Supported devices" paragraph for details); - use of default color settings for sunlight conditions; @@ -222,7 +222,7 @@ identifier - of the camera registered as "/dev/video0": [root@localhost #] echo 1 > i2c_reg [root@localhost #] cat i2c_val -Note that if the sensor registers can not be read, "cat" will fail. +Note that if the sensor registers cannot be read, "cat" will fail. To avoid race conditions, all the I/O accesses to the files are serialized. diff --git a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt index 93fec32a1188..faccee68f603 100644 --- a/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt +++ b/Documentation/video4linux/hauppauge-wintv-cx88-ir.txt @@ -30,7 +30,7 @@ provide for a handler) GP_SAMPLE register is at 0x35C058 Bits are then right shifted into the GP_SAMPLE register at the specified -rate; you get an interrupt when a full DWORD is recieved. +rate; you get an interrupt when a full DWORD is received. You need to recover the actual RC5 bits out of the (oversampled) IR sensor bits. (Hint: look for the 0/1and 1/0 crossings of the RC5 bi-phase data) An actual raw RC5 code will span 2-3 DWORDS, depending on the actual alignment. diff --git a/Documentation/video4linux/meye.txt b/Documentation/video4linux/meye.txt index 2137da97552f..ecb34160e61d 100644 --- a/Documentation/video4linux/meye.txt +++ b/Documentation/video4linux/meye.txt @@ -29,7 +29,7 @@ driver (PCI vendor/device is 0x136b/0xff01) The third one, present in recent (more or less last year) Picturebooks (C1M* models), is not supported. The manufacturer has given the specs -to the developers under a NDA (which allows the develoment of a GPL +to the developers under a NDA (which allows the development of a GPL driver however), but things are not moving very fast (see http://r-engine.sourceforge.net/) (PCI vendor/device is 0x10cf/0x2011). diff --git a/Documentation/video4linux/sn9c102.txt b/Documentation/video4linux/sn9c102.txt index 1d20895b4354..8cda472db36d 100644 --- a/Documentation/video4linux/sn9c102.txt +++ b/Documentation/video4linux/sn9c102.txt @@ -60,7 +60,7 @@ It's worth to note that SONiX has never collaborated with the author during the development of this project, despite several requests for enough detailed specifications of the register tables, compression engine and video data format of the above chips. Nevertheless, these informations are no longer necessary, -becouse all the aspects related to these chips are known and have been +because all the aspects related to these chips are known and have been described in detail in this documentation. The driver relies on the Video4Linux2 and USB core modules. It has been @@ -85,7 +85,7 @@ Some of the features of the driver are: high compression quality (see also "Notes for V4L2 application developers" and "Video frame formats" paragraphs); - full support for the capabilities of many of the possible image sensors that - can be connected to the SN9C10x bridges, including, for istance, red, green, + can be connected to the SN9C10x bridges, including, for instance, red, green, blue and global gain adjustments and exposure (see "Supported devices" paragraph for details); - use of default color settings for sunlight conditions; diff --git a/Documentation/video4linux/w9968cf.txt b/Documentation/video4linux/w9968cf.txt index 0d53ce774b01..e0bba8393c77 100644 --- a/Documentation/video4linux/w9968cf.txt +++ b/Documentation/video4linux/w9968cf.txt @@ -15,7 +15,7 @@ Index 5. Supported devices 6. Module dependencies 7. Module loading -8. Module paramaters +8. Module parameters 9. Contact information 10. Credits diff --git a/Documentation/video4linux/zr36120.txt b/Documentation/video4linux/zr36120.txt index ac6d92d01944..1a1c2d03a5c8 100644 --- a/Documentation/video4linux/zr36120.txt +++ b/Documentation/video4linux/zr36120.txt @@ -118,9 +118,9 @@ card is not there, please try if any other card gives some response, and mail me if you got a working tvcard addition. PS. <TVCard editors behold!) - Dont forget to set video_input to the number of inputs + Don't forget to set video_input to the number of inputs you defined in the video_mux part of the tvcard definition. - Its a common error to add a channel but not incrementing + It's a common error to add a channel but not incrementing video_input and getting angry with me/v4l/linux/linus :( You are now ready to test the framegrabber with your favorite diff --git a/Documentation/vm/numa b/Documentation/vm/numa index 4b8db1bd3b78..e93ad9425e2a 100644 --- a/Documentation/vm/numa +++ b/Documentation/vm/numa @@ -22,7 +22,7 @@ The initial port includes NUMAizing the bootmem allocator code by encapsulating all the pieces of information into a bootmem_data_t structure. Node specific calls have been added to the allocator. In theory, any platform which uses the bootmem allocator should -be able to to put the bootmem and mem_map data structures anywhere +be able to put the bootmem and mem_map data structures anywhere it deems best. Each node's page allocation data structures have also been encapsulated diff --git a/Documentation/watchdog/watchdog-api.txt b/Documentation/watchdog/watchdog-api.txt index 958ff3d48be3..7e8ae83e9847 100644 --- a/Documentation/watchdog/watchdog-api.txt +++ b/Documentation/watchdog/watchdog-api.txt @@ -45,7 +45,7 @@ daemon and it crashes the system will not reboot. Because of this, some of the drivers support the configuration option "Disable watchdog shutdown on close", CONFIG_WATCHDOG_NOWAYOUT. If it is set to Y when compiling the kernel, there is no way of disabling the watchdog once -it has been started. So, if the watchdog dameon crashes, the system +it has been started. So, if the watchdog daemon crashes, the system will reboot after the timeout has passed. Some other drivers will not disable the watchdog, unless a specific @@ -207,7 +207,7 @@ Note that not all devices support these two calls, and some only support the GETBOOTSTATUS call. Some drivers can measure the temperature using the GETTEMP ioctl. The -returned value is the temperature in degrees farenheit. +returned value is the temperature in degrees fahrenheit. int temperature; ioctl(fd, WDIOC_GETTEMP, &temperature); @@ -258,13 +258,13 @@ booke_wdt.c -- PowerPC BookE Watchdog Timer Timeout default varies according to frequency, supports SETTIMEOUT - Watchdog can not be turned off, CONFIG_WATCHDOG_NOWAYOUT + Watchdog cannot be turned off, CONFIG_WATCHDOG_NOWAYOUT does not make sense GETSUPPORT returns the watchdog_info struct, and GETSTATUS returns the supported options. GETBOOTSTATUS returns a 1 if the last reset was caused by the - watchdog and a 0 otherwise. This watchdog can not be + watchdog and a 0 otherwise. This watchdog cannot be disabled once it has been started. The wdt_period kernel parameter selects which bit of the time base changing from 0->1 will trigger the watchdog exception. Changing diff --git a/Documentation/x86_64/boot-options.txt b/Documentation/x86_64/boot-options.txt index 6da24e7a56cb..f3c57f43ba64 100644 --- a/Documentation/x86_64/boot-options.txt +++ b/Documentation/x86_64/boot-options.txt @@ -109,7 +109,7 @@ Idle loop Rebooting reboot=b[ios] | t[riple] | k[bd] [, [w]arm | [c]old] - bios Use the CPU reboto vector for warm reset + bios Use the CPU reboot vector for warm reset warm Don't set the cold reboot flag cold Set the cold reboot flag triple Force a triple fault (init) @@ -199,6 +199,11 @@ IOMMU allowed overwrite iommu off workarounds for specific chipsets. soft Use software bounce buffering (default for Intel machines) noaperture Don't touch the aperture for AGP. + allowdac Allow DMA >4GB + When off all DMA over >4GB is forced through an IOMMU or bounce + buffering. + nodac Forbid DMA >4GB + panic Always panic when IOMMU overflows swiotlb=pages[,force] @@ -245,6 +250,13 @@ Debugging newfallback: use new unwinder but fall back to old if it gets stuck (default) + call_trace=[old|both|newfallback|new] + old: use old inexact backtracer + new: use new exact dwarf2 unwinder + both: print entries from both + newfallback: use new unwinder but fall back to old if it gets + stuck (default) + Misc noreplacement Don't replace instructions with more appropriate ones diff --git a/Documentation/x86_64/kernel-stacks b/Documentation/x86_64/kernel-stacks new file mode 100644 index 000000000000..bddfddd466ab --- /dev/null +++ b/Documentation/x86_64/kernel-stacks @@ -0,0 +1,99 @@ +Most of the text from Keith Owens, hacked by AK + +x86_64 page size (PAGE_SIZE) is 4K. + +Like all other architectures, x86_64 has a kernel stack for every +active thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big. +These stacks contain useful data as long as a thread is alive or a +zombie. While the thread is in user space the kernel stack is empty +except for the thread_info structure at the bottom. + +In addition to the per thread stacks, there are specialized stacks +associated with each cpu. These stacks are only used while the kernel +is in control on that cpu, when a cpu returns to user space the +specialized stacks contain no useful data. The main cpu stacks is + +* Interrupt stack. IRQSTACKSIZE + + Used for external hardware interrupts. If this is the first external + hardware interrupt (i.e. not a nested hardware interrupt) then the + kernel switches from the current task to the interrupt stack. Like + the split thread and interrupt stacks on i386 (with CONFIG_4KSTACKS), + this gives more room for kernel interrupt processing without having + to increase the size of every per thread stack. + + The interrupt stack is also used when processing a softirq. + +Switching to the kernel interrupt stack is done by software based on a +per CPU interrupt nest counter. This is needed because x86-64 "IST" +hardware stacks cannot nest without races. + +x86_64 also has a feature which is not available on i386, the ability +to automatically switch to a new stack for designated events such as +double fault or NMI, which makes it easier to handle these unusual +events on x86_64. This feature is called the Interrupt Stack Table +(IST). There can be up to 7 IST entries per cpu. The IST code is an +index into the Task State Segment (TSS), the IST entries in the TSS +point to dedicated stacks, each stack can be a different size. + +An IST is selected by an non-zero value in the IST field of an +interrupt-gate descriptor. When an interrupt occurs and the hardware +loads such a descriptor, the hardware automatically sets the new stack +pointer based on the IST value, then invokes the interrupt handler. If +software wants to allow nested IST interrupts then the handler must +adjust the IST values on entry to and exit from the interrupt handler. +(this is occasionally done, e.g. for debug exceptions) + +Events with different IST codes (i.e. with different stacks) can be +nested. For example, a debug interrupt can safely be interrupted by an +NMI. arch/x86_64/kernel/entry.S::paranoidentry adjusts the stack +pointers on entry to and exit from all IST events, in theory allowing +IST events with the same code to be nested. However in most cases, the +stack size allocated to an IST assumes no nesting for the same code. +If that assumption is ever broken then the stacks will become corrupt. + +The currently assigned IST stacks are :- + +* STACKFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). + + Used for interrupt 12 - Stack Fault Exception (#SS). + + This allows to recover from invalid stack segments. Rarely + happens. + +* DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE). + + Used for interrupt 8 - Double Fault Exception (#DF). + + Invoked when handling a exception causes another exception. Happens + when the kernel is very confused (e.g. kernel stack pointer corrupt) + Using a separate stack allows to recover from it well enough in many + cases to still output an oops. + +* NMI_STACK. EXCEPTION_STKSZ (PAGE_SIZE). + + Used for non-maskable interrupts (NMI). + + NMI can be delivered at any time, including when the kernel is in the + middle of switching stacks. Using IST for NMI events avoids making + assumptions about the previous state of the kernel stack. + +* DEBUG_STACK. DEBUG_STKSZ + + Used for hardware debug interrupts (interrupt 1) and for software + debug interrupts (INT3). + + When debugging a kernel, debug interrupts (both hardware and + software) can occur at any time. Using IST for these interrupts + avoids making assumptions about the previous state of the kernel + stack. + +* MCE_STACK. EXCEPTION_STKSZ (PAGE_SIZE). + + Used for interrupt 18 - Machine Check Exception (#MC). + + MCE can be delivered at any time, including when the kernel is in the + middle of switching stacks. Using IST for MCE events avoids making + assumptions about the previous state of the kernel stack. + +For more details see the Intel IA32 or AMD AMD64 architecture manuals. |