xiaomi-sm8450/android_kernel_xiaomi_sm8450
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge tag 'v3.9-rc3' into next

Browse Source 
Merge with mainline to bring in module_platform_driver_probe() and
devm_ioremap_resource().
This commit is contained in:
Dmitry Torokhov
2013-03-17 19:40:50 -07:00
parent 1614265526 a937536b86
commit 688d794c4c
17348 changed files with 1083156 additions and 593704 deletions
Download Patch File Download Diff File Expand all files Collapse all files

1
.gitignore vendored
View File

@@ -60,7 +60,6 @@ modules.builtin
# Generated include files
#
include/config
include/linux/version.h
include/generated
arch/*/include/generated

19
CREDITS
View File

@@ -953,11 +953,11 @@ S: Blacksburg, Virginia 24061
S: USA
N: Randy Dunlap
E: rdunlap@xenotime.net
W: http://www.xenotime.net/linux/linux.html
W: http://www.linux-usb.org
E: rdunlap@infradead.org
W: http://www.infradead.org/~rdunlap/
D: Linux-USB subsystem, USB core/UHCI/printer/storage drivers
D: x86 SMP, ACPI, bootflag hacking
D: documentation, builds
S: (ask for current address)
S: USA
@@ -1572,12 +1572,12 @@ S: Wantage, New Jersey 07461
S: USA
N: Harald Hoyer
E: harald.hoyer@parzelle.de
W: http://parzelle.de/
E: harald@redhat.com
W: http://www.harald-hoyer.de
D: ip_masq_quake
D: md boot support
S: Hohe Strasse 30
S: D-70176 Stuttgart
S: Am Strand 5
S: D-19063 Schwerin
S: Germany
N: Jan Hubicka
@@ -1823,6 +1823,11 @@ S: Kattreinstr 38
S: D-64295
S: Germany
N: Avi Kivity
E: avi.kivity@gmail.com
D: Kernel-based Virtual Machine (KVM)
S: Ra'annana, Israel
N: Andi Kleen
E: andi@firstfloor.org
U: http://www.halobates.de

153
Documentation/00-INDEX
View File

@@ -2,7 +2,7 @@
This is a brief list of all the files in ./linux/Documentation and what
they contain. If you add a documentation file, please list it here in
alphabetical order as well, or risk being hunted down like a rabid dog.
Please try and keep the descriptions small enough to fit on one line.
Please keep the descriptions small enough to fit on one line.
Thanks -- Paul G.
Following translations are available on the WWW:
@@ -20,24 +20,33 @@ BUG-HUNTING
Changes
- list of changes that break older software packages.
CodingStyle
- how the boss likes the C code in the kernel to look.
development-process/
- An extended tutorial on how to work with the kernel development
process.
- how the maintainers expect the C code in the kernel to look.
DMA-API.txt
- DMA API, pci_ API & extensions for non-consistent memory machines.
DMA-API-HOWTO.txt
- Dynamic DMA mapping Guide
DMA-ISA-LPC.txt
- How to do DMA with ISA (and LPC) devices.
DMA-attributes.txt
- listing of the various possible attributes a DMA region can have
DocBook/
- directory with DocBook templates etc. for kernel documentation.
EDID/
- directory with info on customizing EDID for broken gfx/displays.
HOWTO
- the process and procedures of how to do Linux kernel development.
IPMI.txt
- info on Linux Intelligent Platform Management Interface (IPMI) Driver.
IRQ-affinity.txt
- how to select which CPU(s) handle which interrupt events on SMP.
IRQ-domain.txt
- info on inerrupt numbering and setting up IRQ domains.
IRQ.txt
- description of what an IRQ is.
Intel-IOMMU.txt
- basic info on the Intel IOMMU virtualization support.
Makefile
- some files in Documentation dir are actually sample code to build
ManagementStyle
- how to (attempt to) manage kernel hackers.
RCU/
@@ -66,10 +75,16 @@ applying-patches.txt
- description of various trees and how to apply their patches.
arm/
- directory with info about Linux on the ARM architecture.
arm64/
- directory with info about Linux on the 64 bit ARM architecture.
atomic_ops.txt
- semantics and behavior of atomic and bitmask operations.
auxdisplay/
- misc. LCD driver documentation (cfag12864b, ks0108).
backlight/
- directory with info on controlling backlights in flat panel displays
bad_memory.txt
- how to use kernel parameters to exclude bad RAM regions.
basic_profiling.txt
- basic instructions for those who wants to profile Linux kernel.
binfmt_misc.txt
@@ -80,8 +95,14 @@ block/
- info on the Block I/O (BIO) layer.
blockdev/
- info on block devices & drivers
braille-console.txt
- info on how to use serial devices for Braille support.
bt8xxgpio.txt
- info on how to modify a bt8xx video card for GPIO usage.
btmrvl.txt
- info on Marvell Bluetooth driver usage.
bus-devices/
- directory with info on TI GPMC (General Purpose Memory Controller)
bus-virt-phys-mapping.txt
- how to access I/O mapped memory from within device drivers.
cachetlb.txt
@@ -90,6 +111,12 @@ cdrom/
- directory with information on the CD-ROM drivers that Linux has.
cgroups/
- cgroups features, including cpusets and memory controller.
circular-buffers.txt
- how to make use of the existing circular buffer infrastructure
clk.txt
- info on the common clock framework
coccinelle.txt
- info on how to get and use the Coccinelle code checking tool.
connector/
- docs on the netlink based userspace<->kernel space communication mod.
console/
@@ -114,40 +141,66 @@ dcdbas.txt
- information on the Dell Systems Management Base Driver.
debugging-modules.txt
- some notes on debugging modules after Linux 2.6.3.
debugging-via-ohci1394.txt
- how to use firewire like a hardware debugger memory reader.
dell_rbu.txt
- document demonstrating the use of the Dell Remote BIOS Update driver.
development-process/
- how to work with the mainline kernel development process.
device-mapper/
- directory with info on Device Mapper.
devices.txt
- plain ASCII listing of all the nodes in /dev/ with major minor #'s.
devicetree/
- directory with info on device tree files used by OF/PowerPC/ARM
digsig.txt
-info on the Digital Signature Verification API
dma-buf-sharing.txt
- the DMA Buffer Sharing API Guide
dmaengine.txt
-the DMA Engine API Guide
dontdiff
- file containing a list of files that should never be diff'ed.
driver-model/
- directory with info about Linux driver model.
dvb/
- info on Linux Digital Video Broadcast (DVB) subsystem.
dynamic-debug-howto.txt
- how to use the dynamic debug (dyndbg) feature.
early-userspace/
- info about initramfs, klibc, and userspace early during boot.
edac.txt
- information on EDAC - Error Detection And Correction
eisa.txt
- info on EISA bus support.
email-clients.txt
- info on how to use e-mail to send un-mangled (git) patches.
extcon/
- directory with porting guide for Android kernel switch driver.
fault-injection/
- dir with docs about the fault injection capabilities infrastructure.
fb/
- directory with info on the frame buffer graphics abstraction layer.
feature-removal-schedule.txt
- list of files and features that are going to be removed.
filesystems/
- info on the vfs and the various filesystems that Linux supports.
firmware_class/
- request_firmware() hotplug interface info.
flexible-arrays.txt
- how to make use of flexible sized arrays in linux
frv/
- Fujitsu FR-V Linux documentation.
futex-requeue-pi.txt
- info on requeueing of tasks from a non-PI futex to a PI futex
gcov.txt
- use of GCC's coverage testing tool "gcov" with the Linux kernel
gpio.txt
- overview of GPIO (General Purpose Input/Output) access conventions.
hid/
- directory with information on human interface devices
highuid.txt
- notes on the change from 16 bit to 32 bit user/group IDs.
hwspinlock.txt
- hardware spinlock provides hardware assistance for synchronization
timers/
- info on the timer related topics
hw_random.txt
@@ -164,10 +217,14 @@ ia64/
- directory with info about Linux on Intel 64 bit architecture.
infiniband/
- directory with documents concerning Linux InfiniBand support.
init.txt
- what to do when the kernel can't find the 1st process to run.
initrd.txt
- how to use the RAM disk as an initial/temporary root filesystem.
input/
- info on Linux input device support.
intel_txt.txt
- info on intel Trusted Execution Technology (intel TXT).
io-mapping.txt
- description of io_mapping functions in linux/io-mapping.h
io_ordering.txt
@@ -184,6 +241,8 @@ isdn/
- directory with info on the Linux ISDN support, and supported cards.
java.txt
- info on the in-kernel binary support for Java(tm).
ja_JP/
- directory with Japanese translations of various documents
kbuild/
- directory with info about the kernel build process.
kdump/
@@ -194,6 +253,12 @@ kernel-docs.txt
- listing of various WWW + books that document kernel internals.
kernel-parameters.txt
- summary listing of command line / boot prompt args for the kernel.
kmemcheck.txt
- info on dynamic checker that detects uses of uninitialized memory.
kmemleak.txt
- info on how to make use of the kernel memory leak detection system
ko_KR/
- directory with Korean translations of various documents
kobject.txt
- info of the kobject infrastructure of the Linux kernel.
kprobes.txt
@@ -210,6 +275,8 @@ local_ops.txt
- semantics and behavior of local atomic operations.
lockdep-design.txt
- documentation on the runtime locking correctness validator.
lockstat.txt
- info on collecting statistics on locks (and contention).
lockup-watchdogs.txt
- info on soft and hard lockup detectors (aka nmi_watchdog).
logo.gif
@@ -222,16 +289,28 @@ magic-number.txt
- list of magic numbers used to mark/protect kernel data structures.
md.txt
- info on boot arguments for the multiple devices driver.
media-framework.txt
- info on media framework, its data structures, functions and usage.
memory-barriers.txt
- info on Linux kernel memory barriers.
memory-devices/
- directory with info on parts like the Texas Instruments EMIF driver
memory-hotplug.txt
- Hotpluggable memory support, how to use and current status.
memory.txt
- info on typical Linux memory problems.
metag/
- directory with info about Linux on Meta architecture.
mips/
- directory with info about Linux on MIPS architecture.
misc-devices/
- directory with info about devices using the misc dev subsystem
mmc/
- directory with info about the MMC subsystem
mn10300/
- directory with info about the mn10300 architecture port
mtd/
- directory with info about memory technology devices (flash)
mono.txt
- how to execute Mono-based .NET binaries with the help of BINFMT_MISC.
mutex-design.txt
@@ -242,6 +321,8 @@ netlabel/
- directory with information on the NetLabel subsystem.
networking/
- directory with info on various aspects of networking with Linux.
nfc/
- directory relating info about Near Field Communications support.
nommu-mmap.txt
- documentation about no-mmu memory mapping support.
numastat.txt
@@ -258,26 +339,46 @@ parport-lowlevel.txt
- description and usage of the low level parallel port functions.
pcmcia/
- info on the Linux PCMCIA driver.
percpu-rw-semaphore.txt
- RCU based read-write semaphore optimized for locking for reading
pi-futex.txt
- documentation on lightweight PI-futexes.
- documentation on lightweight priority inheritance futexes.
pinctrl.txt
- info on pinctrl subsystem and the PINMUX/PINCONF and drivers
pnp.txt
- Linux Plug and Play documentation.
power/
- directory with info on Linux PCI power management.
powerpc/
- directory with info on using Linux with the PowerPC.
prctl/
- directory with info on the priveledge control subsystem
preempt-locking.txt
- info on locking under a preemptive kernel.
printk-formats.txt
- how to get printk format specifiers right
pps/
- directory with information on the pulse-per-second support
ptp/
- directory with info on support for IEEE 1588 PTP clocks in Linux.
pwm.txt
- info on the pulse width modulation driver subsystem
ramoops.txt
- documentation of the ramoops oops/panic logging module.
rapidio/
- directory with info on RapidIO packet-based fabric interconnect
rbtree.txt
- info on what red-black trees are and what they are for.
remoteproc.txt
- info on how to handle remote processor (e.g. AMP) offloads/usage.
rfkill.txt
- info on the radio frequency kill switch subsystem/support.
robust-futex-ABI.txt
- documentation of the robust futex ABI.
robust-futexes.txt
- a description of what robust futexes are.
rpmsg.txt
- info on the Remote Processor Messaging (rpmsg) Framework
rt-mutex-design.txt
- description of the RealTime mutex implementation design.
rt-mutex.txt
@@ -302,10 +403,10 @@ sgi-visws.txt
- short blurb on the SGI Visual Workstations.
sh/
- directory with info on porting Linux to a new architecture.
smsc_ece1099.txt
-info on the smsc Keyboard Scan Expansion/GPIO Expansion device.
sound/
- directory with info on sound card support.
sparc/
- directory with info on using Linux on Sparc architecture.
sparse.txt
- info on how to obtain and use the sparse tool for typechecking.
spi/
@@ -316,6 +417,8 @@ stable_api_nonsense.txt
- info on why the kernel does not have a stable in-kernel api or abi.
stable_kernel_rules.txt
- rules and procedures for the -stable kernel releases.
static-keys.txt
- info on how static keys allow debug code in hotpaths via patching
svga.txt
- short guide on selecting video modes at boot via VGA BIOS.
sysfs-rules.txt
@@ -324,27 +427,53 @@ sysctl/
- directory with info on the /proc/sys/* files.
sysrq.txt
- info on the magic SysRq key.
telephony/
- directory with info on telephony (e.g. voice over IP) support.
target/
- directory with info on generating TCM v4 fabric .ko modules
thermal/
- directory with information on managing thermal issues (CPU/temp)
trace/
- directory with info on tracing technologies within linux
unaligned-memory-access.txt
- info on how to avoid arch breaking unaligned memory access in code.
unicode.txt
- info on the Unicode character/font mapping used in Linux.
unshare.txt
- description of the Linux unshare system call.
usb/
- directory with info regarding the Universal Serial Bus.
vDSO/
- directory with info regarding virtual dynamic shared objects
vfio.txt
- info on Virtual Function I/O used in guest/hypervisor instances.
vgaarbiter.txt
- info on enable/disable the legacy decoding on different VGA devices
video-output.txt
- sysfs class driver interface to enable/disable a video output device.
video4linux/
- directory with info regarding video/TV/radio cards and linux.
virtual/
- directory with information on the various linux virtualizations.
vm/
- directory with info on the Linux vm code.
vme_api.txt
- file relating info on the VME bus API in linux
volatile-considered-harmful.txt
- Why the "volatile" type class should not be used
w1/
- directory with documents regarding the 1-wire (w1) subsystem.
watchdog/
- how to auto-reboot Linux if it has "fallen and can't get up". ;-)
wimax/
- directory with info about Intel Wireless Wimax Connections
workqueue.txt
- information on the Concurrency Managed Workqueue implementation
x86/x86_64/
- directory with info on Linux support for AMD x86-64 (Hammer) machines.
xtensa/
- directory with documents relating to arch/xtensa port/implementation
xz.txt
- how to make use of the XZ data compression within linux kernel
zh_CN/
- directory with Chinese translations of various documents
zorro.txt
- info on writing drivers for Zorro bus devices found on Amigas.

3
Documentation/ABI/README
View File

@@ -36,9 +36,6 @@ The different levels of stability are:
the kernel, but are marked to be removed at some later point in
time. The description of the interface will document the reason
why it is obsolete and when it can be expected to be removed.
The file Documentation/feature-removal-schedule.txt may describe
some of these interfaces, giving a schedule for when they will
be removed.
removed/
This directory contains a list of the old interfaces that have

38
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-koneplus
View File

@@ -8,3 +8,41 @@ Description: The integer value of this attribute ranges from 0-4.
When written, this file sets the number of the startup profile
and the mouse activates this profile immediately.
Please use actual_profile, it does the same thing.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
This file is readonly.
Please read binary attribute info which contains firmware version.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 77 bytes in size.
This file is readonly.
Write control to select profile and read profile_buttons instead.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 43 bytes in size.
This file is readonly.
Write control to select profile and read profile_settings instead.
Users: http://roccat.sourceforge.net

66
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus Normal file
View File

@@ -0,0 +1,66 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-4.
When read, this attribute returns the number of the active
cpi level.
This file is readonly.
Has never been used. If bookkeeping is done, it's done in userland tools.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in x direction.
This file is readonly.
Has never been used. If bookkeeping is done, it's done in userland tools.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in y direction.
This file is readonly.
Has never been used. If bookkeeping is done, it's done in userland tools.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
This file is readonly.
Obsoleted by binary sysfs attribute "info".
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 23 bytes in size.
This file is readonly.
Write control to select profile and read profile_buttons instead.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 16 bytes in size.
This file is readonly.
Write control to select profile and read profile_settings instead.
Users: http://roccat.sourceforge.net

73
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra Normal file
View File

@@ -0,0 +1,73 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: It is possible to switch the cpi setting of the mouse with the
press of a button.
When read, this file returns the raw number of the actual cpi
setting reported by the mouse. This number has to be further
processed to receive the real dpi value.
VALUE DPI
1 400
2 800
4 1600
This file is readonly.
Has never been used. If bookkeeping is done, it's done in userland tools.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
This file is readonly.
Please use binary attribute "settings" which provides this information.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
This file is readonly.
Please use binary attribute "info" which provides this information.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.
Write control to select profile and read profile_buttons instead.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
This file is readonly.
Write control to select profile and read profile_settings instead.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
This file is readonly.
Please use binary attribute "settings" which provides this information.
Users: http://roccat.sourceforge.net

185
Documentation/ABI/stable/sysfs-class-tpm Normal file
View File

@@ -0,0 +1,185 @@
What: /sys/class/misc/tpmX/device/
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The device/ directory under a specific TPM instance exposes
the properties of that TPM chip
What: /sys/class/misc/tpmX/device/active
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "active" property prints a '1' if the TPM chip is accepting
commands. An inactive TPM chip still contains all the state of
an active chip (Storage Root Key, NVRAM, etc), and can be
visible to the OS, but will only accept a restricted set of
commands. See the TPM Main Specification part 2, Structures,
section 17 for more information on which commands are
available.
What: /sys/class/misc/tpmX/device/cancel
Date: June 2005
KernelVersion: 2.6.13
Contact: tpmdd-devel@lists.sf.net
Description: The "cancel" property allows you to cancel the currently
pending TPM command. Writing any value to cancel will call the
TPM vendor specific cancel operation.
What: /sys/class/misc/tpmX/device/caps
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "caps" property contains TPM manufacturer and version info.
Example output:
Manufacturer: 0x53544d20
TCG version: 1.2
Firmware version: 8.16
Manufacturer is a hex dump of the 4 byte manufacturer info
space in a TPM. TCG version shows the TCG TPM spec level that
the chip supports. Firmware version is that of the chip and
is manufacturer specific.
What: /sys/class/misc/tpmX/device/durations
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net
Description: The "durations" property shows the 3 vendor-specific values
used to wait for a short, medium and long TPM command. All
TPM commands are categorized as short, medium or long in
execution time, so that the driver doesn't have to wait
any longer than necessary before starting to poll for a
result.
Example output:
3015000 4508000 180995000 [original]
Here the short, medium and long durations are displayed in
usecs. "[original]" indicates that the values are displayed
unmodified from when they were queried from the chip.
Durations can be modified in the case where a buggy chip
reports them in msec instead of usec and they need to be
scaled to be displayed in usecs. In this case "[adjusted]"
will be displayed in place of "[original]".
What: /sys/class/misc/tpmX/device/enabled
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "enabled" property prints a '1' if the TPM chip is enabled,
meaning that it should be visible to the OS. This property
may be visible but produce a '0' after some operation that
disables the TPM.
What: /sys/class/misc/tpmX/device/owned
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "owned" property produces a '1' if the TPM_TakeOwnership
ordinal has been executed successfully in the chip. A '0'
indicates that ownership hasn't been taken.
What: /sys/class/misc/tpmX/device/pcrs
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "pcrs" property will dump the current value of all Platform
Configuration Registers in the TPM. Note that since these
values may be constantly changing, the output is only valid
for a snapshot in time.
Example output:
PCR-00: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-01: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-02: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-03: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
PCR-04: 3A 3F 78 0F 11 A4 B4 99 69 FC AA 80 CD 6E 39 57 C3 3B 22 75
...
The number of PCRs and hex bytes needed to represent a PCR
value will vary depending on TPM chip version. For TPM 1.1 and
1.2 chips, PCRs represent SHA-1 hashes, which are 20 bytes
long. Use the "caps" property to determine TPM version.
What: /sys/class/misc/tpmX/device/pubek
Date: April 2005
KernelVersion: 2.6.12
Contact: tpmdd-devel@lists.sf.net
Description: The "pubek" property will return the TPM's public endorsement
key if possible. If the TPM has had ownership established and
is version 1.2, the pubek will not be available without the
owner's authorization. Since the TPM driver doesn't store any
secrets, it can't authorize its own request for the pubek,
making it unaccessible. The public endorsement key is gener-
ated at TPM menufacture time and exists for the life of the
chip.
Example output:
Algorithm: 00 00 00 01
Encscheme: 00 03
Sigscheme: 00 01
Parameters: 00 00 08 00 00 00 00 02 00 00 00 00
Modulus length: 256
Modulus:
B4 76 41 82 C9 20 2C 10 18 40 BC 8B E5 44 4C 6C
3A B2 92 0C A4 9B 2A 83 EB 5C 12 85 04 48 A0 B6
1E E4 81 84 CE B2 F2 45 1C F0 85 99 61 02 4D EB
86 C4 F7 F3 29 60 52 93 6B B2 E5 AB 8B A9 09 E3
D7 0E 7D CA 41 BF 43 07 65 86 3C 8C 13 7A D0 8B
82 5E 96 0B F8 1F 5F 34 06 DA A2 52 C1 A9 D5 26
0F F4 04 4B D9 3F 2D F2 AC 2F 74 64 1F 8B CD 3E
1E 30 38 6C 70 63 69 AB E2 50 DF 49 05 2E E1 8D
6F 78 44 DA 57 43 69 EE 76 6C 38 8A E9 8E A3 F0
A7 1F 3C A8 D0 12 15 3E CA 0E BD FA 24 CD 33 C6
47 AE A4 18 83 8E 22 39 75 93 86 E6 FD 66 48 B6
10 AD 94 14 65 F9 6A 17 78 BD 16 53 84 30 BF 70
E0 DC 65 FD 3C C6 B0 1E BF B9 C1 B5 6C EF B1 3A
F8 28 05 83 62 26 11 DC B4 6B 5A 97 FF 32 26 B6
F7 02 71 CF 15 AE 16 DD D1 C1 8E A8 CF 9B 50 7B
C3 91 FF 44 1E CF 7C 39 FE 17 77 21 20 BD CE 9B
Possible values:
Algorithm: TPM_ALG_RSA (1)
Encscheme: TPM_ES_RSAESPKCSv15 (2)
TPM_ES_RSAESOAEP_SHA1_MGF1 (3)
Sigscheme: TPM_SS_NONE (1)
Parameters, a byte string of 3 u32 values:
Key Length (bits): 00 00 08 00 (2048)
Num primes: 00 00 00 02 (2)
Exponent Size: 00 00 00 00 (0 means the
default exp)
Modulus Length: 256 (bytes)
Modulus: The 256 byte Endorsement Key modulus
What: /sys/class/misc/tpmX/device/temp_deactivated
Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "temp_deactivated" property returns a '1' if the chip has
been temporarily dectivated, usually until the next power
cycle. Whether a warm boot (reboot) will clear a TPM chip
from a temp_deactivated state is platform specific.
What: /sys/class/misc/tpmX/device/timeouts
Date: March 2011
KernelVersion: 3.1
Contact: tpmdd-devel@lists.sf.net
Description: The "timeouts" property shows the 4 vendor-specific values
for the TPM's interface spec timeouts. The use of these
timeouts is defined by the TPM interface spec that the chip
conforms to.
Example output:
750000 750000 750000 750000 [original]
The four timeout values are shown in usecs, with a trailing
"[original]" or "[adjusted]" depending on whether the values
were scaled by the driver to be reported in usec from msecs.

96
Documentation/ABI/stable/sysfs-devices-node
View File

@@ -1,7 +1,101 @@
What: /sys/devices/system/node/possible
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that could be possibly become online at some point.
What: /sys/devices/system/node/online
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that are online.
What: /sys/devices/system/node/has_normal_memory
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have regular memory.
What: /sys/devices/system/node/has_cpu
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have one or more CPUs.
What: /sys/devices/system/node/has_high_memory
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Nodes that have regular or high memory.
Depends on CONFIG_HIGHMEM.
What: /sys/devices/system/node/nodeX
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
When CONFIG_NUMA is enabled, this is a directory containing
information on node X such as what CPUs are local to the
node.
node. Each file is detailed next.
What: /sys/devices/system/node/nodeX/cpumap
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's cpumap.
What: /sys/devices/system/node/nodeX/cpulist
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The CPUs associated to the node.
What: /sys/devices/system/node/nodeX/meminfo
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Provides information about the node's distribution and memory
utilization. Similar to /proc/meminfo, see Documentation/filesystems/proc.txt
What: /sys/devices/system/node/nodeX/numastat
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's hit/miss statistics, in units of pages.
See Documentation/numastat.txt
What: /sys/devices/system/node/nodeX/distance
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
Distance between the node and all the other nodes
in the system.
What: /sys/devices/system/node/nodeX/vmstat
Date: October 2002
Contact: Linux Memory Management list <linux-mm@kvack.org>
Description:
The node's zoned virtual memory statistics.
This is a superset of numastat.
What: /sys/devices/system/node/nodeX/compact
Date: February 2010
Contact: Mel Gorman <mel@csn.ul.ie>
Description:
When this file is written to, all memory within that node
will be compacted. When it completes, memory will be freed
into blocks which have as many contiguous pages as possible
What: /sys/devices/system/node/nodeX/scan_unevictable_pages
Date: October 2008
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
Description:
When set, it triggers scanning the node's unevictable lists
and move any pages that have become evictable onto the respective
zone's inactive list. See mm/vmscan.c
What: /sys/devices/system/node/nodeX/hugepages/hugepages-<size>/
Date: December 2009
Contact: Lee Schermerhorn <lee.schermerhorn@hp.com>
Description:
The node's huge page size control/query attributes.
See Documentation/vm/hugetlbpage.txt

156
Documentation/ABI/stable/sysfs-driver-ib_srp Normal file
View File

@@ -0,0 +1,156 @@
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/add_target
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: Interface for making ib_srp connect to a new target.
One can request ib_srp to connect to a new target by writing
a comma-separated list of login parameters to this sysfs
attribute. The supported parameters are:
* id_ext, a 16-digit hexadecimal number specifying the eight
byte identifier extension in the 16-byte SRP target port
identifier. The target port identifier is sent by ib_srp
to the target in the SRP_LOGIN_REQ request.
* ioc_guid, a 16-digit hexadecimal number specifying the eight
byte I/O controller GUID portion of the 16-byte target port
identifier.
* dgid, a 32-digit hexadecimal number specifying the
destination GID.
* pkey, a four-digit hexadecimal number specifying the
InfiniBand partition key.
* service_id, a 16-digit hexadecimal number specifying the
InfiniBand service ID used to establish communication with
the SRP target. How to find out the value of the service ID
is specified in the documentation of the SRP target.
* max_sect, a decimal number specifying the maximum number of
512-byte sectors to be transferred via a single SCSI command.
* max_cmd_per_lun, a decimal number specifying the maximum
number of outstanding commands for a single LUN.
* io_class, a hexadecimal number specifying the SRP I/O class.
Must be either 0xff00 (rev 10) or 0x0100 (rev 16a). The I/O
class defines the format of the SRP initiator and target
port identifiers.
* initiator_ext, a 16-digit hexadecimal number specifying the
identifier extension portion of the SRP initiator port
identifier. This data is sent by the initiator to the target
in the SRP_LOGIN_REQ request.
* cmd_sg_entries, a number in the range 1..255 that specifies
the maximum number of data buffer descriptors stored in the
SRP_CMD information unit itself. With allow_ext_sg=0 the
parameter cmd_sg_entries defines the maximum S/G list length
for a single SRP_CMD, and commands whose S/G list length
exceeds this limit after S/G list collapsing will fail.
* allow_ext_sg, whether ib_srp is allowed to include a partial
memory descriptor list in an SRP_CMD instead of the entire
list. If a partial memory descriptor list has been included
in an SRP_CMD the remaining memory descriptors are
communicated from initiator to target via an additional RDMA
transfer. Setting allow_ext_sg to 1 increases the maximum
amount of data that can be transferred between initiator and
target via a single SCSI command. Since not all SRP target
implementations support partial memory descriptor lists the
default value for this option is 0.
* sg_tablesize, a number in the range 1..2048 specifying the
maximum S/G list length the SCSI layer is allowed to pass to
ib_srp. Specifying a value that exceeds cmd_sg_entries is
only safe with partial memory descriptor list support enabled
(allow_ext_sg=1).
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/ibdev
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: HCA name (<hca>).
What: /sys/class/infiniband_srp/srp-<hca>-<port_number>/port
Date: January 2, 2006
KernelVersion: 2.6.15
Contact: linux-rdma@vger.kernel.org
Description: HCA port number (<port_number>).
What: /sys/class/scsi_host/host<n>/allow_ext_sg
Date: May 19, 2011
KernelVersion: 2.6.39
Contact: linux-rdma@vger.kernel.org
Description: Whether ib_srp is allowed to include a partial memory
descriptor list in an SRP_CMD when communicating with an SRP
target.
What: /sys/class/scsi_host/host<n>/cmd_sg_entries
Date: May 19, 2011
KernelVersion: 2.6.39
Contact: linux-rdma@vger.kernel.org
Description: Maximum number of data buffer descriptors that may be sent to
the target in a single SRP_CMD request.
What: /sys/class/scsi_host/host<n>/dgid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand destination GID used for communication with the SRP
target. Differs from orig_dgid if port redirection has happened.
What: /sys/class/scsi_host/host<n>/id_ext
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: Eight-byte identifier extension portion of the 16-byte target
port identifier.
What: /sys/class/scsi_host/host<n>/ioc_guid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: Eight-byte I/O controller GUID portion of the 16-byte target
port identifier.
What: /sys/class/scsi_host/host<n>/local_ib_device
Date: November 29, 2006
KernelVersion: 2.6.19
Contact: linux-rdma@vger.kernel.org
Description: Name of the InfiniBand HCA used for communicating with the
SRP target.
What: /sys/class/scsi_host/host<n>/local_ib_port
Date: November 29, 2006
KernelVersion: 2.6.19
Contact: linux-rdma@vger.kernel.org
Description: Number of the HCA port used for communicating with the
SRP target.
What: /sys/class/scsi_host/host<n>/orig_dgid
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand destination GID specified in the parameters
written to the add_target sysfs attribute.
What: /sys/class/scsi_host/host<n>/pkey
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: A 16-bit number representing the InfiniBand partition key used
for communication with the SRP target.
What: /sys/class/scsi_host/host<n>/req_lim
Date: October 20, 2010
KernelVersion: 2.6.36
Contact: linux-rdma@vger.kernel.org
Description: Number of requests ib_srp can send to the target before it has
to wait for more credits. For more information see also the
SRP credit algorithm in the SRP specification.
What: /sys/class/scsi_host/host<n>/service_id
Date: June 17, 2006
KernelVersion: 2.6.17
Contact: linux-rdma@vger.kernel.org
Description: InfiniBand service ID used for establishing communication with
the SRP target.
What: /sys/class/scsi_host/host<n>/zero_req_lim
Date: September 20, 2006
KernelVersion: 2.6.18
Contact: linux-rdma@vger.kernel.org
Description: Number of times the initiator had to wait before sending a
request to the target because it ran out of credits. For more
information see also the SRP credit algorithm in the SRP
specification.

19
Documentation/ABI/stable/sysfs-transport-srp Normal file
View File

@@ -0,0 +1,19 @@
What: /sys/class/srp_remote_ports/port-<h>:<n>/delete
Date: June 1, 2012
KernelVersion: 3.7
Contact: linux-scsi@vger.kernel.org, linux-rdma@vger.kernel.org
Description: Instructs an SRP initiator to disconnect from a target and to
remove all LUNs imported from that target.
What: /sys/class/srp_remote_ports/port-<h>:<n>/port_id
Date: June 27, 2007
KernelVersion: 2.6.24
Contact: linux-scsi@vger.kernel.org
Description: 16-byte local SRP port identifier in hexadecimal format. An
example: 4c:49:4e:55:58:20:56:49:4f:00:00:00:00:00:00:00.
What: /sys/class/srp_remote_ports/port-<h>:<n>/roles
Date: June 27, 2007
KernelVersion: 2.6.24
Contact: linux-scsi@vger.kernel.org
Description: Role of the remote port. Either "SRP Initiator" or "SRP Target".

2
Documentation/ABI/testing/dev-kmsg
View File

@@ -92,7 +92,7 @@ Description: The /dev/kmsg character device node provides userspace access
The flags field carries '-' by default. A 'c' indicates a
fragment of a line. All following fragments are flagged with
'+'. Note, that these hints about continuation lines are not
neccessarily correct, and the stream could be interleaved with
necessarily correct, and the stream could be interleaved with
unrelated messages, but merging the lines in the output
usually produces better human readable results. A similar
logic is used internally when messages are printed to the

11
Documentation/ABI/testing/ima_policy
View File

@@ -18,17 +18,21 @@ Description:
rule format: action [condition ...]
action: measure | dont_measure | appraise | dont_appraise | audit
condition:= base | lsm
base: [[func=] [mask=] [fsmagic=] [uid=] [fowner]]
condition:= base | lsm [option]
base: [[func=] [mask=] [fsmagic=] [fsuuid=] [uid=]
[fowner]]
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
option: [[appraise_type=]]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]
base: func:= [BPRM_CHECK][MMAP_CHECK][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
fsuuid:= file system UUID (e.g 8bcbe394-4f13-4144-be8e-5aa9ea2ce2f6)
uid:= decimal value
fowner:=decimal value
lsm: are LSM specific
option: appraise_type:= [imasig]
default policy:
# PROC_SUPER_MAGIC
@@ -53,6 +57,7 @@ Description:
measure func=BPRM_CHECK
measure func=FILE_MMAP mask=MAY_EXEC
measure func=FILE_CHECK mask=MAY_READ uid=0
measure func=MODULE_CHECK uid=0
appraise fowner=0
The default policy measures all executables in bprm_check,

10
Documentation/ABI/testing/pstore
View File

@@ -1,4 +1,4 @@
Where: /dev/pstore/...
Where: /sys/fs/pstore/... (or /dev/pstore/...)
Date: March 2011
Kernel Version: 2.6.39
Contact: tony.luck@intel.com
@@ -11,9 +11,9 @@ Description: Generic interface to platform dependent persistent storage.
of the console log is captured, but other interesting
data can also be saved.
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
# mount -t pstore -o kmsg_bytes=8000 - /sys/fs/pstore
$ ls -l /dev/pstore
$ ls -l /sys/fs/pstore/
total 0
-r--r--r-- 1 root root 7896 Nov 30 15:38 dmesg-erst-1
@@ -27,9 +27,9 @@ Description: Generic interface to platform dependent persistent storage.
the file will signal to the underlying persistent storage
device that it can reclaim the space for later re-use.
$ rm /dev/pstore/dmesg-erst-1
$ rm /sys/fs/pstore/dmesg-erst-1
The expectation is that all files in /dev/pstore
The expectation is that all files in /sys/fs/pstore/
will be saved elsewhere and erased from persistent store
soon after boot to free up space ready for the next
catastrophe.

62
Documentation/ABI/testing/sysfs-bus-event_source-devices-events Normal file
View File

@@ -0,0 +1,62 @@
What: /sys/devices/cpu/events/
/sys/devices/cpu/events/branch-misses
/sys/devices/cpu/events/cache-references
/sys/devices/cpu/events/cache-misses
/sys/devices/cpu/events/stalled-cycles-frontend
/sys/devices/cpu/events/branch-instructions
/sys/devices/cpu/events/stalled-cycles-backend
/sys/devices/cpu/events/instructions
/sys/devices/cpu/events/cpu-cycles
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Description: Generic performance monitoring events
A collection of performance monitoring events that may be
supported by many/most CPUs. These events can be monitored
using the 'perf(1)' tool.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
What: /sys/devices/cpu/events/PM_LD_MISS_L1
/sys/devices/cpu/events/PM_LD_REF_L1
/sys/devices/cpu/events/PM_CYC
/sys/devices/cpu/events/PM_BRU_FIN
/sys/devices/cpu/events/PM_GCT_NOSLOT_CYC
/sys/devices/cpu/events/PM_BRU_MPRED
/sys/devices/cpu/events/PM_INST_CMPL
/sys/devices/cpu/events/PM_CMPLU_STALL
Date: 2013/01/08
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux Powerpc mailing list <linuxppc-dev@ozlabs.org>
Description: POWER-systems specific performance monitoring events
A collection of performance monitoring events that may be
supported by the POWER CPU. These events can be monitored
using the 'perf(1)' tool.
These events may not be supported by other CPUs.
The contents of each file would look like:
event=0xNNNN
where 'N' is a hex digit and the number '0xNNNN' shows the
"raw code" for the perf event identified by the file's
"basename".
Further, multiple terms like 'event=0xNNNN' can be specified
and separated with comma. All available terms are defined in
the /sys/bus/event_source/devices/<dev>/format file.

45
Documentation/ABI/testing/sysfs-bus-fcoe
View File

@@ -1,14 +1,53 @@
What: /sys/bus/fcoe/ctlr_X
What: /sys/bus/fcoe/
Date: August 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: The FCoE bus. Attributes in this directory are control interfaces.
Attributes:
ctlr_create: 'FCoE Controller' instance creation interface. Writing an
<ifname> to this file will allocate and populate sysfs with a
fcoe_ctlr_device (ctlr_X). The user can then configure any
per-port settings and finally write to the fcoe_ctlr_device's
'start' attribute to begin the kernel's discovery and login
process.
ctlr_destroy: 'FCoE Controller' instance removal interface. Writing a
fcoe_ctlr_device's sysfs name to this file will log the
fcoe_ctlr_device out of the fabric or otherwise connected
FCoE devices. It will also free all kernel memory allocated
for this fcoe_ctlr_device and any structures associated
with it, this includes the scsi_host.
What: /sys/bus/fcoe/devices/ctlr_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org
Description: 'FCoE Controller' instances on the fcoe bus
Description: 'FCoE Controller' instances on the fcoe bus.
The FCoE Controller now has a three stage creation process.
1) Write interface name to ctlr_create 2) Configure the FCoE
Controller (ctlr_X) 3) Enable the FCoE Controller to begin
discovery and login. The FCoE Controller is destroyed by
writing it's name, i.e. ctlr_X to the ctlr_delete file.
Attributes:
fcf_dev_loss_tmo: Device loss timeout peroid (see below). Changing
this value will change the dev_loss_tmo for all
FCFs discovered by this controller.
mode: Display or change the FCoE Controller's mode. Possible
modes are 'Fabric' and 'VN2VN'. If a FCoE Controller
is started in 'Fabric' mode then FIP FCF discovery is
initiated and ultimately a fabric login is attempted.
If a FCoE Controller is started in 'VN2VN' mode then
FIP VN2VN discovery and login is performed. A FCoE
Controller only supports one mode at a time.
enabled: Whether an FCoE controller is enabled or disabled.
0 if disabled, 1 if enabled. Writing either 0 or 1
to this file will enable or disable the FCoE controller.
lesb/link_fail: Link Error Status Block (LESB) link failure count.
lesb/vlink_fail: Link Error Status Block (LESB) virtual link
@@ -26,7 +65,7 @@ Attributes:
Notes: ctlr_X (global increment starting at 0)
What: /sys/bus/fcoe/fcf_X
What: /sys/bus/fcoe/devices/fcf_X
Date: March 2012
KernelVersion: TBD
Contact: Robert Love <robert.w.love@intel.com>, devel@open-fcoe.org

24
Documentation/ABI/testing/sysfs-bus-iio
View File

@@ -189,6 +189,14 @@ Description:
A computed peak value based on the sum squared magnitude of
the underlying value in the specified directions.
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_raw
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_raw
KernelVersion: 3.8
Contact: linux-iio@vger.kernel.org
Description:
Raw pressure measurement from channel Y. Units after
application of scale and offset are kilopascal.
What: /sys/bus/iio/devices/iio:deviceX/in_accel_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_offset
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_offset
@@ -197,6 +205,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_voltage_offset
What: /sys/bus/iio/devices/iio:deviceX/in_tempY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_temp_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_offset
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_offset
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -226,6 +236,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_magn_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_x_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_y_scale
What: /sys/bus/iio/devices/iio:deviceX/in_magn_z_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_scale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_scale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -245,6 +257,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibbias
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -262,6 +276,8 @@ What /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibscale
What /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibscale
what /sys/bus/iio/devices/iio:deviceX/in_illuminance0_calibscale
what /sys/bus/iio/devices/iio:deviceX/in_proximity0_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_pressureY_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_pressure_calibscale
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -275,6 +291,8 @@ What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
What: /sys/.../iio:deviceX/out_voltageX_scale_available
What: /sys/.../iio:deviceX/out_altvoltageX_scale_available
What: /sys/.../iio:deviceX/in_capacitance_scale_available
What: /sys/.../iio:deviceX/in_pressure_scale_available
What: /sys/.../iio:deviceX/in_pressureY_scale_available
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
@@ -694,6 +712,8 @@ What: /sys/.../buffer/scan_elements/in_voltageY_en
What: /sys/.../buffer/scan_elements/in_voltageY-voltageZ_en
What: /sys/.../buffer/scan_elements/in_incli_x_en
What: /sys/.../buffer/scan_elements/in_incli_y_en
What: /sys/.../buffer/scan_elements/in_pressureY_en
What: /sys/.../buffer/scan_elements/in_pressure_en
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -707,6 +727,8 @@ What: /sys/.../buffer/scan_elements/in_voltageY_type
What: /sys/.../buffer/scan_elements/in_voltage_type
What: /sys/.../buffer/scan_elements/in_voltageY_supply_type
What: /sys/.../buffer/scan_elements/in_timestamp_type
What: /sys/.../buffer/scan_elements/in_pressureY_type
What: /sys/.../buffer/scan_elements/in_pressure_type
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
@@ -751,6 +773,8 @@ What: /sys/.../buffer/scan_elements/in_magn_z_index
What: /sys/.../buffer/scan_elements/in_incli_x_index
What: /sys/.../buffer/scan_elements/in_incli_y_index
What: /sys/.../buffer/scan_elements/in_timestamp_index
What: /sys/.../buffer/scan_elements/in_pressureY_index
What: /sys/.../buffer/scan_elements/in_pressure_index
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:

13
Documentation/ABI/testing/sysfs-bus-iio-mpu6050 Normal file
View File

@@ -0,0 +1,13 @@
What: /sys/bus/iio/devices/iio:deviceX/in_gyro_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_accel_matrix
What: /sys/bus/iio/devices/iio:deviceX/in_magn_matrix
KernelVersion: 3.4.0
Contact: linux-iio@vger.kernel.org
Description:
This is mounting matrix for motion sensors. Mounting matrix
is a 3x3 unitary matrix. A typical mounting matrix would look like
[0, 1, 0; 1, 0, 0; 0, 0, -1]. Using this information, it would be
easy to tell the relative positions among sensors as well as their
positions relative to the board that holds these sensors. Identity matrix
[1, 0, 0; 0, 1, 0; 0, 0, 1] means sensor chip and device are perfectly
aligned with each other. All axes are exactly the same.

9
Documentation/ABI/testing/sysfs-bus-mdio Normal file
View File

@@ -0,0 +1,9 @@
What: /sys/bus/mdio_bus/devices/.../phy_id
Date: November 2012
KernelVersion: 3.8
Contact: netdev@vger.kernel.org
Description:
This attribute contains the 32-bit PHY Identifier as reported
by the device during bus enumeration, encoded in hexadecimal.
This ID is used to match the device with the appropriate
driver.

34
Documentation/ABI/testing/sysfs-bus-pci
View File

@@ -222,3 +222,37 @@ Description:
satisfied too. Reading this attribute will show the current
value of d3cold_allowed bit. Writing this attribute will set
the value of d3cold_allowed bit.
What: /sys/bus/pci/devices/.../sriov_totalvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read this file to determine the
maximum number of Virtual Functions (VFs) a PCIe physical
function (PF) can support. Typically, this is the value reported
in the PF's SR-IOV extended capability structure's TotalVFs
element. Drivers have the ability at probe time to reduce the
value read from this file via the pci_sriov_set_totalvfs()
function.
What: /sys/bus/pci/devices/.../sriov_numvfs
Date: November 2012
Contact: Donald Dutile <ddutile@redhat.com>
Description:
This file appears when a physical PCIe device supports SR-IOV.
Userspace applications can read and write to this file to
determine and control the enablement or disablement of Virtual
Functions (VFs) on the physical function (PF). A read of this
file will return the number of VFs that are enabled on this PF.
A number written to this file will enable the specified
number of VFs. A userspace application would typically read the
file and check that the value is zero, and then write the number
of VFs that should be enabled on the PF; the value written
should be less than or equal to the value in the sriov_totalvfs
file. A userspace application wanting to disable the VFs would
write a zero to this file. The core ensures that valid values
are written to this file, and returns errors when values are not
valid. For example, writing a 2 to this file when sriov_numvfs
is not 0 and not 2 already will return an error. Writing a 10
when the value of sriov_totalvfs is 8 will return an error.

4
Documentation/ABI/testing/sysfs-bus-rbd
View File

@@ -70,6 +70,10 @@ snap_*
A directory per each snapshot
parent
Information identifying the pool, image, and snapshot id for
the parent image in a layered rbd image (format 2 only).
Entries under /sys/bus/rbd/devices/<dev-id>/snap_<snap-name>
-------------------------------------------------------------

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

@@ -227,3 +227,12 @@ Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
The /sys/bus/usb/devices/.../(hub interface)/portX
is usb port device's sysfs directory.
What: /sys/bus/usb/devices/.../(hub interface)/portX/connect_type
Date: January 2013
Contact: Lan Tianyu <tianyu.lan@intel.com>
Description:
Some platforms provide usb port connect types through ACPI.
This attribute is to expose these information to user space.
The file will read "hotplug", "wired" and "not used" if the
information is available, and "unknown" otherwise.

5
Documentation/ABI/testing/sysfs-class-bdi
View File

@@ -48,3 +48,8 @@ max_ratio (read-write)
most of the write-back cache. For example in case of an NFS
mount that is prone to get stuck, or a FUSE mount which cannot
be trusted to play fair.
stable_pages_required (read-only)
If set, the backing device requires that all pages comprising a write
request must not be changed until writeout is complete.

44
Documentation/ABI/testing/sysfs-class-devfreq
View File

@@ -11,7 +11,7 @@ What: /sys/class/devfreq/.../governor
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../governor shows the name of the
The /sys/class/devfreq/.../governor show or set the name of the
governor used by the corresponding devfreq object.
What: /sys/class/devfreq/.../cur_freq
@@ -19,15 +19,16 @@ Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Description:
The /sys/class/devfreq/.../cur_freq shows the current
frequency of the corresponding devfreq object.
frequency of the corresponding devfreq object. Same as
target_freq when get_cur_freq() is not implemented by
devfreq driver.
What: /sys/class/devfreq/.../central_polling
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
What: /sys/class/devfreq/.../target_freq
Date: September 2012
Contact: Rajagopal Venkat <rajagopal.venkat@linaro.org>
Description:
The /sys/class/devfreq/.../central_polling shows whether
the devfreq ojbect is using devfreq-provided central
polling mechanism or not.
The /sys/class/devfreq/.../target_freq shows the next governor
predicted target frequency of the corresponding devfreq object.
What: /sys/class/devfreq/.../polling_interval
Date: September 2011
@@ -43,6 +44,17 @@ Description:
(/sys/class/devfreq/.../central_polling is 0), this value
may be useless.
What: /sys/class/devfreq/.../trans_stat
Date: October 2012
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
Descrtiption:
This ABI shows the statistics of devfreq behavior on a
specific device. It shows the time spent in each state and
the number of transitions between states.
In order to activate this ABI, the devfreq target device
driver should provide the list of available frequencies
with its profile.
What: /sys/class/devfreq/.../userspace/set_freq
Date: September 2011
Contact: MyungJoo Ham <myungjoo.ham@samsung.com>
@@ -50,3 +62,19 @@ Description:
The /sys/class/devfreq/.../userspace/set_freq shows and
sets the requested frequency for the devfreq object if
userspace governor is in effect.
What: /sys/class/devfreq/.../available_frequencies
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_frequencies shows
the available frequencies of the corresponding devfreq object.
This is a snapshot of available frequencies and not limited
by the min/max frequency restrictions.
What: /sys/class/devfreq/.../available_governors
Date: October 2012
Contact: Nishanth Menon <nm@ti.com>
Description:
The /sys/class/devfreq/.../available_governors shows
currently available governors in the system.

11
Documentation/ABI/testing/sysfs-class-net-batman-adv
View File

@@ -1,4 +1,10 @@
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Indicates the status of <iface> as it is seen by batman.
What: /sys/class/net/<iface>/batman-adv/mesh_iface
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
@@ -7,8 +13,3 @@ Description:
displays the batman mesh interface this <iface>
currently is associated with.
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Indicates the status of <iface> as it is seen by batman.

35
Documentation/ABI/testing/sysfs-class-net-grcan Normal file
View File

@@ -0,0 +1,35 @@
What: /sys/class/net/<iface>/grcan/enable0
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Hardware configuration of physical interface 0. This file reads
and writes the "Enable 0" bit of the configuration register.
Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
core library documentation for details. The default value is 0
or set by the module parameter grcan.enable0 and can be read at
/sys/module/grcan/parameters/enable0.
What: /sys/class/net/<iface>/grcan/enable1
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Hardware configuration of physical interface 1. This file reads
and writes the "Enable 1" bit of the configuration register.
Possible values: 0 or 1. See the GRCAN chapter of the GRLIB IP
core library documentation for details. The default value is 0
or set by the module parameter grcan.enable1 and can be read at
/sys/module/grcan/parameters/enable1.
What: /sys/class/net/<iface>/grcan/select
Date: October 2012
KernelVersion: 3.8
Contact: Andreas Larsson <andreas@gaisler.com>
Description:
Configuration of which physical interface to be used. Possible
values: 0 or 1. See the GRCAN chapter of the GRLIB IP core
library documentation for details. The default value is 0 or is
set by the module parameter grcan.select and can be read at
/sys/module/grcan/parameters/select.

40
Documentation/ABI/testing/sysfs-class-net-mesh
View File

@@ -6,6 +6,14 @@ Description:
Indicates whether the batman protocol messages of the
mesh <mesh_iface> shall be aggregated or not.
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <ordex@autistici.org>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped.
What: /sys/class/net/<mesh_iface>/mesh/bonding
Date: June 2010
Contact: Simon Wunderlich <siwu@hrz.tu-chemnitz.de>
@@ -31,14 +39,6 @@ Description:
mesh will be fragmented or silently discarded if the
packet size exceeds the outgoing interface MTU.
What: /sys/class/net/<mesh_iface>/mesh/ap_isolation
Date: May 2011
Contact: Antonio Quartulli <ordex@autistici.org>
Description:
Indicates whether the data traffic going from a
wireless client to another wireless client will be
silently dropped.
What: /sys/class/net/<mesh_iface>/mesh/gw_bandwidth
Date: October 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
@@ -60,6 +60,13 @@ Description:
Defines the selection criteria this node will use
to choose a gateway if gw_mode was set to 'client'.
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
Date: Oct 2010
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/orig_interval
Date: May 2010
Contact: Marek Lindner <lindner_marek@yahoo.de>
@@ -67,19 +74,12 @@ Description:
Defines the interval in milliseconds in which batman
sends its protocol messages.
What: /sys/class/net/<mesh_iface>/mesh/hop_penalty
Date: Oct 2010
Contact: Linus Lüssing <linus.luessing@web.de>
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Defines the penalty which will be applied to an
originator message's tq-field on every hop.
What: /sys/class/net/<mesh_iface>/mesh/routing_algo
Date: Dec 2011
Contact: Marek Lindner <lindner_marek@yahoo.de>
Description:
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.
Defines the routing procotol this mesh instance
uses to find the optimal paths through the mesh.
What: /sys/class/net/<mesh_iface>/mesh/vis_mode
Date: May 2010

7
Documentation/ABI/testing/sysfs-devices-node
View File

@@ -1,7 +0,0 @@
What: /sys/devices/system/node/nodeX/compact
Date: February 2010
Contact: Mel Gorman <mel@csn.ul.ie>
Description:
When this file is written to, all memory within that node
will be compacted. When it completes, memory will be freed
into blocks which have as many contiguous pages as possible

33
Documentation/ABI/testing/sysfs-devices-power
View File

@@ -164,7 +164,7 @@ Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../wakeup_prevent_sleep_time_ms attribute
contains the total time the device has been preventing
opportunistic transitions to sleep states from occuring.
opportunistic transitions to sleep states from occurring.
This attribute is read-only. If the device is not enabled to
wake up the system from sleep states, this attribute is not
present.
@@ -204,3 +204,34 @@ Description:
This attribute has no effect on system-wide suspend/resume and
hibernation.
What: /sys/devices/.../power/pm_qos_no_power_off
Date: September 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../power/pm_qos_no_power_off attribute
is used for manipulating the PM QoS "no power off" flag. If
set, this flag indicates to the kernel that power should not
be removed entirely from the device.
Not all drivers support this attribute. If it isn't supported,
it is not present.
This attribute has no effect on system-wide suspend/resume and
hibernation.
What: /sys/devices/.../power/pm_qos_remote_wakeup
Date: September 2012
Contact: Rafael J. Wysocki <rjw@sisk.pl>
Description:
The /sys/devices/.../power/pm_qos_remote_wakeup attribute
is used for manipulating the PM QoS "remote wakeup required"
flag. If set, this flag indicates to the kernel that the
device is a source of user events that have to be signaled from
its low-power states.
Not all drivers support this attribute. If it isn't supported,
it is not present.
This attribute has no effect on system-wide suspend/resume and
hibernation.

13
Documentation/ABI/testing/sysfs-devices-power_resources_D0 Normal file
View File

@@ -0,0 +1,13 @@
What: /sys/devices/.../power_resources_D0/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D0/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D0. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D1 Normal file
View File

@@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D1/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D1/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D1.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D1. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D2 Normal file
View File

@@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D2/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D2/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D2.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D2. The names
of the links are the same as the names of the directories they
point to.

14
Documentation/ABI/testing/sysfs-devices-power_resources_D3hot Normal file
View File

@@ -0,0 +1,14 @@
What: /sys/devices/.../power_resources_D3hot/
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_resources_D3hot/ directory is only
present for device objects representing ACPI device nodes that
use ACPI power resources for power management and support ACPI
power state D3hot.
If present, it contains symbolic links to device directories
representing ACPI power resources that need to be turned on for
the given device node to be in ACPI power state D3hot. The
names of the links are the same as the names of the directories
they point to.

20
Documentation/ABI/testing/sysfs-devices-power_state Normal file
View File

@@ -0,0 +1,20 @@
What: /sys/devices/.../power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../power_state attribute is only present for
device objects representing ACPI device nodes that provide power
management methods.
If present, it contains a string representing the current ACPI
power state of the given device node. Its possible values,
"D0", "D1", "D2", "D3hot", and "D3cold", reflect the power state
names defined by the ACPI specification (ACPI 4 and above).
If the device node uses shared ACPI power resources, this state
determines a list of power resources required not to be turned
off. However, some power resources needed by the device node in
higher-power (lower-number) states may also be ON because of
some other devices using them at the moment.
This attribute is read-only.

23
Documentation/ABI/testing/sysfs-devices-real_power_state Normal file
View File

@@ -0,0 +1,23 @@
What: /sys/devices/.../real_power_state
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../real_power_state attribute is only present
for device objects representing ACPI device nodes that provide
power management methods and use ACPI power resources for power
management.
If present, it contains a string representing the real ACPI
power state of the given device node as returned by the _PSC
control method or inferred from the configuration of power
resources. Its possible values, "D0", "D1", "D2", "D3hot", and
"D3cold", reflect the power state names defined by the ACPI
specification (ACPI 4 and above).
In some situations the value of this attribute may be different
from the value of the /sys/devices/.../power_state attribute for
the same device object. If that happens, some shared power
resources used by the device node are only ON because of some
other devices using them at the moment.
This attribute is read-only.

12
Documentation/ABI/testing/sysfs-devices-resource_in_use Normal file
View File

@@ -0,0 +1,12 @@
What: /sys/devices/.../resource_in_use
Date: January 2013
Contact: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Description:
The /sys/devices/.../resource_in_use attribute is only present
for device objects representing ACPI power resources.
If present, it contains a number (0 or 1) representing the
current status of the given power resource (0 means that the
resource is not in use and therefore it has been turned off).
This attribute is read-only.

14
Documentation/ABI/testing/sysfs-devices-sun Normal file
View File

@@ -0,0 +1,14 @@
Whatt: /sys/devices/.../sun
Date: October 2012
Contact: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Description:
The file contains a Slot-unique ID which provided by the _SUN
method in the ACPI namespace. The value is written in Advanced
Configuration and Power Interface Specification as follows:
"The _SUN value is required to be unique among the slots of
the same type. It is also recommended that this number match
the slot number printed on the physical slot whenever possible."
So reading the sysfs file, we can identify a physical position
of the slot in the system.

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

@@ -67,20 +67,6 @@ Description: Discover NUMA node a CPU belongs to
/sys/devices/system/cpu/cpu42/node2 -> ../../node/node2
What: /sys/devices/system/cpu/cpu#/node
Date: October 2009
Contact: Linux memory management mailing list <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#/topology/core_id
/sys/devices/system/cpu/cpu#/topology/core_siblings
/sys/devices/system/cpu/cpu#/topology/core_siblings_list

8
Documentation/ABI/testing/sysfs-driver-hid-roccat-isku
View File

@@ -117,6 +117,14 @@ Description: When written, this file lets one store macros with max 500
which profile and key to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/reset
Date: November 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, this file lets one reset the device.
The data has to be 3 bytes long.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/isku/roccatisku<minor>/control
Date: June 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>

48
Documentation/ABI/testing/sysfs-driver-hid-roccat-koneplus
View File

@@ -9,15 +9,12 @@ Description: The integer value of this attribute ranges from 0-4.
and the mouse activates this profile immediately.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/firmware_version
Date: October 2010
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/info
Date: November 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
This file is readonly.
Description: When read, this file returns general data like firmware version.
When written, the device can be reset.
The data is 8 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/macro
@@ -42,18 +39,8 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 77 bytes in size.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile_settings
@@ -68,19 +55,8 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 43 bytes in size.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/sensor
@@ -104,9 +80,9 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written a calibration process for the tracking control unit
can be initiated/cancelled.
The data has to be 3 bytes long.
This file is writeonly.
can be initiated/cancelled. Also lets one read/write sensor
registers.
The data has to be 4 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/tcu_image

69
Documentation/ABI/testing/sysfs-driver-hid-roccat-kovaplus
View File

@@ -1,12 +1,3 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_cpi
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-4.
When read, this attribute returns the number of the active
cpi level.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_profile
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@@ -18,33 +9,12 @@ Description: The integer value of this attribute ranges from 0-4.
active when the mouse is powered on.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_x
Date: January 2011
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/info
Date: November 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in x direction.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/actual_sensitivity_y
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 1-10.
When read, this attribute returns the number of the actual
sensitivity in y direction.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/firmware_version
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 121 means 1.21
This file is readonly.
Description: When read, this file returns general data like firmware version.
When written, the device can be reset.
The data is 6 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_buttons
@@ -58,18 +28,8 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_buttons
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 23 bytes in size.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile_settings
@@ -84,17 +44,6 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/kovaplus/roccatkovaplus<minor>/profile[1-5]_settings
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 16 bytes in size.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net

7
Documentation/ABI/testing/sysfs-driver-hid-roccat-lua Normal file
View File

@@ -0,0 +1,7 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/control
Date: October 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When written, cpi, button and light settings can be configured.
When read, actual cpi setting and sensor data are returned.
The data has to be 8 bytes long.
Users: http://roccat.sourceforge.net

76
Documentation/ABI/testing/sysfs-driver-hid-roccat-pyra
View File

@@ -1,37 +1,9 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_cpi
Date: August 2010
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/info
Date: November 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: It is possible to switch the cpi setting of the mouse with the
press of a button.
When read, this file returns the raw number of the actual cpi
setting reported by the mouse. This number has to be further
processed to receive the real dpi value.
VALUE DPI
1 400
2 800
4 1600
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/actual_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the number of the actual profile in
range 0-4.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/firmware_version
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the raw integer version number of the
firmware reported by the mouse. Using the integer value eases
further usage in other programs. To receive the real version
number the decimal point has to be shifted 2 positions to the
left. E.g. a returned value of 138 means 1.38
This file is readonly.
Description: When read, this file returns general data like firmware version.
When written, the device can be reset.
The data is 6 bytes long.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_settings
@@ -46,19 +18,8 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_settings holds information like resolution, sensitivity
and light effects.
When read, these files return the respective profile settings.
The returned data is 13 bytes in size.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile_buttons
@@ -72,27 +33,8 @@ Description: The mouse can store 5 profiles which can be switched by the
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
This file is writeonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/profile[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store 5 profiles which can be switched by the
press of a button. A profile is split in settings and buttons.
profile_buttons holds information about button layout.
When read, these files return the respective profile buttons.
The returned data is 19 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/startup_profile
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the profile
that's active when the mouse is powered on.
This file is readonly.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/pyra/roccatpyra<minor>/settings

3
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu
View File

@@ -40,8 +40,8 @@ What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-
Date: Mai 2012
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns general data like firmware version.
When written, the device can be reset.
The data is 8 bytes long.
This file is readonly.
Users: http://roccat.sourceforge.net
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/savu/roccatsavu<minor>/macro
@@ -74,4 +74,3 @@ Description: The mouse has a Avago ADNS-3090 sensor.
This file allows reading and writing of the mouse sensors registers.
The data has to be 4 bytes long.
Users: http://roccat.sourceforge.net

21
Documentation/ABI/testing/sysfs-driver-hid-srws1 Normal file
View File

@@ -0,0 +1,21 @@
What: /sys/class/leds/SRWS1::<serial>::RPM1
What: /sys/class/leds/SRWS1::<serial>::RPM2
What: /sys/class/leds/SRWS1::<serial>::RPM3
What: /sys/class/leds/SRWS1::<serial>::RPM4
What: /sys/class/leds/SRWS1::<serial>::RPM5
What: /sys/class/leds/SRWS1::<serial>::RPM6
What: /sys/class/leds/SRWS1::<serial>::RPM7
What: /sys/class/leds/SRWS1::<serial>::RPM8
What: /sys/class/leds/SRWS1::<serial>::RPM9
What: /sys/class/leds/SRWS1::<serial>::RPM10
What: /sys/class/leds/SRWS1::<serial>::RPM11
What: /sys/class/leds/SRWS1::<serial>::RPM12
What: /sys/class/leds/SRWS1::<serial>::RPM13
What: /sys/class/leds/SRWS1::<serial>::RPM14
What: /sys/class/leds/SRWS1::<serial>::RPM15
What: /sys/class/leds/SRWS1::<serial>::RPMALL
Date: Jan 2013
KernelVersion: 3.9
Contact: Simon Wood <simon@mungewell.org>
Description: Provides a control for turning on/off the LEDs which form
an RPM meter on the front of the controller

23
Documentation/ABI/testing/sysfs-driver-hid-thingm Normal file
View File

@@ -0,0 +1,23 @@
What: /sys/class/leds/blink1::<serial>/rgb
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: The ThingM blink1 is an USB RGB LED. The color notation is
3-byte hexadecimal. Read this attribute to get the last set
color. Write the 24-bit hexadecimal color to change the current
LED color. The default color is full white (0xFFFFFF).
For instance, set the color to green with: echo 00FF00 > rgb
What: /sys/class/leds/blink1::<serial>/fade
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: This attribute allows to set a fade time in milliseconds for
the next color change. Read the attribute to know the current
fade time. The default value is set to 0 (no fade time). For
instance, set a fade time of 2 seconds with: echo 2000 > fade
What: /sys/class/leds/blink1::<serial>/play
Date: January 2013
Contact: Vivien Didelot <vivien.didelot@savoirfairelinux.com>
Description: This attribute is used to play/pause the light patterns. Write 1
to start playing, 0 to stop. Reading this attribute returns the
current playing status.

2
Documentation/ABI/testing/sysfs-driver-ppi
View File

@@ -5,7 +5,7 @@ Contact: xiaoyan.zhang@intel.com
Description:
This folder includes the attributes related with PPI (Physical
Presence Interface). Only if TPM is supported by BIOS, this
folder makes sence. The folder path can be got by command
folder makes sense. The folder path can be got by command
'find /sys/ -name 'pcrs''. For the detail information of PPI,
please refer to the PPI specification from
http://www.trustedcomputinggroup.org/

52
Documentation/ABI/testing/sysfs-kernel-mm-ksm Normal file
View File

@@ -0,0 +1,52 @@
What: /sys/kernel/mm/ksm
Date: September 2009
KernelVersion: 2.6.32
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Interface for Kernel Samepage Merging (KSM)
What: /sys/kernel/mm/ksm/full_scans
What: /sys/kernel/mm/ksm/pages_shared
What: /sys/kernel/mm/ksm/pages_sharing
What: /sys/kernel/mm/ksm/pages_to_scan
What: /sys/kernel/mm/ksm/pages_unshared
What: /sys/kernel/mm/ksm/pages_volatile
What: /sys/kernel/mm/ksm/run
What: /sys/kernel/mm/ksm/sleep_millisecs
Date: September 2009
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Kernel Samepage Merging daemon sysfs interface
full_scans: how many times all mergeable areas have been
scanned.
pages_shared: how many shared pages are being used.
pages_sharing: how many more sites are sharing them i.e. how
much saved.
pages_to_scan: how many present pages to scan before ksmd goes
to sleep.
pages_unshared: how many pages unique but repeatedly checked
for merging.
pages_volatile: how many pages changing too fast to be placed
in a tree.
run: write 0 to disable ksm, read 0 while ksm is disabled.
write 1 to run ksm, read 1 while ksm is running.
write 2 to disable ksm and unmerge all its pages.
sleep_millisecs: how many milliseconds ksm should sleep between
scans.
See Documentation/vm/ksm.txt for more information.
What: /sys/kernel/mm/ksm/merge_across_nodes
Date: January 2013
KernelVersion: 3.9
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description: Control merging pages across different NUMA nodes.
When it is set to 0 only pages from the same node are merged,
otherwise pages from all nodes can be merged together (default).

83
Documentation/ABI/testing/sysfs-platform-msi-laptop Normal file
View File

@@ -0,0 +1,83 @@
What: /sys/devices/platform/msi-laptop-pf/lcd_level
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Screen brightness: contains a single integer in the range 0..8.
What: /sys/devices/platform/msi-laptop-pf/auto_brightness
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Enable automatic brightness control: contains either 0 or 1. If
set to 1 the hardware adjusts the screen brightness
automatically when the power cord is plugged/unplugged.
What: /sys/devices/platform/msi-laptop-pf/wlan
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
WLAN subsystem enabled: contains either 0 or 1.
What: /sys/devices/platform/msi-laptop-pf/bluetooth
Date: Oct 2006
KernelVersion: 2.6.19
Contact: "Lennart Poettering <mzxreary@0pointer.de>"
Description:
Bluetooth subsystem enabled: contains either 0 or 1. Please
note that this file is constantly 0 if no Bluetooth hardware is
available.
What: /sys/devices/platform/msi-laptop-pf/touchpad
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if touchpad is turned on.
Touchpad state can only be toggled by pressing Fn+F3.
What: /sys/devices/platform/msi-laptop-pf/turbo_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if turbo mode is turned
on. In turbo mode power LED is orange and processor is
overclocked. Turbo mode is available only if charging. It is
only possible to toggle turbo mode state by pressing Fn+F10,
and there is a few seconds cooldown between subsequent toggles.
If user presses Fn+F10 too frequent, turbo mode state is not
changed.
What: /sys/devices/platform/msi-laptop-pf/eco_mode
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if ECO mode is turned on.
In ECO mode power LED is green and userspace should do some
powersaving actions. ECO mode is available only on battery
power. ECO mode can only be toggled by pressing Fn+F10.
What: /sys/devices/platform/msi-laptop-pf/turbo_cooldown
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains value in range 0..3:
* 0 -> Turbo mode is off
* 1 -> Turbo mode is on, cannot be turned off yet
* 2 -> Turbo mode is off, cannot be turned on yet
* 3 -> Turbo mode is on
What: /sys/devices/platform/msi-laptop-pf/auto_fan
Date: Nov 2012
KernelVersion: 3.8
Contact: "Maxim Mikityanskiy <maxtram95@gmail.com>"
Description:
Contains either 0 or 1 and indicates if fan speed is controlled
automatically (1) or fan runs at maximal speed (0). Can be
toggled in software.

47
Documentation/ABI/testing/sysfs-platform-ts5500 Normal file
View File

@@ -0,0 +1,47 @@
What: /sys/devices/platform/ts5500/adc
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an A/D Converter. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/ereset
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of an external reset. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/id
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Product ID of the TS board. TS-5500 ID is 0x60.
What: /sys/devices/platform/ts5500/jumpers
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Bitfield showing the jumpers' state. If a jumper is present,
the corresponding bit is set. For instance, 0x0e means jumpers
2, 3 and 4 are set.
What: /sys/devices/platform/ts5500/rs485
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the RS485 option. If it is present,
it will display "1", otherwise "0".
What: /sys/devices/platform/ts5500/sram
Date: January 2013
KernelVersion: 3.7
Contact: "Savoir-faire Linux Inc." <kernel@savoirfairelinux.com>
Description:
Indicates the presence of the SRAM option. If it is present,
it will display "1", otherwise "0".

6
Documentation/ABI/testing/sysfs-profiling
View File

@@ -1,13 +1,13 @@
What: /sys/kernel/profile
What: /sys/kernel/profiling
Date: September 2008
Contact: Dave Hansen <dave@linux.vnet.ibm.com>
Description:
/sys/kernel/profile is the runtime equivalent
/sys/kernel/profiling is the runtime equivalent
of the boot-time profile= option.
You can get the same effect running:
echo 2 > /sys/kernel/profile
echo 2 > /sys/kernel/profiling
as you would by issuing profile=2 on the boot
command line.

112
Documentation/ABI/testing/sysfs-tty
View File

@@ -26,3 +26,115 @@ Description:
UART port in serial_core, that is bound to TTY like ttyS0.
uartclk = 16 * baud_base
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/type
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Shows the current tty type for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/line
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Shows the current tty line number for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/port
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Shows the current tty port I/O address for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/irq
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Shows the current primary interrupt for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/flags
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the tty port status flags for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/xmit_fifo_size
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the transmit FIFO size for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/close_delay
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the closing delay time for this port in ms.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/closing_wait
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the close wait time for this port in ms.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/custom_divisor
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the custom divisor if any that is set on this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/io_type
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the I/O type that is to be used with the iomem base
address.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/iomem_base
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
The I/O memory base for this port.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.
What: /sys/class/tty/ttyS0/iomem_reg_shift
Date: October 2012
Contact: Alan Cox <alan@linux.intel.com>
Description:
Show the register shift indicating the spacing to be used
for accesses on this iomem address.
These sysfs values expose the TIOCGSERIAL interface via
sysfs rather than via ioctls.

10
Documentation/CodingStyle
View File

@@ -546,15 +546,7 @@ config AUDIT
logging of avc messages output). Does not do system-call
auditing without CONFIG_AUDITSYSCALL.
Features that might still be considered unstable should be defined as
dependent on "EXPERIMENTAL":
config SLUB
depends on EXPERIMENTAL && !ARCH_USES_SLAB_PAGE_STRUCT
bool "SLUB (Unqueued Allocator)"
...
while seriously dangerous features (such as write support for certain
Seriously dangerous features (such as write support for certain
filesystems) should advertise this prominently in their prompt string:
config ADFS_FS_RW

127
Documentation/DMA-API-HOWTO.txt
View File

@@ -468,11 +468,47 @@ To map a single region, you do:
size_t size = buffer->len;
dma_handle = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
and to unmap it:
dma_unmap_single(dev, dma_handle, size, direction);
You should call dma_mapping_error() as dma_map_single() could fail and return
error. Not all dma implementations support dma_mapping_error() interface.
However, it is a good practice to call dma_mapping_error() interface, which
will invoke the generic mapping error check interface. Doing so will ensure
that the mapping code will work correctly on all dma implementations without
any dependency on the specifics of the underlying implementation. Using the
returned address without checking for errors could result in failures ranging
from panics to silent data corruption. A couple of examples of incorrect ways
to check for errors that make assumptions about the underlying dma
implementation are as follows and these are applicable to dma_map_page() as
well.
Incorrect example 1:
dma_addr_t dma_handle;
dma_handle = dma_map_single(dev, addr, size, direction);
if ((dma_handle & 0xffff != 0) || (dma_handle >= 0x1000000)) {
goto map_error;
}
Incorrect example 2:
dma_addr_t dma_handle;
dma_handle = dma_map_single(dev, addr, size, direction);
if (dma_handle == DMA_ERROR_CODE) {
goto map_error;
}
You should call dma_unmap_single when the DMA activity is finished, e.g.
from the interrupt which told you that the DMA transfer is done.
@@ -489,6 +525,14 @@ Specifically:
size_t size = buffer->len;
dma_handle = dma_map_page(dev, page, offset, size, direction);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
...
@@ -496,6 +540,12 @@ Specifically:
Here, "offset" means byte offset within the given page.
You should call dma_mapping_error() as dma_map_page() could fail and return
error as outlined under the dma_map_single() discussion.
You should call dma_unmap_page when the DMA activity is finished, e.g.
from the interrupt which told you that the DMA transfer is done.
With scatterlists, you map a region gathered from several regions by:
int i, count = dma_map_sg(dev, sglist, nents, direction);
@@ -578,6 +628,14 @@ to use the dma_sync_*() interfaces.
dma_addr_t mapping;
mapping = dma_map_single(cp->dev, buffer, len, DMA_FROM_DEVICE);
if (dma_mapping_error(dma_handle)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
cp->rx_buf = buffer;
cp->rx_len = len;
@@ -658,6 +716,75 @@ failure can be determined by:
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
- unmap pages that are already mapped, when mapping error occurs in the middle
of a multiple page mapping attempt. These example are applicable to
dma_map_page() as well.
Example 1:
dma_addr_t dma_handle1;
dma_addr_t dma_handle2;
dma_handle1 = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_handle1)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling1;
}
dma_handle2 = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_handle2)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling2;
}
...
map_error_handling2:
dma_unmap_single(dma_handle1);
map_error_handling1:
Example 2: (if buffers are allocated in a loop, unmap all mapped buffers when
mapping error is detected in the middle)
dma_addr_t dma_addr;
dma_addr_t array[DMA_BUFFERS];
int save_index = 0;
for (i = 0; i < DMA_BUFFERS; i++) {
...
dma_addr = dma_map_single(dev, addr, size, direction);
if (dma_mapping_error(dev, dma_addr)) {
/*
* reduce current DMA mapping usage,
* delay and try again later or
* reset driver.
*/
goto map_error_handling;
}
array[i].dma_addr = dma_addr;
save_index++;
}
...
map_error_handling:
for (i = 0; i < save_index; i++) {
...
dma_unmap_single(array[i].dma_addr);
}
Networking drivers must call dev_kfree_skb to free the socket buffer

12
Documentation/DMA-API.txt
View File

@@ -678,3 +678,15 @@ out of dma_debug_entries. These entries are preallocated at boot. The number
of preallocated entries is defined per architecture. If it is too low for you
boot with 'dma_debug_entries=<your_desired_number>' to overwrite the
architectural default.
void debug_dmap_mapping_error(struct device *dev, dma_addr_t dma_addr);
dma-debug interface debug_dma_mapping_error() to debug drivers that fail
to check dma mapping errors on addresses returned by dma_map_single() and
dma_map_page() interfaces. This interface clears a flag set by
debug_dma_map_page() to indicate that dma_mapping_error() has been called by
the driver. When driver does unmap, debug_dma_unmap() checks the flag and if
this flag is still set, prints warning message that includes call trace that
leads up to the unmap. This interface can be called from dma_mapping_error()
routines to enable dma mapping error check debugging.

9
Documentation/DMA-attributes.txt
View File

@@ -91,3 +91,12 @@ transferred to 'device' domain. This attribute can be also used for
dma_unmap_{single,page,sg} functions family to force buffer to stay in
device domain after releasing a mapping for it. Use this attribute with
care!
DMA_ATTR_FORCE_CONTIGUOUS
-------------------------
By default DMA-mapping subsystem is allowed to assemble the buffer
allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifing this attribute the allocated buffer is forced to be contiguous
also in physical memory.

4
Documentation/DocBook/80211.tmpl
View File

@@ -107,8 +107,8 @@
!Finclude/net/cfg80211.h key_params
!Finclude/net/cfg80211.h survey_info_flags
!Finclude/net/cfg80211.h survey_info
!Finclude/net/cfg80211.h beacon_parameters
!Finclude/net/cfg80211.h plink_actions
!Finclude/net/cfg80211.h cfg80211_beacon_data
!Finclude/net/cfg80211.h cfg80211_ap_settings
!Finclude/net/cfg80211.h station_parameters
!Finclude/net/cfg80211.h station_info_flags
!Finclude/net/cfg80211.h rate_info_flags

117
Documentation/DocBook/drm.tmpl
View File

@@ -743,6 +743,10 @@ char *date;</synopsis>
These two operations are mandatory for GEM drivers that support DRM
PRIME.
</para>
<sect4>
<title>DRM PRIME Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_prime.c PRIME Helpers
</sect4>
</sect3>
<sect3 id="drm-gem-objects-mapping">
<title>GEM Objects Mapping</title>
@@ -978,10 +982,25 @@ int max_width, max_height;</synopsis>
If the parameters are deemed valid, drivers then create, initialize and
return an instance of struct <structname>drm_framebuffer</structname>.
If desired the instance can be embedded in a larger driver-specific
structure. The new instance is initialized with a call to
<function>drm_framebuffer_init</function> which takes a pointer to DRM
frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Frame buffer operations are
structure. Drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
<para>
The initailization of the new framebuffer instance is finalized with a
call to <function>drm_framebuffer_init</function> which takes a pointer
to DRM frame buffer operations (struct
<structname>drm_framebuffer_funcs</structname>). Note that this function
publishes the framebuffer and so from this point on it can be accessed
concurrently from other threads. Hence it must be the last step in the
driver's framebuffer initialization sequence. Frame buffer operations
are
<itemizedlist>
<listitem>
<synopsis>int (*create_handle)(struct drm_framebuffer *fb,
@@ -1022,16 +1041,16 @@ int max_width, max_height;</synopsis>
</itemizedlist>
</para>
<para>
After initializing the <structname>drm_framebuffer</structname>
instance drivers must fill its <structfield>width</structfield>,
<structfield>height</structfield>, <structfield>pitches</structfield>,
<structfield>offsets</structfield>, <structfield>depth</structfield>,
<structfield>bits_per_pixel</structfield> and
<structfield>pixel_format</structfield> fields from the values passed
through the <parameter>drm_mode_fb_cmd2</parameter> argument. They
should call the <function>drm_helper_mode_fill_fb_struct</function>
helper function to do so.
</para>
The lifetime of a drm framebuffer is controlled with a reference count,
drivers can grab additional references with
<function>drm_framebuffer_reference</function> </para> and drop them
again with <function>drm_framebuffer_unreference</function>. For
driver-private framebuffers for which the last reference is never
dropped (e.g. for the fbdev framebuffer when the struct
<structname>drm_framebuffer</structname> is embedded into the fbdev
helper struct) drivers can manually clean up a framebuffer at module
unload time with
<function>drm_framebuffer_unregister_private</function>.
</sect2>
<sect2>
<title>Output Polling</title>
@@ -1043,6 +1062,22 @@ int max_width, max_height;</synopsis>
operation.
</para>
</sect2>
<sect2>
<title>Locking</title>
<para>
Beside some lookup structures with their own locking (which is hidden
behind the interface functions) most of the modeset state is protected
by the <code>dev-&lt;mode_config.lock</code> mutex and additionally
per-crtc locks to allow cursor updates, pageflips and similar operations
to occur concurrently with background tasks like output detection.
Operations which cross domains like a full modeset always grab all
locks. Drivers there need to protect resources shared between crtcs with
additional locking. They also need to be careful to always grab the
relevant crtc locks if a modset functions touches crtc state, e.g. for
load detection (which does only grab the <code>mode_config.lock</code>
to allow concurrent screen updates on live crtcs).
</para>
</sect2>
</sect1>
<!-- Internals: kms initialization and cleanup -->
@@ -1125,6 +1160,12 @@ int max_width, max_height;</synopsis>
without waiting for rendering or page flip to complete and must block
any new rendering to the frame buffer until the page flip completes.
</para>
<para>
If a page flip can be successfully scheduled the driver must set the
<code>drm_crtc-&lt;fb</code> field to the new framebuffer pointed to
by <code>fb</code>. This is important so that the reference counting
on framebuffers stays balanced.
</para>
<para>
If a page flip is already pending, the
<methodname>page_flip</methodname> operation must return
@@ -1141,23 +1182,13 @@ int max_width, max_height;</synopsis>
the <methodname>page_flip</methodname> operation will be called with a
non-NULL <parameter>event</parameter> argument pointing to a
<structname>drm_pending_vblank_event</structname> instance. Upon page
flip completion the driver must fill the
<parameter>event</parameter>::<structfield>event</structfield>
<structfield>sequence</structfield>, <structfield>tv_sec</structfield>
and <structfield>tv_usec</structfield> fields with the associated
vertical blanking count and timestamp, add the event to the
<parameter>drm_file</parameter> list of events to be signaled, and wake
up any waiting process. This can be performed with
flip completion the driver must call <methodname>drm_send_vblank_event</methodname>
to fill in the event and send to wake up any waiting processes.
This can be performed with
<programlisting><![CDATA[
struct timeval now;
event->event.sequence = drm_vblank_count_and_time(..., &now);
event->event.tv_sec = now.tv_sec;
event->event.tv_usec = now.tv_usec;
spin_lock_irqsave(&dev->event_lock, flags);
list_add_tail(&event->base.link, &event->base.file_priv->event_list);
wake_up_interruptible(&event->base.file_priv->event_wait);
...
drm_send_vblank_event(dev, pipe, event);
spin_unlock_irqrestore(&dev->event_lock, flags);
]]></programlisting>
</para>
@@ -1619,12 +1650,16 @@ void intel_crt_init(struct drm_device *dev)
make its properties available to applications.
</para>
</sect2>
<sect2>
<title>KMS API Functions</title>
!Edrivers/gpu/drm/drm_crtc.c
</sect2>
</sect1>
<!-- Internals: mid-layer helper functions -->
<!-- Internals: kms helper functions -->
<sect1>
<title>Mid-layer Helper Functions</title>
<title>Mode Setting Helper Functions</title>
<para>
The CRTC, encoder and connector functions provided by the drivers
implement the DRM API. They're called by the DRM core and ioctl handlers
@@ -2106,6 +2141,26 @@ void intel_crt_init(struct drm_device *dev)
</listitem>
</itemizedlist>
</sect2>
<sect2>
<title>Modeset Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_crtc_helper.c
</sect2>
<sect2>
<title>fbdev Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_fb_helper.c fbdev helpers
!Edrivers/gpu/drm/drm_fb_helper.c
!Iinclude/drm/drm_fb_helper.h
</sect2>
<sect2>
<title>Display Port Helper Functions Reference</title>
!Pdrivers/gpu/drm/drm_dp_helper.c dp helpers
!Iinclude/drm/drm_dp_helper.h
!Edrivers/gpu/drm/drm_dp_helper.c
</sect2>
<sect2>
<title>EDID Helper Functions Reference</title>
!Edrivers/gpu/drm/drm_edid.c
</sect2>
</sect1>
<!-- Internals: vertical blanking -->

2
Documentation/DocBook/gadget.tmpl
View File

@@ -671,7 +671,7 @@ than a kernel driver.
<para>There's a USB Mass Storage class driver, which provides
a different solution for interoperability with systems such
as MS-Windows and MacOS.
That <emphasis>File-backed Storage</emphasis> driver uses a
That <emphasis>Mass Storage</emphasis> driver uses a
file or block device as backing store for a drive,
like the <filename>loop</filename> driver.
The USB host uses the BBB, CB, or CBI versions of the mass

3
Documentation/DocBook/kernel-api.tmpl
View File

@@ -58,6 +58,9 @@
<sect1><title>String Conversions</title>
!Elib/vsprintf.c
!Finclude/linux/kernel.h kstrtol
!Finclude/linux/kernel.h kstrtoul
!Elib/kstrtox.c
</sect1>
<sect1><title>String Manipulation</title>
<!-- All functions are exported at now

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

@@ -945,7 +945,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="sym-exportsymbols">
<title><function>EXPORT_SYMBOL()</function>
<filename class="headerfile">include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/export.h</filename></title>
<para>
This is the classic method of exporting a symbol: dynamically
@@ -955,7 +955,7 @@ printk(KERN_INFO "my ip: %pI4\n", &amp;ipaddress);
<sect1 id="sym-exportsymbols-gpl">
<title><function>EXPORT_SYMBOL_GPL()</function>
<filename class="headerfile">include/linux/module.h</filename></title>
<filename class="headerfile">include/linux/export.h</filename></title>
<para>
Similar to <function>EXPORT_SYMBOL()</function> except that the
@@ -1184,13 +1184,6 @@ static struct block_device_operations opt_fops = {
<filename>Documentation/kbuild/kconfig-language.txt</filename>.
</para>
<para>
You may well want to make your CONFIG option only visible if
<symbol>CONFIG_EXPERIMENTAL</symbol> is enabled: this serves as a
warning to users. There many other fancy things you can do: see
the various <filename>Kconfig</filename> files for ideas.
</para>
<para>
In your description of the option, make sure you address both the
expert user and the user who knows nothing about your feature. Mention

6
Documentation/DocBook/kgdb.tmpl
View File

@@ -94,10 +94,8 @@
<sect1 id="CompileKGDB">
<title>Kernel config options for kgdb</title>
<para>
To enable <symbol>CONFIG_KGDB</symbol> you should first turn on
"Prompt for development and/or incomplete code/drivers"
(CONFIG_EXPERIMENTAL) in "General setup", then under the
"Kernel debugging" select "KGDB: kernel debugger".
To enable <symbol>CONFIG_KGDB</symbol> you should look under
"Kernel debugging" and select "KGDB: kernel debugger".
</para>
<para>
While it is not a hard requirement that you have symbols in your

2
Documentation/DocBook/media/dvb/dvbapi.xml
View File

@@ -84,7 +84,7 @@ Added ISDB-T test originally written by Patrick Boettcher
<title>LINUX DVB API</title>
<subtitle>Version 5.8</subtitle>
<subtitle>Version 5.10</subtitle>
<!-- ADD THE CHAPTERS HERE -->
<chapter id="dvb_introdution">
&sub-intro;

180
Documentation/DocBook/media/dvb/dvbproperty.xml
View File

@@ -7,14 +7,41 @@ the capability ioctls weren't implemented yet via the new way.</para>
<para>The typical usage for the <constant>FE_GET_PROPERTY/FE_SET_PROPERTY</constant>
API is to replace the ioctl's were the <link linkend="dvb-frontend-parameters">
struct <constant>dvb_frontend_parameters</constant></link> were used.</para>
<section id="dtv-stats">
<title>DTV stats type</title>
<programlisting>
struct dtv_stats {
__u8 scale; /* enum fecap_scale_params type */
union {
__u64 uvalue; /* for counters and relative scales */
__s64 svalue; /* for 1/1000 dB measures */
};
} __packed;
</programlisting>
</section>
<section id="dtv-fe-stats">
<title>DTV stats type</title>
<programlisting>
#define MAX_DTV_STATS 4
struct dtv_fe_stats {
__u8 len;
struct dtv_stats stat[MAX_DTV_STATS];
} __packed;
</programlisting>
</section>
<section id="dtv-property">
<title>DTV property type</title>
<programlisting>
/* Reserved fields should be set to 0 */
struct dtv_property {
__u32 cmd;
__u32 reserved[3];
union {
__u32 data;
struct dtv_fe_stats st;
struct {
__u8 data[32];
__u32 len;
@@ -440,7 +467,7 @@ typedef enum fe_delivery_system {
<title><constant>DTV-ISDBT-LAYER*</constant> parameters</title>
<para>ISDB-T channels can be coded hierarchically. As opposed to DVB-T in
ISDB-T hierarchical layers can be decoded simultaneously. For that
reason a ISDB-T demodulator has 3 viterbi and 3 reed-solomon-decoders.</para>
reason a ISDB-T demodulator has 3 Viterbi and 3 Reed-Solomon decoders.</para>
<para>ISDB-T has 3 hierarchical layers which each can use a part of the
available segments. The total number of segments over all layers has
to 13 in ISDB-T.</para>
@@ -850,6 +877,147 @@ enum fe_interleaving {
<para>use the special macro LNA_AUTO to set LNA auto</para>
</section>
</section>
<section id="frontend-stat-properties">
<title>Frontend statistics indicators</title>
<para>The values are returned via <constant>dtv_property.stat</constant>.
If the property is supported, <constant>dtv_property.stat.len</constant> is bigger than zero.</para>
<para>For most delivery systems, <constant>dtv_property.stat.len</constant>
will be 1 if the stats is supported, and the properties will
return a single value for each parameter.</para>
<para>It should be noticed, however, that new OFDM delivery systems
like ISDB can use different modulation types for each group of
carriers. On such standards, up to 3 groups of statistics can be
provided, and <constant>dtv_property.stat.len</constant> is updated
to reflect the "global" metrics, plus one metric per each carrier
group (called "layer" on ISDB).</para>
<para>So, in order to be consistent with other delivery systems, the first
value at <link linkend="dtv-stats"><constant>dtv_property.stat.dtv_stats</constant></link>
array refers to the global metric. The other elements of the array
represent each layer, starting from layer A(index 1),
layer B (index 2) and so on.</para>
<para>The number of filled elements are stored at <constant>dtv_property.stat.len</constant>.</para>
<para>Each element of the <constant>dtv_property.stat.dtv_stats</constant> array consists on two elements:</para>
<itemizedlist mark='opencircle'>
<listitem><para><constant>svalue</constant> or <constant>uvalue</constant>, where
<constant>svalue</constant> is for signed values of the measure (dB measures)
and <constant>uvalue</constant> is for unsigned values (counters, relative scale)</para></listitem>
<listitem><para><constant>scale</constant> - Scale for the value. It can be:</para>
<section id = "fecap-scale-params">
<itemizedlist mark='bullet'>
<listitem><para><constant>FE_SCALE_NOT_AVAILABLE</constant> - The parameter is supported by the frontend, but it was not possible to collect it (could be a transitory or permanent condition)</para></listitem>
<listitem><para><constant>FE_SCALE_DECIBEL</constant> - parameter is a signed value, measured in 1/1000 dB</para></listitem>
<listitem><para><constant>FE_SCALE_RELATIVE</constant> - parameter is a unsigned value, where 0 means 0% and 65535 means 100%.</para></listitem>
<listitem><para><constant>FE_SCALE_COUNTER</constant> - parameter is a unsigned value that counts the occurrence of an event, like bit error, block error, or lapsed time.</para></listitem>
</itemizedlist>
</section>
</listitem>
</itemizedlist>
<section id="DTV-STAT-SIGNAL-STRENGTH">
<title><constant>DTV_STAT_SIGNAL_STRENGTH</constant></title>
<para>Indicates the signal strength level at the analog part of the tuner or of the demod.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - signal strength is in 0.0001 dBm units, power measured in miliwatts. This value is generally negative.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for power (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-CNR">
<title><constant>DTV_STAT_CNR</constant></title>
<para>Indicates the Signal to Noise ratio for the main carrier.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_DECIBEL</constant> - Signal/Noise ratio is in 0.0001 dB units.</listitem>
<listitem><constant>FE_SCALE_RELATIVE</constant> - The frontend provides a 0% to 100% measurement for Signal/Noise (actually, 0 to 65535).</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors before the forward error correction (FEC) on the inner coding block (before Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-PRE-TOTAL-BIT-COUNT"><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted before the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-PRE-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_PRE_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received before the inner code block, during the same period as
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-PRE-ERROR-BIT-COUNT"><constant>DTV_STAT_PRE_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-ERROR-BIT-COUNT">
<title><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></title>
<para>Measures the number of bit errors after the forward error correction (FEC) done by inner code block (after Viterbi, LDPC or other inner code).</para>
<para>This measure is taken during the same interval as <constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant>.</para>
<para>In order to get the BER (Bit Error Rate) measurement, it should be divided by
<link linkend="DTV-STAT-POST-TOTAL-BIT-COUNT"><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></link>.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error bits counted after the inner coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-POST-TOTAL-BIT-COUNT">
<title><constant>DTV_STAT_POST_TOTAL_BIT_COUNT</constant></title>
<para>Measures the amount of bits received after the inner coding, during the same period as
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link> measurement was taken.</para>
<para>It should be noticed that this measurement can be smaller than the total amount of bits on the transport stream,
as the frontend may need to manually restart the measurement, loosing some data between each measurement interval.</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of bits counted while measuring
<link linkend="DTV-STAT-POST-ERROR-BIT-COUNT"><constant>DTV_STAT_POST_ERROR_BIT_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-ERROR-BLOCK-COUNT">
<title><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></title>
<para>Measures the number of block errors after the outer forward error correction coding (after Reed-Solomon or other outer code).</para>
<para>This measurement is monotonically increased, as the frontend gets more bit count measurements.
The frontend may reset it when a channel/transponder is tuned.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of error blocks counted after the outer coding.</listitem>
</itemizedlist>
</section>
<section id="DTV-STAT-TOTAL-BLOCK-COUNT">
<title><constant>DTV-STAT_TOTAL_BLOCK_COUNT</constant></title>
<para>Measures the total number of blocks received during the same period as
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link> measurement was taken.</para>
<para>It can be used to calculate the PER indicator, by dividing
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>
by <link linkend="DTV-STAT-TOTAL-BLOCK-COUNT"><constant>DTV-STAT-TOTAL-BLOCK-COUNT</constant></link>.</para>
<para>Possible scales for this metric are:</para>
<itemizedlist mark='bullet'>
<listitem><constant>FE_SCALE_NOT_AVAILABLE</constant> - it failed to measure it, or the measurement was not complete yet.</listitem>
<listitem><constant>FE_SCALE_COUNTER</constant> - Number of blocks counted while measuring
<link linkend="DTV-STAT-ERROR-BLOCK-COUNT"><constant>DTV_STAT_ERROR_BLOCK_COUNT</constant></link>.</listitem>
</itemizedlist>
</section>
</section>
<section id="frontend-property-terrestrial-systems">
<title>Properties used on terrestrial delivery systems</title>
<section id="dvbt-params">
@@ -871,6 +1039,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-HIERARCHY"><constant>DTV_HIERARCHY</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbt2-params">
<title>DVB-T2 delivery system</title>
@@ -895,6 +1064,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="isdbt">
<title>ISDB-T delivery system</title>
@@ -948,6 +1118,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ISDBT-LAYER-SEGMENT-COUNT"><constant>DTV_ISDBT_LAYERC_SEGMENT_COUNT</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ISDBT-LAYER-TIME-INTERLEAVING"><constant>DTV_ISDBT_LAYERC_TIME_INTERLEAVING</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atsc-params">
<title>ATSC delivery system</title>
@@ -961,6 +1132,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-MODULATION"><constant>DTV_MODULATION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-BANDWIDTH-HZ"><constant>DTV_BANDWIDTH_HZ</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="atscmh-params">
<title>ATSC-MH delivery system</title>
@@ -988,6 +1160,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-C"><constant>DTV_ATSCMH_SCCC_CODE_MODE_C</constant></link></para></listitem>
<listitem><para><link linkend="DTV-ATSCMH-SCCC-CODE-MODE-D"><constant>DTV_ATSCMH_SCCC_CODE_MODE_D</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dtmb-params">
<title>DTMB delivery system</title>
@@ -1007,6 +1180,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INTERLEAVING"><constant>DTV_INTERLEAVING</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-cable-systems">
@@ -1028,6 +1202,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INNER-FEC"><constant>DTV_INNER_FEC</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="dvbc-annex-b-params">
<title>DVB-C Annex B delivery system</title>
@@ -1043,6 +1218,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-INVERSION"><constant>DTV_INVERSION</constant></link></para></listitem>
<listitem><para><link linkend="DTV-LNA"><constant>DTV_LNA</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
</section>
<section id="frontend-property-satellital-systems">
@@ -1062,6 +1238,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-VOLTAGE"><constant>DTV_VOLTAGE</constant></link></para></listitem>
<listitem><para><link linkend="DTV-TONE"><constant>DTV_TONE</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
<para>Future implementations might add those two missing parameters:</para>
<itemizedlist mark='opencircle'>
<listitem><para><link linkend="DTV-DISEQC-MASTER"><constant>DTV_DISEQC_MASTER</constant></link></para></listitem>
@@ -1077,6 +1254,7 @@ enum fe_interleaving {
<listitem><para><link linkend="DTV-ROLLOFF"><constant>DTV_ROLLOFF</constant></link></para></listitem>
<listitem><para><link linkend="DTV-STREAM-ID"><constant>DTV_STREAM_ID</constant></link></para></listitem>
</itemizedlist>
<para>In addition, the <link linkend="frontend-stat-properties">DTV QoS statistics</link> are also valid.</para>
</section>
<section id="turbo-params">
<title>Turbo code delivery system</title>

2
Documentation/DocBook/media/dvb/frontend.xml
View File

@@ -230,7 +230,7 @@ typedef enum fe_status {
<entry align="char">The frontend has found a DVB signal</entry>
</row><row>
<entry align="char">FE_HAS_VITERBI</entry>
<entry align="char">The frontend FEC code is stable</entry>
<entry align="char">The frontend FEC inner coding (Viterbi, LDPC or other inner code) is stable</entry>
</row><row>
<entry align="char">FE_HAS_SYNC</entry>
<entry align="char">Syncronization bytes was found</entry>

2
Documentation/DocBook/media/v4l/common.xml
View File

@@ -609,7 +609,7 @@ to zero and the <constant>VIDIOC_G_STD</constant>,
<para>Applications can make use of the <xref linkend="input-capabilities" /> and
<xref linkend="output-capabilities"/> flags to determine whether the video standard ioctls
are available for the device.</para>
&ENOTTY;.
<para>See <xref linkend="buffer" /> for a rationale. Probably
even USB cameras follow some well known video standard. It might have
been better to explicitly indicate elsewhere if a device cannot live

23
Documentation/DocBook/media/v4l/compat.xml
View File

@@ -2477,6 +2477,22 @@ that used it. It was originally scheduled for removal in 2.6.35.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 3.9</title>
<orderedlist>
<listitem>
<para>Added timestamp types to
<structfield>flags</structfield> field in
<structname>v4l2_buffer</structname>. See <xref
linkend="buffer-flags" />.</para>
</listitem>
<listitem>
<para>Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control event
changes flag. See <xref linkend="changes-flags"/>.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>
@@ -2586,6 +2602,13 @@ ioctls.</para>
<para>Vendor and device specific media bus pixel formats.
<xref linkend="v4l2-mbus-vendor-spec-fmts" />.</para>
</listitem>
<listitem>
<para>Importing DMABUF file descriptors as a new IO method described
in <xref linkend="dmabuf" />.</para>
</listitem>
<listitem>
<para>Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.</para>
</listitem>
</itemizedlist>
</section>

23
Documentation/DocBook/media/v4l/controls.xml
View File

@@ -203,29 +203,6 @@ and should not be used in new drivers and applications.</entry>
<entry>boolean</entry>
<entry>Mirror the picture vertically.</entry>
</row>
<row>
<entry><constant>V4L2_CID_HCENTER_DEPRECATED</constant> (formerly <constant>V4L2_CID_HCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Horizontal image centering. This control is
deprecated. New drivers and applications should use the <link
linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_PAN_ABSOLUTE</constant>,
<constant>V4L2_CID_PAN_RELATIVE</constant> and
<constant>V4L2_CID_PAN_RESET</constant> instead.</entry>
</row>
<row>
<entry><constant>V4L2_CID_VCENTER_DEPRECATED</constant>
(formerly <constant>V4L2_CID_VCENTER</constant>)</entry>
<entry>integer</entry>
<entry>Vertical image centering. Centering is intended to
<emphasis>physically</emphasis> adjust cameras. For image cropping see
<xref linkend="crop" />, for clipping <xref linkend="overlay" />. This
control is deprecated. New drivers and applications should use the
<link linkend="camera-controls">Camera class controls</link>
<constant>V4L2_CID_TILT_ABSOLUTE</constant>,
<constant>V4L2_CID_TILT_RELATIVE</constant> and
<constant>V4L2_CID_TILT_RESET</constant> instead.</entry>
</row>
<row id="v4l2-power-line-frequency">
<entry><constant>V4L2_CID_POWER_LINE_FREQUENCY</constant></entry>
<entry>enum</entry>

6
Documentation/DocBook/media/v4l/driver.xml
View File

@@ -116,7 +116,7 @@ my_suspend (struct pci_dev * pci_dev,
return 0; /* a negative value on error, 0 on success. */
}
static void __devexit
static void
my_remove (struct pci_dev * pci_dev)
{
my_device *my = pci_get_drvdata (pci_dev);
@@ -124,7 +124,7 @@ my_remove (struct pci_dev * pci_dev)
/* Describe me. */
}
static int __devinit
static int
my_probe (struct pci_dev * pci_dev,
const struct pci_device_id * pci_id)
{
@@ -157,7 +157,7 @@ my_pci_driver = {
.id_table = my_pci_device_ids,
.probe = my_probe,
.remove = __devexit_p (my_remove),
.remove = my_remove,
/* Power management functions. */
.suspend = my_suspend,

243
Documentation/DocBook/media/v4l/io.xml
View File

@@ -331,7 +331,7 @@ application until one or more buffers can be dequeued. By default
outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
returns immediately with an &EAGAIN; when no buffer is available. The
&func-select; or &func-poll; function are always available.</para>
&func-select; or &func-poll; functions are always available.</para>
<para>To start and stop capturing or output applications call the
&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctl. Note
@@ -472,6 +472,165 @@ rest should be evident.</para>
</footnote></para>
</section>
<section id="dmabuf">
<title>Streaming I/O (DMA buffer importing)</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental">experimental</link>
interface and may change in the future.</para>
</note>
<para>The DMABUF framework provides a generic method for sharing buffers
between multiple devices. Device drivers that support DMABUF can export a DMA
buffer to userspace as a file descriptor (known as the exporter role), import a
DMA buffer from userspace using a file descriptor previously exported for a
different or the same device (known as the importer role), or both. This
section describes the DMABUF importer role API in V4L2.</para>
<para>Refer to <link linkend="vidioc-expbuf">DMABUF exporting</link> for
details about exporting V4L2 buffers as DMABUF file descriptors.</para>
<para>Input and output devices support the streaming I/O method when the
<constant>V4L2_CAP_STREAMING</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability; returned by
the &VIDIOC-QUERYCAP; ioctl is set. Whether importing DMA buffers through
DMABUF file descriptors is supported is determined by calling the
&VIDIOC-REQBUFS; ioctl with the memory type set to
<constant>V4L2_MEMORY_DMABUF</constant>.</para>
<para>This I/O method is dedicated to sharing DMA buffers between different
devices, which may be V4L devices or other video-related devices (e.g. DRM).
Buffers (planes) are allocated by a driver on behalf of an application. Next,
these buffers are exported to the application as file descriptors using an API
which is specific for an allocator driver. Only such file descriptor are
exchanged. The descriptors and meta-information are passed in &v4l2-buffer; (or
in &v4l2-plane; in the multi-planar API case). The driver must be switched
into DMABUF I/O mode by calling the &VIDIOC-REQBUFS; with the desired buffer
type.</para>
<example>
<title>Initiating streaming I/O with DMABUF file descriptors</title>
<programlisting>
&v4l2-requestbuffers; reqbuf;
memset(&amp;reqbuf, 0, sizeof (reqbuf));
reqbuf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
reqbuf.memory = V4L2_MEMORY_DMABUF;
reqbuf.count = 1;
if (ioctl(fd, &VIDIOC-REQBUFS;, &amp;reqbuf) == -1) {
if (errno == EINVAL)
printf("Video capturing or DMABUF streaming is not supported\n");
else
perror("VIDIOC_REQBUFS");
exit(EXIT_FAILURE);
}
</programlisting>
</example>
<para>The buffer (plane) file descriptor is passed on the fly with the
&VIDIOC-QBUF; ioctl. In case of multiplanar buffers, every plane can be
associated with a different DMABUF descriptor. Although buffers are commonly
cycled, applications can pass a different DMABUF descriptor at each
<constant>VIDIOC_QBUF</constant> call.</para>
<example>
<title>Queueing DMABUF using single plane API</title>
<programlisting>
int buffer_queue(int v4lfd, int index, int dmafd)
{
&v4l2-buffer; buf;
memset(&amp;buf, 0, sizeof buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.index = index;
buf.m.fd = dmafd;
if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
perror("VIDIOC_QBUF");
return -1;
}
return 0;
}
</programlisting>
</example>
<example>
<title>Queueing DMABUF using multi plane API</title>
<programlisting>
int buffer_queue_mp(int v4lfd, int index, int dmafd[], int n_planes)
{
&v4l2-buffer; buf;
&v4l2-plane; planes[VIDEO_MAX_PLANES];
int i;
memset(&amp;buf, 0, sizeof buf);
buf.type = V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE;
buf.memory = V4L2_MEMORY_DMABUF;
buf.index = index;
buf.m.planes = planes;
buf.length = n_planes;
memset(&amp;planes, 0, sizeof planes);
for (i = 0; i &lt; n_planes; ++i)
buf.m.planes[i].m.fd = dmafd[i];
if (ioctl(v4lfd, &VIDIOC-QBUF;, &amp;buf) == -1) {
perror("VIDIOC_QBUF");
return -1;
}
return 0;
}
</programlisting>
</example>
<para>Captured or displayed buffers are dequeued with the
&VIDIOC-DQBUF; ioctl. The driver can unlock the buffer at any
time between the completion of the DMA and this ioctl. The memory is
also unlocked when &VIDIOC-STREAMOFF; is called, &VIDIOC-REQBUFS;, or
when the device is closed.</para>
<para>For capturing applications it is customary to enqueue a
number of empty buffers, to start capturing and enter the read loop.
Here the application waits until a filled buffer can be dequeued, and
re-enqueues the buffer when the data is no longer needed. Output
applications fill and enqueue buffers, when enough buffers are stacked
up output is started. In the write loop, when the application
runs out of free buffers it must wait until an empty buffer can be
dequeued and reused. Two methods exist to suspend execution of the
application until one or more buffers can be dequeued. By default
<constant>VIDIOC_DQBUF</constant> blocks when no buffer is in the
outgoing queue. When the <constant>O_NONBLOCK</constant> flag was
given to the &func-open; function, <constant>VIDIOC_DQBUF</constant>
returns immediately with an &EAGAIN; when no buffer is available. The
&func-select; and &func-poll; functions are always available.</para>
<para>To start and stop capturing or displaying applications call the
&VIDIOC-STREAMON; and &VIDIOC-STREAMOFF; ioctls. Note that
<constant>VIDIOC_STREAMOFF</constant> removes all buffers from both queues and
unlocks all buffers as a side effect. Since there is no notion of doing
anything "now" on a multitasking system, if an application needs to synchronize
with another event it should examine the &v4l2-buffer;
<structfield>timestamp</structfield> of captured buffers, or set the field
before enqueuing buffers for output.</para>
<para>Drivers implementing DMABUF importing I/O must support the
<constant>VIDIOC_REQBUFS</constant>, <constant>VIDIOC_QBUF</constant>,
<constant>VIDIOC_DQBUF</constant>, <constant>VIDIOC_STREAMON</constant> and
<constant>VIDIOC_STREAMOFF</constant> ioctls, and the
<function>select()</function> and <function>poll()</function> functions.</para>
</section>
<section id="async">
<title>Asynchronous I/O</title>
@@ -582,17 +741,19 @@ applications when an output stream.</entry>
<entry>struct timeval</entry>
<entry><structfield>timestamp</structfield></entry>
<entry></entry>
<entry><para>For input streams this is the
system time (as returned by the <function>gettimeofday()</function>
function) when the first data byte was captured. For output streams
the data will not be displayed before this time, secondary to the
nominal frame rate determined by the current video standard in
enqueued order. Applications can for example zero this field to
display frames as soon as possible. The driver stores the time at
which the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
<entry><para>For input streams this is time when the first data
byte was captured, as returned by the
<function>clock_gettime()</function> function for the relevant
clock id; see <constant>V4L2_BUF_FLAG_TIMESTAMP_*</constant> in
<xref linkend="buffer-flags" />. For output streams the data
will not be displayed before this time, secondary to the nominal
frame rate determined by the current video standard in enqueued
order. Applications can for example zero this field to display
frames as soon as possible. The driver stores the time at which
the first data byte was actually sent out in the
<structfield>timestamp</structfield> field. This permits
applications to monitor the drift between the video and system
clock.</para></entry>
</row>
<row>
<entry>&v4l2-timecode;</entry>
@@ -672,6 +833,14 @@ memory, set by the application. See <xref linkend="userp" /> for details.
in the <structfield>length</structfield> field of this
<structname>v4l2_buffer</structname> structure.</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>fd</structfield></entry>
<entry>For the single-plane API and when
<structfield>memory</structfield> is <constant>V4L2_MEMORY_DMABUF</constant> this
is the file descriptor associated with a DMABUF buffer.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>length</structfield></entry>
@@ -736,13 +905,22 @@ should set this to 0.</entry>
</row>
<row>
<entry></entry>
<entry>__unsigned long</entry>
<entry>unsigned long</entry>
<entry><structfield>userptr</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_USERPTR</constant>, this is a userspace
pointer to the memory allocated for this plane by an application.
</entry>
</row>
<row>
<entry></entry>
<entry>int</entry>
<entry><structfield>fd</structfield></entry>
<entry>When the memory type in the containing &v4l2-buffer; is
<constant>V4L2_MEMORY_DMABUF</constant>, this is a file
descriptor associated with a DMABUF buffer, similar to the
<structfield>fd</structfield> field in &v4l2-buffer;.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>data_offset</structfield></entry>
@@ -923,7 +1101,7 @@ application. Drivers set or clear this flag when the
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_INVALIDATE</constant></entry>
<entry>0x0400</entry>
<entry>0x0800</entry>
<entry>Caches do not have to be invalidated for this buffer.
Typically applications shall use this flag if the data captured in the buffer
is not going to be touched by the CPU, instead the buffer will, probably, be
@@ -932,12 +1110,41 @@ passed on to a DMA-capable hardware unit for further processing or output.
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_NO_CACHE_CLEAN</constant></entry>
<entry>0x0800</entry>
<entry>0x1000</entry>
<entry>Caches do not have to be cleaned for this buffer.
Typically applications shall use this flag for output buffers if the data
in this buffer has not been created by the CPU but by some DMA-capable unit,
in which case caches have not been used.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MASK</constant></entry>
<entry>0xe000</entry>
<entry>Mask for timestamp types below. To test the
timestamp type, mask out bits not belonging to timestamp
type by performing a logical and operation with buffer
flags and timestamp mask.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_UNKNOWN</constant></entry>
<entry>0x0000</entry>
<entry>Unknown timestamp type. This type is used by
drivers before Linux 3.9 and may be either monotonic (see
below) or realtime (wall clock). Monotonic clock has been
favoured in embedded systems whereas most of the drivers
use the realtime clock. Either kinds of timestamps are
available in user space via
<function>clock_gettime(2)</function> using clock IDs
<constant>CLOCK_MONOTONIC</constant> and
<constant>CLOCK_REALTIME</constant>, respectively.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC</constant></entry>
<entry>0x2000</entry>
<entry>The buffer timestamp has been taken from the
<constant>CLOCK_MONOTONIC</constant> clock. To access the
same clock outside V4L2, use
<function>clock_gettime(2)</function> .</entry>
</row>
</tbody>
</tgroup>
</table>
@@ -964,6 +1171,12 @@ pointer</link> I/O.</entry>
<entry>3</entry>
<entry>[to do]</entry>
</row>
<row>
<entry><constant>V4L2_MEMORY_DMABUF</constant></entry>
<entry>4</entry>
<entry>The buffer is used for <link linkend="dmabuf">DMA shared
buffer</link> I/O.</entry>
</row>
</tbody>
</tgroup>
</table>

2
Documentation/DocBook/media/v4l/pixfmt-nv12m.xml
View File

@@ -6,7 +6,7 @@
<refnamediv>
<refname id="V4L2-PIX-FMT-NV12M"><constant>V4L2_PIX_FMT_NV12M</constant></refname>
<refname id="V4L2-PIX-FMT-NV21M"><constant>V4L2_PIX_FMT_NV21M</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT_16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refname id="V4L2-PIX-FMT-NV12MT-16X16"><constant>V4L2_PIX_FMT_NV12MT_16X16</constant></refname>
<refpurpose>Variation of <constant>V4L2_PIX_FMT_NV12</constant> and <constant>V4L2_PIX_FMT_NV21</constant> with planes
non contiguous in memory. </refpurpose>
</refnamediv>

34
Documentation/DocBook/media/v4l/pixfmt-srggb10alaw8.xml Normal file
View File

@@ -0,0 +1,34 @@
<refentry>
<refmeta>
<refentrytitle>
V4L2_PIX_FMT_SBGGR10ALAW8 ('aBA8'),
V4L2_PIX_FMT_SGBRG10ALAW8 ('aGA8'),
V4L2_PIX_FMT_SGRBG10ALAW8 ('agA8'),
V4L2_PIX_FMT_SRGGB10ALAW8 ('aRA8'),
</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname id="V4L2-PIX-FMT-SBGGR10ALAW8">
<constant>V4L2_PIX_FMT_SBGGR10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGBRG10ALAW8">
<constant>V4L2_PIX_FMT_SGBRG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SGRBG10ALAW8">
<constant>V4L2_PIX_FMT_SGRBG10ALAW8</constant>
</refname>
<refname id="V4L2-PIX-FMT-SRGGB10ALAW8">
<constant>V4L2_PIX_FMT_SRGGB10ALAW8</constant>
</refname>
<refpurpose>10-bit Bayer formats compressed to 8 bits</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>The following four pixel formats are raw sRGB / Bayer
formats with 10 bits per color compressed to 8 bits each,
using the A-LAW algorithm. Each color component consumes 8
bits of memory. In other respects this format is similar to
<xref linkend="V4L2-PIX-FMT-SRGGB8"></xref>.</para>
</refsect1>
</refentry>

62
Documentation/DocBook/media/v4l/pixfmt-uv8.xml Normal file
View File

@@ -0,0 +1,62 @@
<refentry id="V4L2-PIX-FMT-UV8">
<refmeta>
<refentrytitle>V4L2_PIX_FMT_UV8 ('UV8')</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname><constant>V4L2_PIX_FMT_UV8</constant></refname>
<refpurpose>UV plane interleaved</refpurpose>
</refnamediv>
<refsect1>
<title>Description</title>
<para>In this format there is no Y plane, Only CbCr plane. ie
(UV interleaved)</para>
<example>
<title>
<constant>V4L2_PIX_FMT_UV8</constant>
pixel image
</title>
<formalpara>
<title>Byte Order.</title>
<para>Each cell is one byte.
<informaltable frame="none">
<tgroup cols="5" align="center">
<colspec align="left" colwidth="2*" />
<tbody valign="top">
<row>
<entry>start&nbsp;+&nbsp;0:</entry>
<entry>Cb<subscript>00</subscript></entry>
<entry>Cr<subscript>00</subscript></entry>
<entry>Cb<subscript>01</subscript></entry>
<entry>Cr<subscript>01</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;4:</entry>
<entry>Cb<subscript>10</subscript></entry>
<entry>Cr<subscript>10</subscript></entry>
<entry>Cb<subscript>11</subscript></entry>
<entry>Cr<subscript>11</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;8:</entry>
<entry>Cb<subscript>20</subscript></entry>
<entry>Cr<subscript>20</subscript></entry>
<entry>Cb<subscript>21</subscript></entry>
<entry>Cr<subscript>21</subscript></entry>
</row>
<row>
<entry>start&nbsp;+&nbsp;12:</entry>
<entry>Cb<subscript>30</subscript></entry>
<entry>Cr<subscript>30</subscript></entry>
<entry>Cb<subscript>31</subscript></entry>
<entry>Cr<subscript>31</subscript></entry>
</row>
</tbody>
</tgroup>
</informaltable>
</para>
</formalpara>
</example>
</refsect1>
</refentry>

2
Documentation/DocBook/media/v4l/pixfmt.xml
View File

@@ -673,6 +673,7 @@ access the palette, this must be done with ioctls of the Linux framebuffer API.<
&sub-srggb8;
&sub-sbggr16;
&sub-srggb10;
&sub-srggb10alaw8;
&sub-srggb10dpcm8;
&sub-srggb12;
</section>
@@ -701,6 +702,7 @@ information.</para>
&sub-y12;
&sub-y10b;
&sub-y16;
&sub-uv8;
&sub-yuyv;
&sub-uyvy;
&sub-yvyu;

938
Documentation/DocBook/media/v4l/subdev-formats.xml
View File

File diff suppressed because it is too large Load Diff

13
Documentation/DocBook/media/v4l/v4l2.xml
View File

@@ -139,6 +139,16 @@ structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>3.9</revnumber>
<date>2012-12-03</date>
<authorinitials>sa, sn</authorinitials>
<revremark>Added timestamp types to v4l2_buffer.
Added <constant>V4L2_EVENT_CTRL_CH_RANGE</constant> control
event changes flag, see <xref linkend="changes-flags"/>.
</revremark>
</revision>
<revision>
<revnumber>3.6</revnumber>
<date>2012-07-02</date>
@@ -472,7 +482,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.6</subtitle>
<subtitle>Revision 3.9</subtitle>
<chapter id="common">
&sub-common;
@@ -543,6 +553,7 @@ and discussions on the V4L mailing list.</revremark>
&sub-enuminput;
&sub-enumoutput;
&sub-enumstd;
&sub-expbuf;
&sub-g-audio;
&sub-g-audioout;
&sub-g-crop;

16
Documentation/DocBook/media/v4l/vidioc-create-bufs.xml
View File

@@ -6,7 +6,8 @@
<refnamediv>
<refname>VIDIOC_CREATE_BUFS</refname>
<refpurpose>Create buffers for Memory Mapped or User Pointer I/O</refpurpose>
<refpurpose>Create buffers for Memory Mapped or User Pointer or DMA Buffer
I/O</refpurpose>
</refnamediv>
<refsynopsisdiv>
@@ -55,11 +56,11 @@
</note>
<para>This ioctl is used to create buffers for <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link>
I/O. It can be used as an alternative or in addition to the
<constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter control over buffers
is required. This ioctl can be called multiple times to create buffers of
different sizes.</para>
mapped</link> or <link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMA buffer</link> I/O. It can be used as an alternative or in
addition to the <constant>VIDIOC_REQBUFS</constant> ioctl, when a tighter
control over buffers is required. This ioctl can be called multiple times to
create buffers of different sizes.</para>
<para>To allocate device buffers applications initialize relevant fields of
the <structname>v4l2_create_buffers</structname> structure. They set the
@@ -109,7 +110,8 @@ information.</para>
<entry>__u32</entry>
<entry><structfield>memory</structfield></entry>
<entry>Applications set this field to
<constant>V4L2_MEMORY_MMAP</constant> or
<constant>V4L2_MEMORY_MMAP</constant>,
<constant>V4L2_MEMORY_DMABUF</constant> or
<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
/></entry>
</row>

6
Documentation/DocBook/media/v4l/vidioc-dqevent.xml
View File

@@ -261,6 +261,12 @@
<entry>This control event was triggered because the control flags
changed.</entry>
</row>
<row>
<entry><constant>V4L2_EVENT_CTRL_CH_RANGE</constant></entry>
<entry>0x0004</entry>
<entry>This control event was triggered because the minimum,
maximum, step or the default value of the control changed.</entry>
</row>
</tbody>
</tgroup>
</table>

208
Documentation/DocBook/media/v4l/vidioc-expbuf.xml Normal file
View File

@@ -0,0 +1,208 @@
<refentry id="vidioc-expbuf">
<refmeta>
<refentrytitle>ioctl VIDIOC_EXPBUF</refentrytitle>
&manvol;
</refmeta>
<refnamediv>
<refname>VIDIOC_EXPBUF</refname>
<refpurpose>Export a buffer as a DMABUF file descriptor.</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_exportbuffer *<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_EXPBUF</para>
</listitem>
</varlistentry>
<varlistentry>
<term><parameter>argp</parameter></term>
<listitem>
<para></para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
<refsect1>
<title>Description</title>
<note>
<title>Experimental</title>
<para>This is an <link linkend="experimental"> experimental </link>
interface and may change in the future.</para>
</note>
<para>This ioctl is an extension to the <link linkend="mmap">memory
mapping</link> I/O method, therefore it is available only for
<constant>V4L2_MEMORY_MMAP</constant> buffers. It can be used to export a
buffer as a DMABUF file at any time after buffers have been allocated with the
&VIDIOC-REQBUFS; ioctl.</para>
<para> To export a buffer, applications fill &v4l2-exportbuffer;. The
<structfield> type </structfield> field is set to the same buffer type as was
previously used with &v4l2-requestbuffers;<structfield> type </structfield>.
Applications must also set the <structfield> index </structfield> field. Valid
index numbers range from zero to the number of buffers allocated with
&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
minus one. For the multi-planar API, applications set the <structfield> plane
</structfield> field to the index of the plane to be exported. Valid planes
range from zero to the maximal number of valid planes for the currently active
format. For the single-planar API, applications must set <structfield> plane
</structfield> to zero. Additional flags may be posted in the <structfield>
flags </structfield> field. Refer to a manual for open() for details.
Currently only O_CLOEXEC is supported. All other fields must be set to zero.
In the case of multi-planar API, every plane is exported separately using
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
</structfield> field will be set by a driver. This is a DMABUF file
descriptor. The application may pass it to other DMABUF-aware devices. Refer to
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
</refsect1>
<refsect1>
<title>Examples</title>
<example>
<title>Exporting a buffer.</title>
<programlisting>
int buffer_export(int v4lfd, &v4l2-buf-type; bt, int index, int *dmafd)
{
&v4l2-exportbuffer; expbuf;
memset(&amp;expbuf, 0, sizeof(expbuf));
expbuf.type = bt;
expbuf.index = index;
if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
perror("VIDIOC_EXPBUF");
return -1;
}
*dmafd = expbuf.fd;
return 0;
}
</programlisting>
</example>
<example>
<title>Exporting a buffer using the multi-planar API.</title>
<programlisting>
int buffer_export_mp(int v4lfd, &v4l2-buf-type; bt, int index,
int dmafd[], int n_planes)
{
int i;
for (i = 0; i &lt; n_planes; ++i) {
&v4l2-exportbuffer; expbuf;
memset(&amp;expbuf, 0, sizeof(expbuf));
expbuf.type = bt;
expbuf.index = index;
expbuf.plane = i;
if (ioctl(v4lfd, &VIDIOC-EXPBUF;, &amp;expbuf) == -1) {
perror("VIDIOC_EXPBUF");
while (i)
close(dmafd[--i]);
return -1;
}
dmafd[i] = expbuf.fd;
}
return 0;
}
</programlisting>
</example>
<table pgwide="1" frame="none" id="v4l2-exportbuffer">
<title>struct <structname>v4l2_exportbuffer</structname></title>
<tgroup cols="3">
&cs-str;
<tbody valign="top">
<row>
<entry>__u32</entry>
<entry><structfield>type</structfield></entry>
<entry>Type of the buffer, same as &v4l2-format;
<structfield>type</structfield> or &v4l2-requestbuffers;
<structfield>type</structfield>, set by the application. See <xref
linkend="v4l2-buf-type" /></entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>index</structfield></entry>
<entry>Number of the buffer, set by the application. This field is
only used for <link linkend="mmap">memory mapping</link> I/O and can range from
zero to the number of buffers allocated with the &VIDIOC-REQBUFS; and/or
&VIDIOC-CREATE-BUFS; ioctls. </entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>plane</structfield></entry>
<entry>Index of the plane to be exported when using the
multi-planar API. Otherwise this value must be set to zero. </entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags for the newly created file, currently only <constant>
O_CLOEXEC </constant> is supported, refer to the manual of open() for more
details.</entry>
</row>
<row>
<entry>__s32</entry>
<entry><structfield>fd</structfield></entry>
<entry>The DMABUF file descriptor associated with a buffer. Set by
the driver.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved[11]</structfield></entry>
<entry>Reserved field for future use. Must be set to zero.</entry>
</row>
</tbody>
</tgroup>
</table>
</refsect1>
<refsect1>
&return-value;
<variablelist>
<varlistentry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>A queue is not in MMAP mode or DMABUF exporting is not
supported or <structfield> flags </structfield> or <structfield> type
</structfield> or <structfield> index </structfield> or <structfield> plane
</structfield> fields are invalid.</para>
</listitem>
</varlistentry>
</variablelist>
</refsect1>
</refentry>

8
Documentation/DocBook/media/v4l/vidioc-g-ctrl.xml
View File

@@ -64,7 +64,9 @@ return an &EINVAL;. When the <structfield>value</structfield> is out
of bounds drivers can choose to take the closest valid value or return
an &ERANGE;, whatever seems more appropriate. However,
<constant>VIDIOC_S_CTRL</constant> is a write-only ioctl, it does not
return the actual new value.</para>
return the actual new value. If the <structfield>value</structfield>
is inappropriate for the control (e.g. if it refers to an unsupported
menu index of a menu control), then &EINVAL; is returned as well.</para>
<para>These ioctls work only with user controls. For other
control classes the &VIDIOC-G-EXT-CTRLS;, &VIDIOC-S-EXT-CTRLS; or
@@ -99,7 +101,9 @@ application.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-control; <structfield>id</structfield> is
invalid.</para>
invalid or the <structfield>value</structfield> is inappropriate for
the given control (i.e. if a menu item is selected that is not supported
by the driver according to &VIDIOC-QUERYMENU;).</para>
</listitem>
</varlistentry>
<varlistentry>

57
Documentation/DocBook/media/v4l/vidioc-g-ext-ctrls.xml
View File

@@ -106,7 +106,9 @@ value or if an error is returned.</para>
&EINVAL;. When the value is out of bounds drivers can choose to take
the closest valid value or return an &ERANGE;, whatever seems more
appropriate. In the first case the new value is set in
&v4l2-ext-control;.</para>
&v4l2-ext-control;. If the new control value is inappropriate (e.g. the
given menu index is not supported by the menu control), then this will
also result in an &EINVAL; error.</para>
<para>The driver will only set/get these controls if all control
values are correct. This prevents the situation where only some of the
@@ -199,13 +201,46 @@ also be zero.</entry>
<row>
<entry>__u32</entry>
<entry><structfield>error_idx</structfield></entry>
<entry>Set by the driver in case of an error. If it is equal
to <structfield>count</structfield>, then no actual changes were made to
controls. In other words, the error was not associated with setting a particular
control. If it is another value, then only the controls up to <structfield>error_idx-1</structfield>
were modified and control <structfield>error_idx</structfield> is the one that
caused the error. The <structfield>error_idx</structfield> value is undefined
if the ioctl returned 0 (success).</entry>
<entry><para>Set by the driver in case of an error. If the error is
associated with a particular control, then <structfield>error_idx</structfield>
is set to the index of that control. If the error is not related to a specific
control, or the validation step failed (see below), then
<structfield>error_idx</structfield> is set to <structfield>count</structfield>.
The value is undefined if the ioctl returned 0 (success).</para>
<para>Before controls are read from/written to hardware a validation step
takes place: this checks if all controls in the list are valid controls,
if no attempt is made to write to a read-only control or read from a write-only
control, and any other up-front checks that can be done without accessing the
hardware. The exact validations done during this step are driver dependent
since some checks might require hardware access for some devices, thus making
it impossible to do those checks up-front. However, drivers should make a
best-effort to do as many up-front checks as possible.</para>
<para>This check is done to avoid leaving the hardware in an inconsistent state due
to easy-to-avoid problems. But it leads to another problem: the application needs to
know whether an error came from the validation step (meaning that the hardware
was not touched) or from an error during the actual reading from/writing to hardware.</para>
<para>The, in hindsight quite poor, solution for that is to set <structfield>error_idx</structfield>
to <structfield>count</structfield> if the validation failed. This has the
unfortunate side-effect that it is not possible to see which control failed the
validation. If the validation was successful and the error happened while
accessing the hardware, then <structfield>error_idx</structfield> is less than
<structfield>count</structfield> and only the controls up to
<structfield>error_idx-1</structfield> were read or written correctly, and the
state of the remaining controls is undefined.</para>
<para>Since <constant>VIDIOC_TRY_EXT_CTRLS</constant> does not access hardware
there is also no need to handle the validation step in this special way,
so <structfield>error_idx</structfield> will just be set to the control that
failed the validation step instead of to <structfield>count</structfield>.
This means that if <constant>VIDIOC_S_EXT_CTRLS</constant> fails with
<structfield>error_idx</structfield> set to <structfield>count</structfield>,
then you can call <constant>VIDIOC_TRY_EXT_CTRLS</constant> to try to discover
the actual control that failed the validation step. Unfortunately, there
is no <constant>TRY</constant> equivalent for <constant>VIDIOC_G_EXT_CTRLS</constant>.
</para></entry>
</row>
<row>
<entry>__u32</entry>
@@ -298,8 +333,10 @@ These controls are described in <xref
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>The &v4l2-ext-control; <structfield>id</structfield>
is invalid or the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid. This error code is
is invalid, the &v4l2-ext-controls;
<structfield>ctrl_class</structfield> is invalid, or the &v4l2-ext-control;
<structfield>value</structfield> was inappropriate (e.g. the given menu
index is not supported by the driver). This error code is
also returned by the <constant>VIDIOC_S_EXT_CTRLS</constant> and
<constant>VIDIOC_TRY_EXT_CTRLS</constant> ioctls if two or more
control values are in conflict.</para>

17
Documentation/DocBook/media/v4l/vidioc-qbuf.xml
View File

@@ -109,6 +109,23 @@ they cannot be swapped out to disk. Buffers remain locked until
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is
called, or until the device is closed.</para>
<para>To enqueue a <link linkend="dmabuf">DMABUF</link> buffer applications
set the <structfield>memory</structfield> field to
<constant>V4L2_MEMORY_DMABUF</constant> and the <structfield>m.fd</structfield>
field to a file descriptor associated with a DMABUF buffer. When the
multi-planar API is used the <structfield>m.fd</structfield> fields of the
passed array of &v4l2-plane; have to be used instead. When
<constant>VIDIOC_QBUF</constant> is called with a pointer to this structure the
driver sets the <constant>V4L2_BUF_FLAG_QUEUED</constant> flag and clears the
<constant>V4L2_BUF_FLAG_MAPPED</constant> and
<constant>V4L2_BUF_FLAG_DONE</constant> flags in the
<structfield>flags</structfield> field, or it returns an error code. This
ioctl locks the buffer. Locking a buffer means passing it to a driver for a
hardware access (usually DMA). If an application accesses (reads/writes) a
locked buffer then the result is undefined. Buffers remain locked until
dequeued, until the &VIDIOC-STREAMOFF; or &VIDIOC-REQBUFS; ioctl is called, or
until the device is closed.</para>
<para>Applications call the <constant>VIDIOC_DQBUF</constant>
ioctl to dequeue a filled (capturing) or displayed (output) buffer
from the driver's outgoing queue. They just set the

2
Documentation/DocBook/media/v4l/vidioc-querycap.xml
View File

@@ -76,7 +76,7 @@ make sure the strings are properly NUL-terminated.</para></entry>
<row>
<entry>__u8</entry>
<entry><structfield>card</structfield>[32]</entry>
<entry>Name of the device, a NUL-terminated ASCII string.
<entry>Name of the device, a NUL-terminated UTF-8 string.
For example: "Yoyodyne TV/FM". One driver may support different brands
or models of video hardware. This information is intended for users,
for example in a menu of available devices. Since multiple TV cards of

47
Documentation/DocBook/media/v4l/vidioc-reqbufs.xml
View File

@@ -48,28 +48,30 @@
<refsect1>
<title>Description</title>
<para>This ioctl is used to initiate <link linkend="mmap">memory
mapped</link> or <link linkend="userp">user pointer</link>
I/O. Memory mapped buffers are located in device memory and must be
allocated with this ioctl before they can be mapped into the
application's address space. User buffers are allocated by
applications themselves, and this ioctl is merely used to switch the
driver into user pointer I/O mode and to setup some internal structures.</para>
<para>This ioctl is used to initiate <link linkend="mmap">memory mapped</link>,
<link linkend="userp">user pointer</link> or <link
linkend="dmabuf">DMABUF</link> based I/O. Memory mapped buffers are located in
device memory and must be allocated with this ioctl before they can be mapped
into the application's address space. User buffers are allocated by
applications themselves, and this ioctl is merely used to switch the driver
into user pointer I/O mode and to setup some internal structures.
Similarly, DMABUF buffers are allocated by applications through a device
driver, and this ioctl only configures the driver into DMABUF I/O mode without
performing any direct allocation.</para>
<para>To allocate device buffers applications initialize all
fields of the <structname>v4l2_requestbuffers</structname> structure.
They set the <structfield>type</structfield> field to the respective
stream or buffer type, the <structfield>count</structfield> field to
the desired number of buffers, <structfield>memory</structfield>
must be set to the requested I/O method and the <structfield>reserved</structfield> array
must be zeroed. When the ioctl
is called with a pointer to this structure the driver will attempt to allocate
the requested number of buffers and it stores the actual number
allocated in the <structfield>count</structfield> field. It can be
smaller than the number requested, even zero, when the driver runs out
of free memory. A larger number is also possible when the driver requires
more buffers to function correctly. For example video output requires at least two buffers,
one displayed and one filled by the application.</para>
<para>To allocate device buffers applications initialize all fields of the
<structname>v4l2_requestbuffers</structname> structure. They set the
<structfield>type</structfield> field to the respective stream or buffer type,
the <structfield>count</structfield> field to the desired number of buffers,
<structfield>memory</structfield> must be set to the requested I/O method and
the <structfield>reserved</structfield> array must be zeroed. When the ioctl is
called with a pointer to this structure the driver will attempt to allocate the
requested number of buffers and it stores the actual number allocated in the
<structfield>count</structfield> field. It can be smaller than the number
requested, even zero, when the driver runs out of free memory. A larger number
is also possible when the driver requires more buffers to function correctly.
For example video output requires at least two buffers, one displayed and one
filled by the application.</para>
<para>When the I/O method is not supported the ioctl
returns an &EINVAL;.</para>
@@ -102,7 +104,8 @@ as the &v4l2-format; <structfield>type</structfield> field. See <xref
<entry>__u32</entry>
<entry><structfield>memory</structfield></entry>
<entry>Applications set this field to
<constant>V4L2_MEMORY_MMAP</constant> or
<constant>V4L2_MEMORY_MMAP</constant>,
<constant>V4L2_MEMORY_DMABUF</constant> or
<constant>V4L2_MEMORY_USERPTR</constant>. See <xref linkend="v4l2-memory"
/>.</entry>
</row>

1
Documentation/DocBook/media_api.tmpl
View File

@@ -22,6 +22,7 @@
<!-- LinuxTV v4l-dvb repository. -->
<!ENTITY v4l-dvb "<ulink url='http://linuxtv.org/repo/'>http://linuxtv.org/repo/</ulink>">
<!ENTITY dash-ent-10 "<entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry><entry>-</entry>">
]>
<book id="media_api">

58
Documentation/DocBook/uio-howto.tmpl
View File

@@ -719,6 +719,62 @@ framework to set up sysfs files for this region. Simply leave it alone.
</para>
</sect1>
<sect1 id="using uio_dmem_genirq">
<title>Using uio_dmem_genirq for platform devices</title>
<para>
In addition to statically allocated memory ranges, they may also be
a desire to use dynamically allocated regions in a user space driver.
In particular, being able to access memory made available through the
dma-mapping API, may be particularly useful. The
<varname>uio_dmem_genirq</varname> driver provides a way to accomplish
this.
</para>
<para>
This driver is used in a similar manner to the
<varname>"uio_pdrv_genirq"</varname> driver with respect to interrupt
configuration and handling.
</para>
<para>
Set the <varname>.name</varname> element of
<varname>struct platform_device</varname> to
<varname>"uio_dmem_genirq"</varname> to use this driver.
</para>
<para>
When using this driver, fill in the <varname>.platform_data</varname>
element of <varname>struct platform_device</varname>, which is of type
<varname>struct uio_dmem_genirq_pdata</varname> and which contains the
following elements:
</para>
<itemizedlist>
<listitem><varname>struct uio_info uioinfo</varname>: The same
structure used as the <varname>uio_pdrv_genirq</varname> platform
data</listitem>
<listitem><varname>unsigned int *dynamic_region_sizes</varname>:
Pointer to list of sizes of dynamic memory regions to be mapped into
user space.
</listitem>
<listitem><varname>unsigned int num_dynamic_regions</varname>:
Number of elements in <varname>dynamic_region_sizes</varname> array.
</listitem>
</itemizedlist>
<para>
The dynamic regions defined in the platform data will be appended to
the <varname> mem[] </varname> array after the platform device
resources, which implies that the total number of static and dynamic
memory regions cannot exceed <varname>MAX_UIO_MAPS</varname>.
</para>
<para>
The dynamic memory regions will be allocated when the UIO device file,
<varname>/dev/uioX</varname> is opened.
Simiar to static memory resources, the memory region information for
dynamic regions is then visible via sysfs at
<varname>/sys/class/uio/uioX/maps/mapY/*</varname>.
The dynmaic memory regions will be freed when the UIO device file is
closed. When no processes are holding the device file open, the address
returned to userspace is ~0.
</para>
</sect1>
</chapter>
<chapter id="userspace_driver" xreflabel="Writing a driver in user space">
@@ -928,7 +984,7 @@ int main()
return errno;
}
configfd = open(&quot;/sys/class/uio/uio0/device/config&quot;, O_RDWR);
if (uiofd &lt; 0) {
if (configfd &lt; 0) {
perror(&quot;config open:&quot;);
return errno;
}

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

@@ -433,9 +433,9 @@
/* chip-specific constructor
* (see "Management of Cards and Components")
*/
static int __devinit snd_mychip_create(struct snd_card *card,
struct pci_dev *pci,
struct mychip **rchip)
static int snd_mychip_create(struct snd_card *card,
struct pci_dev *pci,
struct mychip **rchip)
{
struct mychip *chip;
int err;
@@ -475,8 +475,8 @@
}
/* constructor -- see "Constructor" sub-section */
static int __devinit snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
static int snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
{
static int dev;
struct snd_card *card;
@@ -526,7 +526,7 @@
}
/* destructor -- see the "Destructor" sub-section */
static void __devexit snd_mychip_remove(struct pci_dev *pci)
static void snd_mychip_remove(struct pci_dev *pci)
{
snd_card_free(pci_get_drvdata(pci));
pci_set_drvdata(pci, NULL);
@@ -542,9 +542,8 @@
<para>
The real constructor of PCI drivers is the <function>probe</function> callback.
The <function>probe</function> callback and other component-constructors which are called
from the <function>probe</function> callback should be defined with
the <parameter>__devinit</parameter> prefix. You
cannot use the <parameter>__init</parameter> prefix for them,
from the <function>probe</function> callback cannot be used with
the <parameter>__init</parameter> prefix
because any PCI device could be a hotplug device.
</para>
@@ -728,7 +727,7 @@
<informalexample>
<programlisting>
<![CDATA[
static void __devexit snd_mychip_remove(struct pci_dev *pci)
static void snd_mychip_remove(struct pci_dev *pci)
{
snd_card_free(pci_get_drvdata(pci));
pci_set_drvdata(pci, NULL);
@@ -872,9 +871,8 @@
<para>
This function itself doesn't allocate the data space. The data
must be allocated manually beforehand, and its pointer is passed
as the argument. This pointer is used as the
(<parameter>chip</parameter> identifier in the above example)
for the instance.
as the argument. This pointer (<parameter>chip</parameter> in the
above example) is used as the identifier for the instance.
</para>
<para>
@@ -1058,14 +1056,6 @@
components are released automatically by this call.
</para>
<para>
As further notes, the destructors (both
<function>snd_mychip_dev_free</function> and
<function>snd_mychip_free</function>) cannot be defined with
the <parameter>__devexit</parameter> prefix, because they may be
called from the constructor, too, at the false path.
</para>
<para>
For a device which allows hotplugging, you can use
<function>snd_card_free_when_closed</function>. This one will
@@ -1120,9 +1110,9 @@
}
/* chip-specific constructor */
static int __devinit snd_mychip_create(struct snd_card *card,
struct pci_dev *pci,
struct mychip **rchip)
static int snd_mychip_create(struct snd_card *card,
struct pci_dev *pci,
struct mychip **rchip)
{
struct mychip *chip;
int err;
@@ -1200,7 +1190,7 @@
.name = KBUILD_MODNAME,
.id_table = snd_mychip_ids,
.probe = snd_mychip_probe,
.remove = __devexit_p(snd_mychip_remove),
.remove = snd_mychip_remove,
};
/* module initialization */
@@ -1464,11 +1454,6 @@
</informalexample>
</para>
<para>
Again, remember that you cannot
use the <parameter>__devexit</parameter> prefix for this destructor.
</para>
<para>
We didn't implement the hardware disabling part in the above.
If you need to do this, please note that the destructor may be
@@ -1619,7 +1604,7 @@
.name = KBUILD_MODNAME,
.id_table = snd_mychip_ids,
.probe = snd_mychip_probe,
.remove = __devexit_p(snd_mychip_remove),
.remove = snd_mychip_remove,
};
]]>
</programlisting>
@@ -1630,11 +1615,7 @@
The <structfield>probe</structfield> and
<structfield>remove</structfield> functions have already
been defined in the previous sections.
The <structfield>remove</structfield> function should
be defined with the
<function>__devexit_p()</function> macro, so that it's not
defined for built-in (and non-hot-pluggable) case. The
<structfield>name</structfield>
The <structfield>name</structfield>
field is the name string of this device. Note that you must not
use a slash <quote>/</quote> in this string.
</para>
@@ -1665,9 +1646,7 @@
<para>
Note that these module entries are tagged with
<parameter>__init</parameter> and
<parameter>__exit</parameter> prefixes, not
<parameter>__devinit</parameter> nor
<parameter>__devexit</parameter>.
<parameter>__exit</parameter> prefixes.
</para>
<para>
@@ -1918,7 +1897,7 @@
*/
/* create a pcm device */
static int __devinit snd_mychip_new_pcm(struct mychip *chip)
static int snd_mychip_new_pcm(struct mychip *chip)
{
struct snd_pcm *pcm;
int err;
@@ -1957,7 +1936,7 @@
<informalexample>
<programlisting>
<![CDATA[
static int __devinit snd_mychip_new_pcm(struct mychip *chip)
static int snd_mychip_new_pcm(struct mychip *chip)
{
struct snd_pcm *pcm;
int err;
@@ -2124,7 +2103,7 @@
....
}
static int __devinit snd_mychip_new_pcm(struct mychip *chip)
static int snd_mychip_new_pcm(struct mychip *chip)
{
struct snd_pcm *pcm;
....
@@ -2324,7 +2303,7 @@ struct _snd_pcm_runtime {
<constant>SNDRV_PCM_INFO_XXX</constant>. Here, at least, you
have to specify whether the mmap is supported and which
interleaved format is supported.
When the is supported, add the
When the hardware supports mmap, add the
<constant>SNDRV_PCM_INFO_MMAP</constant> flag here. When the
hardware supports the interleaved or the non-interleaved
formats, <constant>SNDRV_PCM_INFO_INTERLEAVED</constant> or
@@ -2918,7 +2897,7 @@ struct _snd_pcm_runtime {
<para>
When the pcm supports the pause operation (given in the info
field of the hardware table), the <constant>PAUSE_PUSE</constant>
field of the hardware table), the <constant>PAUSE_PUSH</constant>
and <constant>PAUSE_RELEASE</constant> commands must be
handled here, too. The former is the command to pause the pcm,
and the latter to restart the pcm again.
@@ -3105,7 +3084,7 @@ struct _snd_pcm_runtime {
<section id="pcm-interface-interrupt-handler-timer">
<title>High frequency timer interrupts</title>
<para>
This happense when the hardware doesn't generate interrupts
This happens when the hardware doesn't generate interrupts
at the period boundary but issues timer interrupts at a fixed
timer rate (e.g. es1968 or ymfpci drivers).
In this case, you need to check the current hardware
@@ -3270,49 +3249,6 @@ struct _snd_pcm_runtime {
<example>
<title>Example of Hardware Constraints for Channels</title>
<programlisting>
<![CDATA[
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
struct snd_interval *c = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
struct snd_mask fmt;
snd_mask_any(&fmt); /* Init the struct */
if (c->min < 2) {
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
return snd_mask_refine(f, &fmt);
}
return 0;
}
]]>
</programlisting>
</example>
</para>
<para>
Then you need to call this function to add your rule:
<informalexample>
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
hw_rule_channels_by_format, 0, SNDRV_PCM_HW_PARAM_FORMAT,
-1);
]]>
</programlisting>
</informalexample>
</para>
<para>
The rule function is called when an application sets the number of
channels. But an application can set the format before the number of
channels. Thus you also need to define the inverse rule:
<example>
<title>Example of Hardware Constraints for Channels</title>
<programlisting>
<![CDATA[
static int hw_rule_channels_by_format(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
@@ -3335,14 +3271,58 @@ struct _snd_pcm_runtime {
</example>
</para>
<para>
Then you need to call this function to add your rule:
<informalexample>
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
hw_rule_channels_by_format, NULL,
SNDRV_PCM_HW_PARAM_FORMAT, -1);
]]>
</programlisting>
</informalexample>
</para>
<para>
The rule function is called when an application sets the PCM
format, and it refines the number of channels accordingly.
But an application may set the number of channels before
setting the format. Thus you also need to define the inverse rule:
<example>
<title>Example of Hardware Constraints for Formats</title>
<programlisting>
<![CDATA[
static int hw_rule_format_by_channels(struct snd_pcm_hw_params *params,
struct snd_pcm_hw_rule *rule)
{
struct snd_interval *c = hw_param_interval(params,
SNDRV_PCM_HW_PARAM_CHANNELS);
struct snd_mask *f = hw_param_mask(params, SNDRV_PCM_HW_PARAM_FORMAT);
struct snd_mask fmt;
snd_mask_any(&fmt); /* Init the struct */
if (c->min < 2) {
fmt.bits[0] &= SNDRV_PCM_FMTBIT_S16_LE;
return snd_mask_refine(f, &fmt);
}
return 0;
}
]]>
</programlisting>
</example>
</para>
<para>
...and in the open callback:
<informalexample>
<programlisting>
<![CDATA[
snd_pcm_hw_rule_add(substream->runtime, 0, SNDRV_PCM_HW_PARAM_FORMAT,
hw_rule_format_by_channels, 0, SNDRV_PCM_HW_PARAM_CHANNELS,
-1);
hw_rule_format_by_channels, NULL,
SNDRV_PCM_HW_PARAM_CHANNELS, -1);
]]>
</programlisting>
</informalexample>
@@ -3399,7 +3379,7 @@ struct _snd_pcm_runtime {
<title>Definition of a Control</title>
<programlisting>
<![CDATA[
static struct snd_kcontrol_new my_control __devinitdata = {
static struct snd_kcontrol_new my_control = {
.iface = SNDRV_CTL_ELEM_IFACE_MIXER,
.name = "PCM Playback Switch",
.index = 0,
@@ -3414,13 +3394,6 @@ struct _snd_pcm_runtime {
</example>
</para>
<para>
Most likely the control is created via
<function>snd_ctl_new1()</function>, and in such a case, you can
add the <parameter>__devinitdata</parameter> prefix to the
definition as above.
</para>
<para>
The <structfield>iface</structfield> field specifies the control
type, <constant>SNDRV_CTL_ELEM_IFACE_XXX</constant>, which
@@ -3847,10 +3820,8 @@ struct _snd_pcm_runtime {
<para>
<function>snd_ctl_new1()</function> allocates a new
<structname>snd_kcontrol</structname> instance (that's why the definition
of <parameter>my_control</parameter> can be with
the <parameter>__devinitdata</parameter>
prefix), and <function>snd_ctl_add</function> assigns the given
<structname>snd_kcontrol</structname> instance,
and <function>snd_ctl_add</function> assigns the given
control component to the card.
</para>
</section>
@@ -3896,7 +3867,7 @@ struct _snd_pcm_runtime {
<![CDATA[
static DECLARE_TLV_DB_SCALE(db_scale_my_control, -4050, 150, 0);
static struct snd_kcontrol_new my_control __devinitdata = {
static struct snd_kcontrol_new my_control = {
...
.access = SNDRV_CTL_ELEM_ACCESS_READWRITE |
SNDRV_CTL_ELEM_ACCESS_TLV_READ,
@@ -5761,8 +5732,8 @@ struct _snd_pcm_runtime {
<informalexample>
<programlisting>
<![CDATA[
static int __devinit snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
static int snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
{
....
struct snd_card *card;
@@ -5787,8 +5758,8 @@ struct _snd_pcm_runtime {
<informalexample>
<programlisting>
<![CDATA[
static int __devinit snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
static int snd_mychip_probe(struct pci_dev *pci,
const struct pci_device_id *pci_id)
{
....
struct snd_card *card;
@@ -5825,7 +5796,7 @@ struct _snd_pcm_runtime {
.name = KBUILD_MODNAME,
.id_table = snd_my_ids,
.probe = snd_my_probe,
.remove = __devexit_p(snd_my_remove),
.remove = snd_my_remove,
#ifdef CONFIG_PM
.suspend = snd_my_suspend,
.resume = snd_my_resume,

27
Documentation/EDID/HOWTO.txt
View File

@@ -28,11 +28,30 @@ Makefile environment are given here.
To create binary EDID and C source code files from the existing data
material, simply type "make".
If you want to create your own EDID file, copy the file 1024x768.S and
replace the settings with your own data. The CRC value in the last line
If you want to create your own EDID file, copy the file 1024x768.S,
replace the settings with your own data and add a new target to the
Makefile. Please note that the EDID data structure expects the timing
values in a different way as compared to the standard X11 format.
X11:
HTimings: hdisp hsyncstart hsyncend htotal
VTimings: vdisp vsyncstart vsyncend vtotal
EDID:
#define XPIX hdisp
#define XBLANK htotal-hdisp
#define XOFFSET hsyncstart-hdisp
#define XPULSE hsyncend-hsyncstart
#define YPIX vdisp
#define YBLANK vtotal-vdisp
#define YOFFSET (63+(vsyncstart-vdisp))
#define YPULSE (63+(vsyncend-vsyncstart))
The CRC value in the last line
#define CRC 0x55
is a bit tricky. After a first version of the binary data set is
created, it must be be checked with the "edid-decode" utility which will
also is a bit tricky. After a first version of the binary data set is
created, it must be checked with the "edid-decode" utility which will
most probably complain about a wrong CRC. Fortunately, the utility also
displays the correct CRC which must then be inserted into the source
file. After the make procedure is repeated, the EDID data set is ready

2
Documentation/HOWTO
View File

@@ -462,7 +462,7 @@ Differences between the kernel community and corporate structures
The kernel community works differently than most traditional corporate
development environments. Here are a list of things that you can try to
do to try to avoid problems:
do to avoid problems:
Good things to say regarding your proposed changes:
- "This solves multiple problems."
- "This deletes 2000 lines of code."

18
Documentation/IPMI.txt
View File

@@ -348,34 +348,40 @@ You can change this at module load time (for a module) with:
modprobe ipmi_si.o type=<type1>,<type2>....
ports=<port1>,<port2>... addrs=<addr1>,<addr2>...
irqs=<irq1>,<irq2>... trydefaults=[0|1]
irqs=<irq1>,<irq2>...
regspacings=<sp1>,<sp2>,... regsizes=<size1>,<size2>,...
regshifts=<shift1>,<shift2>,...
slave_addrs=<addr1>,<addr2>,...
force_kipmid=<enable1>,<enable2>,...
kipmid_max_busy_us=<ustime1>,<ustime2>,...
unload_when_empty=[0|1]
trydefaults=[0|1] trydmi=[0|1] tryacpi=[0|1]
tryplatform=[0|1] trypci=[0|1]
Each of these except si_trydefaults is a list, the first item for the
Each of these except try... items is a list, the first item for the
first interface, second item for the second interface, etc.
The si_type may be either "kcs", "smic", or "bt". If you leave it blank, it
defaults to "kcs".
If you specify si_addrs as non-zero for an interface, the driver will
If you specify addrs as non-zero for an interface, the driver will
use the memory address given as the address of the device. This
overrides si_ports.
If you specify si_ports as non-zero for an interface, the driver will
If you specify ports as non-zero for an interface, the driver will
use the I/O port given as the device address.
If you specify si_irqs as non-zero for an interface, the driver will
If you specify irqs as non-zero for an interface, the driver will
attempt to use the given interrupt for the device.
si_trydefaults sets whether the standard IPMI interface at 0xca2 and
trydefaults sets whether the standard IPMI interface at 0xca2 and
any interfaces specified by ACPE are tried. By default, the driver
tries it, set this value to zero to turn this off.
The other try... items disable discovery by their corresponding
names. These are all enabled by default, set them to zero to disable
them. The tryplatform disables openfirmware.
The next three parameters have to do with register layout. The
registers used by the interfaces may not appear at successive
locations and they may not be in 8-bit registers. These parameters

34
Documentation/IRQ-domain.txt
View File

@@ -7,6 +7,21 @@ systems with multiple interrupt controllers the kernel must ensure
that each one gets assigned non-overlapping allocations of Linux
IRQ numbers.
The number of interrupt controllers registered as unique irqchips
show a rising tendency: for example subdrivers of different kinds
such as GPIO controllers avoid reimplementing identical callback
mechanisms as the IRQ core system by modelling their interrupt
handlers as irqchips, i.e. in effect cascading interrupt controllers.
Here the interrupt number loose all kind of correspondence to
hardware interrupt numbers: whereas in the past, IRQ numbers could
be chosen so they matched the hardware IRQ line into the root
interrupt controller (i.e. the component actually fireing the
interrupt line to the CPU) nowadays this number is just a number.
For this reason we need a mechanism to separate controller-local
interrupt numbers, called hardware irq's, from Linux IRQ numbers.
The irq_alloc_desc*() and irq_free_desc*() APIs provide allocation of
irq numbers, but they don't provide any support for reverse mapping of
the controller-local IRQ (hwirq) number into the Linux IRQ number
@@ -40,6 +55,10 @@ required hardware setup.
When an interrupt is received, irq_find_mapping() function should
be used to find the Linux IRQ number from the hwirq number.
The irq_create_mapping() function must be called *atleast once*
before any call to irq_find_mapping(), lest the descriptor will not
be allocated.
If the driver has the Linux IRQ number or the irq_data pointer, and
needs to know the associated hwirq number (such as in the irq_chip
callbacks) then it can be directly obtained from irq_data->hwirq.
@@ -119,4 +138,17 @@ numbers.
Most users of legacy mappings should use irq_domain_add_simple() which
will use a legacy domain only if an IRQ range is supplied by the
system and will otherwise use a linear domain mapping.
system and will otherwise use a linear domain mapping. The semantics
of this call are such that if an IRQ range is specified then
descriptors will be allocated on-the-fly for it, and if no range is
specified it will fall through to irq_domain_add_linear() which meand
*no* irq descriptors will be allocated.
A typical use case for simple domains is where an irqchip provider
is supporting both dynamic and static IRQ assignments.
In order to avoid ending up in a situation where a linear domain is
used and no descriptor gets allocated it is very important to make sure
that the driver using the simple domain call irq_create_mapping()
before any irq_find_mapping() since the latter will actually work
for the static IRQ assignment case.

37
Documentation/PCI/MSI-HOWTO.txt
View File

@@ -127,15 +127,42 @@ on the number of vectors that can be allocated; pci_enable_msi_block()
returns as soon as it finds any constraint that doesn't allow the
call to succeed.
4.2.3 pci_disable_msi
4.2.3 pci_enable_msi_block_auto
int pci_enable_msi_block_auto(struct pci_dev *dev, unsigned int *count)
This variation on pci_enable_msi() call allows a device driver to request
the maximum possible number of MSIs. The MSI specification only allows
interrupts to be allocated in powers of two, up to a maximum of 2^5 (32).
If this function returns a positive number, it indicates that it has
succeeded and the returned value is the number of allocated interrupts. In
this case, the function enables MSI on this device and updates dev->irq to
be the lowest of the new interrupts assigned to it. The other interrupts
assigned to the device are in the range dev->irq to dev->irq + returned
value - 1.
If this function returns a negative number, it indicates an error and
the driver should not attempt to request any more MSI interrupts for
this device.
If the device driver needs to know the number of interrupts the device
supports it can pass the pointer count where that number is stored. The
device driver must decide what action to take if pci_enable_msi_block_auto()
succeeds, but returns a value less than the number of interrupts supported.
If the device driver does not need to know the number of interrupts
supported, it can set the pointer count to NULL.
4.2.4 pci_disable_msi
void pci_disable_msi(struct pci_dev *dev)
This function should be used to undo the effect of pci_enable_msi() or
pci_enable_msi_block(). Calling it restores dev->irq to the pin-based
interrupt number and frees the previously allocated message signaled
interrupt(s). The interrupt may subsequently be assigned to another
device, so drivers should not cache the value of dev->irq.
pci_enable_msi_block() or pci_enable_msi_block_auto(). Calling it restores
dev->irq to the pin-based interrupt number and frees the previously
allocated message signaled interrupt(s). The interrupt may subsequently be
assigned to another device, so drivers should not cache the value of
dev->irq.
Before calling this function, a device driver must always call free_irq()
on any interrupt for which it previously called request_irq().

54
Documentation/PCI/pci-iov-howto.txt
View File

@@ -2,6 +2,9 @@
Copyright (C) 2009 Intel Corporation
Yu Zhao <yu.zhao@intel.com>
Update: November 2012
-- sysfs-based SRIOV enable-/disable-ment
Donald Dutile <ddutile@redhat.com>
1. Overview
@@ -24,10 +27,21 @@ real existing PCI device.
2.1 How can I enable SR-IOV capability
The device driver (PF driver) will control the enabling and disabling
of the capability via API provided by SR-IOV core. If the hardware
has SR-IOV capability, loading its PF driver would enable it and all
VFs associated with the PF.
Multiple methods are available for SR-IOV enablement.
In the first method, the device driver (PF driver) will control the
enabling and disabling of the capability via API provided by SR-IOV core.
If the hardware has SR-IOV capability, loading its PF driver would
enable it and all VFs associated with the PF. Some PF drivers require
a module parameter to be set to determine the number of VFs to enable.
In the second method, a write to the sysfs file sriov_numvfs will
enable and disable the VFs associated with a PCIe PF. This method
enables per-PF, VF enable/disable values versus the first method,
which applies to all PFs of the same device. Additionally, the
PCI SRIOV core support ensures that enable/disable operations are
valid to reduce duplication in multiple drivers for the same
checks, e.g., check numvfs == 0 if enabling VFs, ensure
numvfs <= totalvfs.
The second method is the recommended method for new/future VF devices.
2.2 How can I use the Virtual Functions
@@ -40,20 +54,29 @@ requires device driver that is same as a normal PCI device's.
3.1 SR-IOV API
To enable SR-IOV capability:
(a) For the first method, in the driver:
int pci_enable_sriov(struct pci_dev *dev, int nr_virtfn);
'nr_virtfn' is number of VFs to be enabled.
(b) For the second method, from sysfs:
echo 'nr_virtfn' > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
To disable SR-IOV capability:
(a) For the first method, in the driver:
void pci_disable_sriov(struct pci_dev *dev);
(b) For the second method, from sysfs:
echo 0 > \
/sys/bus/pci/devices/<DOMAIN:BUS:DEVICE.FUNCTION>/sriov_numvfs
To notify SR-IOV core of Virtual Function Migration:
(a) In the driver:
irqreturn_t pci_sriov_migration(struct pci_dev *dev);
3.2 Usage example
Following piece of code illustrates the usage of the SR-IOV API.
static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
static int dev_probe(struct pci_dev *dev, const struct pci_device_id *id)
{
pci_enable_sriov(dev, NR_VIRTFN);
@@ -62,7 +85,7 @@ static int __devinit dev_probe(struct pci_dev *dev, const struct pci_device_id *
return 0;
}
static void __devexit dev_remove(struct pci_dev *dev)
static void dev_remove(struct pci_dev *dev)
{
pci_disable_sriov(dev);
@@ -88,12 +111,29 @@ static void dev_shutdown(struct pci_dev *dev)
...
}
static int dev_sriov_configure(struct pci_dev *dev, int numvfs)
{
if (numvfs > 0) {
...
pci_enable_sriov(dev, numvfs);
...
return numvfs;
}
if (numvfs == 0) {
....
pci_disable_sriov(dev);
...
return 0;
}
}
static struct pci_driver dev_driver = {
.name = "SR-IOV Physical Function driver",
.id_table = dev_id_table,
.probe = dev_probe,
.remove = __devexit_p(dev_remove),
.remove = dev_remove,
.suspend = dev_suspend,
.resume = dev_resume,
.shutdown = dev_shutdown,
.sriov_configure = dev_sriov_configure,
};

20
Documentation/PCI/pci.txt
View File

@@ -183,12 +183,6 @@ Please mark the initialization and cleanup functions where appropriate
initializes.
__exit Exit code. Ignored for non-modular drivers.
__devinit Device initialization code.
Identical to __init if the kernel is not compiled
with CONFIG_HOTPLUG, normal function otherwise.
__devexit The same for __exit.
Tips on when/where to use the above attributes:
o The module_init()/module_exit() functions (and all
initialization functions called _only_ from these)
@@ -196,20 +190,6 @@ Tips on when/where to use the above attributes:
o Do not mark the struct pci_driver.
o The ID table array should be marked __devinitconst; this is done
automatically if the table is declared with DEFINE_PCI_DEVICE_TABLE().
o The probe() and remove() functions should be marked __devinit
and __devexit respectively. All initialization functions
exclusively called by the probe() routine, can be marked __devinit.
Ditto for remove() and __devexit.
o If mydriver_remove() is marked with __devexit(), then all address
references to mydriver_remove must use __devexit_p(mydriver_remove)
(in the struct pci_driver declaration for example).
__devexit_p() will generate the function name _or_ NULL if the
function will be discarded. For an example, see drivers/net/tg3.c.
o Do NOT mark a function if you are not sure which mark to use.
Better to not mark the function than mark the function wrong.

2
Documentation/RCU/RTFP.txt
View File

@@ -186,7 +186,7 @@ Bibtex Entries
@article{Kung80
,author="H. T. Kung and Q. Lehman"
,title="Concurrent Maintenance of Binary Search Trees"
,title="Concurrent Manipulation of Binary Search Trees"
,Year="1980"
,Month="September"
,journal="ACM Transactions on Database Systems"

17
Documentation/RCU/checklist.txt
View File

@@ -271,15 +271,14 @@ over a rather long period of time, but improvements are always welcome!
The same cautions apply to call_rcu_bh() and call_rcu_sched().
9. All RCU list-traversal primitives, which include
rcu_dereference(), list_for_each_entry_rcu(),
list_for_each_continue_rcu(), and list_for_each_safe_rcu(),
must be either within an RCU read-side critical section or
must be protected by appropriate update-side locks. RCU
read-side critical sections are delimited by rcu_read_lock()
and rcu_read_unlock(), or by similar primitives such as
rcu_read_lock_bh() and rcu_read_unlock_bh(), in which case
the matching rcu_dereference() primitive must be used in order
to keep lockdep happy, in this case, rcu_dereference_bh().
rcu_dereference(), list_for_each_entry_rcu(), and
list_for_each_safe_rcu(), must be either within an RCU read-side
critical section or must be protected by appropriate update-side
locks. RCU read-side critical sections are delimited by
rcu_read_lock() and rcu_read_unlock(), or by similar primitives
such as rcu_read_lock_bh() and rcu_read_unlock_bh(), in which
case the matching rcu_dereference() primitive must be used in
order to keep lockdep happy, in this case, rcu_dereference_bh().
The reason that it is permissible to use RCU list-traversal
primitives when the update-side lock is held is that doing so

2
Documentation/RCU/listRCU.txt
View File

@@ -205,7 +205,7 @@ RCU ("read-copy update") its name. The RCU code is as follows:
audit_copy_rule(&ne->rule, &e->rule);
ne->rule.action = newaction;
ne->rule.file_count = newfield_count;
list_replace_rcu(e, ne);
list_replace_rcu(&e->list, &ne->list);
call_rcu(&e->rcu, audit_free_rule);
return 0;
}

61
Documentation/RCU/rcuref.txt
View File

@@ -20,7 +20,7 @@ release_referenced() delete()
{ {
... write_lock(&list_lock);
atomic_dec(&el->rc, relfunc) ...
... delete_element
... remove_element
} write_unlock(&list_lock);
...
if (atomic_dec_and_test(&el->rc))
@@ -52,7 +52,7 @@ release_referenced() delete()
{ {
... spin_lock(&list_lock);
if (atomic_dec_and_test(&el->rc)) ...
call_rcu(&el->head, el_free); delete_element
call_rcu(&el->head, el_free); remove_element
... spin_unlock(&list_lock);
} ...
if (atomic_dec_and_test(&el->rc))
@@ -64,3 +64,60 @@ Sometimes, a reference to the element needs to be obtained in the
update (write) stream. In such cases, atomic_inc_not_zero() might be
overkill, since we hold the update-side spinlock. One might instead
use atomic_inc() in such cases.
It is not always convenient to deal with "FAIL" in the
search_and_reference() code path. In such cases, the
atomic_dec_and_test() may be moved from delete() to el_free()
as follows:
1. 2.
add() search_and_reference()
{ {
alloc_object rcu_read_lock();
... search_for_element
atomic_set(&el->rc, 1); atomic_inc(&el->rc);
spin_lock(&list_lock); ...
add_element rcu_read_unlock();
... }
spin_unlock(&list_lock); 4.
} delete()
3. {
release_referenced() spin_lock(&list_lock);
{ ...
... remove_element
if (atomic_dec_and_test(&el->rc)) spin_unlock(&list_lock);
kfree(el); ...
... call_rcu(&el->head, el_free);
} ...
5. }
void el_free(struct rcu_head *rhp)
{
release_referenced();
}
The key point is that the initial reference added by add() is not removed
until after a grace period has elapsed following removal. This means that
search_and_reference() cannot find this element, which means that the value
of el->rc cannot increase. Thus, once it reaches zero, there are no
readers that can or ever will be able to reference the element. The
element can therefore safely be freed. This in turn guarantees that if
any reader finds the element, that reader may safely acquire a reference
without checking the value of the reference counter.
In cases where delete() can sleep, synchronize_rcu() can be called from
delete(), so that el_free() can be subsumed into delete as follows:
4.
delete()
{
spin_lock(&list_lock);
...
remove_element
spin_unlock(&list_lock);
...
synchronize_rcu();
if (atomic_dec_and_test(&el->rc))
kfree(el);
...
}

384
Documentation/RCU/trace.txt
View File

@@ -10,51 +10,63 @@ for rcutree and next for rcutiny.
CONFIG_TREE_RCU and CONFIG_TREE_PREEMPT_RCU debugfs Files and Formats
These implementations of RCU provides several debugfs files under the
These implementations of RCU provide several debugfs directories under the
top-level directory "rcu":
rcu/rcudata:
rcu/rcu_bh
rcu/rcu_preempt
rcu/rcu_sched
Each directory contains files for the corresponding flavor of RCU.
Note that rcu/rcu_preempt is only present for CONFIG_TREE_PREEMPT_RCU.
For CONFIG_TREE_RCU, the RCU flavor maps onto the RCU-sched flavor,
so that activity for both appears in rcu/rcu_sched.
In addition, the following file appears in the top-level directory:
rcu/rcutorture. This file displays rcutorture test progress. The output
of "cat rcu/rcutorture" looks as follows:
rcutorture test sequence: 0 (test in progress)
rcutorture update version number: 615
The first line shows the number of rcutorture tests that have completed
since boot. If a test is currently running, the "(test in progress)"
string will appear as shown above. The second line shows the number of
update cycles that the current test has started, or zero if there is
no test in progress.
Within each flavor directory (rcu/rcu_bh, rcu/rcu_sched, and possibly
also rcu/rcu_preempt) the following files will be present:
rcudata:
Displays fields in struct rcu_data.
rcu/rcudata.csv:
Comma-separated values spreadsheet version of rcudata.
rcu/rcugp:
rcuexp:
Displays statistics for expedited grace periods.
rcugp:
Displays grace-period counters.
rcu/rcuhier:
rcuhier:
Displays the struct rcu_node hierarchy.
rcu/rcu_pending:
rcu_pending:
Displays counts of the reasons rcu_pending() decided that RCU had
work to do.
rcu/rcutorture:
Displays rcutorture test progress.
rcu/rcuboost:
rcuboost:
Displays RCU boosting statistics. Only present if
CONFIG_RCU_BOOST=y.
The output of "cat rcu/rcudata" looks as follows:
The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
rcu_sched:
0 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=545/1/0 df=50 of=0 ql=163 qs=NRW. kt=0/W/0 ktl=ebc3 b=10 ci=153737 co=0 ca=0
1 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=967/1/0 df=58 of=0 ql=634 qs=NRW. kt=0/W/1 ktl=58c b=10 ci=191037 co=0 ca=0
2 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1081/1/0 df=175 of=0 ql=74 qs=N.W. kt=0/W/2 ktl=da94 b=10 ci=75991 co=0 ca=0
3 c=20942 g=20943 pq=1 pgp=20942 qp=1 dt=1846/0/0 df=404 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=72261 co=0 ca=0
4 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=369/1/0 df=83 of=0 ql=48 qs=N.W. kt=0/W/4 ktl=e0e7 b=10 ci=128365 co=0 ca=0
5 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=381/1/0 df=64 of=0 ql=169 qs=NRW. kt=0/W/5 ktl=fb2f b=10 ci=164360 co=0 ca=0
6 c=20972 g=20973 pq=1 pgp=20973 qp=0 dt=1037/1/0 df=183 of=0 ql=62 qs=N.W. kt=0/W/6 ktl=d2ad b=10 ci=65663 co=0 ca=0
7 c=20897 g=20897 pq=1 pgp=20896 qp=0 dt=1572/0/0 df=382 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=75006 co=0 ca=0
rcu_bh:
0 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=545/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/0 ktl=ebc3 b=10 ci=0 co=0 ca=0
1 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=967/1/0 df=3 of=0 ql=0 qs=.... kt=0/W/1 ktl=58c b=10 ci=151 co=0 ca=0
2 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1081/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/2 ktl=da94 b=10 ci=0 co=0 ca=0
3 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1846/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/3 ktl=d1cd b=10 ci=0 co=0 ca=0
4 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=369/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/4 ktl=e0e7 b=10 ci=0 co=0 ca=0
5 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=381/1/0 df=4 of=0 ql=0 qs=.... kt=0/W/5 ktl=fb2f b=10 ci=0 co=0 ca=0
6 c=1480 g=1480 pq=1 pgp=1480 qp=0 dt=1037/1/0 df=6 of=0 ql=0 qs=.... kt=0/W/6 ktl=d2ad b=10 ci=0 co=0 ca=0
7 c=1474 g=1474 pq=1 pgp=1473 qp=0 dt=1572/0/0 df=8 of=0 ql=0 qs=.... kt=0/W/7 ktl=cf15 b=10 ci=0 co=0 ca=0
0!c=30455 g=30456 pq=1 qp=1 dt=126535/140000000000000/0 df=2002 of=4 ql=0/0 qs=N... b=10 ci=74572 nci=0 co=1131 ca=716
1!c=30719 g=30720 pq=1 qp=0 dt=132007/140000000000000/0 df=1874 of=10 ql=0/0 qs=N... b=10 ci=123209 nci=0 co=685 ca=982
2!c=30150 g=30151 pq=1 qp=1 dt=138537/140000000000000/0 df=1707 of=8 ql=0/0 qs=N... b=10 ci=80132 nci=0 co=1328 ca=1458
3 c=31249 g=31250 pq=1 qp=0 dt=107255/140000000000000/0 df=1749 of=6 ql=0/450 qs=NRW. b=10 ci=151700 nci=0 co=509 ca=622
4!c=29502 g=29503 pq=1 qp=1 dt=83647/140000000000000/0 df=965 of=5 ql=0/0 qs=N... b=10 ci=65643 nci=0 co=1373 ca=1521
5 c=31201 g=31202 pq=1 qp=1 dt=70422/0/0 df=535 of=7 ql=0/0 qs=.... b=10 ci=58500 nci=0 co=764 ca=698
6!c=30253 g=30254 pq=1 qp=1 dt=95363/140000000000000/0 df=780 of=5 ql=0/0 qs=N... b=10 ci=100607 nci=0 co=1414 ca=1353
7 c=31178 g=31178 pq=1 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
The first section lists the rcu_data structures for rcu_sched, the second
for rcu_bh. Note that CONFIG_TREE_PREEMPT_RCU kernels will have an
additional section for rcu_preempt. Each section has one line per CPU,
or eight for this 8-CPU system. The fields are as follows:
This file has one line per CPU, or eight for this 8-CPU system.
The fields are as follows:
o The number at the beginning of each line is the CPU number.
CPUs numbers followed by an exclamation mark are offline,
@@ -64,11 +76,13 @@ o The number at the beginning of each line is the CPU number.
substantially larger than the number of actual CPUs.
o "c" is the count of grace periods that this CPU believes have
completed. Offlined CPUs and CPUs in dynticks idle mode may
lag quite a ways behind, for example, CPU 6 under "rcu_sched"
above, which has been offline through not quite 40,000 RCU grace
periods. It is not unusual to see CPUs lagging by thousands of
grace periods.
completed. Offlined CPUs and CPUs in dynticks idle mode may lag
quite a ways behind, for example, CPU 4 under "rcu_sched" above,
which has been offline through 16 RCU grace periods. It is not
unusual to see offline CPUs lagging by thousands of grace periods.
Note that although the grace-period number is an unsigned long,
it is printed out as a signed long to allow more human-friendly
representation near boot time.
o "g" is the count of grace periods that this CPU believes have
started. Again, offlined CPUs and CPUs in dynticks idle mode
@@ -84,30 +98,25 @@ o "pq" indicates that this CPU has passed through a quiescent state
CPU has not yet reported that fact, (2) some other CPU has not
yet reported for this grace period, or (3) both.
o "pgp" indicates which grace period the last-observed quiescent
state for this CPU corresponds to. This is important for handling
the race between CPU 0 reporting an extended dynticks-idle
quiescent state for CPU 1 and CPU 1 suddenly waking up and
reporting its own quiescent state. If CPU 1 was the last CPU
for the current grace period, then the CPU that loses this race
will attempt to incorrectly mark CPU 1 as having checked in for
the next grace period!
o "qp" indicates that RCU still expects a quiescent state from
this CPU. Offlined CPUs and CPUs in dyntick idle mode might
well have qp=1, which is OK: RCU is still ignoring them.
o "dt" is the current value of the dyntick counter that is incremented
when entering or leaving dynticks idle state, either by the
scheduler or by irq. This number is even if the CPU is in
dyntick idle mode and odd otherwise. The number after the first
"/" is the interrupt nesting depth when in dyntick-idle state,
or one greater than the interrupt-nesting depth otherwise.
The number after the second "/" is the NMI nesting depth.
when entering or leaving idle, either due to a context switch or
due to an interrupt. This number is even if the CPU is in idle
from RCU's viewpoint and odd otherwise. The number after the
first "/" is the interrupt nesting depth when in idle state,
or a large number added to the interrupt-nesting depth when
running a non-idle task. Some architectures do not accurately
count interrupt nesting when running in non-idle kernel context,
which can result in interesting anomalies such as negative
interrupt-nesting levels. The number after the second "/"
is the NMI nesting depth.
o "df" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being in
dynticks-idle state.
idle state.
o "of" is the number of times that some other CPU has forced a
quiescent state on behalf of this CPU due to this CPU being
@@ -120,9 +129,13 @@ o "of" is the number of times that some other CPU has forced a
error, so it makes sense to err conservatively.
o "ql" is the number of RCU callbacks currently residing on
this CPU. This is the total number of callbacks, regardless
of what state they are in (new, waiting for grace period to
start, waiting for grace period to end, ready to invoke).
this CPU. The first number is the number of "lazy" callbacks
that are known to RCU to only be freeing memory, and the number
after the "/" is the total number of callbacks, lazy or not.
These counters count callbacks regardless of what phase of
grace-period processing that they are in (new, waiting for
grace period to start, waiting for grace period to end, ready
to invoke).
o "qs" gives an indication of the state of the callback queue
with four characters:
@@ -150,6 +163,43 @@ o "qs" gives an indication of the state of the callback queue
If there are no callbacks in a given one of the above states,
the corresponding character is replaced by ".".
o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will
be deferred.
o "ci" is the number of RCU callbacks that have been invoked for
this CPU. Note that ci+nci+ql is the number of callbacks that have
been registered in absence of CPU-hotplug activity.
o "nci" is the number of RCU callbacks that have been offloaded from
this CPU. This will always be zero unless the kernel was built
with CONFIG_RCU_NOCB_CPU=y and the "rcu_nocbs=" kernel boot
parameter was specified.
o "co" is the number of RCU callbacks that have been orphaned due to
this CPU going offline. These orphaned callbacks have been moved
to an arbitrarily chosen online CPU.
o "ca" is the number of RCU callbacks that have been adopted by this
CPU due to other CPUs going offline. Note that ci+co-ca+ql is
the number of RCU callbacks registered on this CPU.
Kernels compiled with CONFIG_RCU_BOOST=y display the following from
/debug/rcu/rcu_preempt/rcudata:
0!c=12865 g=12866 pq=1 qp=1 dt=83113/140000000000000/0 df=288 of=11 ql=0/0 qs=N... kt=0/O ktl=944 b=10 ci=60709 nci=0 co=748 ca=871
1 c=14407 g=14408 pq=1 qp=0 dt=100679/140000000000000/0 df=378 of=7 ql=0/119 qs=NRW. kt=0/W ktl=9b6 b=10 ci=109740 nci=0 co=589 ca=485
2 c=14407 g=14408 pq=1 qp=0 dt=105486/0/0 df=90 of=9 ql=0/89 qs=NRW. kt=0/W ktl=c0c b=10 ci=83113 nci=0 co=533 ca=490
3 c=14407 g=14408 pq=1 qp=0 dt=107138/0/0 df=142 of=8 ql=0/188 qs=NRW. kt=0/W ktl=b96 b=10 ci=121114 nci=0 co=426 ca=290
4 c=14405 g=14406 pq=1 qp=1 dt=50238/0/0 df=706 of=7 ql=0/0 qs=.... kt=0/W ktl=812 b=10 ci=34929 nci=0 co=643 ca=114
5!c=14168 g=14169 pq=1 qp=0 dt=45465/140000000000000/0 df=161 of=11 ql=0/0 qs=N... kt=0/O ktl=b4d b=10 ci=47712 nci=0 co=677 ca=722
6 c=14404 g=14405 pq=1 qp=0 dt=59454/0/0 df=94 of=6 ql=0/0 qs=.... kt=0/W ktl=e57 b=10 ci=55597 nci=0 co=701 ca=811
7 c=14407 g=14408 pq=1 qp=1 dt=68850/0/0 df=31 of=8 ql=0/0 qs=.... kt=0/W ktl=14bd b=10 ci=77475 nci=0 co=508 ca=1042
This is similar to the output discussed above, but contains the following
additional fields:
o "kt" is the per-CPU kernel-thread state. The digit preceding
the first slash is zero if there is no work pending and 1
otherwise. The character between the first pair of slashes is
@@ -184,35 +234,51 @@ o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
This field is displayed only for CONFIG_RCU_BOOST kernels.
o "b" is the batch limit for this CPU. If more than this number
of RCU callbacks is ready to invoke, then the remainder will
be deferred.
o "ci" is the number of RCU callbacks that have been invoked for
this CPU. Note that ci+ql is the number of callbacks that have
been registered in absence of CPU-hotplug activity.
The output of "cat rcu/rcu_preempt/rcuexp" looks as follows:
o "co" is the number of RCU callbacks that have been orphaned due to
this CPU going offline. These orphaned callbacks have been moved
to an arbitrarily chosen online CPU.
s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872
o "ca" is the number of RCU callbacks that have been adopted due to
other CPUs going offline. Note that ci+co-ca+ql is the number of
RCU callbacks registered on this CPU.
These fields are as follows:
There is also an rcu/rcudata.csv file with the same information in
comma-separated-variable spreadsheet format.
o "s" is the starting sequence number.
o "d" is the ending sequence number. When the starting and ending
numbers differ, there is an expedited grace period in progress.
o "w" is the number of times that the sequence numbers have been
in danger of wrapping.
o "tf" is the number of times that contention has resulted in a
failure to begin an expedited grace period.
o "wd1" and "wd2" are the number of times that an attempt to
start an expedited grace period found that someone else had
completed an expedited grace period that satisfies the
attempted request. "Our work is done."
o "n" is number of times that contention was so great that
the request was demoted from an expedited grace period to
a normal grace period.
o "sc" is the number of times that the attempt to start a
new expedited grace period succeeded.
o "dt" is the number of times that we attempted to update
the "d" counter.
o "dl" is the number of times that we failed to update the "d"
counter.
o "dx" is the number of times that we succeeded in updating
the "d" counter.
The output of "cat rcu/rcugp" looks as follows:
The output of "cat rcu/rcu_preempt/rcugp" looks as follows:
rcu_sched: completed=33062 gpnum=33063
rcu_bh: completed=464 gpnum=464
completed=31249 gpnum=31250 age=1 max=18
Again, this output is for both "rcu_sched" and "rcu_bh". Note that
kernels built with CONFIG_TREE_PREEMPT_RCU will have an additional
"rcu_preempt" line. The fields are taken from the rcu_state structure,
and are as follows:
These fields are taken from the rcu_state structure, and are as follows:
o "completed" is the number of grace periods that have completed.
It is comparable to the "c" field from rcu/rcudata in that a
@@ -220,44 +286,42 @@ o "completed" is the number of grace periods that have completed.
that the corresponding RCU grace period has completed.
o "gpnum" is the number of grace periods that have started. It is
comparable to the "g" field from rcu/rcudata in that a CPU
whose "g" field matches the value of "gpnum" is aware that the
corresponding RCU grace period has started.
similarly comparable to the "g" field from rcu/rcudata in that
a CPU whose "g" field matches the value of "gpnum" is aware that
the corresponding RCU grace period has started.
If these two fields are equal (as they are for "rcu_bh" above),
then there is no grace period in progress, in other words, RCU
is idle. On the other hand, if the two fields differ (as they
do for "rcu_sched" above), then an RCU grace period is in progress.
If these two fields are equal, then there is no grace period
in progress, in other words, RCU is idle. On the other hand,
if the two fields differ (as they are above), then an RCU grace
period is in progress.
o "age" is the number of jiffies that the current grace period
has extended for, or zero if there is no grace period currently
in effect.
The output of "cat rcu/rcuhier" looks as follows, with very long lines:
o "max" is the age in jiffies of the longest-duration grace period
thus far.
c=6902 g=6903 s=2 jfq=3 j=72c7 nfqs=13142/nfqsng=0(13142) fqlh=6
1/1 ..>. 0:127 ^0
3/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
3/3f ..>. 0:5 ^0 2/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
rcu_bh:
c=-226 g=-226 s=1 jfq=-5701 j=72c7 nfqs=88/nfqsng=0(88) fqlh=0
0/1 ..>. 0:127 ^0
0/3 ..>. 0:35 ^0 0/0 ..>. 36:71 ^1 0/0 ..>. 72:107 ^2 0/0 ..>. 108:127 ^3
0/3f ..>. 0:5 ^0 0/3 ..>. 6:11 ^1 0/0 ..>. 12:17 ^2 0/0 ..>. 18:23 ^3 0/0 ..>. 24:29 ^4 0/0 ..>. 30:35 ^5 0/0 ..>. 36:41 ^0 0/0 ..>. 42:47 ^1 0/0 ..>. 48:53 ^2 0/0 ..>. 54:59 ^3 0/0 ..>. 60:65 ^4 0/0 ..>. 66:71 ^5 0/0 ..>. 72:77 ^0 0/0 ..>. 78:83 ^1 0/0 ..>. 84:89 ^2 0/0 ..>. 90:95 ^3 0/0 ..>. 96:101 ^4 0/0 ..>. 102:107 ^5 0/0 ..>. 108:113 ^0 0/0 ..>. 114:119 ^1 0/0 ..>. 120:125 ^2 0/0 ..>. 126:127 ^3
The output of "cat rcu/rcu_preempt/rcuhier" looks as follows:
This is once again split into "rcu_sched" and "rcu_bh" portions,
and CONFIG_TREE_PREEMPT_RCU kernels will again have an additional
"rcu_preempt" section. The fields are as follows:
c=14407 g=14408 s=0 jfq=2 j=c863 nfqs=12040/nfqsng=0(12040) fqlh=1051 oqlen=0/0
3/3 ..>. 0:7 ^0
e/e ..>. 0:3 ^0 d/d ..>. 4:7 ^1
o "c" is exactly the same as "completed" under rcu/rcugp.
The fields are as follows:
o "g" is exactly the same as "gpnum" under rcu/rcugp.
o "c" is exactly the same as "completed" under rcu/rcu_preempt/rcugp.
o "s" is the "signaled" state that drives force_quiescent_state()'s
o "g" is exactly the same as "gpnum" under rcu/rcu_preempt/rcugp.
o "s" is the current state of the force_quiescent_state()
state machine.
o "jfq" is the number of jiffies remaining for this grace period
before force_quiescent_state() is invoked to help push things
along. Note that CPUs in dyntick-idle mode throughout the grace
period will not report on their own, but rather must be check by
some other CPU via force_quiescent_state().
along. Note that CPUs in idle mode throughout the grace period
will not report on their own, but rather must be check by some
other CPU via force_quiescent_state().
o "j" is the low-order four hex digits of the jiffies counter.
Yes, Paul did run into a number of problems that turned out to
@@ -268,7 +332,8 @@ o "nfqs" is the number of calls to force_quiescent_state() since
o "nfqsng" is the number of useless calls to force_quiescent_state(),
where there wasn't actually a grace period active. This can
happen due to races. The number in parentheses is the difference
no longer happen due to grace-period processing being pushed
into a kthread. The number in parentheses is the difference
between "nfqs" and "nfqsng", or the number of times that
force_quiescent_state() actually did some real work.
@@ -276,28 +341,27 @@ o "fqlh" is the number of calls to force_quiescent_state() that
exited immediately (without even being counted in nfqs above)
due to contention on ->fqslock.
o Each element of the form "1/1 0:127 ^0" represents one struct
rcu_node. Each line represents one level of the hierarchy, from
root to leaves. It is best to think of the rcu_data structures
as forming yet another level after the leaves. Note that there
might be either one, two, or three levels of rcu_node structures,
depending on the relationship between CONFIG_RCU_FANOUT and
CONFIG_NR_CPUS.
o Each element of the form "3/3 ..>. 0:7 ^0" represents one rcu_node
structure. Each line represents one level of the hierarchy,
from root to leaves. It is best to think of the rcu_data
structures as forming yet another level after the leaves.
Note that there might be either one, two, three, or even four
levels of rcu_node structures, depending on the relationship
between CONFIG_RCU_FANOUT, CONFIG_RCU_FANOUT_LEAF (possibly
adjusted using the rcu_fanout_leaf kernel boot parameter), and
CONFIG_NR_CPUS (possibly adjusted using the nr_cpu_ids count of
possible CPUs for the booting hardware).
o The numbers separated by the "/" are the qsmask followed
by the qsmaskinit. The qsmask will have one bit
set for each entity in the next lower level that
has not yet checked in for the current grace period.
set for each entity in the next lower level that has
not yet checked in for the current grace period ("e"
indicating CPUs 5, 6, and 7 in the example above).
The qsmaskinit will have one bit for each entity that is
currently expected to check in during each grace period.
The value of qsmaskinit is assigned to that of qsmask
at the beginning of each grace period.
For example, for "rcu_sched", the qsmask of the first
entry of the lowest level is 0x14, meaning that we
are still waiting for CPUs 2 and 4 to check in for the
current grace period.
o The characters separated by the ">" indicate the state
of the blocked-tasks lists. A "G" preceding the ">"
indicates that at least one task blocked in an RCU
@@ -312,48 +376,39 @@ o Each element of the form "1/1 0:127 ^0" represents one struct
A "." character appears if the corresponding condition
does not hold, so that "..>." indicates that no tasks
are blocked. In contrast, "GE>T" indicates maximal
inconvenience from blocked tasks.
inconvenience from blocked tasks. CONFIG_TREE_RCU
builds of the kernel will always show "..>.".
o The numbers separated by the ":" are the range of CPUs
served by this struct rcu_node. This can be helpful
in working out how the hierarchy is wired together.
For example, the first entry at the lowest level shows
"0:5", indicating that it covers CPUs 0 through 5.
For example, the example rcu_node structure shown above
has "0:7", indicating that it covers CPUs 0 through 7.
o The number after the "^" indicates the bit in the
next higher level rcu_node structure that this
rcu_node structure corresponds to.
For example, the first entry at the lowest level shows
"^0", indicating that it corresponds to bit zero in
the first entry at the middle level.
next higher level rcu_node structure that this rcu_node
structure corresponds to. For example, the "d/d ..>. 4:7
^1" has a "1" in this position, indicating that it
corresponds to the "1" bit in the "3" shown in the
"3/3 ..>. 0:7 ^0" entry on the next level up.
The output of "cat rcu/rcu_pending" looks as follows:
The output of "cat rcu/rcu_sched/rcu_pending" looks as follows:
rcu_sched:
0 np=255892 qsp=53936 rpq=85 cbr=0 cng=14417 gpc=10033 gps=24320 nn=146741
1 np=261224 qsp=54638 rpq=33 cbr=0 cng=25723 gpc=16310 gps=2849 nn=155792
2 np=237496 qsp=49664 rpq=23 cbr=0 cng=2762 gpc=45478 gps=1762 nn=136629
3 np=236249 qsp=48766 rpq=98 cbr=0 cng=286 gpc=48049 gps=1218 nn=137723
4 np=221310 qsp=46850 rpq=7 cbr=0 cng=26 gpc=43161 gps=4634 nn=123110
5 np=237332 qsp=48449 rpq=9 cbr=0 cng=54 gpc=47920 gps=3252 nn=137456
6 np=219995 qsp=46718 rpq=12 cbr=0 cng=50 gpc=42098 gps=6093 nn=120834
7 np=249893 qsp=49390 rpq=42 cbr=0 cng=72 gpc=38400 gps=17102 nn=144888
rcu_bh:
0 np=146741 qsp=1419 rpq=6 cbr=0 cng=6 gpc=0 gps=0 nn=145314
1 np=155792 qsp=12597 rpq=3 cbr=0 cng=0 gpc=4 gps=8 nn=143180
2 np=136629 qsp=18680 rpq=1 cbr=0 cng=0 gpc=7 gps=6 nn=117936
3 np=137723 qsp=2843 rpq=0 cbr=0 cng=0 gpc=10 gps=7 nn=134863
4 np=123110 qsp=12433 rpq=0 cbr=0 cng=0 gpc=4 gps=2 nn=110671
5 np=137456 qsp=4210 rpq=1 cbr=0 cng=0 gpc=6 gps=5 nn=133235
6 np=120834 qsp=9902 rpq=2 cbr=0 cng=0 gpc=6 gps=3 nn=110921
7 np=144888 qsp=26336 rpq=0 cbr=0 cng=0 gpc=8 gps=2 nn=118542
0!np=26111 qsp=29 rpq=5386 cbr=1 cng=570 gpc=3674 gps=577 nn=15903
1!np=28913 qsp=35 rpq=6097 cbr=1 cng=448 gpc=3700 gps=554 nn=18113
2!np=32740 qsp=37 rpq=6202 cbr=0 cng=476 gpc=4627 gps=546 nn=20889
3 np=23679 qsp=22 rpq=5044 cbr=1 cng=415 gpc=3403 gps=347 nn=14469
4!np=30714 qsp=4 rpq=5574 cbr=0 cng=528 gpc=3931 gps=639 nn=20042
5 np=28910 qsp=2 rpq=5246 cbr=0 cng=428 gpc=4105 gps=709 nn=18422
6!np=38648 qsp=5 rpq=7076 cbr=0 cng=840 gpc=4072 gps=961 nn=25699
7 np=37275 qsp=2 rpq=6873 cbr=0 cng=868 gpc=3416 gps=971 nn=25147
As always, this is once again split into "rcu_sched" and "rcu_bh"
portions, with CONFIG_TREE_PREEMPT_RCU kernels having an additional
"rcu_preempt" section. The fields are as follows:
The fields are as follows:
o The leading number is the CPU number, with "!" indicating
an offline CPU.
o "np" is the number of times that __rcu_pending() has been invoked
for the corresponding flavor of RCU.
@@ -377,38 +432,23 @@ o "gpc" is the number of times that an old grace period had
o "gps" is the number of times that a new grace period had started,
but this CPU was not yet aware of it.
o "nn" is the number of times that this CPU needed nothing. Alert
readers will note that the rcu "nn" number for a given CPU very
closely matches the rcu_bh "np" number for that same CPU. This
is due to short-circuit evaluation in rcu_pending().
The output of "cat rcu/rcutorture" looks as follows:
rcutorture test sequence: 0 (test in progress)
rcutorture update version number: 615
The first line shows the number of rcutorture tests that have completed
since boot. If a test is currently running, the "(test in progress)"
string will appear as shown above. The second line shows the number of
update cycles that the current test has started, or zero if there is
no test in progress.
o "nn" is the number of times that this CPU needed nothing.
The output of "cat rcu/rcuboost" looks as follows:
0:5 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=989 bt=0 nb=0 ny=0 nos=16
6:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=2f95 bt=300f
balk: nt=0 egt=225 bt=0 nb=0 ny=0 nos=6
0:3 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
balk: nt=0 egt=4695 bt=0 nb=0 ny=56 nos=0
4:7 tasks=.... kt=W ntb=0 neb=0 nnb=0 j=c864 bt=c894
balk: nt=0 egt=6541 bt=0 nb=0 ny=126 nos=0
This information is output only for rcu_preempt. Each two-line entry
corresponds to a leaf rcu_node strcuture. The fields are as follows:
o "n:m" is the CPU-number range for the corresponding two-line
entry. In the sample output above, the first entry covers
CPUs zero through five and the second entry covers CPUs 6
and 7.
CPUs zero through three and the second entry covers CPUs four
through seven.
o "tasks=TNEB" gives the state of the various segments of the
rnp->blocked_tasks list:

17
Documentation/RCU/whatisRCU.txt
View File

@@ -499,6 +499,8 @@ The foo_reclaim() function might appear as follows:
{
struct foo *fp = container_of(rp, struct foo, rcu);
foo_cleanup(fp->a);
kfree(fp);
}
@@ -521,6 +523,12 @@ o Use call_rcu() -after- removing a data element from an
read-side critical sections that might be referencing that
data item.
If the callback for call_rcu() is not doing anything more than calling
kfree() on the structure, you can use kfree_rcu() instead of call_rcu()
to avoid having to write your own callback:
kfree_rcu(old_fp, rcu);
Again, see checklist.txt for additional rules governing the use of RCU.
@@ -773,8 +781,8 @@ a single atomic update, converting to RCU will require special care.
Also, the presence of synchronize_rcu() means that the RCU version of
delete() can now block. If this is a problem, there is a callback-based
mechanism that never blocks, namely call_rcu(), that can be used in
place of synchronize_rcu().
mechanism that never blocks, namely call_rcu() or kfree_rcu(), that can
be used in place of synchronize_rcu().
7. FULL LIST OF RCU APIs
@@ -789,9 +797,7 @@ RCU list traversal:
list_for_each_entry_rcu
hlist_for_each_entry_rcu
hlist_nulls_for_each_entry_rcu
list_for_each_continue_rcu (to be deprecated in favor of new
list_for_each_entry_continue_rcu)
list_for_each_entry_continue_rcu
RCU pointer/list update:
@@ -813,6 +819,7 @@ RCU: Critical sections Grace period Barrier
rcu_read_unlock synchronize_rcu
rcu_dereference synchronize_rcu_expedited
call_rcu
kfree_rcu
bh: Critical sections Grace period Barrier

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