Kernel/linux-stable
1
0
Fork 0
mirror of https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git synced 2025-01-09 22:50:41 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'origin/x86/boot' into x86/mm2

Browse Source 
Coming patches to x86/mm2 require the changes and advanced baseline in
x86/boot.

Resolved Conflicts:
	arch/x86/kernel/setup.c
	mm/nobootmem.c

Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
This commit is contained in:
H. Peter Anvin 2013-01-29 14:59:09 -08:00
commit de65d816aa
11256 changed files with 524356 additions and 299996 deletions
Show Stats 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

5
CREDITS
View File

@ -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

2
Documentation/00-INDEX
View File

@ -136,8 +136,6 @@ 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/

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

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

3
Documentation/ABI/testing/ima_policy
View File

@ -23,7 +23,7 @@ Description:
lsm: [[subj_user=] [subj_role=] [subj_type=]
[obj_user=] [obj_role=] [obj_type=]]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK]
base: func:= [BPRM_CHECK][FILE_MMAP][FILE_CHECK][MODULE_CHECK]
mask:= [MAY_READ] [MAY_WRITE] [MAY_APPEND] [MAY_EXEC]
fsmagic:= hex value
uid:= decimal value
@ -53,6 +53,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,

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:

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>
-------------------------------------------------------------

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.

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.

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

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/

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.

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

@ -468,11 +468,46 @@ 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. Couple of example 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 +524,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 +539,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 +627,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 +715,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 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.

39
Documentation/DocBook/drm.tmpl
View File

@ -1141,23 +1141,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>
@ -1621,10 +1611,10 @@ void intel_crt_init(struct drm_device *dev)
</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 +2096,21 @@ 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
</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>
</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

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

@ -2586,6 +2586,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>

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,

188
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 linked="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>
@ -672,6 +831,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>
@ -743,6 +910,15 @@ should set this to 0.</entry>
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 +1099,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,7 +1108,7 @@ 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,
@ -964,6 +1140,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>

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

@ -543,6 +543,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>

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

@ -0,0 +1,212 @@
<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>
<section>
<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>
</section>
</refsect1>
<refsect1>
<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>

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

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>

56
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">

85
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);
@ -1058,14 +1057,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 +1111,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 +1191,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 +1455,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 +1605,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 +1616,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 +1647,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 +1898,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 +1937,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 +2104,7 @@
....
}
static int __devinit snd_mychip_new_pcm(struct mychip *chip)
static int snd_mychip_new_pcm(struct mychip *chip)
{
struct snd_pcm *pcm;
....
@ -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,

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."

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.

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

1
Documentation/accounting/getdelays.c
View File

@ -51,7 +51,6 @@ int dbg;
int print_delays;
int print_io_accounting;
int print_task_context_switch_counts;
__u64 stime, utime;
#define PRINTF(fmt, arg...) { \
if (dbg) { \

227
Documentation/acpi/enumeration.txt Normal file
View File

@ -0,0 +1,227 @@
ACPI based device enumeration
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ACPI 5 introduced a set of new resources (UartTSerialBus, I2cSerialBus,
SpiSerialBus, GpioIo and GpioInt) which can be used in enumerating slave
devices behind serial bus controllers.
In addition we are starting to see peripherals integrated in the
SoC/Chipset to appear only in ACPI namespace. These are typically devices
that are accessed through memory-mapped registers.
In order to support this and re-use the existing drivers as much as
possible we decided to do following:
o Devices that have no bus connector resource are represented as
platform devices.
o Devices behind real busses where there is a connector resource
are represented as struct spi_device or struct i2c_device
(standard UARTs are not busses so there is no struct uart_device).
As both ACPI and Device Tree represent a tree of devices (and their
resources) this implementation follows the Device Tree way as much as
possible.
The ACPI implementation enumerates devices behind busses (platform, SPI and
I2C), creates the physical devices and binds them to their ACPI handle in
the ACPI namespace.
This means that when ACPI_HANDLE(dev) returns non-NULL the device was
enumerated from ACPI namespace. This handle can be used to extract other
device-specific configuration. There is an example of this below.
Platform bus support
~~~~~~~~~~~~~~~~~~~~
Since we are using platform devices to represent devices that are not
connected to any physical bus we only need to implement a platform driver
for the device and add supported ACPI IDs. If this same IP-block is used on
some other non-ACPI platform, the driver might work out of the box or needs
some minor changes.
Adding ACPI support for an existing driver should be pretty
straightforward. Here is the simplest example:
#ifdef CONFIG_ACPI
static struct acpi_device_id mydrv_acpi_match[] = {
/* ACPI IDs here */
{ }
};
MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match);
#endif
static struct platform_driver my_driver = {
...
.driver = {
.acpi_match_table = ACPI_PTR(mydrv_acpi_match),
},
};
If the driver needs to perform more complex initialization like getting and
configuring GPIOs it can get its ACPI handle and extract this information
from ACPI tables.
Currently the kernel is not able to automatically determine from which ACPI
device it should make the corresponding platform device so we need to add
the ACPI device explicitly to acpi_platform_device_ids list defined in
drivers/acpi/scan.c. This limitation is only for the platform devices, SPI
and I2C devices are created automatically as described below.
SPI serial bus support
~~~~~~~~~~~~~~~~~~~~~~
Slave devices behind SPI bus have SpiSerialBus resource attached to them.
This is extracted automatically by the SPI core and the slave devices are
enumerated once spi_register_master() is called by the bus driver.
Here is what the ACPI namespace for a SPI slave might look like:
Device (EEP0)
{
Name (_ADR, 1)
Name (_CID, Package() {
"ATML0025",
"AT25",
})
...
Method (_CRS, 0, NotSerialized)
{
SPISerialBus(1, PolarityLow, FourWireMode, 8,
ControllerInitiated, 1000000, ClockPolarityLow,
ClockPhaseFirst, "\\_SB.PCI0.SPI1",)
}
...
The SPI device drivers only need to add ACPI IDs in a similar way than with
the platform device drivers. Below is an example where we add ACPI support
to at25 SPI eeprom driver (this is meant for the above ACPI snippet):
#ifdef CONFIG_ACPI
static struct acpi_device_id at25_acpi_match[] = {
{ "AT25", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, at25_acpi_match);
#endif
static struct spi_driver at25_driver = {
.driver = {
...
.acpi_match_table = ACPI_PTR(at25_acpi_match),
},
};
Note that this driver actually needs more information like page size of the
eeprom etc. but at the time writing this there is no standard way of
passing those. One idea is to return this in _DSM method like:
Device (EEP0)
{
...
Method (_DSM, 4, NotSerialized)
{
Store (Package (6)
{
"byte-len", 1024,
"addr-mode", 2,
"page-size, 32
}, Local0)
// Check UUIDs etc.
Return (Local0)
}
Then the at25 SPI driver can get this configation by calling _DSM on its
ACPI handle like:
struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL };
struct acpi_object_list input;
acpi_status status;
/* Fill in the input buffer */
status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM",
&input, &output);
if (ACPI_FAILURE(status))
/* Handle the error */
/* Extract the data here */
kfree(output.pointer);
I2C serial bus support
~~~~~~~~~~~~~~~~~~~~~~
The slaves behind I2C bus controller only need to add the ACPI IDs like
with the platform and SPI drivers. However the I2C bus controller driver
needs to call acpi_i2c_register_devices() after it has added the adapter.
An I2C bus (controller) driver does:
...
ret = i2c_add_numbered_adapter(adapter);
if (ret)
/* handle error */
of_i2c_register_devices(adapter);
/* Enumerate the slave devices behind this bus via ACPI */
acpi_i2c_register_devices(adapter);
Below is an example of how to add ACPI support to the existing mpu3050
input driver:
#ifdef CONFIG_ACPI
static struct acpi_device_id mpu3050_acpi_match[] = {
{ "MPU3050", 0 },
{ },
};
MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match);
#endif
static struct i2c_driver mpu3050_i2c_driver = {
.driver = {
.name = "mpu3050",
.owner = THIS_MODULE,
.pm = &mpu3050_pm,
.of_match_table = mpu3050_of_match,
.acpi_match_table ACPI_PTR(mpu3050_acpi_match),
},
.probe = mpu3050_probe,
.remove = mpu3050_remove,
.id_table = mpu3050_ids,
};
GPIO support
~~~~~~~~~~~~
ACPI 5 introduced two new resources to describe GPIO connections: GpioIo
and GpioInt. These resources are used be used to pass GPIO numbers used by
the device to the driver. For example:
Method (_CRS, 0, NotSerialized)
{
Name (SBUF, ResourceTemplate()
{
GpioIo (Exclusive, PullDefault, 0x0000, 0x0000,
IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0",
0x00, ResourceConsumer,,)
{
// Pin List
0x0055
}
...
Return (SBUF)
}
}
These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0"
specifies the path to the controller. In order to use these GPIOs in Linux
we need to translate them to the Linux GPIO numbers.
The driver can do this by including <linux/acpi_gpio.h> and then calling
acpi_get_gpio(path, gpio). This will return the Linux GPIO number or
negative errno if there was no translation found.
Other GpioIo parameters must be converted first by the driver to be
suitable to the gpiolib before passing them.
In case of GpioInt resource an additional call to gpio_to_irq() must be
done before calling request_irq().

94
Documentation/acpi/initrd_table_override.txt Normal file
View File

@ -0,0 +1,94 @@
Overriding ACPI tables via initrd
=================================
1) Introduction (What is this about)
2) What is this for
3) How does it work
4) References (Where to retrieve userspace tools)
1) What is this about
---------------------
If the ACPI_INITRD_TABLE_OVERRIDE compile option is true, it is possible to
override nearly any ACPI table provided by the BIOS with an instrumented,
modified one.
For a full list of ACPI tables that can be overridden, take a look at
the char *table_sigs[MAX_ACPI_SIGNATURE]; definition in drivers/acpi/osl.c
All ACPI tables iasl (Intel's ACPI compiler and disassembler) knows should
be overridable, except:
- ACPI_SIG_RSDP (has a signature of 6 bytes)
- ACPI_SIG_FACS (does not have an ordinary ACPI table header)
Both could get implemented as well.
2) What is this for
-------------------
Please keep in mind that this is a debug option.
ACPI tables should not get overridden for productive use.
If BIOS ACPI tables are overridden the kernel will get tainted with the
TAINT_OVERRIDDEN_ACPI_TABLE flag.
Complain to your platform/BIOS vendor if you find a bug which is so sever
that a workaround is not accepted in the Linux kernel.
Still, it can and should be enabled in any kernel, because:
- There is no functional change with not instrumented initrds
- It provides a powerful feature to easily debug and test ACPI BIOS table
compatibility with the Linux kernel.
3) How does it work
-------------------
# Extract the machine's ACPI tables:
cd /tmp
acpidump >acpidump
acpixtract -a acpidump
# Disassemble, modify and recompile them:
iasl -d *.dat
# For example add this statement into a _PRT (PCI Routing Table) function
# of the DSDT:
Store("HELLO WORLD", debug)
iasl -sa dsdt.dsl
# Add the raw ACPI tables to an uncompressed cpio archive.
# They must be put into a /kernel/firmware/acpi directory inside the
# cpio archive.
# The uncompressed cpio archive must be the first.
# Other, typically compressed cpio archives, must be
# concatenated on top of the uncompressed one.
mkdir -p kernel/firmware/acpi
cp dsdt.aml kernel/firmware/acpi
# A maximum of: #define ACPI_OVERRIDE_TABLES 10
# tables are currently allowed (see osl.c):
iasl -sa facp.dsl
iasl -sa ssdt1.dsl
cp facp.aml kernel/firmware/acpi
cp ssdt1.aml kernel/firmware/acpi
# Create the uncompressed cpio archive and concatenate the original initrd
# on top:
find kernel | cpio -H newc --create > /boot/instrumented_initrd
cat /boot/initrd >>/boot/instrumented_initrd
# reboot with increased acpi debug level, e.g. boot params:
acpi.debug_level=0x2 acpi.debug_layer=0xFFFFFFFF
# and check your syslog:
[ 1.268089] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 1.272091] [ACPI Debug] String [0x0B] "HELLO WORLD"
iasl is able to disassemble and recompile quite a lot different,
also static ACPI tables.
4) Where to retrieve userspace tools
------------------------------------
iasl and acpixtract are part of Intel's ACPICA project:
http://acpica.org/
and should be packaged by distributions (for example in the acpica package
on SUSE).
acpidump can be found in Len Browns pmtools:
ftp://kernel.org/pub/linux/kernel/people/lenb/acpi/utils/pmtools/acpidump
This tool is also part of the acpica package on SUSE.
Alternatively, used ACPI tables can be retrieved via sysfs in latest kernels:
/sys/firmware/acpi/tables

4
Documentation/aoe/aoe.txt
View File

@ -125,7 +125,9 @@ DRIVER OPTIONS
The aoe_deadsecs module parameter determines the maximum number of
seconds that the driver will wait for an AoE device to provide a
response to an AoE command. After aoe_deadsecs seconds have
elapsed, the AoE device will be marked as "down".
elapsed, the AoE device will be marked as "down". A value of zero
is supported for testing purposes and makes the aoe driver keep
trying AoE commands forever.
The aoe_maxout module parameter has a default of 128. This is the
maximum number of unresponded packets that will be sent to an AoE

10
Documentation/arm/OMAP/DSS
View File

@ -285,7 +285,10 @@ FB0 +-- GFX ---- LCD ---- LCD
Misc notes
----------
OMAP FB allocates the framebuffer memory using the OMAP VRAM allocator.
OMAP FB allocates the framebuffer memory using the standard dma allocator. You
can enable Contiguous Memory Allocator (CONFIG_CMA) to improve the dma
allocator, and if CMA is enabled, you use "cma=" kernel parameter to increase
the global memory area for CMA.
Using DSI DPLL to generate pixel clock it is possible produce the pixel clock
of 86.5MHz (max possible), and with that you get 1280x1024@57 output from DVI.
@ -301,11 +304,6 @@ framebuffer parameters.
Kernel boot arguments
---------------------
vram=<size>[,<physaddr>]
- Amount of total VRAM to preallocate and optionally a physical start
memory address. For example, "10M". omapfb allocates memory for
framebuffers from VRAM.
omapfb.mode=<display>:<mode>[,...]
- Default video mode for specified displays. For example,
"dvi:800x400MR-24@60". See drivers/video/modedb.c.

19
Documentation/arm/sunxi/README Normal file
View File

@ -0,0 +1,19 @@
ARM Allwinner SoCs
==================
This document lists all the ARM Allwinner SoCs that are currently
supported in mainline by the Linux kernel. This document will also
provide links to documentation and or datasheet for these SoCs.
SunXi family
------------
Flavors:
Allwinner A10 (sun4i)
Datasheet : http://dl.linux-sunxi.org/A10/A10%20Datasheet%20-%20v1.21%20%282012-04-06%29.pdf
Allwinner A13 (sun5i)
Datasheet : http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
Core: Cortex A8
Linux kernel mach directory: arch/arm/mach-sunxi

2
Documentation/arm64/memory.txt
View File

@ -41,7 +41,7 @@ ffffffbbffff0000 ffffffbcffffffff ~2MB [guard]
ffffffbffc000000 ffffffbfffffffff 64MB modules
ffffffc000000000 ffffffffffffffff 256GB memory
ffffffc000000000 ffffffffffffffff 256GB kernel logical memory map
Translation table lookup with 4KB pages:

10
Documentation/backlight/lp855x-driver.txt
View File

@ -35,11 +35,8 @@ For supporting platform specific data, the lp855x platform data can be used.
* mode : Brightness control mode. PWM or register based.
* device_control : Value of DEVICE CONTROL register.
* initial_brightness : Initial value of backlight brightness.
* pwm_data : Platform specific pwm generation functions.
* period_ns : Platform specific PWM period value. unit is nano.
Only valid when brightness is pwm input mode.
Functions should be implemented by PWM driver.
- pwm_set_intensity() : set duty of PWM
- pwm_get_intensity() : get current duty of PWM
* load_new_rom_data :
0 : use default configuration data
1 : update values of eeprom or eprom registers on loading driver
@ -71,8 +68,5 @@ static struct lp855x_platform_data lp8556_pdata = {
.mode = PWM_BASED,
.device_control = PWM_CONFIG(LP8556),
.initial_brightness = INITIAL_BRT,
.pwm_data = {
.pwm_set_intensity = platform_pwm_set_intensity,
.pwm_get_intensity = platform_pwm_get_intensity,
},
.period_ns = 1000000,
};

122
Documentation/bus-devices/ti-gpmc.txt Normal file
View File

@ -0,0 +1,122 @@
GPMC (General Purpose Memory Controller):
=========================================
GPMC is an unified memory controller dedicated to interfacing external
memory devices like
* Asynchronous SRAM like memories and application specific integrated
circuit devices.
* Asynchronous, synchronous, and page mode burst NOR flash devices
NAND flash
* Pseudo-SRAM devices
GPMC is found on Texas Instruments SoC's (OMAP based)
IP details: http://www.ti.com/lit/pdf/spruh73 section 7.1
GPMC generic timing calculation:
================================
GPMC has certain timings that has to be programmed for proper
functioning of the peripheral, while peripheral has another set of
timings. To have peripheral work with gpmc, peripheral timings has to
be translated to the form gpmc can understand. The way it has to be
translated depends on the connected peripheral. Also there is a
dependency for certain gpmc timings on gpmc clock frequency. Hence a
generic timing routine was developed to achieve above requirements.
Generic routine provides a generic method to calculate gpmc timings
from gpmc peripheral timings. struct gpmc_device_timings fields has to
be updated with timings from the datasheet of the peripheral that is
connected to gpmc. A few of the peripheral timings can be fed either
in time or in cycles, provision to handle this scenario has been
provided (refer struct gpmc_device_timings definition). It may so
happen that timing as specified by peripheral datasheet is not present
in timing structure, in this scenario, try to correlate peripheral
timing to the one available. If that doesn't work, try to add a new
field as required by peripheral, educate generic timing routine to
handle it, make sure that it does not break any of the existing.
Then there may be cases where peripheral datasheet doesn't mention
certain fields of struct gpmc_device_timings, zero those entries.
Generic timing routine has been verified to work properly on
multiple onenand's and tusb6010 peripherals.
A word of caution: generic timing routine has been developed based
on understanding of gpmc timings, peripheral timings, available
custom timing routines, a kind of reverse engineering without
most of the datasheets & hardware (to be exact none of those supported
in mainline having custom timing routine) and by simulation.
gpmc timing dependency on peripheral timings:
[<gpmc_timing>: <peripheral timing1>, <peripheral timing2> ...]
1. common
cs_on: t_ceasu
adv_on: t_avdasu, t_ceavd
2. sync common
sync_clk: clk
page_burst_access: t_bacc
clk_activation: t_ces, t_avds
3. read async muxed
adv_rd_off: t_avdp_r
oe_on: t_oeasu, t_aavdh
access: t_iaa, t_oe, t_ce, t_aa
rd_cycle: t_rd_cycle, t_cez_r, t_oez
4. read async non-muxed
adv_rd_off: t_avdp_r
oe_on: t_oeasu
access: t_iaa, t_oe, t_ce, t_aa
rd_cycle: t_rd_cycle, t_cez_r, t_oez
5. read sync muxed
adv_rd_off: t_avdp_r, t_avdh
oe_on: t_oeasu, t_ach, cyc_aavdh_oe
access: t_iaa, cyc_iaa, cyc_oe
rd_cycle: t_cez_r, t_oez, t_ce_rdyz
6. read sync non-muxed
adv_rd_off: t_avdp_r
oe_on: t_oeasu
access: t_iaa, cyc_iaa, cyc_oe
rd_cycle: t_cez_r, t_oez, t_ce_rdyz
7. write async muxed
adv_wr_off: t_avdp_w
we_on, wr_data_mux_bus: t_weasu, t_aavdh, cyc_aavhd_we
we_off: t_wpl
cs_wr_off: t_wph
wr_cycle: t_cez_w, t_wr_cycle
8. write async non-muxed
adv_wr_off: t_avdp_w
we_on, wr_data_mux_bus: t_weasu
we_off: t_wpl
cs_wr_off: t_wph
wr_cycle: t_cez_w, t_wr_cycle
9. write sync muxed
adv_wr_off: t_avdp_w, t_avdh
we_on, wr_data_mux_bus: t_weasu, t_rdyo, t_aavdh, cyc_aavhd_we
we_off: t_wpl, cyc_wpl
cs_wr_off: t_wph
wr_cycle: t_cez_w, t_ce_rdyz
10. write sync non-muxed
adv_wr_off: t_avdp_w
we_on, wr_data_mux_bus: t_weasu, t_rdyo
we_off: t_wpl, cyc_wpl
cs_wr_off: t_wph
wr_cycle: t_cez_w, t_ce_rdyz
Note: Many of gpmc timings are dependent on other gpmc timings (a few
gpmc timings purely dependent on other gpmc timings, a reason that
some of the gpmc timings are missing above), and it will result in
indirect dependency of peripheral timings to gpmc timings other than
mentioned above, refer timing routine for more details. To know what
these peripheral timings correspond to, please see explanations in
struct gpmc_device_timings definition. And for gpmc timings refer
IP details (link above).

8
Documentation/cgroups/00-INDEX
View File

@ -1,7 +1,11 @@
00-INDEX
- this file
blkio-controller.txt
- Description for Block IO Controller, implementation and usage details.
cgroups.txt
- Control Groups definition, implementation details, examples and API.
cgroup_event_listener.c
- A user program for cgroup listener.
cpuacct.txt
- CPU Accounting Controller; account CPU usage for groups of tasks.
cpusets.txt
@ -10,9 +14,13 @@ devices.txt
- Device Whitelist Controller; description, interface and security.
freezer-subsystem.txt
- checkpointing; rationale to not use signals, interface.
hugetlb.txt
- HugeTLB Controller implementation and usage details.
memcg_test.txt
- Memory Resource Controller; implementation details.
memory.txt
- Memory Resource Controller; design, accounting, interface, testing.
net_prio.txt
- Network priority cgroups details and usages.
resource_counter.txt
- Resource Counter API.

61
Documentation/cgroups/cgroups.txt
View File

@ -299,11 +299,9 @@ a cgroup hierarchy's release_agent path is empty.
1.5 What does clone_children do ?
---------------------------------
If the clone_children flag is enabled (1) in a cgroup, then all
cgroups created beneath will call the post_clone callbacks for each
subsystem of the newly created cgroup. Usually when this callback is
implemented for a subsystem, it copies the values of the parent
subsystem, this is the case for the cpuset.
This flag only affects the cpuset controller. If the clone_children
flag is enabled (1) in a cgroup, a new cpuset cgroup will copy its
configuration from the parent during initialization.
1.6 How do I use cgroups ?
--------------------------
@ -553,16 +551,16 @@ call to cgroup_unload_subsys(). It should also set its_subsys.module =
THIS_MODULE in its .c file.
Each subsystem may export the following methods. The only mandatory
methods are create/destroy. Any others that are null are presumed to
methods are css_alloc/free. Any others that are null are presumed to
be successful no-ops.
struct cgroup_subsys_state *create(struct cgroup *cgrp)
struct cgroup_subsys_state *css_alloc(struct cgroup *cgrp)
(cgroup_mutex held by caller)
Called to create a subsystem state object for a cgroup. The
Called to allocate a subsystem state object for a cgroup. The
subsystem should allocate its subsystem state object for the passed
cgroup, returning a pointer to the new object on success or a
negative error code. On success, the subsystem pointer should point to
ERR_PTR() value. On success, the subsystem pointer should point to
a structure of type cgroup_subsys_state (typically embedded in a
larger subsystem-specific object), which will be initialized by the
cgroup system. Note that this will be called at initialization to
@ -571,24 +569,33 @@ identified by the passed cgroup object having a NULL parent (since
it's the root of the hierarchy) and may be an appropriate place for
initialization code.
void destroy(struct cgroup *cgrp)
int css_online(struct cgroup *cgrp)
(cgroup_mutex held by caller)
The cgroup system is about to destroy the passed cgroup; the subsystem
should do any necessary cleanup and free its subsystem state
object. By the time this method is called, the cgroup has already been
unlinked from the file system and from the child list of its parent;
cgroup->parent is still valid. (Note - can also be called for a
newly-created cgroup if an error occurs after this subsystem's
create() method has been called for the new cgroup).
Called after @cgrp successfully completed all allocations and made
visible to cgroup_for_each_child/descendant_*() iterators. The
subsystem may choose to fail creation by returning -errno. This
callback can be used to implement reliable state sharing and
propagation along the hierarchy. See the comment on
cgroup_for_each_descendant_pre() for details.
int pre_destroy(struct cgroup *cgrp);
void css_offline(struct cgroup *cgrp);
Called before checking the reference count on each subsystem. This may
be useful for subsystems which have some extra references even if
there are not tasks in the cgroup. If pre_destroy() returns error code,
rmdir() will fail with it. From this behavior, pre_destroy() can be
called multiple times against a cgroup.
This is the counterpart of css_online() and called iff css_online()
has succeeded on @cgrp. This signifies the beginning of the end of
@cgrp. @cgrp is being removed and the subsystem should start dropping
all references it's holding on @cgrp. When all references are dropped,
cgroup removal will proceed to the next step - css_free(). After this
callback, @cgrp should be considered dead to the subsystem.
void css_free(struct cgroup *cgrp)
(cgroup_mutex held by caller)
The cgroup system is about to free @cgrp; the subsystem should free
its subsystem state object. By the time this method is called, @cgrp
is completely unused; @cgrp->parent is still valid. (Note - can also
be called for a newly-created cgroup if an error occurs after this
subsystem's create() method has been called for the new cgroup).
int can_attach(struct cgroup *cgrp, struct cgroup_taskset *tset)
(cgroup_mutex held by caller)
@ -635,14 +642,6 @@ void exit(struct task_struct *task)
Called during task exit.
void post_clone(struct cgroup *cgrp)
(cgroup_mutex held by caller)
Called during cgroup_create() to do any parameter
initialization which might be required before a task could attach. For
example, in cpusets, no task may attach before 'cpus' and 'mems' are set
up.
void bind(struct cgroup *root)
(cgroup_mutex held by caller)

2
Documentation/cgroups/cpusets.txt
View File

@ -218,7 +218,7 @@ and name space for cpusets, with a minimum of additional kernel code.
The cpus and mems files in the root (top_cpuset) cpuset are
read-only. The cpus file automatically tracks the value of
cpu_online_mask using a CPU hotplug notifier, and the mems file
automatically tracks the value of node_states[N_HIGH_MEMORY]--i.e.,
automatically tracks the value of node_states[N_MEMORY]--i.e.,
nodes with memory--using the cpuset_track_online_nodes() hook.

63
Documentation/cgroups/freezer-subsystem.txt
View File

@ -49,13 +49,49 @@ prevent the freeze/unfreeze cycle from becoming visible to the tasks
being frozen. This allows the bash example above and gdb to run as
expected.
The freezer subsystem in the container filesystem defines a file named
freezer.state. Writing "FROZEN" to the state file will freeze all tasks in the
cgroup. Subsequently writing "THAWED" will unfreeze the tasks in the cgroup.
Reading will return the current state.
The cgroup freezer is hierarchical. Freezing a cgroup freezes all
tasks beloning to the cgroup and all its descendant cgroups. Each
cgroup has its own state (self-state) and the state inherited from the
parent (parent-state). Iff both states are THAWED, the cgroup is
THAWED.
Note freezer.state doesn't exist in root cgroup, which means root cgroup
is non-freezable.
The following cgroupfs files are created by cgroup freezer.
* freezer.state: Read-write.
When read, returns the effective state of the cgroup - "THAWED",
"FREEZING" or "FROZEN". This is the combined self and parent-states.
If any is freezing, the cgroup is freezing (FREEZING or FROZEN).
FREEZING cgroup transitions into FROZEN state when all tasks
belonging to the cgroup and its descendants become frozen. Note that
a cgroup reverts to FREEZING from FROZEN after a new task is added
to the cgroup or one of its descendant cgroups until the new task is
frozen.
When written, sets the self-state of the cgroup. Two values are
allowed - "FROZEN" and "THAWED". If FROZEN is written, the cgroup,
if not already freezing, enters FREEZING state along with all its
descendant cgroups.
If THAWED is written, the self-state of the cgroup is changed to
THAWED. Note that the effective state may not change to THAWED if
the parent-state is still freezing. If a cgroup's effective state
becomes THAWED, all its descendants which are freezing because of
the cgroup also leave the freezing state.
* freezer.self_freezing: Read only.
Shows the self-state. 0 if the self-state is THAWED; otherwise, 1.
This value is 1 iff the last write to freezer.state was "FROZEN".
* freezer.parent_freezing: Read only.
Shows the parent-state. 0 if none of the cgroup's ancestors is
frozen; otherwise, 1.
The root cgroup is non-freezable and the above interface files don't
exist.
* Examples of usage :
@ -85,18 +121,3 @@ to unfreeze all tasks in the container :
This is the basic mechanism which should do the right thing for user space task
in a simple scenario.
It's important to note that freezing can be incomplete. In that case we return
EBUSY. This means that some tasks in the cgroup are busy doing something that
prevents us from completely freezing the cgroup at this time. After EBUSY,
the cgroup will remain partially frozen -- reflected by freezer.state reporting
"FREEZING" when read. The state will remain "FREEZING" until one of these
things happens:
1) Userspace cancels the freezing operation by writing "THAWED" to
the freezer.state file
2) Userspace retries the freezing operation by writing "FROZEN" to
the freezer.state file (writing "FREEZING" is not legal
and returns EINVAL)
3) The tasks that blocked the cgroup from entering the "FROZEN"
state disappear from the cgroup's set of tasks.

72
Documentation/cgroups/memory.txt
View File

@ -71,6 +71,11 @@ Brief summary of control files.
memory.oom_control # set/show oom controls.
memory.numa_stat # show the number of memory usage per numa node
memory.kmem.limit_in_bytes # set/show hard limit for kernel memory
memory.kmem.usage_in_bytes # show current kernel memory allocation
memory.kmem.failcnt # show the number of kernel memory usage hits limits
memory.kmem.max_usage_in_bytes # show max kernel memory usage recorded
memory.kmem.tcp.limit_in_bytes # set/show hard limit for tcp buf memory
memory.kmem.tcp.usage_in_bytes # show current tcp buf memory allocation
memory.kmem.tcp.failcnt # show the number of tcp buf memory usage hits limits
@ -144,9 +149,9 @@ Figure 1 shows the important aspects of the controller
3. Each page has a pointer to the page_cgroup, which in turn knows the
cgroup it belongs to
The accounting is done as follows: mem_cgroup_charge() is invoked to set up
the necessary data structures and check if the cgroup that is being charged
is over its limit. If it is, then reclaim is invoked on the cgroup.
The accounting is done as follows: mem_cgroup_charge_common() is invoked to
set up the necessary data structures and check if the cgroup that is being
charged is over its limit. If it is, then reclaim is invoked on the cgroup.
More details can be found in the reclaim section of this document.
If everything goes well, a page meta-data-structure called page_cgroup is
updated. page_cgroup has its own LRU on cgroup.
@ -268,20 +273,73 @@ the amount of kernel memory used by the system. Kernel memory is fundamentally
different than user memory, since it can't be swapped out, which makes it
possible to DoS the system by consuming too much of this precious resource.
Kernel memory won't be accounted at all until limit on a group is set. This
allows for existing setups to continue working without disruption. The limit
cannot be set if the cgroup have children, or if there are already tasks in the
cgroup. Attempting to set the limit under those conditions will return -EBUSY.
When use_hierarchy == 1 and a group is accounted, its children will
automatically be accounted regardless of their limit value.
After a group is first limited, it will be kept being accounted until it
is removed. The memory limitation itself, can of course be removed by writing
-1 to memory.kmem.limit_in_bytes. In this case, kmem will be accounted, but not
limited.
Kernel memory limits are not imposed for the root cgroup. Usage for the root
cgroup may or may not be accounted.
cgroup may or may not be accounted. The memory used is accumulated into
memory.kmem.usage_in_bytes, or in a separate counter when it makes sense.
(currently only for tcp).
The main "kmem" counter is fed into the main counter, so kmem charges will
also be visible from the user counter.
Currently no soft limit is implemented for kernel memory. It is future work
to trigger slab reclaim when those limits are reached.
2.7.1 Current Kernel Memory resources accounted
* stack pages: every process consumes some stack pages. By accounting into
kernel memory, we prevent new processes from being created when the kernel
memory usage is too high.
* slab pages: pages allocated by the SLAB or SLUB allocator are tracked. A copy
of each kmem_cache is created everytime the cache is touched by the first time
from inside the memcg. The creation is done lazily, so some objects can still be
skipped while the cache is being created. All objects in a slab page should
belong to the same memcg. This only fails to hold when a task is migrated to a
different memcg during the page allocation by the cache.
* sockets memory pressure: some sockets protocols have memory pressure
thresholds. The Memory Controller allows them to be controlled individually
per cgroup, instead of globally.
* tcp memory pressure: sockets memory pressure for the tcp protocol.
2.7.3 Common use cases
Because the "kmem" counter is fed to the main user counter, kernel memory can
never be limited completely independently of user memory. Say "U" is the user
limit, and "K" the kernel limit. There are three possible ways limits can be
set:
U != 0, K = unlimited:
This is the standard memcg limitation mechanism already present before kmem
accounting. Kernel memory is completely ignored.
U != 0, K < U:
Kernel memory is a subset of the user memory. This setup is useful in
deployments where the total amount of memory per-cgroup is overcommited.
Overcommiting kernel memory limits is definitely not recommended, since the
box can still run out of non-reclaimable memory.
In this case, the admin could set up K so that the sum of all groups is
never greater than the total memory, and freely set U at the cost of his
QoS.
U != 0, K >= U:
Since kmem charges will also be fed to the user counter and reclaim will be
triggered for the cgroup for both kinds of memory. This setup gives the
admin a unified view of memory, and it is also useful for people who just
want to track kernel memory usage.
3. User Interface
0. Configuration
@ -290,6 +348,7 @@ a. Enable CONFIG_CGROUPS
b. Enable CONFIG_RESOURCE_COUNTERS
c. Enable CONFIG_MEMCG
d. Enable CONFIG_MEMCG_SWAP (to use swap extension)
d. Enable CONFIG_MEMCG_KMEM (to use kmem extension)
1. Prepare the cgroups (see cgroups.txt, Why are cgroups needed?)
# mount -t tmpfs none /sys/fs/cgroup
@ -406,6 +465,11 @@ About use_hierarchy, see Section 6.
Because rmdir() moves all pages to parent, some out-of-use page caches can be
moved to the parent. If you want to avoid that, force_empty will be useful.
Also, note that when memory.kmem.limit_in_bytes is set the charges due to
kernel pages will still be seen. This is not considered a failure and the
write will still return success. In this case, it is expected that
memory.kmem.usage_in_bytes == memory.usage_in_bytes.
About use_hierarchy, see Section 6.
5.2 stat file

2
Documentation/cgroups/net_prio.txt
View File

@ -51,3 +51,5 @@ One usage for the net_prio cgroup is with mqprio qdisc allowing application
traffic to be steered to hardware/driver based traffic classes. These mappings
can then be managed by administrators or other networking protocols such as
DCBX.
A new net_prio cgroup inherits the parent's configuration.

7
Documentation/cgroups/resource_counter.txt
View File

@ -83,16 +83,17 @@ to work with it.
res_counter->lock internally (it must be called with res_counter->lock
held). The force parameter indicates whether we can bypass the limit.
e. void res_counter_uncharge[_locked]
e. u64 res_counter_uncharge[_locked]
(struct res_counter *rc, unsigned long val)
When a resource is released (freed) it should be de-accounted
from the resource counter it was accounted to. This is called
"uncharging".
"uncharging". The return value of this function indicate the amount
of charges still present in the counter.
The _locked routines imply that the res_counter->lock is taken.
f. void res_counter_uncharge_until
f. u64 res_counter_uncharge_until
(struct res_counter *rc, struct res_counter *top,
unsinged long val)

24
Documentation/cpu-hotplug.txt
View File

@ -207,6 +207,30 @@ by making it not-removable.
In such cases you will also notice that the online file is missing under cpu0.
Q: Is CPU0 removable on X86?
A: Yes. If kernel is compiled with CONFIG_BOOTPARAM_HOTPLUG_CPU0=y, CPU0 is
removable by default. Otherwise, CPU0 is also removable by kernel option
cpu0_hotplug.
But some features depend on CPU0. Two known dependencies are:
1. Resume from hibernate/suspend depends on CPU0. Hibernate/suspend will fail if
CPU0 is offline and you need to online CPU0 before hibernate/suspend can
continue.
2. PIC interrupts also depend on CPU0. CPU0 can't be removed if a PIC interrupt
is detected.
It's said poweroff/reboot may depend on CPU0 on some machines although I haven't
seen any poweroff/reboot failure so far after CPU0 is offline on a few tested
machines.
Please let me know if you know or see any other dependencies of CPU0.
If the dependencies are under your control, you can turn on CPU0 hotplug feature
either by CONFIG_BOOTPARAM_HOTPLUG_CPU0 or by kernel parameter cpu0_hotplug.
--Fenghua Yu <fenghua.yu@intel.com>
Q: How do i find out if a particular CPU is not removable?
A: Depending on the implementation, some architectures may show this by the
absence of the "online" file. This is done if it can be determined ahead of

3
Documentation/devices.txt
View File

@ -2561,9 +2561,6 @@ Your cooperation is appreciated.
192 = /dev/usb/yurex1 First USB Yurex device
...
209 = /dev/usb/yurex16 16th USB Yurex device
240 = /dev/usb/dabusb0 First daubusb device
...
243 = /dev/usb/dabusb3 Fourth dabusb device
180 block USB block devices
0 = /dev/uba First USB block device

11
Documentation/devicetree/bindings/arm/altera/socfpga-reset.txt Normal file
View File

@ -0,0 +1,11 @@
Altera SOCFPGA Reset Manager
Required properties:
- compatible : "altr,rst-mgr"
- reg : Should contain 1 register ranges(address and length)
Example:
rstmgr@ffd05000 {
compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>;
};

11
Documentation/devicetree/bindings/arm/altera/socfpga-system.txt Normal file
View File

@ -0,0 +1,11 @@
Altera SOCFPGA System Manager
Required properties:
- compatible : "altr,sys-mgr"
- reg : Should contain 1 register ranges(address and length)
Example:
sysmgr@ffd08000 {
compatible = "altr,sys-mgr";
reg = <0xffd08000 0x1000>;
};

4
Documentation/devicetree/bindings/arm/arm-boards
View File

@ -9,6 +9,10 @@ Required properties (in root node):
FPGA type interrupt controllers, see the versatile-fpga-irq binding doc.
In the root node the Integrator/CP must have a /cpcon node pointing
to the CP control registers, and the Integrator/AP must have a
/syscon node pointing to the Integrator/AP system controller.
ARM Versatile Application and Platform Baseboards
-------------------------------------------------

12
Documentation/devicetree/bindings/arm/armada-370-xp-mpic.txt
View File

@ -6,9 +6,15 @@ Required properties:
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: The number of cells to define the interrupts. Should be 1.
The cell is the IRQ number
- reg: Should contain PMIC registers location and length. First pair
for the main interrupt registers, second pair for the per-CPU
interrupt registers
interrupt registers. For this last pair, to be compliant with SMP
support, the "virtual" must be use (For the record, these registers
automatically map to the interrupt controller registers of the
current CPU)
Example:
@ -18,6 +24,6 @@ Example:
#address-cells = <1>;
#size-cells = <1>;
interrupt-controller;
reg = <0xd0020000 0x1000>,
<0xd0021000 0x1000>;
reg = <0xd0020a00 0x1d0>,
<0xd0021070 0x58>;
};

20
Documentation/devicetree/bindings/arm/armada-370-xp-pmsu.txt Normal file
View File

@ -0,0 +1,20 @@
Power Management Service Unit(PMSU)
-----------------------------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,armada-370-xp-pmsu"
- reg: Should contain PMSU registers location and length. First pair
for the per-CPU SW Reset Control registers, second pair for the
Power Management Service Unit.
Example:
armada-370-xp-pmsu@d0022000 {
compatible = "marvell,armada-370-xp-pmsu";
reg = <0xd0022100 0x430>,
<0xd0020800 0x20>;
};

1
Documentation/devicetree/bindings/arm/armada-370-xp-timer.txt
View File

@ -5,6 +5,7 @@ Required properties:
- compatible: Should be "marvell,armada-370-xp-timer"
- interrupts: Should contain the list of Global Timer interrupts
- reg: Should contain the base address of the Global Timer registers
- clocks: clock driving the timer hardware
Optional properties:
- marvell,timer-25Mhz: Tells whether the Global timer supports the 25

6
Documentation/devicetree/bindings/arm/atmel-at91.txt
View File

@ -7,6 +7,12 @@ PIT Timer required properties:
- interrupts: Should contain interrupt for the PIT which is the IRQ line
shared across all System Controller members.
System Timer (ST) required properties:
- compatible: Should be "atmel,at91rm9200-st"
- reg: Should contain registers location and length
- interrupts: Should contain interrupt for the ST which is the IRQ line
shared across all System Controller members.
TC/TCLIB Timer required properties:
- compatible: Should be "atmel,<chip>-tcb".
<chip> can be "at91rm9200" or "at91sam9x5"

9
Documentation/devicetree/bindings/arm/bcm/bcm11351.txt Normal file
View File

@ -0,0 +1,9 @@
Broadcom BCM11351 device tree bindings
-------------------------------------------
Boards with the bcm281xx SoC family (which includes bcm11130, bcm11140,
bcm11351, bcm28145, bcm28155 SoCs) shall have the following properties:
Required root node property:
compatible = "bcm,bcm11351";

13
Documentation/devicetree/bindings/arm/calxeda.txt
View File

@ -1,8 +1,15 @@
Calxeda Highbank Platforms Device Tree Bindings
Calxeda Platforms Device Tree Bindings
-----------------------------------------------
Boards with Calxeda Cortex-A9 based Highbank SOC shall have the following
properties.
Boards with Calxeda Cortex-A9 based ECX-1000 (Highbank) SOC shall have the
following properties.
Required root node properties:
- compatible = "calxeda,highbank";
Boards with Calxeda Cortex-A15 based ECX-2000 SOC shall have the following
properties.
Required root node properties:
- compatible = "calxeda,ecx-2000";

21
Documentation/devicetree/bindings/arm/coherency-fabric.txt Normal file
View File

@ -0,0 +1,21 @@
Coherency fabric
----------------
Available on Marvell SOCs: Armada 370 and Armada XP
Required properties:
- compatible: "marvell,coherency-fabric"
- reg: Should contain coherency fabric registers location and
length. First pair for the coherency fabric registers, second pair
for the per-CPU fabric registers registers.
Example:
coherency-fabric@d0020200 {
compatible = "marvell,coherency-fabric";
reg = <0xd0020200 0xb0>,
<0xd0021810 0x1c>;
};

77
Documentation/devicetree/bindings/arm/cpus.txt Normal file
View File

@ -0,0 +1,77 @@
* ARM CPUs binding description
The device tree allows to describe the layout of CPUs in a system through
the "cpus" node, which in turn contains a number of subnodes (ie "cpu")
defining properties for every cpu.
Bindings for CPU nodes follow the ePAPR standard, available from:
http://devicetree.org
For the ARM architecture every CPU node must contain the following properties:
- device_type: must be "cpu"
- reg: property matching the CPU MPIDR[23:0] register bits
reg[31:24] bits must be set to 0
- compatible: should be one of:
"arm,arm1020"
"arm,arm1020e"
"arm,arm1022"
"arm,arm1026"
"arm,arm720"
"arm,arm740"
"arm,arm7tdmi"
"arm,arm920"
"arm,arm922"
"arm,arm925"
"arm,arm926"
"arm,arm940"
"arm,arm946"
"arm,arm9tdmi"
"arm,cortex-a5"
"arm,cortex-a7"
"arm,cortex-a8"
"arm,cortex-a9"
"arm,cortex-a15"
"arm,arm1136"
"arm,arm1156"
"arm,arm1176"
"arm,arm11mpcore"
"faraday,fa526"
"intel,sa110"
"intel,sa1100"
"marvell,feroceon"
"marvell,mohawk"
"marvell,xsc3"
"marvell,xscale"
Example:
cpus {
#size-cells = <0>;
#address-cells = <1>;
CPU0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x0>;
};
CPU1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a15";
reg = <0x1>;
};
CPU2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x100>;
};
CPU3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a7";
reg = <0x101>;
};
};

17
Documentation/devicetree/bindings/arm/davinci.txt Normal file
View File

@ -0,0 +1,17 @@
Texas Instruments DaVinci Platforms Device Tree Bindings
--------------------------------------------------------
DA850/OMAP-L138/AM18x Evaluation Module (EVM) board
Required root node properties:
- compatible = "ti,da850-evm", "ti,da850";
EnBW AM1808 based CMC board
Required root node properties:
- compatible = "enbw,cmc", "ti,da850;
Generic DaVinci Boards
----------------------
DA850/OMAP-L138/AM18x generic board
Required root node properties:
- compatible = "ti,da850";

43
Documentation/devicetree/bindings/arm/davinci/nand.txt
View File

@ -23,29 +23,24 @@ Recommended properties :
- ti,davinci-nand-buswidth: buswidth 8 or 16
- ti,davinci-nand-use-bbt: use flash based bad block table support.
Example (enbw_cmc board):
aemif@60000000 {
compatible = "ti,davinci-aemif";
#address-cells = <2>;
#size-cells = <1>;
reg = <0x68000000 0x80000>;
ranges = <2 0 0x60000000 0x02000000
3 0 0x62000000 0x02000000
4 0 0x64000000 0x02000000
5 0 0x66000000 0x02000000
6 0 0x68000000 0x02000000>;
nand@3,0 {
compatible = "ti,davinci-nand";
reg = <3 0x0 0x807ff
6 0x0 0x8000>;
#address-cells = <1>;
#size-cells = <1>;
ti,davinci-chipselect = <1>;
ti,davinci-mask-ale = <0>;
ti,davinci-mask-cle = <0>;
ti,davinci-mask-chipsel = <0>;
ti,davinci-ecc-mode = "hw";
ti,davinci-ecc-bits = <4>;
ti,davinci-nand-use-bbt;
nand device bindings may contain additional sub-nodes describing
partitions of the address space. See partition.txt for more detail.
Example(da850 EVM ):
nand_cs3@62000000 {
compatible = "ti,davinci-nand";
reg = <0x62000000 0x807ff
0x68000000 0x8000>;
ti,davinci-chipselect = <1>;
ti,davinci-mask-ale = <0>;
ti,davinci-mask-cle = <0>;
ti,davinci-mask-chipsel = <0>;
ti,davinci-ecc-mode = "hw";
ti,davinci-ecc-bits = <4>;
ti,davinci-nand-use-bbt;
partition@180000 {
label = "ubifs";
reg = <0x180000 0x7e80000>;
};
};

15
Documentation/devicetree/bindings/arm/exynos/power_domain.txt
View File

@ -4,14 +4,13 @@ Exynos processors include support for multiple power domains which are used
to gate power to one or more peripherals on the processor.
Required Properties:
- compatiable: should be one of the following.
- compatible: should be one of the following.
* samsung,exynos4210-pd - for exynos4210 type power domain.
- reg: physical base address of the controller and length of memory mapped
region.
Optional Properties:
- samsung,exynos4210-pd-off: Specifies that the power domain is in turned-off
state during boot and remains to be turned-off until explicitly turned-on.
Node of a device using power domains must have a samsung,power-domain property
defined with a phandle to respective power domain.
Example:
@ -19,3 +18,11 @@ Example:
compatible = "samsung,exynos4210-pd";
reg = <0x10023C00 0x10>;
};
Example of the node using power domain:
node {
/* ... */
samsung,power-domain = <&lcd0>;
/* ... */
};

4
Documentation/devicetree/bindings/arm/fsl.txt
View File

@ -41,6 +41,10 @@ i.MX6 Quad SABRE Smart Device Board
Required root node properties:
- compatible = "fsl,imx6q-sabresd", "fsl,imx6q";
i.MX6 Quad SABRE Automotive Board
Required root node properties:
- compatible = "fsl,imx6q-sabreauto", "fsl,imx6q";
Generic i.MX boards
-------------------

11
Documentation/devicetree/bindings/arm/l2cc.txt
View File

@ -10,6 +10,12 @@ Required properties:
"arm,pl310-cache"
"arm,l220-cache"
"arm,l210-cache"
"marvell,aurora-system-cache": Marvell Controller designed to be
compatible with the ARM one, with system cache mode (meaning
maintenance operations on L1 are broadcasted to the L2 and L2
performs the same operation).
"marvell,"aurora-outer-cache: Marvell Controller designed to be
compatible with the ARM one with outer cache mode.
- cache-unified : Specifies the cache is a unified cache.
- cache-level : Should be set to 2 for a level 2 cache.
- reg : Physical base address and size of cache controller's memory mapped
@ -29,6 +35,9 @@ Optional properties:
filter. Addresses in the filter window are directed to the M1 port. Other
addresses will go to the M0 port.
- interrupts : 1 combined interrupt.
- cache-id-part: cache id part number to be used if it is not present
on hardware
- wt-override: If present then L2 is forced to Write through mode
Example:
@ -37,7 +46,7 @@ L2: cache-controller {
reg = <0xfff12000 0x1000>;
arm,data-latency = <1 1 1>;
arm,tag-latency = <2 2 2>;
arm,filter-latency = <0x80000000 0x8000000>;
arm,filter-ranges = <0x80000000 0x8000000>;
cache-unified;
cache-level = <2>;
interrupts = <45>;

15
Documentation/devicetree/bindings/arm/omap/counter.txt Normal file
View File

@ -0,0 +1,15 @@
OMAP Counter-32K bindings
Required properties:
- compatible: Must be "ti,omap-counter32k" for OMAP controllers
- reg: Contains timer register address range (base address and length)
- ti,hwmods: Name of the hwmod associated to the counter, which is typically
"counter_32k"
Example:
counter32k: counter@4a304000 {
compatible = "ti,omap-counter32k";
reg = <0x4a304000 0x20>;
ti,hwmods = "counter_32k";
};

31
Documentation/devicetree/bindings/arm/omap/timer.txt Normal file
View File

@ -0,0 +1,31 @@
OMAP Timer bindings
Required properties:
- compatible: Must be "ti,omap2-timer" for OMAP2+ controllers.
- reg: Contains timer register address range (base address and
length).
- interrupts: Contains the interrupt information for the timer. The
format is being dependent on which interrupt controller
the OMAP device uses.
- ti,hwmods: Name of the hwmod associated to the timer, "timer<X>",
where <X> is the instance number of the timer from the
HW spec.
Optional properties:
- ti,timer-alwon: Indicates the timer is in an alway-on power domain.
- ti,timer-dsp: Indicates the timer can interrupt the on-chip DSP in
addition to the ARM CPU.
- ti,timer-pwm: Indicates the timer can generate a PWM output.
- ti,timer-secure: Indicates the timer is reserved on a secure OMAP device
and therefore cannot be used by the kernel.
Example:
timer12: timer@48304000 {
compatible = "ti,omap2-timer";
reg = <0x48304000 0x400>;
interrupts = <95>;
ti,hwmods = "timer12"
ti,timer-alwon;
ti,timer-secure;
};

48
Documentation/devicetree/bindings/arm/spear/shirq.txt Normal file
View File

@ -0,0 +1,48 @@
* SPEAr Shared IRQ layer (shirq)
SPEAr3xx architecture includes shared/multiplexed irqs for certain set
of devices. The multiplexor provides a single interrupt to parent
interrupt controller (VIC) on behalf of a group of devices.
There can be multiple groups available on SPEAr3xx variants but not
exceeding 4. The number of devices in a group can differ, further they
may share same set of status/mask registers spanning across different
bit masks. Also in some cases the group may not have enable or other
registers. This makes software little complex.
A single node in the device tree is used to describe the shared
interrupt multiplexor (one node for all groups). A group in the
interrupt controller shares config/control registers with other groups.
For example, a 32-bit interrupt enable/disable config register can
accommodate upto 4 interrupt groups.
Required properties:
- compatible: should be, either of
- "st,spear300-shirq"
- "st,spear310-shirq"
- "st,spear320-shirq"
- interrupt-controller: Identifies the node as an interrupt controller.
- #interrupt-cells: should be <1> which basically contains the offset
(starting from 0) of interrupts for all the groups.
- reg: Base address and size of shirq registers.
- interrupts: The list of interrupts generated by the groups which are
then connected to a parent interrupt controller. Each group is
associated with one of the interrupts, hence number of interrupts (to
parent) is equal to number of groups. The format of the interrupt
specifier depends in the interrupt parent controller.
Optional properties:
- interrupt-parent: pHandle of the parent interrupt controller, if not
inherited from the parent node.
Example:
The following is an example from the SPEAr320 SoC dtsi file.
shirq: interrupt-controller@0xb3000000 {
compatible = "st,spear320-shirq";
reg = <0xb3000000 0x1000>;
interrupts = <28 29 30 1>;
#interrupt-cells = <1>;
interrupt-controller;
};

50
Documentation/devicetree/bindings/arm/vexpress-sysreg.txt Normal file
View File

@ -0,0 +1,50 @@
ARM Versatile Express system registers
--------------------------------------
This is a system control registers block, providing multiple low level
platform functions like board detection and identification, software
interrupt generation, MMC and NOR Flash control etc.
Required node properties:
- compatible value : = "arm,vexpress,sysreg";
- reg : physical base address and the size of the registers window
- gpio-controller : specifies that the node is a GPIO controller
- #gpio-cells : size of the GPIO specifier, should be 2:
- first cell is the pseudo-GPIO line number:
0 - MMC CARDIN
1 - MMC WPROT
2 - NOR FLASH WPn
- second cell can take standard GPIO flags (currently ignored).
Example:
v2m_sysreg: sysreg@10000000 {
compatible = "arm,vexpress-sysreg";
reg = <0x10000000 0x1000>;
gpio-controller;
#gpio-cells = <2>;
};
This block also can also act a bridge to the platform's configuration
bus via "system control" interface, addressing devices with site number,
position in the board stack, config controller, function and device
numbers - see motherboard's TRM for more details.
The node describing a config device must refer to the sysreg node via
"arm,vexpress,config-bridge" phandle (can be also defined in the node's
parent) and relies on the board topology properties - see main vexpress
node documentation for more details. It must must also define the
following property:
- arm,vexpress-sysreg,func : must contain two cells:
- first cell defines function number (eg. 1 for clock generator,
2 for voltage regulators etc.)
- device number (eg. osc 0, osc 1 etc.)
Example:
mcc {
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
arm,vexpress-sysreg,func = <1 0>;
};
};

98
Documentation/devicetree/bindings/arm/vexpress.txt
View File

@ -11,6 +11,10 @@ the motherboard file using a /include/ directive. As the motherboard
can be initialized in one of two different configurations ("memory
maps"), care must be taken to include the correct one.
Root node
---------
Required properties in the root node:
- compatible value:
compatible = "arm,vexpress,<model>", "arm,vexpress";
@ -45,6 +49,10 @@ Optional properties in the root node:
- Coretile Express A9x4 (V2P-CA9) HBI-0225:
arm,hbi = <0x225>;
CPU nodes
---------
Top-level standard "cpus" node is required. It must contain a node
with device_type = "cpu" property for every available core, eg.:
@ -59,6 +67,52 @@ with device_type = "cpu" property for every available core, eg.:
};
};
Configuration infrastructure
----------------------------
The platform has an elaborated configuration system, consisting of
microcontrollers residing on the mother- and daughterboards known
as Motherboard/Daughterboard Configuration Controller (MCC and DCC).
The controllers are responsible for the platform initialization
(reset generation, flash programming, FPGA bitfiles loading etc.)
but also control clock generators, voltage regulators, gather
environmental data like temperature, power consumption etc. Even
the video output switch (FPGA) is controlled that way.
Nodes describing devices controlled by this infrastructure should
point at the bridge device node:
- bridge phandle:
arm,vexpress,config-bridge = <phandle>;
This property can be also defined in a parent node (eg. for a DCC)
and is effective for all children.
Platform topology
-----------------
As Versatile Express can be configured in number of physically
different setups, the device tree should describe platform topology.
Root node and main motherboard node must define the following
property, describing physical location of the children nodes:
- site number:
arm,vexpress,site = <number>;
where 0 means motherboard, 1 or 2 are daugtherboard sites,
0xf means "master" site (site containing main CPU tile)
- when daughterboards are stacked on one site, their position
in the stack be be described with:
arm,vexpress,position = <number>;
- when describing tiles consisting more than one DCC, its number
can be described with:
arm,vexpress,dcc = <number>;
Any of the numbers above defaults to zero if not defined in
the node or any of its parent.
Motherboard
-----------
The motherboard description file provides a single "motherboard" node
using 2 address cells corresponding to the Static Memory Bus used
between the motherboard and the tile. The first cell defines the Chip
@ -87,22 +141,30 @@ can be used to obtain required phandle in the tile's "aliases" node:
- SP804 timers:
v2m_timer01 and v2m_timer23
Current Linux implementation requires a "arm,v2m_timer" alias
pointing at one of the motherboard's SP804 timers, if it is to be
used as the system timer. This alias should be defined in the
motherboard files.
The tile description should define a "smb" node, describing the
Static Memory Bus between the tile and motherboard. It must define
the following properties:
- "simple-bus" compatible value (to ensure creation of the children)
compatible = "simple-bus";
- mapping of the SMB CS/offset addresses into main address space:
#address-cells = <2>;
#size-cells = <1>;
ranges = <...>;
- interrupts mapping:
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
interrupt-map = <...>;
The tile description must define "ranges", "interrupt-map-mask" and
"interrupt-map" properties to translate the motherboard's address
and interrupt space into one used by the tile's processor.
Abbreviated example:
Example of a VE tile description (simplified)
---------------------------------------------
/dts-v1/;
/ {
model = "V2P-CA5s";
arm,hbi = <0x225>;
arm,vexpress,site = <0xf>;
compatible = "arm,vexpress-v2p-ca5s", "arm,vexpress";
interrupt-parent = <&gic>;
#address-cells = <1>;
@ -134,13 +196,29 @@ Abbreviated example:
<0x2c000100 0x100>;
};
motherboard {
dcc {
compatible = "simple-bus";
arm,vexpress,config-bridge = <&v2m_sysreg>;
osc@0 {
compatible = "arm,vexpress-osc";
};
};
smb {
compatible = "simple-bus";
#address-cells = <2>;
#size-cells = <1>;
/* CS0 is visible at 0x08000000 */
ranges = <0 0 0x08000000 0x04000000>;
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 63>;
/* Active high IRQ 0 is connected to GIC's SPI0 */
interrupt-map = <0 0 0 &gic 0 0 4>;
/include/ "vexpress-v2m-rs1.dtsi"
};
};
/include/ "vexpress-v2m-rs1.dtsi"

