Linux 4.4-rc1
-----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----- Merge tag 'v4.4-rc1' into patchwork Linux 4.4-rc1 * tag 'v4.4-rc1': (12900 commits) Linux 4.4-rc1 ARC: Fix silly typo in MAINTAINERS file ARC: cpu_relax() to be compiler barrier even for UP ARC: use ASL assembler mnemonic ARC: [arcompact] Handle bus error from userspace as Interrupt not exception ARC: remove extraneous header include f2fs: xattr simplifications squashfs: xattr simplifications 9p: xattr simplifications xattr handlers: Pass handler to operations instead of flags jffs2: Add missing capability check for listing trusted xattrs hfsplus: Remove unused xattr handler list operations ubifs: Remove unused security xattr handler vfs: Fix the posix_acl_xattr_list return value vfs: Check attribute names in posix acl xattr handers mpt3sas: fix inline markers on non inline function declarations dax: fix __dax_pmd_fault crash Revert "drm/rockchip: Convert the probe function to the generic drm_of_component_probe()" drm: Don't oops in drm_calc_timestamping_constants() if drm_vblank_init() wasn't called ALSA: pci: depend on ZONE_DMA ...
This commit is contained in:
commit
65b7f6d740
1
.mailmap
1
.mailmap
|
@ -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>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
48
Documentation/ABI/testing/configfs-stp-policy
Normal 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.
|
||||
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
43
Documentation/ABI/testing/sysfs-bus-iio-adc-hi8435
Normal 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
7
Documentation/ABI/testing/sysfs-bus-iio-chemical-vz89x
Normal 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
9
Documentation/ABI/testing/sysfs-bus-iio-humidity-hdc100x
Normal 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
8
Documentation/ABI/testing/sysfs-bus-iio-meas-spec
Normal 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
|
|
@ -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
49
Documentation/ABI/testing/sysfs-bus-intel_th-devices-gth
Normal 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
33
Documentation/ABI/testing/sysfs-bus-intel_th-devices-msc
Normal 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
24
Documentation/ABI/testing/sysfs-bus-intel_th-devices-pti
Normal 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
13
Documentation/ABI/testing/sysfs-bus-intel_th-output-devices
Normal 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).
|
|
@ -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
|
||||
|
|
|
@ -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
37
Documentation/ABI/testing/sysfs-class-fpga-manager
Normal 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
|
|
@ -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.
|
||||
|
|
|
@ -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
14
Documentation/ABI/testing/sysfs-class-stm
Normal 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
11
Documentation/ABI/testing/sysfs-class-stm_source
Normal 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
15
Documentation/ABI/testing/sysfs-driver-hid-corsair
Normal 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.
|
|
@ -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
|
|
@ -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
|
|
@ -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
|
|
@ -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
12
Documentation/ABI/testing/sysfs-driver-st
Normal 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.
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
2
Documentation/DocBook/.gitignore
vendored
|
@ -11,5 +11,7 @@
|
|||
*.png
|
||||
*.gif
|
||||
*.svg
|
||||
*.proc
|
||||
*.db
|
||||
media-indices.tmpl
|
||||
media-entities.tmpl
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
& 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>
|
|
@ -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
|
||||
|
||||
|
||||
|
|
|
@ -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">
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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".
|
||||
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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);
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
58
Documentation/acpi/i2c-muxes.txt
Normal 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
7
Documentation/arm/OMAP/README
Normal 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.
|
|
@ -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.
|
||||
|
|
@ -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
56
Documentation/arm/keystone/knav-qmss.txt
Normal 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.
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
119
Documentation/block/pr.txt
Normal 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.
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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)
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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.
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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
17
Documentation/devicetree/bindings/arm/apm/scu.txt
Normal 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
188
Documentation/devicetree/bindings/arm/arm,scpi.txt
Normal 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.
|
|
@ -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
34
Documentation/devicetree/bindings/arm/bcm/brcm,nsp.txt
Normal 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";
|
|
@ -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 {
|
||||
|
|
|
@ -195,6 +195,8 @@ nodes to be present and contain the properties described below.
|
|||
"marvell,armada-380-smp"
|
||||
"marvell,armada-390-smp"
|
||||
"marvell,armada-xp-smp"
|
||||
"mediatek,mt6589-smp"
|
||||
"mediatek,mt81xx-tz-smp"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
|
|
|
@ -128,10 +128,18 @@ Example:
|
|||
reg = <0x0 0x1ee0000 0x0 0x10000>;
|
||||
};
|
||||
|
||||
Freescale LS2085A SoC Device Tree Bindings
|
||||
------------------------------------------
|
||||
Freescale ARMv8 based Layerscape SoC family Device Tree Bindings
|
||||
----------------------------------------------------------------
|
||||
|
||||
LS2085A ARMv8 based Simulator model
|
||||
LS2080A ARMv8 based Simulator model
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2085a-simu", "fsl,ls2085a";
|
||||
- compatible = "fsl,ls2080a-simu", "fsl,ls2080a";
|
||||
|
||||
LS2080A ARMv8 based QDS Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2080a-qds", "fsl,ls2080a";
|
||||
|
||||
LS2080A ARMv8 based RDB Board
|
||||
Required root node properties:
|
||||
- compatible = "fsl,ls2080a-rdb", "fsl,ls2080a";
|
||||
|
||||
|
|
|
@ -20,6 +20,10 @@ HiKey Board
|
|||
Required root node properties:
|
||||
- compatible = "hisilicon,hi6220-hikey", "hisilicon,hi6220";
|
||||
|
||||
HiP05 D02 Board
|
||||
Required root node properties:
|
||||
- compatible = "hisilicon,hip05-d02";
|
||||
|
||||
Hisilicon system controller
|
||||
|
||||
Required properties:
|
||||
|
@ -166,6 +170,23 @@ Example:
|
|||
reboot-offset = <0x4>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon HiP05 PCIe-SAS system controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,pcie-sas-subctrl", "syscon";
|
||||
- reg : Register address and size
|
||||
|
||||
The HiP05 PCIe-SAS system controller is shared by PCIe and SAS controllers in
|
||||
HiP05 Soc to implement some basic configurations.
|
||||
|
||||
Example:
|
||||
/* for HiP05 PCIe-SAS system */
|
||||
pcie_sas: system_controller@0xb0000000 {
|
||||
compatible = "hisilicon,pcie-sas-subctrl", "syscon";
|
||||
reg = <0xb0000000 0x10000>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon CPU controller
|
||||
|
||||
|
|
|
@ -497,7 +497,7 @@ cpus {
|
|||
};
|
||||
|
||||
idle-states {
|
||||
entry-method = "arm,psci";
|
||||
entry-method = "psci";
|
||||
|
||||
CPU_RETENTION_0_0: cpu-retention-0-0 {
|
||||
compatible = "arm,idle-state";
|
||||
|
|
|
@ -9,12 +9,26 @@ Required properties:
|
|||
the form "ti,keystone-*". Generic devices like gic, arch_timers, ns16550
|
||||
type UART should use the specified compatible for those devices.
|
||||
|
||||
SoC families:
|
||||
|
||||
- Keystone 2 generic SoC:
|
||||
compatible = "ti,keystone"
|
||||
|
||||
SoCs:
|
||||
|
||||
- Keystone 2 Hawking/Kepler
|
||||
compatible = "ti,k2hk", "ti,keystone"
|
||||
- Keystone 2 Lamarr
|
||||
compatible = "ti,k2l", "ti,keystone"
|
||||
- Keystone 2 Edison
|
||||
compatible = "ti,k2e", "ti,keystone"
|
||||
|
||||
Boards:
|
||||
- Keystone 2 Hawking/Kepler EVM
|
||||
compatible = "ti,k2hk-evm","ti,keystone"
|
||||
compatible = "ti,k2hk-evm", "ti,k2hk", "ti,keystone"
|
||||
|
||||
- Keystone 2 Lamarr EVM
|
||||
compatible = "ti,k2l-evm","ti,keystone"
|
||||
compatible = "ti,k2l-evm", "ti, k2l", "ti,keystone"
|
||||
|
||||
- Keystone 2 Edison EVM
|
||||
compatible = "ti,k2e-evm","ti,keystone"
|
||||
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
|
||||
|
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek imgsys controller
|
||||
============================
|
||||
|
||||
The Mediatek imgsys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt8173-imgsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The imgsys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
imgsys: clock-controller@15000000 {
|
||||
compatible = "mediatek,mt8173-imgsys", "syscon";
|
||||
reg = <0 0x15000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek mmsys controller
|
||||
============================
|
||||
|
||||
The Mediatek mmsys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt8173-mmsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The mmsys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
mmsys: clock-controller@14000000 {
|
||||
compatible = "mediatek,mt8173-mmsys", "syscon";
|
||||
reg = <0 0x14000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek vdecsys controller
|
||||
============================
|
||||
|
||||
The Mediatek vdecsys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt8173-vdecsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The vdecsys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
vdecsys: clock-controller@16000000 {
|
||||
compatible = "mediatek,mt8173-vdecsys", "syscon";
|
||||
reg = <0 0x16000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek vencltsys controller
|
||||
============================
|
||||
|
||||
The Mediatek vencltsys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt8173-vencltsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The vencltsys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
vencltsys: clock-controller@19000000 {
|
||||
compatible = "mediatek,mt8173-vencltsys", "syscon";
|
||||
reg = <0 0x19000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
|
@ -0,0 +1,22 @@
|
|||
Mediatek vencsys controller
|
||||
============================
|
||||
|
||||
The Mediatek vencsys controller provides various clocks to the system.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: Should be:
|
||||
- "mediatek,mt8173-vencsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
The vencsys controller uses the common clk binding from
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
The available clocks are defined in dt-bindings/clock/mt*-clk.h.
|
||||
|
||||
Example:
|
||||
|
||||
vencsys: clock-controller@18000000 {
|
||||
compatible = "mediatek,mt8173-vencsys", "syscon";
|
||||
reg = <0 0x18000000 0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
20
Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
Normal file
20
Documentation/devicetree/bindings/arm/mvebu-cpu-config.txt
Normal file
|
@ -0,0 +1,20 @@
|
|||
MVEBU CPU Config registers
|
||||
--------------------------
|
||||
|
||||
MVEBU (Marvell SOCs: Armada 370/XP)
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: one of:
|
||||
- "marvell,armada-370-cpu-config"
|
||||
- "marvell,armada-xp-cpu-config"
|
||||
|
||||
- reg: Should contain CPU config registers location and length, in
|
||||
their per-CPU variant
|
||||
|
||||
Example:
|
||||
|
||||
cpu-config@21000 {
|
||||
compatible = "marvell,armada-xp-cpu-config";
|
||||
reg = <0x21000 0x8>;
|
||||
};
|
|
@ -7,7 +7,10 @@ representation in the device tree should be done as under:-
|
|||
Required properties:
|
||||
|
||||
- compatible : should be one of
|
||||
"apm,potenza-pmu"
|
||||
"arm,armv8-pmuv3"
|
||||
"arm.cortex-a57-pmu"
|
||||
"arm.cortex-a53-pmu"
|
||||
"arm,cortex-a17-pmu"
|
||||
"arm,cortex-a15-pmu"
|
||||
"arm,cortex-a12-pmu"
|
||||
|
|
|
@ -31,6 +31,10 @@ Main node required properties:
|
|||
support, but are permitted to be present for compatibility with
|
||||
existing software when "arm,psci" is later in the compatible list.
|
||||
|
||||
* "arm,psci-1.0" : for implementations complying to PSCI 1.0. PSCI 1.0 is
|
||||
backward compatible with PSCI 0.2 with minor specification updates,
|
||||
as defined in the PSCI specification[2].
|
||||
|
||||
- method : The method of calling the PSCI firmware. Permitted
|
||||
values are:
|
||||
|
||||
|
@ -100,3 +104,5 @@ Case 3: PSCI v0.2 and PSCI v0.1.
|
|||
|
||||
[1] Kernel documentation - ARM idle states bindings
|
||||
Documentation/devicetree/bindings/arm/idle-states.txt
|
||||
[2] Power State Coordination Interface (PSCI) specification
|
||||
http://infocenter.arm.com/help/topic/com.arm.doc.den0022c/DEN0022C_Power_State_Coordination_Interface.pdf
|
||||
|
|
|
@ -17,6 +17,10 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "radxa,rock", "rockchip,rk3188";
|
||||
|
||||
- Radxa Rock2 Square board:
|
||||
Required root node properties:
|
||||
- compatible = "radxa,rock2-square", "rockchip,rk3288";
|
||||
|
||||
- Firefly Firefly-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "firefly,firefly-rk3288", "rockchip,rk3288";
|
||||
|
@ -31,6 +35,13 @@ Rockchip platforms device tree bindings
|
|||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- Google Jaq (Haier Chromebook 11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jaq-rev5", "google,veyron-jaq-rev4",
|
||||
"google,veyron-jaq-rev3", "google,veyron-jaq-rev2",
|
||||
"google,veyron-jaq-rev1", "google,veyron-jaq",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Jerry (Hisense Chromebook C11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
|
||||
|
|
|
@ -1,27 +0,0 @@
|
|||
* Samsung's Exynos SoC based boards
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
|
||||
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
|
||||
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
|
||||
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
|
||||
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
|
||||
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
|
||||
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
|
||||
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
|
||||
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
|
||||
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
|
||||
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
|
||||
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
|
||||
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
|
||||
|
||||
Optional:
|
||||
- firmware node, specifying presence and type of secure firmware:
|
||||
- compatible: only "samsung,secure-firmware" is currently supported
|
||||
- reg: address of non-secure SYSRAM used for communication with firmware
|
||||
|
||||
firmware@0203F000 {
|
||||
compatible = "samsung,secure-firmware";
|
||||
reg = <0x0203F000 0x1000>;
|
||||
};
|
|
@ -0,0 +1,69 @@
|
|||
* Samsung's Exynos SoC based boards
|
||||
|
||||
Required root node properties:
|
||||
- compatible = should be one or more of the following.
|
||||
- "samsung,monk" - for Exynos3250-based Samsung Simband board.
|
||||
- "samsung,rinato" - for Exynos3250-based Samsung Gear2 board.
|
||||
- "samsung,smdkv310" - for Exynos4210-based Samsung SMDKV310 eval board.
|
||||
- "samsung,trats" - for Exynos4210-based Tizen Reference board.
|
||||
- "samsung,universal_c210" - for Exynos4210-based Samsung board.
|
||||
- "samsung,smdk4412", - for Exynos4412-based Samsung SMDK4412 eval board.
|
||||
- "samsung,trats2" - for Exynos4412-based Tizen Reference board.
|
||||
- "samsung,smdk5250" - for Exynos5250-based Samsung SMDK5250 eval board.
|
||||
- "samsung,xyref5260" - for Exynos5260-based Samsung board.
|
||||
- "samsung,smdk5410" - for Exynos5410-based Samsung SMDK5410 eval board.
|
||||
- "samsung,smdk5420" - for Exynos5420-based Samsung SMDK5420 eval board.
|
||||
- "samsung,sd5v1" - for Exynos5440-based Samsung board.
|
||||
- "samsung,ssdk5440" - for Exynos5440-based Samsung board.
|
||||
|
||||
* Other companies Exynos SoC based
|
||||
* FriendlyARM
|
||||
- "friendlyarm,tiny4412" - for Exynos4412-based FriendlyARM
|
||||
TINY4412 board.
|
||||
|
||||
* Google
|
||||
- "google,pi" - for Exynos5800-based Google Peach Pi
|
||||
Rev 10+ board,
|
||||
also: "google,pi-rev16", "google,pi-rev15", "google,pi-rev14",
|
||||
"google,pi-rev13", "google,pi-rev12", "google,pi-rev11",
|
||||
"google,pi-rev10", "google,peach".
|
||||
|
||||
- "google,pit" - for Exynos5420-based Google Peach Pit
|
||||
Rev 6+ (Exynos5420),
|
||||
also: "google,pit-rev16", "google,pit-rev15", "google,pit-rev14",
|
||||
"google,pit-rev13", "google,pit-rev12", "google,pit-rev11",
|
||||
"google,pit-rev10", "google,pit-rev9", "google,pit-rev8",
|
||||
"google,pit-rev7", "google,pit-rev6", "google,peach".
|
||||
|
||||
- "google,snow-rev4" - for Exynos5250-based Google Snow board,
|
||||
also: "google,snow"
|
||||
- "google,snow-rev5" - for Exynos5250-based Google Snow
|
||||
Rev 5+ board.
|
||||
- "google,spring" - for Exynos5250-based Google Spring board.
|
||||
|
||||
* Hardkernel
|
||||
- "hardkernel,odroid-u3" - for Exynos4412-based Hardkernel Odroid U3.
|
||||
- "hardkernel,odroid-x" - for Exynos4412-based Hardkernel Odroid X.
|
||||
- "hardkernel,odroid-x2" - for Exynos4412-based Hardkernel Odroid X2.
|
||||
- "hardkernel,odroid-xu3" - for Exynos5422-based Hardkernel Odroid XU3.
|
||||
- "hardkernel,odroid-xu3-lite" - for Exynos5422-based Hardkernel
|
||||
Odroid XU3 Lite board.
|
||||
- "hardkernel,odroid-xu4" - for Exynos5422-based Hardkernel Odroid XU4.
|
||||
|
||||
* Insignal
|
||||
- "insignal,arndale" - for Exynos5250-based Insignal Arndale board.
|
||||
- "insignal,arndale-octa" - for Exynos5420-based Insignal Arndale
|
||||
Octa board.
|
||||
- "insignal,origen" - for Exynos4210-based Insignal Origen board.
|
||||
- "insignal,origen4412 - for Exynos4412-based Insignal Origen board.
|
||||
|
||||
|
||||
Optional nodes:
|
||||
- firmware node, specifying presence and type of secure firmware:
|
||||
- compatible: only "samsung,secure-firmware" is currently supported
|
||||
- reg: address of non-secure SYSRAM used for communication with firmware
|
||||
|
||||
firmware@0203F000 {
|
||||
compatible = "samsung,secure-firmware";
|
||||
reg = <0x0203F000 0x1000>;
|
||||
};
|
|
@ -39,8 +39,6 @@ Boards:
|
|||
compatible = "renesas,armadillo800eva"
|
||||
- BOCK-W
|
||||
compatible = "renesas,bockw", "renesas,r8a7778"
|
||||
- BOCK-W - Reference Device Tree Implementation
|
||||
compatible = "renesas,bockw-reference", "renesas,r8a7778"
|
||||
- Genmai (RTK772100BC00000BR)
|
||||
compatible = "renesas,genmai", "renesas,r7s72100"
|
||||
- Gose
|
||||
|
@ -57,7 +55,7 @@ Boards:
|
|||
compatible = "renesas,lager", "renesas,r8a7790"
|
||||
- Marzen
|
||||
compatible = "renesas,marzen", "renesas,r8a7779"
|
||||
|
||||
Note: Reference Device Tree Implementations are temporary implementations
|
||||
to ease the migration from platform devices to Device Tree, and are
|
||||
intended to be removed in the future.
|
||||
- Porter (M2-LCDP)
|
||||
compatible = "renesas,porter", "renesas,r8a7791"
|
||||
- SILK (RTP0RC7794LCB00011S)
|
||||
compatible = "renesas,silk", "renesas,r8a7794"
|
||||
|
|
|
@ -6,6 +6,7 @@ using one of the following compatible strings:
|
|||
allwinner,sun4i-a10
|
||||
allwinner,sun5i-a10s
|
||||
allwinner,sun5i-a13
|
||||
allwinner,sun5i-r8
|
||||
allwinner,sun6i-a31
|
||||
allwinner,sun7i-a20
|
||||
allwinner,sun8i-a23
|
||||
|
|
Some files were not shown because too many files have changed in this diff Show more
Loading…
Reference in a new issue