Kernel/linux-next
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git synced 2025-01-10 15:58:47 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge branch 'master' into next

Browse Source
This commit is contained in:
James Morris 2010-01-18 09:56:22 +11:00
commit 2457552d1e
6630 changed files with 539846 additions and 308458 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
.gitignore vendored
View File

@ -22,6 +22,7 @@
*.lst
*.symtypes
*.order
modules.builtin
*.elf
*.bin
*.gz
@ -36,6 +37,7 @@
tags
TAGS
vmlinux
vmlinuz
System.map
Module.markers
Module.symvers
@ -45,14 +47,8 @@ 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

8
Documentation/ABI/stable/sysfs-driver-qla2xxx Normal file
View File

@ -0,0 +1,8 @@
What: /sys/bus/pci/drivers/qla2xxx/.../devices/*
Date: September 2009
Contact: QLogic Linux Driver <linux-driver@qlogic.com>
Description: qla2xxx-udev.sh currently looks for uevent CHANGE events to
signal a firmware-dump has been generated by the driver and is
ready for retrieval.
Users: qla2xxx-udev.sh. Proposed changes should be mailed to
linux-driver@qlogic.com

2
Documentation/ABI/testing/procfs-diskstats
View File

@ -8,7 +8,7 @@ Description:
1 - major number
2 - minor mumber
3 - device name
4 - reads completed succesfully
4 - reads completed successfully
5 - reads merged
6 - sectors read
7 - time spent reading (ms)

2
Documentation/ABI/testing/sysfs-block
View File

@ -4,7 +4,7 @@ Contact: Jerome Marchand <jmarchan@redhat.com>
Description:
The /sys/block/<disk>/stat files displays the I/O
statistics of disk <disk>. They contain 11 fields:
1 - reads completed succesfully
1 - reads completed successfully
2 - reads merged
3 - sectors read
4 - time spent reading (ms)

31
Documentation/ABI/testing/sysfs-bus-usb
View File

@ -21,25 +21,27 @@ Contact: Alan Stern <stern@rowland.harvard.edu>
Description:
Each USB device directory will contain a file named
power/level. This file holds a power-level setting for
the device, one of "on", "auto", or "suspend".
the device, either "on" or "auto".
"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. "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).
capabilities of its driver.
During normal use, devices should be left in the "auto"
level. The other levels are meant for administrative uses.
level. The "on" level is 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
@ -144,3 +146,16 @@ Description:
Write a 1 to force the device to disconnect
(equivalent to unplugging a wired USB device).
What: /sys/bus/usb/drivers/.../remove_id
Date: November 2009
Contact: CHENG Renquan <rqcheng@smu.edu.sg>
Description:
Writing a device ID to this file will remove an ID
that was dynamically added via the new_id sysfs entry.
The format for the device ID is:
idVendor idProduct. After successfully
removing an ID, the driver will no longer support the
device. This is useful to ensure auto probing won't
match the driver to the device. For example:
# echo "046d c315" > /sys/bus/usb/drivers/foo/remove_id

13
Documentation/ABI/testing/sysfs-class-uwb_rc-wusbhc
View File

@ -23,3 +23,16 @@ Description:
Since this relates to security (specifically, the
lifetime of PTKs and GTKs) it should not be changed
from the default.
What: /sys/class/uwb_rc/uwbN/wusbhc/wusb_phy_rate
Date: August 2009
KernelVersion: 2.6.32
Contact: David Vrabel <david.vrabel@csr.com>
Description:
The maximum PHY rate to use for all connected devices.
This is only of limited use for testing and
development as the hardware's automatic rate
adaptation is better then this simple control.
Refer to [ECMA-368] section 10.3.1.1 for the value to
use.

14
Documentation/ABI/testing/sysfs-devices-memory
View File

@ -60,6 +60,19 @@ 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 <linux-mm@kvack.org>
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 <garyhade@us.ibm.com>
@ -70,4 +83,3 @@ 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

47
Documentation/ABI/testing/sysfs-devices-system-cpu
View File

@ -62,6 +62,35 @@ Description: CPU topology files that describe kernel limits related to
See Documentation/cputopology.txt for more information.
What: /sys/devices/system/cpu/probe
/sys/devices/system/cpu/release
Date: November 2009
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Dynamic addition and removal of CPU's. This is not hotplug
removal, this is meant complete removal/addition of the CPU
from the system.
probe: writes to this file will dynamically add a CPU to the
system. Information written to the file to add CPU's is
architecture specific.
release: writes to this file dynamically remove a CPU from
the system. Information writtento the file to remove CPU's
is architecture specific.
What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
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#/node
Date: October 2009
@ -136,6 +165,24 @@ Description: Discover cpuidle policy and mechanism
See files in Documentation/cpuidle/ for more information.
What: /sys/devices/system/cpu/cpu#/cpufreq/*
Date: pre-git history
Contact: cpufreq@vger.kernel.org
Description: Discover and change clock speed of CPUs
Clock scaling allows you to change the clock speed of the
CPUs on the fly. This is a nice method to save battery
power, because the lower the clock speed, the less power
the CPU consumes.
There are many knobs to tweak in this directory.
See files in Documentation/cpu-freq/ for more information.
In particular, read Documentation/cpu-freq/user-guide.txt
to learn how to control the knobs.
What: /sys/devices/system/cpu/cpu*/cache/index*/cache_disable_X
Date: August 2008
KernelVersion: 2.6.27

109
Documentation/ABI/testing/sysfs-kernel-slab
View File

@ -45,8 +45,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_fastpath file is read-only and specifies how many
objects have been allocated using the fast path.
The alloc_fastpath file shows how many objects have been
allocated using the fast path. It can be written to clear the
current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_from_partial
@ -55,9 +56,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_from_partial file is read-only and specifies how
many times a cpu slab has been full and it has been refilled
by using a slab from the list of partially used slabs.
The alloc_from_partial file shows how many times a cpu slab has
been full and it has been refilled by using a slab from the list
of partially used slabs. It can be written to clear the current
count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_refill
@ -66,9 +68,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_refill file is read-only and specifies how many
times the per-cpu freelist was empty but there were objects
available as the result of remote cpu frees.
The alloc_refill file shows how many times the per-cpu freelist
was empty but there were objects available as the result of
remote cpu frees. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_slab
@ -77,8 +79,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_slab file is read-only and specifies how many times
a new slab had to be allocated from the page allocator.
The alloc_slab file is shows how many times a new slab had to
be allocated from the page allocator. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/alloc_slowpath
@ -87,9 +90,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The alloc_slowpath file is read-only and specifies how many
objects have been allocated using the slow path because of a
refill or allocation from a partial or new slab.
The alloc_slowpath file shows how many objects have been
allocated using the slow path because of a refill or
allocation from a partial or new slab. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/cache_dma
@ -117,10 +121,11 @@ KernelVersion: 2.6.31
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file cpuslab_flush is read-only and specifies how many
times a cache's cpu slabs have been flushed as the result of
destroying or shrinking a cache, a cpu going offline, or as
the result of forcing an allocation from a certain node.
The file cpuslab_flush shows how many times a cache's cpu slabs
have been flushed as the result of destroying or shrinking a
cache, a cpu going offline, or as the result of forcing an
allocation from a certain node. It can be written to clear the
current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/ctor
@ -139,8 +144,8 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_empty is read-only and specifies how many
times an empty cpu slab was deactivated.
The deactivate_empty file shows how many times an empty cpu slab
was deactivated. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_full
@ -149,8 +154,8 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_full is read-only and specifies how many
times a full cpu slab was deactivated.
The deactivate_full file shows how many times a full cpu slab
was deactivated. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_remote_frees
@ -159,9 +164,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_remote_frees is read-only and specifies how
many times a cpu slab has been deactivated and contained free
objects that were freed remotely.
The deactivate_remote_frees file shows how many times a cpu slab
has been deactivated and contained free objects that were freed
remotely. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_to_head
@ -170,9 +175,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_to_head is read-only and specifies how
many times a partial cpu slab was deactivated and added to the
head of its node's partial list.
The deactivate_to_head file shows how many times a partial cpu
slab was deactivated and added to the head of its node's partial
list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/deactivate_to_tail
@ -181,9 +186,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file deactivate_to_tail is read-only and specifies how
many times a partial cpu slab was deactivated and added to the
tail of its node's partial list.
The deactivate_to_tail file shows how many times a partial cpu
slab was deactivated and added to the tail of its node's partial
list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/destroy_by_rcu
@ -201,9 +206,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file free_add_partial is read-only and specifies how many
times an object has been freed in a full slab so that it had to
added to its node's partial list.
The free_add_partial file shows how many times an object has
been freed in a full slab so that it had to added to its node's
partial list. It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_calls
@ -222,9 +227,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_fastpath file is read-only and specifies how many
objects have been freed using the fast path because it was an
object from the cpu slab.
The free_fastpath file shows how many objects have been freed
using the fast path because it was an object from the cpu slab.
It can be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_frozen
@ -233,9 +238,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_frozen file is read-only and specifies how many
objects have been freed to a frozen slab (i.e. a remote cpu
slab).
The free_frozen file shows how many objects have been freed to
a frozen slab (i.e. a remote cpu slab). It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_remove_partial
@ -244,9 +249,10 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file free_remove_partial is read-only and specifies how
many times an object has been freed to a now-empty slab so
that it had to be removed from its node's partial list.
The free_remove_partial file shows how many times an object has
been freed to a now-empty slab so that it had to be removed from
its node's partial list. It can be written to clear the current
count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_slab
@ -255,8 +261,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_slab file is read-only and specifies how many times an
empty slab has been freed back to the page allocator.
The free_slab file shows how many times an empty slab has been
freed back to the page allocator. It can be written to clear
the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/free_slowpath
@ -265,9 +272,9 @@ KernelVersion: 2.6.25
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The free_slowpath file is read-only and specifies how many
objects have been freed using the slow path (i.e. to a full or
partial slab).
The free_slowpath file shows how many objects have been freed
using the slow path (i.e. to a full or partial slab). It can
be written to clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/hwcache_align
@ -346,10 +353,10 @@ KernelVersion: 2.6.26
Contact: Pekka Enberg <penberg@cs.helsinki.fi>,
Christoph Lameter <cl@linux-foundation.org>
Description:
The file order_fallback is read-only and specifies how many
times an allocation of a new slab has not been possible at the
cache's order and instead fallen back to its minimum possible
order.
The order_fallback file shows how many times an allocation of a
new slab has not been possible at the cache's order and instead
fallen back to its minimum possible order. It can be written to
clear the current count.
Available when CONFIG_SLUB_STATS is enabled.
What: /sys/kernel/slab/cache/partial

44
Documentation/ABI/testing/sysfs-memory-page-offline Normal file
View File

@ -0,0 +1,44 @@
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.

2
Documentation/Changes
View File

@ -49,6 +49,8 @@ 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
==================

38
Documentation/DocBook/Makefile
View File

@ -8,7 +8,7 @@
DOCBOOKS := z8530book.xml mcabook.xml device-drivers.xml \
kernel-hacking.xml kernel-locking.xml deviceiobook.xml \
procfs-guide.xml writing_usb_driver.xml networking.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 media
PHONY += xmldocs sgmldocs psdocs pdfdocs htmldocs mandocs installmandocs cleandocs xmldoclinks
BOOKS := $(addprefix $(obj)/,$(DOCBOOKS))
xmldocs: $(BOOKS)
xmldocs: $(BOOKS) xmldoclinks
sgmldocs: xmldocs
PS := $(patsubst %.xml, %.ps, $(BOOKS))
@ -45,15 +45,24 @@ PDF := $(patsubst %.xml, %.pdf, $(BOOKS))
pdfdocs: $(PDF)
HTML := $(sort $(patsubst %.xml, %.html, $(BOOKS)))
htmldocs: media $(HTML)
htmldocs: $(HTML)
$(call build_main_index)
$(call build_images)
MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN)
media:
mkdir -p $(srctree)/Documentation/DocBook/media/
cp $(srctree)/Documentation/DocBook/dvb/*.png $(srctree)/Documentation/DocBook/v4l/*.gif $(srctree)/Documentation/DocBook/media/
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
installmandocs: mandocs
mkdir -p /usr/local/man/man9/
@ -65,7 +74,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:
@ -101,17 +110,6 @@ 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)
@ -238,7 +236,7 @@ clean-files := $(DOCBOOKS) \
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
$(C-procfs-example) $(index)
$(index)
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

13
Documentation/DocBook/device-drivers.tmpl
View File

@ -293,10 +293,23 @@ X!Idrivers/video/console/fonts.c
<chapter id="input_subsystem">
<title>Input Subsystem</title>
<sect1><title>Input core</title>
!Iinclude/linux/input.h
!Edrivers/input/input.c
!Edrivers/input/ff-core.c
!Edrivers/input/ff-memless.c
</sect1>
<sect1><title>Polled input devices</title>
!Iinclude/linux/input-polldev.h
!Edrivers/input/input-polldev.c
</sect1>
<sect1><title>Matrix keyboars/keypads</title>
!Iinclude/linux/input/matrix_keypad.h
</sect1>
<sect1><title>Sparse keymap support</title>
!Iinclude/linux/input/sparse-keymap.h
!Edrivers/input/sparse-keymap.c
</sect1>
</chapter>
<chapter id="spi">

13
Documentation/DocBook/dvb/dvbapi.xml
View File

@ -29,6 +29,14 @@
<revhistory>
<!-- Put document revisions here, newest first. -->
<revision>
<revnumber>2.0.2</revnumber>
<date>2009-10-25</date>
<authorinitials>mcc</authorinitials>
<revremark>
documents FE_SET_FRONTEND_TUNE_MODE and FE_DISHETWORK_SEND_LEGACY_CMD ioctls.
</revremark>
</revision>
<revision>
<revnumber>2.0.1</revnumber>
<date>2009-09-16</date>
@ -85,3 +93,8 @@ Added ISDB-T test originally written by Patrick Boettcher
&sub-examples;
</chapter>
<!-- END OF CHAPTERS -->
<appendix id="frontend_h">
<title>DVB Frontend Header File</title>
&sub-frontend-h;
</appendix>

4
Documentation/DocBook/dvb/isdbt.xml → Documentation/DocBook/dvb/dvbproperty.xml
View File

@ -1,3 +1,6 @@
<section id="FE_GET_PROPERTY">
<title>FE_GET_PROPERTY/FE_SET_PROPERTY</title>
<section id="isdbt">
<title>ISDB-T frontend</title>
<para>This section describes shortly what are the possible parameters in the Linux
@ -312,3 +315,4 @@
</section>
</section>
</section>
</section>

415
Documentation/DocBook/dvb/frontend.h.xml Normal file
View File

@ -0,0 +1,415 @@
<programlisting>
/*
* frontend.h
*
* Copyright (C) 2000 Marcus Metzler &lt;marcus@convergence.de&gt;
* Ralph Metzler &lt;ralph@convergence.de&gt;
* Holger Waechtler &lt;holger@convergence.de&gt;
* Andre Draszik &lt;ad@convergence.de&gt;
* for convergence integrated media GmbH
*
* This program is free software; you can redistribute it and/or
* modify it under the terms of the GNU Lesser General Public License
* as published by the Free Software Foundation; either version 2.1
* 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 Lesser 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.
*
*/
#ifndef _DVBFRONTEND_H_
#define _DVBFRONTEND_H_
#include &lt;linux/types.h&gt;
typedef enum fe_type {
FE_QPSK,
FE_QAM,
FE_OFDM,
FE_ATSC
} fe_type_t;
typedef enum fe_caps {
FE_IS_STUPID = 0,
FE_CAN_INVERSION_AUTO = 0x1,
FE_CAN_FEC_1_2 = 0x2,
FE_CAN_FEC_2_3 = 0x4,
FE_CAN_FEC_3_4 = 0x8,
FE_CAN_FEC_4_5 = 0x10,
FE_CAN_FEC_5_6 = 0x20,
FE_CAN_FEC_6_7 = 0x40,
FE_CAN_FEC_7_8 = 0x80,
FE_CAN_FEC_8_9 = 0x100,
FE_CAN_FEC_AUTO = 0x200,
FE_CAN_QPSK = 0x400,
FE_CAN_QAM_16 = 0x800,
FE_CAN_QAM_32 = 0x1000,
FE_CAN_QAM_64 = 0x2000,
FE_CAN_QAM_128 = 0x4000,
FE_CAN_QAM_256 = 0x8000,
FE_CAN_QAM_AUTO = 0x10000,
FE_CAN_TRANSMISSION_MODE_AUTO = 0x20000,
FE_CAN_BANDWIDTH_AUTO = 0x40000,
FE_CAN_GUARD_INTERVAL_AUTO = 0x80000,
FE_CAN_HIERARCHY_AUTO = 0x100000,
FE_CAN_8VSB = 0x200000,
FE_CAN_16VSB = 0x400000,
FE_HAS_EXTENDED_CAPS = 0x800000, /* We need more bitspace for newer APIs, indicate this. */
FE_CAN_2G_MODULATION = 0x10000000, /* frontend supports "2nd generation modulation" (DVB-S2) */
FE_NEEDS_BENDING = 0x20000000, /* not supported anymore, don't use (frontend requires frequency bending) */
FE_CAN_RECOVER = 0x40000000, /* frontend can recover from a cable unplug automatically */
FE_CAN_MUTE_TS = 0x80000000 /* frontend can stop spurious TS data output */
} fe_caps_t;
struct dvb_frontend_info {
char name[128];
fe_type_t type;
__u32 frequency_min;
__u32 frequency_max;
__u32 frequency_stepsize;
__u32 frequency_tolerance;
__u32 symbol_rate_min;
__u32 symbol_rate_max;
__u32 symbol_rate_tolerance; /* ppm */
__u32 notifier_delay; /* DEPRECATED */
fe_caps_t caps;
};
/**
* Check out the DiSEqC bus spec available on http://www.eutelsat.org/ for
* the meaning of this struct...
*/
struct dvb_diseqc_master_cmd {
__u8 msg [6]; /* { framing, address, command, data [3] } */
__u8 msg_len; /* valid values are 3...6 */
};
struct dvb_diseqc_slave_reply {
__u8 msg [4]; /* { framing, data [3] } */
__u8 msg_len; /* valid values are 0...4, 0 means no msg */
int timeout; /* return from ioctl after timeout ms with */
}; /* errorcode when no message was received */
typedef enum fe_sec_voltage {
SEC_VOLTAGE_13,
SEC_VOLTAGE_18,
SEC_VOLTAGE_OFF
} fe_sec_voltage_t;
typedef enum fe_sec_tone_mode {
SEC_TONE_ON,
SEC_TONE_OFF
} fe_sec_tone_mode_t;
typedef enum fe_sec_mini_cmd {
SEC_MINI_A,
SEC_MINI_B
} fe_sec_mini_cmd_t;
typedef enum fe_status {
FE_HAS_SIGNAL = 0x01, /* found something above the noise level */
FE_HAS_CARRIER = 0x02, /* found a DVB signal */
FE_HAS_VITERBI = 0x04, /* FEC is stable */
FE_HAS_SYNC = 0x08, /* found sync bytes */
FE_HAS_LOCK = 0x10, /* everything's working... */
FE_TIMEDOUT = 0x20, /* no lock within the last ~2 seconds */
FE_REINIT = 0x40 /* frontend was reinitialized, */
} fe_status_t; /* application is recommended to reset */
/* DiSEqC, tone and parameters */
typedef enum fe_spectral_inversion {
INVERSION_OFF,
INVERSION_ON,
INVERSION_AUTO
} fe_spectral_inversion_t;
typedef enum fe_code_rate {
FEC_NONE = 0,
FEC_1_2,
FEC_2_3,
FEC_3_4,
FEC_4_5,
FEC_5_6,
FEC_6_7,
FEC_7_8,
FEC_8_9,
FEC_AUTO,
FEC_3_5,
FEC_9_10,
} fe_code_rate_t;
typedef enum fe_modulation {
QPSK,
QAM_16,
QAM_32,
QAM_64,
QAM_128,
QAM_256,
QAM_AUTO,
VSB_8,
VSB_16,
PSK_8,
APSK_16,
APSK_32,
DQPSK,
} fe_modulation_t;
typedef enum fe_transmit_mode {
TRANSMISSION_MODE_2K,
TRANSMISSION_MODE_8K,
TRANSMISSION_MODE_AUTO,
TRANSMISSION_MODE_4K
} fe_transmit_mode_t;
typedef enum fe_bandwidth {
BANDWIDTH_8_MHZ,
BANDWIDTH_7_MHZ,
BANDWIDTH_6_MHZ,
BANDWIDTH_AUTO
} fe_bandwidth_t;
typedef enum fe_guard_interval {
GUARD_INTERVAL_1_32,
GUARD_INTERVAL_1_16,
GUARD_INTERVAL_1_8,
GUARD_INTERVAL_1_4,
GUARD_INTERVAL_AUTO
} fe_guard_interval_t;
typedef enum fe_hierarchy {
HIERARCHY_NONE,
HIERARCHY_1,
HIERARCHY_2,
HIERARCHY_4,
HIERARCHY_AUTO
} fe_hierarchy_t;
struct dvb_qpsk_parameters {
__u32 symbol_rate; /* symbol rate in Symbols per second */
fe_code_rate_t fec_inner; /* forward error correction (see above) */
};
struct dvb_qam_parameters {
__u32 symbol_rate; /* symbol rate in Symbols per second */
fe_code_rate_t fec_inner; /* forward error correction (see above) */
fe_modulation_t modulation; /* modulation type (see above) */
};
struct dvb_vsb_parameters {
fe_modulation_t modulation; /* modulation type (see above) */
};
struct dvb_ofdm_parameters {
fe_bandwidth_t bandwidth;
fe_code_rate_t code_rate_HP; /* high priority stream code rate */
fe_code_rate_t code_rate_LP; /* low priority stream code rate */
fe_modulation_t constellation; /* modulation type (see above) */
fe_transmit_mode_t transmission_mode;
fe_guard_interval_t guard_interval;
fe_hierarchy_t hierarchy_information;
};
struct dvb_frontend_parameters {
__u32 frequency; /* (absolute) frequency in Hz for QAM/OFDM/ATSC */
/* intermediate frequency in kHz for QPSK */
fe_spectral_inversion_t inversion;
union {
struct dvb_qpsk_parameters qpsk;
struct dvb_qam_parameters qam;
struct dvb_ofdm_parameters ofdm;
struct dvb_vsb_parameters vsb;
} u;
};
struct dvb_frontend_event {
fe_status_t status;
struct dvb_frontend_parameters parameters;
};
/* S2API Commands */
#define DTV_UNDEFINED 0
#define DTV_TUNE 1
#define DTV_CLEAR 2
#define DTV_FREQUENCY 3
#define DTV_MODULATION 4
#define DTV_BANDWIDTH_HZ 5
#define DTV_INVERSION 6
#define DTV_DISEQC_MASTER 7
#define DTV_SYMBOL_RATE 8
#define DTV_INNER_FEC 9
#define DTV_VOLTAGE 10
#define DTV_TONE 11
#define DTV_PILOT 12
#define DTV_ROLLOFF 13
#define DTV_DISEQC_SLAVE_REPLY 14
/* Basic enumeration set for querying unlimited capabilities */
#define DTV_FE_CAPABILITY_COUNT 15
#define DTV_FE_CAPABILITY 16
#define DTV_DELIVERY_SYSTEM 17
/* ISDB-T and ISDB-Tsb */
#define DTV_ISDBT_PARTIAL_RECEPTION 18
#define DTV_ISDBT_SOUND_BROADCASTING 19
#define DTV_ISDBT_SB_SUBCHANNEL_ID 20
#define DTV_ISDBT_SB_SEGMENT_IDX 21
#define DTV_ISDBT_SB_SEGMENT_COUNT 22
#define DTV_ISDBT_LAYERA_FEC 23
#define DTV_ISDBT_LAYERA_MODULATION 24
#define DTV_ISDBT_LAYERA_SEGMENT_COUNT 25
#define DTV_ISDBT_LAYERA_TIME_INTERLEAVING 26
#define DTV_ISDBT_LAYERB_FEC 27
#define DTV_ISDBT_LAYERB_MODULATION 28
#define DTV_ISDBT_LAYERB_SEGMENT_COUNT 29
#define DTV_ISDBT_LAYERB_TIME_INTERLEAVING 30
#define DTV_ISDBT_LAYERC_FEC 31
#define DTV_ISDBT_LAYERC_MODULATION 32
#define DTV_ISDBT_LAYERC_SEGMENT_COUNT 33
#define DTV_ISDBT_LAYERC_TIME_INTERLEAVING 34
#define DTV_API_VERSION 35
#define DTV_CODE_RATE_HP 36
#define DTV_CODE_RATE_LP 37
#define DTV_GUARD_INTERVAL 38
#define DTV_TRANSMISSION_MODE 39
#define DTV_HIERARCHY 40
#define DTV_ISDBT_LAYER_ENABLED 41
#define DTV_ISDBS_TS_ID 42
#define DTV_MAX_COMMAND DTV_ISDBS_TS_ID
typedef enum fe_pilot {
PILOT_ON,
PILOT_OFF,
PILOT_AUTO,
} fe_pilot_t;
typedef enum fe_rolloff {
ROLLOFF_35, /* Implied value in DVB-S, default for DVB-S2 */
ROLLOFF_20,
ROLLOFF_25,
ROLLOFF_AUTO,
} fe_rolloff_t;
typedef enum fe_delivery_system {
SYS_UNDEFINED,
SYS_DVBC_ANNEX_AC,
SYS_DVBC_ANNEX_B,
SYS_DVBT,
SYS_DSS,
SYS_DVBS,
SYS_DVBS2,
SYS_DVBH,
SYS_ISDBT,
SYS_ISDBS,
SYS_ISDBC,
SYS_ATSC,
SYS_ATSCMH,
SYS_DMBTH,
SYS_CMMB,
SYS_DAB,
} fe_delivery_system_t;
struct dtv_cmds_h {
char *name; /* A display name for debugging purposes */
__u32 cmd; /* A unique ID */
/* Flags */
__u32 set:1; /* Either a set or get property */
__u32 buffer:1; /* Does this property use the buffer? */
__u32 reserved:30; /* Align */
};
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct {
__u8 data[32];
__u32 len;
__u32 reserved1[3];
void *reserved2;
} buffer;
} u;
int result;
} __attribute__ ((packed));
/* num of properties cannot exceed DTV_IOCTL_MAX_MSGS per ioctl */
#define DTV_IOCTL_MAX_MSGS 64
struct dtv_properties {
__u32 num;
struct dtv_property *props;
};
#define <link linkend="FE_GET_PROPERTY">FE_SET_PROPERTY</link> _IOW('o', 82, struct dtv_properties)
#define <link linkend="FE_GET_PROPERTY">FE_GET_PROPERTY</link> _IOR('o', 83, struct dtv_properties)
/**
* When set, this flag will disable any zigzagging or other "normal" tuning
* behaviour. Additionally, there will be no automatic monitoring of the lock
* status, and hence no frontend events will be generated. If a frontend device
* is closed, this flag will be automatically turned off when the device is
* reopened read-write.
*/
#define FE_TUNE_MODE_ONESHOT 0x01
#define <link linkend="FE_GET_INFO">FE_GET_INFO</link> _IOR('o', 61, struct dvb_frontend_info)
#define <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> _IO('o', 62)
#define <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> _IOW('o', 63, struct dvb_diseqc_master_cmd)
#define <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> _IOR('o', 64, struct dvb_diseqc_slave_reply)
#define <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> _IO('o', 65) /* fe_sec_mini_cmd_t */
#define <link linkend="FE_SET_TONE">FE_SET_TONE</link> _IO('o', 66) /* fe_sec_tone_mode_t */
#define <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> _IO('o', 67) /* fe_sec_voltage_t */
#define <link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link> _IO('o', 68) /* int */
#define <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> _IOR('o', 69, fe_status_t)
#define <link linkend="FE_READ_BER">FE_READ_BER</link> _IOR('o', 70, __u32)
#define <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> _IOR('o', 71, __u16)
#define <link linkend="FE_READ_SNR">FE_READ_SNR</link> _IOR('o', 72, __u16)
#define <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> _IOR('o', 73, __u32)
#define <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> _IOW('o', 76, struct dvb_frontend_parameters)
#define <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link> _IOR('o', 77, struct dvb_frontend_parameters)
#define <link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link> _IO('o', 81) /* unsigned int */
#define <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> _IOR('o', 78, struct dvb_frontend_event)
#define <link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link> _IO('o', 80) /* unsigned int */
#endif /*_DVBFRONTEND_H_*/
</programlisting>