14
Documentation/devicetree/bindings/ata/exynos-sata-phy.txt Normal file
View File

@ -0,0 +1,14 @@
* Samsung SATA PHY Controller
SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers.
Each SATA PHY controller should have its own node.
Required properties:
- compatible : compatible list, contains "samsung,exynos5-sata-phy"
- reg : <registers mapping>
Example:
sata@ffe07000 {
compatible = "samsung,exynos5-sata-phy";
reg = <0xffe07000 0x1000>;
};

17
Documentation/devicetree/bindings/ata/exynos-sata.txt Normal file
View File

@ -0,0 +1,17 @@
* Samsung AHCI SATA Controller
SATA nodes are defined to describe on-chip Serial ATA controllers.
Each SATA controller should have its own node.
Required properties:
- compatible : compatible list, contains "samsung,exynos5-sata"
- interrupts : <interrupt mapping for SATA IRQ>
- reg : <registers mapping>
- samsung,sata-freq : <frequency in MHz>
Example:
sata@ffe08000 {
compatible = "samsung,exynos5-sata";
reg = <0xffe08000 0x1000>;
interrupts = <115>;
};

18
Documentation/devicetree/bindings/bus/omap-ocp2scp.txt
View File

@ -2,9 +2,27 @@
properties:
- compatible : Should be "ti,omap-ocp2scp"
- reg : Address and length of the register set for the device
- #address-cells, #size-cells : Must be present if the device has sub-nodes
- ranges : the child address space are mapped 1:1 onto the parent address space
- ti,hwmods : must be "ocp2scp_usb_phy"
Sub-nodes:
All the devices connected to ocp2scp are described using sub-node to ocp2scp
ocp2scp@4a0ad000 {
compatible = "ti,omap-ocp2scp";
reg = <0x4a0ad000 0x1f>;
#address-cells = <1>;
#size-cells = <1>;
ranges;
ti,hwmods = "ocp2scp_usb_phy";
subnode1 {
...
};
subnode2 {
...
};
};

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