diff --git a/[refs] b/[refs] index 6fc843f33872..0b5a463d2317 100644 --- a/[refs] +++ b/[refs] @@ -1,2 +1,2 @@ --- -refs/heads/master: b1681c56f5b6bf551bed2617a395855055836571 +refs/heads/master: 1c8a375185935f8106a45221bd187b7b272f97c2 diff --git a/trunk/.gitignore b/trunk/.gitignore index de6344e15706..946c7ec5c922 100644 --- a/trunk/.gitignore +++ b/trunk/.gitignore @@ -22,7 +22,6 @@ *.lst *.symtypes *.order -modules.builtin *.elf *.bin *.gz @@ -37,7 +36,6 @@ modules.builtin tags TAGS vmlinux -vmlinuz System.map Module.markers Module.symvers @@ -47,8 +45,14 @@ Module.symvers # # Generated include files # +include/asm +include/asm-*/asm-offsets.h include/config +include/linux/autoconf.h +include/linux/compile.h include/linux/version.h +include/linux/utsrelease.h +include/linux/bounds.h include/generated # stgit generated dirs diff --git a/trunk/Documentation/ABI/testing/sysfs-bus-usb b/trunk/Documentation/ABI/testing/sysfs-bus-usb index a07c0f366f91..deb6b489e4e5 100644 --- a/trunk/Documentation/ABI/testing/sysfs-bus-usb +++ b/trunk/Documentation/ABI/testing/sysfs-bus-usb @@ -21,27 +21,25 @@ Contact: Alan Stern Description: Each USB device directory will contain a file named power/level. This file holds a power-level setting for - the device, either "on" or "auto". + the device, one of "on", "auto", or "suspend". "on" means that the device is not allowed to autosuspend, although normal suspends for system sleep will still be honored. "auto" means the device will autosuspend and autoresume in the usual manner, according to the - capabilities of its driver. + capabilities of its driver. "suspend" means the device + is forced into a suspended state and it will not autoresume + in response to I/O requests. However remote-wakeup requests + from the device may still be enabled (the remote-wakeup + setting is controlled separately by the power/wakeup + attribute). During normal use, devices should be left in the "auto" - level. The "on" level is meant for administrative uses. + level. The other levels are meant for administrative uses. If you want to suspend a device immediately but leave it free to wake up in response to I/O requests, you should write "0" to power/autosuspend. - Device not capable of proper suspend and resume should be - left in the "on" level. Although the USB spec requires - devices to support suspend/resume, many of them do not. - In fact so many don't that by default, the USB core - initializes all non-hub devices in the "on" level. Some - drivers may change this setting when they are bound. - What: /sys/bus/usb/devices/.../power/persist Date: May 2007 KernelVersion: 2.6.23 diff --git a/trunk/Documentation/ABI/testing/sysfs-devices-memory b/trunk/Documentation/ABI/testing/sysfs-devices-memory index bf1627b02a03..9fe91c02ee40 100644 --- a/trunk/Documentation/ABI/testing/sysfs-devices-memory +++ b/trunk/Documentation/ABI/testing/sysfs-devices-memory @@ -60,19 +60,6 @@ Description: Users: hotplug memory remove tools https://w3.opensource.ibm.com/projects/powerpc-utils/ - -What: /sys/devices/system/memoryX/nodeY -Date: October 2009 -Contact: Linux Memory Management list -Description: - When CONFIG_NUMA is enabled, a symbolic link that - points to the corresponding NUMA node directory. - - For example, the following symbolic link is created for - memory section 9 on node0: - /sys/devices/system/memory/memory9/node0 -> ../../node/node0 - - What: /sys/devices/system/node/nodeX/memoryY Date: September 2008 Contact: Gary Hade @@ -83,3 +70,4 @@ Description: memory section directory. For example, the following symbolic link is created for memory section 9 on node0. /sys/devices/system/node/node0/memory9 -> ../../memory/memory9 + diff --git a/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu b/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu index 84a710f87c64..2aae06fcbed7 100644 --- a/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/trunk/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -92,20 +92,6 @@ Description: Discover NUMA node a CPU belongs to /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 -What: /sys/devices/system/cpu/cpu#/node -Date: October 2009 -Contact: Linux memory management mailing list -Description: Discover NUMA node a CPU belongs to - - When CONFIG_NUMA is enabled, a symbolic link that points - to the corresponding NUMA node directory. - - For example, the following symlink is created for cpu42 - in NUMA node 2: - - /sys/devices/system/cpu/cpu42/node2 -> ../../node/node2 - - What: /sys/devices/system/cpu/cpu#/topology/core_id /sys/devices/system/cpu/cpu#/topology/core_siblings /sys/devices/system/cpu/cpu#/topology/core_siblings_list diff --git a/trunk/Documentation/ABI/testing/sysfs-memory-page-offline b/trunk/Documentation/ABI/testing/sysfs-memory-page-offline deleted file mode 100644 index e14703f12fdf..000000000000 --- a/trunk/Documentation/ABI/testing/sysfs-memory-page-offline +++ /dev/null @@ -1,44 +0,0 @@ -What: /sys/devices/system/memory/soft_offline_page -Date: Sep 2009 -KernelVersion: 2.6.33 -Contact: andi@firstfloor.org -Description: - Soft-offline the memory page containing the physical address - written into this file. Input is a hex number specifying the - physical address of the page. The kernel will then attempt - to soft-offline it, by moving the contents elsewhere or - dropping it if possible. The kernel will then be placed - on the bad page list and never be reused. - - The offlining is done in kernel specific granuality. - Normally it's the base page size of the kernel, but - this might change. - - The page must be still accessible, not poisoned. The - kernel will never kill anything for this, but rather - fail the offline. Return value is the size of the - number, or a error when the offlining failed. Reading - the file is not allowed. - -What: /sys/devices/system/memory/hard_offline_page -Date: Sep 2009 -KernelVersion: 2.6.33 -Contact: andi@firstfloor.org -Description: - Hard-offline the memory page containing the physical - address written into this file. Input is a hex number - specifying the physical address of the page. The - kernel will then attempt to hard-offline the page, by - trying to drop the page or killing any owner or - triggering IO errors if needed. Note this may kill - any processes owning the page. The kernel will avoid - to access this page assuming it's poisoned by the - hardware. - - The offlining is done in kernel specific granuality. - Normally it's the base page size of the kernel, but - this might change. - - Return value is the size of the number, or a error when - the offlining failed. - Reading the file is not allowed. diff --git a/trunk/Documentation/Changes b/trunk/Documentation/Changes index f08b313cd235..6d0f1efc5bf6 100644 --- a/trunk/Documentation/Changes +++ b/trunk/Documentation/Changes @@ -49,8 +49,6 @@ o oprofile 0.9 # oprofiled --version o udev 081 # udevinfo -V o grub 0.93 # grub --version o mcelog 0.6 -o iptables 1.4.1 # iptables -V - Kernel compilation ================== diff --git a/trunk/Documentation/PCI/PCI-DMA-mapping.txt b/trunk/Documentation/DMA-mapping.txt similarity index 100% rename from trunk/Documentation/PCI/PCI-DMA-mapping.txt rename to trunk/Documentation/DMA-mapping.txt diff --git a/trunk/Documentation/DocBook/Makefile b/trunk/Documentation/DocBook/Makefile index 325cfd1d6d99..ab8300f67182 100644 --- a/trunk/Documentation/DocBook/Makefile +++ b/trunk/Documentation/DocBook/Makefile @@ -8,7 +8,7 @@ DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \ kernel-hacking.xml kernel-locking.xml deviceiobook.xml \ - writing_usb_driver.xml networking.xml \ + procfs-guide.xml writing_usb_driver.xml networking.xml \ kernel-api.xml filesystems.xml lsm.xml usb.xml kgdb.xml \ gadget.xml libata.xml mtdnand.xml librs.xml rapidio.xml \ genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \ @@ -32,10 +32,10 @@ PS_METHOD = $(prefer-db2x) ### # The targets that may be used. -PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks +PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs media BOOKS := $(addprefix $(obj)/,$(DOCBOOKS)) -xmldocs: $(BOOKS) xmldoclinks +xmldocs: $(BOOKS) sgmldocs: xmldocs PS := $(patsubst %.xml, %.ps, $(BOOKS)) @@ -45,24 +45,15 @@ PDF := $(patsubst %.xml, %.pdf, $(BOOKS)) pdfdocs: $(PDF) HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS))) -htmldocs: $(HTML) +htmldocs: media $(HTML) $(call build_main_index) - $(call build_images) MAN := $(patsubst %.xml, %.9, $(BOOKS)) mandocs: $(MAN) -build_images = mkdir -p $(objtree)/Documentation/DocBook/media/ && \ - cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(objtree)/Documentation/DocBook/media/ - -xmldoclinks: -ifneq ($(objtree),$(srctree)) - for dep in dvb media-entities.tmpl media-indices.tmpl v4l; do \ - rm -f $(objtree)/Documentation/DocBook/$$dep \ - && ln -s $(srctree)/Documentation/DocBook/$$dep $(objtree)/Documentation/DocBook/ \ - || exit; \ - done -endif +media: + mkdir -p $(srctree)/Documentation/DocBook/media/ + cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(srctree)/Documentation/DocBook/media/ installmandocs: mandocs mkdir -p /usr/local/man/man9/ @@ -74,7 +65,7 @@ KERNELDOC = $(srctree)/scripts/kernel-doc DOCPROC = $(objtree)/scripts/basic/docproc XMLTOFLAGS = -m $(srctree)/Documentation/DocBook/stylesheet.xsl -XMLTOFLAGS += --skip-validation +#XMLTOFLAGS += --skip-validation ### # DOCPROC is used for two purposes: @@ -110,6 +101,17 @@ endif # Changes in kernel-doc force a rebuild of all documentation $(BOOKS): $(KERNELDOC) +### +# procfs guide uses a .c file as example code. +# This requires an explicit dependency +C-procfs-example = procfs_example.xml +C-procfs-example2 = $(addprefix $(obj)/,$(C-procfs-example)) +$(obj)/procfs-guide.xml: $(C-procfs-example2) + +# List of programs to build +##oops, this is a kernel module::hostprogs-y := procfs_example +obj-m += procfs_example.o + # Tell kbuild to always build the programs always := $(hostprogs-y) @@ -236,7 +238,7 @@ clean-files := $(DOCBOOKS) \ $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ $(patsubst %.xml, %.html, $(DOCBOOKS)) \ $(patsubst %.xml, %.9, $(DOCBOOKS)) \ - $(index) + $(C-procfs-example) $(index) clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man diff --git a/trunk/Documentation/DocBook/media-entities.tmpl b/trunk/Documentation/DocBook/media-entities.tmpl index c725cb852c54..bb5ab741220e 100644 --- a/trunk/Documentation/DocBook/media-entities.tmpl +++ b/trunk/Documentation/DocBook/media-entities.tmpl @@ -23,7 +23,6 @@ VIDIOC_ENUMINPUT"> VIDIOC_ENUMOUTPUT"> VIDIOC_ENUMSTD"> -VIDIOC_ENUM_DV_PRESETS"> VIDIOC_ENUM_FMT"> VIDIOC_ENUM_FRAMEINTERVALS"> VIDIOC_ENUM_FRAMESIZES"> @@ -31,8 +30,6 @@ VIDIOC_G_AUDOUT"> VIDIOC_G_CROP"> VIDIOC_G_CTRL"> -VIDIOC_G_DV_PRESET"> -VIDIOC_G_DV_TIMINGS"> VIDIOC_G_ENC_INDEX"> VIDIOC_G_EXT_CTRLS"> VIDIOC_G_FBUF"> @@ -56,7 +53,6 @@ VIDIOC_QUERYCTRL"> VIDIOC_QUERYMENU"> VIDIOC_QUERYSTD"> -VIDIOC_QUERY_DV_PRESET"> VIDIOC_REQBUFS"> VIDIOC_STREAMOFF"> VIDIOC_STREAMON"> @@ -64,8 +60,6 @@ VIDIOC_S_AUDOUT"> VIDIOC_S_CROP"> VIDIOC_S_CTRL"> -VIDIOC_S_DV_PRESET"> -VIDIOC_S_DV_TIMINGS"> VIDIOC_S_EXT_CTRLS"> VIDIOC_S_FBUF"> VIDIOC_S_FMT"> @@ -124,7 +118,6 @@ v4l2_audio"> v4l2_audioout"> -v4l2_bt_timings"> v4l2_buffer"> v4l2_capability"> v4l2_captureparm"> @@ -135,9 +128,6 @@ v4l2_dbg_chip_ident"> v4l2_dbg_match"> v4l2_dbg_register"> -v4l2_dv_enum_preset"> -v4l2_dv_preset"> -v4l2_dv_timings"> v4l2_enc_idx"> v4l2_enc_idx_entry"> v4l2_encoder_cmd"> @@ -253,10 +243,6 @@ - - - - @@ -347,10 +333,6 @@ - - - - diff --git a/trunk/Documentation/DocBook/media-indices.tmpl b/trunk/Documentation/DocBook/media-indices.tmpl index 78d6031de001..9e30a236d74f 100644 --- a/trunk/Documentation/DocBook/media-indices.tmpl +++ b/trunk/Documentation/DocBook/media-indices.tmpl @@ -36,7 +36,6 @@ enum v4l2_preemphasis struct v4l2_audio struct v4l2_audioout -struct v4l2_bt_timings struct v4l2_buffer struct v4l2_capability struct v4l2_captureparm @@ -47,9 +46,6 @@ struct v4l2_dbg_chip_ident struct v4l2_dbg_match struct v4l2_dbg_register -struct v4l2_dv_enum_preset -struct v4l2_dv_preset -struct v4l2_dv_timings struct v4l2_enc_idx struct v4l2_enc_idx_entry struct v4l2_encoder_cmd diff --git a/trunk/Documentation/DocBook/mtdnand.tmpl b/trunk/Documentation/DocBook/mtdnand.tmpl index 5e7d84b48505..f508a8a27fea 100644 --- a/trunk/Documentation/DocBook/mtdnand.tmpl +++ b/trunk/Documentation/DocBook/mtdnand.tmpl @@ -174,7 +174,7 @@ static struct mtd_info *board_mtd; -static void __iomem *baseaddr; +static unsigned long baseaddr; Static example @@ -182,7 +182,7 @@ static void __iomem *baseaddr; static struct mtd_info board_mtd; static struct nand_chip board_chip; -static void __iomem *baseaddr; +static unsigned long baseaddr; @@ -283,8 +283,8 @@ int __init board_init (void) } /* map physical address */ - baseaddr = ioremap(CHIP_PHYSICAL_ADDRESS, 1024); - if (!baseaddr) { + baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024); + if(!baseaddr){ printk("Ioremap to access NAND chip failed\n"); err = -EIO; goto out_mtd; @@ -316,7 +316,7 @@ int __init board_init (void) goto out; out_ior: - iounmap(baseaddr); + iounmap((void *)baseaddr); out_mtd: kfree (board_mtd); out: @@ -341,7 +341,7 @@ static void __exit board_cleanup (void) nand_release (board_mtd); /* unmap physical address */ - iounmap(baseaddr); + iounmap((void *)baseaddr); /* Free the MTD device structure */ kfree (board_mtd); diff --git a/trunk/Documentation/DocBook/procfs-guide.tmpl b/trunk/Documentation/DocBook/procfs-guide.tmpl new file mode 100644 index 000000000000..9eba4b7af73d --- /dev/null +++ b/trunk/Documentation/DocBook/procfs-guide.tmpl @@ -0,0 +1,626 @@ + + +]> + + + + Linux Kernel Procfs Guide + + + + Erik + (J.A.K.) + Mouw + +
+ mouw@nl.linux.org +
+ + + + + This software and documentation were written while working on the + LART computing board + (http://www.lartmaker.nl/), + which was sponsored by the Delt University of Technology projects + Mobile Multi-media Communications and Ubiquitous Communications. + + + + + + + 1.0 + May 30, 2001 + Initial revision posted to linux-kernel + + + 1.1 + June 3, 2001 + Revised after comments from linux-kernel + + + + + 2001 + Erik Mouw + + + + + + This documentation 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 documentation 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., 59 Temple Place, Suite 330, Boston, + MA 02111-1307 USA + + + + For more details see the file COPYING in the source + distribution of Linux. + + + + + + + + + + + + + + + Preface + + + This guide describes the use of the procfs file system from + within the Linux kernel. The idea to write this guide came up on + the #kernelnewbies IRC channel (see http://www.kernelnewbies.org/), + when Jeff Garzik explained the use of procfs and forwarded me a + message Alexander Viro wrote to the linux-kernel mailing list. I + agreed to write it up nicely, so here it is. + + + + I'd like to thank Jeff Garzik + jgarzik@pobox.com and Alexander Viro + viro@parcelfarce.linux.theplanet.co.uk for their input, + Tim Waugh twaugh@redhat.com for his Selfdocbook, + and Marc Joosen marcj@historia.et.tudelft.nl for + proofreading. + + + + Erik + + + + + + + + Introduction + + + The /proc file system + (procfs) is a special file system in the linux kernel. It's a + virtual file system: it is not associated with a block device + but exists only in memory. The files in the procfs are there to + allow userland programs access to certain information from the + kernel (like process information in /proc/[0-9]+/), but also for debug + purposes (like /proc/ksyms). + + + + This guide describes the use of the procfs file system from + within the Linux kernel. It starts by introducing all relevant + functions to manage the files within the file system. After that + it shows how to communicate with userland, and some tips and + tricks will be pointed out. Finally a complete example will be + shown. + + + + Note that the files in /proc/sys are sysctl files: they + don't belong to procfs and are governed by a completely + different API described in the Kernel API book. + + + + + + + + Managing procfs entries + + + This chapter describes the functions that various kernel + components use to populate the procfs with files, symlinks, + device nodes, and directories. + + + + A minor note before we start: if you want to use any of the + procfs functions, be sure to include the correct header file! + This should be one of the first lines in your code: + + + +#include <linux/proc_fs.h> + + + + + + + Creating a regular file + + + + struct proc_dir_entry* create_proc_entry + const char* name + mode_t mode + struct proc_dir_entry* parent + + + + + This function creates a regular file with the name + name, file mode + mode in the directory + parent. To create a file in the root of + the procfs, use NULL as + parent parameter. When successful, the + function will return a pointer to the freshly created + struct proc_dir_entry; otherwise it + will return NULL. describes how to do something useful with + regular files. + + + + Note that it is specifically supported that you can pass a + path that spans multiple directories. For example + create_proc_entry("drivers/via0/info") + will create the via0 + directory if necessary, with standard + 0755 permissions. + + + + If you only want to be able to read the file, the function + create_proc_read_entry described in may be used to create and initialise + the procfs entry in one single call. + + + + + + + + Creating a symlink + + + + struct proc_dir_entry* + proc_symlink const + char* name + struct proc_dir_entry* + parent const + char* dest + + + + + This creates a symlink in the procfs directory + parent that points from + name to + dest. This translates in userland to + ln -s dest + name. + + + + + Creating a directory + + + + struct proc_dir_entry* proc_mkdir + const char* name + struct proc_dir_entry* parent + + + + + Create a directory name in the procfs + directory parent. + + + + + + + + Removing an entry + + + + void remove_proc_entry + const char* name + struct proc_dir_entry* parent + + + + + Removes the entry name in the directory + parent from the procfs. Entries are + removed by their name, not by the + struct proc_dir_entry returned by the + various create functions. Note that this function doesn't + recursively remove entries. + + + + Be sure to free the data entry from + the struct proc_dir_entry before + remove_proc_entry is called (that is: if + there was some data allocated, of + course). See for more information + on using the data entry. + + + + + + + + + Communicating with userland + + + Instead of reading (or writing) information directly from + kernel memory, procfs works with call back + functions for files: functions that are called when + a specific file is being read or written. Such functions have + to be initialised after the procfs file is created by setting + the read_proc and/or + write_proc fields in the + struct proc_dir_entry* that the + function create_proc_entry returned: + + + +struct proc_dir_entry* entry; + +entry->read_proc = read_proc_foo; +entry->write_proc = write_proc_foo; + + + + If you only want to use a the + read_proc, the function + create_proc_read_entry described in may be used to create and initialise the + procfs entry in one single call. + + + + + + Reading data + + + The read function is a call back function that allows userland + processes to read data from the kernel. The read function + should have the following format: + + + + + int read_func + char* buffer + char** start + off_t off + int count + int* peof + void* data + + + + + The read function should write its information into the + buffer, which will be exactly + PAGE_SIZE bytes long. + + + + The parameter + peof should be used to signal that the + end of the file has been reached by writing + 1 to the memory location + peof points to. + + + + The data + parameter can be used to create a single call back function for + several files, see . + + + + The rest of the parameters and the return value are described + by a comment in fs/proc/generic.c as follows: + + +
+ + You have three ways to return data: + + + + + Leave *start = NULL. (This is the default.) + Put the data of the requested offset at that + offset within the buffer. Return the number (n) + of bytes there are from the beginning of the + buffer up to the last byte of data. If the + number of supplied bytes (= n - offset) is + greater than zero and you didn't signal eof + and the reader is prepared to take more data + you will be called again with the requested + offset advanced by the number of bytes + absorbed. This interface is useful for files + no larger than the buffer. + + + + + Set *start to an unsigned long value less than + the buffer address but greater than zero. + Put the data of the requested offset at the + beginning of the buffer. Return the number of + bytes of data placed there. If this number is + greater than zero and you didn't signal eof + and the reader is prepared to take more data + you will be called again with the requested + offset advanced by *start. This interface is + useful when you have a large file consisting + of a series of blocks which you want to count + and return as wholes. + (Hack by Paul.Russell@rustcorp.com.au) + + + + + Set *start to an address within the buffer. + Put the data of the requested offset at *start. + Return the number of bytes of data placed there. + If this number is greater than zero and you + didn't signal eof and the reader is prepared to + take more data you will be called again with the + requested offset advanced by the number of bytes + absorbed. + + + +
+ + + shows how to use a read call back + function. + + + + + + + + Writing data + + + The write call back function allows a userland process to write + data to the kernel, so it has some kind of control over the + kernel. The write function should have the following format: + + + + + int write_func + struct file* file + const char* buffer + unsigned long count + void* data + + + + + The write function should read count + bytes at maximum from the buffer. Note + that the buffer doesn't live in the + kernel's memory space, so it should first be copied to kernel + space with copy_from_user. The + file parameter is usually + ignored. shows how to use the + data parameter. + + + + Again, shows how to use this call back + function. + + + + + + + + A single call back for many files + + + When a large number of almost identical files is used, it's + quite inconvenient to use a separate call back function for + each file. A better approach is to have a single call back + function that distinguishes between the files by using the + data field in struct + proc_dir_entry. First of all, the + data field has to be initialised: + + + +struct proc_dir_entry* entry; +struct my_file_data *file_data; + +file_data = kmalloc(sizeof(struct my_file_data), GFP_KERNEL); +entry->data = file_data; + + + + The data field is a void + *, so it can be initialised with anything. + + + + Now that the data field is set, the + read_proc and + write_proc can use it to distinguish + between files because they get it passed into their + data parameter: + + + +int foo_read_func(char *page, char **start, off_t off, + int count, int *eof, void *data) +{ + int len; + + if(data == file_data) { + /* special case for this file */ + } else { + /* normal processing */ + } + + return len; +} + + + + Be sure to free the data data field + when removing the procfs entry. + + + + + + + + + Tips and tricks + + + + + + Convenience functions + + + + struct proc_dir_entry* create_proc_read_entry + const char* name + mode_t mode + struct proc_dir_entry* parent + read_proc_t* read_proc + void* data + + + + + This function creates a regular file in exactly the same way + as create_proc_entry from does, but also allows to set the read + function read_proc in one call. This + function can set the data as well, like + explained in . + + + + + + + Modules + + + If procfs is being used from within a module, be sure to set + the owner field in the + struct proc_dir_entry to + THIS_MODULE. + + + +struct proc_dir_entry* entry; + +entry->owner = THIS_MODULE; + + + + + + + + Mode and ownership + + + Sometimes it is useful to change the mode and/or ownership of + a procfs entry. Here is an example that shows how to achieve + that: + + + +struct proc_dir_entry* entry; + +entry->mode = S_IWUSR |S_IRUSR | S_IRGRP | S_IROTH; +entry->uid = 0; +entry->gid = 100; + + + + + + + + + + Example + + + +&procfsexample; + + + diff --git a/trunk/Documentation/DocBook/procfs_example.c b/trunk/Documentation/DocBook/procfs_example.c new file mode 100644 index 000000000000..a5b11793b1e0 --- /dev/null +++ b/trunk/Documentation/DocBook/procfs_example.c @@ -0,0 +1,201 @@ +/* + * procfs_example.c: an example proc interface + * + * Copyright (C) 2001, Erik Mouw (mouw@nl.linux.org) + * + * This file accompanies the procfs-guide in the Linux kernel + * source. Its main use is to demonstrate the concepts and + * functions described in the guide. + * + * This software has been developed while working on the LART + * computing board (http://www.lartmaker.nl), which was sponsored + * by the Delt University of Technology projects Mobile Multi-media + * Communications and Ubiquitous Communications. + * + * 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., 59 Temple Place, + * Suite 330, Boston, MA 02111-1307 USA + * + */ + +#include +#include +#include +#include +#include +#include + + +#define MODULE_VERS "1.0" +#define MODULE_NAME "procfs_example" + +#define FOOBAR_LEN 8 + +struct fb_data_t { + char name[FOOBAR_LEN + 1]; + char value[FOOBAR_LEN + 1]; +}; + + +static struct proc_dir_entry *example_dir, *foo_file, + *bar_file, *jiffies_file, *symlink; + + +struct fb_data_t foo_data, bar_data; + + +static int proc_read_jiffies(char *page, char **start, + off_t off, int count, + int *eof, void *data) +{ + int len; + + len = sprintf(page, "jiffies = %ld\n", + jiffies); + + return len; +} + + +static int proc_read_foobar(char *page, char **start, + off_t off, int count, + int *eof, void *data) +{ + int len; + struct fb_data_t *fb_data = (struct fb_data_t *)data; + + /* DON'T DO THAT - buffer overruns are bad */ + len = sprintf(page, "%s = '%s'\n", + fb_data->name, fb_data->value); + + return len; +} + + +static int proc_write_foobar(struct file *file, + const char *buffer, + unsigned long count, + void *data) +{ + int len; + struct fb_data_t *fb_data = (struct fb_data_t *)data; + + if(count > FOOBAR_LEN) + len = FOOBAR_LEN; + else + len = count; + + if(copy_from_user(fb_data->value, buffer, len)) + return -EFAULT; + + fb_data->value[len] = '\0'; + + return len; +} + + +static int __init init_procfs_example(void) +{ + int rv = 0; + + /* create directory */ + example_dir = proc_mkdir(MODULE_NAME, NULL); + if(example_dir == NULL) { + rv = -ENOMEM; + goto out; + } + /* create jiffies using convenience function */ + jiffies_file = create_proc_read_entry("jiffies", + 0444, example_dir, + proc_read_jiffies, + NULL); + if(jiffies_file == NULL) { + rv = -ENOMEM; + goto no_jiffies; + } + + /* create foo and bar files using same callback + * functions + */ + foo_file = create_proc_entry("foo", 0644, example_dir); + if(foo_file == NULL) { + rv = -ENOMEM; + goto no_foo; + } + + strcpy(foo_data.name, "foo"); + strcpy(foo_data.value, "foo"); + foo_file->data = &foo_data; + foo_file->read_proc = proc_read_foobar; + foo_file->write_proc = proc_write_foobar; + + bar_file = create_proc_entry("bar", 0644, example_dir); + if(bar_file == NULL) { + rv = -ENOMEM; + goto no_bar; + } + + strcpy(bar_data.name, "bar"); + strcpy(bar_data.value, "bar"); + bar_file->data = &bar_data; + bar_file->read_proc = proc_read_foobar; + bar_file->write_proc = proc_write_foobar; + + /* create symlink */ + symlink = proc_symlink("jiffies_too", example_dir, + "jiffies"); + if(symlink == NULL) { + rv = -ENOMEM; + goto no_symlink; + } + + /* everything OK */ + printk(KERN_INFO "%s %s initialised\n", + MODULE_NAME, MODULE_VERS); + return 0; + +no_symlink: + remove_proc_entry("bar", example_dir); +no_bar: + remove_proc_entry("foo", example_dir); +no_foo: + remove_proc_entry("jiffies", example_dir); +no_jiffies: + remove_proc_entry(MODULE_NAME, NULL); +out: + return rv; +} + + +static void __exit cleanup_procfs_example(void) +{ + remove_proc_entry("jiffies_too", example_dir); + remove_proc_entry("bar", example_dir); + remove_proc_entry("foo", example_dir); + remove_proc_entry("jiffies", example_dir); + remove_proc_entry(MODULE_NAME, NULL); + + printk(KERN_INFO "%s %s removed\n", + MODULE_NAME, MODULE_VERS); +} + + +module_init(init_procfs_example); +module_exit(cleanup_procfs_example); + +MODULE_AUTHOR("Erik Mouw"); +MODULE_DESCRIPTION("procfs examples"); +MODULE_LICENSE("GPL"); diff --git a/trunk/Documentation/DocBook/v4l/common.xml b/trunk/Documentation/DocBook/v4l/common.xml index c65f0ac9b6ee..b1a81d246d58 100644 --- a/trunk/Documentation/DocBook/v4l/common.xml +++ b/trunk/Documentation/DocBook/v4l/common.xml @@ -716,41 +716,6 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &std_id)) { } -
- Digital Video (DV) Timings - - The video standards discussed so far has been dealing with Analog TV and the -corresponding video timings. Today there are many more different hardware interfaces -such as High Definition TV interfaces (HDMI), VGA, DVI connectors etc., that carry -video signals and there is a need to extend the API to select the video timings -for these interfaces. Since it is not possible to extend the &v4l2-std-id; due to -the limited bits available, a new set of IOCTLs is added to set/get video timings at -the input and output: - - DV Presets: Digital Video (DV) presets. These are IDs representing a -video timing at the input/output. Presets are pre-defined timings implemented -by the hardware according to video standards. A __u32 data type is used to represent -a preset unlike the bit mask that is used in &v4l2-std-id; allowing future extensions -to support as many different presets as needed. - - - Custom DV Timings: This will allow applications to define more detailed -custom video timings for the interface. This includes parameters such as width, height, -polarities, frontporch, backporch etc. - - - - To enumerate and query the attributes of DV presets supported by a device, -applications use the &VIDIOC-ENUM-DV-PRESETS; ioctl. To get the current DV preset, -applications use the &VIDIOC-G-DV-PRESET; ioctl and to set a preset they use the -&VIDIOC-S-DV-PRESET; ioctl. - To set custom DV timings for the device, applications use the -&VIDIOC-S-DV-TIMINGS; ioctl and to get current custom DV timings they use the -&VIDIOC-G-DV-TIMINGS; ioctl. - Applications can make use of the and - flags to decide what ioctls are available to set the -video timings for the device. -
&sub-controls; diff --git a/trunk/Documentation/DocBook/v4l/compat.xml b/trunk/Documentation/DocBook/v4l/compat.xml index b9dbdf9e6d29..4d1902a54d61 100644 --- a/trunk/Documentation/DocBook/v4l/compat.xml +++ b/trunk/Documentation/DocBook/v4l/compat.xml @@ -2291,8 +2291,8 @@ was renamed to v4l2_chip_ident_old New control V4L2_CID_COLORFX was added. - - + +
V4L2 in Linux 2.6.32 @@ -2322,16 +2322,8 @@ more information. Added Remote Controller chapter, describing the default Remote Controller mapping for media devices. - -
-
- V4L2 in Linux 2.6.33 - - - Added support for Digital Video timings in order to support HDTV receivers and transmitters. - - -
+ +
diff --git a/trunk/Documentation/DocBook/v4l/v4l2.xml b/trunk/Documentation/DocBook/v4l/v4l2.xml index 060105af49e5..937b4157a5d0 100644 --- a/trunk/Documentation/DocBook/v4l/v4l2.xml +++ b/trunk/Documentation/DocBook/v4l/v4l2.xml @@ -74,17 +74,6 @@ Remote Controller chapter. - - - Muralidharan - Karicheri - Documented the Digital Video timings API. - -
- m-karicheri2@ti.com -
- - @@ -100,7 +89,7 @@ Remote Controller chapter. 2008 2009 Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin -Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab +Rubli, Andy Walls, Mauro Carvalho Chehab Except when explicitly stated as GPL, programming examples within @@ -113,13 +102,6 @@ structs, ioctls) must be noted in more detail in the history chapter (compat.sgml), along with the possible impact on existing drivers and applications. --> - - 2.6.33 - 2009-12-03 - mk - Added documentation for the Digital Video timings API. - - 2.6.32 2009-08-31 @@ -373,7 +355,7 @@ and discussions on the V4L mailing list. Video for Linux Two API Specification - Revision 2.6.33 + Revision 2.6.32 &sub-common; @@ -429,7 +411,6 @@ and discussions on the V4L mailing list. &sub-encoder-cmd; &sub-enumaudio; &sub-enumaudioout; - &sub-enum-dv-presets; &sub-enum-fmt; &sub-enum-framesizes; &sub-enum-frameintervals; @@ -440,8 +421,6 @@ and discussions on the V4L mailing list. &sub-g-audioout; &sub-g-crop; &sub-g-ctrl; - &sub-g-dv-preset; - &sub-g-dv-timings; &sub-g-enc-index; &sub-g-ext-ctrls; &sub-g-fbuf; @@ -462,7 +441,6 @@ and discussions on the V4L mailing list. &sub-querybuf; &sub-querycap; &sub-queryctrl; - &sub-query-dv-preset; &sub-querystd; &sub-reqbufs; &sub-s-hw-freq-seek; diff --git a/trunk/Documentation/DocBook/v4l/videodev2.h.xml b/trunk/Documentation/DocBook/v4l/videodev2.h.xml index 068325940658..3e282ed9f593 100644 --- a/trunk/Documentation/DocBook/v4l/videodev2.h.xml +++ b/trunk/Documentation/DocBook/v4l/videodev2.h.xml @@ -733,99 +733,6 @@ struct v4l2_standard { __u32 reserved[4]; }; -/* - * V I D E O T I M I N G S D V P R E S E T - */ -struct v4l2_dv_preset { - __u32 preset; - __u32 reserved[4]; -}; - -/* - * D V P R E S E T S E N U M E R A T I O N - */ -struct v4l2_dv_enum_preset { - __u32 index; - __u32 preset; - __u8 name[32]; /* Name of the preset timing */ - __u32 width; - __u32 height; - __u32 reserved[4]; -}; - -/* - * D V P R E S E T V A L U E S - */ -#define V4L2_DV_INVALID 0 -#define V4L2_DV_480P59_94 1 /* BT.1362 */ -#define V4L2_DV_576P50 2 /* BT.1362 */ -#define V4L2_DV_720P24 3 /* SMPTE 296M */ -#define V4L2_DV_720P25 4 /* SMPTE 296M */ -#define V4L2_DV_720P30 5 /* SMPTE 296M */ -#define V4L2_DV_720P50 6 /* SMPTE 296M */ -#define V4L2_DV_720P59_94 7 /* SMPTE 274M */ -#define V4L2_DV_720P60 8 /* SMPTE 274M/296M */ -#define V4L2_DV_1080I29_97 9 /* BT.1120/ SMPTE 274M */ -#define V4L2_DV_1080I30 10 /* BT.1120/ SMPTE 274M */ -#define V4L2_DV_1080I25 11 /* BT.1120 */ -#define V4L2_DV_1080I50 12 /* SMPTE 296M */ -#define V4L2_DV_1080I60 13 /* SMPTE 296M */ -#define V4L2_DV_1080P24 14 /* SMPTE 296M */ -#define V4L2_DV_1080P25 15 /* SMPTE 296M */ -#define V4L2_DV_1080P30 16 /* SMPTE 296M */ -#define V4L2_DV_1080P50 17 /* BT.1120 */ -#define V4L2_DV_1080P60 18 /* BT.1120 */ - -/* - * D V B T T I M I N G S - */ - -/* BT.656/BT.1120 timing data */ -struct v4l2_bt_timings { - __u32 width; /* width in pixels */ - __u32 height; /* height in lines */ - __u32 interlaced; /* Interlaced or progressive */ - __u32 polarities; /* Positive or negative polarity */ - __u64 pixelclock; /* Pixel clock in HZ. Ex. 74.25MHz->74250000 */ - __u32 hfrontporch; /* Horizpontal front porch in pixels */ - __u32 hsync; /* Horizontal Sync length in pixels */ - __u32 hbackporch; /* Horizontal back porch in pixels */ - __u32 vfrontporch; /* Vertical front porch in pixels */ - __u32 vsync; /* Vertical Sync length in lines */ - __u32 vbackporch; /* Vertical back porch in lines */ - __u32 il_vfrontporch; /* Vertical front porch for bottom field of - * interlaced field formats - */ - __u32 il_vsync; /* Vertical sync length for bottom field of - * interlaced field formats - */ - __u32 il_vbackporch; /* Vertical back porch for bottom field of - * interlaced field formats - */ - __u32 reserved[16]; -} __attribute__ ((packed)); - -/* Interlaced or progressive format */ -#define V4L2_DV_PROGRESSIVE 0 -#define V4L2_DV_INTERLACED 1 - -/* Polarities. If bit is not set, it is assumed to be negative polarity */ -#define V4L2_DV_VSYNC_POS_POL 0x00000001 -#define V4L2_DV_HSYNC_POS_POL 0x00000002 - - -/* DV timings */ -struct v4l2_dv_timings { - __u32 type; - union { - struct v4l2_bt_timings bt; - __u32 reserved[32]; - }; -} __attribute__ ((packed)); - -/* Values for the type field */ -#define V4L2_DV_BT_656_1120 0 /* BT.656/1120 timing type */ - /* * V I D E O I N P U T S */ @@ -837,8 +744,7 @@ struct v4l2_input { __u32 tuner; /* Associated tuner */ v4l2_std_id std; __u32 status; - __u32 capabilities; - __u32 reserved[3]; + __u32 reserved[4]; }; /* Values for the 'type' field */ @@ -869,11 +775,6 @@ struct v4l2_input { #define V4L2_IN_ST_NO_ACCESS 0x02000000 /* Conditional access denied */ #define V4L2_IN_ST_VTR 0x04000000 /* VTR time constant */ -/* capabilities flags */ -#define V4L2_IN_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ -#define V4L2_IN_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ -#define V4L2_IN_CAP_STD 0x00000004 /* Supports S_STD */ - /* * V I D E O O U T P U T S */ @@ -884,19 +785,13 @@ struct v4l2_output { __u32 audioset; /* Associated audios (bitfield) */ __u32 modulator; /* Associated modulator */ v4l2_std_id std; - __u32 capabilities; - __u32 reserved[3]; + __u32 reserved[4]; }; /* Values for the 'type' field */ #define V4L2_OUTPUT_TYPE_MODULATOR 1 #define V4L2_OUTPUT_TYPE_ANALOG 2 #define V4L2_OUTPUT_TYPE_ANALOGVGAOVERLAY 3 -/* capabilities flags */ -#define V4L2_OUT_CAP_PRESETS 0x00000001 /* Supports S_DV_PRESET */ -#define V4L2_OUT_CAP_CUSTOM_TIMINGS 0x00000002 /* Supports S_DV_TIMINGS */ -#define V4L2_OUT_CAP_STD 0x00000004 /* Supports S_STD */ - /* * C O N T R O L S */ @@ -1731,13 +1626,6 @@ struct v4l2_dbg_chip_ident { #endif #define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct v4l2_hw_freq_seek) -#define VIDIOC_ENUM_DV_PRESETS _IOWR('V', 83, struct v4l2_dv_enum_preset) -#define VIDIOC_S_DV_PRESET _IOWR('V', 84, struct v4l2_dv_preset) -#define VIDIOC_G_DV_PRESET _IOWR('V', 85, struct v4l2_dv_preset) -#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct v4l2_dv_preset) -#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct v4l2_dv_timings) -#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct v4l2_dv_timings) - /* Reminder: when adding new ioctls please add support for them to drivers/media/video/v4l2-compat-ioctl32.c as well! */ diff --git a/trunk/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml b/trunk/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml deleted file mode 100644 index 1d31427edd1b..000000000000 --- a/trunk/Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml +++ /dev/null @@ -1,238 +0,0 @@ - - - ioctl VIDIOC_ENUM_DV_PRESETS - &manvol; - - - - VIDIOC_ENUM_DV_PRESETS - Enumerate supported Digital Video presets - - - - - - int ioctl - int fd - int request - struct v4l2_dv_enum_preset *argp - - - - - - Arguments - - - - fd - - &fd; - - - - request - - VIDIOC_ENUM_DV_PRESETS - - - - argp - - - - - - - - - Description - - To query the attributes of a DV preset, applications initialize the -index field and zero the reserved array of &v4l2-dv-enum-preset; -and call the VIDIOC_ENUM_DV_PRESETS ioctl with a pointer to this -structure. Drivers fill the rest of the structure or return an -&EINVAL; when the index is out of bounds. To enumerate all DV Presets supported, -applications shall begin at index zero, incrementing by one until the -driver returns EINVAL. Drivers may enumerate a -different set of DV presets after switching the video input or -output. - - - struct <structname>v4l2_dv_enum_presets</structname> - - &cs-str; - - - __u32 - index - Number of the DV preset, set by the -application. - - - __u32 - preset - This field identifies one of the DV preset values listed in . - - - __u8 - name[24] - Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is -intended for the user. - - - __u32 - width - Width of the active video in pixels for the DV preset. - - - __u32 - height - Height of the active video in lines for the DV preset. - - - __u32 - reserved[4] - Reserved for future extensions. Drivers must set the array to zero. - - - -
- - - struct <structname>DV Presets</structname> - - &cs-str; - - - Preset - Preset value - Description - - - - - - - - V4L2_DV_INVALID - 0 - Invalid preset value. - - - V4L2_DV_480P59_94 - 1 - 720x480 progressive video at 59.94 fps as per BT.1362. - - - V4L2_DV_576P50 - 2 - 720x576 progressive video at 50 fps as per BT.1362. - - - V4L2_DV_720P24 - 3 - 1280x720 progressive video at 24 fps as per SMPTE 296M. - - - V4L2_DV_720P25 - 4 - 1280x720 progressive video at 25 fps as per SMPTE 296M. - - - V4L2_DV_720P30 - 5 - 1280x720 progressive video at 30 fps as per SMPTE 296M. - - - V4L2_DV_720P50 - 6 - 1280x720 progressive video at 50 fps as per SMPTE 296M. - - - V4L2_DV_720P59_94 - 7 - 1280x720 progressive video at 59.94 fps as per SMPTE 274M. - - - V4L2_DV_720P60 - 8 - 1280x720 progressive video at 60 fps as per SMPTE 274M/296M. - - - V4L2_DV_1080I29_97 - 9 - 1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M. - - - V4L2_DV_1080I30 - 10 - 1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M. - - - V4L2_DV_1080I25 - 11 - 1920x1080 interlaced video at 25 fps as per BT.1120. - - - V4L2_DV_1080I50 - 12 - 1920x1080 interlaced video at 50 fps as per SMPTE 296M. - - - V4L2_DV_1080I60 - 13 - 1920x1080 interlaced video at 60 fps as per SMPTE 296M. - - - V4L2_DV_1080P24 - 14 - 1920x1080 progressive video at 24 fps as per SMPTE 296M. - - - V4L2_DV_1080P25 - 15 - 1920x1080 progressive video at 25 fps as per SMPTE 296M. - - - V4L2_DV_1080P30 - 16 - 1920x1080 progressive video at 30 fps as per SMPTE 296M. - - - V4L2_DV_1080P50 - 17 - 1920x1080 progressive video at 50 fps as per BT.1120. - - - V4L2_DV_1080P60 - 18 - 1920x1080 progressive video at 60 fps as per BT.1120. - - - -
- - - - &return-value; - - - - EINVAL - - The &v4l2-dv-enum-preset; index -is out of bounds. - - - - - - - diff --git a/trunk/Documentation/DocBook/v4l/vidioc-enuminput.xml b/trunk/Documentation/DocBook/v4l/vidioc-enuminput.xml index 71b868e2fb8f..414856b82473 100644 --- a/trunk/Documentation/DocBook/v4l/vidioc-enuminput.xml +++ b/trunk/Documentation/DocBook/v4l/vidioc-enuminput.xml @@ -124,13 +124,7 @@ current input. __u32 - capabilities - This field provides capabilities for the -input. See for flags. - - - __u32 - reserved[3] + reserved[4] Reserved for future extensions. Drivers must set the array to zero. @@ -267,34 +261,6 @@ flag is set Macrovision has been detected. - - - - Input capabilities - - &cs-def; - - - V4L2_IN_CAP_PRESETS - 0x00000001 - This input supports setting DV presets by using VIDIOC_S_DV_PRESET. - - - V4L2_OUT_CAP_CUSTOM_TIMINGS - 0x00000002 - This input supports setting custom video timings by using VIDIOC_S_DV_TIMINGS. - - - V4L2_IN_CAP_STD - 0x00000004 - This input supports setting the TV standard by using VIDIOC_S_STD. - - - -
diff --git a/trunk/Documentation/DocBook/v4l/vidioc-enumoutput.xml b/trunk/Documentation/DocBook/v4l/vidioc-enumoutput.xml index a281d26a195f..e8d16dcd50cf 100644 --- a/trunk/Documentation/DocBook/v4l/vidioc-enumoutput.xml +++ b/trunk/Documentation/DocBook/v4l/vidioc-enumoutput.xml @@ -114,13 +114,7 @@ details on video standards and how to switch see __u32 - capabilities - This field provides capabilities for the -output. See for flags. - - - __u32 - reserved[3] + reserved[4] Reserved for future extensions. Drivers must set the array to zero. @@ -153,34 +147,6 @@ CVBS, S-Video, RGB. - - - Output capabilities - - &cs-def; - - - V4L2_OUT_CAP_PRESETS - 0x00000001 - This output supports setting DV presets by using VIDIOC_S_DV_PRESET. - - - V4L2_OUT_CAP_CUSTOM_TIMINGS - 0x00000002 - This output supports setting custom video timings by using VIDIOC_S_DV_TIMINGS. - - - V4L2_OUT_CAP_STD - 0x00000004 - This output supports setting the TV standard by using VIDIOC_S_STD. - - - -
- &return-value; diff --git a/trunk/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml b/trunk/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml deleted file mode 100644 index 3c6784e132f3..000000000000 --- a/trunk/Documentation/DocBook/v4l/vidioc-g-dv-preset.xml +++ /dev/null @@ -1,111 +0,0 @@ - - - ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET - &manvol; - - - - VIDIOC_G_DV_PRESET - VIDIOC_S_DV_PRESET - Query or select the DV preset of the current input or output - - - - - - int ioctl - int fd - int request - &v4l2-dv-preset; -*argp - - - - - - Arguments - - - - fd - - &fd; - - - - request - - VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET - - - - argp - - - - - - - - - Description - To query and select the current DV preset, applications -use the VIDIOC_G_DV_PRESET and VIDIOC_S_DV_PRESET -ioctls which take a pointer to a &v4l2-dv-preset; type as argument. -Applications must zero the reserved array in &v4l2-dv-preset;. -VIDIOC_G_DV_PRESET returns a dv preset in the field -preset of &v4l2-dv-preset;. - - VIDIOC_S_DV_PRESET accepts a pointer to a &v4l2-dv-preset; -that has the preset value to be set. Applications must zero the reserved array in &v4l2-dv-preset;. -If the preset is not supported, it returns an &EINVAL; - - - - &return-value; - - - - EINVAL - - This ioctl is not supported, or the -VIDIOC_S_DV_PRESET,VIDIOC_S_DV_PRESET parameter was unsuitable. - - - - EBUSY - - The device is busy and therefore can not change the preset. - - - - - - struct <structname>v4l2_dv_preset</structname> - - &cs-str; - - - __u32 - preset - Preset value to represent the digital video timings - - - __u32 - reserved[4] - Reserved fields for future use - - - -
- - - - - diff --git a/trunk/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml b/trunk/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml deleted file mode 100644 index ecc19576bb8f..000000000000 --- a/trunk/Documentation/DocBook/v4l/vidioc-g-dv-timings.xml +++ /dev/null @@ -1,224 +0,0 @@ - - - ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS - &manvol; - - - - VIDIOC_G_DV_TIMINGS - VIDIOC_S_DV_TIMINGS - Get or set custom DV timings for input or output - - - - - - int ioctl - int fd - int request - &v4l2-dv-timings; -*argp - - - - - - Arguments - - - - fd - - &fd; - - - - request - - VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS - - - - argp - - - - - - - - - Description - To set custom DV timings for the input or output, applications use the -VIDIOC_S_DV_TIMINGS ioctl and to get the current custom timings, -applications use the VIDIOC_G_DV_TIMINGS ioctl. The detailed timing -information is filled in using the structure &v4l2-dv-timings;. These ioctls take -a pointer to the &v4l2-dv-timings; structure as argument. If the ioctl is not supported -or the timing values are not correct, the driver returns &EINVAL;. - - - - &return-value; - - - - EINVAL - - This ioctl is not supported, or the -VIDIOC_S_DV_TIMINGS parameter was unsuitable. - - - - EBUSY - - The device is busy and therefore can not change the timings. - - - - - - struct <structname>v4l2_bt_timings</structname> - - &cs-str; - - - __u32 - width - Width of the active video in pixels - - - __u32 - height - Height of the active video in lines - - - __u32 - interlaced - Progressive (0) or interlaced (1) - - - __u32 - polarities - This is a bit mask that defines polarities of sync signals. -bit 0 (V4L2_DV_VSYNC_POS_POL) is for vertical sync polarity and bit 1 (V4L2_DV_HSYNC_POS_POL) is for horizontal sync polarity. If the bit is set -(1) it is positive polarity and if is cleared (0), it is negative polarity. - - - __u64 - pixelclock - Pixel clock in Hz. Ex. 74.25MHz->74250000 - - - __u32 - hfrontporch - Horizontal front porch in pixels - - - __u32 - hsync - Horizontal sync length in pixels - - - __u32 - hbackporch - Horizontal back porch in pixels - - - __u32 - vfrontporch - Vertical front porch in lines - - - __u32 - vsync - Vertical sync length in lines - - - __u32 - vbackporch - Vertical back porch in lines - - - __u32 - il_vfrontporch - Vertical front porch in lines for bottom field of interlaced field formats - - - __u32 - il_vsync - Vertical sync length in lines for bottom field of interlaced field formats - - - __u32 - il_vbackporch - Vertical back porch in lines for bottom field of interlaced field formats - - - -
- - - struct <structname>v4l2_dv_timings</structname> - - &cs-str; - - - __u32 - type - - Type of DV timings as listed in . - - - union - - - - - - &v4l2-bt-timings; - bt - Timings defined by BT.656/1120 specifications - - - - __u32 - reserved[32] - - - - -
- - - DV Timing types - - &cs-str; - - - Timing type - value - Description - - - - - - - - V4L2_DV_BT_656_1120 - 0 - BT.656/1120 timings - - - -
- - - - diff --git a/trunk/Documentation/DocBook/v4l/vidioc-g-std.xml b/trunk/Documentation/DocBook/v4l/vidioc-g-std.xml index 912f8513e5da..b6f5d267e856 100644 --- a/trunk/Documentation/DocBook/v4l/vidioc-g-std.xml +++ b/trunk/Documentation/DocBook/v4l/vidioc-g-std.xml @@ -86,12 +86,6 @@ standards. VIDIOC_S_STD parameter was unsuitable. - - EBUSY - - The device is busy and therefore can not change the standard - - diff --git a/trunk/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml b/trunk/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml deleted file mode 100644 index 87e4f0f6151c..000000000000 --- a/trunk/Documentation/DocBook/v4l/vidioc-query-dv-preset.xml +++ /dev/null @@ -1,85 +0,0 @@ - - - ioctl VIDIOC_QUERY_DV_PRESET - &manvol; - - - - VIDIOC_QUERY_DV_PRESET - Sense the DV preset received by the current -input - - - - - - int ioctl - int fd - int request - &v4l2-dv-preset; *argp - - - - - - Arguments - - - - fd - - &fd; - - - - request - - VIDIOC_QUERY_DV_PRESET - - - - argp - - - - - - - - - Description - - The hardware may be able to detect the current DV preset -automatically, similar to sensing the video standard. To do so, applications -call VIDIOC_QUERY_DV_PRESET with a pointer to a -&v4l2-dv-preset; type. Once the hardware detects a preset, that preset is -returned in the preset field of &v4l2-dv-preset;. When detection is not -possible or fails, the value V4L2_DV_INVALID is returned. - - - - &return-value; - - - EINVAL - - This ioctl is not supported. - - - - EBUSY - - The device is busy and therefore can not sense the preset - - - - - - - diff --git a/trunk/Documentation/DocBook/v4l/vidioc-querystd.xml b/trunk/Documentation/DocBook/v4l/vidioc-querystd.xml index 1a9e60393091..b5a7ff934486 100644 --- a/trunk/Documentation/DocBook/v4l/vidioc-querystd.xml +++ b/trunk/Documentation/DocBook/v4l/vidioc-querystd.xml @@ -70,12 +70,6 @@ current video input or output. This ioctl is not supported. - - EBUSY - - The device is busy and therefore can not detect the standard - - diff --git a/trunk/Documentation/IO-mapping.txt b/trunk/Documentation/IO-mapping.txt index 1b5aa10df845..78a440695e11 100644 --- a/trunk/Documentation/IO-mapping.txt +++ b/trunk/Documentation/IO-mapping.txt @@ -157,7 +157,7 @@ For such memory, you can do things like * access only the 640k-1MB area, so anything else * has to be remapped. */ - void __iomem *baseptr = ioremap(0xFC000000, 1024*1024); + char * baseptr = ioremap(0xFC000000, 1024*1024); /* write a 'A' to the offset 10 of the area */ writeb('A',baseptr+10); diff --git a/trunk/Documentation/SubmitChecklist b/trunk/Documentation/SubmitChecklist index 1053a56be3b1..78a9168ff377 100644 --- a/trunk/Documentation/SubmitChecklist +++ b/trunk/Documentation/SubmitChecklist @@ -15,7 +15,7 @@ kernel patches. 2: Passes allnoconfig, allmodconfig 3: Builds on multiple CPU architectures by using local cross-compile tools - or some other build farm. + or something like PLM at OSDL. 4: ppc64 is a good architecture for cross-compilation checking because it tends to use `unsigned long' for 64-bit quantities. @@ -88,6 +88,3 @@ kernel patches. 24: All memory barriers {e.g., barrier(), rmb(), wmb()} need a comment in the source code that explains the logic of what they are doing and why. - -25: If any ioctl's are added by the patch, then also update - Documentation/ioctl/ioctl-number.txt. diff --git a/trunk/Documentation/acpi/method-customizing.txt b/trunk/Documentation/acpi/method-customizing.txt deleted file mode 100644 index e628cd23ca80..000000000000 --- a/trunk/Documentation/acpi/method-customizing.txt +++ /dev/null @@ -1,66 +0,0 @@ -Linux ACPI Custom Control Method How To -======================================= - -Written by Zhang Rui - - -Linux supports customizing ACPI control methods at runtime. - -Users can use this to -1. override an existing method which may not work correctly, - or just for debugging purposes. -2. insert a completely new method in order to create a missing - method such as _OFF, _ON, _STA, _INI, etc. -For these cases, it is far simpler to dynamically install a single -control method rather than override the entire DSDT, because kernel -rebuild/reboot is not needed and test result can be got in minutes. - -Note: Only ACPI METHOD can be overridden, any other object types like - "Device", "OperationRegion", are not recognized. -Note: The same ACPI control method can be overridden for many times, - and it's always the latest one that used by Linux/kernel. - -1. override an existing method - a) get the ACPI table via ACPI sysfs I/F. e.g. to get the DSDT, - just run "cat /sys/firmware/acpi/tables/DSDT > /tmp/dsdt.dat" - b) disassemble the table by running "iasl -d dsdt.dat". - c) rewrite the ASL code of the method and save it in a new file, - d) package the new file (psr.asl) to an ACPI table format. - Here is an example of a customized \_SB._AC._PSR method, - - DefinitionBlock ("", "SSDT", 1, "", "", 0x20080715) - { - External (ACON) - - Method (\_SB_.AC._PSR, 0, NotSerialized) - { - Store ("In AC _PSR", Debug) - Return (ACON) - } - } - Note that the full pathname of the method in ACPI namespace - should be used. - And remember to use "External" to declare external objects. - e) assemble the file to generate the AML code of the method. - e.g. "iasl psr.asl" (psr.aml is generated as a result) - f) mount debugfs by "mount -t debugfs none /sys/kernel/debug" - g) override the old method via the debugfs by running - "cat /tmp/psr.aml > /sys/kernel/debug/acpi/custom_method" - -2. insert a new method - This is easier than overriding an existing method. - We just need to create the ASL code of the method we want to - insert and then follow the step c) ~ g) in section 1. - -3. undo your changes - The "undo" operation is not supported for a new inserted method - right now, i.e. we can not remove a method currently. - For an overrided method, in order to undo your changes, please - save a copy of the method original ASL code in step c) section 1, - and redo step c) ~ g) to override the method with the original one. - - -Note: We can use a kernel with multiple custom ACPI method running, - But each individual write to debugfs can implement a SINGLE - method override. i.e. if we want to insert/override multiple - ACPI methods, we need to redo step c) ~ g) for multiple times. diff --git a/trunk/Documentation/blackfin/00-INDEX b/trunk/Documentation/blackfin/00-INDEX index c34e12440fec..d6840a91e1e1 100644 --- a/trunk/Documentation/blackfin/00-INDEX +++ b/trunk/Documentation/blackfin/00-INDEX @@ -1,6 +1,9 @@ 00-INDEX - This file +cache-lock.txt + - HOWTO for blackfin cache locking. + cachefeatures.txt - Supported cache features. diff --git a/trunk/Documentation/blackfin/Makefile b/trunk/Documentation/blackfin/Makefile deleted file mode 100644 index 773dbb103f1c..000000000000 --- a/trunk/Documentation/blackfin/Makefile +++ /dev/null @@ -1,6 +0,0 @@ -obj-m := gptimers-example.o - -all: modules - -modules clean: - $(MAKE) -C ../.. SUBDIRS=$(PWD) $@ diff --git a/trunk/Documentation/blackfin/cache-lock.txt b/trunk/Documentation/blackfin/cache-lock.txt new file mode 100644 index 000000000000..88ba1e6c31c3 --- /dev/null +++ b/trunk/Documentation/blackfin/cache-lock.txt @@ -0,0 +1,48 @@ +/* + * File: Documentation/blackfin/cache-lock.txt + * Based on: + * Author: + * + * Created: + * Description: This file contains the simple DMA Implementation for Blackfin + * + * Rev: $Id: cache-lock.txt 2384 2006-11-01 04:12:43Z magicyang $ + * + * Modified: + * Copyright 2004-2006 Analog Devices Inc. + * + * Bugs: Enter bugs at http://blackfin.uclinux.org/ + * + */ + +How to lock your code in cache in uClinux/blackfin +-------------------------------------------------- + +There are only a few steps required to lock your code into the cache. +Currently you can lock the code by Way. + +Below are the interface provided for locking the cache. + + +1. cache_grab_lock(int Ways); + +This function grab the lock for locking your code into the cache specified +by Ways. + + +2. cache_lock(int Ways); + +This function should be called after your critical code has been executed. +Once the critical code exits, the code is now loaded into the cache. This +function locks the code into the cache. + + +So, the example sequence will be: + + cache_grab_lock(WAY0_L); /* Grab the lock */ + + critical_code(); /* Execute the code of interest */ + + cache_lock(WAY0_L); /* Lock the cache */ + +Where WAY0_L signifies WAY0 locking. diff --git a/trunk/Documentation/blackfin/cachefeatures.txt b/trunk/Documentation/blackfin/cachefeatures.txt index 75de51f94515..0fbec23becb5 100644 --- a/trunk/Documentation/blackfin/cachefeatures.txt +++ b/trunk/Documentation/blackfin/cachefeatures.txt @@ -41,6 +41,16 @@ icplb_flush(); dcplb_flush(); + - Locking the cache. + + cache_grab_lock(); + cache_lock(); + + Please refer linux-2.6.x/Documentation/blackfin/cache-lock.txt for how to + lock the cache. + + Locking the cache is optional feature. + - Miscellaneous cache functions. flush_cache_all(); diff --git a/trunk/Documentation/blackfin/gptimers-example.c b/trunk/Documentation/blackfin/gptimers-example.c deleted file mode 100644 index b1bd6340e748..000000000000 --- a/trunk/Documentation/blackfin/gptimers-example.c +++ /dev/null @@ -1,83 +0,0 @@ -/* - * Simple gptimers example - * http://docs.blackfin.uclinux.org/doku.php?id=linux-kernel:drivers:gptimers - * - * Copyright 2007-2009 Analog Devices Inc. - * - * Licensed under the GPL-2 or later. - */ - -#include -#include - -#include -#include - -/* ... random driver includes ... */ - -#define DRIVER_NAME "gptimer_example" - -struct gptimer_data { - uint32_t period, width; -}; -static struct gptimer_data data; - -/* ... random driver state ... */ - -static irqreturn_t gptimer_example_irq(int irq, void *dev_id) -{ - struct gptimer_data *data = dev_id; - - /* make sure it was our timer which caused the interrupt */ - if (!get_gptimer_intr(TIMER5_id)) - return IRQ_NONE; - - /* read the width/period values that were captured for the waveform */ - data->width = get_gptimer_pwidth(TIMER5_id); - data->period = get_gptimer_period(TIMER5_id); - - /* acknowledge the interrupt */ - clear_gptimer_intr(TIMER5_id); - - /* tell the upper layers we took care of things */ - return IRQ_HANDLED; -} - -/* ... random driver code ... */ - -static int __init gptimer_example_init(void) -{ - int ret; - - /* grab the peripheral pins */ - ret = peripheral_request(P_TMR5, DRIVER_NAME); - if (ret) { - printk(KERN_NOTICE DRIVER_NAME ": peripheral request failed\n"); - return ret; - } - - /* grab the IRQ for the timer */ - ret = request_irq(IRQ_TIMER5, gptimer_example_irq, IRQF_SHARED, DRIVER_NAME, &data); - if (ret) { - printk(KERN_NOTICE DRIVER_NAME ": IRQ request failed\n"); - peripheral_free(P_TMR5); - return ret; - } - - /* setup the timer and enable it */ - set_gptimer_config(TIMER5_id, WDTH_CAP | PULSE_HI | PERIOD_CNT | IRQ_ENA); - enable_gptimers(TIMER5bit); - - return 0; -} -module_init(gptimer_example_init); - -static void __exit gptimer_example_exit(void) -{ - disable_gptimers(TIMER5bit); - free_irq(IRQ_TIMER5, &data); - peripheral_free(P_TMR5); -} -module_exit(gptimer_example_exit); - -MODULE_LICENSE("BSD"); diff --git a/trunk/Documentation/block/00-INDEX b/trunk/Documentation/block/00-INDEX index a406286f6f3e..961a0513f8c3 100644 --- a/trunk/Documentation/block/00-INDEX +++ b/trunk/Documentation/block/00-INDEX @@ -1,5 +1,7 @@ 00-INDEX - This file +as-iosched.txt + - Anticipatory IO scheduler barrier.txt - I/O Barriers biodoc.txt diff --git a/trunk/Documentation/block/as-iosched.txt b/trunk/Documentation/block/as-iosched.txt new file mode 100644 index 000000000000..738b72be128e --- /dev/null +++ b/trunk/Documentation/block/as-iosched.txt @@ -0,0 +1,172 @@ +Anticipatory IO scheduler +------------------------- +Nick Piggin 13 Sep 2003 + +Attention! Database servers, especially those using "TCQ" disks should +investigate performance with the 'deadline' IO scheduler. Any system with high +disk performance requirements should do so, in fact. + +If you see unusual performance characteristics of your disk systems, or you +see big performance regressions versus the deadline scheduler, please email +me. Database users don't bother unless you're willing to test a lot of patches +from me ;) its a known issue. + +Also, users with hardware RAID controllers, doing striping, may find +highly variable performance results with using the as-iosched. The +as-iosched anticipatory implementation is based on the notion that a disk +device has only one physical seeking head. A striped RAID controller +actually has a head for each physical device in the logical RAID device. + +However, setting the antic_expire (see tunable parameters below) produces +very similar behavior to the deadline IO scheduler. + +Selecting IO schedulers +----------------------- +Refer to Documentation/block/switching-sched.txt for information on +selecting an io scheduler on a per-device basis. + +Anticipatory IO scheduler Policies +---------------------------------- +The as-iosched implementation implements several layers of policies +to determine when an IO request is dispatched to the disk controller. +Here are the policies outlined, in order of application. + +1. one-way Elevator algorithm. + +The elevator algorithm is similar to that used in deadline scheduler, with +the addition that it allows limited backward movement of the elevator +(i.e. seeks backwards). A seek backwards can occur when choosing between +two IO requests where one is behind the elevator's current position, and +the other is in front of the elevator's position. If the seek distance to +the request in back of the elevator is less than half the seek distance to +the request in front of the elevator, then the request in back can be chosen. +Backward seeks are also limited to a maximum of MAXBACK (1024*1024) sectors. +This favors forward movement of the elevator, while allowing opportunistic +"short" backward seeks. + +2. FIFO expiration times for reads and for writes. + +This is again very similar to the deadline IO scheduler. The expiration +times for requests on these lists is tunable using the parameters read_expire +and write_expire discussed below. When a read or a write expires in this way, +the IO scheduler will interrupt its current elevator sweep or read anticipation +to service the expired request. + +3. Read and write request batching + +A batch is a collection of read requests or a collection of write +requests. The as scheduler alternates dispatching read and write batches +to the driver. In the case a read batch, the scheduler submits read +requests to the driver as long as there are read requests to submit, and +the read batch time limit has not been exceeded (read_batch_expire). +The read batch time limit begins counting down only when there are +competing write requests pending. + +In the case of a write batch, the scheduler submits write requests to +the driver as long as there are write requests available, and the +write batch time limit has not been exceeded (write_batch_expire). +However, the length of write batches will be gradually shortened +when read batches frequently exceed their time limit. + +When changing between batch types, the scheduler waits for all requests +from the previous batch to complete before scheduling requests for the +next batch. + +The read and write fifo expiration times described in policy 2 above +are checked only when in scheduling IO of a batch for the corresponding +(read/write) type. So for example, the read FIFO timeout values are +tested only during read batches. Likewise, the write FIFO timeout +values are tested only during write batches. For this reason, +it is generally not recommended for the read batch time +to be longer than the write expiration time, nor for the write batch +time to exceed the read expiration time (see tunable parameters below). + +When the IO scheduler changes from a read to a write batch, +it begins the elevator from the request that is on the head of the +write expiration FIFO. Likewise, when changing from a write batch to +a read batch, scheduler begins the elevator from the first entry +on the read expiration FIFO. + +4. Read anticipation. + +Read anticipation occurs only when scheduling a read batch. +This implementation of read anticipation allows only one read request +to be dispatched to the disk controller at a time. In +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 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. +At the end of each read request, the IO scheduler examines its next +candidate read request from its sorted read list. If that next request +is from the same process as the request that just completed, +or if the next request in the queue is "very close" to the +just completed request, it is dispatched immediately. Otherwise, +statistics (average think time, average seek distance) on the process +that submitted the just completed request are examined. If it seems +likely that that process will submit another request soon, and that +request is likely to be near the just completed request, then the IO +scheduler will stop dispatching more read requests for up to (antic_expire) +milliseconds, hoping that process will submit a new request near the one +that just completed. If such a request is made, then it is dispatched +immediately. If the antic_expire wait time expires, then the IO scheduler +will dispatch the next read request from the sorted read queue. + +To decide whether an anticipatory wait is worthwhile, the scheduler +maintains statistics for each process that can be used to compute +mean "think time" (the time between read requests), and mean seek +distance for that process. One observation is that these statistics +are associated with each process, but those statistics are not associated +with a specific IO device. So for example, if a process is doing IO +on several file systems on separate devices, the statistics will be +a combination of IO behavior from all those devices. + + +Tuning the anticipatory IO scheduler +------------------------------------ +When using 'as', the anticipatory IO scheduler there are 5 parameters under +/sys/block/*/queue/iosched/. All are units of milliseconds. + +The parameters are: +* read_expire + Controls how long until a read request becomes "expired". It also controls the + interval between which expired requests are served, so set to 50, a request + might take anywhere < 100ms to be serviced _if_ it is the next on the + expired list. Obviously request expiration strategies won't make the disk + go faster. The result basically equates to the timeslice a single reader + gets in the presence of other IO. 100*((seek time / read_expire) + 1) is + very roughly the % streaming read efficiency your disk should get with + multiple readers. + +* read_batch_expire + Controls how much time a batch of reads is given before pending writes are + served. A higher value is more efficient. This might be set below read_expire + if writes are to be given higher priority than reads, but reads are to be + as efficient as possible when there are no writes. Generally though, it + should be some multiple of read_expire. + +* write_expire, and +* write_batch_expire are equivalent to the above, for writes. + +* antic_expire + Controls the maximum amount of time we can anticipate a good read (one + with a short seek distance from the most recently completed request) before + giving up. Many other factors may cause anticipation to be stopped early, + or some processes will not be "anticipated" at all. Should be a bit higher + for big seek time devices though not a linear correspondence - most + processes have only a few ms thinktime. + +In addition to the tunables above there is a read-only file named est_time +which, when read, will show: + + - The probability of a task exiting without a cooperating task + submitting an anticipated IO. + + - The current mean think time. + + - The seek distance used to determine if an incoming IO is better. + diff --git a/trunk/Documentation/block/biodoc.txt b/trunk/Documentation/block/biodoc.txt index 6fab97ea7e6b..8d2158a1c6aa 100644 --- a/trunk/Documentation/block/biodoc.txt +++ b/trunk/Documentation/block/biodoc.txt @@ -186,7 +186,7 @@ a virtual address mapping (unlike the earlier scheme of virtual address do not have a corresponding kernel virtual address space mapping) and low-memory pages. -Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion +Note: Please refer to Documentation/DMA-mapping.txt for a discussion on PCI high mem DMA aspects and mapping of scatter gather lists, and support for 64 bit PCI. diff --git a/trunk/Documentation/cdrom/ide-cd b/trunk/Documentation/cdrom/ide-cd index 2c558cd6c1ef..f4dc9de2694e 100644 --- a/trunk/Documentation/cdrom/ide-cd +++ b/trunk/Documentation/cdrom/ide-cd @@ -159,42 +159,7 @@ two arguments: the CDROM device, and the slot number to which you wish to change. If the slot number is -1, the drive is unloaded. -4. Compilation options ----------------------- - -There are a few additional options which can be set when compiling the -driver. Most people should not need to mess with any of these; they -are listed here simply for completeness. A compilation option can be -enabled by adding a line of the form `#define