Merge branch 'master' of /home/davem/src/GIT/linux-2.6/
This commit is contained in:
David S. Miller
Коммит
6be325719b
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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 <link linkend='v4l2-audio'>v4l2_audio</link>">
|
||||
<!ENTITY v4l2-audioout "struct <link linkend='v4l2-audioout'>v4l2_audioout</link>">
|
||||
<!ENTITY v4l2-bt-timings "struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link>">
|
||||
<!ENTITY v4l2-buffer "struct <link linkend='v4l2-buffer'>v4l2_buffer</link>">
|
||||
<!ENTITY v4l2-capability "struct <link linkend='v4l2-capability'>v4l2_capability</link>">
|
||||
<!ENTITY v4l2-captureparm "struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link>">
|
||||
|
|
@ -128,6 +135,9 @@
|
|||
<!ENTITY v4l2-dbg-chip-ident "struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link>">
|
||||
<!ENTITY v4l2-dbg-match "struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link>">
|
||||
<!ENTITY v4l2-dbg-register "struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link>">
|
||||
<!ENTITY v4l2-dv-enum-preset "struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link>">
|
||||
<!ENTITY v4l2-dv-preset "struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link>">
|
||||
<!ENTITY v4l2-dv-timings "struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link>">
|
||||
<!ENTITY v4l2-enc-idx "struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link>">
|
||||
<!ENTITY v4l2-enc-idx-entry "struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link>">
|
||||
<!ENTITY v4l2-encoder-cmd "struct <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">
|
||||
|
|
@ -333,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">
|
||||
|
|
|
|||
|
|
@ -36,6 +36,7 @@
|
|||
<indexentry><primaryie>enum <link linkend='v4l2-preemphasis'>v4l2_preemphasis</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-audio'>v4l2_audio</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-audioout'>v4l2_audioout</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-bt-timings'>v4l2_bt_timings</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-buffer'>v4l2_buffer</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-capability'>v4l2_capability</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-captureparm'>v4l2_captureparm</link></primaryie></indexentry>
|
||||
|
|
@ -46,6 +47,9 @@
|
|||
<indexentry><primaryie>struct <link linkend='v4l2-dbg-chip-ident'>v4l2_dbg_chip_ident</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-dbg-match'>v4l2_dbg_match</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-dbg-register'>v4l2_dbg_register</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-dv-enum-preset'>v4l2_dv_enum_preset</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-dv-preset'>v4l2_dv_preset</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-dv-timings'>v4l2_dv_timings</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-enc-idx'>v4l2_enc_idx</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-enc-idx-entry'>v4l2_enc_idx_entry</link></primaryie></indexentry>
|
||||
<indexentry><primaryie>struct <link linkend='v4l2-encoder-cmd'>v4l2_encoder_cmd</link></primaryie></indexentry>
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -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 <linux/proc_fs.h>
|
||||
</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>
|
||||
|
|
@ -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");
|
||||
|
|
@ -716,6 +716,41 @@ if (-1 == ioctl (fd, &VIDIOC-S-STD;, &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;
|
||||
|
|
|
|||
|
|
@ -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">
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -733,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->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
|
||||
*/
|
||||
|
|
@ -744,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 */
|
||||
|
|
@ -775,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
|
||||
*/
|
||||
|
|
@ -785,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
|
||||
*/
|
||||
|
|
@ -1626,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! */
|
||||
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
-->
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
-->
|
||||
|
|
@ -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:
|
||||
-->
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
-->
|
||||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -1,9 +1,6 @@
|
|||
00-INDEX
|
||||
- This file
|
||||
|
||||
cache-lock.txt
|
||||
- HOWTO for blackfin cache locking.
|
||||
|
||||
cachefeatures.txt
|
||||
- Supported cache features.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,6 @@
|
|||
obj-m := gptimers-example.o
|
||||
|
||||
all: modules
|
||||
|
||||
modules clean:
|
||||
$(MAKE) -C ../.. SUBDIRS=$(PWD) $@
|
||||
|
|
@ -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.
|
||||
|
|
@ -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();
|
||||
|
|
|
|||
|
|
@ -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");
|
||||
|
|
@ -1,7 +1,5 @@
|
|||
00-INDEX
|
||||
- This file
|
||||
as-iosched.txt
|
||||
- Anticipatory IO scheduler
|
||||
barrier.txt
|
||||
- I/O Barriers
|
||||
biodoc.txt
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -103,6 +103,7 @@ gconf
|
|||
gen-devlist
|
||||
gen_crc32table
|
||||
gen_init_cpio
|
||||
generated
|
||||
genheaders
|
||||
genksyms
|
||||
*_gray256.c
|
||||
|
|
|
|||
|
|
@ -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 *);
|
||||
|
|
|
|||
|
|
@ -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]
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -490,3 +474,71 @@ 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>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: usbvideo quickcam_messenger driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/usbvideo/quickcam_messenger.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv06xx
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ov511 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ov511.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: w9968cf v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/w9968cf*.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_ov519
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: ovcamchip sensor framework
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/ovcamchip/*
|
||||
Why: Only used by obsoleted v4l1 drivers
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: stv680 v4l1 driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/stv680.[ch]
|
||||
Why: obsolete v4l1 driver replaced by gspca_stv0680
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
||||
----------------------------
|
||||
|
||||
What: zc0301 v4l driver
|
||||
When: 2.6.35
|
||||
Files: drivers/media/video/zc0301/*
|
||||
Why: Duplicate functionality with the gspca_zc3xx driver, zc0301 only
|
||||
supports 2 USB-ID's (because it only supports a limited set of
|
||||
sensors) wich are also supported by the gspca_zc3xx driver
|
||||
(which supports 53 USB-ID's in total)
|
||||
Who: Hans de Goede <hdegoede@redhat.com>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -68,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
|
||||
|
|
@ -92,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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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
|
||||
=======
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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;
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -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 *);
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -531,6 +531,13 @@ and have the following read/write attributes:
|
|||
This file exists only if the pin can be configured as an
|
||||
interrupt generating input pin.
|
||||
|
||||
"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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
-------------------
|
||||
|
|
|
|||
|
|
@ -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 */
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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".
|
||||
|
||||
|
||||
======================================================================
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -240,7 +240,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
|
||||
acpi_sleep= [HW,ACPI] Sleep options
|
||||
Format: { s3_bios, s3_mode, s3_beep, s4_nohwsig,
|
||||
old_ordering, s4_nonvs }
|
||||
old_ordering, s4_nonvs, sci_force_enable }
|
||||
See Documentation/power/video.txt for information on
|
||||
s3_bios and s3_mode.
|
||||
s3_beep is for debugging; it makes the PC's speaker beep
|
||||
|
|
@ -253,6 +253,9 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
of _PTS is used by default).
|
||||
s4_nonvs prevents the kernel from saving/restoring the
|
||||
ACPI NVS memory during hibernation.
|
||||
sci_force_enable causes the kernel to set SCI_EN directly
|
||||
on resume from S1/S3 (which is against the ACPI spec,
|
||||
but some broken systems don't work without it).
|
||||
|
||||
acpi_use_timer_override [HW,ACPI]
|
||||
Use timer override. For some broken Nvidia NF5 boards
|
||||
|
|
@ -1032,7 +1035,7 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
No delay
|
||||
|
||||
ip= [IP_PNP]
|
||||
See Documentation/filesystems/nfsroot.txt.
|
||||
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||
|
||||
ip2= [HW] Set IO/IRQ pairs for up to 4 IntelliPort boards
|
||||
See comment before ip2_setup() in
|
||||
|
|
@ -1553,10 +1556,10 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
going to be removed in 2.6.29.
|
||||
|
||||
nfsaddrs= [NFS]
|
||||
See Documentation/filesystems/nfsroot.txt.
|
||||
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||
|
||||
nfsroot= [NFS] nfs root filesystem for disk-less boxes.
|
||||
See Documentation/filesystems/nfsroot.txt.
|
||||
See Documentation/filesystems/nfs/nfsroot.txt.
|
||||
|
||||
nfs.callback_tcpport=
|
||||
[NFS] set the TCP port on which the NFSv4 callback
|
||||
|
|
@ -1787,6 +1790,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
waiting for the ACK, so if this is set too high
|
||||
interrupts *may* be lost!
|
||||
|
||||
omap_mux= [OMAP] Override bootloader pin multiplexing.
|
||||
Format: <mux_mode0.mode_name=value>...
|
||||
For example, to override I2C bus2:
|
||||
omap_mux=i2c2_scl.i2c2_scl=0x100,i2c2_sda.i2c2_sda=0x100
|
||||
|
||||
opl3= [HW,OSS]
|
||||
Format: <io>
|
||||
|
||||
|
|
@ -2724,6 +2732,11 @@ and is between 256 and 4096 characters. It is defined in the file
|
|||
vmpoff= [KNL,S390] Perform z/VM CP command after power off.
|
||||
Format: <command>
|
||||
|
||||
vt.cur_default= [VT] Default cursor shape.
|
||||
Format: 0xCCBBAA, where AA, BB, and CC are the same as
|
||||
the parameters of the <Esc>[?A;B;Cc escape sequence;
|
||||
see VGA-softcursor.txt. Default: 2 = underline.
|
||||
|
||||
vt.default_blu= [VT]
|
||||
Format: <blue0>,<blue1>,<blue2>,...,<blue15>
|
||||
Change the default blue palette of the console.
|
||||
|
|
|
|||
|
|
@ -685,7 +685,7 @@ struct kvm_vcpu_events {
|
|||
__u8 pad;
|
||||
} nmi;
|
||||
__u32 sipi_vector;
|
||||
__u32 flags; /* must be zero */
|
||||
__u32 flags;
|
||||
};
|
||||
|
||||
4.30 KVM_SET_VCPU_EVENTS
|
||||
|
|
@ -701,6 +701,14 @@ vcpu.
|
|||
|
||||
See KVM_GET_VCPU_EVENTS for the data structure.
|
||||
|
||||
Fields that may be modified asynchronously by running VCPUs can be excluded
|
||||
from the update. These fields are nmi.pending and sipi_vector. Keep the
|
||||
corresponding bits in the flags field cleared to suppress overwriting the
|
||||
current in-kernel state. The bits are:
|
||||
|
||||
KVM_VCPUEVENT_VALID_NMI_PENDING - transfer nmi.pending to the kernel
|
||||
KVM_VCPUEVENT_VALID_SIPI_VECTOR - transfer sipi_vector
|
||||
|
||||
|
||||
5. The kvm_run structure
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
ThinkPad ACPI Extras Driver
|
||||
|
||||
Version 0.23
|
||||
April 10th, 2009
|
||||
Version 0.24
|
||||
December 11th, 2009
|
||||
|
||||
Borislav Deianov <borislav@users.sf.net>
|
||||
Henrique de Moraes Holschuh <hmh@hmh.eng.br>
|
||||
|
|
@ -460,6 +460,8 @@ event code Key Notes
|
|||
For Lenovo ThinkPads with a new
|
||||
BIOS, it has to be handled either
|
||||
by the ACPI OSI, or by userspace.
|
||||
The driver does the right thing,
|
||||
never mess with this.
|
||||
0x1011 0x10 FN+END Brightness down. See brightness
|
||||
up for details.
|
||||
|
||||
|
|
@ -582,46 +584,15 @@ with hotkey_report_mode.
|
|||
|
||||
Brightness hotkey notes:
|
||||
|
||||
These are the current sane choices for brightness key mapping in
|
||||
thinkpad-acpi:
|
||||
Don't mess with the brightness hotkeys in a Thinkpad. If you want
|
||||
notifications for OSD, use the sysfs backlight class event support.
|
||||
|
||||
For IBM and Lenovo models *without* ACPI backlight control (the ones on
|
||||
which thinkpad-acpi will autoload its backlight interface by default,
|
||||
and on which ACPI video does not export a backlight interface):
|
||||
|
||||
1. Don't enable or map the brightness hotkeys in thinkpad-acpi, as
|
||||
these older firmware versions unfortunately won't respect the hotkey
|
||||
mask for brightness keys anyway, and always reacts to them. This
|
||||
usually work fine, unless X.org drivers are doing something to block
|
||||
the BIOS. In that case, use (3) below. This is the default mode of
|
||||
operation.
|
||||
|
||||
2. Enable the hotkeys, but map them to something else that is NOT
|
||||
KEY_BRIGHTNESS_UP/DOWN or any other keycode that would cause
|
||||
userspace to try to change the backlight level, and use that as an
|
||||
on-screen-display hint.
|
||||
|
||||
3. IF AND ONLY IF X.org drivers find a way to block the firmware from
|
||||
automatically changing the brightness, enable the hotkeys and map
|
||||
them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN, and feed that to
|
||||
something that calls xbacklight. thinkpad-acpi will not be able to
|
||||
change brightness in that case either, so you should disable its
|
||||
backlight interface.
|
||||
|
||||
For Lenovo models *with* ACPI backlight control:
|
||||
|
||||
1. Load up ACPI video and use that. ACPI video will report ACPI
|
||||
events for brightness change keys. Do not mess with thinkpad-acpi
|
||||
defaults in this case. thinkpad-acpi should not have anything to do
|
||||
with backlight events in a scenario where ACPI video is loaded:
|
||||
brightness hotkeys must be disabled, and the backlight interface is
|
||||
to be kept disabled as well. This is the default mode of operation.
|
||||
|
||||
2. Do *NOT* load up ACPI video, enable the hotkeys in thinkpad-acpi,
|
||||
and map them to KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN. Process
|
||||
these keys on userspace somehow (e.g. by calling xbacklight).
|
||||
The driver will do this automatically if it detects that ACPI video
|
||||
has been disabled.
|
||||
The driver will issue KEY_BRIGHTNESS_UP and KEY_BRIGHTNESS_DOWN events
|
||||
automatically for the cases were userspace has to do something to
|
||||
implement brightness changes. When you override these events, you will
|
||||
either fail to handle properly the ThinkPads that require explicit
|
||||
action to change backlight brightness, or the ThinkPads that require
|
||||
that no action be taken to work properly.
|
||||
|
||||
|
||||
Bluetooth
|
||||
|
|
@ -1121,25 +1092,103 @@ WARNING:
|
|||
its level up and down at every change.
|
||||
|
||||
|
||||
Volume control -- /proc/acpi/ibm/volume
|
||||
---------------------------------------
|
||||
Volume control (Console Audio control)
|
||||
--------------------------------------
|
||||
|
||||
This feature allows volume control on ThinkPad models which don't have
|
||||
a hardware volume knob. The available commands are:
|
||||
procfs: /proc/acpi/ibm/volume
|
||||
ALSA: "ThinkPad Console Audio Control", default ID: "ThinkPadEC"
|
||||
|
||||
NOTE: by default, the volume control interface operates in read-only
|
||||
mode, as it is supposed to be used for on-screen-display purposes.
|
||||
The read/write mode can be enabled through the use of the
|
||||
"volume_control=1" module parameter.
|
||||
|
||||
NOTE: distros are urged to not enable volume_control by default, this
|
||||
should be done by the local admin only. The ThinkPad UI is for the
|
||||
console audio control to be done through the volume keys only, and for
|
||||
the desktop environment to just provide on-screen-display feedback.
|
||||
Software volume control should be done only in the main AC97/HDA
|
||||
mixer.
|
||||
|
||||
|
||||
About the ThinkPad Console Audio control:
|
||||
|
||||
ThinkPads have a built-in amplifier and muting circuit that drives the
|
||||
console headphone and speakers. This circuit is after the main AC97
|
||||
or HDA mixer in the audio path, and under exclusive control of the
|
||||
firmware.
|
||||
|
||||
ThinkPads have three special hotkeys to interact with the console
|
||||
audio control: volume up, volume down and mute.
|
||||
|
||||
It is worth noting that the normal way the mute function works (on
|
||||
ThinkPads that do not have a "mute LED") is:
|
||||
|
||||
1. Press mute to mute. It will *always* mute, you can press it as
|
||||
many times as you want, and the sound will remain mute.
|
||||
|
||||
2. Press either volume key to unmute the ThinkPad (it will _not_
|
||||
change the volume, it will just unmute).
|
||||
|
||||
This is a very superior design when compared to the cheap software-only
|
||||
mute-toggle solution found on normal consumer laptops: you can be
|
||||
absolutely sure the ThinkPad will not make noise if you press the mute
|
||||
button, no matter the previous state.
|
||||
|
||||
The IBM ThinkPads, and the earlier Lenovo ThinkPads have variable-gain
|
||||
amplifiers driving the speakers and headphone output, and the firmware
|
||||
also handles volume control for the headphone and speakers on these
|
||||
ThinkPads without any help from the operating system (this volume
|
||||
control stage exists after the main AC97 or HDA mixer in the audio
|
||||
path).
|
||||
|
||||
The newer Lenovo models only have firmware mute control, and depend on
|
||||
the main HDA mixer to do volume control (which is done by the operating
|
||||
system). In this case, the volume keys are filtered out for unmute
|
||||
key press (there are some firmware bugs in this area) and delivered as
|
||||
normal key presses to the operating system (thinkpad-acpi is not
|
||||
involved).
|
||||
|
||||
|
||||
The ThinkPad-ACPI volume control:
|
||||
|
||||
The preferred way to interact with the Console Audio control is the
|
||||
ALSA interface.
|
||||
|
||||
The legacy procfs interface allows one to read the current state,
|
||||
and if volume control is enabled, accepts the following commands:
|
||||
|
||||
echo up >/proc/acpi/ibm/volume
|
||||
echo down >/proc/acpi/ibm/volume
|
||||
echo mute >/proc/acpi/ibm/volume
|
||||
echo unmute >/proc/acpi/ibm/volume
|
||||
echo 'level <level>' >/proc/acpi/ibm/volume
|
||||
|
||||
The <level> number range is 0 to 15 although not all of them may be
|
||||
distinct. The unmute the volume after the mute command, use either the
|
||||
up or down command (the level command will not unmute the volume).
|
||||
The current volume level and mute state is shown in the file.
|
||||
The <level> number range is 0 to 14 although not all of them may be
|
||||
distinct. To unmute the volume after the mute command, use either the
|
||||
up or down command (the level command will not unmute the volume), or
|
||||
the unmute command.
|
||||
|
||||
The ALSA mixer interface to this feature is still missing, but patches
|
||||
to add it exist. That problem should be addressed in the not so
|
||||
distant future.
|
||||
You can use the volume_capabilities parameter to tell the driver
|
||||
whether your thinkpad has volume control or mute-only control:
|
||||
volume_capabilities=1 for mixers with mute and volume control,
|
||||
volume_capabilities=2 for mixers with only mute control.
|
||||
|
||||
If the driver misdetects the capabilities for your ThinkPad model,
|
||||
please report this to ibm-acpi-devel@lists.sourceforge.net, so that we
|
||||
can update the driver.
|
||||
|
||||
There are two strategies for volume control. To select which one
|
||||
should be used, use the volume_mode module parameter: volume_mode=1
|
||||
selects EC mode, and volume_mode=3 selects EC mode with NVRAM backing
|
||||
(so that volume/mute changes are remembered across shutdown/reboot).
|
||||
|
||||
The driver will operate in volume_mode=3 by default. If that does not
|
||||
work well on your ThinkPad model, please report this to
|
||||
ibm-acpi-devel@lists.sourceforge.net.
|
||||
|
||||
The driver supports the standard ALSA module parameters. If the ALSA
|
||||
mixer is disabled, the driver will disable all volume functionality.
|
||||
|
||||
|
||||
Fan control and monitoring: fan speed, fan enable/disable
|
||||
|
|
@ -1405,6 +1454,7 @@ to enable more than one output class, just add their values.
|
|||
0x0008 HKEY event interface, hotkeys
|
||||
0x0010 Fan control
|
||||
0x0020 Backlight brightness
|
||||
0x0040 Audio mixer/volume control
|
||||
|
||||
There is also a kernel build option to enable more debugging
|
||||
information, which may be necessary to debug driver problems.
|
||||
|
|
@ -1465,3 +1515,9 @@ Sysfs interface changelog:
|
|||
and it is always able to disable hot keys. Very old
|
||||
thinkpads are properly supported. hotkey_bios_mask
|
||||
is deprecated and marked for removal.
|
||||
|
||||
0x020600: Marker for backlight change event support.
|
||||
|
||||
0x020700: Support for mute-only mixers.
|
||||
Volume control in read-only mode by default.
|
||||
Marker for ALSA mixer support.
|
||||
|
|
|
|||
|
|
@ -62,8 +62,20 @@ applicable).
|
|||
It also tracks 4 contention points per class. A contention point is a call site
|
||||
that had to wait on lock acquisition.
|
||||
|
||||
- CONFIGURATION
|
||||
|
||||
Lock statistics are enabled via CONFIG_LOCK_STATS.
|
||||
|
||||
- USAGE
|
||||
|
||||
Enable collection of statistics:
|
||||
|
||||
# echo 1 >/proc/sys/kernel/lock_stat
|
||||
|
||||
Disable collection of statistics:
|
||||
|
||||
# echo 0 >/proc/sys/kernel/lock_stat
|
||||
|
||||
Look at the current lock statistics:
|
||||
|
||||
( line numbers not part of actual output, done for clarity in the explanation
|
||||
|
|
|
|||
|
|
@ -233,9 +233,9 @@ All md devices contain:
|
|||
|
||||
resync_start
|
||||
The point at which resync should start. If no resync is needed,
|
||||
this will be a very large number. At array creation it will
|
||||
default to 0, though starting the array as 'clean' will
|
||||
set it much larger.
|
||||
this will be a very large number (or 'none' since 2.6.30-rc1). At
|
||||
array creation it will default to 0, though starting the array as
|
||||
'clean' will set it much larger.
|
||||
|
||||
new_dev
|
||||
This file can be written but not read. The value written should
|
||||
|
|
@ -296,6 +296,51 @@ All md devices contain:
|
|||
active-idle
|
||||
like active, but no writes have been seen for a while (safe_mode_delay).
|
||||
|
||||
bitmap/location
|
||||
This indicates where the write-intent bitmap for the array is
|
||||
stored.
|
||||
It can be one of "none", "file" or "[+-]N".
|
||||
"file" may later be extended to "file:/file/name"
|
||||
"[+-]N" means that many sectors from the start of the metadata.
|
||||
This is replicated on all devices. For arrays with externally
|
||||
managed metadata, the offset is from the beginning of the
|
||||
device.
|
||||
bitmap/chunksize
|
||||
The size, in bytes, of the chunk which will be represented by a
|
||||
single bit. For RAID456, it is a portion of an individual
|
||||
device. For RAID10, it is a portion of the array. For RAID1, it
|
||||
is both (they come to the same thing).
|
||||
bitmap/time_base
|
||||
The time, in seconds, between looking for bits in the bitmap to
|
||||
be cleared. In the current implementation, a bit will be cleared
|
||||
between 2 and 3 times "time_base" after all the covered blocks
|
||||
are known to be in-sync.
|
||||
bitmap/backlog
|
||||
When write-mostly devices are active in a RAID1, write requests
|
||||
to those devices proceed in the background - the filesystem (or
|
||||
other user of the device) does not have to wait for them.
|
||||
'backlog' sets a limit on the number of concurrent background
|
||||
writes. If there are more than this, new writes will by
|
||||
synchronous.
|
||||
bitmap/metadata
|
||||
This can be either 'internal' or 'external'.
|
||||
'internal' is the default and means the metadata for the bitmap
|
||||
is stored in the first 256 bytes of the allocated space and is
|
||||
managed by the md module.
|
||||
'external' means that bitmap metadata is managed externally to
|
||||
the kernel (i.e. by some userspace program)
|
||||
bitmap/can_clear
|
||||
This is either 'true' or 'false'. If 'true', then bits in the
|
||||
bitmap will be cleared when the corresponding blocks are thought
|
||||
to be in-sync. If 'false', bits will never be cleared.
|
||||
This is automatically set to 'false' if a write happens on a
|
||||
degraded array, or if the array becomes degraded during a write.
|
||||
When metadata is managed externally, it should be set to true
|
||||
once the array becomes non-degraded, and this fact has been
|
||||
recorded in the metadata.
|
||||
|
||||
|
||||
|
||||
|
||||
As component devices are added to an md array, they appear in the 'md'
|
||||
directory as new directories named
|
||||
|
|
@ -334,8 +379,9 @@ Each directory contains:
|
|||
Writing "writemostly" sets the writemostly flag.
|
||||
Writing "-writemostly" clears the writemostly flag.
|
||||
Writing "blocked" sets the "blocked" flag.
|
||||
Writing "-blocked" clear the "blocked" flag and allows writes
|
||||
Writing "-blocked" clears the "blocked" flag and allows writes
|
||||
to complete.
|
||||
Writing "in_sync" sets the in_sync flag.
|
||||
|
||||
This file responds to select/poll. Any change to 'faulty'
|
||||
or 'blocked' causes an event.
|
||||
|
|
@ -372,6 +418,24 @@ Each directory contains:
|
|||
array. If a value less than the current component_size is
|
||||
written, it will be rejected.
|
||||
|
||||
recovery_start
|
||||
|
||||
When the device is not 'in_sync', this records the number of
|
||||
sectors from the start of the device which are known to be
|
||||
correct. This is normally zero, but during a recovery
|
||||
operation is will steadily increase, and if the recovery is
|
||||
interrupted, restoring this value can cause recovery to
|
||||
avoid repeating the earlier blocks. With v1.x metadata, this
|
||||
value is saved and restored automatically.
|
||||
|
||||
This can be set whenever the device is not an active member of
|
||||
the array, either before the array is activated, or before
|
||||
the 'slot' is set.
|
||||
|
||||
Setting this to 'none' is equivalent to setting 'in_sync'.
|
||||
Setting to any other value also clears the 'in_sync' flag.
|
||||
|
||||
|
||||
|
||||
An active md device will also contain and entry for each active device
|
||||
in the array. These are named
|
||||
|
|
|
|||
|
|
@ -160,12 +160,15 @@ Under each section, you can see 4 files.
|
|||
NOTE:
|
||||
These directories/files appear after physical memory hotplug phase.
|
||||
|
||||
If CONFIG_NUMA is enabled the
|
||||
/sys/devices/system/memory/memoryXXX memory section
|
||||
directories can also be accessed via symbolic links located in
|
||||
the /sys/devices/system/node/node* directories. For example:
|
||||
If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed
|
||||
via symbolic links located in the /sys/devices/system/node/node* directories.
|
||||
|
||||
For example:
|
||||
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||
|
||||
A backlink will also be created:
|
||||
/sys/devices/system/memory/memory9/node0 -> ../../node/node0
|
||||
|
||||
--------------------------------
|
||||
4. Physical memory hot-add phase
|
||||
--------------------------------
|
||||
|
|
|
|||
|
|
@ -0,0 +1,57 @@
|
|||
---------------------------------
|
||||
AD525x Digital Potentiometers
|
||||
---------------------------------
|
||||
|
||||
The ad525x_dpot driver exports a simple sysfs interface. This allows you to
|
||||
work with the immediate resistance settings as well as update the saved startup
|
||||
settings. Access to the factory programmed tolerance is also provided, but
|
||||
interpretation of this settings is required by the end application according to
|
||||
the specific part in use.
|
||||
|
||||
---------
|
||||
Files
|
||||
---------
|
||||
|
||||
Each dpot device will have a set of eeprom, rdac, and tolerance files. How
|
||||
many depends on the actual part you have, as will the range of allowed values.
|
||||
|
||||
The eeprom files are used to program the startup value of the device.
|
||||
|
||||
The rdac files are used to program the immediate value of the device.
|
||||
|
||||
The tolerance files are the read-only factory programmed tolerance settings
|
||||
and may vary greatly on a part-by-part basis. For exact interpretation of
|
||||
this field, please consult the datasheet for your part. This is presented
|
||||
as a hex file for easier parsing.
|
||||
|
||||
-----------
|
||||
Example
|
||||
-----------
|
||||
|
||||
Locate the device in your sysfs tree. This is probably easiest by going into
|
||||
the common i2c directory and locating the device by the i2c slave address.
|
||||
|
||||
# ls /sys/bus/i2c/devices/
|
||||
0-0022 0-0027 0-002f
|
||||
|
||||
So assuming the device in question is on the first i2c bus and has the slave
|
||||
address of 0x2f, we descend (unrelated sysfs entries have been trimmed).
|
||||
|
||||
# ls /sys/bus/i2c/devices/0-002f/
|
||||
eeprom0 rdac0 tolerance0
|
||||
|
||||
You can use simple reads/writes to access these files:
|
||||
|
||||
# cd /sys/bus/i2c/devices/0-002f/
|
||||
|
||||
# cat eeprom0
|
||||
0
|
||||
# echo 10 > eeprom0
|
||||
# cat eeprom0
|
||||
10
|
||||
|
||||
# cat rdac0
|
||||
5
|
||||
# echo 3 > rdac0
|
||||
# cat rdac0
|
||||
3
|
||||
|
|
@ -119,6 +119,32 @@ FURTHER NOTES ON NO-MMU MMAP
|
|||
granule but will only discard the excess if appropriately configured as
|
||||
this has an effect on fragmentation.
|
||||
|
||||
(*) The memory allocated by a request for an anonymous mapping will normally
|
||||
be cleared by the kernel before being returned in accordance with the
|
||||
Linux man pages (ver 2.22 or later).
|
||||
|
||||
In the MMU case this can be achieved with reasonable performance as
|
||||
regions are backed by virtual pages, with the contents only being mapped
|
||||
to cleared physical pages when a write happens on that specific page
|
||||
(prior to which, the pages are effectively mapped to the global zero page
|
||||
from which reads can take place). This spreads out the time it takes to
|
||||
initialize the contents of a page - depending on the write-usage of the
|
||||
mapping.
|
||||
|
||||
In the no-MMU case, however, anonymous mappings are backed by physical
|
||||
pages, and the entire map is cleared at allocation time. This can cause
|
||||
significant delays during a userspace malloc() as the C library does an
|
||||
anonymous mapping and the kernel then does a memset for the entire map.
|
||||
|
||||
However, for memory that isn't required to be precleared - such as that
|
||||
returned by malloc() - mmap() can take a MAP_UNINITIALIZED flag to
|
||||
indicate to the kernel that it shouldn't bother clearing the memory before
|
||||
returning it. Note that CONFIG_MMAP_ALLOW_UNINITIALIZED must be enabled
|
||||
to permit this, otherwise the flag will be ignored.
|
||||
|
||||
uClibc uses this to speed up malloc(), and the ELF-FDPIC binfmt uses this
|
||||
to allocate the brk and stack region.
|
||||
|
||||
(*) A list of all the private copy and anonymous mappings on the system is
|
||||
visible through /proc/maps in no-MMU mode.
|
||||
|
||||
|
|
|
|||
|
|
@ -42,80 +42,81 @@ struct dev_pm_ops {
|
|||
...
|
||||
};
|
||||
|
||||
The ->runtime_suspend() callback is executed by the PM core for the bus type of
|
||||
the device being suspended. The bus type's callback is then _entirely_
|
||||
_responsible_ for handling the device as appropriate, which may, but need not
|
||||
include executing the device driver's own ->runtime_suspend() callback (from the
|
||||
PM core's point of view it is not necessary to implement a ->runtime_suspend()
|
||||
callback in a device driver as long as the bus type's ->runtime_suspend() knows
|
||||
what to do to handle the device).
|
||||
The ->runtime_suspend(), ->runtime_resume() and ->runtime_idle() callbacks are
|
||||
executed by the PM core for either the bus type, or device type (if the bus
|
||||
type's callback is not defined), or device class (if the bus type's and device
|
||||
type's callbacks are not defined) of given device. The bus type, device type
|
||||
and device class callbacks are referred to as subsystem-level callbacks in what
|
||||
follows.
|
||||
|
||||
* Once the bus type's ->runtime_suspend() callback has completed successfully
|
||||
The subsystem-level suspend callback is _entirely_ _responsible_ for handling
|
||||
the suspend of the device as appropriate, which may, but need not include
|
||||
executing the device driver's own ->runtime_suspend() callback (from the
|
||||
PM core's point of view it is not necessary to implement a ->runtime_suspend()
|
||||
callback in a device driver as long as the subsystem-level suspend callback
|
||||
knows what to do to handle the device).
|
||||
|
||||
* Once the subsystem-level suspend callback has completed successfully
|
||||
for given device, the PM core regards the device as suspended, which need
|
||||
not mean that the device has been put into a low power state. It is
|
||||
supposed to mean, however, that the device will not process data and will
|
||||
not communicate with the CPU(s) and RAM until its bus type's
|
||||
->runtime_resume() callback is executed for it. The run-time PM status of
|
||||
a device after successful execution of its bus type's ->runtime_suspend()
|
||||
callback is 'suspended'.
|
||||
not communicate with the CPU(s) and RAM until the subsystem-level resume
|
||||
callback is executed for it. The run-time PM status of a device after
|
||||
successful execution of the subsystem-level suspend callback is 'suspended'.
|
||||
|
||||
* If the bus type's ->runtime_suspend() callback returns -EBUSY or -EAGAIN,
|
||||
the device's run-time PM status is supposed to be 'active', which means that
|
||||
the device _must_ be fully operational afterwards.
|
||||
* If the subsystem-level suspend callback returns -EBUSY or -EAGAIN,
|
||||
the device's run-time PM status is 'active', which means that the device
|
||||
_must_ be fully operational afterwards.
|
||||
|
||||
* If the bus type's ->runtime_suspend() callback returns an error code
|
||||
different from -EBUSY or -EAGAIN, the PM core regards this as a fatal
|
||||
error and will refuse to run the helper functions described in Section 4
|
||||
for the device, until the status of it is directly set either to 'active'
|
||||
or to 'suspended' (the PM core provides special helper functions for this
|
||||
purpose).
|
||||
* If the subsystem-level suspend callback returns an error code different
|
||||
from -EBUSY or -EAGAIN, the PM core regards this as a fatal error and will
|
||||
refuse to run the helper functions described in Section 4 for the device,
|
||||
until the status of it is directly set either to 'active', or to 'suspended'
|
||||
(the PM core provides special helper functions for this purpose).
|
||||
|
||||
In particular, if the driver requires remote wakeup capability for proper
|
||||
functioning and device_run_wake() returns 'false' for the device, then
|
||||
->runtime_suspend() should return -EBUSY. On the other hand, if
|
||||
device_run_wake() returns 'true' for the device and the device is put
|
||||
into a low power state during the execution of its bus type's
|
||||
->runtime_suspend(), it is expected that remote wake-up (i.e. hardware mechanism
|
||||
allowing the device to request a change of its power state, such as PCI PME)
|
||||
will be enabled for the device. Generally, remote wake-up should be enabled
|
||||
for all input devices put into a low power state at run time.
|
||||
In particular, if the driver requires remote wake-up capability (i.e. hardware
|
||||
mechanism allowing the device to request a change of its power state, such as
|
||||
PCI PME) for proper functioning and device_run_wake() returns 'false' for the
|
||||
device, then ->runtime_suspend() should return -EBUSY. On the other hand, if
|
||||
device_run_wake() returns 'true' for the device and the device is put into a low
|
||||
power state during the execution of the subsystem-level suspend callback, it is
|
||||
expected that remote wake-up will be enabled for the device. Generally, remote
|
||||
wake-up should be enabled for all input devices put into a low power state at
|
||||
run time.
|
||||
|
||||
The ->runtime_resume() callback is executed by the PM core for the bus type of
|
||||
the device being woken up. The bus type's callback is then _entirely_
|
||||
_responsible_ for handling the device as appropriate, which may, but need not
|
||||
include executing the device driver's own ->runtime_resume() callback (from the
|
||||
PM core's point of view it is not necessary to implement a ->runtime_resume()
|
||||
callback in a device driver as long as the bus type's ->runtime_resume() knows
|
||||
what to do to handle the device).
|
||||
The subsystem-level resume callback is _entirely_ _responsible_ for handling the
|
||||
resume of the device as appropriate, which may, but need not include executing
|
||||
the device driver's own ->runtime_resume() callback (from the PM core's point of
|
||||
view it is not necessary to implement a ->runtime_resume() callback in a device
|
||||
driver as long as the subsystem-level resume callback knows what to do to handle
|
||||
the device).
|
||||
|
||||
* Once the bus type's ->runtime_resume() callback has completed successfully,
|
||||
the PM core regards the device as fully operational, which means that the
|
||||
device _must_ be able to complete I/O operations as needed. The run-time
|
||||
PM status of the device is then 'active'.
|
||||
* Once the subsystem-level resume callback has completed successfully, the PM
|
||||
core regards the device as fully operational, which means that the device
|
||||
_must_ be able to complete I/O operations as needed. The run-time PM status
|
||||
of the device is then 'active'.
|
||||
|
||||
* If the bus type's ->runtime_resume() callback returns an error code, the PM
|
||||
core regards this as a fatal error and will refuse to run the helper
|
||||
functions described in Section 4 for the device, until its status is
|
||||
directly set either to 'active' or to 'suspended' (the PM core provides
|
||||
special helper functions for this purpose).
|
||||
* If the subsystem-level resume callback returns an error code, the PM core
|
||||
regards this as a fatal error and will refuse to run the helper functions
|
||||
described in Section 4 for the device, until its status is directly set
|
||||
either to 'active' or to 'suspended' (the PM core provides special helper
|
||||
functions for this purpose).
|
||||
|
||||
The ->runtime_idle() callback is executed by the PM core for the bus type of
|
||||
given device whenever the device appears to be idle, which is indicated to the
|
||||
PM core by two counters, the device's usage counter and the counter of 'active'
|
||||
children of the device.
|
||||
The subsystem-level idle callback is executed by the PM core whenever the device
|
||||
appears to be idle, which is indicated to the PM core by two counters, the
|
||||
device's usage counter and the counter of 'active' children of the device.
|
||||
|
||||
* If any of these counters is decreased using a helper function provided by
|
||||
the PM core and it turns out to be equal to zero, the other counter is
|
||||
checked. If that counter also is equal to zero, the PM core executes the
|
||||
device bus type's ->runtime_idle() callback (with the device as an
|
||||
argument).
|
||||
subsystem-level idle callback with the device as an argument.
|
||||
|
||||
The action performed by a bus type's ->runtime_idle() callback is totally
|
||||
dependent on the bus type in question, but the expected and recommended action
|
||||
is to check if the device can be suspended (i.e. if all of the conditions
|
||||
necessary for suspending the device are satisfied) and to queue up a suspend
|
||||
request for the device in that case. The value returned by this callback is
|
||||
ignored by the PM core.
|
||||
The action performed by a subsystem-level idle callback is totally dependent on
|
||||
the subsystem in question, but the expected and recommended action is to check
|
||||
if the device can be suspended (i.e. if all of the conditions necessary for
|
||||
suspending the device are satisfied) and to queue up a suspend request for the
|
||||
device in that case. The value returned by this callback is ignored by the PM
|
||||
core.
|
||||
|
||||
The helper functions provided by the PM core, described in Section 4, guarantee
|
||||
that the following constraints are met with respect to the bus type's run-time
|
||||
|
|
@ -238,41 +239,41 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
|
|||
removing the device from device hierarchy
|
||||
|
||||
int pm_runtime_idle(struct device *dev);
|
||||
- execute ->runtime_idle() for the device's bus type; returns 0 on success
|
||||
or error code on failure, where -EINPROGRESS means that ->runtime_idle()
|
||||
is already being executed
|
||||
- execute the subsystem-level idle callback for the device; returns 0 on
|
||||
success or error code on failure, where -EINPROGRESS means that
|
||||
->runtime_idle() is already being executed
|
||||
|
||||
int pm_runtime_suspend(struct device *dev);
|
||||
- execute ->runtime_suspend() for the device's bus type; returns 0 on
|
||||
- execute the subsystem-level suspend callback for the device; returns 0 on
|
||||
success, 1 if the device's run-time PM status was already 'suspended', or
|
||||
error code on failure, where -EAGAIN or -EBUSY means it is safe to attempt
|
||||
to suspend the device again in future
|
||||
|
||||
int pm_runtime_resume(struct device *dev);
|
||||
- execute ->runtime_resume() for the device's bus type; returns 0 on
|
||||
- execute the subsystem-leve resume callback for the device; returns 0 on
|
||||
success, 1 if the device's run-time PM status was already 'active' or
|
||||
error code on failure, where -EAGAIN means it may be safe to attempt to
|
||||
resume the device again in future, but 'power.runtime_error' should be
|
||||
checked additionally
|
||||
|
||||
int pm_request_idle(struct device *dev);
|
||||
- submit a request to execute ->runtime_idle() for the device's bus type
|
||||
(the request is represented by a work item in pm_wq); returns 0 on success
|
||||
or error code if the request has not been queued up
|
||||
- submit a request to execute the subsystem-level idle callback for the
|
||||
device (the request is represented by a work item in pm_wq); returns 0 on
|
||||
success or error code if the request has not been queued up
|
||||
|
||||
int pm_schedule_suspend(struct device *dev, unsigned int delay);
|
||||
- schedule the execution of ->runtime_suspend() for the device's bus type
|
||||
in future, where 'delay' is the time to wait before queuing up a suspend
|
||||
work item in pm_wq, in milliseconds (if 'delay' is zero, the work item is
|
||||
queued up immediately); returns 0 on success, 1 if the device's PM
|
||||
- schedule the execution of the subsystem-level suspend callback for the
|
||||
device in future, where 'delay' is the time to wait before queuing up a
|
||||
suspend work item in pm_wq, in milliseconds (if 'delay' is zero, the work
|
||||
item is queued up immediately); returns 0 on success, 1 if the device's PM
|
||||
run-time status was already 'suspended', or error code if the request
|
||||
hasn't been scheduled (or queued up if 'delay' is 0); if the execution of
|
||||
->runtime_suspend() is already scheduled and not yet expired, the new
|
||||
value of 'delay' will be used as the time to wait
|
||||
|
||||
int pm_request_resume(struct device *dev);
|
||||
- submit a request to execute ->runtime_resume() for the device's bus type
|
||||
(the request is represented by a work item in pm_wq); returns 0 on
|
||||
- submit a request to execute the subsystem-level resume callback for the
|
||||
device (the request is represented by a work item in pm_wq); returns 0 on
|
||||
success, 1 if the device's run-time PM status was already 'active', or
|
||||
error code if the request hasn't been queued up
|
||||
|
||||
|
|
@ -303,12 +304,12 @@ drivers/base/power/runtime.c and include/linux/pm_runtime.h:
|
|||
run-time PM callbacks described in Section 2
|
||||
|
||||
int pm_runtime_disable(struct device *dev);
|
||||
- prevent the run-time PM helper functions from running the device bus
|
||||
type's run-time PM callbacks, make sure that all of the pending run-time
|
||||
PM operations on the device are either completed or canceled; returns
|
||||
1 if there was a resume request pending and it was necessary to execute
|
||||
->runtime_resume() for the device's bus type to satisfy that request,
|
||||
otherwise 0 is returned
|
||||
- prevent the run-time PM helper functions from running subsystem-level
|
||||
run-time PM callbacks for the device, make sure that all of the pending
|
||||
run-time PM operations on the device are either completed or canceled;
|
||||
returns 1 if there was a resume request pending and it was necessary to
|
||||
execute the subsystem-level resume callback for the device to satisfy that
|
||||
request, otherwise 0 is returned
|
||||
|
||||
void pm_suspend_ignore_children(struct device *dev, bool enable);
|
||||
- set/unset the power.ignore_children flag of the device
|
||||
|
|
@ -378,5 +379,55 @@ pm_runtime_suspend() or pm_runtime_idle() or their asynchronous counterparts,
|
|||
they will fail returning -EAGAIN, because the device's usage counter is
|
||||
incremented by the core before executing ->probe() and ->remove(). Still, it
|
||||
may be desirable to suspend the device as soon as ->probe() or ->remove() has
|
||||
finished, so the PM core uses pm_runtime_idle_sync() to invoke the device bus
|
||||
type's ->runtime_idle() callback at that time.
|
||||
finished, so the PM core uses pm_runtime_idle_sync() to invoke the
|
||||
subsystem-level idle callback for the device at that time.
|
||||
|
||||
6. Run-time PM and System Sleep
|
||||
|
||||
Run-time PM and system sleep (i.e., system suspend and hibernation, also known
|
||||
as suspend-to-RAM and suspend-to-disk) interact with each other in a couple of
|
||||
ways. If a device is active when a system sleep starts, everything is
|
||||
straightforward. But what should happen if the device is already suspended?
|
||||
|
||||
The device may have different wake-up settings for run-time PM and system sleep.
|
||||
For example, remote wake-up may be enabled for run-time suspend but disallowed
|
||||
for system sleep (device_may_wakeup(dev) returns 'false'). When this happens,
|
||||
the subsystem-level system suspend callback is responsible for changing the
|
||||
device's wake-up setting (it may leave that to the device driver's system
|
||||
suspend routine). It may be necessary to resume the device and suspend it again
|
||||
in order to do so. The same is true if the driver uses different power levels
|
||||
or other settings for run-time suspend and system sleep.
|
||||
|
||||
During system resume, devices generally should be brought back to full power,
|
||||
even if they were suspended before the system sleep began. There are several
|
||||
reasons for this, including:
|
||||
|
||||
* The device might need to switch power levels, wake-up settings, etc.
|
||||
|
||||
* Remote wake-up events might have been lost by the firmware.
|
||||
|
||||
* The device's children may need the device to be at full power in order
|
||||
to resume themselves.
|
||||
|
||||
* The driver's idea of the device state may not agree with the device's
|
||||
physical state. This can happen during resume from hibernation.
|
||||
|
||||
* The device might need to be reset.
|
||||
|
||||
* Even though the device was suspended, if its usage counter was > 0 then most
|
||||
likely it would need a run-time resume in the near future anyway.
|
||||
|
||||
* Always going back to full power is simplest.
|
||||
|
||||
If the device was suspended before the sleep began, then its run-time PM status
|
||||
will have to be updated to reflect the actual post-system sleep status. The way
|
||||
to do this is:
|
||||
|
||||
pm_runtime_disable(dev);
|
||||
pm_runtime_set_active(dev);
|
||||
pm_runtime_enable(dev);
|
||||
|
||||
The PM core always increments the run-time usage counter before calling the
|
||||
->prepare() callback and decrements it after calling the ->complete() callback.
|
||||
Hence disabling run-time PM temporarily like this will not cause any run-time
|
||||
suspend callbacks to be lost.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,93 @@
|
|||
PPC440SPe DMA/XOR (DMA Controller and XOR Accelerator)
|
||||
|
||||
Device nodes needed for operation of the ppc440spe-adma driver
|
||||
are specified hereby. These are I2O/DMA, DMA and XOR nodes
|
||||
for DMA engines and Memory Queue Module node. The latter is used
|
||||
by ADMA driver for configuration of RAID-6 H/W capabilities of
|
||||
the PPC440SPe. In addition to the nodes and properties described
|
||||
below, the ranges property of PLB node must specify ranges for
|
||||
DMA devices.
|
||||
|
||||
i) The I2O node
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "ibm,i2o-440spe";
|
||||
- reg : <registers mapping>
|
||||
- dcr-reg : <DCR registers range>
|
||||
|
||||
Example:
|
||||
|
||||
I2O: i2o@400100000 {
|
||||
compatible = "ibm,i2o-440spe";
|
||||
reg = <0x00000004 0x00100000 0x100>;
|
||||
dcr-reg = <0x060 0x020>;
|
||||
};
|
||||
|
||||
|
||||
ii) The DMA node
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "ibm,dma-440spe";
|
||||
- cell-index : 1 cell, hardware index of the DMA engine
|
||||
(typically 0x0 and 0x1 for DMA0 and DMA1)
|
||||
- reg : <registers mapping>
|
||||
- dcr-reg : <DCR registers range>
|
||||
- interrupts : <interrupt mapping for DMA0/1 interrupts sources:
|
||||
2 sources: DMAx CS FIFO Needs Service IRQ (on UIC0)
|
||||
and DMA Error IRQ (on UIC1). The latter is common
|
||||
for both DMA engines>.
|
||||
- interrupt-parent : needed for interrupt mapping
|
||||
|
||||
Example:
|
||||
|
||||
DMA0: dma0@400100100 {
|
||||
compatible = "ibm,dma-440spe";
|
||||
cell-index = <0>;
|
||||
reg = <0x00000004 0x00100100 0x100>;
|
||||
dcr-reg = <0x060 0x020>;
|
||||
interrupt-parent = <&DMA0>;
|
||||
interrupts = <0 1>;
|
||||
#interrupt-cells = <1>;
|
||||
#address-cells = <0>;
|
||||
#size-cells = <0>;
|
||||
interrupt-map = <
|
||||
0 &UIC0 0x14 4
|
||||
1 &UIC1 0x16 4>;
|
||||
};
|
||||
|
||||
|
||||
iii) XOR Accelerator node
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "amcc,xor-accelerator";
|
||||
- reg : <registers mapping>
|
||||
- interrupts : <interrupt mapping for XOR interrupt source>
|
||||
- interrupt-parent : for interrupt mapping
|
||||
|
||||
Example:
|
||||
|
||||
xor-accel@400200000 {
|
||||
compatible = "amcc,xor-accelerator";
|
||||
reg = <0x00000004 0x00200000 0x400>;
|
||||
interrupt-parent = <&UIC1>;
|
||||
interrupts = <0x1f 4>;
|
||||
};
|
||||
|
||||
|
||||
iv) Memory Queue Module node
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : "ibm,mq-440spe";
|
||||
- dcr-reg : <DCR registers range>
|
||||
|
||||
Example:
|
||||
|
||||
MQ0: mq {
|
||||
compatible = "ibm,mq-440spe";
|
||||
dcr-reg = <0x040 0x020>;
|
||||
};
|
||||
|
||||
|
|
@ -20,12 +20,16 @@ Required properities:
|
|||
- compatible : should be "fsl,fpga-pixis".
|
||||
- reg : should contain the address and the length of the FPPGA register
|
||||
set.
|
||||
- interrupt-parent: should specify phandle for the interrupt controller.
|
||||
- interrupts : should specify event (wakeup) IRQ.
|
||||
|
||||
Example (MPC8610HPCD):
|
||||
|
||||
board-control@e8000000 {
|
||||
compatible = "fsl,fpga-pixis";
|
||||
reg = <0xe8000000 32>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <8 8>;
|
||||
};
|
||||
|
||||
* Freescale BCSR GPIO banks
|
||||
|
|
|
|||
|
|
@ -103,7 +103,22 @@ fsl,mpc5200-gpt nodes
|
|||
---------------------
|
||||
On the mpc5200 and 5200b, GPT0 has a watchdog timer function. If the board
|
||||
design supports the internal wdt, then the device node for GPT0 should
|
||||
include the empty property 'fsl,has-wdt'.
|
||||
include the empty property 'fsl,has-wdt'. Note that this does not activate
|
||||
the watchdog. The timer will function as a GPT if the timer api is used, and
|
||||
it will function as watchdog if the watchdog device is used. The watchdog
|
||||
mode has priority over the gpt mode, i.e. if the watchdog is activated, any
|
||||
gpt api call to this timer will fail with -EBUSY.
|
||||
|
||||
If you add the property
|
||||
fsl,wdt-on-boot = <n>;
|
||||
GPT0 will be marked as in-use watchdog, i.e. blocking every gpt access to it.
|
||||
If n>0, the watchdog is started with a timeout of n seconds. If n=0, the
|
||||
configuration of the watchdog is not touched. This is useful in two cases:
|
||||
- just mark GPT0 as watchdog, blocking gpt accesses, and configure it later;
|
||||
- do not touch a configuration assigned by the boot loader which supervises
|
||||
the boot process itself.
|
||||
|
||||
The watchdog will respect the CONFIG_WATCHDOG_NOWAYOUT option.
|
||||
|
||||
An mpc5200-gpt can be used as a single line GPIO controller. To do so,
|
||||
add the following properties to the gpt node:
|
||||
|
|
|
|||
|
|
@ -0,0 +1,42 @@
|
|||
* OpenPIC and its interrupt numbers on Freescale's e500/e600 cores
|
||||
|
||||
The OpenPIC specification does not specify which interrupt source has to
|
||||
become which interrupt number. This is up to the software implementation
|
||||
of the interrupt controller. The only requirement is that every
|
||||
interrupt source has to have an unique interrupt number / vector number.
|
||||
To accomplish this the current implementation assigns the number zero to
|
||||
the first source, the number one to the second source and so on until
|
||||
all interrupt sources have their unique number.
|
||||
Usually the assigned vector number equals the interrupt number mentioned
|
||||
in the documentation for a given core / CPU. This is however not true
|
||||
for the e500 cores (MPC85XX CPUs) where the documentation distinguishes
|
||||
between internal and external interrupt sources and starts counting at
|
||||
zero for both of them.
|
||||
|
||||
So what to write for external interrupt source X or internal interrupt
|
||||
source Y into the device tree? Here is an example:
|
||||
|
||||
The memory map for the interrupt controller in the MPC8544[0] shows,
|
||||
that the first interrupt source starts at 0x5_0000 (PIC Register Address
|
||||
Map-Interrupt Source Configuration Registers). This source becomes the
|
||||
number zero therefore:
|
||||
External interrupt 0 = interrupt number 0
|
||||
External interrupt 1 = interrupt number 1
|
||||
External interrupt 2 = interrupt number 2
|
||||
...
|
||||
Every interrupt number allocates 0x20 bytes register space. So to get
|
||||
its number it is sufficient to shift the lower 16bits to right by five.
|
||||
So for the external interrupt 10 we have:
|
||||
0x0140 >> 5 = 10
|
||||
|
||||
After the external sources, the internal sources follow. The in core I2C
|
||||
controller on the MPC8544 for instance has the internal source number
|
||||
27. Oo obtain its interrupt number we take the lower 16bits of its memory
|
||||
address (0x5_0560) and shift it right:
|
||||
0x0560 >> 5 = 43
|
||||
|
||||
Therefore the I2C device node for the MPC8544 CPU has to have the
|
||||
interrupt number 43 specified in the device tree.
|
||||
|
||||
[0] MPC8544E PowerQUICCTM III, Integrated Host Processor Family Reference Manual
|
||||
MPC8544ERM Rev. 1 10/2007
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
|
||||
Nintendo GameCube device tree
|
||||
=============================
|
||||
|
||||
1) The "flipper" node
|
||||
|
||||
This node represents the multi-function "Flipper" chip, which packages
|
||||
many of the devices found in the Nintendo GameCube.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "nintendo,flipper"
|
||||
|
||||
1.a) The Video Interface (VI) node
|
||||
|
||||
Represents the interface between the graphics processor and a external
|
||||
video encoder.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-vi"
|
||||
- reg : should contain the VI registers location and length
|
||||
- interrupts : should contain the VI interrupt
|
||||
|
||||
1.b) The Processor Interface (PI) node
|
||||
|
||||
Represents the data and control interface between the main processor
|
||||
and graphics and audio processor.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-pi"
|
||||
- reg : should contain the PI registers location and length
|
||||
|
||||
1.b.i) The "Flipper" interrupt controller node
|
||||
|
||||
Represents the interrupt controller within the "Flipper" chip.
|
||||
The node for the "Flipper" interrupt controller must be placed under
|
||||
the PI node.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-pic"
|
||||
|
||||
1.c) The Digital Signal Procesor (DSP) node
|
||||
|
||||
Represents the digital signal processor interface, designed to offload
|
||||
audio related tasks.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-dsp"
|
||||
- reg : should contain the DSP registers location and length
|
||||
- interrupts : should contain the DSP interrupt
|
||||
|
||||
1.c.i) The Auxiliary RAM (ARAM) node
|
||||
|
||||
Represents the non cpu-addressable ram designed mainly to store audio
|
||||
related information.
|
||||
The ARAM node must be placed under the DSP node.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-aram"
|
||||
- reg : should contain the ARAM start (zero-based) and length
|
||||
|
||||
1.d) The Disk Interface (DI) node
|
||||
|
||||
Represents the interface used to communicate with mass storage devices.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-di"
|
||||
- reg : should contain the DI registers location and length
|
||||
- interrupts : should contain the DI interrupt
|
||||
|
||||
1.e) The Audio Interface (AI) node
|
||||
|
||||
Represents the interface to the external 16-bit stereo digital-to-analog
|
||||
converter.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-ai"
|
||||
- reg : should contain the AI registers location and length
|
||||
- interrupts : should contain the AI interrupt
|
||||
|
||||
1.f) The Serial Interface (SI) node
|
||||
|
||||
Represents the interface to the four single bit serial interfaces.
|
||||
The SI is a proprietary serial interface used normally to control gamepads.
|
||||
It's NOT a RS232-type interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-si"
|
||||
- reg : should contain the SI registers location and length
|
||||
- interrupts : should contain the SI interrupt
|
||||
|
||||
1.g) The External Interface (EXI) node
|
||||
|
||||
Represents the multi-channel SPI-like interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,flipper-exi"
|
||||
- reg : should contain the EXI registers location and length
|
||||
- interrupts : should contain the EXI interrupt
|
||||
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
|
||||
Nintendo Wii device tree
|
||||
========================
|
||||
|
||||
0) The root node
|
||||
|
||||
This node represents the Nintendo Wii video game console.
|
||||
|
||||
Required properties:
|
||||
|
||||
- model : Should be "nintendo,wii"
|
||||
- compatible : Should be "nintendo,wii"
|
||||
|
||||
1) The "hollywood" node
|
||||
|
||||
This node represents the multi-function "Hollywood" chip, which packages
|
||||
many of the devices found in the Nintendo Wii.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : Should be "nintendo,hollywood"
|
||||
|
||||
1.a) The Video Interface (VI) node
|
||||
|
||||
Represents the interface between the graphics processor and a external
|
||||
video encoder.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-vi","nintendo,flipper-vi"
|
||||
- reg : should contain the VI registers location and length
|
||||
- interrupts : should contain the VI interrupt
|
||||
|
||||
1.b) The Processor Interface (PI) node
|
||||
|
||||
Represents the data and control interface between the main processor
|
||||
and graphics and audio processor.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-pi","nintendo,flipper-pi"
|
||||
- reg : should contain the PI registers location and length
|
||||
|
||||
1.b.i) The "Flipper" interrupt controller node
|
||||
|
||||
Represents the "Flipper" interrupt controller within the "Hollywood" chip.
|
||||
The node for the "Flipper" interrupt controller must be placed under
|
||||
the PI node.
|
||||
|
||||
Required properties:
|
||||
|
||||
- #interrupt-cells : <1>
|
||||
- compatible : should be "nintendo,flipper-pic"
|
||||
- interrupt-controller
|
||||
|
||||
1.c) The Digital Signal Procesor (DSP) node
|
||||
|
||||
Represents the digital signal processor interface, designed to offload
|
||||
audio related tasks.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-dsp","nintendo,flipper-dsp"
|
||||
- reg : should contain the DSP registers location and length
|
||||
- interrupts : should contain the DSP interrupt
|
||||
|
||||
1.d) The Serial Interface (SI) node
|
||||
|
||||
Represents the interface to the four single bit serial interfaces.
|
||||
The SI is a proprietary serial interface used normally to control gamepads.
|
||||
It's NOT a RS232-type interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-si","nintendo,flipper-si"
|
||||
- reg : should contain the SI registers location and length
|
||||
- interrupts : should contain the SI interrupt
|
||||
|
||||
1.e) The Audio Interface (AI) node
|
||||
|
||||
Represents the interface to the external 16-bit stereo digital-to-analog
|
||||
converter.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-ai","nintendo,flipper-ai"
|
||||
- reg : should contain the AI registers location and length
|
||||
- interrupts : should contain the AI interrupt
|
||||
|
||||
1.f) The External Interface (EXI) node
|
||||
|
||||
Represents the multi-channel SPI-like interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-exi","nintendo,flipper-exi"
|
||||
- reg : should contain the EXI registers location and length
|
||||
- interrupts : should contain the EXI interrupt
|
||||
|
||||
1.g) The Open Host Controller Interface (OHCI) nodes
|
||||
|
||||
Represent the USB 1.x Open Host Controller Interfaces.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-usb-ohci","usb-ohci"
|
||||
- reg : should contain the OHCI registers location and length
|
||||
- interrupts : should contain the OHCI interrupt
|
||||
|
||||
1.h) The Enhanced Host Controller Interface (EHCI) node
|
||||
|
||||
Represents the USB 2.0 Enhanced Host Controller Interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-usb-ehci","usb-ehci"
|
||||
- reg : should contain the EHCI registers location and length
|
||||
- interrupts : should contain the EHCI interrupt
|
||||
|
||||
1.i) The Secure Digital Host Controller Interface (SDHCI) nodes
|
||||
|
||||
Represent the Secure Digital Host Controller Interfaces.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-sdhci","sdhci"
|
||||
- reg : should contain the SDHCI registers location and length
|
||||
- interrupts : should contain the SDHCI interrupt
|
||||
|
||||
1.j) The Inter-Processsor Communication (IPC) node
|
||||
|
||||
Represent the Inter-Processor Communication interface. This interface
|
||||
enables communications between the Broadway and the Starlet processors.
|
||||
|
||||
- compatible : should be "nintendo,hollywood-ipc"
|
||||
- reg : should contain the IPC registers location and length
|
||||
- interrupts : should contain the IPC interrupt
|
||||
|
||||
1.k) The "Hollywood" interrupt controller node
|
||||
|
||||
Represents the "Hollywood" interrupt controller within the
|
||||
"Hollywood" chip.
|
||||
|
||||
Required properties:
|
||||
|
||||
- #interrupt-cells : <1>
|
||||
- compatible : should be "nintendo,hollywood-pic"
|
||||
- reg : should contain the controller registers location and length
|
||||
- interrupt-controller
|
||||
- interrupts : should contain the cascade interrupt of the "flipper" pic
|
||||
- interrupt-parent: should contain the phandle of the "flipper" pic
|
||||
|
||||
1.l) The General Purpose I/O (GPIO) controller node
|
||||
|
||||
Represents the dual access 32 GPIO controller interface.
|
||||
|
||||
Required properties:
|
||||
|
||||
- #gpio-cells : <2>
|
||||
- compatible : should be "nintendo,hollywood-gpio"
|
||||
- reg : should contain the IPC registers location and length
|
||||
- gpio-controller
|
||||
|
||||
1.m) The control node
|
||||
|
||||
Represents the control interface used to setup several miscellaneous
|
||||
settings of the "Hollywood" chip like boot memory mappings, resets,
|
||||
disk interface mode, etc.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-control"
|
||||
- reg : should contain the control registers location and length
|
||||
|
||||
1.n) The Disk Interface (DI) node
|
||||
|
||||
Represents the interface used to communicate with mass storage devices.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "nintendo,hollywood-di"
|
||||
- reg : should contain the DI registers location and length
|
||||
- interrupts : should contain the DI interrupt
|
||||
|
||||
|
|
@ -403,4 +403,5 @@ STAC9872
|
|||
Cirrus Logic CS4206/4207
|
||||
========================
|
||||
mbp55 MacBook Pro 5,5
|
||||
imac27 IMac 27 Inch
|
||||
auto BIOS setup (default)
|
||||
|
|
|
|||
|
|
@ -95,7 +95,7 @@ card*/pcm*/xrun_debug
|
|||
It takes an integer value, can be changed by writing to this
|
||||
file, such as
|
||||
|
||||
# cat 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
# echo 5 > /proc/asound/card0/pcm0p/xrun_debug
|
||||
|
||||
The value consists of the following bit flags:
|
||||
bit 0 = Enable XRUN/jiffies debug messages
|
||||
|
|
|
|||
|
|
@ -1,73 +1,8 @@
|
|||
SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED defeat lockdep state tracking and
|
||||
are hence deprecated.
|
||||
Lesson 1: Spin locks
|
||||
|
||||
Please use DEFINE_SPINLOCK()/DEFINE_RWLOCK() or
|
||||
__SPIN_LOCK_UNLOCKED()/__RW_LOCK_UNLOCKED() as appropriate for static
|
||||
initialization.
|
||||
|
||||
Most of the time, you can simply turn:
|
||||
|
||||
static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
|
||||
|
||||
into:
|
||||
|
||||
static DEFINE_SPINLOCK(xxx_lock);
|
||||
|
||||
Static structure member variables go from:
|
||||
|
||||
struct foo bar {
|
||||
.lock = SPIN_LOCK_UNLOCKED;
|
||||
};
|
||||
|
||||
to:
|
||||
|
||||
struct foo bar {
|
||||
.lock = __SPIN_LOCK_UNLOCKED(bar.lock);
|
||||
};
|
||||
|
||||
Declaration of static rw_locks undergo a similar transformation.
|
||||
|
||||
Dynamic initialization, when necessary, may be performed as
|
||||
demonstrated below.
|
||||
|
||||
spinlock_t xxx_lock;
|
||||
rwlock_t xxx_rw_lock;
|
||||
|
||||
static int __init xxx_init(void)
|
||||
{
|
||||
spin_lock_init(&xxx_lock);
|
||||
rwlock_init(&xxx_rw_lock);
|
||||
...
|
||||
}
|
||||
|
||||
module_init(xxx_init);
|
||||
|
||||
The following discussion is still valid, however, with the dynamic
|
||||
initialization of spinlocks or with DEFINE_SPINLOCK, etc., used
|
||||
instead of SPIN_LOCK_UNLOCKED.
|
||||
|
||||
-----------------------
|
||||
|
||||
On Fri, 2 Jan 1998, Doug Ledford wrote:
|
||||
>
|
||||
> I'm working on making the aic7xxx driver more SMP friendly (as well as
|
||||
> importing the latest FreeBSD sequencer code to have 7895 support) and wanted
|
||||
> to get some info from you. The goal here is to make the various routines
|
||||
> SMP safe as well as UP safe during interrupts and other manipulating
|
||||
> routines. So far, I've added a spin_lock variable to things like my queue
|
||||
> structs. Now, from what I recall, there are some spin lock functions I can
|
||||
> use to lock these spin locks from other use as opposed to a (nasty)
|
||||
> save_flags(); cli(); stuff; restore_flags(); construct. Where do I find
|
||||
> these routines and go about making use of them? Do they only lock on a
|
||||
> per-processor basis or can they also lock say an interrupt routine from
|
||||
> mucking with a queue if the queue routine was manipulating it when the
|
||||
> interrupt occurred, or should I still use a cli(); based construct on that
|
||||
> one?
|
||||
|
||||
See <asm/spinlock.h>. The basic version is:
|
||||
|
||||
spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
|
||||
The most basic primitive for locking is spinlock.
|
||||
|
||||
static DEFINE_SPINLOCK(xxx_lock);
|
||||
|
||||
unsigned long flags;
|
||||
|
||||
|
|
@ -75,13 +10,11 @@ See <asm/spinlock.h>. The basic version is:
|
|||
... critical section here ..
|
||||
spin_unlock_irqrestore(&xxx_lock, flags);
|
||||
|
||||
and the above is always safe. It will disable interrupts _locally_, but the
|
||||
The above is always safe. It will disable interrupts _locally_, but the
|
||||
spinlock itself will guarantee the global lock, so it will guarantee that
|
||||
there is only one thread-of-control within the region(s) protected by that
|
||||
lock.
|
||||
|
||||
Note that it works well even under UP - the above sequence under UP
|
||||
essentially is just the same as doing a
|
||||
lock. This works well even under UP. The above sequence under UP
|
||||
essentially is just the same as doing
|
||||
|
||||
unsigned long flags;
|
||||
|
||||
|
|
@ -91,15 +24,13 @@ essentially is just the same as doing a
|
|||
|
||||
so the code does _not_ need to worry about UP vs SMP issues: the spinlocks
|
||||
work correctly under both (and spinlocks are actually more efficient on
|
||||
architectures that allow doing the "save_flags + cli" in one go because I
|
||||
don't export that interface normally).
|
||||
architectures that allow doing the "save_flags + cli" in one operation).
|
||||
|
||||
NOTE NOTE NOTE! The reason the spinlock is so much faster than a global
|
||||
interrupt lock under SMP is exactly because it disables interrupts only on
|
||||
the local CPU. The spin-lock is safe only when you _also_ use the lock
|
||||
itself to do locking across CPU's, which implies that EVERYTHING that
|
||||
touches a shared variable has to agree about the spinlock they want to
|
||||
use.
|
||||
NOTE! Implications of spin_locks for memory are further described in:
|
||||
|
||||
Documentation/memory-barriers.txt
|
||||
(5) LOCK operations.
|
||||
(6) UNLOCK operations.
|
||||
|
||||
The above is usually pretty simple (you usually need and want only one
|
||||
spinlock for most things - using more than one spinlock can make things a
|
||||
|
|
@ -120,20 +51,24 @@ and another sequence that does
|
|||
then they are NOT mutually exclusive, and the critical regions can happen
|
||||
at the same time on two different CPU's. That's fine per se, but the
|
||||
critical regions had better be critical for different things (ie they
|
||||
can't stomp on each other).
|
||||
can't stomp on each other).
|
||||
|
||||
The above is a problem mainly if you end up mixing code - for example the
|
||||
routines in ll_rw_block() tend to use cli/sti to protect the atomicity of
|
||||
their actions, and if a driver uses spinlocks instead then you should
|
||||
think about issues like the above..
|
||||
think about issues like the above.
|
||||
|
||||
This is really the only really hard part about spinlocks: once you start
|
||||
using spinlocks they tend to expand to areas you might not have noticed
|
||||
before, because you have to make sure the spinlocks correctly protect the
|
||||
shared data structures _everywhere_ they are used. The spinlocks are most
|
||||
easily added to places that are completely independent of other code (ie
|
||||
internal driver data structures that nobody else ever touches, for
|
||||
example).
|
||||
easily added to places that are completely independent of other code (for
|
||||
example, internal driver data structures that nobody else ever touches).
|
||||
|
||||
NOTE! The spin-lock is safe only when you _also_ use the lock itself
|
||||
to do locking across CPU's, which implies that EVERYTHING that
|
||||
touches a shared variable has to agree about the spinlock they want
|
||||
to use.
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -141,14 +76,18 @@ Lesson 2: reader-writer spinlocks.
|
|||
|
||||
If your data accesses have a very natural pattern where you usually tend
|
||||
to mostly read from the shared variables, the reader-writer locks
|
||||
(rw_lock) versions of the spinlocks are often nicer. They allow multiple
|
||||
(rw_lock) versions of the spinlocks are sometimes useful. They allow multiple
|
||||
readers to be in the same critical region at once, but if somebody wants
|
||||
to change the variables it has to get an exclusive write lock. The
|
||||
routines look the same as above:
|
||||
to change the variables it has to get an exclusive write lock.
|
||||
|
||||
NOTE! reader-writer locks require more atomic memory operations than
|
||||
simple spinlocks. Unless the reader critical section is long, you
|
||||
are better off just using spinlocks.
|
||||
|
||||
The routines look the same as above:
|
||||
|
||||
rwlock_t xxx_lock = RW_LOCK_UNLOCKED;
|
||||
|
||||
|
||||
unsigned long flags;
|
||||
|
||||
read_lock_irqsave(&xxx_lock, flags);
|
||||
|
|
@ -159,18 +98,21 @@ routines look the same as above:
|
|||
.. read and write exclusive access to the info ...
|
||||
write_unlock_irqrestore(&xxx_lock, flags);
|
||||
|
||||
The above kind of lock is useful for complex data structures like linked
|
||||
lists etc, especially when you know that most of the work is to just
|
||||
traverse the list searching for entries without changing the list itself,
|
||||
for example. Then you can use the read lock for that kind of list
|
||||
traversal, which allows many concurrent readers. Anything that _changes_
|
||||
the list will have to get the write lock.
|
||||
The above kind of lock may be useful for complex data structures like
|
||||
linked lists, especially searching for entries without changing the list
|
||||
itself. The read lock allows many concurrent readers. Anything that
|
||||
_changes_ the list will have to get the write lock.
|
||||
|
||||
Note: you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
|
||||
NOTE! RCU is better for list traversal, but requires careful
|
||||
attention to design detail (see Documentation/RCU/listRCU.txt).
|
||||
|
||||
Also, you cannot "upgrade" a read-lock to a write-lock, so if you at _any_
|
||||
time need to do any changes (even if you don't do it every time), you have
|
||||
to get the write-lock at the very beginning. I could fairly easily add a
|
||||
primitive to create a "upgradeable" read-lock, but it hasn't been an issue
|
||||
yet. Tell me if you'd want one.
|
||||
to get the write-lock at the very beginning.
|
||||
|
||||
NOTE! We are working hard to remove reader-writer spinlocks in most
|
||||
cases, so please don't add a new one without consensus. (Instead, see
|
||||
Documentation/RCU/rcu.txt for complete information.)
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -233,4 +175,46 @@ indeed), while write-locks need to protect themselves against interrupts.
|
|||
|
||||
Linus
|
||||
|
||||
----
|
||||
|
||||
Reference information:
|
||||
|
||||
For dynamic initialization, use spin_lock_init() or rwlock_init() as
|
||||
appropriate:
|
||||
|
||||
spinlock_t xxx_lock;
|
||||
rwlock_t xxx_rw_lock;
|
||||
|
||||
static int __init xxx_init(void)
|
||||
{
|
||||
spin_lock_init(&xxx_lock);
|
||||
rwlock_init(&xxx_rw_lock);
|
||||
...
|
||||
}
|
||||
|
||||
module_init(xxx_init);
|
||||
|
||||
For static initialization, use DEFINE_SPINLOCK() / DEFINE_RWLOCK() or
|
||||
__SPIN_LOCK_UNLOCKED() / __RW_LOCK_UNLOCKED() as appropriate.
|
||||
|
||||
SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED are deprecated. These interfere
|
||||
with lockdep state tracking.
|
||||
|
||||
Most of the time, you can simply turn:
|
||||
static spinlock_t xxx_lock = SPIN_LOCK_UNLOCKED;
|
||||
into:
|
||||
static DEFINE_SPINLOCK(xxx_lock);
|
||||
|
||||
Static structure member variables go from:
|
||||
|
||||
struct foo bar {
|
||||
.lock = SPIN_LOCK_UNLOCKED;
|
||||
};
|
||||
|
||||
to:
|
||||
|
||||
struct foo bar {
|
||||
.lock = __SPIN_LOCK_UNLOCKED(bar.lock);
|
||||
};
|
||||
|
||||
Declaration of static rw_locks undergo a similar transformation.
|
||||
|
|
|
|||
|
|
@ -26,13 +26,33 @@ Procedure for submitting patches to the -stable tree:
|
|||
|
||||
- Send the patch, after verifying that it follows the above rules, to
|
||||
stable@kernel.org.
|
||||
- To have the patch automatically included in the stable tree, add the
|
||||
the tag
|
||||
Cc: stable@kernel.org
|
||||
in the sign-off area. Once the patch is merged it will be applied to
|
||||
the stable tree without anything else needing to be done by the author
|
||||
or subsystem maintainer.
|
||||
- If the patch requires other patches as prerequisites which can be
|
||||
cherry-picked than this can be specified in the following format in
|
||||
the sign-off area:
|
||||
|
||||
Cc: <stable@kernel.org> # .32.x: a1f84a3: sched: Check for idle
|
||||
Cc: <stable@kernel.org> # .32.x: 1b9508f: sched: Rate-limit newidle
|
||||
Cc: <stable@kernel.org> # .32.x: fd21073: sched: Fix affinity logic
|
||||
Cc: <stable@kernel.org> # .32.x
|
||||
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|
||||
|
||||
The tag sequence has the meaning of:
|
||||
git cherry-pick a1f84a3
|
||||
git cherry-pick 1b9508f
|
||||
git cherry-pick fd21073
|
||||
git cherry-pick <this commit>
|
||||
|
||||
- The sender will receive an ACK when the patch has been accepted into the
|
||||
queue, or a NAK if the patch is rejected. This response might take a few
|
||||
days, according to the developer's schedules.
|
||||
- If accepted, the patch will be added to the -stable queue, for review by
|
||||
other developers and by the relevant subsystem maintainer.
|
||||
- If the stable@kernel.org address is added to a patch, when it goes into
|
||||
Linus's tree it will automatically be emailed to the stable team.
|
||||
- Security patches should not be sent to this alias, but instead to the
|
||||
documented security@kernel.org address.
|
||||
|
||||
|
|
|
|||
|
|
@ -19,6 +19,8 @@ Currently, these files might (depending on your configuration)
|
|||
show up in /proc/sys/kernel:
|
||||
- acpi_video_flags
|
||||
- acct
|
||||
- bootloader_type [ X86 only ]
|
||||
- bootloader_version [ X86 only ]
|
||||
- callhome [ S390 only ]
|
||||
- auto_msgmni
|
||||
- core_pattern
|
||||
|
|
@ -93,6 +95,35 @@ valid for 30 seconds.
|
|||
|
||||
==============================================================
|
||||
|
||||
bootloader_type:
|
||||
|
||||
x86 bootloader identification
|
||||
|
||||
This gives the bootloader type number as indicated by the bootloader,
|
||||
shifted left by 4, and OR'd with the low four bits of the bootloader
|
||||
version. The reason for this encoding is that this used to match the
|
||||
type_of_loader field in the kernel header; the encoding is kept for
|
||||
backwards compatibility. That is, if the full bootloader type number
|
||||
is 0x15 and the full version number is 0x234, this file will contain
|
||||
the value 340 = 0x154.
|
||||
|
||||
See the type_of_loader and ext_loader_type fields in
|
||||
Documentation/x86/boot.txt for additional information.
|
||||
|
||||
==============================================================
|
||||
|
||||
bootloader_version:
|
||||
|
||||
x86 bootloader version
|
||||
|
||||
The complete bootloader version number. In the example above, this
|
||||
file will contain the value 564 = 0x234.
|
||||
|
||||
See the type_of_loader and ext_loader_ver fields in
|
||||
Documentation/x86/boot.txt for additional information.
|
||||
|
||||
==============================================================
|
||||
|
||||
callhome:
|
||||
|
||||
Controls the kernel's callhome behavior in case of a kernel panic.
|
||||
|
|
|
|||
|
|
@ -206,6 +206,7 @@ passive
|
|||
passive trip point for the zone. Activation is done by polling with
|
||||
an interval of 1 second.
|
||||
Unit: millidegrees Celsius
|
||||
Valid values: 0 (disabled) or greater than 1000
|
||||
RW, Optional
|
||||
|
||||
*****************************
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
Subsystem Trace Points: kmem
|
||||
|
||||
The tracing system kmem captures events related to object and page allocation
|
||||
within the kernel. Broadly speaking there are four major subheadings.
|
||||
The kmem tracing system captures events related to object and page allocation
|
||||
within the kernel. Broadly speaking there are five major subheadings.
|
||||
|
||||
o Slab allocation of small objects of unknown type (kmalloc)
|
||||
o Slab allocation of small objects of known type
|
||||
|
|
@ -9,7 +9,7 @@ within the kernel. Broadly speaking there are four major subheadings.
|
|||
o Per-CPU Allocator Activity
|
||||
o External Fragmentation
|
||||
|
||||
This document will describe what each of the tracepoints are and why they
|
||||
This document describes what each of the tracepoints is and why they
|
||||
might be useful.
|
||||
|
||||
1. Slab allocation of small objects of unknown type
|
||||
|
|
@ -34,7 +34,7 @@ kmem_cache_free call_site=%lx ptr=%p
|
|||
These events are similar in usage to the kmalloc-related events except that
|
||||
it is likely easier to pin the event down to a specific cache. At the time
|
||||
of writing, no information is available on what slab is being allocated from,
|
||||
but the call_site can usually be used to extrapolate that information
|
||||
but the call_site can usually be used to extrapolate that information.
|
||||
|
||||
3. Page allocation
|
||||
==================
|
||||
|
|
@ -80,9 +80,9 @@ event indicating whether it is for a percpu_refill or not.
|
|||
When the per-CPU list is too full, a number of pages are freed, each one
|
||||
which triggers a mm_page_pcpu_drain event.
|
||||
|
||||
The individual nature of the events are so that pages can be tracked
|
||||
The individual nature of the events is so that pages can be tracked
|
||||
between allocation and freeing. A number of drain or refill pages that occur
|
||||
consecutively imply the zone->lock being taken once. Large amounts of PCP
|
||||
consecutively imply the zone->lock being taken once. Large amounts of per-CPU
|
||||
refills and drains could imply an imbalance between CPUs where too much work
|
||||
is being concentrated in one place. It could also indicate that the per-CPU
|
||||
lists should be a larger size. Finally, large amounts of refills on one CPU
|
||||
|
|
@ -102,6 +102,6 @@ is important.
|
|||
|
||||
Large numbers of this event implies that memory is fragmenting and
|
||||
high-order allocations will start failing at some time in the future. One
|
||||
means of reducing the occurange of this event is to increase the size of
|
||||
means of reducing the occurrence of this event is to increase the size of
|
||||
min_free_kbytes in increments of 3*pageblock_size*nr_online_nodes where
|
||||
pageblock_size is usually the size of the default hugepage size.
|
||||
|
|
|
|||
|
|
@ -53,14 +53,14 @@ size of the mcount call that is embedded in the function).
|
|||
For example, if the function foo() calls bar(), when the bar() function calls
|
||||
mcount(), the arguments mcount() will pass to the tracer are:
|
||||
"frompc" - the address bar() will use to return to foo()
|
||||
"selfpc" - the address bar() (with _mcount() size adjustment)
|
||||
"selfpc" - the address bar() (with mcount() size adjustment)
|
||||
|
||||
Also keep in mind that this mcount function will be called *a lot*, so
|
||||
optimizing for the default case of no tracer will help the smooth running of
|
||||
your system when tracing is disabled. So the start of the mcount function is
|
||||
typically the bare min with checking things before returning. That also means
|
||||
the code flow should usually kept linear (i.e. no branching in the nop case).
|
||||
This is of course an optimization and not a hard requirement.
|
||||
typically the bare minimum with checking things before returning. That also
|
||||
means the code flow should usually be kept linear (i.e. no branching in the nop
|
||||
case). This is of course an optimization and not a hard requirement.
|
||||
|
||||
Here is some pseudo code that should help (these functions should actually be
|
||||
implemented in assembly):
|
||||
|
|
@ -131,10 +131,10 @@ some functions to save (hijack) and restore the return address.
|
|||
|
||||
The mcount function should check the function pointers ftrace_graph_return
|
||||
(compare to ftrace_stub) and ftrace_graph_entry (compare to
|
||||
ftrace_graph_entry_stub). If either of those are not set to the relevant stub
|
||||
ftrace_graph_entry_stub). If either of those is not set to the relevant stub
|
||||
function, call the arch-specific function ftrace_graph_caller which in turn
|
||||
calls the arch-specific function prepare_ftrace_return. Neither of these
|
||||
function names are strictly required, but you should use them anyways to stay
|
||||
function names is strictly required, but you should use them anyway to stay
|
||||
consistent across the architecture ports -- easier to compare & contrast
|
||||
things.
|
||||
|
||||
|
|
@ -144,7 +144,7 @@ but the first argument should be a pointer to the "frompc". Typically this is
|
|||
located on the stack. This allows the function to hijack the return address
|
||||
temporarily to have it point to the arch-specific function return_to_handler.
|
||||
That function will simply call the common ftrace_return_to_handler function and
|
||||
that will return the original return address with which, you can return to the
|
||||
that will return the original return address with which you can return to the
|
||||
original call site.
|
||||
|
||||
Here is the updated mcount pseudo code:
|
||||
|
|
|
|||
|
|
@ -44,7 +44,8 @@ Check for lost events.
|
|||
Usage
|
||||
-----
|
||||
|
||||
Make sure debugfs is mounted to /sys/kernel/debug. If not, (requires root privileges)
|
||||
Make sure debugfs is mounted to /sys/kernel/debug.
|
||||
If not (requires root privileges):
|
||||
$ mount -t debugfs debugfs /sys/kernel/debug
|
||||
|
||||
Check that the driver you are about to trace is not loaded.
|
||||
|
|
@ -91,7 +92,7 @@ $ dmesg > dmesg.txt
|
|||
$ tar zcf pciid-nick-mmiotrace.tar.gz mydump.txt lspci.txt dmesg.txt
|
||||
and then send the .tar.gz file. The trace compresses considerably. Replace
|
||||
"pciid" and "nick" with the PCI ID or model name of your piece of hardware
|
||||
under investigation and your nick name.
|
||||
under investigation and your nickname.
|
||||
|
||||
|
||||
How Mmiotrace Works
|
||||
|
|
@ -100,7 +101,7 @@ How Mmiotrace Works
|
|||
Access to hardware IO-memory is gained by mapping addresses from PCI bus by
|
||||
calling one of the ioremap_*() functions. Mmiotrace is hooked into the
|
||||
__ioremap() function and gets called whenever a mapping is created. Mapping is
|
||||
an event that is recorded into the trace log. Note, that ISA range mappings
|
||||
an event that is recorded into the trace log. Note that ISA range mappings
|
||||
are not caught, since the mapping always exists and is returned directly.
|
||||
|
||||
MMIO accesses are recorded via page faults. Just before __ioremap() returns,
|
||||
|
|
@ -122,11 +123,11 @@ Trace Log Format
|
|||
----------------
|
||||
|
||||
The raw log is text and easily filtered with e.g. grep and awk. One record is
|
||||
one line in the log. A record starts with a keyword, followed by keyword
|
||||
dependant arguments. Arguments are separated by a space, or continue until the
|
||||
one line in the log. A record starts with a keyword, followed by keyword-
|
||||
dependent arguments. Arguments are separated by a space, or continue until the
|
||||
end of line. The format for version 20070824 is as follows:
|
||||
|
||||
Explanation Keyword Space separated arguments
|
||||
Explanation Keyword Space-separated arguments
|
||||
---------------------------------------------------------------------------
|
||||
|
||||
read event R width, timestamp, map id, physical, value, PC, PID
|
||||
|
|
@ -136,7 +137,7 @@ iounmap event UNMAP timestamp, map id, PC, PID
|
|||
marker MARK timestamp, text
|
||||
version VERSION the string "20070824"
|
||||
info for reader LSPCI one line from lspci -v
|
||||
PCI address map PCIDEV space separated /proc/bus/pci/devices data
|
||||
PCI address map PCIDEV space-separated /proc/bus/pci/devices data
|
||||
unk. opcode UNKNOWN timestamp, map id, physical, data, PC, PID
|
||||
|
||||
Timestamp is in seconds with decimals. Physical is a PCI bus address, virtual
|
||||
|
|
|
|||
|
|
@ -33,9 +33,9 @@ head_page - a pointer to the page that the reader will use next
|
|||
|
||||
tail_page - a pointer to the page that will be written to next
|
||||
|
||||
commit_page - a pointer to the page with the last finished non nested write.
|
||||
commit_page - a pointer to the page with the last finished non-nested write.
|
||||
|
||||
cmpxchg - hardware assisted atomic transaction that performs the following:
|
||||
cmpxchg - hardware-assisted atomic transaction that performs the following:
|
||||
|
||||
A = B iff previous A == C
|
||||
|
||||
|
|
@ -52,15 +52,15 @@ The Generic Ring Buffer
|
|||
The ring buffer can be used in either an overwrite mode or in
|
||||
producer/consumer mode.
|
||||
|
||||
Producer/consumer mode is where the producer were to fill up the
|
||||
Producer/consumer mode is where if the producer were to fill up the
|
||||
buffer before the consumer could free up anything, the producer
|
||||
will stop writing to the buffer. This will lose most recent events.
|
||||
|
||||
Overwrite mode is where the produce were to fill up the buffer
|
||||
Overwrite mode is where if the producer were to fill up the buffer
|
||||
before the consumer could free up anything, the producer will
|
||||
overwrite the older data. This will lose the oldest events.
|
||||
|
||||
No two writers can write at the same time (on the same per cpu buffer),
|
||||
No two writers can write at the same time (on the same per-cpu buffer),
|
||||
but a writer may interrupt another writer, but it must finish writing
|
||||
before the previous writer may continue. This is very important to the
|
||||
algorithm. The writers act like a "stack". The way interrupts works
|
||||
|
|
@ -79,16 +79,16 @@ the interrupt doing a write as well.
|
|||
|
||||
Readers can happen at any time. But no two readers may run at the
|
||||
same time, nor can a reader preempt/interrupt another reader. A reader
|
||||
can not preempt/interrupt a writer, but it may read/consume from the
|
||||
cannot preempt/interrupt a writer, but it may read/consume from the
|
||||
buffer at the same time as a writer is writing, but the reader must be
|
||||
on another processor to do so. A reader may read on its own processor
|
||||
and can be preempted by a writer.
|
||||
|
||||
A writer can preempt a reader, but a reader can not preempt a writer.
|
||||
A writer can preempt a reader, but a reader cannot preempt a writer.
|
||||
But a reader can read the buffer at the same time (on another processor)
|
||||
as a writer.
|
||||
|
||||
The ring buffer is made up of a list of pages held together by a link list.
|
||||
The ring buffer is made up of a list of pages held together by a linked list.
|
||||
|
||||
At initialization a reader page is allocated for the reader that is not
|
||||
part of the ring buffer.
|
||||
|
|
@ -102,7 +102,7 @@ the head page.
|
|||
|
||||
The reader has its own page to use. At start up time, this page is
|
||||
allocated but is not attached to the list. When the reader wants
|
||||
to read from the buffer, if its page is empty (like it is on start up)
|
||||
to read from the buffer, if its page is empty (like it is on start-up),
|
||||
it will swap its page with the head_page. The old reader page will
|
||||
become part of the ring buffer and the head_page will be removed.
|
||||
The page after the inserted page (old reader_page) will become the
|
||||
|
|
@ -206,7 +206,7 @@ The main pointers:
|
|||
|
||||
commit page - the page that last finished a write.
|
||||
|
||||
The commit page only is updated by the outer most writer in the
|
||||
The commit page only is updated by the outermost writer in the
|
||||
writer stack. A writer that preempts another writer will not move the
|
||||
commit page.
|
||||
|
||||
|
|
@ -281,7 +281,7 @@ with the previous write.
|
|||
The commit pointer points to the last write location that was
|
||||
committed without preempting another write. When a write that
|
||||
preempted another write is committed, it only becomes a pending commit
|
||||
and will not be a full commit till all writes have been committed.
|
||||
and will not be a full commit until all writes have been committed.
|
||||
|
||||
The commit page points to the page that has the last full commit.
|
||||
The tail page points to the page with the last write (before
|
||||
|
|
@ -292,7 +292,7 @@ be several pages ahead. If the tail page catches up to the commit
|
|||
page then no more writes may take place (regardless of the mode
|
||||
of the ring buffer: overwrite and produce/consumer).
|
||||
|
||||
The order of pages are:
|
||||
The order of pages is:
|
||||
|
||||
head page
|
||||
commit page
|
||||
|
|
@ -311,7 +311,7 @@ Possible scenario:
|
|||
There is a special case that the head page is after either the commit page
|
||||
and possibly the tail page. That is when the commit (and tail) page has been
|
||||
swapped with the reader page. This is because the head page is always
|
||||
part of the ring buffer, but the reader page is not. When ever there
|
||||
part of the ring buffer, but the reader page is not. Whenever there
|
||||
has been less than a full page that has been committed inside the ring buffer,
|
||||
and a reader swaps out a page, it will be swapping out the commit page.
|
||||
|
||||
|
|
@ -338,7 +338,7 @@ and a reader swaps out a page, it will be swapping out the commit page.
|
|||
In this case, the head page will not move when the tail and commit
|
||||
move back into the ring buffer.
|
||||
|
||||
The reader can not swap a page into the ring buffer if the commit page
|
||||
The reader cannot swap a page into the ring buffer if the commit page
|
||||
is still on that page. If the read meets the last commit (real commit
|
||||
not pending or reserved), then there is nothing more to read.
|
||||
The buffer is considered empty until another full commit finishes.
|
||||
|
|
@ -395,7 +395,7 @@ The main idea behind the lockless algorithm is to combine the moving
|
|||
of the head_page pointer with the swapping of pages with the reader.
|
||||
State flags are placed inside the pointer to the page. To do this,
|
||||
each page must be aligned in memory by 4 bytes. This will allow the 2
|
||||
least significant bits of the address to be used as flags. Since
|
||||
least significant bits of the address to be used as flags, since
|
||||
they will always be zero for the address. To get the address,
|
||||
simply mask out the flags.
|
||||
|
||||
|
|
@ -460,7 +460,7 @@ When the reader tries to swap the page with the ring buffer, it
|
|||
will also use cmpxchg. If the flag bit in the pointer to the
|
||||
head page does not have the HEADER flag set, the compare will fail
|
||||
and the reader will need to look for the new head page and try again.
|
||||
Note, the flag UPDATE and HEADER are never set at the same time.
|
||||
Note, the flags UPDATE and HEADER are never set at the same time.
|
||||
|
||||
The reader swaps the reader page as follows:
|
||||
|
||||
|
|
@ -539,7 +539,7 @@ updated to the reader page.
|
|||
| +-----------------------------+ |
|
||||
+------------------------------------+
|
||||
|
||||
Another important point. The page that the reader page points back to
|
||||
Another important point: The page that the reader page points back to
|
||||
by its previous pointer (the one that now points to the new head page)
|
||||
never points back to the reader page. That is because the reader page is
|
||||
not part of the ring buffer. Traversing the ring buffer via the next pointers
|
||||
|
|
@ -572,7 +572,7 @@ not be able to swap the head page from the buffer, nor will it be able to
|
|||
move the head page, until the writer is finished with the move.
|
||||
|
||||
This eliminates any races that the reader can have on the writer. The reader
|
||||
must spin, and this is why the reader can not preempt the writer.
|
||||
must spin, and this is why the reader cannot preempt the writer.
|
||||
|
||||
tail page
|
||||
|
|
||||
|
|
@ -659,9 +659,9 @@ before pushing the head page. If it is, then it can be assumed that the
|
|||
tail page wrapped the buffer, and we must drop new writes.
|
||||
|
||||
This is not a race condition, because the commit page can only be moved
|
||||
by the outter most writer (the writer that was preempted).
|
||||
by the outermost writer (the writer that was preempted).
|
||||
This means that the commit will not move while a writer is moving the
|
||||
tail page. The reader can not swap the reader page if it is also being
|
||||
tail page. The reader cannot swap the reader page if it is also being
|
||||
used as the commit page. The reader can simply check that the commit
|
||||
is off the reader page. Once the commit page leaves the reader page
|
||||
it will never go back on it unless a reader does another swap with the
|
||||
|
|
@ -733,7 +733,7 @@ The write converts the head page pointer to UPDATE.
|
|||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
But if a nested writer preempts here. It will see that the next
|
||||
But if a nested writer preempts here, it will see that the next
|
||||
page is a head page, but it is also nested. It will detect that
|
||||
it is nested and will save that information. The detection is the
|
||||
fact that it sees the UPDATE flag instead of a HEADER or NORMAL
|
||||
|
|
@ -761,7 +761,7 @@ to NORMAL.
|
|||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
After the nested writer finishes, the outer most writer will convert
|
||||
After the nested writer finishes, the outermost writer will convert
|
||||
the UPDATE pointer to NORMAL.
|
||||
|
||||
|
||||
|
|
@ -812,7 +812,7 @@ head page.
|
|||
+---+ +---+ +---+ +---+
|
||||
|
||||
The nested writer moves the tail page forward. But does not set the old
|
||||
update page to NORMAL because it is not the outer most writer.
|
||||
update page to NORMAL because it is not the outermost writer.
|
||||
|
||||
tail page
|
||||
|
|
||||
|
|
@ -892,7 +892,7 @@ It will return to the first writer.
|
|||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
The first writer can not know atomically test if the tail page moved
|
||||
The first writer cannot know atomically if the tail page moved
|
||||
while it updates the HEAD page. It will then update the head page to
|
||||
what it thinks is the new head page.
|
||||
|
||||
|
|
@ -923,9 +923,9 @@ if the tail page is either where it use to be or on the next page:
|
|||
--->| |<---| |<---| |<---| |<---
|
||||
+---+ +---+ +---+ +---+
|
||||
|
||||
If tail page != A and tail page does not equal B, then it must reset the
|
||||
pointer back to NORMAL. The fact that it only needs to worry about
|
||||
nested writers, it only needs to check this after setting the HEAD page.
|
||||
If tail page != A and tail page != B, then it must reset the pointer
|
||||
back to NORMAL. The fact that it only needs to worry about nested
|
||||
writers means that it only needs to check this after setting the HEAD page.
|
||||
|
||||
|
||||
(first writer)
|
||||
|
|
@ -939,7 +939,7 @@ nested writers, it only needs to check this after setting the HEAD page.
|
|||
+---+ +---+ +---+ +---+
|
||||
|
||||
Now the writer can update the head page. This is also why the head page must
|
||||
remain in UPDATE and only reset by the outer most writer. This prevents
|
||||
remain in UPDATE and only reset by the outermost writer. This prevents
|
||||
the reader from seeing the incorrect head page.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -10,8 +10,8 @@ Tracepoints (see Documentation/trace/tracepoints.txt) can be used without
|
|||
creating custom kernel modules to register probe functions using the event
|
||||
tracing infrastructure.
|
||||
|
||||
Simplistically, tracepoints will represent an important event that when can
|
||||
be taken in conjunction with other tracepoints to build a "Big Picture" of
|
||||
Simplistically, tracepoints represent important events that can be
|
||||
taken in conjunction with other tracepoints to build a "Big Picture" of
|
||||
what is going on within the system. There are a large number of methods for
|
||||
gathering and interpreting these events. Lacking any current Best Practises,
|
||||
this document describes some of the methods that can be used.
|
||||
|
|
@ -33,12 +33,12 @@ calling
|
|||
|
||||
will give a fair indication of the number of events available.
|
||||
|
||||
2.2 PCL
|
||||
2.2 PCL (Performance Counters for Linux)
|
||||
-------
|
||||
|
||||
Discovery and enumeration of all counters and events, including tracepoints
|
||||
Discovery and enumeration of all counters and events, including tracepoints,
|
||||
are available with the perf tool. Getting a list of available events is a
|
||||
simple case of
|
||||
simple case of:
|
||||
|
||||
$ perf list 2>&1 | grep Tracepoint
|
||||
ext4:ext4_free_inode [Tracepoint event]
|
||||
|
|
@ -49,19 +49,19 @@ simple case of
|
|||
[ .... remaining output snipped .... ]
|
||||
|
||||
|
||||
2. Enabling Events
|
||||
3. Enabling Events
|
||||
==================
|
||||
|
||||
2.1 System-Wide Event Enabling
|
||||
3.1 System-Wide Event Enabling
|
||||
------------------------------
|
||||
|
||||
See Documentation/trace/events.txt for a proper description on how events
|
||||
can be enabled system-wide. A short example of enabling all events related
|
||||
to page allocation would look something like
|
||||
to page allocation would look something like:
|
||||
|
||||
$ for i in `find /sys/kernel/debug/tracing/events -name "enable" | grep mm_`; do echo 1 > $i; done
|
||||
|
||||
2.2 System-Wide Event Enabling with SystemTap
|
||||
3.2 System-Wide Event Enabling with SystemTap
|
||||
---------------------------------------------
|
||||
|
||||
In SystemTap, tracepoints are accessible using the kernel.trace() function
|
||||
|
|
@ -86,7 +86,7 @@ were allocating the pages.
|
|||
print_count()
|
||||
}
|
||||
|
||||
2.3 System-Wide Event Enabling with PCL
|
||||
3.3 System-Wide Event Enabling with PCL
|
||||
---------------------------------------
|
||||
|
||||
By specifying the -a switch and analysing sleep, the system-wide events
|
||||
|
|
@ -107,16 +107,16 @@ for a duration of time can be examined.
|
|||
Similarly, one could execute a shell and exit it as desired to get a report
|
||||
at that point.
|
||||
|
||||
2.4 Local Event Enabling
|
||||
3.4 Local Event Enabling
|
||||
------------------------
|
||||
|
||||
Documentation/trace/ftrace.txt describes how to enable events on a per-thread
|
||||
basis using set_ftrace_pid.
|
||||
|
||||
2.5 Local Event Enablement with PCL
|
||||
3.5 Local Event Enablement with PCL
|
||||
-----------------------------------
|
||||
|
||||
Events can be activate and tracked for the duration of a process on a local
|
||||
Events can be activated and tracked for the duration of a process on a local
|
||||
basis using PCL such as follows.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
|
|
@ -131,18 +131,18 @@ basis using PCL such as follows.
|
|||
|
||||
0.973913387 seconds time elapsed
|
||||
|
||||
3. Event Filtering
|
||||
4. Event Filtering
|
||||
==================
|
||||
|
||||
Documentation/trace/ftrace.txt covers in-depth how to filter events in
|
||||
ftrace. Obviously using grep and awk of trace_pipe is an option as well
|
||||
as any script reading trace_pipe.
|
||||
|
||||
4. Analysing Event Variances with PCL
|
||||
5. Analysing Event Variances with PCL
|
||||
=====================================
|
||||
|
||||
Any workload can exhibit variances between runs and it can be important
|
||||
to know what the standard deviation in. By and large, this is left to the
|
||||
to know what the standard deviation is. By and large, this is left to the
|
||||
performance analyst to do it by hand. In the event that the discrete event
|
||||
occurrences are useful to the performance analyst, then perf can be used.
|
||||
|
||||
|
|
@ -166,7 +166,7 @@ In the event that some higher-level event is required that depends on some
|
|||
aggregation of discrete events, then a script would need to be developed.
|
||||
|
||||
Using --repeat, it is also possible to view how events are fluctuating over
|
||||
time on a system wide basis using -a and sleep.
|
||||
time on a system-wide basis using -a and sleep.
|
||||
|
||||
$ perf stat -e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
-e kmem:mm_pagevec_free \
|
||||
|
|
@ -180,7 +180,7 @@ time on a system wide basis using -a and sleep.
|
|||
|
||||
1.002251757 seconds time elapsed ( +- 0.005% )
|
||||
|
||||
5. Higher-Level Analysis with Helper Scripts
|
||||
6. Higher-Level Analysis with Helper Scripts
|
||||
============================================
|
||||
|
||||
When events are enabled the events that are triggering can be read from
|
||||
|
|
@ -190,11 +190,11 @@ be gathered on-line as appropriate. Examples of post-processing might include
|
|||
|
||||
o Reading information from /proc for the PID that triggered the event
|
||||
o Deriving a higher-level event from a series of lower-level events.
|
||||
o Calculate latencies between two events
|
||||
o Calculating latencies between two events
|
||||
|
||||
Documentation/trace/postprocess/trace-pagealloc-postprocess.pl is an example
|
||||
script that can read trace_pipe from STDIN or a copy of a trace. When used
|
||||
on-line, it can be interrupted once to generate a report without existing
|
||||
on-line, it can be interrupted once to generate a report without exiting
|
||||
and twice to exit.
|
||||
|
||||
Simplistically, the script just reads STDIN and counts up events but it
|
||||
|
|
@ -212,12 +212,12 @@ also can do more such as
|
|||
processes, the parent process responsible for creating all the helpers
|
||||
can be identified
|
||||
|
||||
6. Lower-Level Analysis with PCL
|
||||
7. Lower-Level Analysis with PCL
|
||||
================================
|
||||
|
||||
There may also be a requirement to identify what functions with a program
|
||||
There may also be a requirement to identify what functions within a program
|
||||
were generating events within the kernel. To begin this sort of analysis, the
|
||||
data must be recorded. At the time of writing, this required root
|
||||
data must be recorded. At the time of writing, this required root:
|
||||
|
||||
$ perf record -c 1 \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
|
|
@ -253,11 +253,11 @@ perf report.
|
|||
# (For more details, try: perf report --sort comm,dso,symbol)
|
||||
#
|
||||
|
||||
According to this, the vast majority of events occured triggered on events
|
||||
within the VDSO. With simple binaries, this will often be the case so lets
|
||||
According to this, the vast majority of events triggered on events
|
||||
within the VDSO. With simple binaries, this will often be the case so let's
|
||||
take a slightly different example. In the course of writing this, it was
|
||||
noticed that X was generating an insane amount of page allocations so lets look
|
||||
at it
|
||||
noticed that X was generating an insane amount of page allocations so let's look
|
||||
at it:
|
||||
|
||||
$ perf record -c 1 -f \
|
||||
-e kmem:mm_page_alloc -e kmem:mm_page_free_direct \
|
||||
|
|
@ -280,8 +280,8 @@ This was interrupted after a few seconds and
|
|||
# (For more details, try: perf report --sort comm,dso,symbol)
|
||||
#
|
||||
|
||||
So, almost half of the events are occuring in a library. To get an idea which
|
||||
symbol.
|
||||
So, almost half of the events are occurring in a library. To get an idea which
|
||||
symbol:
|
||||
|
||||
$ perf report --sort comm,dso,symbol
|
||||
# Samples: 27666
|
||||
|
|
@ -297,7 +297,7 @@ symbol.
|
|||
0.01% Xorg /opt/gfx-test/lib/libpixman-1.so.0.13.1 [.] get_fast_path
|
||||
0.00% Xorg [kernel] [k] ftrace_trace_userstack
|
||||
|
||||
To see where within the function pixmanFillsse2 things are going wrong
|
||||
To see where within the function pixmanFillsse2 things are going wrong:
|
||||
|
||||
$ perf annotate pixmanFillsse2
|
||||
[ ... ]
|
||||
|
|
|
|||
|
|
@ -71,12 +71,10 @@ being accessed through sysfs, then it definitely is idle.
|
|||
Forms of dynamic PM
|
||||
-------------------
|
||||
|
||||
Dynamic suspends can occur in two ways: manual and automatic.
|
||||
"Manual" means that the user has told the kernel to suspend a device,
|
||||
whereas "automatic" means that the kernel has decided all by itself to
|
||||
suspend a device. Automatic suspend is called "autosuspend" for
|
||||
short. In general, a device won't be autosuspended unless it has been
|
||||
idle for some minimum period of time, the so-called idle-delay time.
|
||||
Dynamic suspends occur when the kernel decides to suspend an idle
|
||||
device. This is called "autosuspend" for short. In general, a device
|
||||
won't be autosuspended unless it has been idle for some minimum period
|
||||
of time, the so-called idle-delay time.
|
||||
|
||||
Of course, nothing the kernel does on its own initiative should
|
||||
prevent the computer or its devices from working properly. If a
|
||||
|
|
@ -96,10 +94,11 @@ idle.
|
|||
We can categorize power management events in two broad classes:
|
||||
external and internal. External events are those triggered by some
|
||||
agent outside the USB stack: system suspend/resume (triggered by
|
||||
userspace), manual dynamic suspend/resume (also triggered by
|
||||
userspace), and remote wakeup (triggered by the device). Internal
|
||||
events are those triggered within the USB stack: autosuspend and
|
||||
autoresume.
|
||||
userspace), manual dynamic resume (also triggered by userspace), and
|
||||
remote wakeup (triggered by the device). Internal events are those
|
||||
triggered within the USB stack: autosuspend and autoresume. Note that
|
||||
all dynamic suspend events are internal; external agents are not
|
||||
allowed to issue dynamic suspends.
|
||||
|
||||
|
||||
The user interface for dynamic PM
|
||||
|
|
@ -145,9 +144,9 @@ relevant attribute files are: wakeup, level, and autosuspend.
|
|||
number of seconds the device should remain idle before
|
||||
the kernel will autosuspend it (the idle-delay time).
|
||||
The default is 2. 0 means to autosuspend as soon as
|
||||
the device becomes idle, and -1 means never to
|
||||
autosuspend. You can write a number to the file to
|
||||
change the autosuspend idle-delay time.
|
||||
the device becomes idle, and negative values mean
|
||||
never to autosuspend. You can write a number to the
|
||||
file to change the autosuspend idle-delay time.
|
||||
|
||||
Writing "-1" to power/autosuspend and writing "on" to power/level do
|
||||
essentially the same thing -- they both prevent the device from being
|
||||
|
|
@ -377,9 +376,9 @@ the device hasn't been idle for long enough, a delayed workqueue
|
|||
routine is automatically set up to carry out the operation when the
|
||||
autosuspend idle-delay has expired.
|
||||
|
||||
Autoresume attempts also can fail. This will happen if power/level is
|
||||
set to "suspend" or if the device doesn't manage to resume properly.
|
||||
Unlike autosuspend, there's no delay for an autoresume.
|
||||
Autoresume attempts also can fail, although failure would mean that
|
||||
the device is no longer present or operating properly. Unlike
|
||||
autosuspend, there's no delay for an autoresume.
|
||||
|
||||
|
||||
Other parts of the driver interface
|
||||
|
|
@ -527,13 +526,3 @@ succeed, it may still remain active and thus cause the system to
|
|||
resume as soon as the system suspend is complete. Or the remote
|
||||
wakeup may fail and get lost. Which outcome occurs depends on timing
|
||||
and on the hardware and firmware design.
|
||||
|
||||
More interestingly, a device might undergo a manual resume or
|
||||
autoresume during system suspend. With current kernels this shouldn't
|
||||
happen, because manual resumes must be initiated by userspace and
|
||||
autoresumes happen in response to I/O requests, but all user processes
|
||||
and I/O should be quiescent during a system suspend -- thanks to the
|
||||
freezer. However there are plans to do away with the freezer, which
|
||||
would mean these things would become possible. If and when this comes
|
||||
about, the USB core will carefully arrange matters so that either type
|
||||
of resume will block until the entire system has resumed.
|
||||
|
|
|
|||
|
|
@ -103,7 +103,7 @@ I.2 libpciaccess
|
|||
----------------
|
||||
|
||||
To use the vga arbiter char device it was implemented an API inside the
|
||||
libpciaccess library. One fieldd was added to struct pci_device (each device
|
||||
libpciaccess library. One field was added to struct pci_device (each device
|
||||
on the system):
|
||||
|
||||
/* the type of resource decoded by the device */
|
||||
|
|
|
|||
|
|
@ -12,6 +12,7 @@ m5602 0402:5602 ALi Video Camera Controller
|
|||
spca501 040a:0002 Kodak DVC-325
|
||||
spca500 040a:0300 Kodak EZ200
|
||||
zc3xx 041e:041e Creative WebCam Live!
|
||||
ov519 041e:4003 Video Blaster WebCam Go Plus
|
||||
spca500 041e:400a Creative PC-CAM 300
|
||||
sunplus 041e:400b Creative PC-CAM 600
|
||||
sunplus 041e:4012 PC-Cam350
|
||||
|
|
@ -168,10 +169,14 @@ sunplus 055f:c650 Mustek MDC5500Z
|
|||
zc3xx 055f:d003 Mustek WCam300A
|
||||
zc3xx 055f:d004 Mustek WCam300 AN
|
||||
conex 0572:0041 Creative Notebook cx11646
|
||||
ov519 05a9:0511 Video Blaster WebCam 3/WebCam Plus, D-Link USB Digital Video Camera
|
||||
ov519 05a9:0518 Creative WebCam
|
||||
ov519 05a9:0519 OV519 Microphone
|
||||
ov519 05a9:0530 OmniVision
|
||||
ov519 05a9:2800 OmniVision SuperCAM
|
||||
ov519 05a9:4519 Webcam Classic
|
||||
ov519 05a9:8519 OmniVision
|
||||
ov519 05a9:a511 D-Link USB Digital Video Camera
|
||||
ov519 05a9:a518 D-Link DSB-C310 Webcam
|
||||
sunplus 05da:1018 Digital Dream Enigma 1.3
|
||||
stk014 05e1:0893 Syntek DV4000
|
||||
|
|
@ -187,7 +192,7 @@ ov534 06f8:3002 Hercules Blog Webcam
|
|||
ov534 06f8:3003 Hercules Dualpix HD Weblog
|
||||
sonixj 06f8:3004 Hercules Classic Silver
|
||||
sonixj 06f8:3008 Hercules Deluxe Optical Glass
|
||||
pac7311 06f8:3009 Hercules Classic Link
|
||||
pac7302 06f8:3009 Hercules Classic Link
|
||||
spca508 0733:0110 ViewQuest VQ110
|
||||
spca501 0733:0401 Intel Create and Share
|
||||
spca501 0733:0402 ViewQuest M318B
|
||||
|
|
@ -199,6 +204,7 @@ sunplus 0733:2221 Mercury Digital Pro 3.1p
|
|||
sunplus 0733:3261 Concord 3045 spca536a
|
||||
sunplus 0733:3281 Cyberpix S550V
|
||||
spca506 0734:043b 3DeMon USB Capture aka
|
||||
ov519 0813:0002 Dual Mode USB Camera Plus
|
||||
spca500 084d:0003 D-Link DSC-350
|
||||
spca500 08ca:0103 Aiptek PocketDV
|
||||
sunplus 08ca:0104 Aiptek PocketDVII 1.3
|
||||
|
|
@ -236,15 +242,15 @@ pac7311 093a:2603 Philips SPC 500 NC
|
|||
pac7311 093a:2608 Trust WB-3300p
|
||||
pac7311 093a:260e Gigaware VGA PC Camera, Trust WB-3350p, SIGMA cam 2350
|
||||
pac7311 093a:260f SnakeCam
|
||||
pac7311 093a:2620 Apollo AC-905
|
||||
pac7311 093a:2621 PAC731x
|
||||
pac7311 093a:2622 Genius Eye 312
|
||||
pac7311 093a:2624 PAC7302
|
||||
pac7311 093a:2626 Labtec 2200
|
||||
pac7311 093a:2628 Genius iLook 300
|
||||
pac7311 093a:2629 Genious iSlim 300
|
||||
pac7311 093a:262a Webcam 300k
|
||||
pac7311 093a:262c Philips SPC 230 NC
|
||||
pac7302 093a:2620 Apollo AC-905
|
||||
pac7302 093a:2621 PAC731x
|
||||
pac7302 093a:2622 Genius Eye 312
|
||||
pac7302 093a:2624 PAC7302
|
||||
pac7302 093a:2626 Labtec 2200
|
||||
pac7302 093a:2628 Genius iLook 300
|
||||
pac7302 093a:2629 Genious iSlim 300
|
||||
pac7302 093a:262a Webcam 300k
|
||||
pac7302 093a:262c Philips SPC 230 NC
|
||||
jeilinj 0979:0280 Sakar 57379
|
||||
zc3xx 0ac8:0302 Z-star Vimicro zc0302
|
||||
vc032x 0ac8:0321 Vimicro generic vc0321
|
||||
|
|
@ -259,6 +265,7 @@ vc032x 0ac8:c002 Sony embedded vimicro
|
|||
vc032x 0ac8:c301 Samsung Q1 Ultra Premium
|
||||
spca508 0af9:0010 Hama USB Sightcam 100
|
||||
spca508 0af9:0011 Hama USB Sightcam 100
|
||||
ov519 0b62:0059 iBOT2 Webcam
|
||||
sonixb 0c45:6001 Genius VideoCAM NB
|
||||
sonixb 0c45:6005 Microdia Sweex Mini Webcam
|
||||
sonixb 0c45:6007 Sonix sn9c101 + Tas5110D
|
||||
|
|
@ -318,8 +325,10 @@ sn9c20x 0c45:62b3 PC Camera (SN9C202 + OV9655)
|
|||
sn9c20x 0c45:62bb PC Camera (SN9C202 + OV7660)
|
||||
sn9c20x 0c45:62bc PC Camera (SN9C202 + HV7131R)
|
||||
sunplus 0d64:0303 Sunplus FashionCam DXG
|
||||
ov519 0e96:c001 TRUST 380 USB2 SPACEC@M
|
||||
etoms 102c:6151 Qcam Sangha CIF
|
||||
etoms 102c:6251 Qcam xxxxxx VGA
|
||||
ov519 1046:9967 W9967CF/W9968CF WebCam IC, Video Blaster WebCam Go
|
||||
zc3xx 10fd:0128 Typhoon Webshot II USB 300k 0x0128
|
||||
spca561 10fd:7e50 FlyCam Usb 100
|
||||
zc3xx 10fd:8050 Typhoon Webshot II USB 300k
|
||||
|
|
@ -332,7 +341,12 @@ spca501 1776:501c Arowana 300K CMOS Camera
|
|||
t613 17a1:0128 TASCORP JPEG Webcam, NGS Cyclops
|
||||
vc032x 17ef:4802 Lenovo Vc0323+MI1310_SOC
|
||||
pac207 2001:f115 D-Link DSB-C120
|
||||
sq905c 2770:9050 sq905c
|
||||
sq905c 2770:905c DualCamera
|
||||
sq905 2770:9120 Argus Digital Camera DC1512
|
||||
sq905c 2770:913d sq905c
|
||||
spca500 2899:012c Toptro Industrial
|
||||
ov519 8020:ef04 ov519
|
||||
spca508 8086:0110 Intel Easy PC Camera
|
||||
spca500 8086:0630 Intel Pocket PC Camera
|
||||
spca506 99fa:8988 Grandtec V.cap
|
||||
|
|
|
|||
|
|
@ -0,0 +1,157 @@
|
|||
Cropping and Scaling algorithm, used in the sh_mobile_ceu_camera driver
|
||||
=======================================================================
|
||||
|
||||
Terminology
|
||||
-----------
|
||||
|
||||
sensor scales: horizontal and vertical scales, configured by the sensor driver
|
||||
host scales: -"- host driver
|
||||
combined scales: sensor_scale * host_scale
|
||||
|
||||
|
||||
Generic scaling / cropping scheme
|
||||
---------------------------------
|
||||
|
||||
-1--
|
||||
|
|
||||
-2-- -\
|
||||
| --\
|
||||
| --\
|
||||
+-5-- -\ -- -3--
|
||||
| ---\
|
||||
| --- -4-- -\
|
||||
| -\
|
||||
| - -6--
|
||||
|
|
||||
| - -6'-
|
||||
| -/
|
||||
| --- -4'- -/
|
||||
| ---/
|
||||
+-5'- -/
|
||||
| -- -3'-
|
||||
| --/
|
||||
| --/
|
||||
-2'- -/
|
||||
|
|
||||
|
|
||||
-1'-
|
||||
|
||||
Produced by user requests:
|
||||
|
||||
S_CROP(left / top = (5) - (1), width / height = (5') - (5))
|
||||
S_FMT(width / height = (6') - (6))
|
||||
|
||||
Here:
|
||||
|
||||
(1) to (1') - whole max width or height
|
||||
(1) to (2) - sensor cropped left or top
|
||||
(2) to (2') - sensor cropped width or height
|
||||
(3) to (3') - sensor scale
|
||||
(3) to (4) - CEU cropped left or top
|
||||
(4) to (4') - CEU cropped width or height
|
||||
(5) to (5') - reverse sensor scale applied to CEU cropped width or height
|
||||
(2) to (5) - reverse sensor scale applied to CEU cropped left or top
|
||||
(6) to (6') - CEU scale - user window
|
||||
|
||||
|
||||
S_FMT
|
||||
-----
|
||||
|
||||
Do not touch input rectangle - it is already optimal.
|
||||
|
||||
1. Calculate current sensor scales:
|
||||
|
||||
scale_s = ((3') - (3)) / ((2') - (2))
|
||||
|
||||
2. Calculate "effective" input crop (sensor subwindow) - CEU crop scaled back at
|
||||
current sensor scales onto input window - this is user S_CROP:
|
||||
|
||||
width_u = (5') - (5) = ((4') - (4)) * scale_s
|
||||
|
||||
3. Calculate new combined scales from "effective" input window to requested user
|
||||
window:
|
||||
|
||||
scale_comb = width_u / ((6') - (6))
|
||||
|
||||
4. Calculate sensor output window by applying combined scales to real input
|
||||
window:
|
||||
|
||||
width_s_out = ((2') - (2)) / scale_comb
|
||||
|
||||
5. Apply iterative sensor S_FMT for sensor output window.
|
||||
|
||||
subdev->video_ops->s_fmt(.width = width_s_out)
|
||||
|
||||
6. Retrieve sensor output window (g_fmt)
|
||||
|
||||
7. Calculate new sensor scales:
|
||||
|
||||
scale_s_new = ((3')_new - (3)_new) / ((2') - (2))
|
||||
|
||||
8. Calculate new CEU crop - apply sensor scales to previously calculated
|
||||
"effective" crop:
|
||||
|
||||
width_ceu = (4')_new - (4)_new = width_u / scale_s_new
|
||||
left_ceu = (4)_new - (3)_new = ((5) - (2)) / scale_s_new
|
||||
|
||||
9. Use CEU cropping to crop to the new window:
|
||||
|
||||
ceu_crop(.width = width_ceu, .left = left_ceu)
|
||||
|
||||
10. Use CEU scaling to scale to the requested user window:
|
||||
|
||||
scale_ceu = width_ceu / width
|
||||
|
||||
|
||||
S_CROP
|
||||
------
|
||||
|
||||
If old scale applied to new crop is invalid produce nearest new scale possible
|
||||
|
||||
1. Calculate current combined scales.
|
||||
|
||||
scale_comb = (((4') - (4)) / ((6') - (6))) * (((2') - (2)) / ((3') - (3)))
|
||||
|
||||
2. Apply iterative sensor S_CROP for new input window.
|
||||
|
||||
3. If old combined scales applied to new crop produce an impossible user window,
|
||||
adjust scales to produce nearest possible window.
|
||||
|
||||
width_u_out = ((5') - (5)) / scale_comb
|
||||
|
||||
if (width_u_out > max)
|
||||
scale_comb = ((5') - (5)) / max;
|
||||
else if (width_u_out < min)
|
||||
scale_comb = ((5') - (5)) / min;
|
||||
|
||||
4. Issue G_CROP to retrieve actual input window.
|
||||
|
||||
5. Using actual input window and calculated combined scales calculate sensor
|
||||
target output window.
|
||||
|
||||
width_s_out = ((3') - (3)) = ((2') - (2)) / scale_comb
|
||||
|
||||
6. Apply iterative S_FMT for new sensor target output window.
|
||||
|
||||
7. Issue G_FMT to retrieve the actual sensor output window.
|
||||
|
||||
8. Calculate sensor scales.
|
||||
|
||||
scale_s = ((3') - (3)) / ((2') - (2))
|
||||
|
||||
9. Calculate sensor output subwindow to be cropped on CEU by applying sensor
|
||||
scales to the requested window.
|
||||
|
||||
width_ceu = ((5') - (5)) / scale_s
|
||||
|
||||
10. Use CEU cropping for above calculated window.
|
||||
|
||||
11. Calculate CEU scales from sensor scales from results of (10) and user window
|
||||
from (3)
|
||||
|
||||
scale_ceu = calc_scale(((5') - (5)), &width_u_out)
|
||||
|
||||
12. Apply CEU scales.
|
||||
|
||||
--
|
||||
Author: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
|
||||
|
|
@ -561,6 +561,8 @@ video_device helper functions
|
|||
|
||||
There are a few useful helper functions:
|
||||
|
||||
- file/video_device private data
|
||||
|
||||
You can set/get driver private data in the video_device struct using:
|
||||
|
||||
void *video_get_drvdata(struct video_device *vdev);
|
||||
|
|
@ -575,8 +577,7 @@ struct video_device *video_devdata(struct file *file);
|
|||
|
||||
returns the video_device belonging to the file struct.
|
||||
|
||||
The final helper function combines video_get_drvdata with
|
||||
video_devdata:
|
||||
The video_drvdata function combines video_get_drvdata with video_devdata:
|
||||
|
||||
void *video_drvdata(struct file *file);
|
||||
|
||||
|
|
@ -584,6 +585,17 @@ You can go from a video_device struct to the v4l2_device struct using:
|
|||
|
||||
struct v4l2_device *v4l2_dev = vdev->v4l2_dev;
|
||||
|
||||
- Device node name
|
||||
|
||||
The video_device node kernel name can be retrieved using
|
||||
|
||||
const char *video_device_node_name(struct video_device *vdev);
|
||||
|
||||
The name is used as a hint by userspace tools such as udev. The function
|
||||
should be used where possible instead of accessing the video_device::num and
|
||||
video_device::minor fields.
|
||||
|
||||
|
||||
video buffer helper functions
|
||||
-----------------------------
|
||||
|
||||
|
|
|
|||
|
|
@ -11,23 +11,21 @@ This optimization is more critical now as bigger and bigger physical memories
|
|||
(several GBs) are more readily available.
|
||||
|
||||
Users can use the huge page support in Linux kernel by either using the mmap
|
||||
system call or standard SYSv shared memory system calls (shmget, shmat).
|
||||
system call or standard SYSV shared memory system calls (shmget, shmat).
|
||||
|
||||
First the Linux kernel needs to be built with the CONFIG_HUGETLBFS
|
||||
(present under "File systems") and CONFIG_HUGETLB_PAGE (selected
|
||||
automatically when CONFIG_HUGETLBFS is selected) configuration
|
||||
options.
|
||||
|
||||
The kernel built with huge page support should show the number of configured
|
||||
huge pages in the system by running the "cat /proc/meminfo" command.
|
||||
The /proc/meminfo file provides information about the total number of
|
||||
persistent hugetlb pages in the kernel's huge page pool. It also displays
|
||||
information about the number of free, reserved and surplus huge pages and the
|
||||
default huge page size. The huge page size is needed for generating the
|
||||
proper alignment and size of the arguments to system calls that map huge page
|
||||
regions.
|
||||
|
||||
/proc/meminfo also provides information about the total number of hugetlb
|
||||
pages configured in the kernel. It also displays information about the
|
||||
number of free hugetlb pages at any time. It also displays information about
|
||||
the configured huge page size - this is needed for generating the proper
|
||||
alignment and size of the arguments to the above system calls.
|
||||
|
||||
The output of "cat /proc/meminfo" will have lines like:
|
||||
The output of "cat /proc/meminfo" will include lines like:
|
||||
|
||||
.....
|
||||
HugePages_Total: vvv
|
||||
|
|
@ -53,59 +51,63 @@ HugePages_Surp is short for "surplus," and is the number of huge pages in
|
|||
/proc/filesystems should also show a filesystem of type "hugetlbfs" configured
|
||||
in the kernel.
|
||||
|
||||
/proc/sys/vm/nr_hugepages indicates the current number of configured hugetlb
|
||||
pages in the kernel. Super user can dynamically request more (or free some
|
||||
pre-configured) huge pages.
|
||||
The allocation (or deallocation) of hugetlb pages is possible only if there are
|
||||
enough physically contiguous free pages in system (freeing of huge pages is
|
||||
possible only if there are enough hugetlb pages free that can be transferred
|
||||
back to regular memory pool).
|
||||
/proc/sys/vm/nr_hugepages indicates the current number of "persistent" huge
|
||||
pages in the kernel's huge page pool. "Persistent" huge pages will be
|
||||
returned to the huge page pool when freed by a task. A user with root
|
||||
privileges can dynamically allocate more or free some persistent huge pages
|
||||
by increasing or decreasing the value of 'nr_hugepages'.
|
||||
|
||||
Pages that are used as hugetlb pages are reserved inside the kernel and cannot
|
||||
be used for other purposes.
|
||||
Pages that are used as huge pages are reserved inside the kernel and cannot
|
||||
be used for other purposes. Huge pages cannot be swapped out under
|
||||
memory pressure.
|
||||
|
||||
Once the kernel with Hugetlb page support is built and running, a user can
|
||||
use either the mmap system call or shared memory system calls to start using
|
||||
the huge pages. It is required that the system administrator preallocate
|
||||
enough memory for huge page purposes.
|
||||
Once a number of huge pages have been pre-allocated to the kernel huge page
|
||||
pool, a user with appropriate privilege can use either the mmap system call
|
||||
or shared memory system calls to use the huge pages. See the discussion of
|
||||
Using Huge Pages, below.
|
||||
|
||||
The administrator can preallocate huge pages on the kernel boot command line by
|
||||
specifying the "hugepages=N" parameter, where 'N' = the number of huge pages
|
||||
requested. This is the most reliable method for preallocating huge pages as
|
||||
memory has not yet become fragmented.
|
||||
The administrator can allocate persistent huge pages on the kernel boot
|
||||
command line by specifying the "hugepages=N" parameter, where 'N' = the
|
||||
number of huge pages requested. This is the most reliable method of
|
||||
allocating huge pages as memory has not yet become fragmented.
|
||||
|
||||
Some platforms support multiple huge page sizes. To preallocate huge pages
|
||||
Some platforms support multiple huge page sizes. To allocate huge pages
|
||||
of a specific size, one must preceed the huge pages boot command parameters
|
||||
with a huge page size selection parameter "hugepagesz=<size>". <size> must
|
||||
be specified in bytes with optional scale suffix [kKmMgG]. The default huge
|
||||
page size may be selected with the "default_hugepagesz=<size>" boot parameter.
|
||||
|
||||
/proc/sys/vm/nr_hugepages indicates the current number of configured [default
|
||||
size] hugetlb pages in the kernel. Super user can dynamically request more
|
||||
(or free some pre-configured) huge pages.
|
||||
|
||||
Use the following command to dynamically allocate/deallocate default sized
|
||||
huge pages:
|
||||
When multiple huge page sizes are supported, /proc/sys/vm/nr_hugepages
|
||||
indicates the current number of pre-allocated huge pages of the default size.
|
||||
Thus, one can use the following command to dynamically allocate/deallocate
|
||||
default sized persistent huge pages:
|
||||
|
||||
echo 20 > /proc/sys/vm/nr_hugepages
|
||||
|
||||
This command will try to configure 20 default sized huge pages in the system.
|
||||
This command will try to adjust the number of default sized huge pages in the
|
||||
huge page pool to 20, allocating or freeing huge pages, as required.
|
||||
|
||||
On a NUMA platform, the kernel will attempt to distribute the huge page pool
|
||||
over the all on-line nodes. These huge pages, allocated when nr_hugepages
|
||||
is increased, are called "persistent huge pages".
|
||||
over all the set of allowed nodes specified by the NUMA memory policy of the
|
||||
task that modifies nr_hugepages. The default for the allowed nodes--when the
|
||||
task has default memory policy--is all on-line nodes with memory. Allowed
|
||||
nodes with insufficient available, contiguous memory for a huge page will be
|
||||
silently skipped when allocating persistent huge pages. See the discussion
|
||||
below of the interaction of task memory policy, cpusets and per node attributes
|
||||
with the allocation and freeing of persistent huge pages.
|
||||
|
||||
The success or failure of huge page allocation depends on the amount of
|
||||
physically contiguous memory that is preset in system at the time of the
|
||||
physically contiguous memory that is present in system at the time of the
|
||||
allocation attempt. If the kernel is unable to allocate huge pages from
|
||||
some nodes in a NUMA system, it will attempt to make up the difference by
|
||||
allocating extra pages on other nodes with sufficient available contiguous
|
||||
memory, if any.
|
||||
|
||||
System administrators may want to put this command in one of the local rc init
|
||||
files. This will enable the kernel to request huge pages early in the boot
|
||||
process when the possibility of getting physical contiguous pages is still
|
||||
very high. Administrators can verify the number of huge pages actually
|
||||
allocated by checking the sysctl or meminfo. To check the per node
|
||||
System administrators may want to put this command in one of the local rc
|
||||
init files. This will enable the kernel to allocate huge pages early in
|
||||
the boot process when the possibility of getting physical contiguous pages
|
||||
is still very high. Administrators can verify the number of huge pages
|
||||
actually allocated by checking the sysctl or meminfo. To check the per node
|
||||
distribution of huge pages in a NUMA system, use:
|
||||
|
||||
cat /sys/devices/system/node/node*/meminfo | fgrep Huge
|
||||
|
|
@ -113,45 +115,47 @@ distribution of huge pages in a NUMA system, use:
|
|||
/proc/sys/vm/nr_overcommit_hugepages specifies how large the pool of
|
||||
huge pages can grow, if more huge pages than /proc/sys/vm/nr_hugepages are
|
||||
requested by applications. Writing any non-zero value into this file
|
||||
indicates that the hugetlb subsystem is allowed to try to obtain "surplus"
|
||||
huge pages from the buddy allocator, when the normal pool is exhausted. As
|
||||
these surplus huge pages go out of use, they are freed back to the buddy
|
||||
allocator.
|
||||
indicates that the hugetlb subsystem is allowed to try to obtain that
|
||||
number of "surplus" huge pages from the kernel's normal page pool, when the
|
||||
persistent huge page pool is exhausted. As these surplus huge pages become
|
||||
unused, they are freed back to the kernel's normal page pool.
|
||||
|
||||
When increasing the huge page pool size via nr_hugepages, any surplus
|
||||
When increasing the huge page pool size via nr_hugepages, any existing surplus
|
||||
pages will first be promoted to persistent huge pages. Then, additional
|
||||
huge pages will be allocated, if necessary and if possible, to fulfill
|
||||
the new huge page pool size.
|
||||
the new persistent huge page pool size.
|
||||
|
||||
The administrator may shrink the pool of preallocated huge pages for
|
||||
The administrator may shrink the pool of persistent huge pages for
|
||||
the default huge page size by setting the nr_hugepages sysctl to a
|
||||
smaller value. The kernel will attempt to balance the freeing of huge pages
|
||||
across all on-line nodes. Any free huge pages on the selected nodes will
|
||||
be freed back to the buddy allocator.
|
||||
across all nodes in the memory policy of the task modifying nr_hugepages.
|
||||
Any free huge pages on the selected nodes will be freed back to the kernel's
|
||||
normal page pool.
|
||||
|
||||
Caveat: Shrinking the pool via nr_hugepages such that it becomes less
|
||||
than the number of huge pages in use will convert the balance to surplus
|
||||
huge pages even if it would exceed the overcommit value. As long as
|
||||
this condition holds, however, no more surplus huge pages will be
|
||||
allowed on the system until one of the two sysctls are increased
|
||||
sufficiently, or the surplus huge pages go out of use and are freed.
|
||||
Caveat: Shrinking the persistent huge page pool via nr_hugepages such that
|
||||
it becomes less than the number of huge pages in use will convert the balance
|
||||
of the in-use huge pages to surplus huge pages. This will occur even if
|
||||
the number of surplus pages it would exceed the overcommit value. As long as
|
||||
this condition holds--that is, until nr_hugepages+nr_overcommit_hugepages is
|
||||
increased sufficiently, or the surplus huge pages go out of use and are freed--
|
||||
no more surplus huge pages will be allowed to be allocated.
|
||||
|
||||
With support for multiple huge page pools at run-time available, much of
|
||||
the huge page userspace interface has been duplicated in sysfs. The above
|
||||
information applies to the default huge page size which will be
|
||||
controlled by the /proc interfaces for backwards compatibility. The root
|
||||
huge page control directory in sysfs is:
|
||||
the huge page userspace interface in /proc/sys/vm has been duplicated in sysfs.
|
||||
The /proc interfaces discussed above have been retained for backwards
|
||||
compatibility. The root huge page control directory in sysfs is:
|
||||
|
||||
/sys/kernel/mm/hugepages
|
||||
|
||||
For each huge page size supported by the running kernel, a subdirectory
|
||||
will exist, of the form
|
||||
will exist, of the form:
|
||||
|
||||
hugepages-${size}kB
|
||||
|
||||
Inside each of these directories, the same set of files will exist:
|
||||
|
||||
nr_hugepages
|
||||
nr_hugepages_mempolicy
|
||||
nr_overcommit_hugepages
|
||||
free_hugepages
|
||||
resv_hugepages
|
||||
|
|
@ -159,6 +163,102 @@ Inside each of these directories, the same set of files will exist:
|
|||
|
||||
which function as described above for the default huge page-sized case.
|
||||
|
||||
|
||||
Interaction of Task Memory Policy with Huge Page Allocation/Freeing
|
||||
|
||||
Whether huge pages are allocated and freed via the /proc interface or
|
||||
the /sysfs interface using the nr_hugepages_mempolicy attribute, the NUMA
|
||||
nodes from which huge pages are allocated or freed are controlled by the
|
||||
NUMA memory policy of the task that modifies the nr_hugepages_mempolicy
|
||||
sysctl or attribute. When the nr_hugepages attribute is used, mempolicy
|
||||
is ignored.
|
||||
|
||||
The recommended method to allocate or free huge pages to/from the kernel
|
||||
huge page pool, using the nr_hugepages example above, is:
|
||||
|
||||
numactl --interleave <node-list> echo 20 \
|
||||
>/proc/sys/vm/nr_hugepages_mempolicy
|
||||
|
||||
or, more succinctly:
|
||||
|
||||
numactl -m <node-list> echo 20 >/proc/sys/vm/nr_hugepages_mempolicy
|
||||
|
||||
This will allocate or free abs(20 - nr_hugepages) to or from the nodes
|
||||
specified in <node-list>, depending on whether number of persistent huge pages
|
||||
is initially less than or greater than 20, respectively. No huge pages will be
|
||||
allocated nor freed on any node not included in the specified <node-list>.
|
||||
|
||||
When adjusting the persistent hugepage count via nr_hugepages_mempolicy, any
|
||||
memory policy mode--bind, preferred, local or interleave--may be used. The
|
||||
resulting effect on persistent huge page allocation is as follows:
|
||||
|
||||
1) Regardless of mempolicy mode [see Documentation/vm/numa_memory_policy.txt],
|
||||
persistent huge pages will be distributed across the node or nodes
|
||||
specified in the mempolicy as if "interleave" had been specified.
|
||||
However, if a node in the policy does not contain sufficient contiguous
|
||||
memory for a huge page, the allocation will not "fallback" to the nearest
|
||||
neighbor node with sufficient contiguous memory. To do this would cause
|
||||
undesirable imbalance in the distribution of the huge page pool, or
|
||||
possibly, allocation of persistent huge pages on nodes not allowed by
|
||||
the task's memory policy.
|
||||
|
||||
2) One or more nodes may be specified with the bind or interleave policy.
|
||||
If more than one node is specified with the preferred policy, only the
|
||||
lowest numeric id will be used. Local policy will select the node where
|
||||
the task is running at the time the nodes_allowed mask is constructed.
|
||||
For local policy to be deterministic, the task must be bound to a cpu or
|
||||
cpus in a single node. Otherwise, the task could be migrated to some
|
||||
other node at any time after launch and the resulting node will be
|
||||
indeterminate. Thus, local policy is not very useful for this purpose.
|
||||
Any of the other mempolicy modes may be used to specify a single node.
|
||||
|
||||
3) The nodes allowed mask will be derived from any non-default task mempolicy,
|
||||
whether this policy was set explicitly by the task itself or one of its
|
||||
ancestors, such as numactl. This means that if the task is invoked from a
|
||||
shell with non-default policy, that policy will be used. One can specify a
|
||||
node list of "all" with numactl --interleave or --membind [-m] to achieve
|
||||
interleaving over all nodes in the system or cpuset.
|
||||
|
||||
4) Any task mempolicy specifed--e.g., using numactl--will be constrained by
|
||||
the resource limits of any cpuset in which the task runs. Thus, there will
|
||||
be no way for a task with non-default policy running in a cpuset with a
|
||||
subset of the system nodes to allocate huge pages outside the cpuset
|
||||
without first moving to a cpuset that contains all of the desired nodes.
|
||||
|
||||
5) Boot-time huge page allocation attempts to distribute the requested number
|
||||
of huge pages over all on-lines nodes with memory.
|
||||
|
||||
Per Node Hugepages Attributes
|
||||
|
||||
A subset of the contents of the root huge page control directory in sysfs,
|
||||
described above, will be replicated under each the system device of each
|
||||
NUMA node with memory in:
|
||||
|
||||
/sys/devices/system/node/node[0-9]*/hugepages/
|
||||
|
||||
Under this directory, the subdirectory for each supported huge page size
|
||||
contains the following attribute files:
|
||||
|
||||
nr_hugepages
|
||||
free_hugepages
|
||||
surplus_hugepages
|
||||
|
||||
The free_' and surplus_' attribute files are read-only. They return the number
|
||||
of free and surplus [overcommitted] huge pages, respectively, on the parent
|
||||
node.
|
||||
|
||||
The nr_hugepages attribute returns the total number of huge pages on the
|
||||
specified node. When this attribute is written, the number of persistent huge
|
||||
pages on the parent node will be adjusted to the specified value, if sufficient
|
||||
resources exist, regardless of the task's mempolicy or cpuset constraints.
|
||||
|
||||
Note that the number of overcommit and reserve pages remain global quantities,
|
||||
as we don't know until fault time, when the faulting task's mempolicy is
|
||||
applied, from which node the huge page allocation will be attempted.
|
||||
|
||||
|
||||
Using Huge Pages
|
||||
|
||||
If the user applications are going to request huge pages using mmap system
|
||||
call, then it is required that system administrator mount a file system of
|
||||
type hugetlbfs:
|
||||
|
|
@ -206,9 +306,11 @@ map_hugetlb.c.
|
|||
* requesting huge pages.
|
||||
*
|
||||
* For the ia64 architecture, the Linux kernel reserves Region number 4 for
|
||||
* huge pages. That means the addresses starting with 0x800000... will need
|
||||
* to be specified. Specifying a fixed address is not required on ppc64,
|
||||
* i386 or x86_64.
|
||||
* huge pages. That means that if one requires a fixed address, a huge page
|
||||
* aligned address starting with 0x800000... will be required. If a fixed
|
||||
* address is not required, the kernel will select an address in the proper
|
||||
* range.
|
||||
* Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
|
||||
*
|
||||
* Note: The default shared memory limit is quite low on many kernels,
|
||||
* you may need to increase it via:
|
||||
|
|
@ -237,14 +339,8 @@ map_hugetlb.c.
|
|||
|
||||
#define dprintf(x) printf(x)
|
||||
|
||||
/* Only ia64 requires this */
|
||||
#ifdef __ia64__
|
||||
#define ADDR (void *)(0x8000000000000000UL)
|
||||
#define SHMAT_FLAGS (SHM_RND)
|
||||
#else
|
||||
#define ADDR (void *)(0x0UL)
|
||||
#define ADDR (void *)(0x0UL) /* let kernel choose address */
|
||||
#define SHMAT_FLAGS (0)
|
||||
#endif
|
||||
|
||||
int main(void)
|
||||
{
|
||||
|
|
@ -302,10 +398,12 @@ int main(void)
|
|||
* example, the app is requesting memory of size 256MB that is backed by
|
||||
* huge pages.
|
||||
*
|
||||
* For ia64 architecture, Linux kernel reserves Region number 4 for huge pages.
|
||||
* That means the addresses starting with 0x800000... will need to be
|
||||
* specified. Specifying a fixed address is not required on ppc64, i386
|
||||
* or x86_64.
|
||||
* For the ia64 architecture, the Linux kernel reserves Region number 4 for
|
||||
* huge pages. That means that if one requires a fixed address, a huge page
|
||||
* aligned address starting with 0x800000... will be required. If a fixed
|
||||
* address is not required, the kernel will select an address in the proper
|
||||
* range.
|
||||
* Other architectures, such as ppc64, i386 or x86_64 are not so constrained.
|
||||
*/
|
||||
#include <stdlib.h>
|
||||
#include <stdio.h>
|
||||
|
|
@ -317,14 +415,8 @@ int main(void)
|
|||
#define LENGTH (256UL*1024*1024)
|
||||
#define PROTECTION (PROT_READ | PROT_WRITE)
|
||||
|
||||
/* Only ia64 requires this */
|
||||
#ifdef __ia64__
|
||||
#define ADDR (void *)(0x8000000000000000UL)
|
||||
#define FLAGS (MAP_SHARED | MAP_FIXED)
|
||||
#else
|
||||
#define ADDR (void *)(0x0UL)
|
||||
#define ADDR (void *)(0x0UL) /* let kernel choose address */
|
||||
#define FLAGS (MAP_SHARED)
|
||||
#endif
|
||||
|
||||
void check_bytes(char *addr)
|
||||
{
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче