Linux 4.3-rc1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJV9LbmAAoJEHm+PkMAQRiGb40IAJWcETZb6hoCUIrGZX+4Znqy UXYY9BwybF+3yPsTKWRUWQGifNhUiW7ejNgMO3QYG+E1RgJ6uj8Mym9I11+x3a9D beIem8Ftf1Zwt71zg6DpUCNhlRIfa3TTnbQMIYmoIihVwYWVve1/rMPD5kgafF6P Xnp7QSUh7uCK/G06sksK9aB2GkRgvoMKfAgTHmj094f24udl87NyUo8O8mP5QWX2 b0S5ZwlDRL64sio59QyxZK87f0TGnquDBLe6Gcl3wJQx/g3RzRpSxEkumylwx+S4 u9xeHlorOkg8a+k62TgbC6GP0Y6Ptk+yMF6UFCPsifwQTRvJubrA2ofdfPuggCk= =aqcb -----END PGP SIGNATURE----- Merge tag 'v4.3-rc1' into locking/core, to refresh the tree Signed-off-by: Ingo Molnar <mingo@kernel.org>hifive-unleashed-5.1
Ingo Molnar
commit
c7ef92cea9
|
|
@ -0,0 +1 @@
|
|||
Christoph Hellwig <hch@lst.de>
|
||||
|
|
@ -36,6 +36,7 @@
|
|||
modules.builtin
|
||||
Module.symvers
|
||||
*.dwo
|
||||
*.su
|
||||
|
||||
#
|
||||
# Top-level generic files
|
||||
|
|
@ -44,6 +45,7 @@ Module.symvers
|
|||
/TAGS
|
||||
/linux
|
||||
/vmlinux
|
||||
/vmlinux.32
|
||||
/vmlinux-gdb.py
|
||||
/vmlinuz
|
||||
/System.map
|
||||
|
|
@ -89,6 +91,9 @@ GRTAGS
|
|||
GSYMS
|
||||
GTAGS
|
||||
|
||||
# id-utils files
|
||||
ID
|
||||
|
||||
*.orig
|
||||
*~
|
||||
\#*#
|
||||
|
|
@ -97,6 +102,7 @@ GTAGS
|
|||
# Leavings from module signing
|
||||
#
|
||||
extra_certificates
|
||||
signing_key.pem
|
||||
signing_key.priv
|
||||
signing_key.x509
|
||||
x509.genkey
|
||||
|
|
|
|||
1
.mailmap
1
.mailmap
|
|
@ -17,6 +17,7 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
|||
Al Viro <viro@ftp.linux.org.uk>
|
||||
Al Viro <viro@zenIV.linux.org.uk>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
||||
Andrew Morton <akpm@linux-foundation.org>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
|
|
|
|||
13
CREDITS
13
CREDITS
|
|
@ -20,6 +20,10 @@ D: One of assisting postmasters for vger.kernel.org's lists
|
|||
S: (ask for current address)
|
||||
S: Finland
|
||||
|
||||
N: Thomas Abraham
|
||||
E: thomas.ab@samsung.com
|
||||
D: Samsung pin controller driver
|
||||
|
||||
N: Dragos Acostachioaie
|
||||
E: dragos@iname.com
|
||||
W: http://www.arbornet.org/~dragos
|
||||
|
|
@ -2988,6 +2992,10 @@ S: 2200 Mission College Blvd
|
|||
S: Santa Clara, CA 95052
|
||||
S: USA
|
||||
|
||||
N: Anil Ravindranath
|
||||
E: anil_ravindranath@pmc-sierra.com
|
||||
D: PMC-Sierra MaxRAID driver
|
||||
|
||||
N: Eric S. Raymond
|
||||
E: esr@thyrsus.com
|
||||
W: http://www.tuxedo.org/~esr/
|
||||
|
|
@ -3219,6 +3227,11 @@ S: 69 rue Dunois
|
|||
S: 75013 Paris
|
||||
S: France
|
||||
|
||||
N: Aleksa Sarai
|
||||
E: cyphar@cyphar.com
|
||||
W: https://www.cyphar.com/
|
||||
D: `pids` cgroup subsystem
|
||||
|
||||
N: Dipankar Sarma
|
||||
E: dipankar@in.ibm.com
|
||||
D: RCU
|
||||
|
|
|
|||
|
|
@ -0,0 +1,29 @@
|
|||
What: /sys/bus/vmbus/devices/vmbus_*/id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus child_relid of the device's primary channel
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/class_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface type GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/device_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface instance GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channel_vp_mapping
|
||||
Date: Jul 2015
|
||||
KernelVersion: 4.2.0
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The mapping of which primary/sub channels are bound to which
|
||||
Virtual Processors.
|
||||
Format: <channel's child_relid:the bound cpu's number>
|
||||
Users: tools/hv/lsvmbus
|
||||
|
|
@ -5,4 +5,4 @@ Description:
|
|||
The attributes:
|
||||
|
||||
qlen - depth of loopback queue
|
||||
bulk_buflen - buffer length
|
||||
buflen - buffer length
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Description:
|
|||
isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
|
||||
isoc_mult - 0..2 (hs/ss only)
|
||||
isoc_maxburst - 0..15 (ss only)
|
||||
qlen - buffer length
|
||||
buflen - buffer length
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ KernelVersion: 3.19
|
|||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (RW) Mask to apply to all the context ID comparator.
|
||||
|
||||
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
|
||||
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
|
||||
Date: November 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ KernelVersion: 4.01
|
|||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (RW) Select which context ID comparator to work with.
|
||||
|
||||
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_val
|
||||
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
|
||||
Date: April 2015
|
||||
KernelVersion: 4.01
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
|
|
|
|||
|
|
@ -413,6 +413,11 @@ Description:
|
|||
to compute the calories burnt by the user.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
|
||||
What: /sys/.../iio:deviceX/in_anglvel_scale_available
|
||||
What: /sys/.../iio:deviceX/in_magn_scale_available
|
||||
What: /sys/.../iio:deviceX/in_illuminance_scale_available
|
||||
What: /sys/.../iio:deviceX/in_intensity_scale_available
|
||||
What: /sys/.../iio:deviceX/in_proximity_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltageX_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
|
||||
What: /sys/.../iio:deviceX/out_voltageX_scale_available
|
||||
|
|
@ -488,7 +493,7 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
Specifies the output powerdown mode.
|
||||
DAC output stage is disconnected from the amplifier and
|
||||
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
|
||||
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
|
||||
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
|
||||
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
|
||||
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
|
||||
|
|
@ -498,9 +503,9 @@ Description:
|
|||
outX_powerdown_mode_available. If Y is not present the
|
||||
mode is shared across all outputs.
|
||||
|
||||
What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
|
||||
KernelVersion: 2.6.38
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
@ -1035,13 +1040,6 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
Number of scans contained by the buffer.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Bytes per scan. Due to alignment fun, the scan may be larger
|
||||
than implied directly by the scan_element parameters.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
|
|||
|
|
@ -9,3 +9,12 @@ Description:
|
|||
automated testing or in situations, where other trigger methods
|
||||
are not applicable. For example no RTC or spare GPIOs.
|
||||
X is the IIO index of the trigger.
|
||||
|
||||
What: /sys/bus/iio/devices/triggerX/name
|
||||
KernelVersion: 2.6.39
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The name attribute holds a description string for the current
|
||||
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.
|
||||
|
|
|
|||
|
|
@ -114,6 +114,20 @@ Description:
|
|||
enabled for the device. Developer can write y/Y/1 or n/N/0 to
|
||||
the file to enable/disable the feature.
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/usb3_hardware_lpm
|
||||
Date: June 2015
|
||||
Contact: Kevin Strasser <kevin.strasser@linux.intel.com>
|
||||
Description:
|
||||
If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
|
||||
in to a xHCI host which supports link PM, it will check if U1
|
||||
and U2 exit latencies have been set in the BOS descriptor; if
|
||||
the check is is passed and the host supports USB3 hardware LPM,
|
||||
USB3 hardware LPM will be enabled for the device and the USB
|
||||
device directory will contain a file named
|
||||
power/usb3_hardware_lpm. The file holds a string value (enable
|
||||
or disable) indicating whether or not USB3 hardware LPM is
|
||||
enabled for the device.
|
||||
|
||||
What: /sys/bus/usb/devices/.../removable
|
||||
Date: February 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
|
|
|
|||
|
|
@ -223,3 +223,13 @@ Description: write only
|
|||
Writing 1 will issue a PERST to card which may cause the card
|
||||
to reload the FPGA depending on load_image_on_perst.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
||||
What: /sys/class/cxl/<card>/perst_reloads_same_image
|
||||
Date: July 2015
|
||||
Contact: linuxppc-dev@lists.ozlabs.org
|
||||
Description: read/write
|
||||
Trust that when an image is reloaded via PERST, it will not
|
||||
have changed.
|
||||
0 = don't trust, the image may be different (default)
|
||||
1 = trust that the image will not change.
|
||||
Users: https://github.com/ibm-capi/libcxl
|
||||
|
|
|
|||
|
|
@ -0,0 +1,45 @@
|
|||
What: /sys/class/power_supply/twl4030_ac/max_current
|
||||
/sys/class/power_supply/twl4030_usb/max_current
|
||||
Description:
|
||||
Read/Write limit on current which may
|
||||
be drawn from the ac (Accessory Charger) or
|
||||
USB port.
|
||||
|
||||
Value is in micro-Amps.
|
||||
|
||||
Value is set automatically to an appropriate
|
||||
value when a cable is plugged or unplugged.
|
||||
|
||||
Value can the set by writing to the attribute.
|
||||
The change will only persist until the next
|
||||
plug event. These event are reported via udev.
|
||||
|
||||
|
||||
What: /sys/class/power_supply/twl4030_usb/mode
|
||||
Description:
|
||||
Changing mode for USB port.
|
||||
Writing to this can disable charging.
|
||||
|
||||
Possible values are:
|
||||
"auto" - draw power as appropriate for detected
|
||||
power source and battery status.
|
||||
"off" - do not draw any power.
|
||||
"continuous"
|
||||
- activate mode described as "linear" in
|
||||
TWL data sheets. This uses whatever
|
||||
current is available and doesn't switch off
|
||||
when voltage drops.
|
||||
|
||||
This is useful for unstable power sources
|
||||
such as bicycle dynamo, but care should
|
||||
be taken that battery is not over-charged.
|
||||
|
||||
What: /sys/class/power_supply/twl4030_ac/mode
|
||||
Description:
|
||||
Changing mode for 'ac' port.
|
||||
Writing to this can disable charging.
|
||||
|
||||
Possible values are:
|
||||
"auto" - draw power as appropriate for detected
|
||||
power source and battery status.
|
||||
"off" - do not draw any power.
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
What: /sys/devices/*/<our-device>/eeprom
|
||||
Date: August 2013
|
||||
Contact: Oliver Schinagl <oliver@schinagl.nl>
|
||||
Description: read-only access to the SID (Security-ID) on current
|
||||
A-series SoC's from Allwinner. Currently supports A10, A10s, A13
|
||||
and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
|
||||
whereas the newer A20 SoC exposes 512 bytes split into sections.
|
||||
Besides the 16 bytes of SID, there's also an SJTAG area,
|
||||
HDMI-HDCP key and some custom keys. Below a quick overview, for
|
||||
details see the user manual:
|
||||
0x000 128 bit root-key (sun[457]i)
|
||||
0x010 128 bit boot-key (sun7i)
|
||||
0x020 64 bit security-jtag-key (sun7i)
|
||||
0x028 16 bit key configuration (sun7i)
|
||||
0x02b 16 bit custom-vendor-key (sun7i)
|
||||
0x02c 320 bit low general key (sun7i)
|
||||
0x040 32 bit read-control access (sun7i)
|
||||
0x064 224 bit low general key (sun7i)
|
||||
0x080 2304 bit HDCP-key (sun7i)
|
||||
0x1a0 768 bit high general key (sun7i)
|
||||
Users: any user space application which wants to read the SID on
|
||||
Allwinner's A-series of CPU's.
|
||||
|
|
@ -77,3 +77,22 @@ Description:
|
|||
The format is also scrambled, like in the USB mode, and it can
|
||||
be summarized by converting 76543210 into GECA6420.
|
||||
HGFEDCBA HFDB7531
|
||||
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/unpair_remote
|
||||
Date: July 2015
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing the character sequence '*' followed by a newline to
|
||||
this file will delete all of the current pairings on the
|
||||
device. Other character sequences are reserved. This file is
|
||||
write only.
|
||||
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/remote_mode
|
||||
Date: July 2015
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Reading from this file reports the mode status of the
|
||||
remote as indicated by the LED lights on the device. If no
|
||||
reports have been received from the paired device, reading
|
||||
from this file will report '-1'. The mode is read-only
|
||||
and cannot be set through the driver.
|
||||
|
|
|
|||
|
|
@ -16,7 +16,8 @@ Description:
|
|||
/sys/class/gpio
|
||||
/export ... asks the kernel to export a GPIO to userspace
|
||||
/unexport ... to return a GPIO to the kernel
|
||||
/gpioN ... for each exported GPIO #N
|
||||
/gpioN ... for each exported GPIO #N OR
|
||||
/<LINE-NAME> ... for a properly named GPIO line
|
||||
/value ... always readable, writes fail for input GPIOs
|
||||
/direction ... r/w as: in, out (default low); write: high, low
|
||||
/edge ... r/w as: none, falling, rising, both
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
What: /sys/hypervisor/pmu/pmu_mode
|
||||
Date: August 2015
|
||||
KernelVersion: 4.3
|
||||
Contact: Boris Ostrovsky <boris.ostrovsky@oracle.com>
|
||||
Description:
|
||||
Describes mode that Xen's performance-monitoring unit (PMU)
|
||||
uses. Accepted values are
|
||||
"off" -- PMU is disabled
|
||||
"self" -- The guest can profile itself
|
||||
"hv" -- The guest can profile itself and, if it is
|
||||
privileged (e.g. dom0), the hypervisor
|
||||
"all" -- The guest can profile itself, the hypervisor
|
||||
and all other guests. Only available to
|
||||
privileged guests.
|
||||
|
||||
What: /sys/hypervisor/pmu/pmu_features
|
||||
Date: August 2015
|
||||
KernelVersion: 4.3
|
||||
Contact: Boris Ostrovsky <boris.ostrovsky@oracle.com>
|
||||
Description:
|
||||
Describes Xen PMU features (as an integer). A set bit indicates
|
||||
that the corresponding feature is enabled. See
|
||||
include/xen/interface/xenpmu.h for available features
|
||||
|
|
@ -43,6 +43,7 @@ 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
|
||||
|
||||
|
||||
Kernel compilation
|
||||
|
|
@ -79,6 +80,17 @@ BC
|
|||
You will need bc to build kernels 3.10 and higher
|
||||
|
||||
|
||||
OpenSSL
|
||||
-------
|
||||
|
||||
Module signing and external certificate handling use the OpenSSL program and
|
||||
crypto library to do key creation and signature generation.
|
||||
|
||||
You will need openssl to build kernels 3.7 and higher if module signing is
|
||||
enabled. You will also need openssl development packages to build kernels 4.3
|
||||
and higher.
|
||||
|
||||
|
||||
System utilities
|
||||
================
|
||||
|
||||
|
|
@ -295,6 +307,10 @@ Binutils
|
|||
--------
|
||||
o <ftp://ftp.kernel.org/pub/linux/devel/binutils/>
|
||||
|
||||
OpenSSL
|
||||
-------
|
||||
o <https://www.openssl.org/>
|
||||
|
||||
System utilities
|
||||
****************
|
||||
|
||||
|
|
@ -392,4 +408,3 @@ o <http://oprofile.sf.net/download/>
|
|||
NFS-Utils
|
||||
---------
|
||||
o <http://nfs.sourceforge.net/>
|
||||
|
||||
|
|
|
|||
|
|
@ -929,13 +929,11 @@ The C Programming Language, Second Edition
|
|||
by Brian W. Kernighan and Dennis M. Ritchie.
|
||||
Prentice Hall, Inc., 1988.
|
||||
ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
|
||||
URL: http://cm.bell-labs.com/cm/cs/cbook/
|
||||
|
||||
The Practice of Programming
|
||||
by Brian W. Kernighan and Rob Pike.
|
||||
Addison-Wesley, Inc., 1999.
|
||||
ISBN 0-201-61586-X.
|
||||
URL: http://cm.bell-labs.com/cm/cs/tpop/
|
||||
|
||||
GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
|
||||
gcc internals and indent, all available from http://www.gnu.org/manual/
|
||||
|
|
|
|||
|
|
@ -104,6 +104,13 @@ crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated
|
|||
from this pool must not cross 4KByte boundaries.
|
||||
|
||||
|
||||
void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
|
||||
dma_addr_t *handle)
|
||||
|
||||
Wraps dma_pool_alloc() and also zeroes the returned memory if the
|
||||
allocation attempt succeeded.
|
||||
|
||||
|
||||
void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
|
||||
dma_addr_t *dma_handle);
|
||||
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.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 \
|
||||
writing_musb_glue_layer.xml crypto-API.xml
|
||||
writing_musb_glue_layer.xml crypto-API.xml iio.xml
|
||||
|
||||
include Documentation/DocBook/media/Makefile
|
||||
|
||||
|
|
@ -56,16 +56,19 @@ htmldocs: $(HTML)
|
|||
|
||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||
mandocs: $(MAN)
|
||||
find $(obj)/man -name '*.9' | xargs gzip -f
|
||||
find $(obj)/man -name '*.9' | xargs gzip -nf
|
||||
|
||||
installmandocs: mandocs
|
||||
mkdir -p /usr/local/man/man9/
|
||||
install $(obj)/man/*.9.gz /usr/local/man/man9/
|
||||
find $(obj)/man -name '*.9.gz' -printf '%h %f\n' | \
|
||||
sort -k 2 -k 1 | uniq -f 1 | sed -e 's: :/:' | \
|
||||
xargs install -m 644 -t /usr/local/man/man9/
|
||||
|
||||
###
|
||||
#External programs used
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
|
||||
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
|
||||
XMLTOFLAGS += --skip-validation
|
||||
|
|
@ -89,7 +92,7 @@ define rule_docproc
|
|||
) > $(dir $@).$(notdir $@).cmd
|
||||
endef
|
||||
|
||||
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
|
||||
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
|
||||
$(call if_changed_rule,docproc)
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
|
|
@ -140,7 +143,20 @@ quiet_cmd_db2html = HTML $@
|
|||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
|
||||
%.html: %.xml
|
||||
###
|
||||
# Rules to create an aux XML and .db, and use them to re-process the DocBook XML
|
||||
# to fill internal hyperlinks
|
||||
gen_aux_xml = :
|
||||
quiet_gen_aux_xml = echo ' XMLREF $@'
|
||||
silent_gen_aux_xml = :
|
||||
%.aux.xml: %.xml
|
||||
@$($(quiet)gen_aux_xml)
|
||||
@rm -rf $@
|
||||
@(cat $< | egrep "^<refentry id" | egrep -o "\".*\"" | cut -f 2 -d \" > $<.db)
|
||||
@$(KERNELDOCXMLREF) -db $<.db $< > $@
|
||||
.PRECIOUS: %.aux.xml
|
||||
|
||||
%.html: %.aux.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
exit 1)
|
||||
|
|
@ -150,12 +166,12 @@ quiet_cmd_db2html = HTML $@
|
|||
cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
|
||||
|
||||
quiet_cmd_db2man = MAN $@
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man/$(*F) $< ; fi
|
||||
%.9 : %.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
exit 1)
|
||||
$(Q)mkdir -p $(obj)/man
|
||||
$(Q)mkdir -p $(obj)/man/$(*F)
|
||||
$(call cmd,db2man)
|
||||
@touch $@
|
||||
|
||||
|
|
@ -209,15 +225,18 @@ dochelp:
|
|||
###
|
||||
# Temporary files left by various tools
|
||||
clean-files := $(DOCBOOKS) \
|
||||
$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.tex, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.log, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.out, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.ps, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.tex, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.log, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.out, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.ps, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.xml, $(DOCBOOKS)) \
|
||||
$(index)
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@
|
|||
<sect1><title>ASoC Core API</title>
|
||||
!Iinclude/sound/soc.h
|
||||
!Esound/soc/soc-core.c
|
||||
!Esound/soc/soc-cache.c
|
||||
<!-- !Esound/soc/soc-cache.c no docbook comments here -->
|
||||
!Esound/soc/soc-devres.c
|
||||
!Esound/soc/soc-io.c
|
||||
!Esound/soc/soc-pcm.c
|
||||
|
|
|
|||
|
|
@ -585,7 +585,7 @@ kernel crypto API | IPSEC Layer
|
|||
+-----------+ |
|
||||
| | (1)
|
||||
| aead | <----------------------------------- esp_output
|
||||
| (seqniv) | ---+
|
||||
| (seqiv) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
|
|
@ -1101,7 +1101,7 @@ kernel crypto API | Caller
|
|||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
[1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -1661,7 +1661,7 @@ read(opfd, out, outlen);
|
|||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
[1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -1687,7 +1687,7 @@ read(opfd, out, outlen);
|
|||
!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
|
||||
!Finclude/linux/crypto.h crypto_alg
|
||||
!Finclude/linux/crypto.h ablkcipher_alg
|
||||
!Finclude/linux/crypto.h aead_alg
|
||||
!Finclude/crypto/aead.h aead_alg
|
||||
!Finclude/linux/crypto.h blkcipher_alg
|
||||
!Finclude/linux/crypto.h cipher_alg
|
||||
!Finclude/crypto/rng.h rng_alg
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@
|
|||
!Ekernel/time/hrtimer.c
|
||||
</sect1>
|
||||
<sect1><title>Workqueues and Kevents</title>
|
||||
!Iinclude/linux/workqueue.h
|
||||
!Ekernel/workqueue.c
|
||||
</sect1>
|
||||
<sect1><title>Internal Functions</title>
|
||||
|
|
@ -216,6 +217,40 @@ X!Isound/sound_firmware.c
|
|||
-->
|
||||
</chapter>
|
||||
|
||||
<chapter id="mediadev">
|
||||
<title>Media Devices</title>
|
||||
|
||||
<sect1><title>Video2Linux devices</title>
|
||||
!Iinclude/media/v4l2-async.h
|
||||
!Iinclude/media/v4l2-ctrls.h
|
||||
!Iinclude/media/v4l2-dv-timings.h
|
||||
!Iinclude/media/v4l2-event.h
|
||||
!Iinclude/media/v4l2-flash-led-class.h
|
||||
!Iinclude/media/v4l2-mediabus.h
|
||||
!Iinclude/media/v4l2-mem2mem.h
|
||||
!Iinclude/media/v4l2-of.h
|
||||
!Iinclude/media/v4l2-subdev.h
|
||||
!Iinclude/media/videobuf2-core.h
|
||||
!Iinclude/media/videobuf2-memops.h
|
||||
</sect1>
|
||||
<sect1><title>Digital TV (DVB) devices</title>
|
||||
!Idrivers/media/dvb-core/dvb_ca_en50221.h
|
||||
!Idrivers/media/dvb-core/dvb_frontend.h
|
||||
!Idrivers/media/dvb-core/dvb_math.h
|
||||
!Idrivers/media/dvb-core/dvb_ringbuffer.h
|
||||
!Idrivers/media/dvb-core/dvbdev.h
|
||||
</sect1>
|
||||
<sect1><title>Remote Controller devices</title>
|
||||
!Iinclude/media/rc-core.h
|
||||
</sect1>
|
||||
<sect1><title>Media Controller devices</title>
|
||||
!Iinclude/media/media-device.h
|
||||
!Iinclude/media/media-devnode.h
|
||||
!Iinclude/media/media-entity.h
|
||||
</sect1>
|
||||
|
||||
</chapter>
|
||||
|
||||
<chapter id="uart16x50">
|
||||
<title>16x50 UART Driver</title>
|
||||
!Edrivers/tty/serial/serial_core.c
|
||||
|
|
@ -455,4 +490,31 @@ X!Ilib/fonts/fonts.c
|
|||
!Edrivers/hsi/hsi.c
|
||||
</chapter>
|
||||
|
||||
<chapter id="pwm">
|
||||
<title>Pulse-Width Modulation (PWM)</title>
|
||||
<para>
|
||||
Pulse-width modulation is a modulation technique primarily used to
|
||||
control power supplied to electrical devices.
|
||||
</para>
|
||||
<para>
|
||||
The PWM framework provides an abstraction for providers and consumers
|
||||
of PWM signals. A controller that provides one or more PWM signals is
|
||||
registered as <structname>struct pwm_chip</structname>. Providers are
|
||||
expected to embed this structure in a driver-specific structure. This
|
||||
structure contains fields that describe a particular chip.
|
||||
</para>
|
||||
<para>
|
||||
A chip exposes one or more PWM signal sources, each of which exposed
|
||||
as a <structname>struct pwm_device</structname>. Operations can be
|
||||
performed on PWM devices to control the period, duty cycle, polarity
|
||||
and active state of the signal.
|
||||
</para>
|
||||
<para>
|
||||
Note that PWM devices are exclusive resources: they can always only be
|
||||
used by one consumer at a time.
|
||||
</para>
|
||||
!Iinclude/linux/pwm.h
|
||||
!Edrivers/pwm/core.c
|
||||
</chapter>
|
||||
|
||||
</book>
|
||||
|
|
|
|||
|
|
@ -3982,7 +3982,6 @@ int num_ioctls;</synopsis>
|
|||
<title>Interrupt Handling</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_fini
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
|
||||
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
|
||||
</sect2>
|
||||
|
|
@ -4012,7 +4011,6 @@ int num_ioctls;</synopsis>
|
|||
<title>Frontbuffer Tracking</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking
|
||||
!Idrivers/gpu/drm/i915/intel_frontbuffer.c
|
||||
!Fdrivers/gpu/drm/i915/intel_drv.h intel_frontbuffer_flip
|
||||
!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb
|
||||
</sect2>
|
||||
<sect2>
|
||||
|
|
@ -4044,6 +4042,11 @@ int num_ioctls;</synopsis>
|
|||
probing, so those sections fully apply.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Hotplug</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_hotplug.c Hotplug
|
||||
!Idrivers/gpu/drm/i915/intel_hotplug.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>High Definition Audio</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
|
||||
|
|
@ -4193,6 +4196,23 @@ int num_ioctls;</synopsis>
|
|||
<title>Global GTT views</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views
|
||||
!Idrivers/gpu/drm/i915/i915_gem_gtt.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>GTT Fences and Swizzling</title>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_fence.c
|
||||
<sect3>
|
||||
<title>Global GTT Fence Handling</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_gem_fence.c fence register handling
|
||||
</sect3>
|
||||
<sect3>
|
||||
<title>Hardware Tiling and Swizzling Details</title>
|
||||
!Pdrivers/gpu/drm/i915/i915_gem_fence.c tiling swizzling details
|
||||
</sect3>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Object Tiling IOCTLs</title>
|
||||
!Idrivers/gpu/drm/i915/i915_gem_tiling.c
|
||||
!Pdrivers/gpu/drm/i915/i915_gem_tiling.c buffer object tiling
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Buffer Object Eviction</title>
|
||||
|
|
|
|||
|
|
@ -146,36 +146,30 @@
|
|||
The journalling layer is easy to use. You need to
|
||||
first of all create a journal_t data structure. There are
|
||||
two calls to do this dependent on how you decide to allocate the physical
|
||||
media on which the journal resides. The journal_init_inode() call
|
||||
is for journals stored in filesystem inodes, or the journal_init_dev()
|
||||
call can be use for journal stored on a raw device (in a continuous range
|
||||
media on which the journal resides. The jbd2_journal_init_inode() call
|
||||
is for journals stored in filesystem inodes, or the jbd2_journal_init_dev()
|
||||
call can be used for journal stored on a raw device (in a continuous range
|
||||
of blocks). A journal_t is a typedef for a struct pointer, so when
|
||||
you are finally finished make sure you call journal_destroy() on it
|
||||
you are finally finished make sure you call jbd2_journal_destroy() on it
|
||||
to free up any used kernel memory.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Once you have got your journal_t object you need to 'mount' or load the journal
|
||||
file, unless of course you haven't initialised it yet - in which case you
|
||||
need to call journal_create().
|
||||
file. The journalling layer expects the space for the journal was already
|
||||
allocated and initialized properly by the userspace tools. When loading the
|
||||
journal you must call jbd2_journal_load() to process journal contents. If the
|
||||
client file system detects the journal contents does not need to be processed
|
||||
(or even need not have valid contents), it may call jbd2_journal_wipe() to
|
||||
clear the journal contents before calling jbd2_journal_load().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Most of the time however your journal file will already have been created, but
|
||||
before you load it you must call journal_wipe() to empty the journal file.
|
||||
Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
|
||||
job of the client file system to detect this and skip the call to journal_wipe().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
In either case the next call should be to journal_load() which prepares the
|
||||
journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
|
||||
for you if it detects any outstanding transactions in the journal and similarly
|
||||
journal_load() will call journal_recover() if necessary.
|
||||
I would advise reading fs/ext3/super.c for examples on this stage.
|
||||
[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
|
||||
complicate the API. Or isn't a good idea for the journal layer to hide
|
||||
dirty mounts from the client fs]
|
||||
Note that jbd2_journal_wipe(..,0) calls jbd2_journal_skip_recovery() for you if
|
||||
it detects any outstanding transactions in the journal and similarly
|
||||
jbd2_journal_load() will call jbd2_journal_recover() if necessary. I would
|
||||
advise reading ext4_load_journal() in fs/ext4/super.c for examples on this
|
||||
stage.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
|
|
@ -189,41 +183,41 @@ You still need to actually journal your filesystem changes, this
|
|||
is done by wrapping them into transactions. Additionally you
|
||||
also need to wrap the modification of each of the buffers
|
||||
with calls to the journal layer, so it knows what the modifications
|
||||
you are actually making are. To do this use journal_start() which
|
||||
you are actually making are. To do this use jbd2_journal_start() which
|
||||
returns a transaction handle.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
journal_start()
|
||||
and its counterpart journal_stop(), which indicates the end of a transaction
|
||||
are nestable calls, so you can reenter a transaction if necessary,
|
||||
but remember you must call journal_stop() the same number of times as
|
||||
journal_start() before the transaction is completed (or more accurately
|
||||
leaves the update phase). Ext3/VFS makes use of this feature to simplify
|
||||
quota support.
|
||||
jbd2_journal_start()
|
||||
and its counterpart jbd2_journal_stop(), which indicates the end of a
|
||||
transaction are nestable calls, so you can reenter a transaction if necessary,
|
||||
but remember you must call jbd2_journal_stop() the same number of times as
|
||||
jbd2_journal_start() before the transaction is completed (or more accurately
|
||||
leaves the update phase). Ext4/VFS makes use of this feature to simplify
|
||||
handling of inode dirtying, quota support, etc.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Inside each transaction you need to wrap the modifications to the
|
||||
individual buffers (blocks). Before you start to modify a buffer you
|
||||
need to call journal_get_{create,write,undo}_access() as appropriate,
|
||||
need to call jbd2_journal_get_{create,write,undo}_access() as appropriate,
|
||||
this allows the journalling layer to copy the unmodified data if it
|
||||
needs to. After all the buffer may be part of a previously uncommitted
|
||||
transaction.
|
||||
At this point you are at last ready to modify a buffer, and once
|
||||
you are have done so you need to call journal_dirty_{meta,}data().
|
||||
you are have done so you need to call jbd2_journal_dirty_{meta,}data().
|
||||
Or if you've asked for access to a buffer you now know is now longer
|
||||
required to be pushed back on the device you can call journal_forget()
|
||||
required to be pushed back on the device you can call jbd2_journal_forget()
|
||||
in much the same way as you might have used bforget() in the past.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A journal_flush() may be called at any time to commit and checkpoint
|
||||
A jbd2_journal_flush() may be called at any time to commit and checkpoint
|
||||
all your transactions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Then at umount time , in your put_super() you can then call journal_destroy()
|
||||
Then at umount time , in your put_super() you can then call jbd2_journal_destroy()
|
||||
to clean up your in-core journal object.
|
||||
</para>
|
||||
|
||||
|
|
@ -231,82 +225,74 @@ to clean up your in-core journal object.
|
|||
Unfortunately there a couple of ways the journal layer can cause a deadlock.
|
||||
The first thing to note is that each task can only have
|
||||
a single outstanding transaction at any one time, remember nothing
|
||||
commits until the outermost journal_stop(). This means
|
||||
commits until the outermost jbd2_journal_stop(). This means
|
||||
you must complete the transaction at the end of each file/inode/address
|
||||
etc. operation you perform, so that the journalling system isn't re-entered
|
||||
on another journal. Since transactions can't be nested/batched
|
||||
across differing journals, and another filesystem other than
|
||||
yours (say ext3) may be modified in a later syscall.
|
||||
yours (say ext4) may be modified in a later syscall.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
The second case to bear in mind is that journal_start() can
|
||||
The second case to bear in mind is that jbd2_journal_start() can
|
||||
block if there isn't enough space in the journal for your transaction
|
||||
(based on the passed nblocks param) - when it blocks it merely(!) needs to
|
||||
wait for transactions to complete and be committed from other tasks,
|
||||
so essentially we are waiting for journal_stop(). So to avoid
|
||||
deadlocks you must treat journal_start/stop() as if they
|
||||
so essentially we are waiting for jbd2_journal_stop(). So to avoid
|
||||
deadlocks you must treat jbd2_journal_start/stop() as if they
|
||||
were semaphores and include them in your semaphore ordering rules to prevent
|
||||
deadlocks. Note that journal_extend() has similar blocking behaviour to
|
||||
journal_start() so you can deadlock here just as easily as on journal_start().
|
||||
deadlocks. Note that jbd2_journal_extend() has similar blocking behaviour to
|
||||
jbd2_journal_start() so you can deadlock here just as easily as on
|
||||
jbd2_journal_start().
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Try to reserve the right number of blocks the first time. ;-). This will
|
||||
be the maximum number of blocks you are going to touch in this transaction.
|
||||
I advise having a look at at least ext3_jbd.h to see the basis on which
|
||||
ext3 uses to make these decisions.
|
||||
I advise having a look at at least ext4_jbd.h to see the basis on which
|
||||
ext4 uses to make these decisions.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Another wriggle to watch out for is your on-disk block allocation strategy.
|
||||
why? Because, if you undo a delete, you need to ensure you haven't reused any
|
||||
of the freed blocks in a later transaction. One simple way of doing this
|
||||
is make sure any blocks you allocate only have checkpointed transactions
|
||||
listed against them. Ext3 does this in ext3_test_allocatable().
|
||||
Why? Because, if you do a delete, you need to ensure you haven't reused any
|
||||
of the freed blocks until the transaction freeing these blocks commits. If you
|
||||
reused these blocks and crash happens, there is no way to restore the contents
|
||||
of the reallocated blocks at the end of the last fully committed transaction.
|
||||
|
||||
One simple way of doing this is to mark blocks as free in internal in-memory
|
||||
block allocation structures only after the transaction freeing them commits.
|
||||
Ext4 uses journal commit callback for this purpose.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Lock is also providing through journal_{un,}lock_updates(),
|
||||
ext3 uses this when it wants a window with a clean and stable fs for a moment.
|
||||
eg.
|
||||
With journal commit callbacks you can ask the journalling layer to call a
|
||||
callback function when the transaction is finally committed to disk, so that
|
||||
you can do some of your own management. You ask the journalling layer for
|
||||
calling the callback by simply setting journal->j_commit_callback function
|
||||
pointer and that function is called after each transaction commit. You can also
|
||||
use transaction->t_private_list for attaching entries to a transaction that
|
||||
need processing when the transaction commits.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
JBD2 also provides a way to block all transaction updates via
|
||||
jbd2_journal_{un,}lock_updates(). Ext4 uses this when it wants a window with a
|
||||
clean and stable fs for a moment. E.g.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
|
||||
journal_lock_updates() //stop new stuff happening..
|
||||
journal_flush() // checkpoint everything.
|
||||
jbd2_journal_lock_updates() //stop new stuff happening..
|
||||
jbd2_journal_flush() // checkpoint everything.
|
||||
..do stuff on stable fs
|
||||
journal_unlock_updates() // carry on with filesystem use.
|
||||
jbd2_journal_unlock_updates() // carry on with filesystem use.
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
The opportunities for abuse and DOS attacks with this should be obvious,
|
||||
if you allow unprivileged userspace to trigger codepaths containing these
|
||||
calls.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
A new feature of jbd since 2.5.25 is commit callbacks with the new
|
||||
journal_callback_set() function you can now ask the journalling layer
|
||||
to call you back when the transaction is finally committed to disk, so that
|
||||
you can do some of your own management. The key to this is the journal_callback
|
||||
struct, this maintains the internal callback information but you can
|
||||
extend it like this:-
|
||||
</para>
|
||||
<programlisting>
|
||||
struct myfs_callback_s {
|
||||
//Data structure element required by jbd..
|
||||
struct journal_callback for_jbd;
|
||||
// Stuff for myfs allocated together.
|
||||
myfs_inode* i_commited;
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>
|
||||
this would be useful if you needed to know when data was committed to a
|
||||
particular inode.
|
||||
</para>
|
||||
|
||||
</sect2>
|
||||
|
|
@ -319,36 +305,6 @@ being each mount, each modification (transaction) and each changed buffer
|
|||
to tell the journalling layer about them.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Here is a some pseudo code to give you an idea of how it works, as
|
||||
an example.
|
||||
</para>
|
||||
|
||||
<programlisting>
|
||||
journal_t* my_jnrl = journal_create();
|
||||
journal_init_{dev,inode}(jnrl,...)
|
||||
if (clean) journal_wipe();
|
||||
journal_load();
|
||||
|
||||
foreach(transaction) { /*transactions must be
|
||||
completed before
|
||||
a syscall returns to
|
||||
userspace*/
|
||||
|
||||
handle_t * xct=journal_start(my_jnrl);
|
||||
foreach(bh) {
|
||||
journal_get_{create,write,undo}_access(xact,bh);
|
||||
if ( myfs_modify(bh) ) { /* returns true
|
||||
if makes changes */
|
||||
journal_dirty_{meta,}data(xact,bh);
|
||||
} else {
|
||||
journal_forget(bh);
|
||||
}
|
||||
}
|
||||
journal_stop(xct);
|
||||
}
|
||||
journal_destroy(my_jrnl);
|
||||
</programlisting>
|
||||
</sect2>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -357,13 +313,13 @@ an example.
|
|||
<title>Data Types</title>
|
||||
<para>
|
||||
The journalling layer uses typedefs to 'hide' the concrete definitions
|
||||
of the structures used. As a client of the JBD layer you can
|
||||
of the structures used. As a client of the JBD2 layer you can
|
||||
just rely on the using the pointer as a magic cookie of some sort.
|
||||
|
||||
Obviously the hiding is not enforced as this is 'C'.
|
||||
</para>
|
||||
<sect2 id="structures"><title>Structures</title>
|
||||
!Iinclude/linux/jbd.h
|
||||
!Iinclude/linux/jbd2.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
|
|
@ -375,11 +331,11 @@ an example.
|
|||
manage transactions
|
||||
</para>
|
||||
<sect2 id="journal_level"><title>Journal Level</title>
|
||||
!Efs/jbd/journal.c
|
||||
!Ifs/jbd/recovery.c
|
||||
!Efs/jbd2/journal.c
|
||||
!Ifs/jbd2/recovery.c
|
||||
</sect2>
|
||||
<sect2 id="transaction_level"><title>Transasction Level</title>
|
||||
!Efs/jbd/transaction.c
|
||||
!Efs/jbd2/transaction.c
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="see_also">
|
||||
|
|
|
|||
|
|
@ -0,0 +1,697 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="iioid">
|
||||
<bookinfo>
|
||||
<title>Industrial I/O driver developer's guide </title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Daniel</firstname>
|
||||
<surname>Baluta</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>daniel.baluta@intel.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2015</year>
|
||||
<holder>Intel Corporation</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License version 2.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="intro">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The main purpose of the Industrial I/O subsystem (IIO) is to provide
|
||||
support for devices that in some sense perform either analog-to-digital
|
||||
conversion (ADC) or digital-to-analog conversion (DAC) or both. The aim
|
||||
is to fill the gap between the somewhat similar hwmon and input
|
||||
subsystems.
|
||||
Hwmon is directed at low sample rate sensors used to monitor and
|
||||
control the system itself, like fan speed control or temperature
|
||||
measurement. Input is, as its name suggests, focused on human interaction
|
||||
input devices (keyboard, mouse, touchscreen). In some cases there is
|
||||
considerable overlap between these and IIO.
|
||||
</para>
|
||||
<para>
|
||||
Devices that fall into this category include:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
analog to digital converters (ADCs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
accelerometers
|
||||
</listitem>
|
||||
<listitem>
|
||||
capacitance to digital converters (CDCs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
digital to analog converters (DACs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
gyroscopes
|
||||
</listitem>
|
||||
<listitem>
|
||||
inertial measurement units (IMUs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
color and light sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
magnetometers
|
||||
</listitem>
|
||||
<listitem>
|
||||
pressure sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
proximity sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
temperature sensors
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Usually these sensors are connected via SPI or I2C. A common use case of the
|
||||
sensors devices is to have combined functionality (e.g. light plus proximity
|
||||
sensor).
|
||||
</para>
|
||||
</chapter>
|
||||
<chapter id='iiosubsys'>
|
||||
<title>Industrial I/O core</title>
|
||||
<para>
|
||||
The Industrial I/O core offers:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
a unified framework for writing drivers for many different types of
|
||||
embedded sensors.
|
||||
</listitem>
|
||||
<listitem>
|
||||
a standard interface to user space applications manipulating sensors.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
The implementation can be found under <filename>
|
||||
drivers/iio/industrialio-*</filename>
|
||||
</para>
|
||||
<sect1 id="iiodevice">
|
||||
<title> Industrial I/O devices </title>
|
||||
|
||||
!Finclude/linux/iio/iio.h iio_dev
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_alloc
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_free
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_register
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_unregister
|
||||
|
||||
<para>
|
||||
An IIO device usually corresponds to a single hardware sensor and it
|
||||
provides all the information needed by a driver handling a device.
|
||||
Let's first have a look at the functionality embedded in an IIO
|
||||
device then we will show how a device driver makes use of an IIO
|
||||
device.
|
||||
</para>
|
||||
<para>
|
||||
There are two ways for a user space application to interact
|
||||
with an IIO driver.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/</filename>, this
|
||||
represents a hardware sensor and groups together the data
|
||||
channels of the same chip.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/dev/iio:deviceX</filename>, character device node
|
||||
interface used for buffered data transfer and for events information
|
||||
retrieval.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
A typical IIO driver will register itself as an I2C or SPI driver and will
|
||||
create two routines, <function> probe </function> and <function> remove
|
||||
</function>. At <function>probe</function>:
|
||||
<itemizedlist>
|
||||
<listitem>call <function>iio_device_alloc</function>, which allocates memory
|
||||
for an IIO device.
|
||||
</listitem>
|
||||
<listitem> initialize IIO device fields with driver specific information
|
||||
(e.g. device name, device channels).
|
||||
</listitem>
|
||||
<listitem>call <function> iio_device_register</function>, this registers the
|
||||
device with the IIO core. After this call the device is ready to accept
|
||||
requests from user space applications.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
At <function>remove</function>, we free the resources allocated in
|
||||
<function>probe</function> in reverse order:
|
||||
<itemizedlist>
|
||||
<listitem><function>iio_device_unregister</function>, unregister the device
|
||||
from the IIO core.
|
||||
</listitem>
|
||||
<listitem><function>iio_device_free</function>, free the memory allocated
|
||||
for the IIO device.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2 id="iioattr"> <title> IIO device sysfs interface </title>
|
||||
<para>
|
||||
Attributes are sysfs files used to expose chip info and also allowing
|
||||
applications to set various configuration parameters. For device
|
||||
with index X, attributes can be found under
|
||||
<filename>/sys/bus/iio/iio:deviceX/ </filename> directory.
|
||||
Common attributes are:
|
||||
<itemizedlist>
|
||||
<listitem><filename>name</filename>, description of the physical
|
||||
chip.
|
||||
</listitem>
|
||||
<listitem><filename>dev</filename>, shows the major:minor pair
|
||||
associated with <filename>/dev/iio:deviceX</filename> node.
|
||||
</listitem>
|
||||
<listitem><filename>sampling_frequency_available</filename>,
|
||||
available discrete set of sampling frequency values for
|
||||
device.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Available standard attributes for IIO devices are described in the
|
||||
<filename>Documentation/ABI/testing/sysfs-bus-iio </filename> file
|
||||
in the Linux kernel sources.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="iiochannel"> <title> IIO device channels </title>
|
||||
!Finclude/linux/iio/iio.h iio_chan_spec structure.
|
||||
<para>
|
||||
An IIO device channel is a representation of a data channel. An
|
||||
IIO device can have one or multiple channels. For example:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
a thermometer sensor has one channel representing the
|
||||
temperature measurement.
|
||||
</listitem>
|
||||
<listitem>
|
||||
a light sensor with two channels indicating the measurements in
|
||||
the visible and infrared spectrum.
|
||||
</listitem>
|
||||
<listitem>
|
||||
an accelerometer can have up to 3 channels representing
|
||||
acceleration on X, Y and Z axes.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
An IIO channel is described by the <type> struct iio_chan_spec
|
||||
</type>. A thermometer driver for the temperature sensor in the
|
||||
example above would have to describe its channel as follows:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec temp_channel[] = {
|
||||
{
|
||||
.type = IIO_TEMP,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
|
||||
},
|
||||
};
|
||||
|
||||
</programlisting>
|
||||
Channel sysfs attributes exposed to userspace are specified in
|
||||
the form of <emphasis>bitmasks</emphasis>. Depending on their
|
||||
shared info, attributes can be set in one of the following masks:
|
||||
<itemizedlist>
|
||||
<listitem><emphasis>info_mask_separate</emphasis>, attributes will
|
||||
be specific to this channel</listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_type</emphasis>,
|
||||
attributes are shared by all channels of the same type</listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_dir</emphasis>, attributes
|
||||
are shared by all channels of the same direction </listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_all</emphasis>,
|
||||
attributes are shared by all channels</listitem>
|
||||
</itemizedlist>
|
||||
When there are multiple data channels per channel type we have two
|
||||
ways to distinguish between them:
|
||||
<itemizedlist>
|
||||
<listitem> set <emphasis> .modified</emphasis> field of <type>
|
||||
iio_chan_spec</type> to 1. Modifiers are specified using
|
||||
<emphasis>.channel2</emphasis> field of the same
|
||||
<type>iio_chan_spec</type> structure and are used to indicate a
|
||||
physically unique characteristic of the channel such as its direction
|
||||
or spectral response. For example, a light sensor can have two channels,
|
||||
one for infrared light and one for both infrared and visible light.
|
||||
</listitem>
|
||||
<listitem> set <emphasis>.indexed </emphasis> field of
|
||||
<type>iio_chan_spec</type> to 1. In this case the channel is
|
||||
simply another instance with an index specified by the
|
||||
<emphasis>.channel</emphasis> field.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Here is how we can make use of the channel's modifiers:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec light_channels[] = {
|
||||
{
|
||||
.type = IIO_INTENSITY,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_LIGHT_IR,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
{
|
||||
.type = IIO_INTENSITY,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_LIGHT_BOTH,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
{
|
||||
.type = IIO_LIGHT,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
This channel's definition will generate two separate sysfs files
|
||||
for raw data retrieval:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_intensity_ir_raw</filename>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_intensity_both_raw</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
one file for processed data:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_illuminance_input
|
||||
</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
and one shared sysfs file for sampling frequency:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/sampling_frequency.
|
||||
</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
Here is how we can make use of the channel's indexing:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec light_channels[] = {
|
||||
{
|
||||
.type = IIO_VOLTAGE,
|
||||
.indexed = 1,
|
||||
.channel = 0,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
},
|
||||
{
|
||||
.type = IIO_VOLTAGE,
|
||||
.indexed = 1,
|
||||
.channel = 1,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
},
|
||||
}
|
||||
</programlisting>
|
||||
This will generate two separate attributes files for raw data
|
||||
retrieval:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw</filename>,
|
||||
representing voltage measurement for channel 0.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw</filename>,
|
||||
representing voltage measurement for channel 1.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="iiobuffer"> <title> Industrial I/O buffers </title>
|
||||
!Finclude/linux/iio/buffer.h iio_buffer
|
||||
!Edrivers/iio/industrialio-buffer.c
|
||||
|
||||
<para>
|
||||
The Industrial I/O core offers a way for continuous data capture
|
||||
based on a trigger source. Multiple data channels can be read at once
|
||||
from <filename>/dev/iio:deviceX</filename> character device node,
|
||||
thus reducing the CPU load.
|
||||
</para>
|
||||
|
||||
<sect2 id="iiobuffersysfs">
|
||||
<title>IIO buffer sysfs interface </title>
|
||||
<para>
|
||||
An IIO buffer has an associated attributes directory under <filename>
|
||||
/sys/bus/iio/iio:deviceX/buffer/</filename>. Here are the existing
|
||||
attributes:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<emphasis>length</emphasis>, the total number of data samples
|
||||
(capacity) that can be stored by the buffer.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>enable</emphasis>, activate buffer capture.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="iiobuffersetup"> <title> IIO buffer setup </title>
|
||||
<para>The meta information associated with a channel reading
|
||||
placed in a buffer is called a <emphasis> scan element </emphasis>.
|
||||
The important bits configuring scan elements are exposed to
|
||||
userspace applications via the <filename>
|
||||
/sys/bus/iio/iio:deviceX/scan_elements/</filename> directory. This
|
||||
file contains attributes of the following form:
|
||||
<itemizedlist>
|
||||
<listitem><emphasis>enable</emphasis>, used for enabling a channel.
|
||||
If and only if its attribute is non zero, then a triggered capture
|
||||
will contain data samples for this channel.
|
||||
</listitem>
|
||||
<listitem><emphasis>type</emphasis>, description of the scan element
|
||||
data storage within the buffer and hence the form in which it is
|
||||
read from user space. Format is <emphasis>
|
||||
[be|le]:[s|u]bits/storagebitsXrepeat[>>shift] </emphasis>.
|
||||
<itemizedlist>
|
||||
<listitem> <emphasis>be</emphasis> or <emphasis>le</emphasis>, specifies
|
||||
big or little endian.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>s </emphasis>or <emphasis>u</emphasis>, specifies if
|
||||
signed (2's complement) or unsigned.
|
||||
</listitem>
|
||||
<listitem><emphasis>bits</emphasis>, is the number of valid data
|
||||
bits.
|
||||
</listitem>
|
||||
<listitem><emphasis>storagebits</emphasis>, is the number of bits
|
||||
(after padding) that it occupies in the buffer.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>shift</emphasis>, if specified, is the shift that needs
|
||||
to be applied prior to masking out unused bits.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>repeat</emphasis>, specifies the number of bits/storagebits
|
||||
repetitions. When the repeat element is 0 or 1, then the repeat
|
||||
value is omitted.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
For example, a driver for a 3-axis accelerometer with 12 bit
|
||||
resolution where data is stored in two 8-bits registers as
|
||||
follows:
|
||||
<programlisting>
|
||||
7 6 5 4 3 2 1 0
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06)
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|
||||
7 6 5 4 3 2 1 0
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07)
|
||||
+---+---+---+---+---+---+---+---+
|
||||
</programlisting>
|
||||
|
||||
will have the following scan element type for each axis:
|
||||
<programlisting>
|
||||
$ cat /sys/bus/iio/devices/iio:device0/scan_elements/in_accel_y_type
|
||||
le:s12/16>>4
|
||||
</programlisting>
|
||||
A user space application will interpret data samples read from the
|
||||
buffer as two byte little endian signed data, that needs a 4 bits
|
||||
right shift before masking out the 12 valid bits of data.
|
||||
</para>
|
||||
<para>
|
||||
For implementing buffer support a driver should initialize the following
|
||||
fields in <type>iio_chan_spec</type> definition:
|
||||
<programlisting>
|
||||
struct iio_chan_spec {
|
||||
/* other members */
|
||||
int scan_index
|
||||
struct {
|
||||
char sign;
|
||||
u8 realbits;
|
||||
u8 storagebits;
|
||||
u8 shift;
|
||||
u8 repeat;
|
||||
enum iio_endian endianness;
|
||||
} scan_type;
|
||||
};
|
||||
</programlisting>
|
||||
The driver implementing the accelerometer described above will
|
||||
have the following channel definition:
|
||||
<programlisting>
|
||||
struct struct iio_chan_spec accel_channels[] = {
|
||||
{
|
||||
.type = IIO_ACCEL,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_X,
|
||||
/* other stuff here */
|
||||
.scan_index = 0,
|
||||
.scan_type = {
|
||||
.sign = 's',
|
||||
.realbits = 12,
|
||||
.storgebits = 16,
|
||||
.shift = 4,
|
||||
.endianness = IIO_LE,
|
||||
},
|
||||
}
|
||||
/* similar for Y (with channel2 = IIO_MOD_Y, scan_index = 1)
|
||||
* and Z (with channel2 = IIO_MOD_Z, scan_index = 2) axis
|
||||
*/
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Here <emphasis> scan_index </emphasis> defines the order in which
|
||||
the enabled channels are placed inside the buffer. Channels with a lower
|
||||
scan_index will be placed before channels with a higher index. Each
|
||||
channel needs to have a unique scan_index.
|
||||
</para>
|
||||
<para>
|
||||
Setting scan_index to -1 can be used to indicate that the specific
|
||||
channel does not support buffered capture. In this case no entries will
|
||||
be created for the channel in the scan_elements directory.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="iiotrigger"> <title> Industrial I/O triggers </title>
|
||||
!Finclude/linux/iio/trigger.h iio_trigger
|
||||
!Edrivers/iio/industrialio-trigger.c
|
||||
<para>
|
||||
In many situations it is useful for a driver to be able to
|
||||
capture data based on some external event (trigger) as opposed
|
||||
to periodically polling for data. An IIO trigger can be provided
|
||||
by a device driver that also has an IIO device based on hardware
|
||||
generated events (e.g. data ready or threshold exceeded) or
|
||||
provided by a separate driver from an independent interrupt
|
||||
source (e.g. GPIO line connected to some external system, timer
|
||||
interrupt or user space writing a specific file in sysfs). A
|
||||
trigger may initiate data capture for a number of sensors and
|
||||
also it may be completely unrelated to the sensor itself.
|
||||
</para>
|
||||
|
||||
<sect2 id="iiotrigsysfs"> <title> IIO trigger sysfs interface </title>
|
||||
There are two locations in sysfs related to triggers:
|
||||
<itemizedlist>
|
||||
<listitem><filename>/sys/bus/iio/devices/triggerY</filename>,
|
||||
this file is created once an IIO trigger is registered with
|
||||
the IIO core and corresponds to trigger with index Y. Because
|
||||
triggers can be very different depending on type there are few
|
||||
standard attributes that we can describe here:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<emphasis>name</emphasis>, trigger name that can be later
|
||||
used for association with a device.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>sampling_frequency</emphasis>, some timer based
|
||||
triggers use this attribute to specify the frequency for
|
||||
trigger calls.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/trigger/</filename>, this
|
||||
directory is created once the device supports a triggered
|
||||
buffer. We can associate a trigger with our device by writing
|
||||
the trigger's name in the <filename>current_trigger</filename> file.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iiotrigattr"> <title> IIO trigger setup</title>
|
||||
|
||||
<para>
|
||||
Let's see a simple example of how to setup a trigger to be used
|
||||
by a driver.
|
||||
|
||||
<programlisting>
|
||||
struct iio_trigger_ops trigger_ops = {
|
||||
.set_trigger_state = sample_trigger_state,
|
||||
.validate_device = sample_validate_device,
|
||||
}
|
||||
|
||||
struct iio_trigger *trig;
|
||||
|
||||
/* first, allocate memory for our trigger */
|
||||
trig = iio_trigger_alloc(dev, "trig-%s-%d", name, idx);
|
||||
|
||||
/* setup trigger operations field */
|
||||
trig->ops = &trigger_ops;
|
||||
|
||||
/* now register the trigger with the IIO core */
|
||||
iio_trigger_register(trig);
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iiotrigsetup"> <title> IIO trigger ops</title>
|
||||
!Finclude/linux/iio/trigger.h iio_trigger_ops
|
||||
<para>
|
||||
Notice that a trigger has a set of operations attached:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<function>set_trigger_state</function>, switch the trigger on/off
|
||||
on demand.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<function>validate_device</function>, function to validate the
|
||||
device when the current trigger gets changed.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="iiotriggered_buffer">
|
||||
<title> Industrial I/O triggered buffers </title>
|
||||
<para>
|
||||
Now that we know what buffers and triggers are let's see how they
|
||||
work together.
|
||||
</para>
|
||||
<sect2 id="iiotrigbufsetup"> <title> IIO triggered buffer setup</title>
|
||||
!Edrivers/iio/industrialio-triggered-buffer.c
|
||||
!Finclude/linux/iio/iio.h iio_buffer_setup_ops
|
||||
|
||||
|
||||
<para>
|
||||
A typical triggered buffer setup looks like this:
|
||||
<programlisting>
|
||||
const struct iio_buffer_setup_ops sensor_buffer_setup_ops = {
|
||||
.preenable = sensor_buffer_preenable,
|
||||
.postenable = sensor_buffer_postenable,
|
||||
.postdisable = sensor_buffer_postdisable,
|
||||
.predisable = sensor_buffer_predisable,
|
||||
};
|
||||
|
||||
irqreturn_t sensor_iio_pollfunc(int irq, void *p)
|
||||
{
|
||||
pf->timestamp = iio_get_time_ns();
|
||||
return IRQ_WAKE_THREAD;
|
||||
}
|
||||
|
||||
irqreturn_t sensor_trigger_handler(int irq, void *p)
|
||||
{
|
||||
u16 buf[8];
|
||||
int i = 0;
|
||||
|
||||
/* read data for each active channel */
|
||||
for_each_set_bit(bit, active_scan_mask, masklength)
|
||||
buf[i++] = sensor_get_data(bit)
|
||||
|
||||
iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
|
||||
|
||||
iio_trigger_notify_done(trigger);
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
/* setup triggered buffer, usually in probe function */
|
||||
iio_triggered_buffer_setup(indio_dev, sensor_iio_polfunc,
|
||||
sensor_trigger_handler,
|
||||
sensor_buffer_setup_ops);
|
||||
</programlisting>
|
||||
</para>
|
||||
The important things to notice here are:
|
||||
<itemizedlist>
|
||||
<listitem><function> iio_buffer_setup_ops</function>, the buffer setup
|
||||
functions to be called at predefined points in the buffer configuration
|
||||
sequence (e.g. before enable, after disable). If not specified, the
|
||||
IIO core uses the default <type>iio_triggered_buffer_setup_ops</type>.
|
||||
</listitem>
|
||||
<listitem><function>sensor_iio_pollfunc</function>, the function that
|
||||
will be used as top half of poll function. It should do as little
|
||||
processing as possible, because it runs in interrupt context. The most
|
||||
common operation is recording of the current timestamp and for this reason
|
||||
one can use the IIO core defined <function>iio_pollfunc_store_time
|
||||
</function> function.
|
||||
</listitem>
|
||||
<listitem><function>sensor_trigger_handler</function>, the function that
|
||||
will be used as bottom half of the poll function. This runs in the
|
||||
context of a kernel thread and all the processing takes place here.
|
||||
It usually reads data from the device and stores it in the internal
|
||||
buffer together with the timestamp recorded in the top half.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id='iioresources'>
|
||||
<title> Resources </title>
|
||||
IIO core may change during time so the best documentation to read is the
|
||||
source code. There are several locations where you should look:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>drivers/iio/</filename>, contains the IIO core plus
|
||||
and directories for each sensor type (e.g. accel, magnetometer,
|
||||
etc.)
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>include/linux/iio/</filename>, contains the header
|
||||
files, nice to read for the internal kernel interfaces.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>include/uapi/linux/iio/</filename>, contains files to be
|
||||
used by user space applications.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>tools/iio/</filename>, contains tools for rapidly
|
||||
testing buffers, events and device creation.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>drivers/staging/iio/</filename>, contains code for some
|
||||
drivers or experimental features that are not yet mature enough
|
||||
to be moved out.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Besides the code, there are some good online documentation sources:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<ulink url="http://marc.info/?l=linux-iio"> Industrial I/O mailing
|
||||
list </ulink>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<ulink url="http://wiki.analog.com/software/linux/docs/iio/iio">
|
||||
Analog Device IIO wiki page </ulink>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<ulink url="https://fosdem.org/2015/schedule/event/iiosdr/">
|
||||
Using the Linux IIO framework for SDR, Lars-Peter Clausen's
|
||||
presentation at FOSDEM </ulink>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
<!--
|
||||
vim: softtabstop=2:shiftwidth=2:expandtab:textwidth=72
|
||||
-->
|
||||
|
|
@ -199,7 +199,8 @@ DVB_DOCUMENTED = \
|
|||
#
|
||||
|
||||
install_media_images = \
|
||||
$(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
|
||||
$(Q)-mkdir $(MEDIA_OBJ_DIR)/media_api; \
|
||||
cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
|
||||
|
||||
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
|
||||
$(Q)base64 -d $< >$@
|
||||
|
|
|
|||
|
|
@ -163,9 +163,8 @@ are called:</para>
|
|||
<para>where N enumerates the DVB PCI cards in a system starting
|
||||
from 0, and M enumerates the devices of each type within each
|
||||
adapter, starting from 0, too. We will omit the “
|
||||
<constant>/dev/dvb/adapterN/</constant>” in the further dicussion
|
||||
of these devices. The naming scheme for the devices is the same wheter
|
||||
devfs is used or not.</para>
|
||||
<constant>/dev/dvb/adapterN/</constant>” in the further discussion
|
||||
of these devices.</para>
|
||||
|
||||
<para>More details about the data structures and function calls of all
|
||||
the devices are described in the following chapters.</para>
|
||||
|
|
|
|||
|
|
@ -3414,7 +3414,7 @@ giving priority to the center of the metered area.</entry>
|
|||
<row>
|
||||
<entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant> </entry>
|
||||
<entry>A multi-zone metering. The light intensity is measured
|
||||
in several points of the frame and the the results are combined. The
|
||||
in several points of the frame and the results are combined. The
|
||||
algorithm of the zones selection and their significance in calculating the
|
||||
final value is device dependent.</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -102,7 +102,7 @@
|
|||
</row>
|
||||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>media_version</structfield></entry>
|
||||
<entry><structfield>driver_version</structfield></entry>
|
||||
<entry>Media device driver version, formatted with the
|
||||
<constant>KERNEL_VERSION()</constant> macro. Together with the
|
||||
<structfield>driver</structfield> field this identifies a particular
|
||||
|
|
|
|||
|
|
@ -62,28 +62,28 @@ buffer as a DMABUF file at any time after buffers have been allocated with the
|
|||
&VIDIOC-REQBUFS; ioctl.</para>
|
||||
|
||||
<para> To export a buffer, applications fill &v4l2-exportbuffer;. The
|
||||
<structfield> type </structfield> field is set to the same buffer type as was
|
||||
previously used with &v4l2-requestbuffers;<structfield> type </structfield>.
|
||||
Applications must also set the <structfield> index </structfield> field. Valid
|
||||
<structfield>type</structfield> field is set to the same buffer type as was
|
||||
previously used with &v4l2-requestbuffers; <structfield>type</structfield>.
|
||||
Applications must also set the <structfield>index</structfield> field. Valid
|
||||
index numbers range from zero to the number of buffers allocated with
|
||||
&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
|
||||
minus one. For the multi-planar API, applications set the <structfield> plane
|
||||
</structfield> field to the index of the plane to be exported. Valid planes
|
||||
&VIDIOC-REQBUFS; (&v4l2-requestbuffers; <structfield>count</structfield>)
|
||||
minus one. For the multi-planar API, applications set the <structfield>plane</structfield>
|
||||
field to the index of the plane to be exported. Valid planes
|
||||
range from zero to the maximal number of valid planes for the currently active
|
||||
format. For the single-planar API, applications must set <structfield> plane
|
||||
</structfield> to zero. Additional flags may be posted in the <structfield>
|
||||
flags </structfield> field. Refer to a manual for open() for details.
|
||||
format. For the single-planar API, applications must set <structfield>plane</structfield>
|
||||
to zero. Additional flags may be posted in the <structfield>flags</structfield>
|
||||
field. Refer to a manual for open() for details.
|
||||
Currently only O_CLOEXEC, O_RDONLY, O_WRONLY, and O_RDWR are supported. All
|
||||
other fields must be set to zero.
|
||||
In the case of multi-planar API, every plane is exported separately using
|
||||
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
|
||||
multiple <constant>VIDIOC_EXPBUF</constant> calls.</para>
|
||||
|
||||
<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
|
||||
</structfield> field will be set by a driver. This is a DMABUF file
|
||||
<para>After calling <constant>VIDIOC_EXPBUF</constant> the <structfield>fd</structfield>
|
||||
field will be set by a driver. This is a DMABUF file
|
||||
descriptor. The application may pass it to other DMABUF-aware devices. Refer to
|
||||
<link linkend="dmabuf">DMABUF importing</link> for details about importing
|
||||
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
|
||||
is no longer used to allow the associated memory to be reclaimed. </para>
|
||||
is no longer used to allow the associated memory to be reclaimed.</para>
|
||||
</refsect1>
|
||||
|
||||
<refsect1>
|
||||
|
|
@ -170,9 +170,9 @@ multi-planar API. Otherwise this value must be set to zero. </entry>
|
|||
<row>
|
||||
<entry>__u32</entry>
|
||||
<entry><structfield>flags</structfield></entry>
|
||||
<entry>Flags for the newly created file, currently only <constant>
|
||||
O_CLOEXEC </constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY
|
||||
</constant>, and <constant>O_RDWR</constant> are supported, refer to the manual
|
||||
<entry>Flags for the newly created file, currently only
|
||||
<constant>O_CLOEXEC</constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY</constant>,
|
||||
and <constant>O_RDWR</constant> are supported, refer to the manual
|
||||
of open() for more details.</entry>
|
||||
</row>
|
||||
<row>
|
||||
|
|
@ -200,9 +200,9 @@ set the array to zero.</entry>
|
|||
<term><errorcode>EINVAL</errorcode></term>
|
||||
<listitem>
|
||||
<para>A queue is not in MMAP mode or DMABUF exporting is not
|
||||
supported or <structfield> flags </structfield> or <structfield> type
|
||||
</structfield> or <structfield> index </structfield> or <structfield> plane
|
||||
</structfield> fields are invalid.</para>
|
||||
supported or <structfield>flags</structfield> or <structfield>type</structfield>
|
||||
or <structfield>index</structfield> or <structfield>plane</structfield> fields
|
||||
are invalid.</para>
|
||||
</listitem>
|
||||
</varlistentry>
|
||||
</variablelist>
|
||||
|
|
|
|||
|
|
@ -267,7 +267,7 @@ is intended for still imaging applications. The idea is to get the
|
|||
best possible image quality that the hardware can deliver. It is not
|
||||
defined how the driver writer may achieve that; it will depend on the
|
||||
hardware and the ingenuity of the driver writer. High quality mode is
|
||||
a different mode from the the regular motion video capture modes. In
|
||||
a different mode from the regular motion video capture modes. In
|
||||
high quality mode:<itemizedlist>
|
||||
<listitem>
|
||||
<para>The driver may be able to capture higher
|
||||
|
|
|
|||
|
|
@ -616,7 +616,7 @@ pointer to memory containing the payload of the control.</entry>
|
|||
<entry><constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant></entry>
|
||||
<entry>0x0200</entry>
|
||||
<entry>The value provided to the control will be propagated to the driver
|
||||
even if remains constant. This is required when the control represents an action
|
||||
even if it remains constant. This is required when the control represents an action
|
||||
on the hardware. For example: clearing an error flag or triggering the flash. All the
|
||||
controls of the type <constant>V4L2_CTRL_TYPE_BUTTON</constant> have this flag set.</entry>
|
||||
</row>
|
||||
|
|
|
|||
|
|
@ -5,6 +5,7 @@
|
|||
<param name="funcsynopsis.tabular.threshold">80</param>
|
||||
<param name="callout.graphics">0</param>
|
||||
<!-- <param name="paper.type">A4</param> -->
|
||||
<param name="generate.consistent.ids">1</param>
|
||||
<param name="generate.section.toc.level">2</param>
|
||||
<param name="use.id.as.filename">1</param>
|
||||
</stylesheet>
|
||||
|
|
|
|||
|
|
@ -218,16 +218,16 @@ The development process
|
|||
Linux kernel development process currently consists of a few different
|
||||
main kernel "branches" and lots of different subsystem-specific kernel
|
||||
branches. These different branches are:
|
||||
- main 3.x kernel tree
|
||||
- 3.x.y -stable kernel tree
|
||||
- 3.x -git kernel patches
|
||||
- main 4.x kernel tree
|
||||
- 4.x.y -stable kernel tree
|
||||
- 4.x -git kernel patches
|
||||
- subsystem specific kernel trees and patches
|
||||
- the 3.x -next kernel tree for integration tests
|
||||
- the 4.x -next kernel tree for integration tests
|
||||
|
||||
3.x kernel tree
|
||||
4.x kernel tree
|
||||
-----------------
|
||||
3.x kernels are maintained by Linus Torvalds, and can be found on
|
||||
kernel.org in the pub/linux/kernel/v3.x/ directory. Its development
|
||||
4.x kernels are maintained by Linus Torvalds, and can be found on
|
||||
kernel.org in the pub/linux/kernel/v4.x/ directory. Its development
|
||||
process is as follows:
|
||||
- As soon as a new kernel is released a two weeks window is open,
|
||||
during this period of time maintainers can submit big diffs to
|
||||
|
|
@ -262,20 +262,20 @@ mailing list about kernel releases:
|
|||
released according to perceived bug status, not according to a
|
||||
preconceived timeline."
|
||||
|
||||
3.x.y -stable kernel tree
|
||||
4.x.y -stable kernel tree
|
||||
---------------------------
|
||||
Kernels with 3-part versions are -stable kernels. They contain
|
||||
relatively small and critical fixes for security problems or significant
|
||||
regressions discovered in a given 3.x kernel.
|
||||
regressions discovered in a given 4.x kernel.
|
||||
|
||||
This is the recommended branch for users who want the most recent stable
|
||||
kernel and are not interested in helping test development/experimental
|
||||
versions.
|
||||
|
||||
If no 3.x.y kernel is available, then the highest numbered 3.x
|
||||
If no 4.x.y kernel is available, then the highest numbered 4.x
|
||||
kernel is the current stable kernel.
|
||||
|
||||
3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
|
||||
4.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
|
||||
are released as needs dictate. The normal release period is approximately
|
||||
two weeks, but it can be longer if there are no pressing problems. A
|
||||
security-related problem, instead, can cause a release to happen almost
|
||||
|
|
@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree
|
|||
documents what kinds of changes are acceptable for the -stable tree, and
|
||||
how the release process works.
|
||||
|
||||
3.x -git patches
|
||||
4.x -git patches
|
||||
------------------
|
||||
These are daily snapshots of Linus' kernel tree which are managed in a
|
||||
git repository (hence the name.) These patches are usually released
|
||||
|
|
@ -317,9 +317,9 @@ revisions to it, and maintainers can mark patches as under review,
|
|||
accepted, or rejected. Most of these patchwork sites are listed at
|
||||
http://patchwork.kernel.org/.
|
||||
|
||||
3.x -next kernel tree for integration tests
|
||||
4.x -next kernel tree for integration tests
|
||||
---------------------------------------------
|
||||
Before updates from subsystem trees are merged into the mainline 3.x
|
||||
Before updates from subsystem trees are merged into the mainline 4.x
|
||||
tree, they need to be integration-tested. For this purpose, a special
|
||||
testing repository exists into which virtually all subsystem trees are
|
||||
pulled on an almost daily basis:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This guide gives a quick cheat sheet for some basic understanding.
|
|||
Some Keywords
|
||||
|
||||
DMAR - DMA remapping
|
||||
DRHD - DMA Engine Reporting Structure
|
||||
DRHD - DMA Remapping Hardware Unit Definition
|
||||
RMRR - Reserved memory Region Reporting Structure
|
||||
ZLR - Zero length reads from PCI devices
|
||||
IOVA - IO Virtual address.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ o You must use one of the rcu_dereference() family of primitives
|
|||
o Avoid cancellation when using the "+" and "-" infix arithmetic
|
||||
operators. For example, for a given variable "x", avoid
|
||||
"(x-x)". There are similar arithmetic pitfalls from other
|
||||
arithmetic operatiors, such as "(x*0)", "(x/(x+1))" or "(x%1)".
|
||||
arithmetic operators, such as "(x*0)", "(x/(x+1))" or "(x%1)".
|
||||
The compiler is within its rights to substitute zero for all of
|
||||
these expressions, so that subsequent accesses no longer depend
|
||||
on the rcu_dereference(), again possibly resulting in bugs due
|
||||
|
|
|
|||
|
|
@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
Stall-warning messages may be enabled and disabled completely via
|
||||
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
print out additional per-CPU diagnostic information, including
|
||||
information on scheduling-clock ticks and RCU's idle-CPU tracking.
|
||||
|
||||
RCU_STALL_DELAY_DELTA
|
||||
|
||||
Although the lockdep facility is extremely useful, it does add
|
||||
|
|
@ -101,15 +95,13 @@ interact. Please note that it is not possible to entirely eliminate this
|
|||
sort of false positive without resorting to things like stop_machine(),
|
||||
which is overkill for this sort of problem.
|
||||
|
||||
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
Recent kernels will print a long form of the stall-warning message:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
|
||||
(t=65000 jiffies)
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||
printed:
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
|
||||
|
|
@ -171,6 +163,23 @@ message will be about three times the interval between the beginning
|
|||
of the stall and the first message.
|
||||
|
||||
|
||||
Stall Warnings for Expedited Grace Periods
|
||||
|
||||
If an expedited grace period detects a stall, it will place a message
|
||||
like the following in dmesg:
|
||||
|
||||
INFO: rcu_sched detected expedited stalls on CPUs: { 1 2 6 } 26009 jiffies s: 1043
|
||||
|
||||
This indicates that CPUs 1, 2, and 6 have failed to respond to a
|
||||
reschedule IPI, that the expedited grace period has been going on for
|
||||
26,009 jiffies, and that the expedited grace-period sequence counter is
|
||||
1043. The fact that this last value is odd indicates that an expedited
|
||||
grace period is in flight.
|
||||
|
||||
It is entirely possible to see stall warnings from normal and from
|
||||
expedited grace periods at about the same time from the same run.
|
||||
|
||||
|
||||
What Causes RCU CPU Stall Warnings?
|
||||
|
||||
So your kernel printed an RCU CPU stall warning. The next question is
|
||||
|
|
|
|||
|
|
@ -237,42 +237,26 @@ o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
|
|||
|
||||
The output of "cat rcu/rcu_preempt/rcuexp" looks as follows:
|
||||
|
||||
s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872
|
||||
s=21872 wd0=0 wd1=0 wd2=0 wd3=5 n=0 enq=0 sc=21872
|
||||
|
||||
These fields are as follows:
|
||||
|
||||
o "s" is the starting sequence number.
|
||||
o "s" is the sequence number, with an odd number indicating that
|
||||
an expedited grace period is in progress.
|
||||
|
||||
o "d" is the ending sequence number. When the starting and ending
|
||||
numbers differ, there is an expedited grace period in progress.
|
||||
|
||||
o "w" is the number of times that the sequence numbers have been
|
||||
in danger of wrapping.
|
||||
|
||||
o "tf" is the number of times that contention has resulted in a
|
||||
failure to begin an expedited grace period.
|
||||
|
||||
o "wd1" and "wd2" are the number of times that an attempt to
|
||||
start an expedited grace period found that someone else had
|
||||
completed an expedited grace period that satisfies the
|
||||
o "wd0", "wd1", "wd2", and "wd3" are the number of times that an
|
||||
attempt to start an expedited grace period found that someone
|
||||
else had completed an expedited grace period that satisfies the
|
||||
attempted request. "Our work is done."
|
||||
|
||||
o "n" is number of times that contention was so great that
|
||||
the request was demoted from an expedited grace period to
|
||||
a normal grace period.
|
||||
o "n" is number of times that a concurrent CPU-hotplug operation
|
||||
forced a fallback to a normal grace period.
|
||||
|
||||
o "enq" is the number of quiescent states still outstanding.
|
||||
|
||||
o "sc" is the number of times that the attempt to start a
|
||||
new expedited grace period succeeded.
|
||||
|
||||
o "dt" is the number of times that we attempted to update
|
||||
the "d" counter.
|
||||
|
||||
o "dl" is the number of times that we failed to update the "d"
|
||||
counter.
|
||||
|
||||
o "dx" is the number of times that we succeeded in updating
|
||||
the "d" counter.
|
||||
|
||||
|
||||
The output of "cat rcu/rcu_preempt/rcugp" looks as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -883,7 +883,7 @@ All: lockdep-checked RCU-protected pointer access
|
|||
|
||||
rcu_access_pointer
|
||||
rcu_dereference_raw
|
||||
rcu_lockdep_assert
|
||||
RCU_LOCKDEP_WARN
|
||||
rcu_sleep_check
|
||||
RCU_NONIDLE
|
||||
|
||||
|
|
|
|||
|
|
@ -90,11 +90,11 @@ patch.
|
|||
|
||||
Make sure your patch does not include any extra files which do not
|
||||
belong in a patch submission. Make sure to review your patch -after-
|
||||
generated it with diff(1), to ensure accuracy.
|
||||
generating it with diff(1), to ensure accuracy.
|
||||
|
||||
If your changes produce a lot of deltas, you need to split them into
|
||||
individual patches which modify things in logical stages; see section
|
||||
#3. This will facilitate easier reviewing by other kernel developers,
|
||||
#3. This will facilitate review by other kernel developers,
|
||||
very important if you want your patch accepted.
|
||||
|
||||
If you're using git, "git rebase -i" can help you with this process. If
|
||||
|
|
@ -267,7 +267,7 @@ You should always copy the appropriate subsystem maintainer(s) on any patch
|
|||
to code that they maintain; look through the MAINTAINERS file and the
|
||||
source code revision history to see who those maintainers are. The
|
||||
script scripts/get_maintainer.pl can be very useful at this step. If you
|
||||
cannot find a maintainer for the subsystem your are working on, Andrew
|
||||
cannot find a maintainer for the subsystem you are working on, Andrew
|
||||
Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
|
||||
|
||||
You should also normally choose at least one mailing list to receive a copy
|
||||
|
|
@ -291,7 +291,7 @@ sending him e-mail.
|
|||
|
||||
If you have a patch that fixes an exploitable security bug, send that patch
|
||||
to security@kernel.org. For severe bugs, a short embargo may be considered
|
||||
to allow distrbutors to get the patch out to users; in such cases,
|
||||
to allow distributors to get the patch out to users; in such cases,
|
||||
obviously, the patch should not be sent to any public lists.
|
||||
|
||||
Patches that fix a severe bug in a released kernel should be directed
|
||||
|
|
@ -340,7 +340,7 @@ on the changes you are submitting. It is important for a kernel
|
|||
developer to be able to "quote" your changes, using standard e-mail
|
||||
tools, so that they may comment on specific portions of your code.
|
||||
|
||||
For this reason, all patches should be submitting e-mail "inline".
|
||||
For this reason, all patches should be submitted by e-mail "inline".
|
||||
WARNING: Be wary of your editor's word-wrap corrupting your patch,
|
||||
if you choose to cut-n-paste your patch.
|
||||
|
||||
|
|
@ -739,7 +739,7 @@ interest on a single line; it should look something like:
|
|||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
to get these changes:
|
||||
|
||||
A pull request should also include an overall message saying what will be
|
||||
included in the request, a "git shortlog" listing of the patches
|
||||
|
|
@ -796,7 +796,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
|||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
|
||||
<Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
|
|
|||
|
|
@ -1,26 +1,192 @@
|
|||
/sys/module/acpi/parameters/:
|
||||
ACPICA Trace Facility
|
||||
|
||||
trace_method_name
|
||||
The AML method name that the user wants to trace
|
||||
Copyright (C) 2015, Intel Corporation
|
||||
Author: Lv Zheng <lv.zheng@intel.com>
|
||||
|
||||
trace_debug_layer
|
||||
The temporary debug_layer used when tracing the method.
|
||||
Using 0xffffffff by default if it is 0.
|
||||
|
||||
trace_debug_level
|
||||
The temporary debug_level used when tracing the method.
|
||||
Using 0x00ffffff by default if it is 0.
|
||||
Abstract:
|
||||
|
||||
trace_state
|
||||
This document describes the functions and the interfaces of the method
|
||||
tracing facility.
|
||||
|
||||
1. Functionalities and usage examples:
|
||||
|
||||
ACPICA provides method tracing capability. And two functions are
|
||||
currently implemented using this capability.
|
||||
|
||||
A. Log reducer
|
||||
ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is
|
||||
enabled. The debugging messages which are deployed via
|
||||
ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component
|
||||
level (known as debug layer, configured via
|
||||
/sys/module/acpi/parameters/debug_layer) and per-type level (known as
|
||||
debug level, configured via /sys/module/acpi/parameters/debug_level).
|
||||
|
||||
But when the particular layer/level is applied to the control method
|
||||
evaluations, the quantity of the debugging outputs may still be too
|
||||
large to be put into the kernel log buffer. The idea thus is worked out
|
||||
to only enable the particular debug layer/level (normally more detailed)
|
||||
logs when the control method evaluation is started, and disable the
|
||||
detailed logging when the control method evaluation is stopped.
|
||||
|
||||
The following command examples illustrate the usage of the "log reducer"
|
||||
functionality:
|
||||
a. Filter out the debug layer/level matched logs when control methods
|
||||
are being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "enable" > trace_state
|
||||
b. Filter out the debug layer/level matched logs when the specified
|
||||
control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method" > /sys/module/acpi/parameters/trace_state
|
||||
c. Filter out the debug layer/level matched logs when the specified
|
||||
control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method-once" > /sys/module/acpi/parameters/trace_state
|
||||
Where:
|
||||
0xXXXXXXXX/0xYYYYYYYY: Refer to Documentation/acpi/debug.txt for
|
||||
possible debug layer/level masking values.
|
||||
\PPPP.AAAA.TTTT.HHHH: Full path of a control method that can be found
|
||||
in the ACPI namespace. It needn't be an entry
|
||||
of a control method evaluation.
|
||||
|
||||
B. AML tracer
|
||||
|
||||
There are special log entries added by the method tracing facility at
|
||||
the "trace points" the AML interpreter starts/stops to execute a control
|
||||
method, or an AML opcode. Note that the format of the log entries are
|
||||
subject to change:
|
||||
[ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
[ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution.
|
||||
[ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution.
|
||||
[ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution.
|
||||
[ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution.
|
||||
[ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
|
||||
[ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
|
||||
[ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution.
|
||||
[ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution.
|
||||
[ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
|
||||
[ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
|
||||
[ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution.
|
||||
[ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution.
|
||||
[ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
|
||||
Developers can utilize these special log entries to track the AML
|
||||
interpretion, thus can aid issue debugging and performance tuning. Note
|
||||
that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT()
|
||||
macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling
|
||||
"AML tracer" logs.
|
||||
|
||||
The following command examples illustrate the usage of the "AML tracer"
|
||||
functionality:
|
||||
a. Filter out the method start/stop "AML tracer" logs when control
|
||||
methods are being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "enable" > trace_state
|
||||
b. Filter out the method start/stop "AML tracer" when the specified
|
||||
control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method" > trace_state
|
||||
c. Filter out the method start/stop "AML tracer" logs when the specified
|
||||
control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method-once" > trace_state
|
||||
d. Filter out the method/opcode start/stop "AML tracer" when the
|
||||
specified control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "opcode" > trace_state
|
||||
e. Filter out the method/opcode start/stop "AML tracer" when the
|
||||
specified control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "opcode-opcode" > trace_state
|
||||
|
||||
Note that all above method tracing facility related module parameters can
|
||||
be used as the boot parameters, for example:
|
||||
acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \
|
||||
acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once
|
||||
|
||||
2. Interface descriptions:
|
||||
|
||||
All method tracing functions can be configured via ACPI module
|
||||
parameters that are accessible at /sys/module/acpi/parameters/:
|
||||
|
||||
trace_method_name
|
||||
The full path of the AML method that the user wants to trace.
|
||||
Note that the full path shouldn't contain the trailing "_"s in its
|
||||
name segments but may contain "\" to form an absolute path.
|
||||
|
||||
trace_debug_layer
|
||||
The temporary debug_layer used when the tracing feature is enabled.
|
||||
Using ACPI_EXECUTER (0x80) by default, which is the debug_layer
|
||||
used to match all "AML tracer" logs.
|
||||
|
||||
trace_debug_level
|
||||
The temporary debug_level used when the tracing feature is enabled.
|
||||
Using ACPI_LV_TRACE_POINT (0x10) by default, which is the
|
||||
debug_level used to match all "AML tracer" logs.
|
||||
|
||||
trace_state
|
||||
The status of the tracing feature.
|
||||
|
||||
"enabled" means this feature is enabled
|
||||
and the AML method is traced every time it's executed.
|
||||
|
||||
"1" means this feature is enabled and the AML method
|
||||
will only be traced during the next execution.
|
||||
|
||||
"disabled" means this feature is disabled.
|
||||
Users can enable/disable this debug tracing feature by
|
||||
"echo string > /sys/module/acpi/parameters/trace_state".
|
||||
"string" should be one of "enable", "disable" and "1".
|
||||
Users can enable/disable this debug tracing feature by executing
|
||||
the following command:
|
||||
# echo string > /sys/module/acpi/parameters/trace_state
|
||||
Where "string" should be one of the followings:
|
||||
"disable"
|
||||
Disable the method tracing feature.
|
||||
"enable"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during any method
|
||||
execution will be logged.
|
||||
"method"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method execution
|
||||
of "trace_method_name" will be logged.
|
||||
"method-once"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method execution
|
||||
of "trace_method_name" will be logged only once.
|
||||
"opcode"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method/opcode
|
||||
execution of "trace_method_name" will be logged.
|
||||
"opcode-once"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method/opcode
|
||||
execution of "trace_method_name" will be logged only once.
|
||||
Note that, the difference between the "enable" and other feature
|
||||
enabling options are:
|
||||
1. When "enable" is specified, since
|
||||
"trace_debug_layer/trace_debug_level" shall apply to all control
|
||||
method evaluations, after configuring "trace_state" to "enable",
|
||||
"trace_method_name" will be reset to NULL.
|
||||
2. When "method/opcode" is specified, if
|
||||
"trace_method_name" is NULL when "trace_state" is configured to
|
||||
these options, the "trace_debug_layer/trace_debug_level" will
|
||||
apply to all control method evaluations.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,527 @@
|
|||
Adding a New System Call
|
||||
========================
|
||||
|
||||
This document describes what's involved in adding a new system call to the
|
||||
Linux kernel, over and above the normal submission advice in
|
||||
Documentation/SubmittingPatches.
|
||||
|
||||
|
||||
System Call Alternatives
|
||||
------------------------
|
||||
|
||||
The first thing to consider when adding a new system call is whether one of
|
||||
the alternatives might be suitable instead. Although system calls are the
|
||||
most traditional and most obvious interaction points between userspace and the
|
||||
kernel, there are other possibilities -- choose what fits best for your
|
||||
interface.
|
||||
|
||||
- If the operations involved can be made to look like a filesystem-like
|
||||
object, it may make more sense to create a new filesystem or device. This
|
||||
also makes it easier to encapsulate the new functionality in a kernel module
|
||||
rather than requiring it to be built into the main kernel.
|
||||
- If the new functionality involves operations where the kernel notifies
|
||||
userspace that something has happened, then returning a new file
|
||||
descriptor for the relevant object allows userspace to use
|
||||
poll/select/epoll to receive that notification.
|
||||
- However, operations that don't map to read(2)/write(2)-like operations
|
||||
have to be implemented as ioctl(2) requests, which can lead to a
|
||||
somewhat opaque API.
|
||||
- If you're just exposing runtime system information, a new node in sysfs
|
||||
(see Documentation/filesystems/sysfs.txt) or the /proc filesystem may be
|
||||
more appropriate. However, access to these mechanisms requires that the
|
||||
relevant filesystem is mounted, which might not always be the case (e.g.
|
||||
in a namespaced/sandboxed/chrooted environment). Avoid adding any API to
|
||||
debugfs, as this is not considered a 'production' interface to userspace.
|
||||
- If the operation is specific to a particular file or file descriptor, then
|
||||
an additional fcntl(2) command option may be more appropriate. However,
|
||||
fcntl(2) is a multiplexing system call that hides a lot of complexity, so
|
||||
this option is best for when the new function is closely analogous to
|
||||
existing fcntl(2) functionality, or the new functionality is very simple
|
||||
(for example, getting/setting a simple flag related to a file descriptor).
|
||||
- If the operation is specific to a particular task or process, then an
|
||||
additional prctl(2) command option may be more appropriate. As with
|
||||
fcntl(2), this system call is a complicated multiplexor so is best reserved
|
||||
for near-analogs of existing prctl() commands or getting/setting a simple
|
||||
flag related to a process.
|
||||
|
||||
|
||||
Designing the API: Planning for Extension
|
||||
-----------------------------------------
|
||||
|
||||
A new system call forms part of the API of the kernel, and has to be supported
|
||||
indefinitely. As such, it's a very good idea to explicitly discuss the
|
||||
interface on the kernel mailing list, and it's important to plan for future
|
||||
extensions of the interface.
|
||||
|
||||
(The syscall table is littered with historical examples where this wasn't done,
|
||||
together with the corresponding follow-up system calls -- eventfd/eventfd2,
|
||||
dup2/dup3, inotify_init/inotify_init1, pipe/pipe2, renameat/renameat2 -- so
|
||||
learn from the history of the kernel and plan for extensions from the start.)
|
||||
|
||||
For simpler system calls that only take a couple of arguments, the preferred
|
||||
way to allow for future extensibility is to include a flags argument to the
|
||||
system call. To make sure that userspace programs can safely use flags
|
||||
between kernel versions, check whether the flags value holds any unknown
|
||||
flags, and reject the system call (with EINVAL) if it does:
|
||||
|
||||
if (flags & ~(THING_FLAG1 | THING_FLAG2 | THING_FLAG3))
|
||||
return -EINVAL;
|
||||
|
||||
(If no flags values are used yet, check that the flags argument is zero.)
|
||||
|
||||
For more sophisticated system calls that involve a larger number of arguments,
|
||||
it's preferred to encapsulate the majority of the arguments into a structure
|
||||
that is passed in by pointer. Such a structure can cope with future extension
|
||||
by including a size argument in the structure:
|
||||
|
||||
struct xyzzy_params {
|
||||
u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
|
||||
u32 param_1;
|
||||
u64 param_2;
|
||||
u64 param_3;
|
||||
};
|
||||
|
||||
As long as any subsequently added field, say param_4, is designed so that a
|
||||
zero value gives the previous behaviour, then this allows both directions of
|
||||
version mismatch:
|
||||
|
||||
- To cope with a later userspace program calling an older kernel, the kernel
|
||||
code should check that any memory beyond the size of the structure that it
|
||||
expects is zero (effectively checking that param_4 == 0).
|
||||
- To cope with an older userspace program calling a newer kernel, the kernel
|
||||
code can zero-extend a smaller instance of the structure (effectively
|
||||
setting param_4 = 0).
|
||||
|
||||
See perf_event_open(2) and the perf_copy_attr() function (in
|
||||
kernel/events/core.c) for an example of this approach.
|
||||
|
||||
|
||||
Designing the API: Other Considerations
|
||||
---------------------------------------
|
||||
|
||||
If your new system call allows userspace to refer to a kernel object, it
|
||||
should use a file descriptor as the handle for that object -- don't invent a
|
||||
new type of userspace object handle when the kernel already has mechanisms and
|
||||
well-defined semantics for using file descriptors.
|
||||
|
||||
If your new xyzzy(2) system call does return a new file descriptor, then the
|
||||
flags argument should include a value that is equivalent to setting O_CLOEXEC
|
||||
on the new FD. This makes it possible for userspace to close the timing
|
||||
window between xyzzy() and calling fcntl(fd, F_SETFD, FD_CLOEXEC), where an
|
||||
unexpected fork() and execve() in another thread could leak a descriptor to
|
||||
the exec'ed program. (However, resist the temptation to re-use the actual value
|
||||
of the O_CLOEXEC constant, as it is architecture-specific and is part of a
|
||||
numbering space of O_* flags that is fairly full.)
|
||||
|
||||
If your system call returns a new file descriptor, you should also consider
|
||||
what it means to use the poll(2) family of system calls on that file
|
||||
descriptor. Making a file descriptor ready for reading or writing is the
|
||||
normal way for the kernel to indicate to userspace that an event has
|
||||
occurred on the corresponding kernel object.
|
||||
|
||||
If your new xyzzy(2) system call involves a filename argument:
|
||||
|
||||
int sys_xyzzy(const char __user *path, ..., unsigned int flags);
|
||||
|
||||
you should also consider whether an xyzzyat(2) version is more appropriate:
|
||||
|
||||
int sys_xyzzyat(int dfd, const char __user *path, ..., unsigned int flags);
|
||||
|
||||
This allows more flexibility for how userspace specifies the file in question;
|
||||
in particular it allows userspace to request the functionality for an
|
||||
already-opened file descriptor using the AT_EMPTY_PATH flag, effectively giving
|
||||
an fxyzzy(3) operation for free:
|
||||
|
||||
- xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
|
||||
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
|
||||
|
||||
(For more details on the rationale of the *at() calls, see the openat(2) man
|
||||
page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
|
||||
|
||||
If your new xyzzy(2) system call involves a parameter describing an offset
|
||||
within a file, make its type loff_t so that 64-bit offsets can be supported
|
||||
even on 32-bit architectures.
|
||||
|
||||
If your new xyzzy(2) system call involves privileged functionality, it needs
|
||||
to be governed by the appropriate Linux capability bit (checked with a call to
|
||||
capable()), as described in the capabilities(7) man page. Choose an existing
|
||||
capability bit that governs related functionality, but try to avoid combining
|
||||
lots of only vaguely related functions together under the same bit, as this
|
||||
goes against capabilities' purpose of splitting the power of root. In
|
||||
particular, avoid adding new uses of the already overly-general CAP_SYS_ADMIN
|
||||
capability.
|
||||
|
||||
If your new xyzzy(2) system call manipulates a process other than the calling
|
||||
process, it should be restricted (using a call to ptrace_may_access()) so that
|
||||
only a calling process with the same permissions as the target process, or
|
||||
with the necessary capabilities, can manipulate the target process.
|
||||
|
||||
Finally, be aware that some non-x86 architectures have an easier time if
|
||||
system call parameters that are explicitly 64-bit fall on odd-numbered
|
||||
arguments (i.e. parameter 1, 3, 5), to allow use of contiguous pairs of 32-bit
|
||||
registers. (This concern does not apply if the arguments are part of a
|
||||
structure that's passed in by pointer.)
|
||||
|
||||
|
||||
Proposing the API
|
||||
-----------------
|
||||
|
||||
To make new system calls easy to review, it's best to divide up the patchset
|
||||
into separate chunks. These should include at least the following items as
|
||||
distinct commits (each of which is described further below):
|
||||
|
||||
- The core implementation of the system call, together with prototypes,
|
||||
generic numbering, Kconfig changes and fallback stub implementation.
|
||||
- Wiring up of the new system call for one particular architecture, usually
|
||||
x86 (including all of x86_64, x86_32 and x32).
|
||||
- A demonstration of the use of the new system call in userspace via a
|
||||
selftest in tools/testing/selftests/.
|
||||
- A draft man-page for the new system call, either as plain text in the
|
||||
cover letter, or as a patch to the (separate) man-pages repository.
|
||||
|
||||
New system call proposals, like any change to the kernel's API, should always
|
||||
be cc'ed to linux-api@vger.kernel.org.
|
||||
|
||||
|
||||
Generic System Call Implementation
|
||||
----------------------------------
|
||||
|
||||
The main entry point for your new xyzzy(2) system call will be called
|
||||
sys_xyzzy(), but you add this entry point with the appropriate
|
||||
SYSCALL_DEFINEn() macro rather than explicitly. The 'n' indicates the number
|
||||
of arguments to the system call, and the macro takes the system call name
|
||||
followed by the (type, name) pairs for the parameters as arguments. Using
|
||||
this macro allows metadata about the new system call to be made available for
|
||||
other tools.
|
||||
|
||||
The new entry point also needs a corresponding function prototype, in
|
||||
include/linux/syscalls.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long sys_xyzzy(...);
|
||||
|
||||
Some architectures (e.g. x86) have their own architecture-specific syscall
|
||||
tables, but several other architectures share a generic syscall table. Add your
|
||||
new system call to the generic list by adding an entry to the list in
|
||||
include/uapi/asm-generic/unistd.h:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SYSCALL(__NR_xyzzy, sys_xyzzy)
|
||||
|
||||
Also update the __NR_syscalls count to reflect the additional system call, and
|
||||
note that if multiple new system calls are added in the same merge window,
|
||||
your new syscall number may get adjusted to resolve conflicts.
|
||||
|
||||
The file kernel/sys_ni.c provides a fallback stub implementation of each system
|
||||
call, returning -ENOSYS. Add your new system call here too:
|
||||
|
||||
cond_syscall(sys_xyzzy);
|
||||
|
||||
Your new kernel functionality, and the system call that controls it, should
|
||||
normally be optional, so add a CONFIG option (typically to init/Kconfig) for
|
||||
it. As usual for new CONFIG options:
|
||||
|
||||
- Include a description of the new functionality and system call controlled
|
||||
by the option.
|
||||
- Make the option depend on EXPERT if it should be hidden from normal users.
|
||||
- Make any new source files implementing the function dependent on the CONFIG
|
||||
option in the Makefile (e.g. "obj-$(CONFIG_XYZZY_SYSCALL) += xyzzy.c").
|
||||
- Double check that the kernel still builds with the new CONFIG option turned
|
||||
off.
|
||||
|
||||
To summarize, you need a commit that includes:
|
||||
|
||||
- CONFIG option for the new function, normally in init/Kconfig
|
||||
- SYSCALL_DEFINEn(xyzzy, ...) for the entry point
|
||||
- corresponding prototype in include/linux/syscalls.h
|
||||
- generic table entry in include/uapi/asm-generic/unistd.h
|
||||
- fallback stub in kernel/sys_ni.c
|
||||
|
||||
|
||||
x86 System Call Implementation
|
||||
------------------------------
|
||||
|
||||
To wire up your new system call for x86 platforms, you need to update the
|
||||
master syscall tables. Assuming your new system call isn't special in some
|
||||
way (see below), this involves a "common" entry (for x86_64 and x32) in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl:
|
||||
|
||||
333 common xyzzy sys_xyzzy
|
||||
|
||||
and an "i386" entry in arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy
|
||||
|
||||
Again, these numbers are liable to be changed if there are conflicts in the
|
||||
relevant merge window.
|
||||
|
||||
|
||||
Compatibility System Calls (Generic)
|
||||
------------------------------------
|
||||
|
||||
For most system calls the same 64-bit implementation can be invoked even when
|
||||
the userspace program is itself 32-bit; even if the system call's parameters
|
||||
include an explicit pointer, this is handled transparently.
|
||||
|
||||
However, there are a couple of situations where a compatibility layer is
|
||||
needed to cope with size differences between 32-bit and 64-bit.
|
||||
|
||||
The first is if the 64-bit kernel also supports 32-bit userspace programs, and
|
||||
so needs to parse areas of (__user) memory that could hold either 32-bit or
|
||||
64-bit values. In particular, this is needed whenever a system call argument
|
||||
is:
|
||||
|
||||
- a pointer to a pointer
|
||||
- a pointer to a struct containing a pointer (e.g. struct iovec __user *)
|
||||
- a pointer to a varying sized integral type (time_t, off_t, long, ...)
|
||||
- a pointer to a struct containing a varying sized integral type.
|
||||
|
||||
The second situation that requires a compatibility layer is if one of the
|
||||
system call's arguments has a type that is explicitly 64-bit even on a 32-bit
|
||||
architecture, for example loff_t or __u64. In this case, a value that arrives
|
||||
at a 64-bit kernel from a 32-bit application will be split into two 32-bit
|
||||
values, which then need to be re-assembled in the compatibility layer.
|
||||
|
||||
(Note that a system call argument that's a pointer to an explicit 64-bit type
|
||||
does *not* need a compatibility layer; for example, splice(2)'s arguments of
|
||||
type loff_t __user * do not trigger the need for a compat_ system call.)
|
||||
|
||||
The compatibility version of the system call is called compat_sys_xyzzy(), and
|
||||
is added with the COMPAT_SYSCALL_DEFINEn() macro, analogously to
|
||||
SYSCALL_DEFINEn. This version of the implementation runs as part of a 64-bit
|
||||
kernel, but expects to receive 32-bit parameter values and does whatever is
|
||||
needed to deal with them. (Typically, the compat_sys_ version converts the
|
||||
values to 64-bit versions and either calls on to the sys_ version, or both of
|
||||
them call a common inner implementation function.)
|
||||
|
||||
The compat entry point also needs a corresponding function prototype, in
|
||||
include/linux/compat.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long compat_sys_xyzzy(...);
|
||||
|
||||
If the system call involves a structure that is laid out differently on 32-bit
|
||||
and 64-bit systems, say struct xyzzy_args, then the include/linux/compat.h
|
||||
header file should also include a compat version of the structure (struct
|
||||
compat_xyzzy_args) where each variable-size field has the appropriate compat_
|
||||
type that corresponds to the type in struct xyzzy_args. The
|
||||
compat_sys_xyzzy() routine can then use this compat_ structure to parse the
|
||||
arguments from a 32-bit invocation.
|
||||
|
||||
For example, if there are fields:
|
||||
|
||||
struct xyzzy_args {
|
||||
const char __user *ptr;
|
||||
__kernel_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
in struct xyzzy_args, then struct compat_xyzzy_args would have:
|
||||
|
||||
struct compat_xyzzy_args {
|
||||
compat_uptr_t ptr;
|
||||
compat_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
The generic system call list also needs adjusting to allow for the compat
|
||||
version; the entry in include/uapi/asm-generic/unistd.h should use
|
||||
__SC_COMP rather than __SYSCALL:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SC_COMP(__NR_xyzzy, sys_xyzzy, compat_sys_xyzzy)
|
||||
|
||||
To summarize, you need:
|
||||
|
||||
- a COMPAT_SYSCALL_DEFINEn(xyzzy, ...) for the compat entry point
|
||||
- corresponding prototype in include/linux/compat.h
|
||||
- (if needed) 32-bit mapping struct in include/linux/compat.h
|
||||
- instance of __SC_COMP not __SYSCALL in include/uapi/asm-generic/unistd.h
|
||||
|
||||
|
||||
Compatibility System Calls (x86)
|
||||
--------------------------------
|
||||
|
||||
To wire up the x86 architecture of a system call with a compatibility version,
|
||||
the entries in the syscall tables need to be adjusted.
|
||||
|
||||
First, the entry in arch/x86/entry/syscalls/syscall_32.tbl gets an extra
|
||||
column to indicate that a 32-bit userspace program running on a 64-bit kernel
|
||||
should hit the compat entry point:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy compat_sys_xyzzy
|
||||
|
||||
Second, you need to figure out what should happen for the x32 ABI version of
|
||||
the new system call. There's a choice here: the layout of the arguments
|
||||
should either match the 64-bit version or the 32-bit version.
|
||||
|
||||
If there's a pointer-to-a-pointer involved, the decision is easy: x32 is
|
||||
ILP32, so the layout should match the 32-bit version, and the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is split so that x32 programs hit the
|
||||
compatibility wrapper:
|
||||
|
||||
333 64 xyzzy sys_xyzzy
|
||||
...
|
||||
555 x32 xyzzy compat_sys_xyzzy
|
||||
|
||||
If no pointers are involved, then it is preferable to re-use the 64-bit system
|
||||
call for the x32 ABI (and consequently the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is unchanged).
|
||||
|
||||
In either case, you should check that the types involved in your argument
|
||||
layout do indeed map exactly from x32 (-mx32) to either the 32-bit (-m32) or
|
||||
64-bit (-m64) equivalents.
|
||||
|
||||
|
||||
System Calls Returning Elsewhere
|
||||
--------------------------------
|
||||
|
||||
For most system calls, once the system call is complete the user program
|
||||
continues exactly where it left off -- at the next instruction, with the
|
||||
stack the same and most of the registers the same as before the system call,
|
||||
and with the same virtual memory space.
|
||||
|
||||
However, a few system calls do things differently. They might return to a
|
||||
different location (rt_sigreturn) or change the memory space (fork/vfork/clone)
|
||||
or even architecture (execve/execveat) of the program.
|
||||
|
||||
To allow for this, the kernel implementation of the system call may need to
|
||||
save and restore additional registers to the kernel stack, allowing complete
|
||||
control of where and how execution continues after the system call.
|
||||
|
||||
This is arch-specific, but typically involves defining assembly entry points
|
||||
that save/restore additional registers and invoke the real system call entry
|
||||
point.
|
||||
|
||||
For x86_64, this is implemented as a stub_xyzzy entry point in
|
||||
arch/x86/entry/entry_64.S, and the entry in the syscall table
|
||||
(arch/x86/entry/syscalls/syscall_64.tbl) is adjusted to match:
|
||||
|
||||
333 common xyzzy stub_xyzzy
|
||||
|
||||
The equivalent for 32-bit programs running on a 64-bit kernel is normally
|
||||
called stub32_xyzzy and implemented in arch/x86/entry/entry_64_compat.S,
|
||||
with the corresponding syscall table adjustment in
|
||||
arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy stub32_xyzzy
|
||||
|
||||
If the system call needs a compatibility layer (as in the previous section)
|
||||
then the stub32_ version needs to call on to the compat_sys_ version of the
|
||||
system call rather than the native 64-bit version. Also, if the x32 ABI
|
||||
implementation is not common with the x86_64 version, then its syscall
|
||||
table will also need to invoke a stub that calls on to the compat_sys_
|
||||
version.
|
||||
|
||||
For completeness, it's also nice to set up a mapping so that user-mode Linux
|
||||
still works -- its syscall table will reference stub_xyzzy, but the UML build
|
||||
doesn't include arch/x86/entry/entry_64.S implementation (because UML
|
||||
simulates registers etc). Fixing this is as simple as adding a #define to
|
||||
arch/x86/um/sys_call_table_64.c:
|
||||
|
||||
#define stub_xyzzy sys_xyzzy
|
||||
|
||||
|
||||
Other Details
|
||||
-------------
|
||||
|
||||
Most of the kernel treats system calls in a generic way, but there is the
|
||||
occasional exception that may need updating for your particular system call.
|
||||
|
||||
The audit subsystem is one such special case; it includes (arch-specific)
|
||||
functions that classify some special types of system call -- specifically
|
||||
file open (open/openat), program execution (execve/exeveat) or socket
|
||||
multiplexor (socketcall) operations. If your new system call is analogous to
|
||||
one of these, then the audit system should be updated.
|
||||
|
||||
More generally, if there is an existing system call that is analogous to your
|
||||
new system call, it's worth doing a kernel-wide grep for the existing system
|
||||
call to check there are no other special cases.
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
A new system call should obviously be tested; it is also useful to provide
|
||||
reviewers with a demonstration of how user space programs will use the system
|
||||
call. A good way to combine these aims is to include a simple self-test
|
||||
program in a new directory under tools/testing/selftests/.
|
||||
|
||||
For a new system call, there will obviously be no libc wrapper function and so
|
||||
the test will need to invoke it using syscall(); also, if the system call
|
||||
involves a new userspace-visible structure, the corresponding header will need
|
||||
to be installed to compile the test.
|
||||
|
||||
Make sure the selftest runs successfully on all supported architectures. For
|
||||
example, check that it works when compiled as an x86_64 (-m64), x86_32 (-m32)
|
||||
and x32 (-mx32) ABI program.
|
||||
|
||||
For more extensive and thorough testing of new functionality, you should also
|
||||
consider adding tests to the Linux Test Project, or to the xfstests project
|
||||
for filesystem-related changes.
|
||||
- https://linux-test-project.github.io/
|
||||
- git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
|
||||
|
||||
|
||||
Man Page
|
||||
--------
|
||||
|
||||
All new system calls should come with a complete man page, ideally using groff
|
||||
markup, but plain text will do. If groff is used, it's helpful to include a
|
||||
pre-rendered ASCII version of the man page in the cover email for the
|
||||
patchset, for the convenience of reviewers.
|
||||
|
||||
The man page should be cc'ed to linux-man@vger.kernel.org
|
||||
For more details, see https://www.kernel.org/doc/man-pages/patches.html
|
||||
|
||||
References and Sources
|
||||
----------------------
|
||||
|
||||
- LWN article from Michael Kerrisk on use of flags argument in system calls:
|
||||
https://lwn.net/Articles/585415/
|
||||
- LWN article from Michael Kerrisk on how to handle unknown flags in a system
|
||||
call: https://lwn.net/Articles/588444/
|
||||
- LWN article from Jake Edge describing constraints on 64-bit system call
|
||||
arguments: https://lwn.net/Articles/311630/
|
||||
- Pair of LWN articles from David Drysdale that describe the system call
|
||||
implementation paths in detail for v3.14:
|
||||
- https://lwn.net/Articles/604287/
|
||||
- https://lwn.net/Articles/604515/
|
||||
- Architecture-specific requirements for system calls are discussed in the
|
||||
syscall(2) man-page:
|
||||
http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
|
||||
- Collated emails from Linus Torvalds discussing the problems with ioctl():
|
||||
http://yarchive.net/comp/linux/ioctl.html
|
||||
- "How to not invent kernel interfaces", Arnd Bergmann,
|
||||
http://www.ukuug.org/events/linux2007/2007/papers/Bergmann.pdf
|
||||
- LWN article from Michael Kerrisk on avoiding new uses of CAP_SYS_ADMIN:
|
||||
https://lwn.net/Articles/486306/
|
||||
- Recommendation from Andrew Morton that all related information for a new
|
||||
system call should come in the same email thread:
|
||||
https://lkml.org/lkml/2014/7/24/641
|
||||
- Recommendation from Michael Kerrisk that a new system call should come with
|
||||
a man page: https://lkml.org/lkml/2014/6/13/309
|
||||
- Suggestion from Thomas Gleixner that x86 wire-up should be in a separate
|
||||
commit: https://lkml.org/lkml/2014/11/19/254
|
||||
- Suggestion from Greg Kroah-Hartman that it's good for new system calls to
|
||||
come with a man-page & selftest: https://lkml.org/lkml/2014/3/19/710
|
||||
- Discussion from Michael Kerrisk of new system call vs. prctl(2) extension:
|
||||
https://lkml.org/lkml/2014/6/3/411
|
||||
- Suggestion from Ingo Molnar that system calls that involve multiple
|
||||
arguments should encapsulate those arguments in a struct, which includes a
|
||||
size field for future extensibility: https://lkml.org/lkml/2015/7/30/117
|
||||
- Numbering oddities arising from (re-)use of O_* numbering space flags:
|
||||
- commit 75069f2b5bfb ("vfs: renumber FMODE_NONOTIFY and add to uniqueness
|
||||
check")
|
||||
- commit 12ed2e36c98a ("fanotify: FMODE_NONOTIFY and __O_SYNC in sparc
|
||||
conflict")
|
||||
- commit bb458c644a59 ("Safer ABI for O_TMPFILE")
|
||||
- Discussion from Matthew Wilcox about restrictions on 64-bit arguments:
|
||||
https://lkml.org/lkml/2008/12/12/187
|
||||
- Recommendation from Greg Kroah-Hartman that unknown flags should be
|
||||
policed: https://lkml.org/lkml/2014/7/17/577
|
||||
- Recommendation from Linus Torvalds that x32 system calls should prefer
|
||||
compatibility with 64-bit versions rather than 32-bit versions:
|
||||
https://lkml.org/lkml/2011/8/31/244
|
||||
|
|
@ -90,6 +90,11 @@ the Atmel website: http://www.atmel.com.
|
|||
+ Datasheet
|
||||
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
|
||||
|
||||
- sama5d2 family
|
||||
- sama5d27
|
||||
+ Datasheet
|
||||
Coming soon
|
||||
|
||||
|
||||
Linux kernel information
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ executing kernel.
|
|||
|
||||
|
||||
1. Non-Secure mode
|
||||
|
||||
Address: sysram_ns_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -28,6 +29,7 @@ Offset Value Purpose
|
|||
|
||||
|
||||
2. Secure mode
|
||||
|
||||
Address: sysram_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -40,14 +42,25 @@ Offset Value Purpose
|
|||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0800 exynos_cpu_resume AFTR
|
||||
0x0800 exynos_cpu_resume AFTR, suspend
|
||||
0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend
|
||||
0x0804 0xfcba0d10 (Magic cookie) AFTR
|
||||
0x0804 0x00000bad (Magic cookie) System suspend
|
||||
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
|
||||
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
|
||||
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
|
||||
|
||||
|
||||
3. Other (regardless of secure/non-secure mode)
|
||||
|
||||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
|
||||
|
||||
|
||||
4. Glossary
|
||||
|
||||
AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other
|
||||
modules are power gated, except the TOP modules
|
||||
MCPM - Multi-Cluster Power Management
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
TI Keystone Linux Overview
|
||||
--------------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
Keystone range of SoCs are based on ARM Cortex-A15 MPCore Processors
|
||||
and c66x DSP cores. This document describes essential information required
|
||||
for users to run Linux on Keystone based EVMs from Texas Instruments.
|
||||
|
||||
Following SoCs & EVMs are currently supported:-
|
||||
|
||||
------------ K2HK SoC and EVM --------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Hawking/Kepler SoC
|
||||
TCI6636K2H & TCI6636K2K: See documentation at
|
||||
http://www.ti.com/product/tci6638k2k
|
||||
http://www.ti.com/product/tci6638k2h
|
||||
|
||||
EVM:
|
||||
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
|
||||
|
||||
------------ K2E SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Edison SoC
|
||||
K2E - 66AK2E05: See documentation at
|
||||
http://www.ti.com/product/66AK2E05/technicaldocuments
|
||||
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
|
||||
|
||||
------------ K2L SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Lamarr SoC
|
||||
K2L - TCI6630K2L: See documentation at
|
||||
http://www.ti.com/product/TCI6630K2L/technicaldocuments
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
All of the K2 SoCs/EVMs share a common defconfig, keystone_defconfig and same
|
||||
image is used to boot on individual EVMs. The platform configuration is
|
||||
specified through DTS. Following are the DTS used:-
|
||||
K2HK EVM : k2hk-evm.dts
|
||||
K2E EVM : k2e-evm.dts
|
||||
K2L EVM : k2l-evm.dts
|
||||
|
||||
The device tree documentation for the keystone machines are located at
|
||||
Documentation/devicetree/bindings/arm/keystone/keystone.txt
|
||||
|
||||
Known issues & workaround
|
||||
-------------------------
|
||||
|
||||
Some of the device drivers used on keystone are re-used from that from
|
||||
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
|
||||
Some of the keystone specific drivers such as netcp uses run time power
|
||||
management API instead to enable clock. As this API has limitations on
|
||||
keystone, following workaround is needed to boot Linux.
|
||||
|
||||
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
|
||||
clock frameworks will try to disable clocks that are unused and disable
|
||||
the hardware. This is because netcp related power domain and clock
|
||||
domains are enabled in u-boot as run time power management API currently
|
||||
doesn't enable clocks for netcp due to a limitation. This workaround is
|
||||
expected to be removed in the future when proper API support becomes
|
||||
available. Until then, this work around is needed.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
Murali Karicheri <m-karicheri2@ti.com>
|
||||
Copyright 2015 Texas Instruments
|
||||
|
|
@ -81,7 +81,7 @@ The decompressed kernel image contains a 64-byte header as follows:
|
|||
u64 res3 = 0; /* reserved */
|
||||
u64 res4 = 0; /* reserved */
|
||||
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
|
||||
u32 res5; /* reserved (used for PE COFF offset) */
|
||||
u32 res5; /* reserved (used for PE COFF offset) */
|
||||
|
||||
|
||||
Header notes:
|
||||
|
|
@ -103,7 +103,7 @@ 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.
|
||||
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
|
||||
Bits 1-63: Reserved.
|
||||
|
||||
- When image_size is zero, a bootloader should attempt to keep as much
|
||||
|
|
@ -115,11 +115,14 @@ The Image must be placed text_offset bytes from a 2MB aligned base
|
|||
address near the start of usable system RAM and called there. Memory
|
||||
below that base address is currently unusable by Linux, and therefore it
|
||||
is strongly recommended that this location is the start of system RAM.
|
||||
The region between the 2 MB aligned base address and the start of the
|
||||
image has no special significance to the kernel, and may be used for
|
||||
other purposes.
|
||||
At least image_size bytes from the start of the image must be free for
|
||||
use by the kernel.
|
||||
|
||||
Any memory described to the kernel (even that below the 2MB aligned base
|
||||
address) which is not marked as reserved from the kernel e.g. with a
|
||||
Any memory described to the kernel (even that below the start of the
|
||||
image) which is not marked as reserved from the kernel (e.g., with a
|
||||
memreserve region in the device tree) will be considered as available to
|
||||
the kernel.
|
||||
|
||||
|
|
|
|||
|
|
@ -1109,7 +1109,7 @@ it will loop and handle as many sectors (on a bio-segment granularity)
|
|||
as specified.
|
||||
|
||||
Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the
|
||||
right thing to use is bio_endio(bio, uptodate) instead.
|
||||
right thing to use is bio_endio(bio) instead.
|
||||
|
||||
If the driver is dropping the io_request_lock from its request_fn strategy,
|
||||
then it just needs to replace that with q->queue_lock instead.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ particular, presenting the illusion of partially completed biovecs so that
|
|||
normal code doesn't have to deal with bi_bvec_done.
|
||||
|
||||
* Driver code should no longer refer to biovecs directly; we now have
|
||||
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
|
||||
bio_iovec() and bio_iter_iovec() macros that return literal struct biovecs,
|
||||
constructed from the raw biovecs but taking into account bi_bvec_done and
|
||||
bi_size.
|
||||
|
||||
|
|
@ -109,3 +109,11 @@ Other implications:
|
|||
over all the biovecs in the new bio - which is silly as it's not needed.
|
||||
|
||||
So, don't use bi_vcnt anymore.
|
||||
|
||||
* The current interface allows the block layer to split bios as needed, so we
|
||||
could eliminate a lot of complexity particularly in stacked drivers. Code
|
||||
that creates bios can then create whatever size bios are convenient, and
|
||||
more importantly stacked drivers don't have to deal with both their own bio
|
||||
size limitations and the limitations of the underlying devices. Thus
|
||||
there's no need to define ->merge_bvec_fn() callbacks for individual block
|
||||
drivers.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This shows the size of internal allocation of the device in bytes, if
|
|||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
discard_max_hw_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
|
|
@ -29,6 +29,14 @@ number of bytes that can be discarded in a single operation. Discard
|
|||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_max_bytes (RW)
|
||||
----------------------
|
||||
While discard_max_hw_bytes is the hardware limit for the device, this
|
||||
setting is the software limit. Some devices exhibit large latencies when
|
||||
large discards are issued, setting this value lower will make Linux issue
|
||||
smaller discards and potentially help reduce latencies induced by large
|
||||
discard operations.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
|
|
|
|||
|
|
@ -144,7 +144,8 @@ mem_used_max RW the maximum amount memory zram have consumed to
|
|||
store compressed data
|
||||
mem_limit RW the maximum amount of memory ZRAM can use to store
|
||||
the compressed data
|
||||
num_migrated RO the number of objects migrated migrated by compaction
|
||||
pages_compacted RO the number of pages freed during compaction
|
||||
(available only via zram<id>/mm_stat node)
|
||||
compact WO trigger memory compaction
|
||||
|
||||
WARNING
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ net_cls.txt
|
|||
- Network classifier cgroups details and usages.
|
||||
net_prio.txt
|
||||
- Network priority cgroups details and usages.
|
||||
pids.txt
|
||||
- Process number cgroups details and usages.
|
||||
resource_counter.txt
|
||||
- Resource Counter API.
|
||||
unified-hierarchy.txt
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ Proportional weight policy files
|
|||
specifies the number of bytes.
|
||||
|
||||
- blkio.io_serviced
|
||||
- Number of IOs completed to/from the disk by the group. These
|
||||
- Number of IOs (bio) issued to the disk by the group. These
|
||||
are further divided by the type of operation - read or write, sync
|
||||
or async. First two fields specify the major and minor number of the
|
||||
device, third field specifies the operation type and the fourth field
|
||||
|
|
@ -327,18 +327,11 @@ Note: If both BW and IOPS rules are specified for a device, then IO is
|
|||
subjected to both the constraints.
|
||||
|
||||
- blkio.throttle.io_serviced
|
||||
- Number of IOs (bio) completed to/from the disk by the group (as
|
||||
seen by throttling policy). These are further divided by the type
|
||||
of operation - read or write, sync or async. First two fields specify
|
||||
the major and minor number of the device, third field specifies the
|
||||
operation type and the fourth field specifies the number of IOs.
|
||||
|
||||
blkio.io_serviced does accounting as seen by CFQ and counts are in
|
||||
number of requests (struct request). On the other hand,
|
||||
blkio.throttle.io_serviced counts number of IO in terms of number
|
||||
of bios as seen by throttling policy. These bios can later be
|
||||
merged by elevator and total number of requests completed can be
|
||||
lesser.
|
||||
- Number of IOs (bio) issued to the disk by the group. These
|
||||
are further divided by the type of operation - read or write, sync
|
||||
or async. First two fields specify the major and minor number of the
|
||||
device, third field specifies the operation type and the fourth field
|
||||
specifies the number of IOs.
|
||||
|
||||
- blkio.throttle.io_service_bytes
|
||||
- Number of bytes transferred to/from the disk by the group. These
|
||||
|
|
@ -347,11 +340,6 @@ Note: If both BW and IOPS rules are specified for a device, then IO is
|
|||
device, third field specifies the operation type and the fourth field
|
||||
specifies the number of bytes.
|
||||
|
||||
These numbers should roughly be same as blkio.io_service_bytes as
|
||||
updated by CFQ. The difference between two is that
|
||||
blkio.io_service_bytes will not be updated if CFQ is not operating
|
||||
on request queue.
|
||||
|
||||
Common files among various policies
|
||||
-----------------------------------
|
||||
- blkio.reset_stats
|
||||
|
|
|
|||
|
|
@ -0,0 +1,85 @@
|
|||
Process Number Controller
|
||||
=========================
|
||||
|
||||
Abstract
|
||||
--------
|
||||
|
||||
The process number controller is used to allow a cgroup hierarchy to stop any
|
||||
new tasks from being fork()'d or clone()'d after a certain limit is reached.
|
||||
|
||||
Since it is trivial to hit the task limit without hitting any kmemcg limits in
|
||||
place, PIDs are a fundamental resource. As such, PID exhaustion must be
|
||||
preventable in the scope of a cgroup hierarchy by allowing resource limiting of
|
||||
the number of tasks in a cgroup.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
In order to use the `pids` controller, set the maximum number of tasks in
|
||||
pids.max (this is not available in the root cgroup for obvious reasons). The
|
||||
number of processes currently in the cgroup is given by pids.current.
|
||||
|
||||
Organisational operations are not blocked by cgroup policies, so it is possible
|
||||
to have pids.current > pids.max. This can be done by either setting the limit to
|
||||
be smaller than pids.current, or attaching enough processes to the cgroup such
|
||||
that pids.current > pids.max. However, it is not possible to violate a cgroup
|
||||
policy through fork() or clone(). fork() and clone() will return -EAGAIN if the
|
||||
creation of a new process would cause a cgroup policy to be violated.
|
||||
|
||||
To set a cgroup to have no limit, set pids.max to "max". This is the default for
|
||||
all new cgroups (N.B. that PID limits are hierarchical, so the most stringent
|
||||
limit in the hierarchy is followed).
|
||||
|
||||
pids.current tracks all child cgroup hierarchies, so parent/pids.current is a
|
||||
superset of parent/child/pids.current.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
First, we mount the pids controller:
|
||||
# mkdir -p /sys/fs/cgroup/pids
|
||||
# mount -t cgroup -o pids none /sys/fs/cgroup/pids
|
||||
|
||||
Then we create a hierarchy, set limits and attach processes to it:
|
||||
# mkdir -p /sys/fs/cgroup/pids/parent/child
|
||||
# echo 2 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# echo $$ > /sys/fs/cgroup/pids/parent/cgroup.procs
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
#
|
||||
|
||||
It should be noted that attempts to overcome the set limit (2 in this case) will
|
||||
fail:
|
||||
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
# ( /bin/echo "Here's some processes for you." | cat )
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
||||
Even if we migrate to a child cgroup (which doesn't have a set limit), we will
|
||||
not be able to overcome the most stringent limit in the hierarchy (in this case,
|
||||
parent's):
|
||||
|
||||
# echo $$ > /sys/fs/cgroup/pids/parent/child/cgroup.procs
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
# cat /sys/fs/cgroup/pids/parent/child/pids.current
|
||||
2
|
||||
# cat /sys/fs/cgroup/pids/parent/child/pids.max
|
||||
max
|
||||
# ( /bin/echo "Here's some processes for you." | cat )
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
||||
We can set a limit that is smaller than pids.current, which will stop any new
|
||||
processes from being forked at all (note that the shell itself counts towards
|
||||
pids.current):
|
||||
|
||||
# echo 1 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# /bin/echo "We can't even spawn a single process now."
|
||||
sh: fork: Resource temporary unavailable
|
||||
# echo 0 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# /bin/echo "We can't even spawn a single process now."
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
|
@ -23,10 +23,13 @@ CONTENTS
|
|||
5. Other Changes
|
||||
5-1. [Un]populated Notification
|
||||
5-2. Other Core Changes
|
||||
5-3. Per-Controller Changes
|
||||
5-3-1. blkio
|
||||
5-3-2. cpuset
|
||||
5-3-3. memory
|
||||
5-3. Controller File Conventions
|
||||
5-3-1. Format
|
||||
5-3-2. Control Knobs
|
||||
5-4. Per-Controller Changes
|
||||
5-4-1. io
|
||||
5-4-2. cpuset
|
||||
5-4-3. memory
|
||||
6. Planned Changes
|
||||
6-1. CAP for resource control
|
||||
|
||||
|
|
@ -200,7 +203,7 @@ other issues. The mapping from nice level to weight isn't obvious or
|
|||
universal, and there are various other knobs which simply aren't
|
||||
available for tasks.
|
||||
|
||||
The blkio controller implicitly creates a hidden leaf node for each
|
||||
The io controller implicitly creates a hidden leaf node for each
|
||||
cgroup to host the tasks. The hidden leaf has its own copies of all
|
||||
the knobs with "leaf_" prefixed. While this allows equivalent control
|
||||
over internal tasks, it's with serious drawbacks. It always adds an
|
||||
|
|
@ -372,14 +375,128 @@ supported and the interface files "release_agent" and
|
|||
- The "cgroup.clone_children" file is removed.
|
||||
|
||||
|
||||
5-3. Per-Controller Changes
|
||||
5-3. Controller File Conventions
|
||||
|
||||
5-3-1. blkio
|
||||
5-3-1. Format
|
||||
|
||||
- blk-throttle becomes properly hierarchical.
|
||||
In general, all controller files should be in one of the following
|
||||
formats whenever possible.
|
||||
|
||||
- Values only files
|
||||
|
||||
VAL0 VAL1...\n
|
||||
|
||||
- Flat keyed files
|
||||
|
||||
KEY0 VAL0\n
|
||||
KEY1 VAL1\n
|
||||
...
|
||||
|
||||
- Nested keyed files
|
||||
|
||||
KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01...
|
||||
KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11...
|
||||
...
|
||||
|
||||
For a writeable file, the format for writing should generally match
|
||||
reading; however, controllers may allow omitting later fields or
|
||||
implement restricted shortcuts for most common use cases.
|
||||
|
||||
For both flat and nested keyed files, only the values for a single key
|
||||
can be written at a time. For nested keyed files, the sub key pairs
|
||||
may be specified in any order and not all pairs have to be specified.
|
||||
|
||||
|
||||
5-3-2. cpuset
|
||||
5-3-2. Control Knobs
|
||||
|
||||
- Settings for a single feature should generally be implemented in a
|
||||
single file.
|
||||
|
||||
- In general, the root cgroup should be exempt from resource control
|
||||
and thus shouldn't have resource control knobs.
|
||||
|
||||
- If a controller implements ratio based resource distribution, the
|
||||
control knob should be named "weight" and have the range [1, 10000]
|
||||
and 100 should be the default value. The values are chosen to allow
|
||||
enough and symmetric bias in both directions while keeping it
|
||||
intuitive (the default is 100%).
|
||||
|
||||
- If a controller implements an absolute resource guarantee and/or
|
||||
limit, the control knobs should be named "min" and "max"
|
||||
respectively. If a controller implements best effort resource
|
||||
gurantee and/or limit, the control knobs should be named "low" and
|
||||
"high" respectively.
|
||||
|
||||
In the above four control files, the special token "max" should be
|
||||
used to represent upward infinity for both reading and writing.
|
||||
|
||||
- If a setting has configurable default value and specific overrides,
|
||||
the default settings should be keyed with "default" and appear as
|
||||
the first entry in the file. Specific entries can use "default" as
|
||||
its value to indicate inheritance of the default value.
|
||||
|
||||
|
||||
5-4. Per-Controller Changes
|
||||
|
||||
5-4-1. io
|
||||
|
||||
- blkio is renamed to io. The interface is overhauled anyway. The
|
||||
new name is more in line with the other two major controllers, cpu
|
||||
and memory, and better suited given that it may be used for cgroup
|
||||
writeback without involving block layer.
|
||||
|
||||
- Everything including stat is always hierarchical making separate
|
||||
recursive stat files pointless and, as no internal node can have
|
||||
tasks, leaf weights are meaningless. The operation model is
|
||||
simplified and the interface is overhauled accordingly.
|
||||
|
||||
io.stat
|
||||
|
||||
The stat file. The reported stats are from the point where
|
||||
bio's are issued to request_queue. The stats are counted
|
||||
independent of which policies are enabled. Each line in the
|
||||
file follows the following format. More fields may later be
|
||||
added at the end.
|
||||
|
||||
$MAJ:$MIN rbytes=$RBYTES wbytes=$WBYTES rios=$RIOS wrios=$WIOS
|
||||
|
||||
io.weight
|
||||
|
||||
The weight setting, currently only available and effective if
|
||||
cfq-iosched is in use for the target device. The weight is
|
||||
between 1 and 10000 and defaults to 100. The first line
|
||||
always contains the default weight in the following format to
|
||||
use when per-device setting is missing.
|
||||
|
||||
default $WEIGHT
|
||||
|
||||
Subsequent lines list per-device weights of the following
|
||||
format.
|
||||
|
||||
$MAJ:$MIN $WEIGHT
|
||||
|
||||
Writing "$WEIGHT" or "default $WEIGHT" changes the default
|
||||
setting. Writing "$MAJ:$MIN $WEIGHT" sets per-device weight
|
||||
while "$MAJ:$MIN default" clears it.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
io.max
|
||||
|
||||
The maximum bandwidth and/or iops setting, only available if
|
||||
blk-throttle is enabled. The file is of the following format.
|
||||
|
||||
$MAJ:$MIN rbps=$RBPS wbps=$WBPS riops=$RIOPS wiops=$WIOPS
|
||||
|
||||
${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.
|
||||
|
||||
This file is available only on non-root cgroups.
|
||||
|
||||
|
||||
5-4-2. cpuset
|
||||
|
||||
- Tasks are kept in empty cpusets after hotplug and take on the masks
|
||||
of the nearest non-empty ancestor, instead of being moved to it.
|
||||
|
|
@ -388,7 +505,7 @@ supported and the interface files "release_agent" and
|
|||
masks of the nearest non-empty ancestor.
|
||||
|
||||
|
||||
5-3-3. memory
|
||||
5-4-3. memory
|
||||
|
||||
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||
not created.
|
||||
|
|
|
|||
|
|
@ -71,12 +71,8 @@ the operations defined in clk.h:
|
|||
long (*round_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long *parent_rate);
|
||||
long (*determine_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long min_rate,
|
||||
unsigned long max_rate,
|
||||
unsigned long *best_parent_rate,
|
||||
struct clk_hw **best_parent_clk);
|
||||
int (*determine_rate)(struct clk_hw *hw,
|
||||
struct clk_rate_request *req);
|
||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw,
|
||||
|
|
|
|||
|
|
@ -55,16 +55,13 @@ transition notifiers.
|
|||
----------------------------
|
||||
|
||||
These are notified when a new policy is intended to be set. Each
|
||||
CPUFreq policy notifier is called three times for a policy transition:
|
||||
CPUFreq policy notifier is called twice for a policy transition:
|
||||
|
||||
1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
|
||||
they see a need for this - may it be thermal considerations or
|
||||
hardware limitations.
|
||||
|
||||
2.) During CPUFREQ_INCOMPATIBLE only changes may be done in order to avoid
|
||||
hardware failure.
|
||||
|
||||
3.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
|
||||
2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
|
||||
- if two hardware drivers failed to agree on a new policy before this
|
||||
stage, the incompatible hardware shall be shut down, and the user
|
||||
informed of this.
|
||||
|
|
|
|||
|
|
@ -209,6 +209,37 @@ include:
|
|||
"repair" - Initiate a repair of the array.
|
||||
"reshape"- Currently unsupported (-EINVAL).
|
||||
|
||||
|
||||
Discard Support
|
||||
---------------
|
||||
The implementation of discard support among hardware vendors varies.
|
||||
When a block is discarded, some storage devices will return zeroes when
|
||||
the block is read. These devices set the 'discard_zeroes_data'
|
||||
attribute. Other devices will return random data. Confusingly, some
|
||||
devices that advertise 'discard_zeroes_data' will not reliably return
|
||||
zeroes when discarded blocks are read! Since RAID 4/5/6 uses blocks
|
||||
from a number of devices to calculate parity blocks and (for performance
|
||||
reasons) relies on 'discard_zeroes_data' being reliable, it is important
|
||||
that the devices be consistent. Blocks may be discarded in the middle
|
||||
of a RAID 4/5/6 stripe and if subsequent read results are not
|
||||
consistent, the parity blocks may be calculated differently at any time;
|
||||
making the parity blocks useless for redundancy. It is important to
|
||||
understand how your hardware behaves with discards if you are going to
|
||||
enable discards with RAID 4/5/6.
|
||||
|
||||
Since the behavior of storage devices is unreliable in this respect,
|
||||
even when reporting 'discard_zeroes_data', by default RAID 4/5/6
|
||||
discard support is disabled -- this ensures data integrity at the
|
||||
expense of losing some performance.
|
||||
|
||||
Storage devices that properly support 'discard_zeroes_data' are
|
||||
increasingly whitelisted in the kernel and can thus be trusted.
|
||||
|
||||
For trusted devices, the following dm-raid module parameter can be set
|
||||
to safely enable discard support for RAID 4/5/6:
|
||||
'devices_handle_discards_safely'
|
||||
|
||||
|
||||
Version History
|
||||
---------------
|
||||
1.0.0 Initial version. Support for RAID 4/5/6
|
||||
|
|
|
|||
|
|
@ -121,6 +121,10 @@ Messages
|
|||
|
||||
Output format:
|
||||
<region_id>: <start_sector>+<length> <step> <program_id> <aux_data>
|
||||
precise_timestamps histogram:n1,n2,n3,...
|
||||
|
||||
The strings "precise_timestamps" and "histogram" are printed only
|
||||
if they were specified when creating the region.
|
||||
|
||||
@stats_print <region_id> [<starting_line> <number_of_lines>]
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
* ARC HS Performance Counters
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,archs-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,archs-pct";
|
||||
};
|
||||
|
|
@ -27,6 +27,8 @@ compatible: must be one of:
|
|||
o "atmel,at91sam9xe"
|
||||
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
||||
SoC family:
|
||||
o "atmel,sama5d2" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d27"
|
||||
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d31"
|
||||
- "atmel,sama5d33"
|
||||
|
|
@ -50,6 +52,7 @@ System Timer (ST) required properties:
|
|||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
|
|
@ -61,7 +64,7 @@ TC/TCLIB Timer required properties:
|
|||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
- clock-names: tuple listing input clock names.
|
||||
Required elements: "t0_clk"
|
||||
Required elements: "t0_clk", "slow_clk"
|
||||
Optional elements: "t1_clk", "t2_clk"
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
|
|
@ -87,14 +90,16 @@ One interrupt per TC channel in a TC block:
|
|||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45"
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
|
|
@ -117,6 +122,7 @@ required properties:
|
|||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
|
|
@ -135,9 +141,10 @@ optional at91sam9x5 properties:
|
|||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
Broadcom North Star 2 (NS2) device tree bindings
|
||||
------------------------------------------------
|
||||
|
||||
Boards with NS2 shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
NS2 SVK board
|
||||
compatible = "brcm,ns2-svk", "brcm,ns2";
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Raspberry Pi VideoCore firmware driver
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "raspberrypi,bcm2835-firmware"
|
||||
- mboxes: Phandle to the firmware device's Mailbox.
|
||||
(See: ../mailbox/mailbox.txt for more information)
|
||||
|
||||
Example:
|
||||
|
||||
firmware {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
};
|
||||
|
|
@ -17,6 +17,7 @@ its hardware characteristcs.
|
|||
- "arm,coresight-tmc", "arm,primecell";
|
||||
- "arm,coresight-funnel", "arm,primecell";
|
||||
- "arm,coresight-etm3x", "arm,primecell";
|
||||
- "arm,coresight-etm4x", "arm,primecell";
|
||||
- "qcom,coresight-replicator1x", "arm,primecell";
|
||||
|
||||
* reg: physical base address and length of the register
|
||||
|
|
|
|||
|
|
@ -199,6 +199,7 @@ nodes to be present and contain the properties described below.
|
|||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
"rockchip,rk3066-smp"
|
||||
"ste,dbx500-smp"
|
||||
|
||||
- cpu-release-addr
|
||||
Usage: required for systems that have an "enable-method"
|
||||
|
|
|
|||
|
|
@ -127,6 +127,24 @@ Example:
|
|||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
|
||||
Hisilicon Hi6220 SRAM controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,hi6220-sramctrl", "syscon"
|
||||
- reg : Register address and size
|
||||
|
||||
Hisilicon's SoCs use sram for multiple purpose; on Hi6220 there have several
|
||||
SRAM banks for power management, modem, security, etc. Further, use "syscon"
|
||||
managing the common sram which can be shared by multiple modules.
|
||||
|
||||
Example:
|
||||
/*for Hi6220*/
|
||||
sram: sram@fff80000 {
|
||||
compatible = "hisilicon,hi6220-sramctrl", "syscon";
|
||||
reg = <0x0 0xfff80000 0x0 0x12000>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon HiP01 system controller
|
||||
|
||||
|
|
|
|||
|
|
@ -67,6 +67,12 @@ Optional properties:
|
|||
disable if zero.
|
||||
- arm,prefetch-offset : Override prefetch offset value. Valid values are
|
||||
0-7, 15, 23, and 31.
|
||||
- arm,shared-override : The default behavior of the pl310 cache controller with
|
||||
respect to the shareable attribute is to transform "normal memory
|
||||
non-cacheable transactions" into "cacheable no allocate" (for reads) or
|
||||
"write through no write allocate" (for writes).
|
||||
On systems where this may cause DMA buffer corruption, this property must be
|
||||
specified to indicate that such transforms are precluded.
|
||||
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
|
||||
(forcibly enable), property absent (retain settings set by firmware)
|
||||
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ And in addition, the compatible shall be extended with the specific
|
|||
board. Currently known boards are:
|
||||
|
||||
"buffalo,lschlv2"
|
||||
"buffalo,lswvl"
|
||||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"dlink,dns-320"
|
||||
|
|
|
|||
|
|
@ -1,12 +1,15 @@
|
|||
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
|
||||
MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings
|
||||
|
||||
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
|
||||
Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: Must contain one of
|
||||
"mediatek,mt6580"
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
"mediatek,mt8173"
|
||||
|
|
@ -14,12 +17,18 @@ compatible: Must contain one of
|
|||
|
||||
Supported boards:
|
||||
|
||||
- Evaluation board for MT6580:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
|
||||
- bq Aquaris5 smart phone:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
|
||||
- Evaluation board for MT6592:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
|
||||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Mediatek 65xx/81xx sysirq
|
||||
+Mediatek 65xx/67xx/81xx sysirq
|
||||
|
||||
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
|
||||
interrupt.
|
||||
|
|
@ -8,9 +8,11 @@ Required properties:
|
|||
"mediatek,mt8173-sysirq"
|
||||
"mediatek,mt8135-sysirq"
|
||||
"mediatek,mt8127-sysirq"
|
||||
"mediatek,mt6795-sysirq"
|
||||
"mediatek,mt6592-sysirq"
|
||||
"mediatek,mt6589-sysirq"
|
||||
"mediatek,mt6582-sysirq"
|
||||
"mediatek,mt6580-sysirq"
|
||||
"mediatek,mt6577-sysirq"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Use the same format as specified by GIC in
|
||||
|
|
|
|||
|
|
@ -135,6 +135,9 @@ Boards:
|
|||
- AM335X OrionLXm : Substation Automation Platform
|
||||
compatible = "novatech,am335x-lxm", "ti,am33xx"
|
||||
|
||||
- AM335X phyBOARD-WEGA: Single Board Computer dev kit
|
||||
compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
||||
|
|
|
|||
|
|
@ -26,13 +26,19 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
|
||||
- interrupt-affinity : Valid only when using SPIs, specifies a list of phandles
|
||||
to CPU nodes corresponding directly to the affinity of
|
||||
- interrupt-affinity : When using SPIs, specifies a list of phandles to CPU
|
||||
nodes corresponding directly to the affinity of
|
||||
the SPIs listed in the interrupts property.
|
||||
|
||||
This property should be present when there is more than
|
||||
When using a PPI, specifies a list of phandles to CPU
|
||||
nodes corresponding to the set of CPUs which have
|
||||
a PMU of this type signalling the PPI listed in the
|
||||
interrupts property.
|
||||
|
||||
This property should be present when there is more than
|
||||
a single SPI.
|
||||
|
||||
|
||||
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
|
||||
events.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,3 +26,38 @@ Rockchip platforms device tree bindings
|
|||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
||||
- Netxeon R89 board:
|
||||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- Google Jerry (Hisense Chromebook C11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
|
||||
"google,veyron-jerry-rev5", "google,veyron-jerry-rev4",
|
||||
"google,veyron-jerry-rev3", "google,veyron-jerry",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Minnie (Asus Chromebook Flip C100P):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
|
||||
"google,veyron-minnie-rev2", "google,veyron-minnie-rev1",
|
||||
"google,veyron-minnie-rev0", "google,veyron-minnie",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Pinky (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Speedy (Asus C201 Chromebook):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
|
||||
"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
|
||||
"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
|
||||
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
|
||||
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Rockchip R88 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,r88", "rockchip,rk3368";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
SP810 System Controller
|
||||
-----------------------
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: standard compatible string for a Primecell peripheral,
|
||||
see Documentation/devicetree/bindings/arm/primecell.txt
|
||||
for more details
|
||||
should be: "arm,sp810", "arm,primecell"
|
||||
|
||||
- reg: standard registers property, physical address and size
|
||||
of the control registers
|
||||
|
||||
- clock-names: from the common clock bindings, for more details see
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt;
|
||||
should be: "refclk", "timclk", "apb_pclk"
|
||||
|
||||
- clocks: from the common clock bindings, phandle and clock
|
||||
specifier pairs for the entries of clock-names property
|
||||
|
||||
- #clock-cells: from the common clock bindings;
|
||||
should be: <1>
|
||||
|
||||
- clock-output-names: from the common clock bindings;
|
||||
should be: "timerclken0", "timerclken1", "timerclken2", "timerclken3"
|
||||
|
||||
- assigned-clocks: from the common clock binding;
|
||||
should be: clock specifier for each output clock of this
|
||||
provider node
|
||||
|
||||
- assigned-clock-parents: from the common clock binding;
|
||||
should be: phandle of input clock listed in clocks
|
||||
property with the highest frequency
|
||||
|
||||
Example:
|
||||
v2m_sysctl: sysctl@020000 {
|
||||
compatible = "arm,sp810", "arm,primecell";
|
||||
reg = <0x020000 0x1000>;
|
||||
clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
|
||||
clock-names = "refclk", "timclk", "apb_pclk";
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3";
|
||||
assigned-clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>, <&v2m_sysctl 3>, <&v2m_sysctl 3>;
|
||||
assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
|
||||
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Binding for simple gpio clock multiplexer.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "gpio-mux-clock".
|
||||
- clocks: list of two references to parent clocks.
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- select-gpios : GPIO reference for selecting the parent clock.
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "gpio-mux-clock";
|
||||
clocks = <&parentclk1>, <&parentclk2>;
|
||||
#clock-cells = <0>;
|
||||
select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
|
@ -15,19 +15,36 @@ Required Properties:
|
|||
- "hisilicon,hi6220-sysctrl"
|
||||
- "hisilicon,hi6220-mediactrl"
|
||||
- "hisilicon,hi6220-pmctrl"
|
||||
- "hisilicon,hi6220-stub-clk"
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
For example:
|
||||
Optional Properties:
|
||||
|
||||
- hisilicon,hi6220-clk-sram: phandle to the syscon managing the SoC internal sram;
|
||||
the driver need use the sram to pass parameters for frequency change.
|
||||
|
||||
- mboxes: use the label reference for the mailbox as the first parameter, the
|
||||
second parameter is the channel number.
|
||||
|
||||
Example 1:
|
||||
sys_ctrl: sys_ctrl@f7030000 {
|
||||
compatible = "hisilicon,hi6220-sysctrl", "syscon";
|
||||
reg = <0x0 0xf7030000 0x0 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2:
|
||||
stub_clock: stub_clock {
|
||||
compatible = "hisilicon,hi6220-stub-clk";
|
||||
hisilicon,hi6220-clk-sram = <&sram>;
|
||||
#clock-cells = <1>;
|
||||
mboxes = <&mailbox 1>;
|
||||
};
|
||||
|
||||
Each clock is assigned an identifier and client nodes use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
* Clock bindings for Freescale i.MX6 UltraLite
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx6ul-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- clocks: list of clock specifiers, must contain an entry for each required
|
||||
entry in clock-names
|
||||
- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6ul-clock.h
|
||||
for the full list of i.MX6 UltraLite clock IDs.
|
||||
|
|
@ -0,0 +1,83 @@
|
|||
Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
|
||||
|
||||
Required properties:
|
||||
- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names.
|
||||
- clock-names: Should contain the following:
|
||||
"cpu" - The multiplexer for clock input of CPU cluster.
|
||||
"intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
|
||||
source (usually MAINPLL) when the original CPU PLL is under
|
||||
transition and not stable yet.
|
||||
Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
|
||||
generic clock consumer properties.
|
||||
- proc-supply: Regulator for Vproc of CPU cluster.
|
||||
|
||||
Optional properties:
|
||||
- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver
|
||||
needs to do "voltage tracking" to step by step scale up/down Vproc and
|
||||
Vsram to fit SoC specific needs. When absent, the voltage scaling
|
||||
flow is handled by hardware, hence no software "voltage tracking" is
|
||||
needed.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x000>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA53SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x001>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA53SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu2: cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x100>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA57SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu3: cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x101>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA57SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
&cpu0 {
|
||||
proc-supply = <&mt6397_vpca15_reg>;
|
||||
};
|
||||
|
||||
&cpu1 {
|
||||
proc-supply = <&mt6397_vpca15_reg>;
|
||||
};
|
||||
|
||||
&cpu2 {
|
||||
proc-supply = <&da9211_vcpu_reg>;
|
||||
sram-supply = <&mt6397_vsramca7_reg>;
|
||||
};
|
||||
|
||||
&cpu3 {
|
||||
proc-supply = <&da9211_vcpu_reg>;
|
||||
sram-supply = <&mt6397_vsramca7_reg>;
|
||||
};
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
NVIDIA Tegra124 DFLL FCPU clocksource
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
The DFLL IP block on Tegra is a root clocksource designed for clocking
|
||||
the fast CPU cluster. It consists of a free-running voltage controlled
|
||||
oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
|
||||
control module that will automatically adjust the VDD_CPU voltage by
|
||||
communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
|
||||
Currently only the I2C mode is supported by these bindings.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "nvidia,tegra124-dfll"
|
||||
- reg : Defines the following set of registers, in the order listed:
|
||||
- registers for the DFLL control logic.
|
||||
- registers for the I2C output logic.
|
||||
- registers for the integrated I2C master controller.
|
||||
- look-up table RAM for voltage register values.
|
||||
- interrupts: Should contain the DFLL block interrupt.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- soc: Clock source for the DFLL control logic.
|
||||
- ref: The closed loop reference clock
|
||||
- i2c: Clock source for the integrated I2C master.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- dvco: Reset control for the DFLL DVCO.
|
||||
- #clock-cells: Must be 0.
|
||||
- clock-output-names: Name of the clock output.
|
||||
- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
|
||||
hardware will start controlling. The regulator will be queried for
|
||||
the I2C register, control values and supported voltages.
|
||||
|
||||
Required properties for the control loop parameters:
|
||||
- nvidia,sample-rate: Sample rate of the DFLL control loop.
|
||||
- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
|
||||
- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
|
||||
- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
|
||||
- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
|
||||
- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
|
||||
|
||||
Optional properties for the control loop parameters:
|
||||
- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM.
|
||||
|
||||
Required properties for I2C mode:
|
||||
- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
|
||||
|
||||
Example:
|
||||
|
||||
clock@0,70110000 {
|
||||
compatible = "nvidia,tegra124-dfll";
|
||||
reg = <0 0x70110000 0 0x100>, /* DFLL control */
|
||||
<0 0x70110000 0 0x100>, /* I2C output control */
|
||||
<0 0x70110100 0 0x100>, /* Integrated I2C controller */
|
||||
<0 0x70110200 0 0x100>; /* Look-up table RAM */
|
||||
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
|
||||
<&tegra_car TEGRA124_CLK_DFLL_REF>,
|
||||
<&tegra_car TEGRA124_CLK_I2C5>;
|
||||
clock-names = "soc", "ref", "i2c";
|
||||
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
|
||||
reset-names = "dvco";
|
||||
#clock-cells = <0>;
|
||||
clock-output-names = "dfllCPU_out";
|
||||
vdd-cpu-supply = <&vdd_cpu>;
|
||||
status = "okay";
|
||||
|
||||
nvidia,sample-rate = <12500>;
|
||||
nvidia,droop-ctrl = <0x00000f00>;
|
||||
nvidia,force-mode = <1>;
|
||||
nvidia,cf = <10>;
|
||||
nvidia,ci = <0>;
|
||||
nvidia,cg = <2>;
|
||||
|
||||
nvidia,i2c-fs-rate = <400000>;
|
||||
};
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7778 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7778. It includes two PLLs and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -10,10 +12,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are
|
||||
"plla", "pllb", "b", "out", "p", "s", and "s1".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7778-cpg-clocks";
|
||||
|
|
@ -22,4 +32,17 @@ Example
|
|||
clocks = <&extal_clk>;
|
||||
clock-output-names = "plla", "pllb", "b",
|
||||
"out", "p", "s", "s1";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sdhi0: sd@ffe4c000 {
|
||||
compatible = "renesas,sdhi-r8a7778";
|
||||
reg = <0xffe4c000 0x100>;
|
||||
interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7779 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7779. It includes one PLL and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -12,16 +14,36 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "plla",
|
||||
"z", "zs", "s", "s1", "p", "b", "out".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7779-cpg-clocks";
|
||||
reg = <0 0xffc80000 0 0x30>;
|
||||
reg = <0xffc80000 0x30>;
|
||||
clocks = <&extal_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "plla", "z", "zs", "s", "s1", "p",
|
||||
"b", "out";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sata: sata@fc600000 {
|
||||
compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
|
||||
reg = <0xfc600000 0x2000>;
|
||||
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7779_CLK_SATA>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
|
||||
and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -20,10 +22,18 @@ Required Properties:
|
|||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
||||
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
|
||||
"adsp"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@e6150000 {
|
||||
compatible = "renesas,r8a7790-cpg-clocks",
|
||||
|
|
@ -34,4 +44,16 @@ Example
|
|||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
||||
"lb", "qspi", "sdh", "sd0", "sd1", "z",
|
||||
"rcan", "adsp";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
thermal@e61f0000 {
|
||||
compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
|
||||
reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
|
||||
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
|
||||
CPU and GPU clocks, and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -14,10 +16,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "pll",
|
||||
"i", and "g"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@fcfe0000 {
|
||||
#clock-cells = <1>;
|
||||
|
|
@ -26,4 +36,19 @@ Example
|
|||
reg = <0xfcfe0000 0x18>;
|
||||
clocks = <&extal_clk>, <&usb_x1_clk>;
|
||||
clock-output-names = "pll", "i", "g";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
mtu2: timer@fcff0000 {
|
||||
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
|
||||
reg = <0xfcff0000 0x400>;
|
||||
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tgi0a";
|
||||
clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
* Rockchip RK3368 Clock and Reset Unit
|
||||
|
||||
The RK3368 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "rockchip,rk3368-cru"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||
If missing, pll rates are not changeable, due to the missing pll lock status.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All available clocks are defined as
|
||||
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
|
||||
External clocks:
|
||||
|
||||
There are several clocks that are generated outside the SoC. It is expected
|
||||
that they are defined using standard clock bindings with following
|
||||
clock-output-names:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "ext_i2s" - external I2S clock - optional,
|
||||
- "ext_gmac" - external GMAC clock - optional
|
||||
- "ext_hsadc" - external HSADC clock - optional,
|
||||
- "ext_isp" - external ISP clock - optional,
|
||||
- "ext_jtag" - external JTAG clock - optional
|
||||
- "ext_vip" - external VIP clock - optional,
|
||||
- "usbotg_out" - output clock of the pll in the otg phy
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
cru: clock-controller@ff760000 {
|
||||
compatible = "rockchip,rk3368-cru";
|
||||
reg = <0x0 0xff760000 0x0 0x1000>;
|
||||
rockchip,grf = <&grf>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock generated by the clock
|
||||
controller:
|
||||
|
||||
uart0: serial@10124000 {
|
||||
compatible = "snps,dw-apb-uart";
|
||||
reg = <0x10124000 0x400>;
|
||||
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <1>;
|
||||
clocks = <&cru SCLK_UART0>;
|
||||
};
|
||||
|
|
@ -21,8 +21,8 @@ Required properties:
|
|||
"st,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_0", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_1", "st,clkgen-plls-c32"
|
||||
|
||||
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
Clock bindings for ST-Ericsson Ux500 clocks
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain only one of the following:
|
||||
"stericsson,u8500-clks"
|
||||
"stericsson,u8540-clks"
|
||||
"stericsson,u9540-clks"
|
||||
- reg : shall contain base register location and length for
|
||||
CLKRST1, 2, 3, 5, and 6 in an array. Note the absence of
|
||||
CLKRST4, which does not exist.
|
||||
|
||||
Required subnodes:
|
||||
- prcmu-clock: a subnode with one clock cell for PRCMU (power,
|
||||
reset, control unit) clocks. The cell indicates which PRCMU
|
||||
clock in the prcmu-clock node the consumer wants to use.
|
||||
- prcc-periph-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) peripheral clocks.
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- prcc-kernel-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) kernel clocks
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- rtc32k-clock: a subnode with zero clock cells for the 32kHz
|
||||
RTC clock.
|
||||
- smp-twd-clock: a subnode for the ARM SMP Timer Watchdog cluster
|
||||
with zero clock cells.
|
||||
|
||||
Example:
|
||||
|
||||
clocks {
|
||||
compatible = "stericsson,u8500-clks";
|
||||
/*
|
||||
* Registers for the CLKRST block on peripheral
|
||||
* groups 1, 2, 3, 5, 6,
|
||||
*/
|
||||
reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>,
|
||||
<0x8000f000 0x1000>, <0xa03ff000 0x1000>,
|
||||
<0xa03cf000 0x1000>;
|
||||
|
||||
prcmu_clk: prcmu-clock {
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
prcc_pclk: prcc-periph-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
prcc_kclk: prcc-kernel-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
rtc_clk: rtc32k-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
smp_twd_clk: smp-twd-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Tegra124 CPU frequency scaling driver bindings
|
||||
----------------------------------------------
|
||||
|
||||
Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- cpu_g: Clock mux for the fast CPU cluster.
|
||||
- cpu_lp: Clock mux for the low-power CPU cluster.
|
||||
- pll_x: Fast PLL clocksource.
|
||||
- pll_p: Auxiliary PLL used during fast PLL rate changes.
|
||||
- dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
|
||||
- vdd-cpu-supply: Regulator for CPU voltage
|
||||
|
||||
Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0>;
|
||||
|
||||
clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
|
||||
<&tegra_car TEGRA124_CLK_CCLK_LP>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_X>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_P>,
|
||||
<&dfll>;
|
||||
clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
|
||||
clock-latency = <300000>;
|
||||
vdd-cpu-supply: <&vdd_cpu>;
|
||||
};
|
||||
|
||||
<...>
|
||||
};
|
||||
|
|
@ -106,6 +106,18 @@ PROPERTIES
|
|||
to the interrupt parent to which the child domain
|
||||
is being mapped.
|
||||
|
||||
- clocks
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: A list of phandle and clock specifier pairs describing
|
||||
the clocks required for enabling and disabling SEC 4.0.
|
||||
|
||||
- clock-names
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <string>
|
||||
Definition: A list of clock name strings in the same order as the
|
||||
clocks property.
|
||||
|
||||
Note: All other standard properties (see the ePAPR) are allowed
|
||||
but are optional.
|
||||
|
||||
|
|
@ -120,6 +132,11 @@ EXAMPLE
|
|||
ranges = <0 0x300000 0x10000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <92 2>;
|
||||
clocks = <&clks IMX6QDL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6QDL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6QDL_CLK_CAAM_IPG>,
|
||||
<&clks IMX6QDL_CLK_EIM_SLOW>;
|
||||
clock-names = "mem", "aclk", "ipg", "emi_slow";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -288,12 +305,13 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
Node defines address range and the associated
|
||||
interrupt for the SNVS function. This function
|
||||
monitors security state information & reports
|
||||
security violations.
|
||||
security violations. This also included rtc,
|
||||
system power off and ON/OFF key.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon".
|
||||
Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
|
@ -324,7 +342,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Usage: optional
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
|
|
@ -341,7 +359,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
|
||||
EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
|
|
@ -358,16 +376,72 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
|||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- regmap
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
- offset
|
||||
Usage: option
|
||||
value type: <u32>
|
||||
Definition: LP register offset. default it is 0x34.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
sec_mon_rtc_lp@1 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
interrupts = <93 2>;
|
||||
regmap = <&snvs>;
|
||||
offset = <0x34>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
System ON/OFF key driver
|
||||
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Mush include "fsl,sec-v4.0-pwrkey".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: The SNVS ON/OFF interrupt number to the CPU(s).
|
||||
|
||||
- linux,keycode:
|
||||
Usage: option
|
||||
Value type: <int>
|
||||
Definition: Keycode to emit, KEY_POWER by default.
|
||||
|
||||
- wakeup-source:
|
||||
Usage: option
|
||||
Value type: <boo>
|
||||
Definition: Button can wake-up the system.
|
||||
|
||||
- regmap:
|
||||
Usage: required:
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
EXAMPLE:
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&snvs>;
|
||||
interrupts = <0 4 0x4>
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -443,12 +517,20 @@ FULL EXAMPLE
|
|||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
interrupts = <0 4 0x4>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Allwinner Security System found on A20 SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "allwinner,sun4i-a10-crypto".
|
||||
- reg: Should contain the Security System register location and length.
|
||||
- interrupts: Should contain the IRQ line for the Security System.
|
||||
- clocks : List of clock specifiers, corresponding to ahb and ss.
|
||||
- clock-names : Name of the functional clock, should be
|
||||
* "ahb" : AHB gating clock
|
||||
* "mod" : SS controller clock
|
||||
|
||||
Optional properties:
|
||||
- resets : phandle + reset specifier pair
|
||||
- reset-names : must contain "ahb"
|
||||
|
||||
Example:
|
||||
crypto: crypto-engine@01c15000 {
|
||||
compatible = "allwinner,sun4i-a10-crypto";
|
||||
reg = <0x01c15000 0x1000>;
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ahb_gates 5>, <&ss_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
};
|
||||
|
|
@ -11,15 +11,14 @@ to various devfreq devices. The devfreq devices would use the event data when
|
|||
derterming the current state of each IP.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "samsung,exynos-ppmu".
|
||||
- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2.
|
||||
- reg: physical base address of each PPMU and length of memory mapped region.
|
||||
|
||||
Optional properties:
|
||||
- clock-names : the name of clock used by the PPMU, "ppmu"
|
||||
- clocks : phandles for clock specified in "clock-names" property
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Example1 : PPMU nodes in exynos3250.dtsi are listed below.
|
||||
Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
|
||||
|
||||
ppmu_dmc0: ppmu_dmc0@106a0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
|
|
@ -108,3 +107,41 @@ Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
|
||||
|
||||
ppmu_d0_cpu: ppmu_d0_cpu@10480000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x10480000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d0_general: ppmu_d0_general@10490000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x10490000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d0_rt: ppmu_d0_rt@104a0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104a0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_cpu: ppmu_d1_cpu@104b0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104b0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_general: ppmu_d1_general@104c0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104c0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_rt: ppmu_d1_rt@104d0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104d0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
Analog Device AXI-DMAC DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Must be "adi,axi-dmac-1.00.a".
|
||||
- reg: Specification for the controllers memory mapped register map.
|
||||
- interrupts: Specification for the controllers interrupt.
|
||||
- clocks: Phandle and specifier to the controllers AXI interface clock
|
||||
- #dma-cells: Must be 1.
|
||||
|
||||
Required sub-nodes:
|
||||
- adi,channels: This sub-node must contain a sub-node for each DMA channel. For
|
||||
the channel sub-nodes the following bindings apply. They must match the
|
||||
configuration options of the peripheral as it was instantiated.
|
||||
|
||||
Required properties for adi,channels sub-node:
|
||||
- #size-cells: Must be 0
|
||||
- #address-cells: Must be 1
|
||||
|
||||
Required channel sub-node properties:
|
||||
- reg: Which channel this node refers to.
|
||||
- adi,length-width: Width of the DMA transfer length register.
|
||||
- adi,source-bus-width,
|
||||
adi,destination-bus-width: Width of the source or destination bus in bits.
|
||||
- adi,source-bus-type,
|
||||
adi,destination-bus-type: Type of the source or destination bus. Must be one
|
||||
of the following:
|
||||
0 (AXI_DMAC_TYPE_AXI_MM): Memory mapped AXI interface
|
||||
1 (AXI_DMAC_TYPE_AXI_STREAM): Streaming AXI interface
|
||||
2 (AXI_DMAC_TYPE_AXI_FIFO): FIFO interface
|
||||
|
||||
Optional channel properties:
|
||||
- adi,cyclic: Must be set if the channel supports hardware cyclic DMA
|
||||
transfers.
|
||||
- adi,2d: Must be set if the channel supports hardware 2D DMA transfers.
|
||||
|
||||
DMA clients connected to the AXI-DMAC DMA controller must use the format
|
||||
described in the dma.txt file using a one-cell specifier. The value of the
|
||||
specifier refers to the DMA channel index.
|
||||
|
||||
Example:
|
||||
|
||||
dma: dma@7c420000 {
|
||||
compatible = "adi,axi-dmac-1.00.a";
|
||||
reg = <0x7c420000 0x10000>;
|
||||
interrupts = <0 57 0>;
|
||||
clocks = <&clkc 16>;
|
||||
#dma-cells = <1>;
|
||||
|
||||
adi,channels {
|
||||
#size-cells = <0>;
|
||||
#address-cells = <1>;
|
||||
|
||||
dma-channel@0 {
|
||||
reg = <0>;
|
||||
adi,source-bus-width = <32>;
|
||||
adi,source-bus-type = <ADI_AXI_DMAC_TYPE_MM_AXI>;
|
||||
adi,destination-bus-width = <64>;
|
||||
adi,destination-bus-type = <ADI_AXI_DMAC_TYPE_FIFO>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
* ARM PrimeCells PL080 and PL081 and derivatives DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: "arm,pl080", "arm,primecell";
|
||||
"arm,pl081", "arm,primecell";
|
||||
- reg: Address range of the PL08x registers
|
||||
- interrupt: The PL08x interrupt number
|
||||
- clocks: The clock running the IP core clock
|
||||
- clock-names: Must contain "apb_pclk"
|
||||
- lli-bus-interface-ahb1: if AHB master 1 is eligible for fetching LLIs
|
||||
- lli-bus-interface-ahb2: if AHB master 2 is eligible for fetching LLIs
|
||||
- mem-bus-interface-ahb1: if AHB master 1 is eligible for fetching memory contents
|
||||
- mem-bus-interface-ahb2: if AHB master 2 is eligible for fetching memory contents
|
||||
- #dma-cells: must be <2>. First cell should contain the DMA request,
|
||||
second cell should contain either 1 or 2 depending on
|
||||
which AHB master that is used.
|
||||
|
||||
Optional properties:
|
||||
- dma-channels: contains the total number of DMA channels supported by the DMAC
|
||||
- dma-requests: contains the total number of DMA requests supported by the DMAC
|
||||
- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32
|
||||
64, 128 or 256 bytes are legal values
|
||||
- memcpy-bus-width: the bus width used for memcpy: 8, 16 or 32 are legal
|
||||
values
|
||||
|
||||
Clients
|
||||
Required properties:
|
||||
- dmas: List of DMA controller phandle, request channel and AHB master id
|
||||
- dma-names: Names of the aforementioned requested channels
|
||||
|
||||
Example:
|
||||
|
||||
dmac0: dma-controller@10130000 {
|
||||
compatible = "arm,pl080", "arm,primecell";
|
||||
reg = <0x10130000 0x1000>;
|
||||
interrupt-parent = <&vica>;
|
||||
interrupts = <15>;
|
||||
clocks = <&hclkdma0>;
|
||||
clock-names = "apb_pclk";
|
||||
lli-bus-interface-ahb1;
|
||||
lli-bus-interface-ahb2;
|
||||
mem-bus-interface-ahb2;
|
||||
memcpy-burst-size = <256>;
|
||||
memcpy-bus-width = <32>;
|
||||
#dma-cells = <2>;
|
||||
};
|
||||
|
||||
device@40008000 {
|
||||
...
|
||||
dmas = <&dmac0 0 2
|
||||
&dmac0 1 2>;
|
||||
dma-names = "tx", "rx";
|
||||
...
|
||||
};
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
NXP LPC18xx/43xx DMA MUX (DMA request router)
|
||||
|
||||
Required properties:
|
||||
- compatible: "nxp,lpc1850-dmamux"
|
||||
- reg: Memory map for accessing module
|
||||
- #dma-cells: Should be set to <3>.
|
||||
* 1st cell contain the master dma request signal
|
||||
* 2nd cell contain the mux value (0-3) for the peripheral
|
||||
* 3rd cell contain either 1 or 2 depending on the AHB
|
||||
master used.
|
||||
- dma-requests: Number of DMA requests for the mux
|
||||
- dma-masters: phandle pointing to the DMA controller
|
||||
|
||||
The DMA controller node need to have the following poroperties:
|
||||
- dma-requests: Number of DMA requests the controller can handle
|
||||
|
||||
Example:
|
||||
|
||||
dmac: dma@40002000 {
|
||||
compatible = "nxp,lpc1850-gpdma", "arm,pl080", "arm,primecell";
|
||||
arm,primecell-periphid = <0x00041080>;
|
||||
reg = <0x40002000 0x1000>;
|
||||
interrupts = <2>;
|
||||
clocks = <&ccu1 CLK_CPU_DMA>;
|
||||
clock-names = "apb_pclk";
|
||||
#dma-cells = <2>;
|
||||
dma-channels = <8>;
|
||||
dma-requests = <16>;
|
||||
lli-bus-interface-ahb1;
|
||||
lli-bus-interface-ahb2;
|
||||
mem-bus-interface-ahb1;
|
||||
mem-bus-interface-ahb2;
|
||||
memcpy-burst-size = <256>;
|
||||
memcpy-bus-width = <32>;
|
||||
};
|
||||
|
||||
dmamux: dma-mux {
|
||||
compatible = "nxp,lpc1850-dmamux";
|
||||
#dma-cells = <3>;
|
||||
dma-requests = <64>;
|
||||
dma-masters = <&dmac>;
|
||||
};
|
||||
|
||||
uart0: serial@40081000 {
|
||||
compatible = "nxp,lpc1850-uart", "ns16550a";
|
||||
reg = <0x40081000 0x1000>;
|
||||
reg-shift = <2>;
|
||||
interrupts = <24>;
|
||||
clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
|
||||
clock-names = "uartclk", "reg";
|
||||
dmas = <&dmamux 1 1 2
|
||||
&dmamux 2 1 2>;
|
||||
dma-names = "tx", "rx";
|
||||
};
|
||||
|
|
@ -12,10 +12,13 @@ XOR engine has. Those sub-nodes have the following required
|
|||
properties:
|
||||
- interrupts: interrupt of the XOR channel
|
||||
|
||||
And the following optional properties:
|
||||
The sub-nodes used to contain one or several of the following
|
||||
properties, but they are now deprecated:
|
||||
- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
|
||||
- dmacap,memset to indicate that the XOR channel is capable of memset operations
|
||||
- dmacap,xor to indicate that the XOR channel is capable of xor operations
|
||||
- dmacap,interrupt to indicate that the XOR channel is capable of
|
||||
generating interrupts
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -28,13 +31,8 @@ xor@d0060900 {
|
|||
|
||||
xor00 {
|
||||
interrupts = <51>;
|
||||
dmacap,memcpy;
|
||||
dmacap,xor;
|
||||
};
|
||||
xor01 {
|
||||
interrupts = <52>;
|
||||
dmacap,memcpy;
|
||||
dmacap,xor;
|
||||
dmacap,memset;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
Allwinner A10 DMA Controller
|
||||
|
||||
This driver follows the generic DMA bindings defined in dma.txt.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Must be "allwinner,sun4i-a10-dma"
|
||||
- reg: Should contain the registers base address and length
|
||||
- interrupts: Should contain a reference to the interrupt used by this device
|
||||
- clocks: Should contain a reference to the parent AHB clock
|
||||
- #dma-cells : Should be 2, first cell denoting normal or dedicated dma,
|
||||
second cell holding the request line number.
|
||||
|
||||
Example:
|
||||
dma: dma-controller@01c02000 {
|
||||
compatible = "allwinner,sun4i-a10-dma";
|
||||
reg = <0x01c02000 0x1000>;
|
||||
interrupts = <27>;
|
||||
clocks = <&ahb_gates 6>;
|
||||
#dma-cells = <2>;
|
||||
};
|
||||
|
||||
Clients:
|
||||
|
||||
DMA clients connected to the Allwinner A10 DMA controller must use the
|
||||
format described in the dma.txt file, using a three-cell specifier for
|
||||
each channel: a phandle plus two integer cells.
|
||||
The three cells in order are:
|
||||
|
||||
1. A phandle pointing to the DMA controller.
|
||||
2. Whether it is using normal (0) or dedicated (1) channels
|
||||
3. The port ID as specified in the datasheet
|
||||
|
||||
Example:
|
||||
spi2: spi@01c17000 {
|
||||
compatible = "allwinner,sun4i-a10-spi";
|
||||
reg = <0x01c17000 0x1000>;
|
||||
interrupts = <0 12 4>;
|
||||
clocks = <&ahb_gates 22>, <&spi2_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
dmas = <&dma 1 29>, <&dma 1 28>;
|
||||
dma-names = "rx", "tx";
|
||||
status = "disabled";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
};
|
||||
|
|
@ -0,0 +1,38 @@
|
|||
* ZTE ZX296702 DMA controller
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "zte,zx296702-dma"
|
||||
- reg: Should contain DMA registers location and length.
|
||||
- interrupts: Should contain one interrupt shared by all channel
|
||||
- #dma-cells: see dma.txt, should be 1, para number
|
||||
- dma-channels: physical channels supported
|
||||
- dma-requests: virtual channels supported, each virtual channel
|
||||
have specific request line
|
||||
- clocks: clock required
|
||||
|
||||
Example:
|
||||
|
||||
Controller:
|
||||
dma: dma-controller@0x09c00000{
|
||||
compatible = "zte,zx296702-dma";
|
||||
reg = <0x09c00000 0x1000>;
|
||||
clocks = <&topclk ZX296702_DMA_ACLK>;
|
||||
interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <24>;
|
||||
dma-requests = <24>;
|
||||
};
|
||||
|
||||
Client:
|
||||
Use specific request line passing from dmax
|
||||
For example, spdif0 tx channel request line is 4
|
||||
spdif0: spdif0@0b004000 {
|
||||
#sound-dai-cells = <0>;
|
||||
compatible = "zte,zx296702-spdif";
|
||||
reg = <0x0b004000 0x1000>;
|
||||
clocks = <&lsp0clk ZX296702_SPDIF0_DIV>;
|
||||
clock-names = "tx";
|
||||
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
|
||||
dmas = <&dma 4>;
|
||||
dma-names = "tx";
|
||||
}
|
||||
|
|
@ -30,20 +30,27 @@ Optional properties:
|
|||
- panel@0: Node of panel connected to this DSI controller.
|
||||
See files in Documentation/devicetree/bindings/panel/ for each supported
|
||||
panel.
|
||||
- qcom,dual-panel-mode: Boolean value indicating if the DSI controller is
|
||||
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
|
||||
driving a panel which needs 2 DSI links.
|
||||
- qcom,master-panel: Boolean value indicating if the DSI controller is driving
|
||||
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
|
||||
the master link of the 2-DSI panel.
|
||||
- qcom,sync-dual-panel: Boolean value indicating if the DSI controller is
|
||||
- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is
|
||||
driving a 2-DSI panel whose 2 links need receive command simultaneously.
|
||||
- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
|
||||
through MDP block
|
||||
- pinctrl-names: the pin control state names; should contain "default"
|
||||
- pinctrl-0: the default pinctrl state (active)
|
||||
- pinctrl-n: the "sleep" pinctrl state
|
||||
- port: DSI controller output port. This contains one endpoint subnode, with its
|
||||
remote-endpoint set to the phandle of the connected panel's endpoint.
|
||||
See Documentation/devicetree/bindings/graph.txt for device graph info.
|
||||
|
||||
DSI PHY:
|
||||
Required properties:
|
||||
- compatible: Could be the following
|
||||
* "qcom,dsi-phy-28nm-hpm"
|
||||
* "qcom,dsi-phy-28nm-lp"
|
||||
* "qcom,dsi-phy-20nm"
|
||||
- reg: Physical base address and length of the registers of PLL, PHY and PHY
|
||||
regulator
|
||||
- reg-names: The names of register regions. The following regions are required:
|
||||
|
|
@ -59,6 +66,10 @@ Required properties:
|
|||
* "iface_clk"
|
||||
- vddio-supply: phandle to vdd-io regulator device node
|
||||
|
||||
Optional properties:
|
||||
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
|
||||
regulator is wanted.
|
||||
|
||||
Example:
|
||||
mdss_dsi0: qcom,mdss_dsi@fd922800 {
|
||||
compatible = "qcom,mdss-dsi-ctrl";
|
||||
|
|
@ -90,9 +101,13 @@ Example:
|
|||
|
||||
qcom,dsi-phy = <&mdss_dsi_phy0>;
|
||||
|
||||
qcom,dual-panel-mode;
|
||||
qcom,master-panel;
|
||||
qcom,sync-dual-panel;
|
||||
qcom,dual-dsi-mode;
|
||||
qcom,master-dsi;
|
||||
qcom,sync-dual-dsi;
|
||||
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&mdss_dsi_active>;
|
||||
pinctrl-1 = <&mdss_dsi_suspend>;
|
||||
|
||||
panel: panel@0 {
|
||||
compatible = "sharp,lq101r1sx01";
|
||||
|
|
@ -101,6 +116,18 @@ Example:
|
|||
|
||||
power-supply = <...>;
|
||||
backlight = <...>;
|
||||
|
||||
port {
|
||||
panel_in: endpoint {
|
||||
remote-endpoint = <&dsi0_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
port {
|
||||
dsi0_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
@ -117,4 +144,6 @@ Example:
|
|||
clock-names = "iface_clk";
|
||||
clocks = <&mmcc MDSS_AHB_CLK>;
|
||||
vddio-supply = <&pma8084_l12>;
|
||||
|
||||
qcom,dsi-phy-regulator-ldo-mode;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,8 +2,9 @@ Qualcomm adreno/snapdragon hdmi output
|
|||
|
||||
Required properties:
|
||||
- compatible: one of the following
|
||||
* "qcom,hdmi-tx-8994"
|
||||
* "qcom,hdmi-tx-8084"
|
||||
* "qcom,hdmi-tx-8074"
|
||||
* "qcom,hdmi-tx-8974"
|
||||
* "qcom,hdmi-tx-8660"
|
||||
* "qcom,hdmi-tx-8960"
|
||||
- reg: Physical base address and length of the controller's registers
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue