brain-hackers_pepepper-mirror/linux-brain
1
0
Fork 0
mirror of https://github.com/brain-hackers/linux-brain.git synced 2024-06-09 07:16:21 +09:00
Code Issues Projects Releases Wiki Activity

Linux 4.4-rc1

Browse Source 
-----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1
 
 iQEcBAABAgAGBQJWSSq2AAoJEHm+PkMAQRiGIpQH/2Ro7UPwLARfZyd7GKpCRd/D
 y1aJEk9GaEywkGKPd/Hf3XU+/9vxqyTWhkvpKHkGAFqzuYvw2rSE1JZnGfA+dyt/
 1R/WSKM8f3VL2xmNmRJCXH+zn3W2u8Cvk0oj8VN0hseXByQfCT4HfoHiFrNwuo/9
 63f93Dqsai1G3CBy+/HSPEv5CGR+7yeTJFWS0hQK4kc3prmitI93C5PZkyePyAId
 wrgKo320rIcNL/lEAbMFEBimAqluIjGvdrR9FK6w3F+OwSlTV1HdSwTzNjxwdpP5
 aRKNHZMdsGlShsn12Wsp+mjVFpi9OrT8Askq+/GTDsG+9QMia/gUKC21K9b6UxM=
 =byS9
 -----END PGP SIGNATURE-----

Orangefs: Merge tag 'v4.4-rc1' into for-next

Linux 4.4-rc1
This commit is contained in:
Mike Marshall 2015-11-16 10:58:57 -05:00
commit a52079dad4
9821 changed files with 477715 additions and 236949 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.mailmap
View File

@ -59,6 +59,7 @@ James Bottomley <jejb@mulgrave.(none)>
James Bottomley <jejb@titanic.il.steeleye.com>
James E Wilson <wilson@specifix.com>
James Ketrenos <jketreno@io.(none)>
<javier@osg.samsung.com> <javier.martinez@collabora.co.uk>
Jean Tourrilhes <jt@hpl.hp.com>
Jeff Garzik <jgarzik@pretzel.yyz.us>
Jens Axboe <axboe@suse.de>

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-arvo → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-arvo
View File

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-isku → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-isku
View File

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

@ -1,3 +1,14 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
Date: October 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 actual
profile. This value is persistent, so its equivalent to the
profile that's active when the mouse is powered on next time.
When written, this file sets the number of the startup profile
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>/startup_profile
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -22,6 +33,40 @@ Description: When read, this file returns the raw integer version number of the
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>/info
Date: November 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.
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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store a macro with max 500 key/button strokes
internally.
When written, this file lets one set the sequence for a specific
button for a specific profile. Button and profile numbers are
included in written data. The data has to be 2082 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>/koneplus/roccatkoneplus<minor>/profile_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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 77 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -34,6 +79,22 @@ Description: The mouse can store 5 profiles which can be switched by the
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_settings
Date: October 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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -45,4 +106,40 @@ Description: The mouse can store 5 profiles which can be switched by the
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
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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse has a tracking- and a distance-control-unit. These
can be activated/deactivated and the lift-off distance can be
set. The data has to be 6 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>/koneplus/roccatkoneplus<minor>/talk
Date: May 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: Used to active some easy* functions of the mouse from outside.
The data has to be 16 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>/koneplus/roccatkoneplus<minor>/tcu
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. 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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read the mouse returns a 30x30 pixel image of the
sampled underground. This works only in the course of a
calibration process initiated with tcu.
The returned data is 1028 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-konepure → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-konepure
View File

50
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-kovaplus
View File

@ -8,6 +8,17 @@ Description: The integer value of this attribute ranges from 1-4.
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_profile
Date: January 2011
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 active
profile.
When written, the mouse activates this profile immediately.
The profile that's active when powered down is the same that's
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
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -40,6 +51,29 @@ Description: When read, this file returns the raw integer version number of the
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>/info
Date: November 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 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
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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 23 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_buttons
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -52,6 +86,22 @@ Description: The mouse can store 5 profiles which can be switched by the
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_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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 16 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_settings
Date: January 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-lua → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-lua
View File

50
Documentation/ABI/obsolete/sysfs-driver-hid-roccat-pyra
View File

@ -37,6 +37,29 @@ Description: When read, this file returns the raw integer version number of the
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>/info
Date: November 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 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_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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_buttons
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -49,6 +72,22 @@ Description: The mouse can store 5 profiles which can be switched by the
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_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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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[1-5]_settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
@ -62,6 +101,17 @@ Description: The mouse can store 5 profiles which can be switched by the
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>/settings
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the settings stored in the mouse.
The size of the data is 3 bytes and holds information on the
startup_profile.
When written, this file lets write settings back to the mouse.
The data has to be 3 bytes long. The mouse will reject invalid
data.
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>

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-ryos → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-ryos
View File

0
Documentation/ABI/testing/sysfs-driver-hid-roccat-savu → Documentation/ABI/obsolete/sysfs-driver-hid-roccat-savu
View File

4
Documentation/ABI/stable/sysfs-class-tpm
View File

@ -116,7 +116,7 @@ Description: The "pubek" property will return the TPM's public endorsement
owner's authorization. Since the TPM driver doesn't store any
secrets, it can't authorize its own request for the pubek,
making it unaccessible. The public endorsement key is gener-
ated at TPM menufacture time and exists for the life of the
ated at TPM manufacture time and exists for the life of the
chip.
Example output:
@ -163,7 +163,7 @@ Date: April 2006
KernelVersion: 2.6.17
Contact: tpmdd-devel@lists.sf.net
Description: The "temp_deactivated" property returns a '1' if the chip has
been temporarily dectivated, usually until the next power
been temporarily deactivated, usually until the next power
cycle. Whether a warm boot (reboot) will clear a TPM chip
from a temp_deactivated state is platform specific.

2
Documentation/ABI/stable/sysfs-firmware-opal-elog
View File

@ -57,4 +57,4 @@ Description:
Shortly after acknowledging it, the log
entry will be removed from sysfs.
Reading this file will list the supported
operations (curently just acknowledge).
operations (currently just acknowledge).

48
Documentation/ABI/testing/configfs-stp-policy Normal file
View File

@ -0,0 +1,48 @@
What: /config/stp-policy
Date: June 2015
KernelVersion: 4.3
Description:
This group contains policies mandating Master/Channel allocation
for software sources wishing to send trace data over an STM
device.
What: /config/stp-policy/<device>.<policy>
Date: June 2015
KernelVersion: 4.3
Description:
This group is the root of a policy; its name is a concatenation
of an stm device name to which this policy applies and an
arbitrary string. If <device> part doesn't match an existing
stm device, mkdir will fail with ENODEV; if that device already
has a policy assigned to it, mkdir will fail with EBUSY.
What: /config/stp-policy/<device>.<policy>/device
Date: June 2015
KernelVersion: 4.3
Description:
STM device to which this policy applies, read only. Same as the
<device> component of its parent directory.
What: /config/stp-policy/<device>.<policy>/<node>
Date: June 2015
KernelVersion: 4.3
Description:
Policy node is a string identifier that software clients will
use to request a master/channel to be allocated and assigned to
them.
What: /config/stp-policy/<device>.<policy>/<node>/masters
Date: June 2015
KernelVersion: 4.3
Description:
Range of masters from which to allocate for users of this node.
Write two numbers: the first master and the last master number.
What: /config/stp-policy/<device>.<policy>/<node>/channels
Date: June 2015
KernelVersion: 4.3
Description:
Range of channels from which to allocate for users of this node.
Write two numbers: the first channel and the last channel
number.

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

@ -60,6 +60,13 @@ Description:
Indicates whether a storage device is capable of storing
integrity metadata. Set if the device is T10 PI-capable.
What: /sys/block/<disk>/integrity/protection_interval_bytes
Date: July 2015
Contact: Martin K. Petersen <martin.petersen@oracle.com>
Description:
Describes the number of data bytes which are protected
by one integrity tuple. Typically the device's logical
block size.
What: /sys/block/<disk>/integrity/write_generate
Date: June 2008

83
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
View File

@ -8,13 +8,6 @@ Description: (RW) Enable/disable tracing on this specific trace entiry.
of coresight components linking the source to the sink is
configured and managed automatically by the coresight framework.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/status
Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (R) List various control and status registers. The specific
layout and content is driver specific.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/addr_idx
Date: November 2014
KernelVersion: 3.19
@ -251,3 +244,79 @@ Date: November 2014
KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Define the event that controls the trigger.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/cpu
Date: October 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Holds the cpu number this tracer is affined to.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Configuration Code register
(0x004). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmccer
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Configuration Code Extension
register (0x1e8). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmscr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM System Configuration
register (0x014). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmidr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM ID register (0x1e4). The
value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmcr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Main Control register (0x000).
The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtraceidr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Trace ID register (0x200).
The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmteevr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Trace Enable Event register
(0x020). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtsscr
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Trace Start/Stop Conrol
register (0x018). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr1
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Enable Conrol #1
register (0x024). The value is read directly from the HW.
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/mgmt/etmtecr2
Date: September 2015
KernelVersion: 4.4
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RO) Print the content of the ETM Enable Conrol #2
register (0x01c). The value is read directly from the HW.

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

@ -581,6 +581,7 @@ What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_supply_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_voltageY_thresh_falling_en
What: /sys/.../iio:deviceX/events/in_voltageY_thresh_either_en
What: /sys/.../iio:deviceX/events/in_tempY_thresh_rising_en
What: /sys/.../iio:deviceX/events/in_tempY_thresh_falling_en
KernelVersion: 2.6.37
@ -1459,3 +1460,34 @@ Description:
measurements and return the average value as output data. Each
value resulted from <type>[_name]_oversampling_ratio measurements
is considered as one sample for <type>[_name]_sampling_frequency.
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_co2_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_co2_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_voc_raw
What: /sys/bus/iio/devices/iio:deviceX/in_concentrationX_voc_raw
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) percentage reading of a substance.
What: /sys/bus/iio/devices/iio:deviceX/in_resistance_raw
What: /sys/bus/iio/devices/iio:deviceX/in_resistanceX_raw
What: /sys/bus/iio/devices/iio:deviceX/out_resistance_raw
What: /sys/bus/iio/devices/iio:deviceX/out_resistanceX_raw
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) resistance reading that can be processed
into an ohm value.
What: /sys/bus/iio/devices/iio:deviceX/heater_enable
KernelVersion: 4.1.0
Contact: linux-iio@vger.kernel.org
Description:
'1' (enable) or '0' (disable) specifying the enable
of heater function. Same reading values apply
This ABI is especially applicable for humidity sensors
to heatup the device and get rid of any condensation
in some humidity environment

43
Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435 Normal file
View File

@ -0,0 +1,43 @@
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_sensing_mode
Date: August 2015
KernelVersion: 4.2.0
Contact: source@cogentembedded.com
Description:
Program sensor type for threshold detector inputs.
Could be either "GND-Open" or "Supply-Open" mode. Y is a
threshold detector input channel. Channels 0..7, 8..15, 16..23
and 24..31 has common sensor types.
What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_falling_value
Date: August 2015
KernelVersion: 4.2.0
Contact: source@cogentembedded.com
Description:
Channel Y low voltage threshold. If sensor input voltage goes lower then
this value then the threshold falling event is pushed.
Depending on in_voltageY_sensing_mode the low voltage threshold
is separately set for "GND-Open" and "Supply-Open" modes.
Channels 0..31 have common low threshold values, but could have different
sensing_modes.
The low voltage threshold range is between 2..21V.
Hysteresis between low and high thresholds can not be lower then 2 and
can not be odd.
If falling threshold results hysteresis to odd value then rising
threshold is automatically subtracted by one.
What: /sys/bus/iio/devices/iio:deviceX/events/in_voltageY_thresh_rising_value
Date: August 2015
KernelVersion: 4.2.0
Contact: source@cogentembedded.com
Description:
Channel Y high voltage threshold. If sensor input voltage goes higher then
this value then the threshold rising event is pushed.
Depending on in_voltageY_sensing_mode the high voltage threshold
is separately set for "GND-Open" and "Supply-Open" modes.
Channels 0..31 have common high threshold values, but could have different
sensing_modes.
The high voltage threshold range is between 3..22V.
Hysteresis between low and high thresholds can not be lower then 2 and
can not be odd.
If rising threshold results hysteresis to odd value then falling
threshold is automatically appended by one.

7
Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x Normal file
View File

@ -0,0 +1,7 @@
What: /sys/bus/iio/devices/iio:deviceX/in_concentration_VOC_short_raw
Date: September 2015
KernelVersion: 4.3
Contact: Matt Ranostay <mranostay@gmail.com>
Description:
Get the raw calibration VOC value from the sensor.
This value has little application outside of calibration.

9
Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x Normal file
View File

@ -0,0 +1,9 @@
What: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw
What: /sys/bus/iio/devices/iio:deviceX/out_current_heater_raw_available
KernelVersion: 4.3
Contact: linux-iio@vger.kernel.org
Description:
Controls the heater device within the humidity sensor to get
rid of excess condensation.
Valid control values are 0 = OFF, and 1 = ON.

8
Documentation/ABI/testing/sysfs-bus-iio-meas-spec Normal file
View File

@ -0,0 +1,8 @@
What: /sys/bus/iio/devices/iio:deviceX/battery_low
KernelVersion: 4.1.0
Contact: linux-iio@vger.kernel.org
Description:
Reading returns either '1' or '0'. '1' means that the
battery level supplied to sensor is below 2.25V.
This ABI is available for tsys02d, htu21, ms8607
This ABI is available for htu21, ms8607

22
Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
View File

@ -18,3 +18,25 @@ Description:
trigger. In order to associate the trigger with an IIO device
one should write this name string to
/sys/bus/iio/devices/iio:deviceY/trigger/current_trigger.
What: /sys/bus/iio/devices/iio_sysfs_trigger/add_trigger
KernelVersion: 2.6.39
Contact: linux-iio@vger.kernel.org
Description:
This attribute is provided by the iio-trig-sysfs stand-alone
driver and it is used to activate the creation of a new trigger.
In order to achieve this, one should write a positive integer
into the associated file, which will serve as the id of the
trigger. If the trigger with the specified id is already present
in the system, an invalid argument message will be returned.
What: /sys/bus/iio/devices/iio_sysfs_trigger/remove_trigger
KernelVersion: 2.6.39
Contact: linux-iio@vger.kernel.org
Description:
This attribute is used to unregister and delete a previously
created trigger from the list of available triggers. In order to
achieve this, one should write a positive integer into the
associated file, representing the id of the trigger that needs
to be removed. If the trigger can't be found, an invalid
argument message will be returned to the user.

49
Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth Normal file
View File

@ -0,0 +1,49 @@
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/masters/*
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure output ports for STP masters. Writing -1
disables a master; any
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_port
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RO) Output port type:
0: not present,
1: MSU (Memory Storage Unit)
2: CTP (Common Trace Port)
4: PTI (MIPI PTI).
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_drop
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Data retention policy setting: keep (0) or drop (1)
incoming data while output port is in reset.
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_null
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) STP NULL packet generation: enabled (1) or disabled (0).
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_flush
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Force flush data from byte packing buffer for the output
port.
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_reset
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RO) Output port is in reset (1).
What: /sys/bus/intel_th/devices/<intel_th_id>-gth/outputs/[0-7]_smcfreq
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) STP sync packet frequency for the port. Specifies the
number of clocks between mainenance packets.

33
Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc Normal file
View File

@ -0,0 +1,33 @@
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/wrap
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure MSC buffer wrapping. 1 == wrapping enabled.
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/mode
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure MSC operating mode:
- "single", for contiguous buffer mode (high-order alloc);
- "multi", for multiblock mode;
- "ExI", for DCI handler mode;
- "debug", for debug mode.
If operating mode changes, existing buffer is deallocated,
provided there are no active users and tracing is not enabled,
otherwise the write will fail.
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/nr_pages
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure MSC buffer size for "single" or "multi" modes.
In single mode, this is a single number of pages, has to be
power of 2. In multiblock mode, this is a comma-separated list
of numbers of pages for each window to be allocated. Number of
windows is not limited.
Writing to this file deallocates existing buffer (provided
there are no active users and tracing is not enabled) and then
allocates a new one.

24
Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti Normal file
View File

@ -0,0 +1,24 @@
What: /sys/bus/intel_th/devices/<intel_th_id>-pti/mode
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure PTI output width. Currently supported values
are 4, 8, 12, 16.
What: /sys/bus/intel_th/devices/<intel_th_id>-pti/freerunning_clock
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) 0: PTI trace clock acts as a strobe which only toggles
when there is trace data to send. 1: PTI trace clock is a
free-running clock.
What: /sys/bus/intel_th/devices/<intel_th_id>-pti/clock_divider
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Configure PTI port clock divider:
- 0: Intel TH clock rate,
- 1: 1/2 Intel TH clock rate,
- 2: 1/4 Intel TH clock rate,
- 3: 1/8 Intel TH clock rate.

13
Documentation/ABI/testing/sysfs-bus-intel_th-output-devices Normal file
View File

@ -0,0 +1,13 @@
What: /sys/bus/intel_th/devices/<intel_th_id>-<device><id>/active
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RW) Writes of 1 or 0 enable or disable trace output to this
output device. Reads return current status.
What: /sys/bus/intel_th/devices/<intel_th_id>-msc<msc-id>/port
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description: (RO) Port number, corresponding to this output device on the
switch (GTH).

7
Documentation/ABI/testing/sysfs-bus-mei
View File

@ -19,3 +19,10 @@ KernelVersion: 4.2
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client device uuid
Format: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
What: /sys/bus/mei/devices/.../version
Date: Aug 2015
KernelVersion: 4.3
Contact: Tomas Winkler <tomas.winkler@intel.com>
Description: Stores mei client protocol version
Format: %d

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

@ -1,3 +1,23 @@
What: /sys/bus/usb/devices/INTERFACE/authorized
Date: August 2015
Description:
This allows to authorize (1) or deauthorize (0)
individual interfaces instead a whole device
in contrast to the device authorization.
If a deauthorized interface will be authorized
so the driver probing must be triggered manually
by writing INTERFACE to /sys/bus/usb/drivers_probe
This allows to avoid side-effects with drivers
that need multiple interfaces.
A deauthorized interface cannot be probed or claimed.
What: /sys/bus/usb/devices/usbX/interface_authorized_default
Date: August 2015
Description:
This is used as value that determines if interfaces
would be authorized by default.
The value can be 1 or 0. It's by default 1.
What: /sys/bus/usb/device/.../authorized
Date: July 2008
KernelVersion: 2.6.26

37
Documentation/ABI/testing/sysfs-class-fpga-manager Normal file
View File

@ -0,0 +1,37 @@
What: /sys/class/fpga_manager/<fpga>/name
Date: August 2015
KernelVersion: 4.3
Contact: Alan Tull <atull@opensource.altera.com>
Description: Name of low level fpga manager driver.
What: /sys/class/fpga_manager/<fpga>/state
Date: August 2015
KernelVersion: 4.3
Contact: Alan Tull <atull@opensource.altera.com>
Description: Read fpga manager state as a string.
The intent is to provide enough detail that if something goes
wrong during FPGA programming (something that the driver can't
fix) then userspace can know, i.e. if the firmware request
fails, that could be due to not being able to find the firmware
file.
This is a superset of FPGA states and fpga manager driver
states. The fpga manager driver is walking through these steps
to get the FPGA into a known operating state. It's a sequence,
though some steps may get skipped. Valid FPGA states will vary
by manufacturer; this is a superset.
* unknown = can't determine state
* power off = FPGA power is off
* power up = FPGA reports power is up
* reset = FPGA held in reset state
* firmware request = firmware class request in progress
* firmware request error = firmware request failed
* write init = preparing FPGA for programming
* write init error = Error while preparing FPGA for
programming
* write = FPGA ready to receive image data
* write error = Error while programming
* write complete = Doing post programming steps
* write complete error = Error while doing post programming
* operating = FPGA is programmed and operating

29
Documentation/ABI/testing/sysfs-class-mic.txt
View File

@ -41,18 +41,15 @@ Description:
When read, this entry provides the current state of an Intel
MIC device in the context of the card OS. Possible values that
will be read are:
"offline" - The MIC device is ready to boot the card OS. On
"ready" - The MIC device is ready to boot the card OS. On
reading this entry after an OSPM resume, a "boot" has to be
written to this entry if the card was previously shutdown
during OSPM suspend.
"online" - The MIC device has initiated booting a card OS.
"booting" - The MIC device has initiated booting a card OS.
"online" - The MIC device has completed boot and is online
"shutting_down" - The card OS is shutting down.
"resetting" - A reset has been initiated for the MIC device
"reset_failed" - The MIC device has failed to reset.
"suspending" - The MIC device is currently being prepared for
suspend. On reading this entry, a "suspend" has to be written
to the state sysfs entry to ensure the card is shutdown during
OSPM suspend.
"suspended" - The MIC device has been suspended.
When written, this sysfs entry triggers different state change
operations depending upon the current state of the card OS.
@ -62,8 +59,6 @@ Description:
sysfs entries.
"reset" - Initiates device reset.
"shutdown" - Initiates card OS shutdown.
"suspend" - Initiates card OS shutdown and also marks the card
as suspended.
What: /sys/class/mic/mic(x)/shutdown_status
Date: October 2013
@ -126,7 +121,7 @@ Description:
the card. This sysfs entry can be written with the following
valid strings:
a) linux - Boot a Linux image.
b) elf - Boot an elf image for flash updates.
b) flash - Boot an image for flash updates.
What: /sys/class/mic/mic(x)/log_buf_addr
Date: October 2013
@ -155,3 +150,17 @@ Description:
daemon to set the log buffer length address. The correct log
buffer length address to be written can be found in the
System.map file of the card OS.
What: /sys/class/mic/mic(x)/heartbeat_enable
Date: March 2015
KernelVersion: 3.20
Contact: Ashutosh Dixit <ashutosh.dixit@intel.com>
Description:
The MIC drivers detect and inform user space about card crashes
via a heartbeat mechanism (see the description of
shutdown_status above). User space can turn off this
notification by setting heartbeat_enable to 0 and enable it by
setting this entry to 1. If this notification is disabled it is
the responsibility of user space to detect card crashes via
alternative means such as a network ping. This setting is
enabled by default.

58
Documentation/ABI/testing/sysfs-class-power
View File

@ -74,3 +74,61 @@ Description:
Valid values:
- 0 - 70 (minutes), step by 10 (rounded down)
What: /sys/class/power_supply/bq24257-charger/ovp_voltage
Date: October 2015
KernelVersion: 4.4.0
Contact: Andreas Dannenberg <dannenberg@ti.com>
Description:
This entry configures the overvoltage protection feature of bq24257-
type charger devices. This feature protects the device and other
components against damage from overvoltage on the input supply. See
device datasheet for details.
Valid values:
- 6000000, 6500000, 7000000, 8000000, 9000000, 9500000, 10000000,
10500000 (all uV)
What: /sys/class/power_supply/bq24257-charger/in_dpm_voltage
Date: October 2015
KernelVersion: 4.4.0
Contact: Andreas Dannenberg <dannenberg@ti.com>
Description:
This entry configures the input dynamic power path management voltage of
bq24257-type charger devices. Once the supply drops to the configured
voltage, the input current limit is reduced down to prevent the further
drop of the supply. When the IC enters this mode, the charge current is
lower than the set value. See device datasheet for details.
Valid values:
- 4200000, 4280000, 4360000, 4440000, 4520000, 4600000, 4680000,
4760000 (all uV)
What: /sys/class/power_supply/bq24257-charger/high_impedance_enable
Date: October 2015
KernelVersion: 4.4.0
Contact: Andreas Dannenberg <dannenberg@ti.com>
Description:
This entry allows enabling the high-impedance mode of bq24257-type
charger devices. If enabled, it places the charger IC into low power
standby mode with the switch mode controller disabled. When disabled,
the charger operates normally. See device datasheet for details.
Valid values:
- 1: enabled
- 0: disabled
What: /sys/class/power_supply/bq24257-charger/sysoff_enable
Date: October 2015
KernelVersion: 4.4.0
Contact: Andreas Dannenberg <dannenberg@ti.com>
Description:
This entry allows enabling the sysoff mode of bq24257-type charger
devices. If enabled and the input is removed, the internal battery FET
is turned off in order to reduce the leakage from the BAT pin to less
than 1uA. Note that on some devices/systems this disconnects the battery
from the system. See device datasheet for details.
Valid values:
- 1: enabled
- 0: disabled

14
Documentation/ABI/testing/sysfs-class-stm Normal file
View File

@ -0,0 +1,14 @@
What: /sys/class/stm/<stm>/masters
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
Shows first and last available to software master numbers on
this STM device.
What: /sys/class/stm/<stm>/channels
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
Shows the number of channels per master on this STM device.

11
Documentation/ABI/testing/sysfs-class-stm_source Normal file
View File

@ -0,0 +1,11 @@
What: /sys/class/stm_source/<stm_source>/stm_source_link
Date: June 2015
KernelVersion: 4.3
Contact: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Description:
stm_source device linkage to stm device, where its tracing data
is directed. Reads return an existing connection or "<none>" if
this stm_source is not connected to any stm device yet.
Write an existing (registered) stm device's name here to
connect that device. If a device is already connected to this
stm_source, it will first be disconnected.

15
Documentation/ABI/testing/sysfs-driver-hid-corsair Normal file
View File

@ -0,0 +1,15 @@
What: /sys/bus/drivers/corsair/<dev>/macro_mode
Date: August 2015
KernelVersion: 4.2
Contact: Clement Vuchener <clement.vuchener@gmail.com>
Description: Get/set the current playback mode. "SW" for software mode
where G-keys triggers their regular key codes. "HW" for
hardware playback mode where the G-keys play their macro
from the on-board memory.
What: /sys/bus/drivers/corsair/<dev>/current_profile
Date: August 2015
KernelVersion: 4.2
Contact: Clement Vuchener <clement.vuchener@gmail.com>
Description: Get/set the current selected profile. Values are from 1 to 3.

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

@ -1,96 +0,0 @@
What: /sys/bus/usb/devices/<busnum>-<devnum>:<config num>.<interface num>/<hid-bus>:<vendor-id>:<product-id>.<num>/koneplus/roccatkoneplus<minor>/actual_profile
Date: October 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 actual
profile. This value is persistent, so its equivalent to the
profile that's active when the mouse is powered on next time.
When written, this file sets the number of the startup profile
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>/info
Date: November 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.
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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse can store a macro with max 500 key/button strokes
internally.
When written, this file lets one set the sequence for a specific
button for a specific profile. Button and profile numbers are
included in written data. The data has to be 2082 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>/koneplus/roccatkoneplus<minor>/profile_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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 77 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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
Date: October 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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 43 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: The mouse has a tracking- and a distance-control-unit. These
can be activated/deactivated and the lift-off distance can be
set. The data has to be 6 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>/koneplus/roccatkoneplus<minor>/talk
Date: May 2011
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: Used to active some easy* functions of the mouse from outside.
The data has to be 16 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>/koneplus/roccatkoneplus<minor>/tcu
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. 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
Date: October 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read the mouse returns a 30x30 pixel image of the
sampled underground. This works only in the course of a
calibration process initiated with tcu.
The returned data is 1028 bytes in size.
This file is readonly.
Users: http://roccat.sourceforge.net

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

@ -1,49 +0,0 @@
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>
Description: The integer value of this attribute ranges from 0-4.
When read, this attribute returns the number of the active
profile.
When written, the mouse activates this profile immediately.
The profile that's active when powered down is the same that's
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>/info
Date: November 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 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
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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 23 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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
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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 16 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
Before reading this file, control has to be written to select
which profile to read.
Users: http://roccat.sourceforge.net

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

@ -1,49 +0,0 @@
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: 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
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 written, this file lets one write the respective profile
settings back to the mouse. The data has to be 13 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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
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 written, this file lets one write the respective profile
buttons back to the mouse. The data has to be 19 bytes long.
The mouse will reject invalid data.
Which profile to write is determined by the profile number
contained in the data.
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
Date: August 2010
Contact: Stefan Achatz <erazor_de@users.sourceforge.net>
Description: When read, this file returns the settings stored in the mouse.
The size of the data is 3 bytes and holds information on the
startup_profile.
When written, this file lets write settings back to the mouse.
The data has to be 3 bytes long. The mouse will reject invalid
data.
Users: http://roccat.sourceforge.net

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

@ -1,4 +1,4 @@
What: /sys/devices/pnp0/<bus-num>/ppi/
What: /sys/class/tpm/tpmX/ppi/
Date: August 2012
Kernel Version: 3.6
Contact: xiaoyan.zhang@intel.com
@ -8,9 +8,14 @@ Description:
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/
What: /sys/devices/pnp0/<bus-num>/ppi/version
In Linux 4.2 ppi was moved to the character device directory.
A symlink from tpmX/device/ppi to tpmX/ppi to provide backwards
compatibility.
What: /sys/class/tpm/tpmX/ppi/version
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@ -18,7 +23,7 @@ Description:
platform.
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/request
What: /sys/class/tpm/tpmX/ppi/request
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@ -28,7 +33,7 @@ Description:
integer value range from 1 to 160, and 0 means no request.
This file can be read and written.
What: /sys/devices/pnp0/00:<bus-num>/ppi/response
What: /sys/class/tpm/tpmX/ppi/response
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@ -37,7 +42,7 @@ Description:
: <response description>".
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/transition_action
What: /sys/class/tpm/tpmX/ppi/transition_action
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@ -47,7 +52,7 @@ Description:
description>".
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/tcg_operations
What: /sys/class/tpm/tpmX/ppi/tcg_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:
@ -58,7 +63,7 @@ Description:
This attribute is only supported by PPI version 1.2+.
This file is readonly.
What: /sys/devices/pnp0/<bus-num>/ppi/vs_operations
What: /sys/class/tpm/tpmX/ppi/vs_operations
Date: August 2012
Contact: xiaoyan.zhang@intel.com
Description:

12
Documentation/ABI/testing/sysfs-driver-st Normal file
View File

@ -0,0 +1,12 @@
What: /sys/bus/scsi/drivers/st/debug_flag
Date: October 2015
Kernel Version: ?.?
Contact: shane.seymour@hpe.com
Description:
This file allows you to turn debug output from the st driver
off if you write a '0' to the file or on if you write a '1'.
Note that debug output requires that the module be compiled
with the #define DEBUG set to a non-zero value (this is the
default). If DEBUG is set to 0 then this file will not
appear in sysfs as its presence is conditional upon debug
output support being compiled into the module.

12
Documentation/ABI/testing/sysfs-fs-f2fs
View File

@ -80,3 +80,15 @@ Date: February 2015
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the trimming rate in batch mode.
What: /sys/fs/f2fs/<disk>/cp_interval
Date: October 2015
Contact: "Jaegeuk Kim" <jaegeuk@kernel.org>
Description:
Controls the checkpoint timing.
What: /sys/fs/f2fs/<disk>/ra_nid_pages
Date: October 2015
Contact: "Chao Yu" <chao2.yu@samsung.com>
Description:
Controls the count of nid pages to be readaheaded.

12
Documentation/ABI/testing/sysfs-power
View File

@ -256,3 +256,15 @@ Description:
Writing a "1" enables this printing while writing a "0"
disables it. The default value is "0". Reading from this file
will display the current value.
What: /sys/power/pm_wakeup_irq
Date: April 2015
Contact: Alexandra Yates <alexandra.yates@linux.intel.org>
Description:
The /sys/power/pm_wakeup_irq file reports to user space the IRQ
number of the first wakeup interrupt (that is, the first
interrupt from an IRQ line armed for system wakeup) seen by the
kernel during the most recent system suspend/resume cycle.
This output is useful for system wakeup diagnostics of spurious
wakeup interrupts.

3
Documentation/Changes
View File

@ -43,7 +43,8 @@ o udev 081 # udevd --version
o grub 0.93 # grub --version || grub-install --version
o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V
o openssl & libcrypto 1.0.1k # openssl version
o openssl & libcrypto 1.0.0 # openssl version
o bc 1.06.95 # bc --version
Kernel compilation

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

@ -681,6 +681,11 @@ or:
as appropriate.
PLEASE NOTE: The 'nents' argument to dma_sync_sg_for_cpu() and
dma_sync_sg_for_device() must be the same passed to
dma_map_sg(). It is _NOT_ the count returned by
dma_map_sg().
After the last DMA transfer call one of the DMA unmap routines
dma_unmap_{single,sg}(). If you don't touch the data from the first
dma_map_*() call till dma_unmap_*(), then you don't have to call the

19
Documentation/DMA-API.txt
View File

@ -141,19 +141,6 @@ memory back to the pool before you destroy it.
Part Ic - DMA addressing limitations
------------------------------------
int
dma_supported(struct device *dev, u64 mask)
Checks to see if the device can support DMA to the memory described by
mask.
Returns: 1 if it can and 0 if it can't.
Notes: This routine merely tests to see if the mask is possible. It
won't change the current mask settings. It is more intended as an
internal API for use by the platform than an external API for use by
driver writers.
int
dma_set_mask_and_coherent(struct device *dev, u64 mask)
@ -340,7 +327,7 @@ accessed sg->address and sg->length as shown above.
void
dma_unmap_sg(struct device *dev, struct scatterlist *sg,
int nhwentries, enum dma_data_direction direction)
int nents, enum dma_data_direction direction)
Unmap the previously mapped scatter/gather list. All the parameters
must be the same as those and passed in to the scatter/gather mapping
@ -356,10 +343,10 @@ void
dma_sync_single_for_device(struct device *dev, dma_addr_t dma_handle, size_t size,
enum dma_data_direction direction)
void
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nelems,
dma_sync_sg_for_cpu(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction direction)
void
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nelems,
dma_sync_sg_for_device(struct device *dev, struct scatterlist *sg, int nents,
enum dma_data_direction direction)
Synchronise a single contiguous or scatter/gather mapping for the CPU

2
Documentation/DocBook/.gitignore vendored
View File

@ -11,5 +11,7 @@
*.png
*.gif
*.svg
*.proc
*.db
media-indices.tmpl
media-entities.tmpl

5
Documentation/DocBook/80211.tmpl
View File

@ -154,8 +154,9 @@
!Finclude/net/cfg80211.h cfg80211_scan_request
!Finclude/net/cfg80211.h cfg80211_scan_done
!Finclude/net/cfg80211.h cfg80211_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_width_frame
!Finclude/net/cfg80211.h cfg80211_inform_bss_width
!Finclude/net/cfg80211.h cfg80211_inform_bss
!Finclude/net/cfg80211.h cfg80211_inform_bss_frame_data
!Finclude/net/cfg80211.h cfg80211_inform_bss_data
!Finclude/net/cfg80211.h cfg80211_unlink_bss
!Finclude/net/cfg80211.h cfg80211_find_ie
!Finclude/net/cfg80211.h ieee80211_bss_get_ie

8
Documentation/DocBook/Makefile
View File

@ -14,7 +14,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
genericirq.xml s390-drivers.xml uio-howto.xml scsi.xml \
80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.xml \
tracepoint.xml gpu.xml media_api.xml w1.xml \
writing_musb_glue_layer.xml crypto-API.xml iio.xml
include Documentation/DocBook/media/Makefile
@ -69,6 +69,12 @@ installmandocs: mandocs
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/docproc
CHECK_LC_CTYPE = $(objtree)/scripts/check-lc_ctype
# Use a fixed encoding - UTF-8 if the C library has support built-in
# or ASCII if not
LC_CTYPE := $(call try-run, LC_CTYPE=C.UTF-8 $(CHECK_LC_CTYPE),C.UTF-8,C)
export LC_CTYPE
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation

2
Documentation/DocBook/alsa-driver-api.tmpl
View File

@ -112,6 +112,8 @@
!Esound/soc/soc-devres.c
!Esound/soc/soc-io.c
!Esound/soc/soc-pcm.c
!Esound/soc/soc-ops.c
!Esound/soc/soc-compress.c
</sect1>
<sect1><title>ASoC DAPM API</title>
!Esound/soc/soc-dapm.c

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

@ -221,6 +221,9 @@ X!Isound/sound_firmware.c
<title>Media Devices</title>
<sect1><title>Video2Linux devices</title>
!Iinclude/media/tuner.h
!Iinclude/media/tuner-types.h
!Iinclude/media/tveeprom.h
!Iinclude/media/v4l2-async.h
!Iinclude/media/v4l2-ctrls.h
!Iinclude/media/v4l2-dv-timings.h
@ -231,6 +234,7 @@ X!Isound/sound_firmware.c
!Iinclude/media/v4l2-of.h
!Iinclude/media/v4l2-subdev.h
!Iinclude/media/videobuf2-core.h
!Iinclude/media/videobuf2-v4l2.h
!Iinclude/media/videobuf2-memops.h
</sect1>
<sect1><title>Digital TV (DVB) devices</title>
@ -239,15 +243,82 @@ X!Isound/sound_firmware.c
!Idrivers/media/dvb-core/dvb_math.h
!Idrivers/media/dvb-core/dvb_ringbuffer.h
!Idrivers/media/dvb-core/dvbdev.h
</sect1>
<sect1><title>Remote Controller devices</title>
<sect1><title>Digital TV Demux API</title>
<para>The kernel demux API defines a driver-internal interface for
registering low-level, hardware specific driver to a hardware
independent demux layer. It is only of interest for Digital TV
device driver writers. The header file for this API is named
<constant>demux.h</constant> and located in
<constant>drivers/media/dvb-core</constant>.</para>
<para>The demux API should be implemented for each demux in the
system. It is used to select the TS source of a demux and to manage
the demux resources. When the demux client allocates a resource via
the demux API, it receives a pointer to the API of that
resource.</para>
<para>Each demux receives its TS input from a DVB front-end or from
memory, as set via this demux API. In a system with more than one
front-end, the API can be used to select one of the DVB front-ends
as a TS source for a demux, unless this is fixed in the HW platform.
The demux API only controls front-ends regarding to their connections
with demuxes; the APIs used to set the other front-end parameters,
such as tuning, are not defined in this document.</para>
<para>The functions that implement the abstract interface demux should
be defined static or module private and registered to the Demux
core for external access. It is not necessary to implement every
function in the struct <constant>dmx_demux</constant>. For example,
a demux interface might support Section filtering, but not PES
filtering. The API client is expected to check the value of any
function pointer before calling the function: the value of NULL means
that the &#8220;function is not available&#8221;.</para>
<para>Whenever the functions of the demux API modify shared data,
the possibilities of lost update and race condition problems should
be addressed, e.g. by protecting parts of code with mutexes.</para>
<para>Note that functions called from a bottom half context must not
sleep. Even a simple memory allocation without using GFP_ATOMIC can
result in a kernel thread being put to sleep if swapping is needed.
For example, the Linux kernel calls the functions of a network device
interface from a bottom half context. Thus, if a demux API function
is called from network device code, the function must not sleep.
</para>
</sect1>
<section id="demux_callback_api">
<title>Demux Callback API</title>
<para>This kernel-space API comprises the callback functions that
deliver filtered data to the demux client. Unlike the other DVB
kABIs, these functions are provided by the client and called from
the demux code.</para>
<para>The function pointers of this abstract interface are not
packed into a structure as in the other demux APIs, because the
callback functions are registered and used independent of each
other. As an example, it is possible for the API client to provide
several callback functions for receiving TS packets and no
callbacks for PES packets or sections.</para>
<para>The functions that implement the callback API need not be
re-entrant: when a demux driver calls one of these functions,
the driver is not allowed to call the function again before
the original call returns. If a callback is triggered by a
hardware interrupt, it is recommended to use the Linux
&#8220;bottom half&#8221; mechanism or start a tasklet instead of
making the callback function call directly from a hardware
interrupt.</para>
<para>This mechanism is implemented by
<link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and
<link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para>
</section>
!Idrivers/media/dvb-core/demux.h
</sect1>
<sect1><title>Remote Controller devices</title>
!Iinclude/media/rc-core.h
</sect1>
<sect1><title>Media Controller devices</title>
!Iinclude/media/lirc_dev.h
</sect1>
<sect1><title>Media Controller devices</title>
!Iinclude/media/media-device.h
!Iinclude/media/media-devnode.h
!Iinclude/media/media-entity.h
</sect1>
</sect1>
</chapter>

209
Documentation/DocBook/drm.tmpl → Documentation/DocBook/gpu.tmpl
View File

@ -2,9 +2,9 @@
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
<book id="drmDevelopersGuide">
<book id="gpuDevelopersGuide">
<bookinfo>
<title>Linux DRM Developer's Guide</title>
<title>Linux GPU Driver Developer's Guide</title>
<authorgroup>
<author>
@ -40,6 +40,16 @@
</address>
</affiliation>
</author>
<author>
<firstname>Lukas</firstname>
<surname>Wunner</surname>
<contrib>vga_switcheroo documentation</contrib>
<affiliation>
<address>
<email>lukas@wunner.de</email>
</address>
</affiliation>
</author>
</authorgroup>
<copyright>
@ -51,6 +61,10 @@
<year>2012</year>
<holder>Laurent Pinchart</holder>
</copyright>
<copyright>
<year>2015</year>
<holder>Lukas Wunner</holder>
</copyright>
<legalnotice>
<para>
@ -69,6 +83,13 @@
<revremark>Added extensive documentation about driver internals.
</revremark>
</revision>
<revision>
<revnumber>1.1</revnumber>
<date>2015-10-11</date>
<authorinitials>LW</authorinitials>
<revremark>Added vga_switcheroo documentation.
</revremark>
</revision>
</revhistory>
</bookinfo>
@ -78,9 +99,9 @@
<title>DRM Core</title>
<partintro>
<para>
This first part of the DRM Developer's Guide documents core DRM code,
helper libraries for writing drivers and generic userspace interfaces
exposed by DRM drivers.
This first part of the GPU Driver Developer's Guide documents core DRM
code, helper libraries for writing drivers and generic userspace
interfaces exposed by DRM drivers.
</para>
</partintro>
@ -138,14 +159,10 @@
<para>
At the core of every DRM driver is a <structname>drm_driver</structname>
structure. Drivers typically statically initialize a drm_driver structure,
and then pass it to one of the <function>drm_*_init()</function> functions
to register it with the DRM subsystem.
</para>
<para>
Newer drivers that no longer require a <structname>drm_bus</structname>
structure can alternatively use the low-level device initialization and
registration functions such as <function>drm_dev_alloc()</function> and
<function>drm_dev_register()</function> directly.
and then pass it to <function>drm_dev_alloc()</function> to allocate a
device instance. After the device instance is fully initialized it can be
registered (which makes it accessible from userspace) using
<function>drm_dev_register()</function>.
</para>
<para>
The <structname>drm_driver</structname> structure contains static
@ -296,83 +313,12 @@ char *date;</synopsis>
</sect3>
</sect2>
<sect2>
<title>Device Registration</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices, respectively.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
<para>
New drivers that no longer rely on the services provided by the
<structname>drm_bus</structname> structure can call the low-level
device registration functions directly. The
<function>drm_dev_alloc()</function> function can be used to allocate
and initialize a new <structname>drm_device</structname> structure.
Drivers will typically want to perform some additional setup on this
structure, such as allocating driver-specific data and storing a
pointer to it in the DRM device's <structfield>dev_private</structfield>
field. Drivers should also set the device's unique name using the
<function>drm_dev_set_unique()</function> function. After it has been
set up a device can be registered with the DRM subsystem by calling
<function>drm_dev_register()</function>. This will cause the device to
be exposed to userspace and will call the driver's
<structfield>.load()</structfield> implementation. When a device is
removed, the DRM device can safely be unregistered and freed by calling
<function>drm_dev_unregister()</function> followed by a call to
<function>drm_dev_unref()</function>.
</para>
<title>Device Instance and Driver Handling</title>
!Pdrivers/gpu/drm/drm_drv.c driver instance overview
!Edrivers/gpu/drm/drm_drv.c
</sect2>
<sect2>
<title>Driver Load</title>
<para>
The <methodname>load</methodname> method is the driver and device
initialization entry point. The method is responsible for allocating and
initializing driver private data, performing resource allocation and
mapping (e.g. acquiring
clocks, mapping registers or allocating command buffers), initializing
the memory manager (<xref linkend="drm-memory-management"/>), installing
the IRQ handler (<xref linkend="drm-irq-registration"/>), setting up
vertical blanking handling (<xref linkend="drm-vertical-blank"/>), mode
setting (<xref linkend="drm-mode-setting"/>) and initial output
configuration (<xref linkend="drm-kms-init"/>).
</para>
<note><para>
If compatibility is a concern (e.g. with drivers converted over from
User Mode Setting to Kernel Mode Setting), care must be taken to prevent
device initialization and control that is incompatible with currently
active userspace drivers. For instance, if user level mode setting
drivers are in use, it would be problematic to perform output discovery
&amp; configuration at load time. Likewise, if user-level drivers
unaware of memory management are in use, memory management and command
buffer setup may need to be omitted. These requirements are
driver-specific, and care needs to be taken to keep both old and new
applications and libraries working.
</para></note>
<synopsis>int (*load) (struct drm_device *, unsigned long flags);</synopsis>
<para>
The method takes two arguments, a pointer to the newly created
<structname>drm_device</structname> and flags. The flags are used to
pass the <structfield>driver_data</structfield> field of the device id
corresponding to the device passed to <function>drm_*_init()</function>.
Only PCI devices currently use this, USB and platform DRM drivers have
their <methodname>load</methodname> method called with flags to 0.
</para>
<sect3>
<title>Driver Private Data</title>
<para>
The driver private hangs off the main
<structname>drm_device</structname> structure and can be used for
tracking various device-specific bits of information, like register
offsets, command buffer status, register state for suspend/resume, etc.
At load time, a driver may simply allocate one and set
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
appropriately; it should be freed and
<structname>drm_device</structname>.<structfield>dev_priv</structfield>
set to NULL when the driver is unloaded.
</para>
</sect3>
<sect3 id="drm-irq-registration">
<title>IRQ Registration</title>
<para>
@ -465,6 +411,18 @@ char *date;</synopsis>
</para>
</sect3>
</sect2>
<sect2>
<title>Bus-specific Device Registration and PCI Support</title>
<para>
A number of functions are provided to help with device registration.
The functions deal with PCI and platform devices respectively and are
only provided for historical reasons. These are all deprecated and
shouldn't be used in new drivers. Besides that there's a few
helpers for pci drivers.
</para>
!Edrivers/gpu/drm/drm_pci.c
!Edrivers/gpu/drm/drm_platform.c
</sect2>
</sect1>
<!-- Internals: memory management -->
@ -3646,10 +3604,11 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
plane properties to default value, so that a subsequent open of the
device will not inherit state from the previous user. It can also be
used to execute delayed power switching state changes, e.g. in
conjunction with the vga-switcheroo infrastructure. Beyond that KMS
drivers should not do any further cleanup. Only legacy UMS drivers might
need to clean up device state so that the vga console or an independent
fbdev driver could take over.
conjunction with the vga_switcheroo infrastructure (see
<xref linkend="vga_switcheroo"/>). Beyond that KMS drivers should not
do any further cleanup. Only legacy UMS drivers might need to clean up
device state so that the vga console or an independent fbdev driver
could take over.
</para>
</sect2>
<sect2>
@ -3747,11 +3706,14 @@ int num_ioctls;</synopsis>
</para></listitem>
<listitem><para>
DRM_UNLOCKED - The ioctl handler will be called without locking
the DRM global mutex
the DRM global mutex. This is the enforced default for kms drivers
(i.e. using the DRIVER_MODESET flag) and hence shouldn't be used
any more for new drivers.
</para></listitem>
</itemizedlist>
</para>
</para>
!Edrivers/gpu/drm/drm_ioctl.c
</sect2>
</sect1>
<sect1>
@ -3949,8 +3911,8 @@ int num_ioctls;</synopsis>
<partintro>
<para>
This second part of the DRM Developer's Guide documents driver code,
implementation details and also all the driver-specific userspace
This second part of the GPU Driver Developer's Guide documents driver
code, implementation details and also all the driver-specific userspace
interfaces. Especially since all hardware-acceleration interfaces to
userspace are driver specific for efficiency and other reasons these
interfaces can be rather substantial. Hence every driver has its own
@ -4051,6 +4013,7 @@ int num_ioctls;</synopsis>
<title>High Definition Audio</title>
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
!Idrivers/gpu/drm/i915/intel_audio.c
!Iinclude/drm/i915_component.h
</sect2>
<sect2>
<title>Panel Self Refresh PSR (PSR/SRD)</title>
@ -4237,6 +4200,20 @@ int num_ioctls;</synopsis>
!Idrivers/gpu/drm/i915/i915_gem_shrinker.c
</sect2>
</sect1>
<sect1>
<title>GuC-based Command Submission</title>
<sect2>
<title>GuC</title>
!Pdrivers/gpu/drm/i915/intel_guc_loader.c GuC-specific firmware loader
!Idrivers/gpu/drm/i915/intel_guc_loader.c
</sect2>
<sect2>
<title>GuC Client</title>
!Pdrivers/gpu/drm/i915/i915_guc_submission.c GuC-based command submissison
!Idrivers/gpu/drm/i915/i915_guc_submission.c
</sect2>
</sect1>
<sect1>
<title> Tracing </title>
<para>
@ -4260,4 +4237,50 @@ int num_ioctls;</synopsis>
</chapter>
!Cdrivers/gpu/drm/i915/i915_irq.c
</part>
<part id="vga_switcheroo">
<title>vga_switcheroo</title>
<partintro>
!Pdrivers/gpu/vga/vga_switcheroo.c Overview
</partintro>
<chapter id="modes_of_use">
<title>Modes of Use</title>
<sect1>
<title>Manual switching and manual power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Manual switching and manual power control
</sect1>
<sect1>
<title>Driver power control</title>
!Pdrivers/gpu/vga/vga_switcheroo.c Driver power control
</sect1>
</chapter>
<chapter id="pubfunctions">
<title>Public functions</title>
!Edrivers/gpu/vga/vga_switcheroo.c
</chapter>
<chapter id="pubstructures">
<title>Public structures</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_ops
</chapter>
<chapter id="pubconstants">
<title>Public constants</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
</chapter>
<chapter id="privstructures">
<title>Private structures</title>
!Fdrivers/gpu/vga/vga_switcheroo.c vgasr_priv
!Fdrivers/gpu/vga/vga_switcheroo.c vga_switcheroo_client
</chapter>
!Cdrivers/gpu/vga/vga_switcheroo.c
!Cinclude/linux/vga_switcheroo.h
</part>
</book>

2
Documentation/DocBook/iio.tmpl
View File

@ -578,7 +578,7 @@
work together.
</para>
<sect2 id="iiotrigbufsetup"> <title> IIO triggered buffer setup</title>
!Edrivers/iio/industrialio-triggered-buffer.c
!Edrivers/iio/buffer/industrialio-triggered-buffer.c
!Finclude/linux/iio/iio.h iio_buffer_setup_ops

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

@ -125,9 +125,6 @@ Added ISDB-T test originally written by Patrick Boettcher
&sub-audio;
</section>
</chapter>
<chapter id="dvb_kdapi">
&sub-kdapi;
</chapter>
<chapter id="dvb_examples">
&sub-examples;
</chapter>

2309
Documentation/DocBook/media/dvb/kdapi.xml
View File

File diff suppressed because it is too large Load Diff

18
Documentation/DocBook/media/v4l/biblio.xml
View File

@ -177,6 +177,24 @@ Signal - NTSC for Studio Applications"</title>
1125-Line High-Definition Production"</title>
</biblioentry>
<biblioentry id="smpte431">
<abbrev>SMPTE&nbsp;RP&nbsp;431-2</abbrev>
<authorgroup>
<corpauthor>Society of Motion Picture and Television Engineers
(<ulink url="http://www.smpte.org">http://www.smpte.org</ulink>)</corpauthor>
</authorgroup>
<title>SMPTE RP 431-2:2011 "D-Cinema Quality - Reference Projector and Environment"</title>
</biblioentry>
<biblioentry id="smpte2084">
<abbrev>SMPTE&nbsp;ST&nbsp;2084</abbrev>
<authorgroup>
<corpauthor>Society of Motion Picture and Television Engineers
(<ulink url="http://www.smpte.org">http://www.smpte.org</ulink>)</corpauthor>
</authorgroup>
<title>SMPTE ST 2084:2014 "High Dynamic Range Electro-Optical Transfer Function of Master Reference Displays"</title>
</biblioentry>
<biblioentry id="srgb">
<abbrev>sRGB</abbrev>
<authorgroup>

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

@ -2591,6 +2591,26 @@ and &v4l2-mbus-framefmt;.
</orderedlist>
</section>
<section>
<title>V4L2 in Linux 4.4</title>
<orderedlist>
<listitem>
<para>Renamed <constant>V4L2_TUNER_ADC</constant> to
<constant>V4L2_TUNER_SDR</constant>. The use of
<constant>V4L2_TUNER_ADC</constant> is deprecated now.
</para>
</listitem>
<listitem>
<para>Added <constant>V4L2_CID_RF_TUNER_RF_GAIN</constant>
RF Tuner control.</para>
</listitem>
<listitem>
<para>Added transmitter support for Software Defined Radio (SDR)
Interface.</para>
</listitem>
</orderedlist>
</section>
<section id="other">
<title>Relation of V4L2 to other Linux multimedia APIs</title>

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

@ -5417,6 +5417,18 @@ set. Unit is in Hz. The range and step are driver-specific.</entry>
<row>
<entry spanname="descr">Enables/disables IF automatic gain control (AGC)</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_RF_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
</row>
<row>
<entry spanname="descr">The RF amplifier is the very first
amplifier on the receiver signal path, just right after the antenna input.
The difference between the LNA gain and the RF gain in this document is that
the LNA gain is integrated in the tuner chip while the RF gain is a separate
chip. There may be both RF and LNA gain controls in the same device.
The range and step are driver-specific.</entry>
</row>
<row>
<entry spanname="id"><constant>V4L2_CID_RF_TUNER_LNA_GAIN</constant>&nbsp;</entry>
<entry>integer</entry>
@ -5425,6 +5437,8 @@ set. Unit is in Hz. The range and step are driver-specific.</entry>
<entry spanname="descr">LNA (low noise amplifier) gain is first
gain stage on the RF tuner signal path. It is located very close to tuner
antenna input. Used when <constant>V4L2_CID_RF_TUNER_LNA_GAIN_AUTO</constant> is not set.
See <constant>V4L2_CID_RF_TUNER_RF_GAIN</constant> to understand how RF gain
and LNA gain differs from the each others.
The range and step are driver-specific.</entry>
</row>
<row>

32
Documentation/DocBook/media/v4l/dev-sdr.xml
View File

@ -28,6 +28,16 @@ Devices supporting the SDR receiver interface set the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
Analog to Digital Converter (ADC), which is a mandatory element for the SDR receiver.
</para>
<para>
Devices supporting the SDR transmitter interface set the
<constant>V4L2_CAP_SDR_OUTPUT</constant> and
<constant>V4L2_CAP_MODULATOR</constant> flag in the
<structfield>capabilities</structfield> field of &v4l2-capability;
returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
Digital to Analog Converter (DAC), which is a mandatory element for the SDR transmitter.
</para>
<para>
At least one of the read/write, streaming or asynchronous I/O methods must
be supported.
</para>
@ -39,15 +49,16 @@ be supported.
<para>
SDR devices can support <link linkend="control">controls</link>, and must
support the <link linkend="tuner">tuner</link> ioctls. Tuner ioctls are used
for setting the ADC sampling rate (sampling frequency) and the possible RF tuner
frequency.
for setting the ADC/DAC sampling rate (sampling frequency) and the possible
radio frequency (RF).
</para>
<para>
The <constant>V4L2_TUNER_ADC</constant> tuner type is used for ADC tuners, and
the <constant>V4L2_TUNER_RF</constant> tuner type is used for RF tuners. The
tuner index of the RF tuner (if any) must always follow the ADC tuner index.
Normally the ADC tuner is #0 and the RF tuner is #1.
The <constant>V4L2_TUNER_SDR</constant> tuner type is used for setting SDR
device ADC/DAC frequency, and the <constant>V4L2_TUNER_RF</constant>
tuner type is used for setting radio frequency.
The tuner index of the RF tuner (if any) must always follow the SDR tuner index.
Normally the SDR tuner is #0 and the RF tuner is #1.
</para>
<para>
@ -59,9 +70,9 @@ The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported.
<title>Data Format Negotiation</title>
<para>
The SDR capture device uses the <link linkend="format">format</link> ioctls to
select the capture format. Both the sampling resolution and the data streaming
format are bound to that selectable format. In addition to the basic
The SDR device uses the <link linkend="format">format</link> ioctls to
select the capture and output format. Both the sampling resolution and the data
streaming format are bound to that selectable format. In addition to the basic
<link linkend="format">format</link> ioctls, the &VIDIOC-ENUM-FMT; ioctl
must be supported as well.
</para>
@ -69,7 +80,8 @@ must be supported as well.
<para>
To use the <link linkend="format">format</link> ioctls applications set the
<structfield>type</structfield> field of a &v4l2-format; to
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> and use the &v4l2-sdr-format;
<constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant> or
<constant>V4L2_BUF_TYPE_SDR_OUTPUT</constant> and use the &v4l2-sdr-format;
<structfield>sdr</structfield> member of the <structfield>fmt</structfield>
union as needed per the desired operation.
Currently there is two fields, <structfield>pixelformat</structfield> and

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

@ -1006,8 +1006,14 @@ must set this to 0.</entry>
<row>
<entry><constant>V4L2_BUF_TYPE_SDR_CAPTURE</constant></entry>
<entry>11</entry>
<entry>Buffer for Software Defined Radio (SDR), see <xref
linkend="sdr" />.</entry>
<entry>Buffer for Software Defined Radio (SDR) capture stream, see
<xref linkend="sdr" />.</entry>
</row>
<row>
<entry><constant>V4L2_BUF_TYPE_SDR_OUTPUT</constant></entry>
<entry>12</entry>
<entry>Buffer for Software Defined Radio (SDR) output stream, see
<xref linkend="sdr" />.</entry>
</row>
</tbody>
</tgroup>

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

@ -539,6 +539,10 @@ colorspaces except for BT.2020 which uses limited range R'G'B' quantization.</pa
<entry><constant>V4L2_COLORSPACE_BT2020</constant></entry>
<entry>See <xref linkend="col-bt2020" />.</entry>
</row>
<row>
<entry><constant>V4L2_COLORSPACE_DCI_P3</constant></entry>
<entry>See <xref linkend="col-dcip3" />.</entry>
</row>
<row>
<entry><constant>V4L2_COLORSPACE_SMPTE240M</constant></entry>
<entry>See <xref linkend="col-smpte-240m" />.</entry>
@ -601,6 +605,14 @@ colorspaces except for BT.2020 which uses limited range R'G'B' quantization.</pa
<entry><constant>V4L2_XFER_FUNC_NONE</constant></entry>
<entry>Do not use a transfer function (i.e. use linear RGB values).</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_DCI_P3</constant></entry>
<entry>Use the DCI-P3 transfer function.</entry>
</row>
<row>
<entry><constant>V4L2_XFER_FUNC_SMPTE2084</constant></entry>
<entry>Use the SMPTE 2084 transfer function.</entry>
</row>
</tbody>
</tgroup>
</table>
@ -1154,6 +1166,68 @@ clamped to the range [-0.5&hellip;0.5]. The Y'CbCr quantization is limited range
clamped to the range [-0.5&hellip;0.5]. The Yc'CbcCrc quantization is limited range.</para>
</section>
<section id="col-dcip3">
<title>Colorspace DCI-P3 (<constant>V4L2_COLORSPACE_DCI_P3</constant>)</title>
<para>The <xref linkend="smpte431" /> standard defines the colorspace used by cinema
projectors that use the DCI-P3 colorspace.
The default transfer function is <constant>V4L2_XFER_FUNC_DCI_P3</constant>.
The default Y'CbCr encoding is <constant>V4L2_YCBCR_ENC_709</constant>. Note that this
colorspace does not specify a Y'CbCr encoding since it is not meant to be encoded
to Y'CbCr. So this default Y'CbCr encoding was picked because it is the HDTV
encoding. The default Y'CbCr quantization is limited range. The chromaticities of
the primary colors and the white reference are:</para>
<table frame="none">
<title>DCI-P3 Chromaticities</title>
<tgroup cols="3" align="left">
&cs-str;
<thead>
<row>
<entry>Color</entry>
<entry>x</entry>
<entry>y</entry>
</row>
</thead>
<tbody valign="top">
<row>
<entry>Red</entry>
<entry>0.6800</entry>
<entry>0.3200</entry>
</row>
<row>
<entry>Green</entry>
<entry>0.2650</entry>
<entry>0.6900</entry>
</row>
<row>
<entry>Blue</entry>
<entry>0.1500</entry>
<entry>0.0600</entry>
</row>
<row>
<entry>White Reference</entry>
<entry>0.3140</entry>
<entry>0.3510</entry>
</row>
</tbody>
</tgroup>
</table>
<variablelist>
<varlistentry>
<term>Transfer function:</term>
<listitem>
<para>L' = L<superscript>1/2.6</superscript></para>
</listitem>
</varlistentry>
<varlistentry>
<term>Inverse Transfer function:</term>
<listitem>
<para>L = L'<superscript>2.6</superscript></para>
</listitem>
</varlistentry>
</variablelist>
<para>Y'CbCr encoding is not specified. V4L2 defaults to Rec. 709.</para>
</section>
<section id="col-smpte-240m">
<title>Colorspace SMPTE 240M (<constant>V4L2_COLORSPACE_SMPTE240M</constant>)</title>
<para>The <xref linkend="smpte240m" /> standard was an interim standard used during
@ -1402,6 +1476,41 @@ and <constant>V4L2_QUANTIZATION_FULL_RANGE</constant>.</para>
</section>
<section>
<title>Detailed Transfer Function Descriptions</title>
<section id="xf-smpte-2084">
<title>Transfer Function SMPTE 2084 (<constant>V4L2_XFER_FUNC_SMPTE2084</constant>)</title>
<para>The <xref linkend="smpte2084" /> standard defines the transfer function used by
High Dynamic Range content.</para>
<variablelist>
<varlistentry>
<term>Constants:</term>
<listitem>
<para>m1 = (2610 / 4096) / 4</para>
<para>m2 = (2523 / 4096) * 128</para>
<para>c1 = 3424 / 4096</para>
<para>c2 = (2413 / 4096) * 32</para>
<para>c3 = (2392 / 4096) * 32</para>
</listitem>
</varlistentry>
<varlistentry>
<term>Transfer function:</term>
<listitem>
<para>L' = ((c1 + c2 * L<superscript>m1</superscript>) / (1 + c3 * L<superscript>m1</superscript>))<superscript>m2</superscript></para>
</listitem>
</varlistentry>
</variablelist>
<variablelist>
<varlistentry>
<term>Inverse Transfer function:</term>
<listitem>
<para>L = (max(L'<superscript>1/m2</superscript> - c1, 0) / (c2 - c3 * L'<superscript>1/m2</superscript>))<superscript>1/m1</superscript></para>
</listitem>
</varlistentry>
</variablelist>
</section>
</section>
<section id="pixfmt-indexed">
<title>Indexed Format</title>
@ -1623,7 +1732,7 @@ extended control <constant>V4L2_CID_MPEG_STREAM_TYPE</constant>, see
<section id="sdr-formats">
<title>SDR Formats</title>
<para>These formats are used for <link linkend="sdr">SDR Capture</link>
<para>These formats are used for <link linkend="sdr">SDR</link>
interface only.</para>
&sub-sdr-cu08;

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

@ -151,9 +151,18 @@ Rubli, Andy Walls, Muralidharan Karicheri, Mauro Carvalho Chehab,
structs, ioctls) must be noted in more detail in the history chapter
(compat.xml), along with the possible impact on existing drivers and
applications. -->
<revision>
<revnumber>4.4</revnumber>
<date>2015-05-26</date>
<authorinitials>ap</authorinitials>
<revremark>Renamed V4L2_TUNER_ADC to V4L2_TUNER_SDR.
Added V4L2_CID_RF_TUNER_RF_GAIN control.
Added transmitter support for Software Defined Radio (SDR) Interface.
</revremark>
</revision>
<revision>
<revnumber>3.21</revnumber>
<revnumber>4.1</revnumber>
<date>2015-02-13</date>
<authorinitials>mcc</authorinitials>
<revremark>Fix documentation for media controller device nodes and add support for DVB device nodes.
@ -557,7 +566,7 @@ and discussions on the V4L mailing list.</revremark>
</partinfo>
<title>Video for Linux Two API Specification</title>
<subtitle>Revision 3.19</subtitle>
<subtitle>Revision 4.4</subtitle>
<chapter id="common">
&sub-common;

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

@ -130,7 +130,7 @@ encoding will continue until the end of the current <wordasword>Group
Of Pictures</wordasword>, otherwise encoding will stop immediately.
When the encoder is already stopped, this command does
nothing. mem2mem encoders will send a <constant>V4L2_EVENT_EOS</constant> event
when the last frame has been decoded and all frames are ready to be dequeued and
when the last frame has been encoded and all frames are ready to be dequeued and
will set the <constant>V4L2_BUF_FLAG_LAST</constant> buffer flag on the last
buffer of the capture queue to indicate there will be no new buffers produced to
dequeue. This buffer may be empty, indicated by the driver setting the

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

@ -197,6 +197,13 @@ Valid if this control is of type <constant>V4L2_CTRL_TYPE_U8</constant>.</entry>
<entry><structfield>p_u16</structfield></entry>
<entry>A pointer to a matrix control of unsigned 16-bit values.
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U16</constant>.</entry>
</row>
<row>
<entry></entry>
<entry>__u32 *</entry>
<entry><structfield>p_u32</structfield></entry>
<entry>A pointer to a matrix control of unsigned 32-bit values.
Valid if this control is of type <constant>V4L2_CTRL_TYPE_U32</constant>.</entry>
</row>
<row>
<entry></entry>

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

@ -175,7 +175,7 @@ capture and output devices.</entry>
<entry>&v4l2-sdr-format;</entry>
<entry><structfield>sdr</structfield></entry>
<entry>Definition of a data format, see
<xref linkend="pixfmt" />, used by SDR capture devices.</entry>
<xref linkend="pixfmt" />, used by SDR capture and output devices.</entry>
</row>
<row>
<entry></entry>

14
Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
View File

@ -78,6 +78,12 @@ different audio modulation if the request cannot be satisfied. However
this is a write-only ioctl, it does not return the actual audio
modulation selected.</para>
<para><link linkend="sdr">SDR</link> specific modulator types are
<constant>V4L2_TUNER_SDR</constant> and <constant>V4L2_TUNER_RF</constant>.
For SDR devices <structfield>txsubchans</structfield> field must be
initialized to zero.
The term 'modulator' means SDR transmitter in this context.</para>
<para>To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl
is available.</para>
@ -140,7 +146,13 @@ indicator, for example a stereo pilot tone.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[4]</entry>
<entry><structfield>type</structfield></entry>
<entry spanname="hspan">Type of the modulator, see <xref
linkend="v4l2-tuner-type" />.</entry>
</row>
<row>
<entry>__u32</entry>
<entry><structfield>reserved</structfield>[3]</entry>
<entry>Reserved for future extensions. Drivers and
applications must set the array to zero.</entry>
</row>

16
Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
View File

@ -80,6 +80,12 @@ if the requested mode is invalid or unsupported. Since this is a
<!-- FIXME -->write-only ioctl, it does not return the actually
selected audio mode.</para>
<para><link linkend="sdr">SDR</link> specific tuner types are
<constant>V4L2_TUNER_SDR</constant> and <constant>V4L2_TUNER_RF</constant>.
For SDR devices <structfield>audmode</structfield> field must be
initialized to zero.
The term 'tuner' means SDR receiver in this context.</para>
<para>To change the radio frequency the &VIDIOC-S-FREQUENCY; ioctl
is available.</para>
@ -261,6 +267,16 @@ applications must set the array to zero.</entry>
<entry>2</entry>
<entry></entry>
</row>
<row>
<entry><constant>V4L2_TUNER_SDR</constant></entry>
<entry>4</entry>
<entry></entry>
</row>
<row>
<entry><constant>V4L2_TUNER_RF</constant></entry>
<entry>5</entry>
<entry></entry>
</row>
</tbody>
</tgroup>
</table>

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

@ -306,6 +306,12 @@ modulator programming see
<entry>0x00200000</entry>
<entry>The device supports the &v4l2-pix-format; extended
fields.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_SDR_OUTPUT</constant></entry>
<entry>0x00400000</entry>
<entry>The device supports the
<link linkend="sdr">SDR Output</link> interface.</entry>
</row>
<row>
<entry><constant>V4L2_CAP_READWRITE</constant></entry>

21
Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
View File

@ -101,8 +101,9 @@ prematurely end the enumeration).</para></footnote></para>
next supported non-compound control, or <errorcode>EINVAL</errorcode>
if there is none. In addition, the <constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant>
flag can be specified to enumerate all compound controls (i.e. controls
with type &ge; <constant>V4L2_CTRL_COMPOUND_TYPES</constant>). Specify both
<constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> and
with type &ge; <constant>V4L2_CTRL_COMPOUND_TYPES</constant> and/or array
control, in other words controls that contain more than one value).
Specify both <constant>V4L2_CTRL_FLAG_NEXT_CTRL</constant> and
<constant>V4L2_CTRL_FLAG_NEXT_COMPOUND</constant> in order to enumerate
all controls, compound or not. Drivers which do not support these flags yet
always return <errorcode>EINVAL</errorcode>.</para>
@ -422,7 +423,7 @@ the array to zero.</entry>
<entry>any</entry>
<entry>An integer-valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values which are actually different on the hardware.</entry>
values.</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_TYPE_BOOLEAN</constant></entry>
@ -518,7 +519,7 @@ Older drivers which do not support this feature return an
<entry>any</entry>
<entry>An unsigned 8-bit valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values which are actually different on the hardware.
values.
</entry>
</row>
<row>
@ -528,7 +529,17 @@ values which are actually different on the hardware.
<entry>any</entry>
<entry>An unsigned 16-bit valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values which are actually different on the hardware.
values.
</entry>
</row>
<row>
<entry><constant>V4L2_CTRL_TYPE_U32</constant></entry>
<entry>any</entry>
<entry>any</entry>
<entry>any</entry>
<entry>An unsigned 32-bit valued control ranging from minimum to
maximum inclusive. The step value indicates the increment between
values.
</entry>
</row>
</tbody>

2
Documentation/DocBook/media_api.tmpl
View File

@ -38,7 +38,7 @@
<title>LINUX MEDIA INFRASTRUCTURE API</title>
<copyright>
<year>2009-2014</year>
<year>2009-2015</year>
<holder>LinuxTV Developers</holder>
</copyright>

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

@ -2181,10 +2181,6 @@ struct _snd_pcm_runtime {
struct snd_pcm_hardware hw;
struct snd_pcm_hw_constraints hw_constraints;
/* -- interrupt callbacks -- */
void (*transfer_ack_begin)(struct snd_pcm_substream *substream);
void (*transfer_ack_end)(struct snd_pcm_substream *substream);
/* -- timer -- */
unsigned int timer_resolution; /* timer resolution */
@ -2209,9 +2205,8 @@ struct _snd_pcm_runtime {
For the operators (callbacks) of each sound driver, most of
these records are supposed to be read-only. Only the PCM
middle-layer changes / updates them. The exceptions are
the hardware description (hw), interrupt callbacks
(transfer_ack_xxx), DMA buffer information, and the private
data. Besides, if you use the standard buffer allocation
the hardware description (hw) DMA buffer information and the
private data. Besides, if you use the standard buffer allocation
method via <function>snd_pcm_lib_malloc_pages()</function>,
you don't need to set the DMA buffer information by yourself.
</para>
@ -2538,16 +2533,6 @@ struct _snd_pcm_runtime {
</para>
</section>
<section id="pcm-interface-runtime-intr">
<title>Interrupt Callbacks</title>
<para>
The field <structfield>transfer_ack_begin</structfield> and
<structfield>transfer_ack_end</structfield> are called at
the beginning and at the end of
<function>snd_pcm_period_elapsed()</function>, respectively.
</para>
</section>
</section>
<section id="pcm-interface-operators">

8
Documentation/IRQ-domain.txt
View File

@ -32,9 +32,9 @@ top of the irq_alloc_desc*() API. An irq_domain to manage mapping is
preferred over interrupt controller drivers open coding their own
reverse mapping scheme.
irq_domain also implements translation from Device Tree interrupt
specifiers to hwirq numbers, and can be easily extended to support
other IRQ topology data sources.
irq_domain also implements translation from an abstract irq_fwspec
structure to hwirq numbers (Device Tree and ACPI GSI so far), and can
be easily extended to support other IRQ topology data sources.
=== irq_domain usage ===
An interrupt controller driver creates and registers an irq_domain by
@ -184,7 +184,7 @@ There are four major interfaces to use hierarchy irq_domain:
related resources associated with these interrupts.
3) irq_domain_activate_irq(): activate interrupt controller hardware to
deliver the interrupt.
3) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
4) irq_domain_deactivate_irq(): deactivate interrupt controller hardware
to stop delivering the interrupt.
Following changes are needed to support hierarchy irq_domain.