185
Documentation/DocBook/dvb/frontend.xml
View File

@ -73,7 +73,8 @@ a specific frontend type.</para>
<section id="frontend_info">
<title>frontend information</title>
<para>Information about the frontend ca be queried with FE_GET_INFO.</para>
<para>Information about the frontend ca be queried with
<link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para>
<programlisting>
struct dvb_frontend_info {
@ -338,7 +339,7 @@ modulation mode which can be one of the following:
<entry align="char">
<para>This system call opens a named frontend device (/dev/dvb/adapter0/frontend0)
for subsequent use. Usually the first thing to do after a successful open is to
find out the frontend type with FE_GET_INFO.</para>
find out the frontend type with <link linkend="FE_GET_INFO">FE_GET_INFO</link>.</para>
<para>The device can be opened in read-only mode, which only allows monitoring of
device status and statistics, or read/write mode, which allows any kind of use
(e.g. performing tuning operations.)
@ -478,7 +479,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_read_status">
<section id="FE_READ_STATUS">
<title>FE_READ_STATUS</title>
<para>DESCRIPTION
</para>
@ -492,7 +493,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_READ_STATUS,
<para>int ioctl(int fd, int request = <link linkend="FE_READ_STATUS">FE_READ_STATUS</link>,
fe_status_t &#x22C6;status);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -511,7 +512,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_READ_STATUS for this command.</para>
<para>Equals <link linkend="FE_READ_STATUS">FE_READ_STATUS</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -542,7 +543,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_read_ber">
<section id="FE_READ_BER">
<title>FE_READ_BER</title>
<para>DESCRIPTION
</para>
@ -557,7 +558,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_READ_BER,
<para>int ioctl(int fd, int request = <link linkend="FE_READ_BER">FE_READ_BER</link>,
uint32_t &#x22C6;ber);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -575,7 +576,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_READ_BER for this command.</para>
<para>Equals <link linkend="FE_READ_BER">FE_READ_BER</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -619,7 +620,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_read_snr">
<section id="FE_READ_SNR">
<title>FE_READ_SNR</title>
<para>DESCRIPTION
@ -634,7 +635,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_READ_SNR, int16_t
<para>int ioctl(int fd, int request = <link linkend="FE_READ_SNR">FE_READ_SNR</link>, int16_t
&#x22C6;snr);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -652,7 +653,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_READ_SNR for this command.</para>
<para>Equals <link linkend="FE_READ_SNR">FE_READ_SNR</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -697,7 +698,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_read_signal_strength">
<section id="FE_READ_SIGNAL_STRENGTH">
<title>FE_READ_SIGNAL_STRENGTH</title>
<para>DESCRIPTION
</para>
@ -712,7 +713,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl( int fd, int request =
FE_READ_SIGNAL_STRENGTH, int16_t &#x22C6;strength);</para>
<link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link>, int16_t &#x22C6;strength);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -730,7 +731,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_READ_SIGNAL_STRENGTH for this
<para>Equals <link linkend="FE_READ_SIGNAL_STRENGTH">FE_READ_SIGNAL_STRENGTH</link> for this
command.</para>
</entry>
</row><row><entry
@ -775,7 +776,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_read_ub">
<section id="FE_READ_UNCORRECTED_BLOCKS">
<title>FE_READ_UNCORRECTED_BLOCKS</title>
<para>DESCRIPTION
</para>
@ -797,7 +798,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl( int fd, int request =
FE_READ_UNCORRECTED_BLOCKS, uint32_t &#x22C6;ublocks);</para>
<link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link>, uint32_t &#x22C6;ublocks);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
@ -814,7 +815,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_READ_UNCORRECTED_BLOCKS for this
<para>Equals <link linkend="FE_READ_UNCORRECTED_BLOCKS">FE_READ_UNCORRECTED_BLOCKS</link> for this
command.</para>
</entry>
</row><row><entry
@ -852,7 +853,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_set_fe">
<section id="FE_SET_FRONTEND">
<title>FE_SET_FRONTEND</title>
<para>DESCRIPTION
</para>
@ -861,8 +862,8 @@ modulation mode which can be one of the following:
<para>This ioctl call starts a tuning operation using specified parameters. The result
of this call will be successful if the parameters were valid and the tuning could
be initiated. The result of the tuning operation in itself, however, will arrive
asynchronously as an event (see documentation for FE_GET_EVENT and
FrontendEvent.) If a new FE_SET_FRONTEND operation is initiated before
asynchronously as an event (see documentation for <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> and
FrontendEvent.) If a new <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> operation is initiated before
the previous one was completed, the previous operation will be aborted in favor
of the new one. This command requires read/write access to the device.</para>
</entry>
@ -872,7 +873,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_SET_FRONTEND,
<para>int ioctl(int fd, int request = <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link>,
struct dvb_frontend_parameters &#x22C6;p);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -890,7 +891,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_SET_FRONTEND for this command.</para>
<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -928,7 +929,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_get_fe">
<section id="FE_GET_FRONTEND">
<title>FE_GET_FRONTEND</title>
<para>DESCRIPTION
</para>
@ -943,7 +944,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_GET_FRONTEND,
<para>int ioctl(int fd, int request = <link linkend="FE_GET_FRONTEND">FE_GET_FRONTEND</link>,
struct dvb_frontend_parameters &#x22C6;p);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -962,7 +963,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_SET_FRONTEND for this command.</para>
<para>Equals <link linkend="FE_SET_FRONTEND">FE_SET_FRONTEND</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1003,7 +1004,7 @@ modulation mode which can be one of the following:
</section>
<section id="frontend_get_event">
<section id="FE_GET_EVENT">
<title>FE_GET_EVENT</title>
<para>DESCRIPTION
</para>
@ -1024,7 +1025,8 @@ modulation mode which can be one of the following:
rather small (room for 8 events), the queue must be serviced regularly to avoid
overflow. If an overflow happens, the oldest event is discarded from the queue,
and an error (EOVERFLOW) occurs the next time the queue is read. After
reporting the error condition in this fashion, subsequent FE_GET_EVENT
reporting the error condition in this fashion, subsequent
<link linkend="FE_GET_EVENT">FE_GET_EVENT</link>
calls will return events from the queue as usual.</para>
</entry>
</row><row><entry
@ -1057,7 +1059,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_GET_EVENT for this command.</para>
<para>Equals <link linkend="FE_GET_EVENT">FE_GET_EVENT</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1115,7 +1117,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_get_info">
<section id="FE_GET_INFO">
<title>FE_GET_INFO</title>
<para>DESCRIPTION
</para>
@ -1130,7 +1132,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para> int ioctl(int fd, int request = FE_GET_INFO, struct
<para> int ioctl(int fd, int request = <link linkend="FE_GET_INFO">FE_GET_INFO</link>, struct
dvb_frontend_info &#x22C6;info);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1149,7 +1151,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_GET_INFO for this command.</para>
<para>Equals <link linkend="FE_GET_INFO">FE_GET_INFO</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1181,7 +1183,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_diseqc_reset_overload">
<section id="FE_DISEQC_RESET_OVERLOAD">
<title>FE_DISEQC_RESET_OVERLOAD</title>
<para>DESCRIPTION
</para>
@ -1199,7 +1201,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
FE_DISEQC_RESET_OVERLOAD);</para>
<link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link>);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS
@ -1216,7 +1218,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_DISEQC_RESET_OVERLOAD for this
<para>Equals <link linkend="FE_DISEQC_RESET_OVERLOAD">FE_DISEQC_RESET_OVERLOAD</link> for this
command.</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1247,7 +1249,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_diseqc_send_master_cmd">
<section id="FE_DISEQC_SEND_MASTER_CMD">
<title>FE_DISEQC_SEND_MASTER_CMD</title>
<para>DESCRIPTION
</para>
@ -1261,7 +1263,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
FE_DISEQC_SEND_MASTER_CMD, struct
<link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link>, struct
dvb_diseqc_master_cmd &#x22C6;cmd);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1280,7 +1282,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_DISEQC_SEND_MASTER_CMD for this
<para>Equals <link linkend="FE_DISEQC_SEND_MASTER_CMD">FE_DISEQC_SEND_MASTER_CMD</link> for this
command.</para>
</entry>
</row><row><entry
@ -1335,7 +1337,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_diseqc_recv_slave_reply">
<section id="FE_DISEQC_RECV_SLAVE_REPLY">
<title>FE_DISEQC_RECV_SLAVE_REPLY</title>
<para>DESCRIPTION
</para>
@ -1350,7 +1352,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
FE_DISEQC_RECV_SLAVE_REPLY, struct
<link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link>, struct
dvb_diseqc_slave_reply &#x22C6;reply);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1369,7 +1371,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_DISEQC_RECV_SLAVE_REPLY for this
<para>Equals <link linkend="FE_DISEQC_RECV_SLAVE_REPLY">FE_DISEQC_RECV_SLAVE_REPLY</link> for this
command.</para>
</entry>
</row><row><entry
@ -1423,7 +1425,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_diseqc_send_burst">
<section id="FE_DISEQC_SEND_BURST">
<title>FE_DISEQC_SEND_BURST</title>
<para>DESCRIPTION
</para>
@ -1438,7 +1440,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
FE_DISEQC_SEND_BURST, fe_sec_mini_cmd_t burst);</para>
<link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link>, fe_sec_mini_cmd_t burst);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1456,7 +1458,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_DISEQC_SEND_BURST for this command.</para>
<para>Equals <link linkend="FE_DISEQC_SEND_BURST">FE_DISEQC_SEND_BURST</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1509,7 +1511,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_set_tone">
<section id="FE_SET_TONE">
<title>FE_SET_TONE</title>
<para>DESCRIPTION
</para>
@ -1523,7 +1525,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_SET_TONE,
<para>int ioctl(int fd, int request = <link linkend="FE_SET_TONE">FE_SET_TONE</link>,
fe_sec_tone_mode_t tone);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1541,7 +1543,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_SET_TONE for this command.</para>
<para>Equals <link linkend="FE_SET_TONE">FE_SET_TONE</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1592,7 +1594,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="fe_set_voltage">
<section id="FE_SET_VOLTAGE">
<title>FE_SET_VOLTAGE</title>
<para>DESCRIPTION
</para>
@ -1606,7 +1608,7 @@ modulation mode which can be one of the following:
</para>
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request = FE_SET_VOLTAGE,
<para>int ioctl(int fd, int request = <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link>,
fe_sec_voltage_t voltage);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1625,7 +1627,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_SET_VOLTAGE for this command.</para>
<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1677,7 +1679,7 @@ modulation mode which can be one of the following:
</row></tbody></tgroup></informaltable>
</section>
<section id="frontend_enable_high_lnb_volt">
<section id="FE_ENABLE_HIGH_LNB_VOLTAGE">
<title>FE_ENABLE_HIGH_LNB_VOLTAGE</title>
<para>DESCRIPTION
</para>
@ -1694,7 +1696,7 @@ modulation mode which can be one of the following:
<informaltable><tgroup cols="1"><tbody><row><entry
align="char">
<para>int ioctl(int fd, int request =
FE_ENABLE_HIGH_LNB_VOLTAGE, int high);</para>
<link linkend="FE_ENABLE_HIGH_LNB_VOLTAGE">FE_ENABLE_HIGH_LNB_VOLTAGE</link>, int high);</para>
</entry>
</row></tbody></tgroup></informaltable>
@ -1712,7 +1714,7 @@ modulation mode which can be one of the following:
<para>int request</para>
</entry><entry
align="char">
<para>Equals FE_SET_VOLTAGE for this command.</para>
<para>Equals <link linkend="FE_SET_VOLTAGE">FE_SET_VOLTAGE</link> for this command.</para>
</entry>
</row><row><entry
align="char">
@ -1762,5 +1764,82 @@ modulation mode which can be one of the following:
</entry>
</row></tbody></tgroup></informaltable>
</section>
<section id="FE_SET_FRONTEND_TUNE_MODE">
<title>FE_SET_FRONTEND_TUNE_MODE</title>
<para>DESCRIPTION</para>
<informaltable><tgroup cols="1"><tbody><row>
<entry align="char">
<para>Allow setting tuner mode flags to the frontend.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS</para>
<informaltable><tgroup cols="1"><tbody><row>
<entry align="char">
<para>int ioctl(int fd, int request =
<link linkend="FE_SET_FRONTEND_TUNE_MODE">FE_SET_FRONTEND_TUNE_MODE</link>, unsigned int flags);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS</para>
<informaltable><tgroup cols="2"><tbody><row>
<entry align="char">
<para>unsigned int flags</para>
</entry>
<entry align="char">
<para>
FE_TUNE_MODE_ONESHOT When set, this flag will disable any zigzagging or other "normal" tuning behaviour. Additionally, there will be no automatic monitoring of the lock status, and hence no frontend events will be generated. If a frontend device is closed, this flag will be automatically turned off when the device is reopened read-write.
</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>ERRORS</para>
<informaltable><tgroup cols="2"><tbody><row>
<entry align="char"><para>EINVAL</para></entry>
<entry align="char"><para>Invalid argument.</para></entry>
</row></tbody></tgroup></informaltable>
</section>
&sub-isdbt;
<section id="FE_DISHNETWORK_SEND_LEGACY_CMD">
<title>FE_DISHNETWORK_SEND_LEGACY_CMD</title>
<para>DESCRIPTION</para>
<informaltable><tgroup cols="1"><tbody><row>
<entry align="char">
<para>WARNING: This is a very obscure legacy command, used only at stv0299 driver. Should not be used on newer drivers.</para>
<para>It provides a non-standard method for selecting Diseqc voltage on the frontend, for Dish Network legacy switches.</para>
<para>As support for this ioctl were added in 2004, this means that such dishes were already legacy in 2004.</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>SYNOPSIS</para>
<informaltable><tgroup cols="1"><tbody><row>
<entry align="char">
<para>int ioctl(int fd, int request =
<link linkend="FE_DISHNETWORK_SEND_LEGACY_CMD">FE_DISHNETWORK_SEND_LEGACY_CMD</link>, unsigned long cmd);</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>PARAMETERS</para>
<informaltable><tgroup cols="2"><tbody><row>
<entry align="char">
<para>unsigned long cmd</para>
</entry>
<entry align="char">
<para>
sends the specified raw cmd to the dish via DISEqC.
</para>
</entry>
</row></tbody></tgroup></informaltable>
<para>ERRORS</para>
<informaltable><tgroup cols="1"><tbody><row>
<entry align="char">
<para>There are no errors in use for this call</para>
</entry>
</row></tbody></tgroup></informaltable>
</section>
</section>
&sub-dvbproperty;

4
Documentation/DocBook/genericirq.tmpl
View File

@ -417,8 +417,8 @@ desc->chip->end();
</para>
<para>
To make use of the split implementation, replace the call to
__do_IRQ by a call to desc->chip->handle_irq() and associate
the appropriate handler function to desc->chip->handle_irq().
__do_IRQ by a call to desc->handle_irq() and associate
the appropriate handler function to desc->handle_irq().
In most cases the generic handler implementations should
be sufficient.
</para>

2
Documentation/DocBook/kernel-hacking.tmpl
View File

@ -352,7 +352,7 @@ asmlinkage long sys_mycall(int arg)
</para>
<programlisting>
if (signal_pending())
if (signal_pending(current))
return -ERESTARTSYS;
</programlisting>

21
Documentation/DocBook/media-entities.tmpl
View File

@ -23,6 +23,7 @@
<!ENTITY VIDIOC-ENUMINPUT "<link linkend='vidioc-enuminput'><constant>VIDIOC_ENUMINPUT</constant></link>">
<!ENTITY VIDIOC-ENUMOUTPUT "<link linkend='vidioc-enumoutput'><constant>VIDIOC_ENUMOUTPUT</constant></link>">
<!ENTITY VIDIOC-ENUMSTD "<link linkend='vidioc-enumstd'><constant>VIDIOC_ENUMSTD</constant></link>">
<!ENTITY VIDIOC-ENUM-DV-PRESETS "<link linkend='vidioc-enum-dv-presets'><constant>VIDIOC_ENUM_DV_PRESETS</constant></link>">
<!ENTITY VIDIOC-ENUM-FMT "<link linkend='vidioc-enum-fmt'><constant>VIDIOC_ENUM_FMT</constant></link>">
<!ENTITY VIDIOC-ENUM-FRAMEINTERVALS "<link linkend='vidioc-enum-frameintervals'><constant>VIDIOC_ENUM_FRAMEINTERVALS</constant></link>">
<!ENTITY VIDIOC-ENUM-FRAMESIZES "<link linkend='vidioc-enum-framesizes'><constant>VIDIOC_ENUM_FRAMESIZES</constant></link>">
@ -30,6 +31,8 @@
<!ENTITY VIDIOC-G-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_G_AUDOUT</constant></link>">
<!ENTITY VIDIOC-G-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_G_CROP</constant></link>">
<!ENTITY VIDIOC-G-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_G_CTRL</constant></link>">
<!ENTITY VIDIOC-G-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_G_DV_PRESET</constant></link>">
<!ENTITY VIDIOC-G-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_G_DV_TIMINGS</constant></link>">
<!ENTITY VIDIOC-G-ENC-INDEX "<link linkend='vidioc-g-enc-index'><constant>VIDIOC_G_ENC_INDEX</constant></link>">
<!ENTITY VIDIOC-G-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_G_EXT_CTRLS</constant></link>">
<!ENTITY VIDIOC-G-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_G_FBUF</constant></link>">
@ -53,6 +56,7 @@
<!ENTITY VIDIOC-QUERYCTRL "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYCTRL</constant></link>">
<!ENTITY VIDIOC-QUERYMENU "<link linkend='vidioc-queryctrl'><constant>VIDIOC_QUERYMENU</constant></link>">
<!ENTITY VIDIOC-QUERYSTD "<link linkend='vidioc-querystd'><constant>VIDIOC_QUERYSTD</constant></link>">
<!ENTITY VIDIOC-QUERY-DV-PRESET "<link linkend='vidioc-query-dv-preset'><constant>VIDIOC_QUERY_DV_PRESET</constant></link>">
<!ENTITY VIDIOC-REQBUFS "<link linkend='vidioc-reqbufs'><constant>VIDIOC_REQBUFS</constant></link>">
<!ENTITY VIDIOC-STREAMOFF "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMOFF</constant></link>">
<!ENTITY VIDIOC-STREAMON "<link linkend='vidioc-streamon'><constant>VIDIOC_STREAMON</constant></link>">
@ -60,6 +64,8 @@
<!ENTITY VIDIOC-S-AUDOUT "<link linkend='vidioc-g-audioout'><constant>VIDIOC_S_AUDOUT</constant></link>">
<!ENTITY VIDIOC-S-CROP "<link linkend='vidioc-g-crop'><constant>VIDIOC_S_CROP</constant></link>">
<!ENTITY VIDIOC-S-CTRL "<link linkend='vidioc-g-ctrl'><constant>VIDIOC_S_CTRL</constant></link>">
<!ENTITY VIDIOC-S-DV-PRESET "<link linkend='vidioc-g-dv-preset'><constant>VIDIOC_S_DV_PRESET</constant></link>">
<!ENTITY VIDIOC-S-DV-TIMINGS "<link linkend='vidioc-g-dv-timings'><constant>VIDIOC_S_DV_TIMINGS</constant></link>">
<!ENTITY VIDIOC-S-EXT-CTRLS "<link linkend='vidioc-g-ext-ctrls'><constant>VIDIOC_S_EXT_CTRLS</constant></link>">
<!ENTITY VIDIOC-S-FBUF "<link linkend='vidioc-g-fbuf'><constant>VIDIOC_S_FBUF</constant></link>">
<!ENTITY VIDIOC-S-FMT "<link linkend='vidioc-g-fmt'><constant>VIDIOC_S_FMT</constant></link>">
@ -118,6 +124,7 @@
<!-- Structures -->
<!ENTITY v4l2-audio "struct&nbsp;<link linkend='v4l2-audio'>v4l2_audio</link>">
<!ENTITY v4l2-audioout "struct&nbsp;<link linkend='v4l2-audioout'>v4l2_audioout</link>">
<!ENTITY v4l2-bt-timings "struct&nbsp;<link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>">
<!ENTITY v4l2-buffer "struct&nbsp;<link linkend='v4l2-buffer'>v4l2_buffer</link>">
<!ENTITY v4l2-capability "struct&nbsp;<link linkend='v4l2-capability'>v4l2_capability</link>">
<!ENTITY v4l2-captureparm "struct&nbsp;<link linkend='v4l2-captureparm'>v4l2_captureparm</link>">
@ -128,6 +135,9 @@
<!ENTITY v4l2-dbg-chip-ident "struct&nbsp;<link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link>">
<!ENTITY v4l2-dbg-match "struct&nbsp;<link linkend='v4l2-dbg-match'>v4l2_dbg_match</link>">
<!ENTITY v4l2-dbg-register "struct&nbsp;<link linkend='v4l2-dbg-register'>v4l2_dbg_register</link>">
<!ENTITY v4l2-dv-enum-preset "struct&nbsp;<link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link>">
<!ENTITY v4l2-dv-preset "struct&nbsp;<link linkend='v4l2-dv-preset'>v4l2_dv_preset</link>">
<!ENTITY v4l2-dv-timings "struct&nbsp;<link linkend='v4l2-dv-timings'>v4l2_dv_timings</link>">
<!ENTITY v4l2-enc-idx "struct&nbsp;<link linkend='v4l2-enc-idx'>v4l2_enc_idx</link>">
<!ENTITY v4l2-enc-idx-entry "struct&nbsp;<link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link>">
<!ENTITY v4l2-encoder-cmd "struct&nbsp;<link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link>">
@ -243,6 +253,10 @@
<!ENTITY sub-enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml">
<!ENTITY sub-enuminput SYSTEM "v4l/vidioc-enuminput.xml">
<!ENTITY sub-enumoutput SYSTEM "v4l/vidioc-enumoutput.xml">
<!ENTITY sub-enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml">
<!ENTITY sub-g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml">
<!ENTITY sub-query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml">
<!ENTITY sub-g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml">
<!ENTITY sub-enumstd SYSTEM "v4l/vidioc-enumstd.xml">
<!ENTITY sub-g-audio SYSTEM "v4l/vidioc-g-audio.xml">
<!ENTITY sub-g-audioout SYSTEM "v4l/vidioc-g-audioout.xml">
@ -280,7 +294,7 @@
<!ENTITY sub-v4l2 SYSTEM "v4l/v4l2.xml">
<!ENTITY sub-intro SYSTEM "dvb/intro.xml">
<!ENTITY sub-frontend SYSTEM "dvb/frontend.xml">
<!ENTITY sub-isdbt SYSTEM "dvb/isdbt.xml">
<!ENTITY sub-dvbproperty SYSTEM "dvb/dvbproperty.xml">
<!ENTITY sub-demux SYSTEM "dvb/demux.xml">
<!ENTITY sub-video SYSTEM "dvb/video.xml">
<!ENTITY sub-audio SYSTEM "dvb/audio.xml">
@ -288,6 +302,7 @@
<!ENTITY sub-net SYSTEM "dvb/net.xml">
<!ENTITY sub-kdapi SYSTEM "dvb/kdapi.xml">
<!ENTITY sub-examples SYSTEM "dvb/examples.xml">
<!ENTITY sub-frontend-h SYSTEM "dvb/frontend.h.xml">
<!ENTITY sub-dvbapi SYSTEM "dvb/dvbapi.xml">
<!ENTITY sub-media SYSTEM "media.xml">
<!ENTITY sub-media-entities SYSTEM "media-entities.tmpl">
@ -332,6 +347,10 @@
<!ENTITY enumaudioout SYSTEM "v4l/vidioc-enumaudioout.xml">
<!ENTITY enuminput SYSTEM "v4l/vidioc-enuminput.xml">
<!ENTITY enumoutput SYSTEM "v4l/vidioc-enumoutput.xml">
<!ENTITY enum-dv-presets SYSTEM "v4l/vidioc-enum-dv-presets.xml">
<!ENTITY g-dv-preset SYSTEM "v4l/vidioc-g-dv-preset.xml">
<!ENTITY query-dv-preset SYSTEM "v4l/vidioc-query-dv-preset.xml">
<!ENTITY g-dv-timings SYSTEM "v4l/vidioc-g-dv-timings.xml">
<!ENTITY enumstd SYSTEM "v4l/vidioc-enumstd.xml">
<!ENTITY g-audio SYSTEM "v4l/vidioc-g-audio.xml">
<!ENTITY g-audioout SYSTEM "v4l/vidioc-g-audioout.xml">

4
Documentation/DocBook/media-indices.tmpl
View File

@ -36,6 +36,7 @@
<indexentry><primaryie>enum&nbsp;<link linkend='v4l2-preemphasis'>v4l2_preemphasis</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-audio'>v4l2_audio</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-audioout'>v4l2_audioout</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-bt-timings'>v4l2_bt_timings</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-buffer'>v4l2_buffer</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-capability'>v4l2_capability</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-captureparm'>v4l2_captureparm</link></primaryie></indexentry>
@ -46,6 +47,9 @@
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dbg-match'>v4l2_dbg_match</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dbg-register'>v4l2_dbg_register</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dv-preset'>v4l2_dv_preset</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-dv-timings'>v4l2_dv_timings</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-enc-idx'>v4l2_enc_idx</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link></primaryie></indexentry>
<indexentry><primaryie>struct&nbsp;<link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link></primaryie></indexentry>

14
Documentation/DocBook/mtdnand.tmpl
View File

@ -174,7 +174,7 @@
</para>
<programlisting>
static struct mtd_info *board_mtd;
static unsigned long baseaddr;
static void __iomem *baseaddr;
</programlisting>
<para>
Static example
@ -182,7 +182,7 @@ static unsigned long baseaddr;
<programlisting>
static struct mtd_info board_mtd;
static struct nand_chip board_chip;
static unsigned long baseaddr;
static void __iomem *baseaddr;
</programlisting>
</sect1>
<sect1 id="Partition_defines">
@ -283,8 +283,8 @@ int __init board_init (void)
}
/* map physical address */
baseaddr = (unsigned long)ioremap(CHIP_PHYSICAL_ADDRESS, 1024);
if(!baseaddr){
baseaddr = 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((void *)baseaddr);
iounmap(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((void *)baseaddr);
iounmap(baseaddr);
/* Free the MTD device structure */
kfree (board_mtd);
@ -362,7 +362,7 @@ module_exit(board_cleanup);
<sect1 id="Multiple_chip_control">
<title>Multiple chip control</title>
<para>
The nand driver can control chip arrays. Therefor the
The nand driver can control chip arrays. Therefore the
board driver must provide an own select_chip function. This
function must (de)select the requested chip.
The function pointer in the nand_chip structure must

626
Documentation/DocBook/procfs-guide.tmpl
View File

@ -1,626 +0,0 @@
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" [
<!ENTITY procfsexample SYSTEM "procfs_example.xml">
]>
<book id="LKProcfsGuide">
<bookinfo>
<title>Linux Kernel Procfs Guide</title>
<authorgroup>
<author>
<firstname>Erik</firstname>
<othername>(J.A.K.)</othername>
<surname>Mouw</surname>
<affiliation>
<address>
<email>mouw@nl.linux.org</email>
</address>
</affiliation>
</author>
<othercredit>
<contrib>
This software and documentation were written while working on the
LART computing board
(<ulink url="http://www.lartmaker.nl/">http://www.lartmaker.nl/</ulink>),
which was sponsored by the Delt University of Technology projects
Mobile Multi-media Communications and Ubiquitous Communications.
</contrib>
</othercredit>
</authorgroup>
<revhistory>
<revision>
<revnumber>1.0</revnumber>
<date>May 30, 2001</date>
<revremark>Initial revision posted to linux-kernel</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>June 3, 2001</date>
<revremark>Revised after comments from linux-kernel</revremark>
</revision>
</revhistory>
<copyright>
<year>2001</year>
<holder>Erik Mouw</holder>
</copyright>
<legalnotice>
<para>
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.
</para>
<para>
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.
</para>
<para>
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
</para>
<para>
For more details see the file COPYING in the source
distribution of Linux.
</para>
</legalnotice>
</bookinfo>
<toc>
</toc>
<preface id="Preface">
<title>Preface</title>
<para>
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 <ulink
url="http://www.kernelnewbies.org/">http://www.kernelnewbies.org/</ulink>),
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.
</para>
<para>
I'd like to thank Jeff Garzik
<email>jgarzik@pobox.com</email> and Alexander Viro
<email>viro@parcelfarce.linux.theplanet.co.uk</email> for their input,
Tim Waugh <email>twaugh@redhat.com</email> for his <ulink
url="http://people.redhat.com/twaugh/docbook/selfdocbook/">Selfdocbook</ulink>,
and Marc Joosen <email>marcj@historia.et.tudelft.nl</email> for
proofreading.
</para>
<para>
Erik
</para>
</preface>
<chapter id="intro">
<title>Introduction</title>
<para>
The <filename class="directory">/proc</filename> 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 <filename
class="directory">/proc/[0-9]+/</filename>), but also for debug
purposes (like <filename>/proc/ksyms</filename>).
</para>
<para>
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.
</para>
<para>
Note that the files in <filename
class="directory">/proc/sys</filename> are sysctl files: they
don't belong to procfs and are governed by a completely
different API described in the Kernel API book.
</para>
</chapter>
<chapter id="managing">
<title>Managing procfs entries</title>
<para>
This chapter describes the functions that various kernel
components use to populate the procfs with files, symlinks,
device nodes, and directories.
</para>
<para>
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:
</para>
<programlisting>
#include &lt;linux/proc_fs.h&gt;
</programlisting>
<sect1 id="regularfile">
<title>Creating a regular file</title>
<funcsynopsis>
<funcprototype>
<funcdef>struct proc_dir_entry* <function>create_proc_entry</function></funcdef>
<paramdef>const char* <parameter>name</parameter></paramdef>
<paramdef>mode_t <parameter>mode</parameter></paramdef>
<paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
This function creates a regular file with the name
<parameter>name</parameter>, file mode
<parameter>mode</parameter> in the directory
<parameter>parent</parameter>. To create a file in the root of
the procfs, use <constant>NULL</constant> as
<parameter>parent</parameter> parameter. When successful, the
function will return a pointer to the freshly created
<structname>struct proc_dir_entry</structname>; otherwise it
will return <constant>NULL</constant>. <xref
linkend="userland"/> describes how to do something useful with
regular files.
</para>
<para>
Note that it is specifically supported that you can pass a
path that spans multiple directories. For example
<function>create_proc_entry</function>(<parameter>"drivers/via0/info"</parameter>)
will create the <filename class="directory">via0</filename>
directory if necessary, with standard
<constant>0755</constant> permissions.
</para>
<para>
If you only want to be able to read the file, the function
<function>create_proc_read_entry</function> described in <xref
linkend="convenience"/> may be used to create and initialise
the procfs entry in one single call.
</para>
</sect1>
<sect1 id="Creating_a_symlink">
<title>Creating a symlink</title>
<funcsynopsis>
<funcprototype>
<funcdef>struct proc_dir_entry*
<function>proc_symlink</function></funcdef> <paramdef>const
char* <parameter>name</parameter></paramdef>
<paramdef>struct proc_dir_entry*
<parameter>parent</parameter></paramdef> <paramdef>const
char* <parameter>dest</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
This creates a symlink in the procfs directory
<parameter>parent</parameter> that points from
<parameter>name</parameter> to
<parameter>dest</parameter>. This translates in userland to
<literal>ln -s</literal> <parameter>dest</parameter>
<parameter>name</parameter>.
</para>
</sect1>
<sect1 id="Creating_a_directory">
<title>Creating a directory</title>
<funcsynopsis>
<funcprototype>
<funcdef>struct proc_dir_entry* <function>proc_mkdir</function></funcdef>
<paramdef>const char* <parameter>name</parameter></paramdef>
<paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
Create a directory <parameter>name</parameter> in the procfs
directory <parameter>parent</parameter>.
</para>
</sect1>
<sect1 id="Removing_an_entry">
<title>Removing an entry</title>
<funcsynopsis>
<funcprototype>
<funcdef>void <function>remove_proc_entry</function></funcdef>
<paramdef>const char* <parameter>name</parameter></paramdef>
<paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
Removes the entry <parameter>name</parameter> in the directory
<parameter>parent</parameter> from the procfs. Entries are
removed by their <emphasis>name</emphasis>, not by the
<structname>struct proc_dir_entry</structname> returned by the
various create functions. Note that this function doesn't
recursively remove entries.
</para>
<para>
Be sure to free the <structfield>data</structfield> entry from
the <structname>struct proc_dir_entry</structname> before
<function>remove_proc_entry</function> is called (that is: if
there was some <structfield>data</structfield> allocated, of
course). See <xref linkend="usingdata"/> for more information
on using the <structfield>data</structfield> entry.
</para>
</sect1>
</chapter>
<chapter id="userland">
<title>Communicating with userland</title>
<para>
Instead of reading (or writing) information directly from
kernel memory, procfs works with <emphasis>call back
functions</emphasis> 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 <structfield>read_proc</structfield> and/or
<structfield>write_proc</structfield> fields in the
<structname>struct proc_dir_entry*</structname> that the
function <function>create_proc_entry</function> returned:
</para>
<programlisting>
struct proc_dir_entry* entry;
entry->read_proc = read_proc_foo;
entry->write_proc = write_proc_foo;
</programlisting>
<para>
If you only want to use a the
<structfield>read_proc</structfield>, the function
<function>create_proc_read_entry</function> described in <xref
linkend="convenience"/> may be used to create and initialise the
procfs entry in one single call.
</para>
<sect1 id="Reading_data">
<title>Reading data</title>
<para>
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:
</para>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>read_func</function></funcdef>
<paramdef>char* <parameter>buffer</parameter></paramdef>
<paramdef>char** <parameter>start</parameter></paramdef>
<paramdef>off_t <parameter>off</parameter></paramdef>
<paramdef>int <parameter>count</parameter></paramdef>
<paramdef>int* <parameter>peof</parameter></paramdef>
<paramdef>void* <parameter>data</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
The read function should write its information into the
<parameter>buffer</parameter>, which will be exactly
<literal>PAGE_SIZE</literal> bytes long.
</para>
<para>
The parameter
<parameter>peof</parameter> should be used to signal that the
end of the file has been reached by writing
<literal>1</literal> to the memory location
<parameter>peof</parameter> points to.
</para>
<para>
The <parameter>data</parameter>
parameter can be used to create a single call back function for
several files, see <xref linkend="usingdata"/>.
</para>
<para>
The rest of the parameters and the return value are described
by a comment in <filename>fs/proc/generic.c</filename> as follows:
</para>
<blockquote>
<para>
You have three ways to return data:
</para>
<orderedlist>
<listitem>
<para>
Leave <literal>*start = NULL</literal>. (This is the default.)
Put the data of the requested offset at that
offset within the buffer. Return the number (<literal>n</literal>)
of bytes there are from the beginning of the
buffer up to the last byte of data. If the
number of supplied bytes (<literal>= n - offset</literal>) 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.
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> 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 <literal>*start</literal>. 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)
</para>
</listitem>
<listitem>
<para>
Set <literal>*start</literal> to an address within the buffer.
Put the data of the requested offset at <literal>*start</literal>.
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.
</para>
</listitem>
</orderedlist>
</blockquote>
<para>
<xref linkend="example"/> shows how to use a read call back
function.
</para>
</sect1>
<sect1 id="Writing_data">
<title>Writing data</title>
<para>
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:
</para>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>write_func</function></funcdef>
<paramdef>struct file* <parameter>file</parameter></paramdef>
<paramdef>const char* <parameter>buffer</parameter></paramdef>
<paramdef>unsigned long <parameter>count</parameter></paramdef>
<paramdef>void* <parameter>data</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
The write function should read <parameter>count</parameter>
bytes at maximum from the <parameter>buffer</parameter>. Note
that the <parameter>buffer</parameter> doesn't live in the
kernel's memory space, so it should first be copied to kernel
space with <function>copy_from_user</function>. The
<parameter>file</parameter> parameter is usually
ignored. <xref linkend="usingdata"/> shows how to use the
<parameter>data</parameter> parameter.
</para>
<para>
Again, <xref linkend="example"/> shows how to use this call back
function.
</para>
</sect1>
<sect1 id="usingdata">
<title>A single call back for many files</title>
<para>
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
<structfield>data</structfield> field in <structname>struct
proc_dir_entry</structname>. First of all, the
<structfield>data</structfield> field has to be initialised:
</para>
<programlisting>
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;
</programlisting>
<para>
The <structfield>data</structfield> field is a <type>void
*</type>, so it can be initialised with anything.
</para>
<para>
Now that the <structfield>data</structfield> field is set, the
<function>read_proc</function> and
<function>write_proc</function> can use it to distinguish
between files because they get it passed into their
<parameter>data</parameter> parameter:
</para>
<programlisting>
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;
}
</programlisting>
<para>
Be sure to free the <structfield>data</structfield> data field
when removing the procfs entry.
</para>
</sect1>
</chapter>
<chapter id="tips">
<title>Tips and tricks</title>
<sect1 id="convenience">
<title>Convenience functions</title>
<funcsynopsis>
<funcprototype>
<funcdef>struct proc_dir_entry* <function>create_proc_read_entry</function></funcdef>
<paramdef>const char* <parameter>name</parameter></paramdef>
<paramdef>mode_t <parameter>mode</parameter></paramdef>
<paramdef>struct proc_dir_entry* <parameter>parent</parameter></paramdef>
<paramdef>read_proc_t* <parameter>read_proc</parameter></paramdef>
<paramdef>void* <parameter>data</parameter></paramdef>
</funcprototype>
</funcsynopsis>
<para>
This function creates a regular file in exactly the same way
as <function>create_proc_entry</function> from <xref
linkend="regularfile"/> does, but also allows to set the read
function <parameter>read_proc</parameter> in one call. This
function can set the <parameter>data</parameter> as well, like
explained in <xref linkend="usingdata"/>.
</para>
</sect1>
<sect1 id="Modules">
<title>Modules</title>
<para>
If procfs is being used from within a module, be sure to set
the <structfield>owner</structfield> field in the
<structname>struct proc_dir_entry</structname> to
<constant>THIS_MODULE</constant>.
</para>
<programlisting>
struct proc_dir_entry* entry;
entry->owner = THIS_MODULE;
</programlisting>
</sect1>
<sect1 id="Mode_and_ownership">
<title>Mode and ownership</title>
<para>
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:
</para>
<programlisting>
struct proc_dir_entry* entry;
entry->mode = S_IWUSR |S_IRUSR | S_IRGRP | S_IROTH;
entry->uid = 0;
entry->gid = 100;
</programlisting>
</sect1>
</chapter>
<chapter id="example">
<title>Example</title>
<!-- be careful with the example code: it shouldn't be wider than
approx. 60 columns, or otherwise it won't fit properly on a page
-->
&procfsexample;
</chapter>
</book>

201
Documentation/DocBook/procfs_example.c
View File

@ -1,201 +0,0 @@
/*
* 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 <linux/module.h>
#include <linux/kernel.h>
#include <linux/init.h>
#include <linux/proc_fs.h>
#include <linux/jiffies.h>
#include <asm/uaccess.h>
#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");

35
Documentation/DocBook/v4l/common.xml
View File

@ -716,6 +716,41 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &amp;std_id)) {
}
</programlisting>
</example>
<section id="dv-timings">
<title>Digital Video (DV) Timings</title>
<para>
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: </para><itemizedlist>
<listitem>
<para>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.</para>
</listitem>
<listitem>
<para>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.
</para>
</listitem>
</itemizedlist>
<para>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.</para>
<para>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.</para>
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to decide what ioctls are available to set the
video timings for the device.</para>
</section>
</section>
&sub-controls;

16
Documentation/DocBook/v4l/compat.xml
View File

@ -2291,8 +2291,8 @@ was renamed to <structname id="v4l2-chip-ident-old">v4l2_chip_ident_old</structn
<listitem>
<para>New control <constant>V4L2_CID_COLORFX</constant> was added.</para>
</listitem>
</orderedlist>
</section>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 2.6.32</title>
<orderedlist>
@ -2322,8 +2322,16 @@ more information.</para>
<listitem>
<para>Added Remote Controller chapter, describing the default Remote Controller mapping for media devices.</para>
</listitem>
</orderedlist>
</section>
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 2.6.33</title>
<orderedlist>
<listitem>
<para>Added support for Digital Video timings in order to support HDTV receivers and transmitters.</para>
</listitem>
</orderedlist>
</section>
</section>
<section id="other">

20
Documentation/DocBook/v4l/controls.xml
View File

@ -280,11 +280,29 @@ minimum value disables backlight compensation.</entry>
<constant>V4L2_COLORFX_BW</constant> (1) and
<constant>V4L2_COLORFX_SEPIA</constant> (2).</entry>
</row>
<row>
<entry><constant>V4L2_CID_ROTATE</constant></entry>
<entry>integer</entry>
<entry>Rotates the image by specified angle. Common angles are 90,
270 and 180. Rotating the image to 90 and 270 will reverse the height
and width of the display window. It is necessary to set the new height and
width of the picture using the &VIDIOC-S-FMT; ioctl according to
the rotation angle selected.</entry>
</row>
<row>
<entry><constant>V4L2_CID_BG_COLOR</constant></entry>
<entry>integer</entry>
<entry>Sets the background color on the current output device.
Background color needs to be specified in the RGB24 format. The
supplied 32 bit value is interpreted as bits 0-7 Red color information,
bits 8-15 Green color information, bits 16-23 Blue color
information and bits 24-31 must be zero.</entry>
</row>
<row>
<entry><constant>V4L2_CID_LASTP1</constant></entry>
<entry></entry>
<entry>End of the predefined control IDs (currently
<constant>V4L2_CID_COLORFX</constant> + 1).</entry>
<constant>V4L2_CID_BG_COLOR</constant> + 1).</entry>
</row>
<row>
<entry><constant>V4L2_CID_PRIVATE_BASE</constant></entry>

5
Documentation/DocBook/v4l/pixfmt.xml
View File

@ -770,6 +770,11 @@ kernel sources in the file <filename>Documentation/video4linux/cx2341x/README.hm
<entry>'S920'</entry>
<entry>YUV 4:2:0 format of the gspca sn9c20x driver.</entry>
</row>
<row id="V4L2-PIX-FMT-STV0680">
<entry><constant>V4L2_PIX_FMT_STV0680</constant></entry>
<entry>'S680'</entry>
<entry>Bayer format of the gspca stv0680 driver.</entry>
</row>
<row id="V4L2-PIX-FMT-WNVA">
<entry><constant>V4L2_PIX_FMT_WNVA</constant></entry>
<entry>'WNVA'</entry>

26
Documentation/DocBook/v4l/v4l2.xml
View File

@ -74,6 +74,17 @@ Remote Controller chapter.</contrib>
</address>
</affiliation>
</author>
<author>
<firstname>Muralidharan</firstname>
<surname>Karicheri</surname>
<contrib>Documented the Digital Video timings API.</contrib>
<affiliation>
<address>
<email>m-karicheri2@ti.com</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
@ -89,7 +100,7 @@ Remote Controller chapter.</contrib>
<year>2008</year>
<year>2009</year>
<holder>Bill Dirks, Michael H. Schimek, Hans Verkuil, Martin
Rubli, Andy Walls, Mauro Carvalho Chehab</holder>
Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab</holder>
</copyright>
<legalnotice>
<para>Except when explicitly stated as GPL, programming examples within
@ -102,6 +113,13 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.sgml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>2.6.33</revnumber>
<date>2009-12-03</date>
<authorinitials>mk</authorinitials>
<revremark>Added documentation for the Digital Video timings API.</revremark>
</revision>
<revision>
<revnumber>2.6.32</revnumber>
<date>2009-08-31</date>
@ -355,7 +373,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 2.6.32</subtitle>
<subtitle>Revision 2.6.33</subtitle>
<chapter id="common">
&sub-common;
@ -411,6 +429,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-encoder-cmd;
&sub-enumaudio;
&sub-enumaudioout;
&sub-enum-dv-presets;
&sub-enum-fmt;
&sub-enum-framesizes;
&sub-enum-frameintervals;
@ -421,6 +440,8 @@ and discussions on the V4L mailing list.</revremark>
&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;
@ -441,6 +462,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-querybuf;
&sub-querycap;
&sub-queryctrl;
&sub-query-dv-preset;
&sub-querystd;
&sub-reqbufs;
&sub-s-hw-freq-seek;

125
Documentation/DocBook/v4l/videodev2.h.xml
View File

@ -363,6 +363,7 @@ struct <link linkend="v4l2-pix-format">v4l2_pix_format</link> {
#define <link linkend="V4L2-PIX-FMT-OV511">V4L2_PIX_FMT_OV511</link> v4l2_fourcc('O', '5', '1', '1') /* ov511 JPEG */
#define <link linkend="V4L2-PIX-FMT-OV518">V4L2_PIX_FMT_OV518</link> v4l2_fourcc('O', '5', '1', '8') /* ov518 JPEG */
#define <link linkend="V4L2-PIX-FMT-TM6000">V4L2_PIX_FMT_TM6000</link> v4l2_fourcc('T', 'M', '6', '0') /* tm5600/tm60x0 */
#define <link linkend="V4L2-PIX-FMT-STV0680">V4L2_PIX_FMT_STV0680</link> v4l2_fourcc('S', '6', '8', '0') /* stv0680 bayer */
/*
* F O R M A T E N U M E R A T I O N
@ -492,7 +493,7 @@ struct <link linkend="v4l2-jpegcompression">v4l2_jpegcompression</link> {
* you do, leave them untouched.
* Inluding less markers will make the
* resulting code smaller, but there will
* be fewer aplications which can read it.
* be fewer applications which can read it.
* The presence of the APP and COM marker
* is influenced by APP_len and COM_len
* ONLY, not by this property! */
@ -565,6 +566,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
#define V4L2_FBUF_CAP_LOCAL_ALPHA 0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA 0x0040
#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@ -572,6 +574,7 @@ struct <link linkend="v4l2-framebuffer">v4l2_framebuffer</link> {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct <link linkend="v4l2-clip">v4l2_clip</link> {
struct <link linkend="v4l2-rect">v4l2_rect</link> c;
@ -730,6 +733,99 @@ struct <link linkend="v4l2-standard">v4l2_standard</link> {
__u32 reserved[4];
};
/*
* V I D E O T I M I N G S D V P R E S E T
*/
struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link> {
__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 <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link> {
__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 <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> {
__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-&gt;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 <link linkend="v4l2-dv-timings">v4l2_dv_timings</link> {
__u32 type;
union {
struct <link linkend="v4l2-bt-timings">v4l2_bt_timings</link> 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
*/
@ -741,7 +837,8 @@ struct <link linkend="v4l2-input">v4l2_input</link> {
__u32 tuner; /* Associated tuner */
v4l2_std_id std;
__u32 status;
__u32 reserved[4];
__u32 capabilities;
__u32 reserved[3];
};
/* Values for the 'type' field */
@ -772,6 +869,11 @@ struct <link linkend="v4l2-input">v4l2_input</link> {
#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
*/
@ -782,13 +884,19 @@ struct <link linkend="v4l2-output">v4l2_output</link> {
__u32 audioset; /* Associated audios (bitfield) */
__u32 modulator; /* Associated modulator */
v4l2_std_id std;
__u32 reserved[4];
__u32 capabilities;
__u32 reserved[3];
};
/* 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
*/
@ -914,8 +1022,10 @@ enum <link linkend="v4l2-colorfx">v4l2_colorfx</link> {
#define V4L2_CID_AUTOBRIGHTNESS (V4L2_CID_BASE+32)
#define V4L2_CID_BAND_STOP_FILTER (V4L2_CID_BASE+33)
#define V4L2_CID_ROTATE (V4L2_CID_BASE+34)
#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+35)
/* last CID + 1 */
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
#define V4L2_CID_LASTP1 (V4L2_CID_BASE+36)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
@ -1621,6 +1731,13 @@ struct <link linkend="v4l2-dbg-chip-ident">v4l2_dbg_chip_ident</link> {
#endif
#define VIDIOC_S_HW_FREQ_SEEK _IOW('V', 82, struct <link linkend="v4l2-hw-freq-seek">v4l2_hw_freq_seek</link>)
#define VIDIOC_ENUM_DV_PRESETS _IOWR('V', 83, struct <link linkend="v4l2-dv-enum-preset">v4l2_dv_enum_preset</link>)
#define VIDIOC_S_DV_PRESET _IOWR('V', 84, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
#define VIDIOC_G_DV_PRESET _IOWR('V', 85, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
#define VIDIOC_QUERY_DV_PRESET _IOR('V', 86, struct <link linkend="v4l2-dv-preset">v4l2_dv_preset</link>)
#define VIDIOC_S_DV_TIMINGS _IOWR('V', 87, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
#define VIDIOC_G_DV_TIMINGS _IOWR('V', 88, struct <link linkend="v4l2-dv-timings">v4l2_dv_timings</link>)
/* Reminder: when adding new ioctls please add support for them to
drivers/media/video/v4l2-compat-ioctl32.c as well! */

238
Documentation/DocBook/v4l/vidioc-enum-dv-presets.xml Normal file
View File

@ -0,0 +1,238 @@
<refentry id="vidioc-enum-dv-presets">
<refmeta>
<refentrytitle>ioctl VIDIOC_ENUM_DV_PRESETS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_ENUM_DV_PRESETS</refname>
<refpurpose>Enumerate supported Digital Video presets</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>struct v4l2_dv_enum_preset *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_ENUM_DV_PRESETS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To query the attributes of a DV preset, applications initialize the
<structfield>index</structfield> field and zero the reserved array of &v4l2-dv-enum-preset;
and call the <constant>VIDIOC_ENUM_DV_PRESETS</constant> 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 <errorcode>EINVAL</errorcode>. Drivers may enumerate a
different set of DV presets after switching the video input or
output.</para>
<table pgwide="1" frame="none" id="v4l2-dv-enum-preset">
<title>struct <structname>v4l2_dv_enum_presets</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the DV preset, set by the
application.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>preset</structfield></entry>
<entry>This field identifies one of the DV preset values listed in <xref linkend="v4l2-dv-presets-vals"/>.</entry>
</row>
<row>
<entry>__u8</entry>
<entry><structfield>name</structfield>[24]</entry>
<entry>Name of the preset, a NUL-terminated ASCII string, for example: "720P-60", "1080I-60". This information is
intended for the user.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Width of the active video in pixels for the DV preset.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Height of the active video in lines for the DV preset.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry>Reserved for future extensions. Drivers must set the array to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-dv-presets-vals">
<title>struct <structname>DV Presets</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>Preset</entry>
<entry>Preset value</entry>
<entry>Description</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>V4L2_DV_INVALID</entry>
<entry>0</entry>
<entry>Invalid preset value.</entry>
</row>
<row>
<entry>V4L2_DV_480P59_94</entry>
<entry>1</entry>
<entry>720x480 progressive video at 59.94 fps as per BT.1362.</entry>
</row>
<row>
<entry>V4L2_DV_576P50</entry>
<entry>2</entry>
<entry>720x576 progressive video at 50 fps as per BT.1362.</entry>
</row>
<row>
<entry>V4L2_DV_720P24</entry>
<entry>3</entry>
<entry>1280x720 progressive video at 24 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P25</entry>
<entry>4</entry>
<entry>1280x720 progressive video at 25 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P30</entry>
<entry>5</entry>
<entry>1280x720 progressive video at 30 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P50</entry>
<entry>6</entry>
<entry>1280x720 progressive video at 50 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_720P59_94</entry>
<entry>7</entry>
<entry>1280x720 progressive video at 59.94 fps as per SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_720P60</entry>
<entry>8</entry>
<entry>1280x720 progressive video at 60 fps as per SMPTE 274M/296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I29_97</entry>
<entry>9</entry>
<entry>1920x1080 interlaced video at 29.97 fps as per BT.1120/SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I30</entry>
<entry>10</entry>
<entry>1920x1080 interlaced video at 30 fps as per BT.1120/SMPTE 274M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I25</entry>
<entry>11</entry>
<entry>1920x1080 interlaced video at 25 fps as per BT.1120.</entry>
</row>
<row>
<entry>V4L2_DV_1080I50</entry>
<entry>12</entry>
<entry>1920x1080 interlaced video at 50 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080I60</entry>
<entry>13</entry>
<entry>1920x1080 interlaced video at 60 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P24</entry>
<entry>14</entry>
<entry>1920x1080 progressive video at 24 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P25</entry>
<entry>15</entry>
<entry>1920x1080 progressive video at 25 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P30</entry>
<entry>16</entry>
<entry>1920x1080 progressive video at 30 fps as per SMPTE 296M.</entry>
</row>
<row>
<entry>V4L2_DV_1080P50</entry>
<entry>17</entry>
<entry>1920x1080 progressive video at 50 fps as per BT.1120.</entry>
</row>
<row>
<entry>V4L2_DV_1080P60</entry>
<entry>18</entry>
<entry>1920x1080 progressive video at 60 fps as per BT.1120.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-dv-enum-preset; <structfield>index</structfield>
is out of bounds.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

36
Documentation/DocBook/v4l/vidioc-enuminput.xml
View File

@ -124,7 +124,13 @@ current input.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry><structfield>capabilities</structfield></entry>
<entry>This field provides capabilities for the
input. See <xref linkend="input-capabilities" /> for flags.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[3]</entry>
<entry>Reserved for future extensions. Drivers must set
the array to zero.</entry>
</row>
@ -261,6 +267,34 @@ flag is set Macrovision has been detected.</entry>
</tbody>
</tgroup>
</table>
<!-- Capability flags based on video timings RFC by Muralidharan
Karicheri, titled RFC (v1.2): V4L - Support for video timings at the
input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
-->
<table frame="none" pgwide="1" id="input-capabilities">
<title>Input capabilities</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_IN_CAP_PRESETS</constant></entry>
<entry>0x00000001</entry>
<entry>This input supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This input supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry>
</row>
<row>
<entry><constant>V4L2_IN_CAP_STD</constant></entry>
<entry>0x00000004</entry>
<entry>This input supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>

36
Documentation/DocBook/v4l/vidioc-enumoutput.xml
View File

@ -114,7 +114,13 @@ details on video standards and how to switch see <xref
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry><structfield>capabilities</structfield></entry>
<entry>This field provides capabilities for the
output. See <xref linkend="output-capabilities" /> for flags.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[3]</entry>
<entry>Reserved for future extensions. Drivers must set
the array to zero.</entry>
</row>
@ -147,6 +153,34 @@ CVBS, S-Video, RGB.</entry>
</tgroup>
</table>
<!-- Capabilities flags based on video timings RFC by Muralidharan
Karicheri, titled RFC (v1.2): V4L - Support for video timings at the
input/output interface to linux-media@vger.kernel.org on 19 Oct 2009.
-->
<table frame="none" pgwide="1" id="output-capabilities">
<title>Output capabilities</title>
<tgroup cols="3">
&cs-def;
<tbody valign="top">
<row>
<entry><constant>V4L2_OUT_CAP_PRESETS</constant></entry>
<entry>0x00000001</entry>
<entry>This output supports setting DV presets by using VIDIOC_S_DV_PRESET.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_CUSTOM_TIMINGS</constant></entry>
<entry>0x00000002</entry>
<entry>This output supports setting custom video timings by using VIDIOC_S_DV_TIMINGS.</entry>
</row>
<row>
<entry><constant>V4L2_OUT_CAP_STD</constant></entry>
<entry>0x00000004</entry>
<entry>This output supports setting the TV standard by using VIDIOC_S_STD.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;

111
Documentation/DocBook/v4l/vidioc-g-dv-preset.xml Normal file
View File

@ -0,0 +1,111 @@
<refentry id="vidioc-g-dv-preset">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_G_DV_PRESET</refname>
<refname>VIDIOC_S_DV_PRESET</refname>
<refpurpose>Query or select the DV preset of the current input or output</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-preset;
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_G_DV_PRESET, VIDIOC_S_DV_PRESET</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To query and select the current DV preset, applications
use the <constant>VIDIOC_G_DV_PRESET</constant> and <constant>VIDIOC_S_DV_PRESET</constant>
ioctls which take a pointer to a &v4l2-dv-preset; type as argument.
Applications must zero the reserved array in &v4l2-dv-preset;.
<constant>VIDIOC_G_DV_PRESET</constant> returns a dv preset in the field
<structfield>preset</structfield> of &v4l2-dv-preset;.</para>
<para><constant>VIDIOC_S_DV_PRESET</constant> 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; </para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>This ioctl is not supported, or the
<constant>VIDIOC_S_DV_PRESET</constant>,<constant>VIDIOC_S_DV_PRESET</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not change the preset.</para>
</listitem>
</varlistentry>
</variablelist>
<table pgwide="1" frame="none" id="v4l2-dv-preset">
<title>struct <structname>v4l2_dv_preset</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>preset</structfield></entry>
<entry>Preset value to represent the digital video timings</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[4]</structfield></entry>
<entry>Reserved fields for future use</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

224
Documentation/DocBook/v4l/vidioc-g-dv-timings.xml Normal file
View File

@ -0,0 +1,224 @@
<refentry id="vidioc-g-dv-timings">
<refmeta>
<refentrytitle>ioctl VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_G_DV_TIMINGS</refname>
<refname>VIDIOC_S_DV_TIMINGS</refname>
<refpurpose>Get or set custom DV timings for input or output</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-timings;
*<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_G_DV_TIMINGS, VIDIOC_S_DV_TIMINGS</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>To set custom DV timings for the input or output, applications use the
<constant>VIDIOC_S_DV_TIMINGS</constant> ioctl and to get the current custom timings,
applications use the <constant>VIDIOC_G_DV_TIMINGS</constant> 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;.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>This ioctl is not supported, or the
<constant>VIDIOC_S_DV_TIMINGS</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not change the timings.</para>
</listitem>
</varlistentry>
</variablelist>
<table pgwide="1" frame="none" id="v4l2-bt-timings">
<title>struct <structname>v4l2_bt_timings</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>width</structfield></entry>
<entry>Width of the active video in pixels</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>height</structfield></entry>
<entry>Height of the active video in lines</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>interlaced</structfield></entry>
<entry>Progressive (0) or interlaced (1)</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>polarities</structfield></entry>
<entry>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.</entry>
</row>
<row>
<entry>__u64</entry>
<entry><structfield>pixelclock</structfield></entry>
<entry>Pixel clock in Hz. Ex. 74.25MHz->74250000</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>hfrontporch</structfield></entry>
<entry>Horizontal front porch in pixels</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>hsync</structfield></entry>
<entry>Horizontal sync length in pixels</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>hbackporch</structfield></entry>
<entry>Horizontal back porch in pixels</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>vfrontporch</structfield></entry>
<entry>Vertical front porch in lines</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>vsync</structfield></entry>
<entry>Vertical sync length in lines</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>vbackporch</structfield></entry>
<entry>Vertical back porch in lines</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>il_vfrontporch</structfield></entry>
<entry>Vertical front porch in lines for bottom field of interlaced field formats</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>il_vsync</structfield></entry>
<entry>Vertical sync length in lines for bottom field of interlaced field formats</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>il_vbackporch</structfield></entry>
<entry>Vertical back porch in lines for bottom field of interlaced field formats</entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="v4l2-dv-timings">
<title>struct <structname>v4l2_dv_timings</structname></title>
<tgroup cols="4">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry></entry>
<entry>Type of DV timings as listed in <xref linkend="dv-timing-types"/>.</entry>
</row>
<row>
<entry>union</entry>
<entry><structfield></structfield></entry>
<entry></entry>
</row>
<row>
<entry></entry>
<entry>&v4l2-bt-timings;</entry>
<entry><structfield>bt</structfield></entry>
<entry>Timings defined by BT.656/1120 specifications</entry>
</row>
<row>
<entry></entry>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[32]</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>
<table pgwide="1" frame="none" id="dv-timing-types">
<title>DV Timing types</title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>Timing type</entry>
<entry>value</entry>
<entry>Description</entry>
</row>
<row>
<entry></entry>
<entry></entry>
<entry></entry>
</row>
<row>
<entry>V4L2_DV_BT_656_1120</entry>
<entry>0</entry>
<entry>BT.656/1120 timings</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

17
Documentation/DocBook/v4l/vidioc-g-fbuf.xml
View File

@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays.</entry>
inverted alpha channel of the framebuffer or VGA signal. Alpha
blending makes no sense for destructive overlays.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_CAP_SRC_CHROMAKEY</constant></entry>
<entry>0x0080</entry>
<entry>The device supports Source Chroma-keying. Framebuffer pixels
with the chroma-key colors are replaced by video pixels, which is exactly opposite of
<constant>V4L2_FBUF_CAP_CHROMAKEY</constant></entry>
</row>
</tbody>
</tgroup>
</table>
@ -411,6 +418,16 @@ images, but with an inverted alpha value. The blend function is:
output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The
actual alpha depth depends on the framebuffer pixel format.</entry>
</row>
<row>
<entry><constant>V4L2_FBUF_FLAG_SRC_CHROMAKEY</constant></entry>
<entry>0x0040</entry>
<entry>Use source chroma-keying. The source chroma-key color is
determined by the <structfield>chromakey</structfield> field of
&v4l2-window; and negotiated with the &VIDIOC-S-FMT; ioctl, see <xref
linkend="overlay" /> and <xref linkend="osd" />.
Both chroma-keying are mutual exclusive to each other, so same
<structfield>chromakey</structfield> field of &v4l2-window; is being used.</entry>
</row>
</tbody>
</tgroup>
</table>

6
Documentation/DocBook/v4l/vidioc-g-std.xml
View File

@ -86,6 +86,12 @@ standards.</para>
<constant>VIDIOC_S_STD</constant> parameter was unsuitable.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not change the standard</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

85
Documentation/DocBook/v4l/vidioc-query-dv-preset.xml Normal file
View File

@ -0,0 +1,85 @@
<refentry id="vidioc-query-dv-preset">
<refmeta>
<refentrytitle>ioctl VIDIOC_QUERY_DV_PRESET</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_QUERY_DV_PRESET</refname>
<refpurpose>Sense the DV preset received by the current
input</refpurpose>
</refnamediv>
<refsynopsisdiv>
<funcsynopsis>
<funcprototype>
<funcdef>int <function>ioctl</function></funcdef>
<paramdef>int <parameter>fd</parameter></paramdef>
<paramdef>int <parameter>request</parameter></paramdef>
<paramdef>&v4l2-dv-preset; *<parameter>argp</parameter></paramdef>
</funcprototype>
</funcsynopsis>
</refsynopsisdiv>
<refsect1>
<title>Arguments</title>
<variablelist>
<varlistentry>
<term><parameter>fd</parameter></term>
<listitem>
<para>&fd;</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>request</parameter></term>
<listitem>
<para>VIDIOC_QUERY_DV_PRESET</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<para>The hardware may be able to detect the current DV preset
automatically, similar to sensing the video standard. To do so, applications
call <constant> VIDIOC_QUERY_DV_PRESET</constant> 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.</para>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>This ioctl is not supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not sense the preset</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>
<!--
Local Variables:
mode: sgml
sgml-parent-document: "v4l2.sgml"
indent-tabs-mode: nil
End:
-->

6
Documentation/DocBook/v4l/vidioc-querystd.xml
View File

@ -70,6 +70,12 @@ current video input or output.</para>
<para>This ioctl is not supported.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><errorcode>EBUSY</errorcode></term>
<listitem>
<para>The device is busy and therefore can not detect the standard</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

2
Documentation/DocBook/writing-an-alsa-driver.tmpl
View File

@ -5318,7 +5318,7 @@ struct _snd_pcm_runtime {
pages of the given size and map them onto the virtually contiguous
memory. The virtual pointer is addressed in runtime-&gt;dma_area.
The physical address (runtime-&gt;dma_addr) is set to zero,
because the buffer is physically non-contigous.
because the buffer is physically non-contiguous.
The physical address table is set up in sgbuf-&gt;table.
You can get the physical address at a certain offset via
<function>snd_pcm_sgbuf_get_addr()</function>.

2
Documentation/IO-mapping.txt
View File

@ -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.
*/
char * baseptr = ioremap(0xFC000000, 1024*1024);
void __iomem *baseptr = ioremap(0xFC000000, 1024*1024);
/* write a 'A' to the offset 10 of the area */
writeb('A',baseptr+10);

6
Documentation/DMA-mapping.txt → Documentation/PCI/PCI-DMA-mapping.txt
View File

@ -214,7 +214,7 @@ most specific mask.
Here is pseudo-code showing how this might be done:
#define PLAYBACK_ADDRESS_BITS DMA_BIT_MASK(32)
#define RECORD_ADDRESS_BITS 0x00ffffff
#define RECORD_ADDRESS_BITS DMA_BIT_MASK(24)
struct my_sound_card *card;
struct pci_dev *pdev;
@ -224,14 +224,14 @@ Here is pseudo-code showing how this might be done:
card->playback_enabled = 1;
} else {
card->playback_enabled = 0;
printk(KERN_WARN "%s: Playback disabled due to DMA limitations.\n",
printk(KERN_WARNING "%s: Playback disabled due to DMA limitations.\n",
card->name);
}
if (!pci_set_dma_mask(pdev, RECORD_ADDRESS_BITS)) {
card->record_enabled = 1;
} else {
card->record_enabled = 0;
printk(KERN_WARN "%s: Record disabled due to DMA limitations.\n",
printk(KERN_WARNING "%s: Record disabled due to DMA limitations.\n",
card->name);
}

5
Documentation/SubmitChecklist
View File

@ -15,7 +15,7 @@ kernel patches.
2: Passes allnoconfig, allmodconfig
3: Builds on multiple CPU architectures by using local cross-compile tools
or something like PLM at OSDL.
or some other build farm.
4: ppc64 is a good architecture for cross-compilation checking because it
tends to use `unsigned long' for 64-bit quantities.
@ -88,3 +88,6 @@ 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.

66
Documentation/acpi/method-customizing.txt Normal file
View File

@ -0,0 +1,66 @@
Linux ACPI Custom Control Method How To
=======================================
Written by Zhang Rui <rui.zhang@intel.com>
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.

317
Documentation/arm/OMAP/DSS Normal file
View File

@ -0,0 +1,317 @@
OMAP2/3 Display Subsystem
-------------------------
This is an almost total rewrite of the OMAP FB driver in drivers/video/omap
(let's call it DSS1). The main differences between DSS1 and DSS2 are DSI,
TV-out and multiple display support, but there are lots of small improvements
also.
The DSS2 driver (omapdss module) is in arch/arm/plat-omap/dss/, and the FB,
panel and controller drivers are in drivers/video/omap2/. DSS1 and DSS2 live
currently side by side, you can choose which one to use.
Features
--------
Working and tested features include:
- MIPI DPI (parallel) output
- MIPI DSI output in command mode
- MIPI DBI (RFBI) output
- SDI output
- TV output
- All pieces can be compiled as a module or inside kernel
- Use DISPC to update any of the outputs
- Use CPU to update RFBI or DSI output
- OMAP DISPC planes
- RGB16, RGB24 packed, RGB24 unpacked
- YUV2, UYVY
- Scaling
- Adjusting DSS FCK to find a good pixel clock
- Use DSI DPLL to create DSS FCK
Tested boards include:
- OMAP3 SDP board
- Beagle board
- N810
omapdss driver
--------------
The DSS driver does not itself have any support for Linux framebuffer, V4L or
such like the current ones, but it has an internal kernel API that upper level
drivers can use.
The DSS driver models OMAP's overlays, overlay managers and displays in a
flexible way to enable non-common multi-display configuration. In addition to
modelling the hardware overlays, omapdss supports virtual overlays and overlay
managers. These can be used when updating a display with CPU or system DMA.
Panel and controller drivers
----------------------------
The drivers implement panel or controller specific functionality and are not
usually visible to users except through omapfb driver. They register
themselves to the DSS driver.
omapfb driver
-------------
The omapfb driver implements arbitrary number of standard linux framebuffers.
These framebuffers can be routed flexibly to any overlays, thus allowing very
dynamic display architecture.
The driver exports some omapfb specific ioctls, which are compatible with the
ioctls in the old driver.
The rest of the non standard features are exported via sysfs. Whether the final
implementation will use sysfs, or ioctls, is still open.
V4L2 drivers
------------
V4L2 is being implemented in TI.
From omapdss point of view the V4L2 drivers should be similar to framebuffer
driver.
Architecture
--------------------
Some clarification what the different components do:
- Framebuffer is a memory area inside OMAP's SRAM/SDRAM that contains the
pixel data for the image. Framebuffer has width and height and color
depth.
- Overlay defines where the pixels are read from and where they go on the
screen. The overlay may be smaller than framebuffer, thus displaying only
part of the framebuffer. The position of the overlay may be changed if
the overlay is smaller than the display.
- Overlay manager combines the overlays in to one image and feeds them to
display.
- Display is the actual physical display device.
A framebuffer can be connected to multiple overlays to show the same pixel data
on all of the overlays. Note that in this case the overlay input sizes must be
the same, but, in case of video overlays, the output size can be different. Any
framebuffer can be connected to any overlay.
An overlay can be connected to one overlay manager. Also DISPC overlays can be
connected only to DISPC overlay managers, and virtual overlays can be only
connected to virtual overlays.
An overlay manager can be connected to one display. There are certain
restrictions which kinds of displays an overlay manager can be connected:
- DISPC TV overlay manager can be only connected to TV display.
- Virtual overlay managers can only be connected to DBI or DSI displays.
- DISPC LCD overlay manager can be connected to all displays, except TV
display.
Sysfs
-----
The sysfs interface is mainly used for testing. I don't think sysfs
interface is the best for this in the final version, but I don't quite know
what would be the best interfaces for these things.
The sysfs interface is divided to two parts: DSS and FB.
/sys/class/graphics/fb? directory:
mirror 0=off, 1=on
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
rotate_type 0 = DMA rotation, 1 = VRFB rotation
overlays List of overlay numbers to which framebuffer pixels go
phys_addr Physical address of the framebuffer
virt_addr Virtual address of the framebuffer
size Size of the framebuffer
/sys/devices/platform/omapdss/overlay? directory:
enabled 0=off, 1=on
input_size width,height (ie. the framebuffer size)
manager Destination overlay manager name
name
output_size width,height
position x,y
screen_width width
global_alpha global alpha 0-255 0=transparent 255=opaque
/sys/devices/platform/omapdss/manager? directory:
display Destination display
name
alpha_blending_enabled 0=off, 1=on
trans_key_enabled 0=off, 1=on
trans_key_type gfx-destination, video-source
trans_key_value transparency color key (RGB24)
default_color default background color (RGB24)
/sys/devices/platform/omapdss/display? directory:
ctrl_name Controller name
mirror 0=off, 1=on
update_mode 0=off, 1=auto, 2=manual
enabled 0=off, 1=on
name
rotate Rotation 0-3 for 0, 90, 180, 270 degrees
timings Display timings (pixclock,xres/hfp/hbp/hsw,yres/vfp/vbp/vsw)
When writing, two special timings are accepted for tv-out:
"pal" and "ntsc"
panel_name
tear_elim Tearing elimination 0=off, 1=on
There are also some debugfs files at <debugfs>/omapdss/ which show information
about clocks and registers.
Examples
--------
The following definitions have been made for the examples below:
ovl0=/sys/devices/platform/omapdss/overlay0
ovl1=/sys/devices/platform/omapdss/overlay1
ovl2=/sys/devices/platform/omapdss/overlay2
mgr0=/sys/devices/platform/omapdss/manager0
mgr1=/sys/devices/platform/omapdss/manager1
lcd=/sys/devices/platform/omapdss/display0
dvi=/sys/devices/platform/omapdss/display1
tv=/sys/devices/platform/omapdss/display2
fb0=/sys/class/graphics/fb0
fb1=/sys/class/graphics/fb1
fb2=/sys/class/graphics/fb2
Default setup on OMAP3 SDP
--------------------------
Here's the default setup on OMAP3 SDP board. All planes go to LCD. DVI
and TV-out are not in use. The columns from left to right are:
framebuffers, overlays, overlay managers, displays. Framebuffers are
handled by omapfb, and the rest by the DSS.
FB0 --- GFX -\ DVI
FB1 --- VID1 --+- LCD ---- LCD
FB2 --- VID2 -/ TV ----- TV
Example: Switch from LCD to DVI
----------------------
w=`cat $dvi/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $dvi/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $lcd/enabled
echo "" > $mgr0/display
fbset -fb /dev/fb0 -xres $w -yres $h -vxres $w -vyres $h
# at this point you have to switch the dvi/lcd dip-switch from the omap board
echo "dvi" > $mgr0/display
echo "1" > $dvi/enabled
After this the configuration looks like:
FB0 --- GFX -\ -- DVI
FB1 --- VID1 --+- LCD -/ LCD
FB2 --- VID2 -/ TV ----- TV
Example: Clone GFX overlay to LCD and TV
-------------------------------
w=`cat $tv/timings | cut -d "," -f 2 | cut -d "/" -f 1`
h=`cat $tv/timings | cut -d "," -f 3 | cut -d "/" -f 1`
echo "0" > $ovl0/enabled
echo "0" > $ovl1/enabled
echo "" > $fb1/overlays
echo "0,1" > $fb0/overlays
echo "$w,$h" > $ovl1/output_size
echo "tv" > $ovl1/manager
echo "1" > $ovl0/enabled
echo "1" > $ovl1/enabled
echo "1" > $tv/enabled
After this the configuration looks like (only relevant parts shown):
FB0 +-- GFX ---- LCD ---- LCD
\- VID1 ---- TV ---- TV
Misc notes
----------
OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
Rotation and mirroring currently only supports RGB565 and RGB8888 modes. VRFB
does not support mirroring.
VRFB rotation requires much more memory than non-rotated framebuffer, so you
probably need to increase your vram setting before using VRFB rotation. Also,
many applications may not work with VRFB if they do not pay attention to all
framebuffer parameters.
Kernel boot arguments
---------------------
vram=<size>
- Amount of total VRAM to preallocate. For example, "10M". omapfb
allocates memory for framebuffers from VRAM.
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/modedb.c.
There are also two special modes: "pal" and "ntsc" that
can be used to tv out.
omapfb.vram=<fbnum>:<size>[@<physaddr>][,...]
- VRAM allocated for a framebuffer. Normally omapfb allocates vram
depending on the display size. With this you can manually allocate
more or define the physical address of each framebuffer. For example,
"1:4M" to allocate 4M for fb1.
omapfb.debug=<y|n>
- Enable debug printing. You have to have OMAPFB debug support enabled
in kernel config.
omapfb.test=<y|n>
- Draw test pattern to framebuffer whenever framebuffer settings change.
You need to have OMAPFB debug support enabled in kernel config.
omapfb.vrfb=<y|n>
- Use VRFB rotation for all framebuffers.
omapfb.rotate=<angle>
- Default rotation applied to all framebuffers.
0 - 0 degree rotation
1 - 90 degree rotation
2 - 180 degree rotation
3 - 270 degree rotation
omapfb.mirror=<y|n>
- Default mirror for all framebuffers. Only works with DMA rotation.
omapdss.def_disp=<display>
- Name of default display, to which all overlays will be connected.
Common examples are "lcd" or "tv".
omapdss.debug=<y|n>
- Enable debug printing. You have to have DSS debug support enabled in
kernel config.
TODO
----
DSS locking
Error checking
- Lots of checks are missing or implemented just as BUG()
System DMA update for DSI
- Can be used for RGB16 and RGB24P modes. Probably not for RGB24U (how
to skip the empty byte?)
OMAP1 support
- Not sure if needed

3
Documentation/blackfin/00-INDEX
View File

@ -1,9 +1,6 @@
00-INDEX
- This file
cache-lock.txt
- HOWTO for blackfin cache locking.
cachefeatures.txt
- Supported cache features.

6
Documentation/blackfin/Makefile Normal file
View File

@ -0,0 +1,6 @@
obj-m := gptimers-example.o
all: modules
modules clean:
$(MAKE) -C ../.. SUBDIRS=$(PWD) $@

48
Documentation/blackfin/cache-lock.txt
View File

@ -1,48 +0,0 @@
/*
* 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.

10
Documentation/blackfin/cachefeatures.txt
View File

@ -41,16 +41,6 @@
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();

83
Documentation/blackfin/gptimers-example.c Normal file
View File

@ -0,0 +1,83 @@
/*
* 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 <linux/interrupt.h>
#include <linux/module.h>
#include <asm/gptimers.h>
#include <asm/portmux.h>
/* ... 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");

2
Documentation/block/00-INDEX
View File

@ -1,7 +1,5 @@
00-INDEX
- This file
as-iosched.txt
- Anticipatory IO scheduler
barrier.txt
- I/O Barriers
biodoc.txt

172
Documentation/block/as-iosched.txt
View File

@ -1,172 +0,0 @@
Anticipatory IO scheduler
-------------------------
Nick Piggin <piggin@cyberone.com.au> 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.

2
Documentation/block/biodoc.txt
View File

@ -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/DMA-mapping.txt for a discussion
Note: Please refer to Documentation/PCI/PCI-DMA-mapping.txt for a discussion
on PCI high mem DMA aspects and mapping of scatter gather lists, and support
for 64 bit PCI.

6
Documentation/cpu-freq/cpu-drivers.txt
View File

@ -92,9 +92,9 @@ policy->cpuinfo.max_freq - the minimum and maximum frequency
(in kHz) which is supported by
this CPU
policy->cpuinfo.transition_latency the time it takes on this CPU to
switch between two frequencies (if
appropriate, else specify
CPUFREQ_ETERNAL)
switch between two frequencies in
nanoseconds (if appropriate, else
specify CPUFREQ_ETERNAL)
policy->cur The current operating frequency of
this CPU (if appropriate)

11
Documentation/cpu-freq/user-guide.txt
View File

@ -203,6 +203,17 @@ scaling_cur_freq : Current frequency of the CPU as determined by
the frequency the kernel thinks the CPU runs
at.
bios_limit : If the BIOS tells the OS to limit a CPU to
lower frequencies, the user can read out the
maximum available frequency from this file.
This typically can happen through (often not
intended) BIOS settings, restrictions
triggered through a service processor or other
BIOS/HW based implementations.
This does not cover thermal ACPI limitations
which can be detected through the generic
thermal driver.
If you have selected the "userspace" governor which allows you to
set the CPU operating frequency to a specific value, you can read out
the current frequency in

55
Documentation/cpu-hotplug.txt
View File

@ -49,6 +49,12 @@ maxcpus=n Restrict boot time cpus to n. Say if you have 4 cpus, using
additional_cpus=n (*) Use this to limit hotpluggable cpus. This option sets
cpu_possible_map = cpu_present_map + additional_cpus
cede_offline={"off","on"} Use this option to disable/enable putting offlined
processors to an extended H_CEDE state on
supported pseries platforms.
If nothing is specified,
cede_offline is set to "on".
(*) Option valid only for following architectures
- ia64
@ -309,41 +315,26 @@ A: The following are what is required for CPU hotplug infrastructure to work
Q: I need to ensure that a particular cpu is not removed when there is some
work specific to this cpu is in progress.
A: First switch the current thread context to preferred cpu
A: There are two ways. If your code can be run in interrupt context, use
smp_call_function_single(), otherwise use work_on_cpu(). Note that
work_on_cpu() is slow, and can fail due to out of memory:
int my_func_on_cpu(int cpu)
{
cpumask_t saved_mask, new_mask = CPU_MASK_NONE;
int curr_cpu, err = 0;
saved_mask = current->cpus_allowed;
cpu_set(cpu, new_mask);
err = set_cpus_allowed(current, new_mask);
if (err)
return err;
/*
* If we got scheduled out just after the return from
* set_cpus_allowed() before running the work, this ensures
* we stay locked.
*/
curr_cpu = get_cpu();
if (curr_cpu != cpu) {
err = -EAGAIN;
goto ret;
} else {
/*
* Do work : But cant sleep, since get_cpu() disables preempt
*/
}
ret:
put_cpu();
set_cpus_allowed(current, saved_mask);
return err;
}
int err;
get_online_cpus();
if (!cpu_online(cpu))
err = -EINVAL;
else
#if NEEDS_BLOCKING
err = work_on_cpu(cpu, __my_func_on_cpu, NULL);
#else
smp_call_function_single(cpu, __my_func_on_cpu, &err,
true);
#endif
put_online_cpus();
return err;
}
Q: How do we determine how many CPUs are available for hotplug.
A: There is no clear spec defined way from ACPI that can give us that

64
Documentation/device-mapper/snapshot.txt
View File

@ -8,13 +8,19 @@ the block device which are also writable without interfering with the
original content;
*) To create device "forks", i.e. multiple different versions of the
same data stream.
*) To merge a snapshot of a block device back into the snapshot's origin
device.
In the first two cases, dm copies only the chunks of data that get
changed and uses a separate copy-on-write (COW) block device for
storage.
For snapshot merge the contents of the COW storage are merged back into
the origin device.
In both cases, dm copies only the chunks of data that get changed and
uses a separate copy-on-write (COW) block device for storage.
There are two dm targets available: snapshot and snapshot-origin.
There are three dm targets available:
snapshot, snapshot-origin, and snapshot-merge.
*) snapshot-origin <origin>
@ -40,8 +46,25 @@ The difference is that for transient snapshots less metadata must be
saved on disk - they can be kept in memory by the kernel.
How this is used by LVM2
========================
* snapshot-merge <origin> <COW device> <persistent> <chunksize>
takes the same table arguments as the snapshot target except it only
works with persistent snapshots. This target assumes the role of the
"snapshot-origin" target and must not be loaded if the "snapshot-origin"
is still present for <origin>.
Creates a merging snapshot that takes control of the changed chunks
stored in the <COW device> of an existing snapshot, through a handover
procedure, and merges these chunks back into the <origin>. Once merging
has started (in the background) the <origin> may be opened and the merge
will continue while I/O is flowing to it. Changes to the <origin> are
deferred until the merging snapshot's corresponding chunk(s) have been
merged. Once merging has started the snapshot device, associated with
the "snapshot" target, will return -EIO when accessed.
How snapshot is used by LVM2
============================
When you create the first LVM2 snapshot of a volume, four dm devices are used:
1) a device containing the original mapping table of the source volume;
@ -72,3 +95,30 @@ brw------- 1 root root 254, 12 29 ago 18:15 /dev/mapper/volumeGroup-snap-cow
brw------- 1 root root 254, 13 29 ago 18:15 /dev/mapper/volumeGroup-snap
brw------- 1 root root 254, 10 29 ago 18:14 /dev/mapper/volumeGroup-base
How snapshot-merge is used by LVM2
==================================
A merging snapshot assumes the role of the "snapshot-origin" while
merging. As such the "snapshot-origin" is replaced with
"snapshot-merge". The "-real" device is not changed and the "-cow"
device is renamed to <origin name>-cow to aid LVM2's cleanup of the
merging snapshot after it completes. The "snapshot" that hands over its
COW device to the "snapshot-merge" is deactivated (unless using lvchange
--refresh); but if it is left active it will simply return I/O errors.
A snapshot will merge into its origin with the following command:
lvconvert --merge volumeGroup/snap
we'll now have this situation:
# dmsetup table|grep volumeGroup
volumeGroup-base-real: 0 2097152 linear 8:19 384
volumeGroup-base-cow: 0 204800 linear 8:19 2097536
volumeGroup-base: 0 2097152 snapshot-merge 254:11 254:12 P 16
# ls -lL /dev/mapper/volumeGroup-*
brw------- 1 root root 254, 11 29 ago 18:15 /dev/mapper/volumeGroup-base-real
brw------- 1 root root 254, 12 29 ago 18:16 /dev/mapper/volumeGroup-base-cow
brw------- 1 root root 254, 10 29 ago 18:16 /dev/mapper/volumeGroup-base

1
Documentation/dontdiff
View File

@ -103,6 +103,7 @@ gconf
gen-devlist
gen_crc32table
gen_init_cpio
generated
genheaders
genksyms
*_gray256.c

4
Documentation/driver-model/driver.txt
View File

@ -226,5 +226,5 @@ struct driver_attribute driver_attr_debug;
This can then be used to add and remove the attribute from the
driver's directory using:
int driver_create_file(struct device_driver *, struct driver_attribute *);
void driver_remove_file(struct device_driver *, struct driver_attribute *);
int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);

2
Documentation/dvb/README.dvb-usb
View File

@ -85,7 +85,7 @@ http://www.linuxtv.org/wiki/index.php/DVB_USB
- moved transfer control (pid filter, fifo control) from usb driver to frontend, it seems
better settled there (added xfer_ops-struct)
- created a common files for frontends (mc/p/mb)
2004-09-28 - added support for a new device (Unkown, vendor ID is Hyper-Paltek)
2004-09-28 - added support for a new device (Unknown, vendor ID is Hyper-Paltek)
2004-09-20 - added support for a new device (Compro DVB-U2000), thanks
to Amaury Demol for reporting
- changed usb TS transfer method (several urbs, stopping transfer

7
Documentation/edac.txt
View File

@ -80,7 +80,7 @@ is:
broken_parity_status
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directorys for
as is located in /sys/devices/pci<XXX>/0000:XX:YY.Z directories for
PCI devices.
FUTURE HARDWARE SCANNING
@ -288,9 +288,8 @@ Total UE count that had no information attribute fileY:
'ue_noinfo_count'
This attribute file displays the number of UEs that
have occurred have occurred with no informations as to which DIMM
slot is having errors.
This attribute file displays the number of UEs that have occurred
with no information as to which DIMM slot is having errors.
Total Correctable Errors count attribute file:

12
Documentation/fb/viafb.txt
View File

@ -7,7 +7,7 @@
VIA UniChrome Family(CLE266, PM800 / CN400 / CN300,
P4M800CE / P4M800Pro / CN700 / VN800,
CX700 / VX700, K8M890, P4M890,
CN896 / P4M900, VX800)
CN896 / P4M900, VX800, VX855)
[Driver features]
------------------------
@ -154,13 +154,6 @@
0 : No Dual Edge Panel (default)
1 : Dual Edge Panel
viafb_video_dev:
This option is used to specify video output devices(CRT, DVI, LCD) for
duoview case.
For example:
To output video on DVI, we should use:
modprobe viafb viafb_video_dev=DVI...
viafb_lcd_port:
This option is used to specify LCD output port,
available values are "DVP0" "DVP1" "DFP_HIGHLOW" "DFP_HIGH" "DFP_LOW".
@ -181,9 +174,6 @@ Notes:
and bpp, need to call VIAFB specified ioctl interface VIAFB_SET_DEVICE
instead of calling common ioctl function FBIOPUT_VSCREENINFO since
viafb doesn't support multi-head well, or it will cause screen crush.
4. VX800 2D accelerator hasn't been supported in this driver yet. When
using driver on VX800, the driver will disable the acceleration
function as default.
[Configure viafb with "fbset" tool]

42
Documentation/feature-removal-schedule.txt
View File

@ -291,22 +291,6 @@ Who: Michael Buesch <mb@bu3sch.de>
---------------------------
What: usedac i386 kernel parameter
When: 2.6.27
Why: replaced by allowdac and no dac combination
Who: Glauber Costa <gcosta@redhat.com>
---------------------------
What: print_fn_descriptor_symbol()
When: October 2009
Why: The %pF vsprintf format provides the same functionality in a
simpler way. print_fn_descriptor_symbol() is deprecated but
still present to give out-of-tree modules time to change.
Who: Bjorn Helgaas <bjorn.helgaas@hp.com>
---------------------------
What: /sys/o2cb symlink
When: January 2010
Why: /sys/fs/o2cb is the proper location for this information - /sys/o2cb
@ -483,3 +467,29 @@ Why: With the recent innovations in CPU hardware acceleration technologies
Who: Alok N Kataria <akataria@vmware.com>
----------------------------
What: adt7473 hardware monitoring driver
When: February 2010
Why: Obsoleted by the adt7475 driver.
Who: Jean Delvare <khali@linux-fr.org>
---------------------------
What: Support for lcd_switch and display_get in asus-laptop driver
When: March 2010
Why: These two features use non-standard interfaces. There are the
only features that really need multiple path to guess what's
the right method name on a specific laptop.
Removing them will allow to remove a lot of code an significantly
clean the drivers.
This will affect the backlight code which won't be able to know
if the backlight is on or off. The platform display file will also be
write only (like the one in eeepc-laptop).
This should'nt affect a lot of user because they usually know
when their display is on or off.
Who: Corentin Chary <corentin.chary@gmail.com>
----------------------------

14
Documentation/filesystems/00-INDEX
View File

@ -1,7 +1,5 @@
00-INDEX
- this file (info on some of the filesystems supported by linux).
Exporting
- explanation of how to make filesystems exportable.
Locking
- info on locking rules as they pertain to Linux VFS.
9p.txt
@ -36,6 +34,8 @@ dnotify.txt
- info about directory notification in Linux.
ecryptfs.txt
- docs on eCryptfs: stacked cryptographic filesystem for Linux.
exofs.txt
- info, usage, mount options, design about EXOFS.
ext2.txt
- info, mount options and specifications for the Ext2 filesystem.
ext3.txt
@ -66,12 +66,8 @@ mandatory-locking.txt
- info on the Linux implementation of Sys V mandatory file locking.
ncpfs.txt
- info on Novell Netware(tm) filesystem using NCP protocol.
nfs41-server.txt
- info on the Linux server implementation of NFSv4 minor version 1.
nfs-rdma.txt
- how to install and setup the Linux NFS/RDMA client and server software.
nfsroot.txt
- short guide on setting up a diskless box with NFS root filesystem.
nfs/
- nfs-related documentation.
nilfs2.txt
- info and mount options for the NILFS2 filesystem.
ntfs.txt
@ -90,8 +86,6 @@ relay.txt
- info on relay, for efficient streaming from kernel to user space.
romfs.txt
- description of the ROMFS filesystem.
rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer.
seq_file.txt
- how to use the seq_file API
sharedsubtree.txt

23
Documentation/filesystems/exofs.txt
View File

@ -60,13 +60,13 @@ USAGE
mkfs.exofs --pid=65536 --format /dev/osd0
The --format is optional if not specified no OSD_FORMAT will be
preformed and a clean file system will be created in the specified pid,
The --format is optional. If not specified, no OSD_FORMAT will be
performed and a clean file system will be created in the specified pid,
in the available space of the target. (Use --format=size_in_meg to limit
the total LUN space available)
If pid already exist it will be deleted and a new one will be created in it's
place. Be careful.
If pid already exists, it will be deleted and a new one will be created in
its place. Be careful.
An exofs lives inside a single OSD partition. You can create multiple exofs
filesystems on the same device using multiple pids.
@ -81,7 +81,7 @@ USAGE
7. For reference (See do-exofs example script):
do-exofs start - an example of how to perform the above steps.
do-exofs stop - an example of how to unmount the file system.
do-exofs stop - an example of how to unmount the file system.
do-exofs format - an example of how to format and mkfs a new exofs.
8. Extra compilation flags (uncomment in fs/exofs/Kbuild):
@ -104,8 +104,8 @@ Where:
exofs specific options: Options are separated by commas (,)
pid=<integer> - The partition number to mount/create as
container of the filesystem.
This option is mandatory
to=<integer> - Timeout in ticks for a single command
This option is mandatory.
to=<integer> - Timeout in ticks for a single command.
default is (60 * HZ) [for debugging only]
===============================================================================
@ -116,7 +116,7 @@ DESIGN
with a special ID (defined in common.h).
Information included in the file system control block is used to fill the
in-memory superblock structure at mount time. This object is created before
the file system is used by mkexofs.c It contains information such as:
the file system is used by mkexofs.c. It contains information such as:
- The file system's magic number
- The next inode number to be allocated
@ -134,8 +134,8 @@ DESIGN
attributes. This applies to both regular files and other types (directories,
device files, symlinks, etc.).
* Credentials are generated per object (inode and superblock) when they is
created in memory (read off disk or created). The credential works for all
* Credentials are generated per object (inode and superblock) when they are
created in memory (read from disk or created). The credential works for all
operations and is used as long as the object remains in memory.
* Async OSD operations are used whenever possible, but the target may execute
@ -145,7 +145,8 @@ DESIGN
from executing in reverse order:
- The following are handled with the OBJ_CREATED and OBJ_2BCREATED
flags. OBJ_CREATED is set when we know the object exists on the OSD -
in create's callback function, and when we successfully do a read_inode.
in create's callback function, and when we successfully do a
read_inode.
OBJ_2BCREATED is set in the beginning of the create function, so we
know that we should wait.
- create/delete: delete should wait until the object is created

4
Documentation/filesystems/ext3.txt
View File

@ -32,8 +32,8 @@ journal_dev=devnum When the external journal device's major/minor numbers
identified through its new major/minor numbers encoded
in devnum.
noload Don't load the journal on mounting. Note that this forces
mount of inconsistent filesystem, which can lead to
norecovery Don't load the journal on mounting. Note that this forces
noload mount of inconsistent filesystem, which can lead to
various problems.
data=journal All data are committed into the journal prior to being

12
Documentation/filesystems/ext4.txt
View File

@ -153,8 +153,8 @@ journal_dev=devnum When the external journal device's major/minor numbers
identified through its new major/minor numbers encoded
in devnum.
noload Don't load the journal on mounting. Note that
if the filesystem was not unmounted cleanly,
norecovery Don't load the journal on mounting. Note that
noload if the filesystem was not unmounted cleanly,
skipping the journal replay will lead to the
filesystem containing inconsistencies that can
lead to any number of problems.
@ -196,7 +196,7 @@ nobarrier This also requires an IO stack which can support
also be used to enable or disable barriers, for
consistency with other ext4 mount options.
inode_readahead=n This tuning parameter controls the maximum
inode_readahead_blks=n This tuning parameter controls the maximum
number of inode table blocks that ext4's inode
table readahead algorithm will pre-read into
the buffer cache. The default value is 32 blocks.
@ -353,6 +353,12 @@ noauto_da_alloc replacing existing files via patterns such as
system crashes before the delayed allocation
blocks are forced to disk.
discard Controls whether ext4 should issue discard/TRIM
nodiscard(*) commands to the underlying block device when
blocks are freed. This is useful for SSD devices
and sparse/thinly-provisioned LUNs, but it is off
by default until sufficient testing has been done.
Data Mode
=========
There are 3 different data modes:

16
Documentation/filesystems/nfs/00-INDEX Normal file
View File

@ -0,0 +1,16 @@
00-INDEX
- this file (nfs-related documentation).
Exporting
- explanation of how to make filesystems exportable.
knfsd-stats.txt
- statistics which the NFS server makes available to user space.
nfs.txt
- nfs client, and DNS resolution for fs_locations.
nfs41-server.txt
- info on the Linux server implementation of NFSv4 minor version 1.
nfs-rdma.txt
- how to install and setup the Linux NFS/RDMA client and server software
nfsroot.txt
- short guide on setting up a diskless box with NFS root filesystem.
rpc-cache.txt
- introduction to the caching mechanisms in the sunrpc layer.

0
Documentation/filesystems/Exporting → Documentation/filesystems/nfs/Exporting
View File

0
Documentation/filesystems/knfsd-stats.txt → Documentation/filesystems/nfs/knfsd-stats.txt
View File

0
Documentation/filesystems/nfs-rdma.txt → Documentation/filesystems/nfs/nfs-rdma.txt
View File

0
Documentation/filesystems/nfs.txt → Documentation/filesystems/nfs/nfs.txt
View File

9
Documentation/filesystems/nfs41-server.txt → Documentation/filesystems/nfs/nfs41-server.txt
View File

@ -41,7 +41,7 @@ interoperability problems with future clients. Known issues:
conformant with the spec (for example, we don't use kerberos
on the backchannel correctly).
- no trunking support: no clients currently take advantage of
trunking, but this is a mandatory failure, and its use is
trunking, but this is a mandatory feature, and its use is
recommended to clients in a number of places. (E.g. to ensure
timely renewal in case an existing connection's retry timeouts
have gotten too long; see section 8.3 of the draft.)
@ -213,3 +213,10 @@ The following cases aren't supported yet:
DESTROY_CLIENTID, DESTROY_SESSION, EXCHANGE_ID.
* DESTROY_SESSION MUST be the final operation in the COMPOUND request.
Nonstandard compound limitations:
* No support for a sessions fore channel RPC compound that requires both a
ca_maxrequestsize request and a ca_maxresponsesize reply, so we may
fail to live up to the promise we made in CREATE_SESSION fore channel
negotiation.
* No more than one IO operation (read, write, readdir) allowed per
compound.

0
Documentation/filesystems/nfsroot.txt → Documentation/filesystems/nfs/nfsroot.txt
View File

0
Documentation/filesystems/rpc-cache.txt → Documentation/filesystems/nfs/rpc-cache.txt
View File

9
Documentation/filesystems/nilfs2.txt
View File

@ -28,7 +28,7 @@ described in the man pages included in the package.
Project web page: http://www.nilfs.org/en/
Download page: http://www.nilfs.org/en/download.html
Git tree web page: http://www.nilfs.org/git/
NILFS mailing lists: http://www.nilfs.org/mailman/listinfo/users
List info: http://vger.kernel.org/vger-lists.html#linux-nilfs
Caveats
=======
@ -49,8 +49,7 @@ Mount options
NILFS2 supports the following mount options:
(*) == default
barrier=on(*) This enables/disables barriers. barrier=off disables
it, barrier=on enables it.
nobarrier Disables barriers.
errors=continue(*) Keep going on a filesystem error.
errors=remount-ro Remount the filesystem read-only on an error.
errors=panic Panic and halt the machine if an error occurs.
@ -71,6 +70,10 @@ order=strict Apply strict in-order semantics that preserves sequence
blocks. That means, it is guaranteed that no
overtaking of events occurs in the recovered file
system after a crash.
norecovery Disable recovery of the filesystem on mount.
This disables every write access on the device for
read-only mounts or snapshots. This option will fail
for r/w mounts on an unclean volume.
NILFS2 usage
============

2
Documentation/filesystems/porting
View File

@ -140,7 +140,7 @@ Callers of notify_change() need ->i_mutex now.
New super_block field "struct export_operations *s_export_op" for
explicit support for exporting, e.g. via NFS. The structure is fully
documented at its declaration in include/linux/fs.h, and in
Documentation/filesystems/Exporting.
Documentation/filesystems/nfs/Exporting.
Briefly it allows for the definition of decode_fh and encode_fh operations
to encode and decode filehandles, and allows the filesystem to use

15
Documentation/filesystems/proc.txt
View File

@ -38,6 +38,7 @@ Table of Contents
3.3 /proc/<pid>/io - Display the IO accounting fields
3.4 /proc/<pid>/coredump_filter - Core dump filtering settings
3.5 /proc/<pid>/mountinfo - Information about mounts
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
------------------------------------------------------------------------------
@ -176,7 +177,6 @@ read the file /proc/PID/status:
CapBnd: ffffffffffffffff
voluntary_ctxt_switches: 0
nonvoluntary_ctxt_switches: 1
Stack usage: 12 kB
This shows you nearly the same information you would get if you viewed it with
the ps command. In fact, ps uses the proc file system to obtain its
@ -230,7 +230,6 @@ Table 1-2: Contents of the statm files (as of 2.6.30-rc7)
Mems_allowed_list Same as previous, but in "list format"
voluntary_ctxt_switches number of voluntary context switches
nonvoluntary_ctxt_switches number of non voluntary context switches
Stack usage: stack usage high water mark (round up to page size)
..............................................................................
Table 1-3: Contents of the statm files (as of 2.6.8-rc3)
@ -1089,8 +1088,8 @@ The "processes" line gives the number of processes and threads created, which
includes (but is not limited to) those created by calls to the fork() and
clone() system calls.
The "procs_running" line gives the number of processes currently running on
CPUs.
The "procs_running" line gives the total number of threads that are
running or ready to run (i.e., the total number of runnable threads).
The "procs_blocked" line gives the number of processes currently blocked,
waiting for I/O to complete.
@ -1409,3 +1408,11 @@ For more information on mount propagation see:
Documentation/filesystems/sharedsubtree.txt
3.6 /proc/<pid>/comm & /proc/<pid>/task/<tid>/comm
--------------------------------------------------------
These files provide a method to access a tasks comm value. It also allows for
a task to set its own or one of its thread siblings comm value. The comm value
is limited in size compared to the cmdline value, so writing anything longer
then the kernel's TASK_COMM_LEN (currently 16 chars) will result in a truncated
comm value.

4
Documentation/filesystems/seq_file.txt
View File

@ -248,9 +248,7 @@ code, that is done in the initialization code in the usual way:
{
struct proc_dir_entry *entry;
entry = create_proc_entry("sequence", 0, NULL);
if (entry)
entry->proc_fops = &ct_file_ops;
proc_create("sequence", 0, NULL, &ct_file_ops);
return 0;
}

12
Documentation/filesystems/sysfs.txt
View File

@ -91,8 +91,8 @@ struct device_attribute {
const char *buf, size_t count);
};
int device_create_file(struct device *, struct device_attribute *);
void device_remove_file(struct device *, struct device_attribute *);
int device_create_file(struct device *, const struct device_attribute *);
void device_remove_file(struct device *, const struct device_attribute *);
It also defines this helper for defining device attributes:
@ -316,8 +316,8 @@ DEVICE_ATTR(_name, _mode, _show, _store);
Creation/Removal:
int device_create_file(struct device *device, struct device_attribute * attr);
void device_remove_file(struct device * dev, struct device_attribute * attr);
int device_create_file(struct device *dev, const struct device_attribute * attr);
void device_remove_file(struct device *dev, const struct device_attribute * attr);
- bus drivers (include/linux/device.h)
@ -358,7 +358,7 @@ DRIVER_ATTR(_name, _mode, _show, _store)
Creation/Removal:
int driver_create_file(struct device_driver *, struct driver_attribute *);
void driver_remove_file(struct device_driver *, struct driver_attribute *);
int driver_create_file(struct device_driver *, const struct driver_attribute *);
void driver_remove_file(struct device_driver *, const struct driver_attribute *);

2
Documentation/filesystems/vfs.txt
View File

@ -472,7 +472,7 @@ __sync_single_inode) to check if ->writepages has been successful in
writing out the whole address_space.
The Writeback tag is used by filemap*wait* and sync_page* functions,
via wait_on_page_writeback_range, to wait for all writeback to
via filemap_fdatawait_range, to wait for all writeback to
complete. While waiting ->sync_page (if defined) will be called on
each page that is found to require writeback.

19
Documentation/gpio.txt
View File

@ -380,7 +380,7 @@ rare; use gpiochip_remove() when it is unavoidable.
Most often a gpio_chip is part of an instance-specific structure with state
not exposed by the GPIO interfaces, such as addressing, power management,
and more. Chips such as codecs will have complex non-GPIO state,
and more. Chips such as codecs will have complex non-GPIO state.
Any debugfs dump method should normally ignore signals which haven't been
requested as GPIOs. They can use gpiochip_is_requested(), which returns
@ -531,7 +531,14 @@ and have the following read/write attributes:
This file exists only if the pin can be configured as an
interrupt generating input pin.
GPIO controllers have paths like /sys/class/gpio/chipchip42/ (for the
"active_low" ... reads as either 0 (false) or 1 (true). Write
any nonzero value to invert the value attribute both
for reading and writing. Existing and subsequent
poll(2) support configuration via the edge attribute
for "rising" and "falling" edges will follow this
setting.
GPIO controllers have paths like /sys/class/gpio/gpiochip42/ (for the
controller implementing GPIOs starting at #42) and have the following
read-only attributes:
@ -566,6 +573,8 @@ requested using gpio_request():
int gpio_export_link(struct device *dev, const char *name,
unsigned gpio)
/* change the polarity of a GPIO node in sysfs */
int gpio_sysfs_set_active_low(unsigned gpio, int value);
After a kernel driver requests a GPIO, it may only be made available in
the sysfs interface by gpio_export(). The driver can control whether the
@ -580,3 +589,9 @@ After the GPIO has been exported, gpio_export_link() allows creating
symlinks from elsewhere in sysfs to the GPIO sysfs node. Drivers can
use this to provide the interface under their own device in sysfs with
a descriptive name.
Drivers can use gpio_sysfs_set_active_low() to hide GPIO line polarity
differences between boards from user space. This only affects the
sysfs interface. Polarity change can be done both before and after
gpio_export(), and previously enabled poll(2) support for either
rising or falling edge will be reconfigured to follow this setting.

2
Documentation/hwmon/adt7473
View File

@ -9,6 +9,8 @@ Supported chips:
Author: Darrick J. Wong
This driver is depreacted, please use the adt7475 driver instead.
Description
-----------

156
Documentation/hwmon/adt7475
View File

@ -1,87 +1,117 @@
This describes the interface for the ADT7475 driver:
Kernel driver adt7475
=====================
(there are 4 fans, numbered fan1 to fan4):
Supported chips:
* Analog Devices ADT7473
Prefix: 'adt7473'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7475
Prefix: 'adt7475'
Addresses scanned: I2C 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7476
Prefix: 'adt7476'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
* Analog Devices ADT7490
Prefix: 'adt7490'
Addresses scanned: I2C 0x2C, 0x2D, 0x2E
Datasheet: Publicly available at the On Semiconductors website
fanX_input Read the current speed of the fan (in RPMs)
fanX_min Read/write the minimum speed of the fan. Dropping
below this sets an alarm.
Authors:
Jordan Crouse
Hans de Goede
Darrick J. Wong (documentation)
Jean Delvare
(there are three PWMs, numbered pwm1 to pwm3):
pwmX Read/write the current duty cycle of the PWM. Writes
only have effect when auto mode is turned off (see
below). Range is 0 - 255.
Description
-----------
pwmX_enable Fan speed control method:
This driver implements support for the Analog Devices ADT7473, ADT7475,
ADT7476 and ADT7490 chip family. The ADT7473 and ADT7475 differ only in
minor details. The ADT7476 has additional features, including extra voltage
measurement inputs and VID support. The ADT7490 also has additional
features, including extra voltage measurement inputs and PECI support. All
the supported chips will be collectively designed by the name "ADT747x" in
the rest of this document.
0 - No control (fan at full speed)
1 - Manual fan speed control (using pwm[1-*])
2 - Automatic fan speed control
The ADT747x uses the 2-wire interface compatible with the SMBus 2.0
specification. Using an analog to digital converter it measures three (3)
temperatures and two (2) or more voltages. It has four (4) 16-bit counters
for measuring fan speed. There are three (3) PWM outputs that can be used
to control fan speed.
pwmX_auto_channels_temp Select which channels affect this PWM
A sophisticated control system for the PWM outputs is designed into the
ADT747x that allows fan speed to be adjusted automatically based on any of the
three temperature sensors. Each PWM output is individually adjustable and
programmable. Once configured, the ADT747x will adjust the PWM outputs in
response to the measured temperatures without further host intervention.
This feature can also be disabled for manual control of the PWM's.
1 - TEMP1 controls PWM
2 - TEMP2 controls PWM
4 - TEMP3 controls PWM
6 - TEMP2 and TEMP3 control PWM
7 - All three inputs control PWM
Each of the measured inputs (voltage, temperature, fan speed) has
corresponding high/low limit values. The ADT747x will signal an ALARM if
any measured value exceeds either limit.
pwmX_freq Read/write the PWM frequency in Hz. The number
should be one of the following:
The ADT747x samples all inputs continuously. The driver will not read
the registers more often than once every other second. Further,
configuration data is only read once per minute.
11 Hz
14 Hz
22 Hz
29 Hz
35 Hz
44 Hz
58 Hz
88 Hz
Chip Differences Summary
------------------------
pwmX_auto_point1_pwm Read/write the minimum PWM duty cycle in automatic mode
ADT7473:
* 2 voltage inputs
* system acoustics optimizations (not implemented)
pwmX_auto_point2_pwm Read/write the maximum PWM duty cycle in automatic mode
ADT7475:
* 2 voltage inputs
(there are three temperature settings numbered temp1 to temp3):
ADT7476:
* 5 voltage inputs
* VID support
tempX_input Read the current temperature. The value is in milli
degrees of Celsius.
ADT7490:
* 6 voltage inputs
* 1 Imon input (not implemented)
* PECI support (not implemented)
* 2 GPIO pins (not implemented)
* system acoustics optimizations (not implemented)
tempX_max Read/write the upper temperature limit - exceeding this
will cause an alarm.
Special Features
----------------
tempX_min Read/write the lower temperature limit - exceeding this
will cause an alarm.
The ADT747x has a 10-bit ADC and can therefore measure temperatures
with a resolution of 0.25 degree Celsius. Temperature readings can be
configured either for two's complement format or "Offset 64" format,
wherein 64 is subtracted from the raw value to get the temperature value.
tempX_offset Read/write the temperature adjustment offset
The datasheet is very detailed and describes a procedure for determining
an optimal configuration for the automatic PWM control.
tempX_crit Read/write the THERM limit for remote1.
Fan Speed Control
-----------------
tempX_crit_hyst Set the temperature value below crit where the
fans will stay on - this helps drive the temperature
low enough so it doesn't stay near the edge and
cause THERM to keep tripping.
The driver exposes two trip points per PWM channel.
tempX_auto_point1_temp Read/write the minimum temperature where the fans will
turn on in automatic mode.
point1: Set the PWM speed at the lower temperature bound
point2: Set the PWM speed at the higher temperature bound
tempX_auto_point2_temp Read/write the maximum temperature over which the fans
will run in automatic mode. tempX_auto_point1_temp
and tempX_auto_point2_temp together define the
range of automatic control.
The ADT747x will scale the PWM linearly between the lower and higher PWM
speed when the temperature is between the two temperature boundaries.
Temperature boundaries are associated to temperature channels rather than
PWM outputs, and a given PWM output can be controlled by several temperature
channels. As a result, the ADT747x may compute more than one PWM value
for a channel at a given time, in which case the maximum value (fastest
fan speed) is applied. PWM values range from 0 (off) to 255 (full speed).
tempX_alarm Read a 1 if the max/min alarm is set
tempX_fault Read a 1 if either temp1 or temp3 diode has a fault
Fan speed may be set to maximum when the temperature sensor associated with
the PWM control exceeds temp#_max.
(There are two voltage settings, in1 and in2):
Notes
-----
inX_input Read the current voltage on VCC. Value is in
millivolts.
inX_min read/write the minimum voltage limit.
Dropping below this causes an alarm.
inX_max read/write the maximum voltage limit.
Exceeding this causes an alarm.
inX_alarm Read a 1 if the max/min alarm is set.
The nVidia binary driver presents an ADT7473 chip via an on-card i2c bus.
Unfortunately, they fail to set the i2c adapter class, so this driver may
fail to find the chip until the nvidia driver is patched.

102
Documentation/hwmon/amc6821 Normal file
View File

@ -0,0 +1,102 @@
Kernel driver amc6821
=====================
Supported chips:
Texas Instruments AMC6821
Prefix: 'amc6821'
Addresses scanned: 0x18, 0x19, 0x1a, 0x2c, 0x2d, 0x2e, 0x4c, 0x4d, 0x4e
Datasheet: http://focus.ti.com/docs/prod/folders/print/amc6821.html
Authors:
Tomaz Mertelj <tomaz.mertelj@guest.arnes.si>
Description
-----------
This driver implements support for the Texas Instruments amc6821 chip.
The chip has one on-chip and one remote temperature sensor and one pwm fan
regulator.
The pwm can be controlled either from software or automatically.
The driver provides the following sensor accesses in sysfs:
temp1_input ro on-chip temperature
temp1_min rw "
temp1_max rw "
temp1_crit rw "
temp1_min_alarm ro "
temp1_max_alarm ro "
temp1_crit_alarm ro "
temp2_input ro remote temperature
temp2_min rw "
temp2_max rw "
temp2_crit rw "
temp2_min_alarm ro "
temp2_max_alarm ro "
temp2_crit_alarm ro "
temp2_fault ro "
fan1_input ro tachometer speed
fan1_min rw "
fan1_max rw "
fan1_fault ro "
fan1_div rw Fan divisor can be either 2 or 4.
pwm1 rw pwm1
pwm1_enable rw regulator mode, 1=open loop, 2=fan controlled
by remote temperature, 3=fan controlled by
combination of the on-chip temperature and
remote-sensor temperature,
pwm1_auto_channels_temp ro 1 if pwm_enable==2, 3 if pwm_enable==3
pwm1_auto_point1_pwm ro Hardwired to 0, shared for both
temperature channels.
pwm1_auto_point2_pwm rw This value is shared for both temperature
channels.
pwm1_auto_point3_pwm rw Hardwired to 255, shared for both
temperature channels.
temp1_auto_point1_temp ro Hardwired to temp2_auto_point1_temp
which is rw. Below this temperature fan stops.
temp1_auto_point2_temp rw The low-temperature limit of the proportional
range. Below this temperature
pwm1 = pwm1_auto_point2_pwm. It can go from
0 degree C to 124 degree C in steps of
4 degree C. Read it out after writing to get
the actual value.
temp1_auto_point3_temp rw Above this temperature fan runs at maximum
speed. It can go from temp1_auto_point2_temp.
It can only have certain discrete values
which depend on temp1_auto_point2_temp and
pwm1_auto_point2_pwm. Read it out after
writing to get the actual value.
temp2_auto_point1_temp rw Must be between 0 degree C and 63 degree C and
it defines the passive cooling temperature.
Below this temperature the fan stops in
the closed loop mode.
temp2_auto_point2_temp rw The low-temperature limit of the proportional
range. Below this temperature
pwm1 = pwm1_auto_point2_pwm. It can go from
0 degree C to 124 degree C in steps
of 4 degree C.
temp2_auto_point3_temp rw Above this temperature fan runs at maximum
speed. It can only have certain discrete
values which depend on temp2_auto_point2_temp
and pwm1_auto_point2_pwm. Read it out after
writing to get actual value.
Module parameters
-----------------
If your board has a BIOS that initializes the amc6821 correctly, you should
load the module with: init=0.
If your board BIOS doesn't initialize the chip, or you want
different settings, you can set the following parameters:
init=1,
pwminv: 0 default pwm output, 1 inverts pwm output.

10
Documentation/hwmon/f71882fg
View File

@ -14,6 +14,10 @@ Supported chips:
Prefix: 'f71882fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Available from the Fintek website
* Fintek F71889FG
Prefix: 'f71889fg'
Addresses scanned: none, address read from Super I/O config space
Datasheet: Should become available on the Fintek website soon
* Fintek F8000
Prefix: 'f8000'
Addresses scanned: none, address read from Super I/O config space
@ -51,6 +55,12 @@ supported. The right one to use depends on external circuitry on the
motherboard, so the driver assumes that the BIOS set the method
properly.
Note that the lowest numbered temperature zone trip point corresponds to
to the border between the highest and one but highest temperature zones, and
vica versa. So the temperature zone trip points 1-4 (or 1-2) go from high temp
to low temp! This is how things are implemented in the IC, and the driver
mimicks this.
There are 2 modes to specify the speed of the fan, PWM duty cycle (or DC
voltage) mode, where 0-100% duty cycle (0-100% of 12V) is specified. And RPM
mode where the actual RPM of the fan (as measured) is controlled and the speed

1
Documentation/hwmon/it87
View File

@ -86,7 +86,6 @@ 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 and IT8720F also features VID inputs (up to 8 pins) but the value
is stored in the Super-I/O configuration space. Due to technical limitations,

65
Documentation/hwmon/k10temp Normal file
View File

@ -0,0 +1,65 @@
Kernel driver k10temp
=====================
Supported chips:
* AMD Family 10h processors:
Socket F: Quad-Core/Six-Core/Embedded Opteron (but see below)
Socket AM2+: Quad-Core Opteron, Phenom (II) X3/X4, Athlon X2 (but see below)
Socket AM3: Quad-Core Opteron, Athlon/Phenom II X2/X3/X4, Sempron II
Socket S1G3: Athlon II, Sempron, Turion II
* AMD Family 11h processors:
Socket S1G2: Athlon (X2), Sempron (X2), Turion X2 (Ultra)
Prefix: 'k10temp'
Addresses scanned: PCI space
Datasheets:
BIOS and Kernel Developer's Guide (BKDG) For AMD Family 10h Processors:
http://support.amd.com/us/Processor_TechDocs/31116.pdf
BIOS and Kernel Developer's Guide (BKDG) for AMD Family 11h Processors:
http://support.amd.com/us/Processor_TechDocs/41256.pdf
Revision Guide for AMD Family 10h Processors:
http://support.amd.com/us/Processor_TechDocs/41322.pdf
Revision Guide for AMD Family 11h Processors:
http://support.amd.com/us/Processor_TechDocs/41788.pdf
AMD Family 11h Processor Power and Thermal Data Sheet for Notebooks:
http://support.amd.com/us/Processor_TechDocs/43373.pdf
AMD Family 10h Server and Workstation Processor Power and Thermal Data Sheet:
http://support.amd.com/us/Processor_TechDocs/43374.pdf
AMD Family 10h Desktop Processor Power and Thermal Data Sheet:
http://support.amd.com/us/Processor_TechDocs/43375.pdf
Author: Clemens Ladisch <clemens@ladisch.de>
Description
-----------
This driver permits reading of the internal temperature sensor of AMD
Family 10h and 11h processors.
All these processors have a sensor, but on those for Socket F or AM2+,
the sensor may return inconsistent values (erratum 319). The driver
will refuse to load on these revisions unless you specify the "force=1"
module parameter.
Due to technical reasons, the driver can detect only the mainboard's
socket type, not the processor's actual capabilities. Therefore, if you
are using an AM3 processor on an AM2+ mainboard, you can safely use the
"force=1" parameter.
There is one temperature measurement value, available as temp1_input in
sysfs. It is measured in degrees Celsius with a resolution of 1/8th degree.
Please note that it is defined as a relative value; to quote the AMD manual:
Tctl is the processor temperature control value, used by the platform to
control cooling systems. Tctl is a non-physical temperature on an
arbitrary scale measured in degrees. It does _not_ represent an actual
physical temperature like die or case temperature. Instead, it specifies
the processor temperature relative to the point at which the system must
supply the maximum cooling for the processor's specified maximum case
temperature and maximum thermal power dissipation.
The maximum value for Tctl is available in the file temp1_max.
If the BIOS has enabled hardware temperature control, the threshold at
which the processor will throttle itself to avoid damage is available in
temp1_crit and temp1_crit_hyst.

55
Documentation/hwmon/lis3lv02d
View File

@ -3,7 +3,8 @@ Kernel driver lis3lv02d
Supported chips:
* STMicroelectronics LIS3LV02DL and LIS3LV02DQ
* STMicroelectronics LIS3LV02DL, LIS3LV02DQ (12 bits precision)
* STMicroelectronics LIS302DL, LIS3L02DQ, LIS331DL (8 bits)
Authors:
Yan Burman <burman.yan@gmail.com>
@ -13,32 +14,52 @@ Authors:
Description
-----------
This driver provides support for the accelerometer found in various HP
laptops sporting the feature officially called "HP Mobile Data
Protection System 3D" or "HP 3D DriveGuard". It detects automatically
laptops with this sensor. Known models (for now the HP 2133, nc6420,
nc2510, nc8510, nc84x0, nw9440 and nx9420) will have their axis
automatically oriented on standard way (eg: you can directly play
neverball). The accelerometer data is readable via
/sys/devices/platform/lis3lv02d.
This driver provides support for the accelerometer found in various HP laptops
sporting the feature officially called "HP Mobile Data Protection System 3D" or
"HP 3D DriveGuard". It detects automatically laptops with this sensor. Known
models (full list can be found in drivers/hwmon/hp_accel.c) will have their
axis automatically oriented on standard way (eg: you can directly play
neverball). The accelerometer data is readable via
/sys/devices/platform/lis3lv02d. Reported values are scaled
to mg values (1/1000th of earth gravity).
Sysfs attributes under /sys/devices/platform/lis3lv02d/:
position - 3D position that the accelerometer reports. Format: "(x,y,z)"
calibrate - read: values (x, y, z) that are used as the base for input
class device operation.
write: forces the base to be recalibrated with the current
position.
rate - reports the sampling rate of the accelerometer device in HZ
rate - read reports the sampling rate of the accelerometer device in HZ.
write changes sampling rate of the accelerometer device.
Only values which are supported by HW are accepted.
selftest - performs selftest for the chip as specified by chip manufacturer.
This driver also provides an absolute input class device, allowing
the laptop to act as a pinball machine-esque joystick.
the laptop to act as a pinball machine-esque joystick. Joystick device can be
calibrated. Joystick device can be in two different modes.
By default output values are scaled between -32768 .. 32767. In joystick raw
mode, joystick and sysfs position entry have the same scale. There can be
small difference due to input system fuzziness feature.
Events are also available as input event device.
Selftest is meant only for hardware diagnostic purposes. It is not meant to be
used during normal operations. Position data is not corrupted during selftest
but interrupt behaviour is not guaranteed to work reliably. In test mode, the
sensing element is internally moved little bit. Selftest measures difference
between normal mode and test mode. Chip specifications tell the acceptance
limit for each type of the chip. Limits are provided via platform data
to allow adjustment of the limits without a change to the actual driver.
Seltest returns either "OK x y z" or "FAIL x y z" where x, y and z are
measured difference between modes. Axes are not remapped in selftest mode.
Measurement values are provided to help HW diagnostic applications to make
final decision.
On HP laptops, if the led infrastructure is activated, support for a led
indicating disk protection will be provided as /sys/class/leds/hp::hddprotect.
Another feature of the driver is misc device called "freefall" that
acts similar to /dev/rtc and reacts on free-fall interrupts received
from the device. It supports blocking operations, poll/select and
fasync operation modes. You must read 1 bytes from the device. The
result is number of free-fall interrupts since the last successful
read (or 255 if number of interrupts would not fit).
read (or 255 if number of interrupts would not fit). See the hpfall.c
file for an example on using the device.
Axes orientation
@ -55,7 +76,7 @@ the accelerometer are converted into a "standard" organisation of the axes
* If the laptop is put upside-down, Z becomes negative
If your laptop model is not recognized (cf "dmesg"), you can send an
email to the authors to add it to the database. When reporting a new
email to the maintainer to add it to the database. When reporting a new
laptop, please include the output of "dmidecode" plus the value of
/sys/devices/platform/lis3lv02d/position in these four cases.

50
Documentation/hwmon/mc13783-adc Normal file
View File

@ -0,0 +1,50 @@
Kernel driver mc13783-adc
=========================
Supported chips:
* Freescale Atlas MC13783
Prefix: 'mc13783_adc'
Datasheet: http://www.freescale.com/files/rf_if/doc/data_sheet/MC13783.pdf?fsrch=1
Authors:
Sascha Hauer <s.hauer@pengutronix.de>
Luotao Fu <l.fu@pengutronix.de>
Description
-----------
The Freescale MC13783 is a Power Management and Audio Circuit. Among
other things it contains a 10-bit A/D converter. The converter has 16
channels which can be used in different modes.
The A/D converter has a resolution of 2.25mV. Channels 0-4 have
a dedicated meaning with chip internal scaling applied. Channels 5-7
can be used as general purpose inputs or alternatively in a dedicated
mode. Channels 12-15 are occupied by the touchscreen if it's active.
Currently the driver only supports channels 2 and 5-15 with no alternative
modes for channels 5-7.
See this table for the meaning of the different channels and their chip
internal scaling:
Channel Signal Input Range Scaling
-------------------------------------------------------------------------------
0 Battery Voltage (BATT) 2.50 - 4.65V -2.40V
1 Battery Current (BATT - BATTISNS) -50 - 50 mV x20
2 Application Supply (BP) 2.50 - 4.65V -2.40V
3 Charger Voltage (CHRGRAW) 0 - 10V / /5
0 - 20V /10
4 Charger Current (CHRGISNSP-CHRGISNSN) -0.25V - 0.25V x4
5 General Purpose ADIN5 / Battery Pack Thermistor 0 - 2.30V No
6 General Purpose ADIN6 / Backup Voltage (LICELL) 0 - 2.30V / No /
1.50 - 3.50V -1.20V
7 General Purpose ADIN7 / UID / Die Temperature 0 - 2.30V / No /
0 - 2.55V / x0.9 / No
8 General Purpose ADIN8 0 - 2.30V No
9 General Purpose ADIN9 0 - 2.30V No
10 General Purpose ADIN10 0 - 2.30V No
11 General Purpose ADIN11 0 - 2.30V No
12 General Purpose TSX1 / Touchscreen X-plate 1 0 - 2.30V No
13 General Purpose TSX2 / Touchscreen X-plate 2 0 - 2.30V No
14 General Purpose TSY1 / Touchscreen Y-plate 1 0 - 2.30V No
15 General Purpose TSY2 / Touchscreen Y-plate 2 0 - 2.30V No

11
Documentation/hwmon/sysfs-interface
View File

@ -225,8 +225,6 @@ pwm[1-*]_auto_point[1-*]_temp_hyst
to PWM output channels.
RW
OR
temp[1-*]_auto_point[1-*]_pwm
temp[1-*]_auto_point[1-*]_temp
temp[1-*]_auto_point[1-*]_temp_hyst
@ -235,6 +233,15 @@ temp[1-*]_auto_point[1-*]_temp_hyst
to temperature channels.
RW
There is a third case where trip points are associated to both PWM output
channels and temperature channels: the PWM values are associated to PWM
output channels while the temperature values are associated to temperature
channels. In that case, the result is determined by the mapping between
temperature inputs and PWM outputs. When several temperature inputs are
mapped to a given PWM output, this leads to several candidate PWM values.
The actual result is up to the chip, but in general the highest candidate
value (fastest fan speed) wins.
****************
* Temperatures *

10
Documentation/hwmon/w83627ehf
View File

@ -81,8 +81,14 @@ 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
* 1 Manual mode, write to pwm file any value 0-255 (full speed)
* 2 "Thermal Cruise" mode
* 3 "Fan Speed Cruise" mode
* 4 "Smart Fan III" mode
pwm[1-4]_mode - controls if output is PWM or DC level
* 0 DC output (0 - 12v)
* 1 PWM output
Thermal Cruise mode
-------------------

29
Documentation/hwmon/w83627hf
View File

@ -32,8 +32,6 @@ Authors:
Module Parameters
-----------------
* force_addr: int
Initialize the ISA address of the sensors
* force_i2c: int
Initialize the I2C address of the sensors
* init: int
@ -70,3 +68,30 @@ doesn't help, you may just ignore the bogus VID reading with no harm done.
For further information on this driver see the w83781d driver documentation.
[1] http://www.lm-sensors.org/browser/lm-sensors/trunk/doc/vid
Forcing the address
-------------------
The driver used to have a module parameter named force_addr, which could
be used to force the base I/O address of the hardware monitoring block.
This was meant as a workaround for mainboards with a broken BIOS. This
module parameter is gone for technical reasons. If you need this feature,
you can obtain the same result by using the isaset tool (part of
lm-sensors) before loading the driver:
# Enter the Super I/O config space
isaset -y -f 0x2e 0x87
isaset -y -f 0x2e 0x87
# Select the hwmon logical device
isaset -y 0x2e 0x2f 0x07 0x0b
# Set the base I/O address (to 0x290 in this example)
isaset -y 0x2e 0x2f 0x60 0x02
isaset -y 0x2e 0x2f 0x61 0x90
# Exit the Super-I/O config space
isaset -y -f 0x2e 0xaa
The above sequence assumes a Super-I/O config space at 0x2e/0x2f, but
0x4e/0x4f is also possible.

2
Documentation/i2c/writing-clients
View File

@ -44,7 +44,7 @@ static struct i2c_driver foo_driver = {
/* if device autodetection is needed: */
.class = I2C_CLASS_SOMETHING,
.detect = foo_detect,
.address_data = &addr_data,
.address_list = normal_i2c,
.shutdown = foo_shutdown, /* optional */
.suspend = foo_suspend, /* optional */

10
Documentation/infiniband/ipoib.txt
View File

@ -36,11 +36,11 @@ Datagram vs Connected modes
fabric with a 2K MTU, the IPoIB MTU will be 2048 - 4 = 2044 bytes.
In connected mode, the IB RC (Reliable Connected) transport is used.
Connected mode is to takes advantage of the connected nature of the
IB transport and allows an MTU up to the maximal IP packet size of
64K, which reduces the number of IP packets needed for handling
large UDP datagrams, TCP segments, etc and increases the performance
for large messages.
Connected mode takes advantage of the connected nature of the IB
transport and allows an MTU up to the maximal IP packet size of 64K,
which reduces the number of IP packets needed for handling large UDP
datagrams, TCP segments, etc and increases the performance for large
messages.
In connected mode, the interface's UD QP is still used for multicast
and communication with peers that don't support connected mode. In

203
Documentation/ioctl/ioctl-number.txt
View File

@ -56,10 +56,11 @@ Following this convention is good because:
(5) When following the convention, the driver code can use generic
code to copy the parameters between user and kernel space.
This table lists ioctls visible from user land for Linux/i386. It contains
most drivers up to 2.3.14, but I know I am missing some.
This table lists ioctls visible from user land for Linux/x86. It contains
most drivers up to 2.6.31, but I know I am missing some. There has been
no attempt to list non-X86 architectures or ioctls from drivers/staging/.
Code Seq# Include File Comments
Code Seq#(hex) Include File Comments
========================================================
0x00 00-1F linux/fs.h conflict!
0x00 00-1F scsi/scsi_ioctl.h conflict!
@ -69,119 +70,228 @@ Code Seq# Include File Comments
0x03 all linux/hdreg.h
0x04 D2-DC linux/umsdos_fs.h Dead since 2.6.11, but don't reuse these.
0x06 all linux/lp.h
0x09 all linux/md.h
0x09 all linux/raid/md_u.h
0x10 00-0F drivers/char/s390/vmcp.h
0x12 all linux/fs.h
linux/blkpg.h
0x1b all InfiniBand Subsystem <http://www.openib.org/>
0x20 all drivers/cdrom/cm206.h
0x22 all scsi/sg.h
'#' 00-3F IEEE 1394 Subsystem Block for the entire subsystem
'$' 00-0F linux/perf_counter.h, linux/perf_event.h
'1' 00-1F <linux/timepps.h> PPS kit from Ulrich Windl
<ftp://ftp.de.kernel.org/pub/linux/daemons/ntp/PPS/>
'2' 01-04 linux/i2o.h
'3' 00-0F drivers/s390/char/raw3270.h conflict!
'3' 00-1F linux/suspend_ioctls.h conflict!
and kernel/power/user.c
'8' all SNP8023 advanced NIC card
<mailto:mcr@solidum.com>
'A' 00-1F linux/apm_bios.h
'@' 00-0F linux/radeonfb.h conflict!
'@' 00-0F drivers/video/aty/aty128fb.c conflict!
'A' 00-1F linux/apm_bios.h conflict!
'A' 00-0F linux/agpgart.h conflict!
and drivers/char/agp/compat_ioctl.h
'A' 00-7F sound/asound.h conflict!
'B' 00-1F linux/cciss_ioctl.h conflict!
'B' 00-0F include/linux/pmu.h conflict!
'B' C0-FF advanced bbus
<mailto:maassen@uni-freiburg.de>
'C' all linux/soundcard.h
'C' all linux/soundcard.h conflict!
'C' 01-2F linux/capi.h conflict!
'C' F0-FF drivers/net/wan/cosa.h conflict!
'D' all arch/s390/include/asm/dasd.h
'E' all linux/input.h
'F' all linux/fb.h
'H' all linux/hiddev.h
'I' all linux/isdn.h
'D' 40-5F drivers/scsi/dpt/dtpi_ioctl.h
'D' 05 drivers/scsi/pmcraid.h
'E' all linux/input.h conflict!
'E' 00-0F xen/evtchn.h conflict!
'F' all linux/fb.h conflict!
'F' 01-02 drivers/scsi/pmcraid.h conflict!
'F' 20 drivers/video/fsl-diu-fb.h conflict!
'F' 20 drivers/video/intelfb/intelfb.h conflict!
'F' 20 linux/ivtvfb.h conflict!
'F' 20 linux/matroxfb.h conflict!
'F' 20 drivers/video/aty/atyfb_base.c conflict!
'F' 00-0F video/da8xx-fb.h conflict!
'F' 80-8F linux/arcfb.h conflict!
'F' DD video/sstfb.h conflict!
'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict!
'G' 00-0F linux/gigaset_dev.h conflict!
'H' 00-7F linux/hiddev.h conflict!
'H' 00-0F linux/hidraw.h conflict!
'H' 00-0F sound/asound.h conflict!
'H' 20-40 sound/asound_fm.h conflict!
'H' 80-8F sound/sfnt_info.h conflict!
'H' 10-8F sound/emu10k1.h conflict!
'H' 10-1F sound/sb16_csp.h conflict!
'H' 10-1F sound/hda_hwdep.h conflict!
'H' 40-4F sound/hdspm.h conflict!
'H' 40-4F sound/hdsp.h conflict!
'H' 90 sound/usb/usx2y/usb_stream.h
'H' C0-F0 net/bluetooth/hci.h conflict!
'H' C0-DF net/bluetooth/hidp/hidp.h conflict!
'H' C0-DF net/bluetooth/cmtp/cmtp.h conflict!
'H' C0-DF net/bluetooth/bnep/bnep.h conflict!
'I' all linux/isdn.h conflict!
'I' 00-0F drivers/isdn/divert/isdn_divert.h conflict!
'I' 40-4F linux/mISDNif.h conflict!
'J' 00-1F drivers/scsi/gdth_ioctl.h
'K' all linux/kd.h
'L' 00-1F linux/loop.h
'L' 20-2F driver/usb/misc/vstusb.h
'L' 00-1F linux/loop.h conflict!
'L' 10-1F drivers/scsi/mpt2sas/mpt2sas_ctl.h conflict!
'L' 20-2F linux/usb/vstusb.h
'L' E0-FF linux/ppdd.h encrypted disk device driver
<http://linux01.gwdg.de/~alatham/ppdd.html>
'M' all linux/soundcard.h
'M' all linux/soundcard.h conflict!
'M' 01-16 mtd/mtd-abi.h conflict!
and drivers/mtd/mtdchar.c
'M' 01-03 drivers/scsi/megaraid/megaraid_sas.h
'M' 00-0F drivers/video/fsl-diu-fb.h conflict!
'N' 00-1F drivers/usb/scanner.h
'O' 00-02 include/mtd/ubi-user.h UBI
'P' all linux/soundcard.h
'O' 00-06 mtd/ubi-user.h UBI
'P' all linux/soundcard.h conflict!
'P' 60-6F sound/sscape_ioctl.h conflict!
'P' 00-0F drivers/usb/class/usblp.c conflict!
'Q' all linux/soundcard.h
'R' 00-1F linux/random.h
'R' 00-1F linux/random.h conflict!
'R' 01 linux/rfkill.h conflict!
'R' 01-0F media/rds.h conflict!
'R' C0-DF net/bluetooth/rfcomm.h
'S' all linux/cdrom.h conflict!
'S' 80-81 scsi/scsi_ioctl.h conflict!
'S' 82-FF scsi/scsi.h conflict!
'S' 00-7F sound/asequencer.h conflict!
'T' all linux/soundcard.h conflict!
'T' 00-AF sound/asound.h conflict!
'T' all arch/x86/include/asm/ioctls.h conflict!
'U' 00-EF linux/drivers/usb/usb.h
'V' all linux/vt.h
'T' C0-DF linux/if_tun.h conflict!
'U' all sound/asound.h conflict!
'U' 00-0F drivers/media/video/uvc/uvcvideo.h conflict!
'U' 00-CF linux/uinput.h conflict!
'U' 00-EF linux/usbdevice_fs.h
'U' C0-CF drivers/bluetooth/hci_uart.h
'V' all linux/vt.h conflict!
'V' all linux/videodev2.h conflict!
'V' C0 linux/ivtvfb.h conflict!
'V' C0 linux/ivtv.h conflict!
'V' C0 media/davinci/vpfe_capture.h conflict!
'V' C0 media/si4713.h conflict!
'V' C0-CF drivers/media/video/mxb.h conflict!
'W' 00-1F linux/watchdog.h conflict!
'W' 00-1F linux/wanrouter.h conflict!
'X' all linux/xfs_fs.h
'W' 00-3F sound/asound.h conflict!
'X' all fs/xfs/xfs_fs.h conflict!
and fs/xfs/linux-2.6/xfs_ioctl32.h
and include/linux/falloc.h
and linux/fs.h
'X' all fs/ocfs2/ocfs_fs.h conflict!
'X' 01 linux/pktcdvd.h conflict!
'Y' all linux/cyclades.h
'[' 00-07 linux/usb/usbtmc.h USB Test and Measurement Devices
'Z' 14-15 drivers/message/fusion/mptctl.h
'[' 00-07 linux/usb/tmc.h USB Test and Measurement Devices
<mailto:gregkh@suse.de>
'a' all ATM on linux
'a' all linux/atm*.h, linux/sonet.h ATM on linux
<http://lrcwww.epfl.ch/linux-atm/magic.html>
'b' 00-FF bit3 vme host bridge
'b' 00-FF conflict! bit3 vme host bridge
<mailto:natalia@nikhefk.nikhef.nl>
'b' 00-0F media/bt819.h conflict!
'c' all linux/cm4000_cs.h conflict!
'c' 00-7F linux/comstats.h conflict!
'c' 00-7F linux/coda.h conflict!
'c' 80-9F arch/s390/include/asm/chsc.h
'c' A0-AF arch/x86/include/asm/msr.h
'c' 00-1F linux/chio.h conflict!
'c' 80-9F arch/s390/include/asm/chsc.h conflict!
'c' A0-AF arch/x86/include/asm/msr.h conflict!
'd' 00-FF linux/char/drm/drm/h conflict!
'd' 02-40 pcmcia/ds.h conflict!
'd' 10-3F drivers/media/video/dabusb.h conflict!
'd' C0-CF drivers/media/video/saa7191.h conflict!
'd' F0-FF linux/digi1.h
'e' all linux/digi1.h conflict!
'e' 00-1F net/irda/irtty.h conflict!
'f' 00-1F linux/ext2_fs.h
'h' 00-7F Charon filesystem
'e' 00-1F drivers/net/irda/irtty-sir.h conflict!
'f' 00-1F linux/ext2_fs.h conflict!
'f' 00-1F linux/ext3_fs.h conflict!
'f' 00-0F fs/jfs/jfs_dinode.h conflict!
'f' 00-0F fs/ext4/ext4.h conflict!
'f' 00-0F linux/fs.h conflict!
'f' 00-0F fs/ocfs2/ocfs2_fs.h conflict!
'g' 00-0F linux/usb/gadgetfs.h
'g' 20-2F linux/usb/g_printer.h
'h' 00-7F conflict! Charon filesystem
<mailto:zapman@interlan.net>
'i' 00-3F linux/i2o.h
'h' 00-1F linux/hpet.h conflict!
'i' 00-3F linux/i2o-dev.h conflict!
'i' 0B-1F linux/ipmi.h conflict!
'i' 80-8F linux/i8k.h
'j' 00-3F linux/joystick.h
'k' 00-0F linux/spi/spidev.h conflict!
'k' 00-05 video/kyro.h conflict!
'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system
<http://mikonos.dia.unisa.it/tcfs>
'l' 40-7F linux/udf_fs_i.h in development:
<http://sourceforge.net/projects/linux-udf/>
'm' 00-09 linux/mmtimer.h
'm' 00-09 linux/mmtimer.h conflict!
'm' all linux/mtio.h conflict!
'm' all linux/soundcard.h conflict!
'm' all linux/synclink.h conflict!
'm' 00-19 drivers/message/fusion/mptctl.h conflict!
'm' 00 drivers/scsi/megaraid/megaraid_ioctl.h conflict!
'm' 00-1F net/irda/irmod.h conflict!
'n' 00-7F linux/ncp_fs.h
'n' 00-7F linux/ncp_fs.h and fs/ncpfs/ioctl.c
'n' 80-8F linux/nilfs2_fs.h NILFS2
'n' E0-FF video/matrox.h matroxfb
'n' E0-FF linux/matroxfb.h matroxfb
'o' 00-1F fs/ocfs2/ocfs2_fs.h OCFS2
'o' 00-03 include/mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
'o' 40-41 include/mtd/ubi-user.h UBI
'o' 01-A1 include/linux/dvb/*.h DVB
'o' 00-03 mtd/ubi-user.h conflict! (OCFS2 and UBI overlaps)
'o' 40-41 mtd/ubi-user.h UBI
'o' 01-A1 linux/dvb/*.h DVB
'p' 00-0F linux/phantom.h conflict! (OpenHaptics needs this)
'p' 00-1F linux/rtc.h conflict!
'p' 00-3F linux/mc146818rtc.h conflict!
'p' 40-7F linux/nvram.h
'p' 80-9F user-space parport
'p' 80-9F linux/ppdev.h user-space parport
<mailto:tim@cyberelk.net>
'p' a1-a4 linux/pps.h LinuxPPS
'p' A1-A4 linux/pps.h LinuxPPS
<mailto:giometti@linux.it>
'q' 00-1F linux/serio.h
'q' 80-FF Internet PhoneJACK, Internet LineJACK
<http://www.quicknet.net>
'r' 00-1F linux/msdos_fs.h
'q' 80-FF linux/telephony.h Internet PhoneJACK, Internet LineJACK
linux/ixjuser.h <http://www.quicknet.net>
'r' 00-1F linux/msdos_fs.h and fs/fat/dir.c
's' all linux/cdk.h
't' 00-7F linux/if_ppp.h
't' 80-8F linux/isdn_ppp.h
't' 90 linux/toshiba.h
'u' 00-1F linux/smb_fs.h
'v' 00-1F linux/ext2_fs.h conflict!
'v' all linux/videodev.h conflict!
'v' 00-1F linux/ext2_fs.h conflict!
'v' 00-1F linux/fs.h conflict!
'v' 00-0F linux/sonypi.h conflict!
'v' C0-CF drivers/media/video/ov511.h conflict!
'v' C0-DF media/pwc-ioctl.h conflict!
'v' C0-FF linux/meye.h conflict!
'v' C0-CF drivers/media/video/zoran/zoran.h conflict!
'v' D0-DF drivers/media/video/cpia2/cpia2dev.h conflict!
'w' all CERN SCI driver
'y' 00-1F packet based user level communications
<mailto:zapman@interlan.net>
'z' 00-3F CAN bus card
'z' 00-3F CAN bus card conflict!
<mailto:hdstich@connectu.ulm.circular.de>
'z' 40-7F CAN bus card
'z' 40-7F CAN bus card conflict!
<mailto:oe@port.de>
'z' 10-4F drivers/s390/crypto/zcrypt_api.h conflict!
0x80 00-1F linux/fb.h
0x81 00-1F linux/videotext.h
0x88 00-3F media/ovcamchip.h
0x89 00-06 arch/x86/include/asm/sockios.h
0x89 0B-DF linux/sockios.h
0x89 E0-EF linux/sockios.h SIOCPROTOPRIVATE range
0x89 E0-EF linux/dn.h PROTOPRIVATE range
0x89 F0-FF linux/sockios.h SIOCDEVPRIVATE range
0x8B all linux/wireless.h
0x8C 00-3F WiNRADiO driver
<http://www.proximity.com.au/~brian/winradio/>
0x90 00 drivers/cdrom/sbpcd.h
0x92 00-0F drivers/usb/mon/mon_bin.c
0x93 60-7F linux/auto_fs.h
0x94 all fs/btrfs/ioctl.h
0x99 00-0F 537-Addinboard driver
<mailto:buk@buks.ipn.de>
0xA0 all linux/sdp/sdp.h Industrial Device Project
@ -192,17 +302,22 @@ Code Seq# Include File Comments
0xAB 00-1F linux/nbd.h
0xAC 00-1F linux/raw.h
0xAD 00 Netfilter device in development:
<mailto:rusty@rustcorp.com.au>
<mailto:rusty@rustcorp.com.au>
0xAE all linux/kvm.h Kernel-based Virtual Machine
<mailto:kvm@vger.kernel.org>
0xB0 all RATIO devices in development:
<mailto:vgo@ratio.de>
0xB1 00-1F PPPoX <mailto:mostrows@styx.uwaterloo.ca>
0xC0 00-0F linux/usb/iowarrior.h
0xCB 00-1F CBM serial IEC bus in development:
<mailto:michael.klein@puffin.lb.shuttle.de>
0xCD 01 linux/reiserfs_fs.h
0xCF 02 fs/cifs/ioctl.c
0xDB 00-0F drivers/char/mwave/mwavepub.h
0xDD 00-3F ZFCP device driver see drivers/s390/scsi/
<mailto:aherrman@de.ibm.com>
0xF3 00-3F video/sisfb.h sisfb (in development)
0xF3 00-3F drivers/usb/misc/sisusbvga/sisusb.h sisfb (in development)
<mailto:thomas@winischhofer.net>
0xF4 00-1F video/mbxfb.h mbxfb
<mailto:raph@8d.com>
0xFD all linux/dm-ioctl.h

116
Documentation/isdn/README.gigaset
View File

@ -68,22 +68,38 @@ GigaSet 307x Device Driver
for troubleshooting or to pass module parameters.
The module ser_gigaset provides a serial line discipline N_GIGASET_M101
which drives the device through the regular serial line driver. It must
be attached to the serial line to which the M101 is connected with the
ldattach(8) command (requires util-linux-ng release 2.14 or later), for
example:
ldattach GIGASET_M101 /dev/ttyS1
which uses the regular serial port driver to access the device, and must
therefore be attached to the serial device to which the M101 is connected.
The ldattach(8) command (included in util-linux-ng release 2.14 or later)
can be used for that purpose, for example:
ldattach GIGASET_M101 /dev/ttyS1
This will open the device file, attach the line discipline to it, and
then sleep in the background, keeping the device open so that the line
discipline remains active. To deactivate it, kill the daemon, for example
with
killall ldattach
killall ldattach
before disconnecting the device. To have this happen automatically at
system startup/shutdown on an LSB compatible system, create and activate
an appropriate LSB startup script /etc/init.d/gigaset. (The init name
'gigaset' is officially assigned to this project by LANANA.)
Alternatively, just add the 'ldattach' command line to /etc/rc.local.
The modules accept the following parameters:
Module Parameter Meaning
gigaset debug debug level (see section 3.2.)
startmode initial operation mode (see section 2.5.):
bas_gigaset ) 1=ISDN4linux/CAPI (default), 0=Unimodem
ser_gigaset )
usb_gigaset ) cidmode initial Call-ID mode setting (see section
2.5.): 1=on (default), 0=off
Depending on your distribution you may want to create a separate module
configuration file /etc/modprobe.d/gigaset for these, or add them to a
custom file like /etc/modprobe.conf.local.
2.2. Device nodes for user space programs
------------------------------------
The device can be accessed from user space (eg. by the user space tools
@ -93,11 +109,48 @@ GigaSet 307x Device Driver
- /dev/ttyGU0 for M105 (USB data boxes)
- /dev/ttyGB0 for the base driver (direct USB connection)
You can also select a "default device" which is used by the frontends when
If you connect more than one device of a type, they will get consecutive
device nodes, eg. /dev/ttyGU1 for a second M105.
You can also set a "default device" for the user space tools to use when
no device node is given as parameter, by creating a symlink /dev/ttyG to
one of them, eg.:
ln -s /dev/ttyGB0 /dev/ttyG
ln -s /dev/ttyGB0 /dev/ttyG
The devices accept the following device specific ioctl calls
(defined in gigaset_dev.h):
ioctl(int fd, GIGASET_REDIR, int *cmd);
If cmd==1, the device is set to be controlled exclusively through the
character device node; access from the ISDN subsystem is blocked.
If cmd==0, the device is set to be used from the ISDN subsystem and does
not communicate through the character device node.
ioctl(int fd, GIGASET_CONFIG, int *cmd);
(ser_gigaset and usb_gigaset only)
If cmd==1, the device is set to adapter configuration mode where commands
are interpreted by the M10x DECT adapter itself instead of being
forwarded to the base station. In this mode, the device accepts the
commands described in Siemens document "AT-Kommando Alignment M10x Data"
for setting the operation mode, associating with a base station and
querying parameters like field strengh and signal quality.
Note that there is no ioctl command for leaving adapter configuration
mode and returning to regular operation. In order to leave adapter
configuration mode, write the command ATO to the device.
ioctl(int fd, GIGASET_BRKCHARS, unsigned char brkchars[6]);
(usb_gigaset only)
Set the break characters on an M105's internal serial adapter to the six
bytes stored in brkchars[]. Unused bytes should be set to zero.
ioctl(int fd, GIGASET_VERSION, unsigned version[4]);
Retrieve version information from the driver. version[0] must be set to
one of:
- GIGVER_DRIVER: retrieve driver version
- GIGVER_COMPAT: retrieve interface compatibility version
- GIGVER_FWBASE: retrieve the firmware version of the base
Upon return, version[] is filled with the requested version information.
2.3. ISDN4linux
----------
@ -113,15 +166,24 @@ GigaSet 307x Device Driver
Connection State: 0, Response: -1
gigaset_process_response: resp_code -1 in ConState 0 !
Timeout occurred
you might need to use unimodem mode. (see section 2.5.)
you probably need to use unimodem mode. (see section 2.5.)
2.4. CAPI
----
If the driver is compiled with CAPI support (kernel configuration option
GIGASET_CAPI, experimental) it can also be used with CAPI 2.0 kernel and
user space applications. ISDN4Linux is supported in this configuration
user space applications. For user space access, the module capi.ko must
be loaded. The capiinit command (included in the capi4k-utils package)
does this for you.
The CAPI variant of the driver supports legacy ISDN4Linux applications
via the capidrv compatibility driver. The kernel module capidrv.ko must
be loaded explicitly ("modprobe capidrv") if needed.
be loaded explicitly with the command
modprobe capidrv
if needed, and cannot be unloaded again without unloading the driver
first. (These are limitations of capidrv.)
The note about unimodem mode in the preceding section applies here, too.
2.5. Unimodem mode
-------------
@ -134,9 +196,14 @@ GigaSet 307x Device Driver
You can switch back using
gigacontr --mode isdn
You can also load the driver using e.g.
modprobe usb_gigaset startmode=0
to prevent the driver from starting in "isdn4linux mode".
You can also put the driver directly into Unimodem mode when it's loaded,
by passing the module parameter startmode=0 to the hardware specific
module, e.g.
modprobe usb_gigaset startmode=0
or by adding a line like
options usb_gigaset startmode=0
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
In this mode the device works like a modem connected to a serial port
(the /dev/ttyGU0, ... mentioned above) which understands the commands
@ -164,9 +231,8 @@ GigaSet 307x Device Driver
options ppp_async flag_time=0
to /etc/modprobe.conf. If your distribution has some local module
configuration file like /etc/modprobe.conf.local,
using that should be preferred.
to an appropriate module configuration file, like /etc/modprobe.d/gigaset
or /etc/modprobe.conf.local.
2.6. Call-ID (CID) mode
------------------
@ -189,12 +255,13 @@ GigaSet 307x Device Driver
settings (CID mode).
- If you have several DECT data devices (M10x) which you want to use
in turn, select Unimodem mode by passing the parameter "cidmode=0" to
the driver ("modprobe usb_gigaset cidmode=0" or modprobe.conf).
the appropriate driver module (ser_gigaset or usb_gigaset).
If you want both of these at once, you are out of luck.
You can also use /sys/class/tty/ttyGxy/cidmode for changing the CID mode
setting (ttyGxy is ttyGU0 or ttyGB0).
You can also use the tty class parameter "cidmode" of the device to
change its CID mode while the driver is loaded, eg.
echo 0 > /sys/class/tty/ttyGU0/cidmode
2.7. Unregistered Wireless Devices (M101/M105)
-----------------------------------------
@ -208,7 +275,7 @@ GigaSet 307x Device Driver
driver. In that situation, a restricted set of functions is available
which includes, in particular, those necessary for registering the device
to a base or for switching it between Fixed Part and Portable Part
modes.
modes. See the gigacontr(8) manpage for details.
3. Troubleshooting
---------------
@ -222,9 +289,7 @@ GigaSet 307x Device Driver
options isdn dialtimeout=15
to /etc/modprobe.conf. If your distribution has some local module
configuration file like /etc/modprobe.conf.local,
using that should be preferred.
to /etc/modprobe.d/gigaset, /etc/modprobe.conf.local or a similar file.
Problem:
Your isdn script aborts with a message about isdnlog.
@ -264,7 +329,8 @@ GigaSet 307x Device Driver
The initial value can be set using the debug parameter when loading the
module "gigaset", e.g. by adding a line
options gigaset debug=0
to /etc/modprobe.conf, ...
to your module configuration file, eg. /etc/modprobe.d/gigaset or
/etc/modprobe.conf.local.
Generated debugging information can be found
- as output of the command

14
Documentation/kbuild/kbuild.txt
View File

@ -1,3 +1,17 @@
Output files
modules.order
--------------------------------------------------
This file records the order in which modules appear in Makefiles. This
is used by modprobe to deterministically resolve aliases that match
multiple modules.
modules.builtin
--------------------------------------------------
This file lists all modules that are built into the kernel. This is used
by modprobe to not fail when trying to load something builtin.
Environment variables
KCPPFLAGS

8
Documentation/kbuild/kconfig.txt
View File

@ -103,10 +103,16 @@ KCONFIG_AUTOCONFIG
This environment variable can be set to specify the path & name of the
"auto.conf" file. Its default value is "include/config/auto.conf".
KCONFIG_TRISTATE
--------------------------------------------------
This environment variable can be set to specify the path & name of the
"tristate.conf" file. Its default value is "include/config/tristate.conf".
KCONFIG_AUTOHEADER
--------------------------------------------------
This environment variable can be set to specify the path & name of the
"autoconf.h" (header) file. Its default value is "include/linux/autoconf.h".
"autoconf.h" (header) file.
Its default value is "include/generated/autoconf.h".
======================================================================

12
Documentation/kernel-doc-nano-HOWTO.txt
View File

@ -214,11 +214,13 @@ The format of the block comment is like this:
* (section header: (section description)? )*
(*)?*/
The short function description ***cannot be multiline***, but the other
descriptions can be (and they can contain blank lines). If you continue
that initial short description onto a second line, that second line will
appear further down at the beginning of the description section, which is
almost certainly not what you had in mind.
All "description" text can span multiple lines, although the
function_name & its short description are traditionally on a single line.
Description text may also contain blank lines (i.e., lines that contain
only a "*").
"section header:" names must be unique per function (or struct,
union, typedef, enum).
Avoid putting a spurious blank line after the function name, or else the
description will be repeated!

Some files were not shown because too many files have changed in this diff Show More