7
Documentation/RCU/stallwarn.txt
View File

@ -205,6 +205,13 @@ o For !CONFIG_PREEMPT kernels, a CPU looping anywhere in the
behavior, you might need to replace some of the cond_resched()
calls with calls to cond_resched_rcu_qs().
o Booting Linux using a console connection that is too slow to
keep up with the boot-time console-message rate. For example,
a 115Kbaud serial console can be -way- too slow to keep up
with boot-time message rates, and will frequently result in
RCU CPU stall warning messages. Especially if you have added
debug printk()s.
o Anything that prevents RCU's grace-period kthreads from running.
This can result in the "All QSes seen" console-log message.
This message will include information on when the kthread last

39
Documentation/RCU/torture.txt
View File

@ -166,40 +166,27 @@ test_no_idle_hz Whether or not to test the ability of RCU to operate in
torture_type The type of RCU to test, with string values as follows:
"rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu().
"rcu_sync": rcu_read_lock(), rcu_read_unlock(), and
synchronize_rcu().
"rcu_expedited": rcu_read_lock(), rcu_read_unlock(), and
synchronize_rcu_expedited().
"rcu": rcu_read_lock(), rcu_read_unlock() and call_rcu(),
along with expedited, synchronous, and polling
variants.
"rcu_bh": rcu_read_lock_bh(), rcu_read_unlock_bh(), and
call_rcu_bh().
call_rcu_bh(), along with expedited and synchronous
variants.
"rcu_bh_sync": rcu_read_lock_bh(), rcu_read_unlock_bh(),
and synchronize_rcu_bh().
"rcu_bh_expedited": rcu_read_lock_bh(), rcu_read_unlock_bh(),
and synchronize_rcu_bh_expedited().
"rcu_busted": This tests an intentionally incorrect version
of RCU in order to help test rcutorture itself.
"srcu": srcu_read_lock(), srcu_read_unlock() and
call_srcu().
"srcu_sync": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu().
"srcu_expedited": srcu_read_lock(), srcu_read_unlock() and
synchronize_srcu_expedited().
call_srcu(), along with expedited and
synchronous variants.
"sched": preempt_disable(), preempt_enable(), and
call_rcu_sched().
call_rcu_sched(), along with expedited,
synchronous, and polling variants.
"sched_sync": preempt_disable(), preempt_enable(), and
synchronize_sched().
"sched_expedited": preempt_disable(), preempt_enable(), and
synchronize_sched_expedited().
"tasks": voluntary context switch and call_rcu_tasks(),
along with expedited and synchronous variants.
Defaults to "rcu".

32
Documentation/RCU/trace.txt
View File

@ -56,14 +56,14 @@ rcuboost:
The output of "cat rcu/rcu_preempt/rcudata" looks as follows:
0!c=30455 g=30456 pq=1/0 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/0 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/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/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/0 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/0 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/0 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/0 qp=0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
0!c=30455 g=30456 cnq=1/0: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 cnq=1/0: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 cnq=1/1: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 cnq=1/1: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0:0 dt=91536/0/0 df=547 of=4 ql=0/0 qs=.... b=10 ci=109819 nci=0 co=1115 ca=969
This file has one line per CPU, or eight for this 8-CPU system.
The fields are as follows:
@ -188,14 +188,14 @@ o "ca" is the number of RCU callbacks that have been adopted by this
Kernels compiled with CONFIG_RCU_BOOST=y display the following from
/debug/rcu/rcu_preempt/rcudata:
0!c=12865 g=12866 pq=1/0 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/0 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/0 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/0 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/0 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/0 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/0 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/0 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
0!c=12865 g=12866 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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 cnq=1/0: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:

6
Documentation/RCU/whatisRCU.txt
View File

@ -364,7 +364,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt.
};
DEFINE_SPINLOCK(foo_mutex);
struct foo *gbl_foo;
struct foo __rcu *gbl_foo;
/*
* Create a new struct foo that is the same as the one currently
@ -386,7 +386,7 @@ uses of RCU may be found in listRCU.txt, arrayRCU.txt, and NMI-RCU.txt.
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = gbl_foo;
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
new_fp->a = new_a;
rcu_assign_pointer(gbl_foo, new_fp);
@ -487,7 +487,7 @@ The foo_update_a() function might then be written as follows:
new_fp = kmalloc(sizeof(*new_fp), GFP_KERNEL);
spin_lock(&foo_mutex);
old_fp = gbl_foo;
old_fp = rcu_dereference_protected(gbl_foo, lockdep_is_held(&foo_mutex));
*new_fp = *old_fp;
new_fp->a = new_a;
rcu_assign_pointer(gbl_foo, new_fp);

23
Documentation/SubmittingPatches
View File

@ -659,8 +659,8 @@ succinct and descriptive, but that is what a well-written summary
should do.
The "summary phrase" may be prefixed by tags enclosed in square
brackets: "Subject: [PATCH tag] <summary phrase>". The tags are not
considered part of the summary phrase, but describe how the patch
brackets: "Subject: [PATCH <tag>...] <summary phrase>". The tags are
not considered part of the summary phrase, but describe how the patch
should be treated. Common tags might include a version descriptor if
the multiple versions of the patch have been sent out in response to
comments (i.e., "v1, v2, v3"), or "RFC" to indicate a request for
@ -672,8 +672,8 @@ the patch series.
A couple of example Subjects:
Subject: [patch 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCHv2 001/207] x86: fix eflags tracking
Subject: [PATCH 2/5] ext2: improve scalability of bitmap searching
Subject: [PATCH v2 01/27] x86: fix eflags tracking
The "from" line must be the very first line in the message body,
and has the form:
@ -718,8 +718,21 @@ generates appropriate diffstats by default.)
See more details on the proper patch format in the following
references.
15) Explicit In-Reply-To headers
--------------------------------
15) Sending "git pull" requests
It can be helpful to manually add In-Reply-To: headers to a patch
(e.g., when using "git send email") to associate the patch with
previous relevant discussion, e.g. to link a bug fix to the email with
the bug report. However, for a multi-patch series, it is generally
best to avoid using In-Reply-To: to link to older versions of the
series. This way multiple versions of the patch don't become an
unmanageable forest of references in email clients. If a link is
helpful, you can use the https://lkml.kernel.org/ redirector (e.g., in
the cover email text) to link to an earlier version of the patch series.
16) Sending "git pull" requests
-------------------------------
If you have a series of patches, it may be most convenient to have the

11
Documentation/acpi/enumeration.txt
View File

@ -347,13 +347,18 @@ For the first case, the MFD drivers do not need to do anything. The
resulting child platform device will have its ACPI_COMPANION() set to point
to the parent device.
If the ACPI namespace has a device that we can match using an ACPI id,
the id should be set like:
If the ACPI namespace has a device that we can match using an ACPI id or ACPI
adr, the cell should be set like:
static struct mfd_cell_acpi_match my_subdevice_cell_acpi_match = {
.pnpid = "XYZ0001",
.adr = 0,
};
static struct mfd_cell my_subdevice_cell = {
.name = "my_subdevice",
/* set the resources relative to the parent */
.acpi_pnpid = "XYZ0001",
.acpi_match = &my_subdevice_cell_acpi_match,
};
The ACPI id "XYZ0001" is then used to lookup an ACPI device directly under

58
Documentation/acpi/i2c-muxes.txt Normal file
View File

@ -0,0 +1,58 @@
ACPI I2C Muxes
--------------
Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
Device () scope per mux channel.
Consider this topology:
+------+ +------+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+------+ +------+
which corresponds to the following ASL:
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^SMB1", 0x00,
ResourceConsumer,,)
}
Device (CH00)
{
Name (_ADR, 0)
Device (CLIA)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH00", 0x00,
ResourceConsumer,,)
}
}
}
Device (CH01)
{
Name (_ADR, 1)
Device (CLIB)
{
Name (_HID, ...)
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}

7
Documentation/arm/OMAP/README Normal file
View File

@ -0,0 +1,7 @@
This file contains documentation for running mainline
kernel on omaps.
KERNEL NEW DEPENDENCIES
v4.3+ Update is needed for custom .config files to make sure
CONFIG_REGULATOR_PBIAS is enabled for MMC1 to work
properly.

16
Documentation/arm/SA1100/Victor
View File

@ -1,16 +0,0 @@
Victor is known as a "digital talking book player" manufactured by
VisuAide, Inc. to be used by blind people.
For more information related to Victor, see:
http://www.humanware.com/en-usa/products
Of course Victor is using Linux as its main operating system.
The Victor implementation for Linux is maintained by Nicolas Pitre:
nico@visuaide.com
nico@fluxnic.net
For any comments, please feel free to contact me through the above
addresses.

5
Documentation/arm/Samsung/Bootloader-interface.txt
View File

@ -19,7 +19,7 @@ executing kernel.
Address: sysram_ns_base_addr
Offset Value Purpose
=============================================================================
0x08 exynos_cpu_resume_ns System suspend
0x08 exynos_cpu_resume_ns, mcpm_entry_point System suspend
0x0c 0x00000bad (Magic cookie) System suspend
0x1c exynos4_secondary_startup Secondary CPU boot
0x1c + 4*cpu exynos4_secondary_startup (Exynos4412) Secondary CPU boot
@ -56,7 +56,8 @@ Offset Value Purpose
Address: pmu_base_addr
Offset Value Purpose
=============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
0x0908 Non-zero Secondary CPU boot up indicator
on Exynos3250 and Exynos542x
4. Glossary

56
Documentation/arm/keystone/knav-qmss.txt Normal file
View File

@ -0,0 +1,56 @@
* Texas Instruments Keystone Navigator Queue Management SubSystem driver
Driver source code path
drivers/soc/ti/knav_qmss.c
drivers/soc/ti/knav_qmss_acc.c
The QMSS (Queue Manager Sub System) found on Keystone SOCs is one of
the main hardware sub system which forms the backbone of the Keystone
multi-core Navigator. QMSS consist of queue managers, packed-data structure
processors(PDSP), linking RAM, descriptor pools and infrastructure
Packet DMA.
The Queue Manager is a hardware module that is responsible for accelerating
management of the packet queues. Packets are queued/de-queued by writing or
reading descriptor address to a particular memory mapped location. The PDSPs
perform QMSS related functions like accumulation, QoS, or event management.
Linking RAM registers are used to link the descriptors which are stored in
descriptor RAM. Descriptor RAM is configurable as internal or external memory.
The QMSS driver manages the PDSP setups, linking RAM regions,
queue pool management (allocation, push, pop and notify) and descriptor
pool management.
knav qmss driver provides a set of APIs to drivers to open/close qmss queues,
allocate descriptor pools, map the descriptors, push/pop to queues etc. For
details of the available APIs, please refers to include/linux/soc/ti/knav_qmss.h
DT documentation is available at
Documentation/devicetree/bindings/soc/ti/keystone-navigator-qmss.txt
Accumulator QMSS queues using PDSP firmware
============================================
The QMSS PDSP firmware support accumulator channel that can monitor a single
queue or multiple contiguous queues. drivers/soc/ti/knav_qmss_acc.c is the
driver that interface with the accumulator PDSP. This configures
accumulator channels defined in DTS (example in DT documentation) to monitor
1 or 32 queues per channel. More description on the firmware is available in
CPPI/QMSS Low Level Driver document (docs/CPPI_QMSS_LLD_SDS.pdf) at
git://git.ti.com/keystone-rtos/qmss-lld.git
k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin firmware supports upto 48 accumulator
channels. This firmware is available under ti-keystone folder of
firmware.git at
git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
To use copy the firmware image to lib/firmware folder of the initramfs or
ubifs file system and provide a sym link to k2_qmss_pdsp_acc48_k2_le_1_0_0_9.bin
in the file system and boot up the kernel. User would see
"firmware file ks2_qmss_pdsp_acc48.bin downloaded for PDSP"
in the boot up log if loading of firmware to PDSP is successful.
Use of accumulated queues requires the firmware image to be present in the
file system. The driver doesn't acc queues to the supported queue range if
PDSP is not running in the SoC. The API call fails if there is a queue open
request to an acc queue and PDSP is not running. So make sure to copy firmware
to file system before using these queue types.

2
Documentation/arm/memory.txt
View File

@ -54,7 +54,7 @@ VMALLOC_START VMALLOC_END-1 vmalloc() / ioremap() space.
located here through iotable_init().
VMALLOC_START is based upon the value
of the high_memory variable, and VMALLOC_END
is equal to 0xff000000.
is equal to 0xff800000.
PAGE_OFFSET high_memory-1 Kernel direct-mapped RAM region.
This maps the platforms RAM, and typically

2
Documentation/arm/sunxi/README
View File

@ -25,7 +25,7 @@ SunXi family
+ Datasheet
http://dl.linux-sunxi.org/A10s/A10s%20Datasheet%20-%20v1.20%20%282012-03-27%29.pdf
- Allwinner A13 (sun5i)
- Allwinner A13 / R8 (sun5i)
+ Datasheet
http://dl.linux-sunxi.org/A13/A13%20Datasheet%20-%20v1.12%20%282012-03-29%29.pdf
+ User Manual

4
Documentation/arm/uefi.txt
View File

@ -58,7 +58,3 @@ linux,uefi-mmap-desc-size | 32-bit | Size in bytes of each entry in the UEFI
--------------------------------------------------------------------------------
linux,uefi-mmap-desc-ver | 32-bit | Version of the mmap descriptor format.
--------------------------------------------------------------------------------
linux,uefi-stub-kern-ver | string | Copy of linux_banner from build.
--------------------------------------------------------------------------------
For verbose debug messages, specify 'uefi_debug' on the kernel command line.

18
Documentation/arm64/booting.txt
View File

@ -104,7 +104,12 @@ Header notes:
- The flags field (introduced in v3.17) is a little-endian 64-bit field
composed as follows:
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
Bits 1-63: Reserved.
Bit 1-2: Kernel Page size.
0 - Unspecified.
1 - 4K
2 - 16K
3 - 64K
Bits 3-63: Reserved.
- When image_size is zero, a bootloader should attempt to keep as much
memory as possible free for use by the kernel immediately after the
@ -173,13 +178,22 @@ Before jumping into the kernel, the following conditions must be met:
the kernel image will be entered must be initialised by software at a
higher exception level to prevent execution in an UNKNOWN state.
For systems with a GICv3 interrupt controller:
For systems with a GICv3 interrupt controller to be used in v3 mode:
- If EL3 is present:
ICC_SRE_EL3.Enable (bit 3) must be initialiased to 0b1.
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b1.
- If the kernel is entered at EL1:
ICC.SRE_EL2.Enable (bit 3) must be initialised to 0b1
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b1.
- The DT or ACPI tables must describe a GICv3 interrupt controller.
For systems with a GICv3 interrupt controller to be used in
compatibility (v2) mode:
- If EL3 is present:
ICC_SRE_EL3.SRE (bit 0) must be initialised to 0b0.
- If the kernel is entered at EL1:
ICC_SRE_EL2.SRE (bit 0) must be initialised to 0b0.
- The DT or ACPI tables must describe a GICv2 interrupt controller.
The requirements described above for CPU mode, caches, MMUs, architected
timers, coherency and system registers apply to all CPUs. All CPUs must

4
Documentation/atomic_ops.txt
View File

@ -542,6 +542,10 @@ The routines xchg() and cmpxchg() must provide the same exact
memory-barrier semantics as the atomic and bit operations returning
values.
Note: If someone wants to use xchg(), cmpxchg() and their variants,
linux/atomic.h should be included rather than asm/cmpxchg.h, unless
the code is in arch/* and can take care of itself.
Spinlocks and rwlocks have memory barrier expectations as well.
The rule to follow is simple:

119
Documentation/block/pr.txt Normal file
View File

@ -0,0 +1,119 @@
Block layer support for Persistent Reservations
===============================================
The Linux kernel supports a user space interface for simplified
Persistent Reservations which map to block devices that support
these (like SCSI). Persistent Reservations allow restricting
access to block devices to specific initiators in a shared storage
setup.
This document gives a general overview of the support ioctl commands.
For a more detailed reference please refer the the SCSI Primary
Commands standard, specifically the section on Reservations and the
"PERSISTENT RESERVE IN" and "PERSISTENT RESERVE OUT" commands.
All implementations are expected to ensure the reservations survive
a power loss and cover all connections in a multi path environment.
These behaviors are optional in SPC but will be automatically applied
by Linux.
The following types of reservations are supported:
--------------------------------------------------
- PR_WRITE_EXCLUSIVE
Only the initiator that owns the reservation can write to the
device. Any initiator can read from the device.
- PR_EXCLUSIVE_ACCESS
Only the initiator that owns the reservation can access the
device.
- PR_WRITE_EXCLUSIVE_REG_ONLY
Only initiators with a registered key can write to the device,
Any initiator can read from the device.
- PR_EXCLUSIVE_ACCESS_REG_ONLY
Only initiators with a registered key can access the device.
- PR_WRITE_EXCLUSIVE_ALL_REGS
Only initiators with a registered key can write to the device,
Any initiator can read from the device.
All initiators with a registered key are considered reservation
holders.
Please reference the SPC spec on the meaning of a reservation
holder if you want to use this type.
- PR_EXCLUSIVE_ACCESS_ALL_REGS
Only initiators with a registered key can access the device.
All initiators with a registered key are considered reservation
holders.
Please reference the SPC spec on the meaning of a reservation
holder if you want to use this type.
The following ioctl are supported:
----------------------------------
1. IOC_PR_REGISTER
This ioctl command registers a new reservation if the new_key argument
is non-null. If no existing reservation exists old_key must be zero,
if an existing reservation should be replaced old_key must contain
the old reservation key.
If the new_key argument is 0 it unregisters the existing reservation passed
in old_key.
2. IOC_PR_RESERVE
This ioctl command reserves the device and thus restricts access for other
devices based on the type argument. The key argument must be the existing
reservation key for the device as acquired by the IOC_PR_REGISTER,
IOC_PR_REGISTER_IGNORE, IOC_PR_PREEMPT or IOC_PR_PREEMPT_ABORT commands.
3. IOC_PR_RELEASE
This ioctl command releases the reservation specified by key and flags
and thus removes any access restriction implied by it.
4. IOC_PR_PREEMPT
This ioctl command releases the existing reservation referred to by
old_key and replaces it with a a new reservation of type for the
reservation key new_key.
5. IOC_PR_PREEMPT_ABORT
This ioctl command works like IOC_PR_PREEMPT except that it also aborts
any outstanding command sent over a connection identified by old_key.
6. IOC_PR_CLEAR
This ioctl command unregisters both key and any other reservation key
registered with the device and drops any existing reservation.
Flags
-----
All the ioctls have a flag field. Currently only one flag is supported:
- PR_FL_IGNORE_KEY
Ignore the existing reservation key. This is commonly supported for
IOC_PR_REGISTER, and some implementation may support the flag for
IOC_PR_RESERVE.
For all unknown flags the kernel will return -EOPNOTSUPP.

44
Documentation/blockdev/zram.txt
View File

@ -14,8 +14,43 @@ Statistics for individual zram devices are exported through sysfs nodes at
* Usage
There are several ways to configure and manage zram device(-s):
a) using zram and zram_control sysfs attributes
b) using zramctl utility, provided by util-linux (util-linux@vger.kernel.org).
In this document we will describe only 'manual' zram configuration steps,
IOW, zram and zram_control sysfs attributes.
In order to get a better idea about zramctl please consult util-linux
documentation, zramctl man-page or `zramctl --help'. Please be informed
that zram maintainers do not develop/maintain util-linux or zramctl, should
you have any questions please contact util-linux@vger.kernel.org
Following shows a typical sequence of steps for using zram.
WARNING
=======
For the sake of simplicity we skip error checking parts in most of the
examples below. However, it is your sole responsibility to handle errors.
zram sysfs attributes always return negative values in case of errors.
The list of possible return codes:
-EBUSY -- an attempt to modify an attribute that cannot be changed once
the device has been initialised. Please reset device first;
-ENOMEM -- zram was not able to allocate enough memory to fulfil your
needs;
-EINVAL -- invalid input has been provided.
If you use 'echo', the returned value that is changed by 'echo' utility,
and, in general case, something like:
echo 3 > /sys/block/zram0/max_comp_streams
if [ $? -ne 0 ];
handle_error
fi
should suffice.
1) Load Module:
modprobe zram num_devices=4
This creates 4 devices: /dev/zram{0,1,2,3}
@ -47,7 +82,7 @@ max_comp_streams adjustment.
3) Select compression algorithm
Using comp_algorithm device attribute one can see available and
currently selected (shown in square brackets) compression algortithms,
currently selected (shown in square brackets) compression algorithms,
change selected compression algorithm (once the device is initialised
there is no way to change compression algorithm).
@ -119,7 +154,7 @@ execute
8) Stats:
Per-device statistics are exported as various nodes under /sys/block/zram<id>/
A brief description of exported device attritbutes. For more details please
A brief description of exported device attributes. For more details please
read Documentation/ABI/testing/sysfs-block-zram.
Name access description
@ -140,8 +175,9 @@ zero_pages RO the number of zero filled pages written to this disk
orig_data_size RO uncompressed size of data stored in this disk
compr_data_size RO compressed size of data stored in this disk
mem_used_total RO the amount of memory allocated for this disk
mem_used_max RW the maximum amount memory zram have consumed to
store compressed data
mem_used_max RW the maximum amount of memory zram have consumed to
store the data (to reset this counter to the actual
current value, write 1 to this attribute)
mem_limit RW the maximum amount of memory ZRAM can use to store
the compressed data
pages_compacted RO the number of pages freed during compaction

2
Documentation/cgroups/blkio-controller.txt
View File

@ -59,7 +59,7 @@ cgroups. Here is what you can do.
- At macro level, first dd should finish first. To get more precise data, keep
on looking at (with the help of script), at blkio.disk_time and
blkio.disk_sectors files of both test1 and test2 groups. This will tell how
much disk time (in milli seconds), each group got and how many secotors each
much disk time (in milliseconds), each group got and how many sectors each
group dispatched to the disk. We provide fairness in terms of disk time, so
ideally io.disk_time of cgroups should be in proportion to the weight.

4
Documentation/cgroups/cgroups.txt
View File

@ -637,6 +637,10 @@ void exit(struct task_struct *task)
Called during task exit.
void free(struct task_struct *task)
Called when the task_struct is freed.
void bind(struct cgroup *root)
(cgroup_mutex held by caller)

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

@ -50,7 +50,7 @@ being frozen. This allows the bash example above and gdb to run as
expected.
The cgroup freezer is hierarchical. Freezing a cgroup freezes all
tasks beloning to the cgroup and all its descendant cgroups. Each
tasks belonging 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.

27
Documentation/cgroups/unified-hierarchy.txt
View File

@ -107,12 +107,6 @@ root of unified hierarchy can be bound to other hierarchies. This
allows mixing unified hierarchy with the traditional multiple
hierarchies in a fully backward compatible way.
For development purposes, the following boot parameter makes all
controllers to appear on the unified hierarchy whether supported or
not.
cgroup__DEVEL__legacy_files_on_dfl
A controller can be moved across hierarchies only after the controller
is no longer referenced in its current hierarchy. Because per-cgroup
controller states are destroyed asynchronously and controllers may
@ -341,11 +335,11 @@ is riddled with issues.
unnecessarily complicated and probably done this way because event
delivery itself was expensive.
Unified hierarchy implements an interface file "cgroup.populated"
which can be used to monitor whether the cgroup's subhierarchy has
tasks in it or not. Its value is 0 if there is no task in the cgroup
and its descendants; otherwise, 1. poll and [id]notify events are
triggered when the value changes.
Unified hierarchy implements "populated" field in "cgroup.events"
interface file which can be used to monitor whether the cgroup's
subhierarchy has tasks in it or not. Its value is 0 if there is no
task in the cgroup and its descendants; otherwise, 1. poll and
[id]notify events are triggered when the value changes.
This is significantly lighter and simpler and trivially allows
delegating management of subhierarchy - subhierarchy monitoring can
@ -374,6 +368,10 @@ supported and the interface files "release_agent" and
- The "cgroup.clone_children" file is removed.
- /proc/PID/cgroup keeps reporting the cgroup that a zombie belonged
to before exiting. If the cgroup is removed before the zombie is
reaped, " (deleted)" is appeneded to the path.
5-3. Controller File Conventions
@ -435,6 +433,11 @@ may be specified in any order and not all pairs have to be specified.
the first entry in the file. Specific entries can use "default" as
its value to indicate inheritance of the default value.
- For events which are not very high frequency, an interface file
"events" should be created which lists event key value pairs.
Whenever a notifiable event happens, file modified event should be
generated on the file.
5-4. Per-Controller Changes
@ -491,7 +494,7 @@ may be specified in any order and not all pairs have to be specified.
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
read/write IOs per second. "max" indicates no limit. Writing
to the file follows the same format but the individual
settings may be ommitted or specified in any order.
settings may be omitted or specified in any order.
This file is available only on non-root cgroups.

25
Documentation/crypto/asymmetric-keys.txt
View File

@ -186,7 +186,7 @@ and looks like the following:
const struct public_key_signature *sig);
};
Asymmetric keys point to this with their type_data[0] member.
Asymmetric keys point to this with their payload[asym_subtype] member.
The owner and name fields should be set to the owning module and the name of
the subtype. Currently, the name is only used for print statements.
@ -269,8 +269,7 @@ mandatory:
struct key_preparsed_payload {
char *description;
void *type_data[2];
void *payload;
void *payload[4];
const void *data;
size_t datalen;
size_t quotalen;
@ -283,16 +282,18 @@ mandatory:
not theirs.
If the parser is happy with the blob, it should propose a description for
the key and attach it to ->description, ->type_data[0] should be set to
point to the subtype to be used, ->payload should be set to point to the
initialised data for that subtype, ->type_data[1] should point to a hex
fingerprint and quotalen should be updated to indicate how much quota this
key should account for.
the key and attach it to ->description, ->payload[asym_subtype] should be
set to point to the subtype to be used, ->payload[asym_crypto] should be
set to point to the initialised data for that subtype,
->payload[asym_key_ids] should point to one or more hex fingerprints and
quotalen should be updated to indicate how much quota this key should
account for.
When clearing up, the data attached to ->type_data[1] and ->description
will be kfree()'d and the data attached to ->payload will be passed to the
subtype's ->destroy() method to be disposed of. A module reference for
the subtype pointed to by ->type_data[0] will be put.
When clearing up, the data attached to ->payload[asym_key_ids] and
->description will be kfree()'d and the data attached to
->payload[asm_crypto] will be passed to the subtype's ->destroy() method
to be disposed of. A module reference for the subtype pointed to by
->payload[asym_subtype] will be put.
If the data format is not recognised, -EBADMSG should be returned. If it

1
Documentation/device-mapper/delay.txt
View File

@ -8,6 +8,7 @@ Parameters:
<device> <offset> <delay> [<write_device> <write_offset> <write_delay>]
With separate write parameters, the first set is only used for reads.
Offsets are specified in sectors.
Delays are specified in milliseconds.
Example scripts

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

@ -41,9 +41,13 @@ useless and be disabled, returning errors. So it is important to monitor
the amount of free space and expand the <COW device> before it fills up.
<persistent?> is P (Persistent) or N (Not persistent - will not survive
after reboot).
The difference is that for transient snapshots less metadata must be
saved on disk - they can be kept in memory by the kernel.
after reboot). O (Overflow) can be added as a persistent store option
to allow userspace to advertise its support for seeing "Overflow" in the
snapshot status. So supported store types are "P", "PO" and "N".
The difference between persistent and transient is with transient
snapshots less metadata must be saved on disk - they can be kept in
memory by the kernel.
* snapshot-merge <origin> <COW device> <persistent> <chunksize>

10
Documentation/devicetree/bindings/arm/amlogic.txt
View File

@ -9,6 +9,12 @@ Boards with the Amlogic Meson8 SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8";
Boards with the Amlogic Meson8b SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8b";
Board compatible values:
- "geniatech,atv1200"
- "minix,neo-x8"
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "tronfy,mxq" (Meson8b)
- "hardkernel,odroid-c1" (Meson8b)

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

@ -0,0 +1,17 @@
APM X-GENE SoC series SCU Registers
This system clock unit contain various register that control block resets,
clock enable/disables, clock divisors and other deepsleep registers.
Properties:
- compatible : should contain two values. First value must be:
- "apm,xgene-scu"
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
scu: system-clk-controller@17000000 {
compatible = "apm,xgene-scu","syscon";
reg = <0x0 0x17000000 0x0 0x400>;
};

188
Documentation/devicetree/bindings/arm/arm,scpi.txt Normal file
View File

@ -0,0 +1,188 @@
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be "arm,scpi"
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM on Juno
The rest of the properties should follow the generic mmio-sram description
found in ../../misc/sysram.txt
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor
ID) as used by the firmware. Refer to
platform documentation for your
implementation for the IDs to use. For Juno
R0 and Juno R1 refer to [3].
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal.txt
[3] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.

162
Documentation/devicetree/bindings/arm/bcm/brcm,brcmstb.txt
View File

@ -20,6 +20,25 @@ system control is required:
- compatible: "brcm,bcm<chip_id>-hif-cpubiuctrl", "syscon"
- compatible: "brcm,bcm<chip_id>-hif-continuation", "syscon"
hif-cpubiuctrl node
-------------------
SoCs with Broadcom Brahma15 ARM-based CPUs have a specific Bus Interface Unit
(BIU) block which controls and interfaces the CPU complex to the different
Memory Controller Ports (MCP), one per memory controller (MEMC). This BIU block
offers a feature called Write Pairing which consists in collapsing two adjacent
cache lines into a single (bursted) write transaction towards the memory
controller (MEMC) to maximize write bandwidth.
Required properties:
- compatible: must be "brcm,bcm7445-hif-cpubiuctrl", "syscon"
Optional properties:
- brcm,write-pairing:
Boolean property, which when present indicates that the chip
supports write-pairing.
example:
rdb {
#address-cells = <1>;
@ -35,6 +54,7 @@ example:
hif_cpubiuctrl: syscon@3e2400 {
compatible = "brcm,bcm7445-hif-cpubiuctrl", "syscon";
reg = <0x3e2400 0x5b4>;
brcm,write-pairing;
};
hif_continuation: syscon@452000 {
@ -43,8 +63,7 @@ example:
};
};
Lastly, nodes that allow for support of SMP initialization and reboot are
required:
Nodes that allow for support of SMP initialization and reboot are required:
smpboot
-------
@ -95,3 +114,142 @@ example:
compatible = "brcm,brcmstb-reboot";
syscon = <&sun_top_ctrl 0x304 0x308>;
};
Power management
----------------
For power management (particularly, S2/S3/S5 system suspend), the following SoC
components are needed:
= Always-On control block (AON CTRL)
This hardware provides control registers for the "always-on" (even in low-power
modes) hardware, such as the Power Management State Machine (PMSM).
Required properties:
- compatible : should contain "brcm,brcmstb-aon-ctrl"
- reg : the register start and length for the AON CTRL block
Example:
aon-ctrl@410000 {
compatible = "brcm,brcmstb-aon-ctrl";
reg = <0x410000 0x400>;
};
= Memory controllers
A Broadcom STB SoC typically has a number of independent memory controllers,
each of which may have several associated hardware blocks, which are versioned
independently (control registers, DDR PHYs, etc.). One might consider
describing these controllers as a parent "memory controllers" block, which
contains N sub-nodes (one for each controller in the system), each of which is
associated with a number of hardware register resources (e.g., its PHY). See
the example device tree snippet below.
== MEMC (MEMory Controller)
Represents a single memory controller instance.
Required properties:
- compatible : should contain "brcm,brcmstb-memc" and "simple-bus"
Should contain subnodes for any of the following relevant hardware resources:
== DDR PHY control
Control registers for this memory controller's DDR PHY.
Required properties:
- compatible : should contain one of these
"brcm,brcmstb-ddr-phy-v225.1"
"brcm,brcmstb-ddr-phy-v240.1"
"brcm,brcmstb-ddr-phy-v240.2"
- reg : the DDR PHY register range
== DDR SHIMPHY
Control registers for this memory controller's DDR SHIMPHY.
Required properties:
- compatible : should contain "brcm,brcmstb-ddr-shimphy-v1.0"
- reg : the DDR SHIMPHY register range
== MEMC DDR control
Sequencer DRAM parameters and control registers. Used for Self-Refresh
Power-Down (SRPD), among other things.
Required properties:
- compatible : should contain "brcm,brcmstb-memc-ddr"
- reg : the MEMC DDR register range
Example:
memory_controllers {
ranges;
compatible = "simple-bus";
memc@0 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1106000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1106000 0x21c>;
};
shimphy@f1108000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1108000 0xe4>;
};
memc-ddr@f1102000 {
reg = <0xf1102000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@1 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1186000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1186000 0x21c>;
};
shimphy@f1188000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1188000 0xe4>;
};
memc-ddr@f1182000 {
reg = <0xf1182000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
memc@2 {
compatible = "brcm,brcmstb-memc", "simple-bus";
ranges;
ddr-phy@f1206000 {
compatible = "brcm,brcmstb-ddr-phy-v240.1";
reg = <0xf1206000 0x21c>;
};
shimphy@f1208000 {
compatible = "brcm,brcmstb-ddr-shimphy-v1.0";
reg = <0xf1208000 0xe4>;
};
memc-ddr@f1202000 {
reg = <0xf1202000 0x800>;
compatible = "brcm,brcmstb-memc-ddr";
};
};
};

34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt Normal file
View File

@ -0,0 +1,34 @@
Broadcom Northstar Plus device tree bindings
--------------------------------------------
Broadcom Northstar Plus family of SoCs are used for switching control
and management applications as well as residential router/gateway
applications. The SoC features dual core Cortex A9 ARM CPUs, integrating
several peripheral interfaces including multiple Gigabit Ethernet PHYs,
DDR3 memory, PCIE Gen-2, USB 2.0 and USB 3.0, serial and NAND flash,
SATA and several other IO controllers.
Boards with Northstar Plus SoCs shall have the following properties:
Required root node property:
BCM58522
compatible = "brcm,bcm58522", "brcm,nsp";
BCM58525
compatible = "brcm,bcm58525", "brcm,nsp";
BCM58535
compatible = "brcm,bcm58535", "brcm,nsp";
BCM58622
compatible = "brcm,bcm58622", "brcm,nsp";
BCM58623
compatible = "brcm,bcm58623", "brcm,nsp";
BCM58625
compatible = "brcm,bcm58625", "brcm,nsp";
BCM88312
compatible = "brcm,bcm88312", "brcm,nsp";

5
Documentation/devicetree/bindings/arm/coherency-fabric.txt
View File

@ -27,6 +27,11 @@ Required properties:
* For "marvell,armada-380-coherency-fabric", only one pair is needed
for the per-CPU fabric registers.
Optional properties:
- broken-idle: boolean to set when the Idle mode is not supported by the
hardware.
Examples:
coherency-fabric@d0020200 {

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