redonkable
/
remarkable-linux
1
0
Fork 0
Code Releases Activity

Merge linux-block/for-4.3/core into md/for-linux 

There were a few conflicts that are fairly easy to resolve.

Signed-off-by: NeilBrown <neilb@suse.com>
steinar/wifi_calib_4_9_kernel
NeilBrown 2015-09-05 11:07:04 +02:00
parent c3cce6cda1 1081230b74
commit e89c6fdf9e
4194 changed files with 170019 additions and 80992 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.get_maintainer.ignore 100644
View File

@ -0,0 +1 @@
Christoph Hellwig <hch@lst.de>

1
.mailmap
View File

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

5
CREDITS
View File

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

29
Documentation/ABI/stable/sysfs-bus-vmbus 100644
View File

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

2
Documentation/ABI/testing/configfs-usb-gadget-loopback
View File

@ -5,4 +5,4 @@ Description:
The attributes:
qlen - depth of loopback queue
bulk_buflen - buffer length
buflen - buffer length

2
Documentation/ABI/testing/configfs-usb-gadget-sourcesink
View File

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

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

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

2
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm4x
View File

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

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

@ -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
Documentation/ABI/testing/sysfs-bus-iio-trigger-sysfs
View File

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

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

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

45
Documentation/ABI/testing/sysfs-class-power-twl4030 100644
View File

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

22
Documentation/ABI/testing/sysfs-driver-sunxi-sid
View File

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

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

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

2
Documentation/CodingStyle
View File

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

55
Documentation/DocBook/Makefile
View File

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

8
Documentation/DocBook/crypto-API.tmpl
View File

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

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

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

697
Documentation/DocBook/iio.tmpl 100644
View File

@ -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 = &amp;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
-->

1
Documentation/DocBook/stylesheet.xsl
View File

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

28
Documentation/HOWTO
View File

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

2
Documentation/Intel-IOMMU.txt
View File

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

2
Documentation/RCU/rcu_dereference.txt
View File

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

29
Documentation/RCU/stallwarn.txt
View File

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

36
Documentation/RCU/trace.txt
View File

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

2
Documentation/RCU/whatisRCU.txt
View File

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

14
Documentation/SubmittingPatches
View File

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

208
Documentation/acpi/method-tracing.txt
View File

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

527
Documentation/adding-syscalls.txt 100644
View File

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

5
Documentation/arm/Atmel/README
View File

@ -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
Documentation/arm/Samsung/Bootloader-interface.txt
View File

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

73
Documentation/arm/keystone/Overview.txt 100644
View File

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

2
Documentation/block/biodoc.txt
View File

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

10
Documentation/block/biovecs.txt
View File

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

10
Documentation/block/queue-sysfs.txt
View File

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

2
Documentation/cgroups/00-INDEX
View File

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

85
Documentation/cgroups/pids.txt 100644
View File

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

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

@ -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. blkio
5-4-2. cpuset
5-4-3. memory
6. Planned Changes
6-1. CAP for resource control
@ -372,14 +375,75 @@ 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
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. 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. blkio
- blk-throttle becomes properly hierarchical.
5-3-2. cpuset
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 +452,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.

8
Documentation/clk.txt
View File

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

7
Documentation/cpu-freq/core.txt
View File

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

17
Documentation/devicetree/bindings/arc/archs-pct.txt 100644
View File

@ -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";
};

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

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

9
Documentation/devicetree/bindings/arm/bcm/ns2.txt 100644
View File

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

14
Documentation/devicetree/bindings/arm/bcm/raspberrypi,bcm2835-firmware.txt 100644
View File

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

1
Documentation/devicetree/bindings/arm/coresight.txt
View File

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

1
Documentation/devicetree/bindings/arm/cpus.txt
View File

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

18
Documentation/devicetree/bindings/arm/hisilicon/hisilicon.txt
View File

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

2
Documentation/devicetree/bindings/arm/marvell,kirkwood.txt
View File

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

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

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

4
Documentation/devicetree/bindings/arm/mediatek/mediatek,sysirq.txt
View File

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

3
Documentation/devicetree/bindings/arm/omap/omap.txt
View File

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

35
Documentation/devicetree/bindings/arm/rockchip.txt
View File

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

46
Documentation/devicetree/bindings/arm/sp810.txt 100644
View File

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

19
Documentation/devicetree/bindings/clock/gpio-mux-clock.txt 100644
View File

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

19
Documentation/devicetree/bindings/clock/hi6220-clock.txt
View File

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

13
Documentation/devicetree/bindings/clock/imx6ul-clock.txt 100644
View File

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

83
Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt 100644
View File

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

79
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt 100644
View File

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

29
Documentation/devicetree/bindings/clock/renesas,r8a7778-cpg-clocks.txt
View File

@ -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";
};

30
Documentation/devicetree/bindings/clock/renesas,r8a7779-cpg-clocks.txt
View File

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

26
Documentation/devicetree/bindings/clock/renesas,rcar-gen2-cpg-clocks.txt
View File

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

29
Documentation/devicetree/bindings/clock/renesas,rz-cpg-clocks.txt
View File

@ -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";
};

61
Documentation/devicetree/bindings/clock/rockchip,rk3368-cru.txt 100644
View File

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

4
Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
View File

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

64
Documentation/devicetree/bindings/clock/ux500.txt 100644
View File

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

44
Documentation/devicetree/bindings/cpufreq/tegra124-cpufreq.txt 100644
View File

@ -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>;
};
<...>
};

108
Documentation/devicetree/bindings/crypto/fsl-sec4.txt
View File

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

23
Documentation/devicetree/bindings/crypto/sun4i-ss.txt 100644
View File

@ -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";
};

43
Documentation/devicetree/bindings/devfreq/event/exynos-ppmu.txt
View File

@ -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";
};

5
Documentation/devicetree/bindings/extcon/extcon-palmas.txt
View File

@ -10,8 +10,11 @@ Required Properties:
Optional Properties:
- ti,wakeup : To enable the wakeup comparator in probe
- ti,enable-id-detection: Perform ID detection.
- ti,enable-id-detection: Perform ID detection. If id-gpio is specified
it performs id-detection using GPIO else using OTG core.
- ti,enable-vbus-detection: Perform VBUS detection.
- id-gpio: gpio for GPIO ID detection. See gpio binding.
- debounce-delay-ms: debounce delay for GPIO ID pin in milliseconds.
palmas-usb {
compatible = "ti,twl6035-usb", "ti,palmas-usb";

21
Documentation/devicetree/bindings/hwmon/lm70.txt 100644
View File

@ -0,0 +1,21 @@
* LM70/TMP121/LM71/LM74 thermometer.
Required properties:
- compatible: one of
"ti,lm70"
"ti,tmp121"
"ti,lm71"
"ti,lm74"
See Documentation/devicetree/bindings/spi/spi-bus.txt for more required and
optional properties.
Example:
spi_master {
temperature-sensor@0 {
compatible = "ti,lm70";
reg = <0>;
spi-max-frequency = <1000000>;
};
};

12
Documentation/devicetree/bindings/hwmon/ltc2978.txt
View File

@ -3,10 +3,16 @@ ltc2978
Required properties:
- compatible: should contain one of:
* "lltc,ltc2974"
* "lltc,ltc2975"
* "lltc,ltc2977"
* "lltc,ltc2978"
* "lltc,ltc2980"
* "lltc,ltc3880"
* "lltc,ltc3882"
* "lltc,ltc3883"
* "lltc,ltc3886"
* "lltc,ltc3887"
* "lltc,ltm2987"
* "lltc,ltm4676"
- reg: I2C slave address
@ -17,10 +23,10 @@ Optional properties:
standard binding for regulators; see regulator.txt.
Valid names of regulators depend on number of supplies supported per device:
* ltc2974 : vout0 - vout3
* ltc2977 : vout0 - vout7
* ltc2974, ltc2975 : vout0 - vout3
* ltc2977, ltc2980, ltm2987 : vout0 - vout7
* ltc2978 : vout0 - vout7
* ltc3880 : vout0 - vout1
* ltc3880, ltc3882, ltc3886 : vout0 - vout1
* ltc3883 : vout0
* ltm4676 : vout0 - vout1

1
Documentation/devicetree/bindings/iio/adc/mcp320x.txt
View File

@ -18,6 +18,7 @@ Required properties:
"mcp3202"
"mcp3204"
"mcp3208"
"mcp3301"
Examples:

5
Documentation/devicetree/bindings/iio/adc/vf610-adc.txt
View File

@ -17,6 +17,11 @@ Recommended properties:
- Frequency in normal mode (ADLPC=0, ADHSC=0)
- Frequency in high-speed mode (ADLPC=0, ADHSC=1)
- Frequency in low-power mode (ADLPC=1, ADHSC=0)
- min-sample-time: Minimum sampling time in nanoseconds. This value has
to be chosen according to the conversion mode and the connected analog
source resistance (R_as) and capacitance (C_as). Refer the datasheet's
operating requirements. A safe default across a wide range of R_as and
C_as as well as conversion modes is 1000ns.
Example:
adc0: adc@4003b000 {

13
Documentation/devicetree/bindings/iio/magnetometer/mmc35240.txt 100644
View File

@ -0,0 +1,13 @@
* MEMSIC MMC35240 magnetometer sensor
Required properties:
- compatible : should be "memsic,mmc35240"
- reg : the I2C address of the magnetometer
Example:
mmc35240@30 {
compatible = "memsic,mmc35240";
reg = <0x30>;
};

2
Documentation/devicetree/bindings/iio/st-sensors.txt
View File

@ -35,6 +35,7 @@ Accelerometers:
- st,lsm303dl-accel
- st,lsm303dlm-accel
- st,lsm330-accel
- st,lsm303agr-accel
Gyroscopes:
- st,l3g4200d-gyro
@ -46,6 +47,7 @@ Gyroscopes:
- st,lsm330-gyro
Magnetometers:
- st,lsm303agr-magn
- st,lsm303dlh-magn
- st,lsm303dlhc-magn
- st,lsm303dlm-magn

1
Documentation/devicetree/bindings/input/snvs-pwrkey.txt 100644
View File

@ -0,0 +1 @@
See Documentation/devicetree/bindings/crypto/fsl-sec4.txt

25
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
View File

@ -5,9 +5,14 @@ The BCM2835 contains a custom top-level interrupt controller, which supports
controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence naming of this binding.
The BCM2836 contains the same interrupt controller with the same
interrupts, but the per-CPU interrupt controller is the root, and an
interrupt there indicates that the ARMCTRL has an interrupt to handle.
Required properties:
- compatible : should be "brcm,bcm2835-armctrl-ic"
- compatible : should be "brcm,bcm2835-armctrl-ic" or
"brcm,bcm2836-armctrl-ic"
- reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an
@ -20,6 +25,12 @@ Required properties:
The 2nd cell contains the interrupt number within the bank. Valid values
are 0..7 for bank 0, and 0..31 for bank 1.
Additional required properties for brcm,bcm2836-armctrl-ic:
- interrupt-parent : Specifies the parent interrupt controller when this
controller is the second level.
- interrupts : Specifies the interrupt on the parent for this interrupt
controller to handle.
The interrupt sources are as follows:
Bank 0:
@ -102,9 +113,21 @@ Bank 2:
Example:
/* BCM2835, first level */
intc: interrupt-controller {
compatible = "brcm,bcm2835-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-controller;
#interrupt-cells = <2>;
};
/* BCM2836, second level */
intc: interrupt-controller {
compatible = "brcm,bcm2836-armctrl-ic";
reg = <0x7e00b200 0x200>;
interrupt-controller;
#interrupt-cells = <2>;
interrupt-parent = <&local_intc>;
interrupts = <8>;
};

37
Documentation/devicetree/bindings/interrupt-controller/brcm,bcm2836-l1-intc.txt 100644
View File

@ -0,0 +1,37 @@
BCM2836 per-CPU interrupt controller
The BCM2836 has a per-cpu interrupt controller for the timer, PMU
events, and SMP IPIs. One of the CPUs may receive interrupts for the
peripheral (GPU) events, which chain to the BCM2835-style interrupt
controller.
Required properties:
- compatible: Should be "brcm,bcm2836-l1-intc"
- reg: Specifies base physical address and size of the
registers
- interrupt-controller: Identifies the node as an interrupt controller
- #interrupt-cells: Specifies the number of cells needed to encode an
interrupt source. The value shall be 1
Please refer to interrupts.txt in this directory for details of the common
Interrupt Controllers bindings used by client devices.
The interrupt sources are as follows:
0: CNTPSIRQ
1: CNTPNSIRQ
2: CNTHPIRQ
3: CNTVIRQ
8: GPU_FAST
9: PMU_FAST
Example:
local_intc: local_intc {
compatible = "brcm,bcm2836-l1-intc";
reg = <0x40000000 0x100>;
interrupt-controller;
#interrupt-cells = <1>;
interrupt-parent = <&local_intc>;
};

135
Documentation/devicetree/bindings/interrupt-controller/msi.txt 100644
View File

@ -0,0 +1,135 @@
This document describes the generic device tree binding for MSI controllers and
their master(s).
Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
write to an MMIO address.
MSIs were originally specified by PCI (and are used with PCIe), but may also be
used with other busses, and hence a mechanism is required to relate devices on
those busses to the MSI controllers which they are capable of using,
potentially including additional information.
MSIs are distinguished by some combination of:
- The doorbell (the MMIO address written to).
Devices may be configured by software to write to arbitrary doorbells which
they can address. An MSI controller may feature a number of doorbells.
- The payload (the value written to the doorbell).
Devices may be configured to write an arbitrary payload chosen by software.
MSI controllers may have restrictions on permitted payloads.
- Sideband information accompanying the write.
Typically this is neither configurable nor probeable, and depends on the path
taken through the memory system (i.e. it is a property of the combination of
MSI controller and device rather than a property of either in isolation).
MSI controllers:
================
An MSI controller signals interrupts to a CPU when a write is made to an MMIO
address by some master. An MSI controller may feature a number of doorbells.
Required properties:
--------------------
- msi-controller: Identifies the node as an MSI controller.
Optional properties:
--------------------
- #msi-cells: The number of cells in an msi-specifier, required if not zero.
Typically this will encode information related to sideband data, and will
not encode doorbells or payloads as these can be configured dynamically.
The meaning of the msi-specifier is defined by the device tree binding of
the specific MSI controller.
MSI clients
===========
MSI clients are devices which generate MSIs. For each MSI they wish to
generate, the doorbell and payload may be configured, though sideband
information may not be configurable.
Required properties:
--------------------
- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
controller which the device is capable of using.
This property is unordered, and MSIs may be allocated from any combination of
MSI controllers listed in the msi-parent property.
If a device has restrictions on the allocation of MSIs, these restrictions
must be described with additional properties.
When #msi-cells is non-zero, busses with an msi-parent will require
additional properties to describe the relationship between devices on the bus
and the set of MSIs they can potentially generate.
Example
=======
/ {
#address-cells = <1>;
#size-cells = <1>;
msi_a: msi-controller@a {
reg = <0xa 0xf00>;
compatible = "vendor-a,some-controller";
msi-controller;
/* No sideband data, so #msi-cells omitted */
};
msi_b: msi-controller@b {
reg = <0xb 0xf00>;
compatible = "vendor-b,another-controller";
msi-controller;
/* Each device has some unique ID */
#msi-cells = <1>;
};
msi_c: msi-controller@c {
reg = <0xb 0xf00>;
compatible = "vendor-b,another-controller";
msi-controller;
/* Each device has some unique ID */
#msi-cells = <1>;
};
dev@0 {
reg = <0x0 0xf00>;
compatible = "vendor-c,some-device";
/* Can only generate MSIs to msi_a */
msi-parent = <&msi_a>;
};
dev@1 {
reg = <0x1 0xf00>;
compatible = "vendor-c,some-device";
/*
* Can generate MSIs to either A or B.
*/
msi-parent = <&msi_a>, <&msi_b 0x17>;
};
dev@2 {
reg = <0x2 0xf00>;
compatible = "vendor-c,some-device";
/*
* Has different IDs at each MSI controller.
* Can generate MSIs to all of the MSI controllers.
*/
msi-parent = <&msi_a>, <&msi_b 0x17>, <&msi_c 0x53>;
};
};

27
Documentation/devicetree/bindings/leds/common.txt
View File

@ -29,14 +29,23 @@ Optional properties for child nodes:
"ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate
- max-microamp : maximum intensity in microamperes of the LED
(torch LED for flash devices)
- flash-max-microamp : maximum intensity in microamperes of the
flash LED; it is mandatory if the LED should
support the flash mode
- flash-timeout-us : timeout in microseconds after which the flash
LED is turned off
- led-max-microamp : Maximum LED supply current in microamperes. This property
can be made mandatory for the board configurations
introducing a risk of hardware damage in case an excessive
current is set.
For flash LED controllers with configurable current this
property is mandatory for the LEDs in the non-flash modes
(e.g. torch or indicator).
Required properties for flash LED child nodes:
- flash-max-microamp : Maximum flash LED supply current in microamperes.
- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
LED is turned off.
For controllers that have no configurable current the flash-max-microamp
property can be omitted.
For controllers that have no configurable timeout the flash-max-timeout-us
property can be omitted.
Examples:
@ -49,7 +58,7 @@ system-status {
camera-flash {
label = "Flash";
led-sources = <0>, <1>;
max-microamp = <50000>;
led-max-microamp = <50000>;
flash-max-microamp = <320000>;
flash-timeout-us = <500000>;
flash-max-timeout-us = <500000>;
};

9
Documentation/devicetree/bindings/leds/leds-ns2.txt
View File

@ -8,6 +8,9 @@ Each LED is represented as a sub-node of the ns2-leds device.
Required sub-node properties:
- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
- modes-map: A mapping between LED modes (off, on or SATA activity blinking) and
the corresponding cmd-gpio/slow-gpio values. All the GPIO values combinations
should be given in order to avoid having an unknown mode at driver probe time.
Optional sub-node properties:
- label: Name for this LED. If omitted, the label is taken from the node name.
@ -15,6 +18,8 @@ Optional sub-node properties:
Example:
#include <dt-bindings/leds/leds-ns2.h>
ns2-leds {
compatible = "lacie,ns2-leds";
@ -22,5 +27,9 @@ ns2-leds {
label = "ns2:blue:sata";
slow-gpio = <&gpio0 29 0>;
cmd-gpio = <&gpio0 30 0>;
modes-map = <NS_V2_LED_OFF 0 1
NS_V2_LED_ON 1 0
NS_V2_LED_ON 0 0
NS_V2_LED_SATA 1 1>;
};
};

125
Documentation/devicetree/bindings/memory-controllers/arm,pl172.txt 100644
View File

@ -0,0 +1,125 @@
* Device tree bindings for ARM PL172 MultiPort Memory Controller
Required properties:
- compatible: "arm,pl172", "arm,primecell"
- reg: Must contains offset/length value for controller.
- #address-cells: Must be 2. The partition number has to be encoded in the
first address cell and it may accept values 0..N-1
(N - total number of partitions). The second cell is the
offset into the partition.
- #size-cells: Must be set to 1.
- ranges: Must contain one or more chip select memory regions.
- clocks: Must contain references to controller clocks.
- clock-names: Must contain "mpmcclk" and "apb_pclk".
- clock-ranges: Empty property indicating that child nodes can inherit
named clocks. Required only if clock tree data present
in device tree.
See clock-bindings.txt
Child chip-select (cs) nodes contain the memory devices nodes connected to
such as NOR (e.g. cfi-flash) and NAND.
Required child cs node properties:
- #address-cells: Must be 2.
- #size-cells: Must be 1.
- ranges: Empty property indicating that child nodes can inherit
memory layout.
- clock-ranges: Empty property indicating that child nodes can inherit
named clocks. Required only if clock tree data present
in device tree.
- mpmc,cs: Chip select number. Indicates to the pl0172 driver
which chipselect is used for accessing the memory.
- mpmc,memory-width: Width of the chip select memory. Must be equal to
either 8, 16 or 32.
Optional child cs node config properties:
- mpmc,async-page-mode: Enable asynchronous page mode.
- mpmc,cs-active-high: Set chip select polarity to active high.
- mpmc,byte-lane-low: Set byte lane state to low.
- mpmc,extended-wait: Enable extended wait.
- mpmc,buffer-enable: Enable write buffer.
- mpmc,write-protect: Enable write protect.
Optional child cs node timing properties:
- mpmc,write-enable-delay: Delay from chip select assertion to write
enable (WE signal) in nano seconds.
- mpmc,output-enable-delay: Delay from chip select assertion to output
enable (OE signal) in nano seconds.
- mpmc,write-access-delay: Delay from chip select assertion to write
access in nano seconds.
- mpmc,read-access-delay: Delay from chip select assertion to read
access in nano seconds.
- mpmc,page-mode-read-delay: Delay for asynchronous page mode sequential
accesses in nano seconds.
- mpmc,turn-round-delay: Delay between access to memory banks in nano
seconds.
If any of the above timing parameters are absent, current parameter value will
be taken from the corresponding HW reg.
Example for pl172 with nor flash on chip select 0 shown below.
emc: memory-controller@40005000 {
compatible = "arm,pl172", "arm,primecell";
reg = <0x40005000 0x1000>;
clocks = <&ccu1 CLK_CPU_EMCDIV>, <&ccu1 CLK_CPU_EMC>;
clock-names = "mpmcclk", "apb_pclk";
#address-cells = <2>;
#size-cells = <1>;
ranges = <0 0 0x1c000000 0x1000000
1 0 0x1d000000 0x1000000
2 0 0x1e000000 0x1000000
3 0 0x1f000000 0x1000000>;
cs0 {
#address-cells = <2>;
#size-cells = <1>;
ranges;
mpmc,cs = <0>;
mpmc,memory-width = <16>;
mpmc,byte-lane-low;
mpmc,write-enable-delay = <0>;
mpmc,output-enable-delay = <0>;
mpmc,read-enable-delay = <70>;
mpmc,page-mode-read-delay = <70>;
flash@0,0 {
compatible = "sst,sst39vf320", "cfi-flash";
reg = <0 0 0x400000>;
bank-width = <2>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "data";
reg = <0 0x400000>;
};
};
};
};

4
Documentation/devicetree/bindings/memory-controllers/synopsys.txt
View File

@ -1,5 +1,9 @@
Binding for Synopsys IntelliDDR Multi Protocol Memory Controller
This controller has an optional ECC support in half-bus width (16-bit)
configuration. The ECC controller corrects one bit error and detects
two bit errors.
Required properties:
- compatible: Should be 'xlnx,zynq-ddrc-a05'
- reg: Base address and size of the controllers memory area

8
Documentation/devicetree/bindings/mfd/rk808.txt
View File

@ -24,6 +24,10 @@ Optional properties:
- vcc10-supply: The input supply for LDO_REG6
- vcc11-supply: The input supply for LDO_REG8
- vcc12-supply: The input supply for SWITCH_REG2
- dvs-gpios: buck1/2 can be controlled by gpio dvs, this is GPIO specifiers
for 2 host gpio's used for dvs. The format of the gpio specifier depends in
the gpio controller. If DVS GPIOs aren't present, voltage changes will happen
very quickly with no slow ramp time.
Regulators: All the regulators of RK808 to be instantiated shall be
listed in a child node named 'regulators'. Each regulator is represented
@ -55,7 +59,9 @@ Example:
interrupt-parent = <&gpio0>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default";
pinctrl-0 = <&pmic_int>;
pinctrl-0 = <&pmic_int &dvs_1 &dvs_2>;
dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>,
<&gpio7 15 GPIO_ACTIVE_HIGH>;
reg = <0x1b>;
rockchip,system-power-controller;
wakeup-source;

3
Documentation/devicetree/bindings/mtd/fsl-quadspi.txt
View File

@ -1,7 +1,8 @@
* Freescale Quad Serial Peripheral Interface(QuadSPI)
Required properties:
- compatible : Should be "fsl,vf610-qspi" or "fsl,imx6sx-qspi"
- compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
"fsl,imx7d-qspi", "fsl,imx6ul-qspi"
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"

58
Documentation/devicetree/bindings/mtd/nxp-spifi.txt 100644
View File

@ -0,0 +1,58 @@
* NXP SPI Flash Interface (SPIFI)
NXP SPIFI is a specialized SPI interface for serial Flash devices.
It supports one Flash device with 1-, 2- and 4-bits width in SPI
mode 0 or 3. The controller operates in either command or memory
mode. In memory mode the Flash is accessible from the CPU as
normal memory.
Required properties:
- compatible : Should be "nxp,lpc1773-spifi"
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "spifi" and "flash"
- interrupts : Should contain the interrupt for the device
- clocks : The clocks needed by the SPIFI controller
- clock-names : Should contain the clock names "spifi" and "reg"
Optional properties:
- resets : phandle + reset specifier
The SPI Flash must be a child of the SPIFI node and must have a
compatible property as specified in bindings/mtd/jedec,spi-nor.txt
Optionally it can also contain the following properties.
- spi-cpol : Controller only supports mode 0 and 3 so either
both spi-cpol and spi-cpha should be present or
none of them
- spi-cpha : See above
- spi-rx-bus-width : Used to select how many pins that are used
for input on the controller
See bindings/spi/spi-bus.txt for more information.
Example:
spifi: spifi@40003000 {
compatible = "nxp,lpc1773-spifi";
reg = <0x40003000 0x1000>, <0x14000000 0x4000000>;
reg-names = "spifi", "flash";
interrupts = <30>;
clocks = <&ccu1 CLK_SPIFI>, <&ccu1 CLK_CPU_SPIFI>;
clock-names = "spifi", "reg";
resets = <&rgu 53>;
flash@0 {
compatible = "jedec,spi-nor";
spi-cpol;
spi-cpha;
spi-rx-bus-width = <4>;
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "data";
reg = <0 0x200000>;
};
};
};

3
Documentation/devicetree/bindings/mtd/pxa3xx-nand.txt
View File

@ -11,6 +11,7 @@ Required properties:
Optional properties:
- dmas: dma data channel, see dma.txt binding doc
- marvell,nand-enable-arbiter: Set to enable the bus arbiter
- marvell,nand-keep-config: Set to keep the NAND controller config as set
by the bootloader
@ -32,6 +33,8 @@ Example:
compatible = "marvell,pxa3xx-nand";
reg = <0x43100000 90>;
interrupts = <45>;
dmas = <&pdma 97 0>;
dma-names = "data";
#address-cells = <1>;
marvell,nand-enable-arbiter;

6
Documentation/devicetree/bindings/net/cpsw.txt
View File

@ -2,7 +2,11 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
------------------------------------------------------
Required properties:
- compatible : Should be "ti,cpsw"
- compatible : Should be one of the below:-
"ti,cpsw" for backward compatible
"ti,am335x-cpsw" for AM335x controllers
"ti,am4372-cpsw" for AM437x controllers
"ti,dra7-cpsw" for DRA7x controllers
- reg : physical base address and size of the cpsw
registers map
- interrupts : property with a value describing the interrupt

4
Documentation/devicetree/bindings/misc/allwinner,sunxi-sid.txt → Documentation/devicetree/bindings/nvmem/allwinner,sunxi-sid.txt
View File

@ -4,6 +4,10 @@ Required properties:
- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
- reg: Should contain registers location and length
= Data cells =
Are child nodes of qfprom, bindings of which as described in
bindings/nvmem/nvmem.txt
Example for sun4i:
sid@01c23800 {
compatible = "allwinner,sun4i-a10-sid";

80
Documentation/devicetree/bindings/nvmem/nvmem.txt 100644
View File

@ -0,0 +1,80 @@
= NVMEM(Non Volatile Memory) Data Device Tree Bindings =
This binding is intended to represent the location of hardware
configuration data stored in NVMEMs like eeprom, efuses and so on.
On a significant proportion of boards, the manufacturer has stored
some data on NVMEM, for the OS to be able to retrieve these information
and act upon it. Obviously, the OS has to know about where to retrieve
these data from, and where they are stored on the storage device.
This document is here to document this.
= Data providers =
Contains bindings specific to provider drivers and data cells as children
of this node.
Optional properties:
read-only: Mark the provider as read only.
= Data cells =
These are the child nodes of the provider which contain data cell
information like offset and size in nvmem provider.
Required properties:
reg: specifies the offset in byte within the storage device.
Optional properties:
bits: Is pair of bit location and number of bits, which specifies offset
in bit and number of bits within the address range specified by reg property.
Offset takes values from 0-7.
For example:
/* Provider */
qfprom: qfprom@00700000 {
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x404 0x10>;
};
tsens_calibration_bckp: calib_bckp@504 {
reg = <0x504 0x11>;
bits = <6 128>
};
pvs_version: pvs-version@6 {
reg = <0x6 0x2>
bits = <7 2>
};
speed_bin: speed-bin@c{
reg = <0xc 0x1>;
bits = <2 3>;
};
...
};
= Data consumers =
Are device nodes which consume nvmem data cells/providers.
Required-properties:
nvmem-cells: list of phandle to the nvmem data cells.
nvmem-cell-names: names for the each nvmem-cells specified. Required if
nvmem-cells is used.
Optional-properties:
nvmem : list of phandles to nvmem providers.
nvmem-names: names for the each nvmem provider. required if nvmem is used.
For example:
tsens {
...
nvmem-cells = <&tsens_calibration>;
nvmem-cell-names = "calibration";
};

35
Documentation/devicetree/bindings/nvmem/qfprom.txt 100644
View File

@ -0,0 +1,35 @@
= Qualcomm QFPROM device tree bindings =
This binding is intended to represent QFPROM which is found in most QCOM SOCs.
Required properties:
- compatible: should be "qcom,qfprom"
- reg: Should contain registers location and length
= Data cells =
Are child nodes of qfprom, bindings of which as described in
bindings/nvmem/nvmem.txt
Example:
qfprom: qfprom@00700000 {
compatible = "qcom,qfprom";
reg = <0x00700000 0x8000>;
...
/* Data cells */
tsens_calibration: calib@404 {
reg = <0x4404 0x10>;
};
};
= Data consumers =
Are device nodes which consume nvmem data cells.
For example:
tsens {
...
nvmem-cells = <&tsens_calibration>;
nvmem-cell-names = "calibration";
};

40
Documentation/devicetree/bindings/power/opp.txt → Documentation/devicetree/bindings/opp/opp.txt
View File

@ -88,7 +88,7 @@ This defines voltage-current-frequency combinations along with other related
properties.
Required properties:
- opp-hz: Frequency in Hz
- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer.
Optional properties:
- opp-microvolt: voltage in micro Volts.
@ -158,20 +158,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
opp-shared;
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp-hz = <1100000000>;
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp-hz = <1200000000>;
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
clock-latency-ns = <290000>;
turbo-mode;
@ -237,20 +237,20 @@ independently.
*/
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp-hz = <1100000000>;
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp-hz = <1200000000>;
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000;
lock-latency-ns = <290000>;
@ -313,20 +313,20 @@ DVFS state together.
opp-shared;
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>;
opp-microamp = <70000>;
clock-latency-ns = <300000>;
opp-suspend;
};
opp01 {
opp-hz = <1100000000>;
opp-hz = /bits/ 64 <1100000000>;
opp-microvolt = <980000 1000000 1010000>;
opp-microamp = <80000>;
clock-latency-ns = <310000>;
};
opp02 {
opp-hz = <1200000000>;
opp-hz = /bits/ 64 <1200000000>;
opp-microvolt = <1025000>;
opp-microamp = <90000>;
clock-latency-ns = <290000>;
@ -339,20 +339,20 @@ DVFS state together.
opp-shared;
opp10 {
opp-hz = <1300000000>;
opp-hz = /bits/ 64 <1300000000>;
opp-microvolt = <1045000 1050000 1055000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
opp-suspend;
};
opp11 {
opp-hz = <1400000000>;
opp-hz = /bits/ 64 <1400000000>;
opp-microvolt = <1075000>;
opp-microamp = <100000>;
clock-latency-ns = <400000>;
};
opp12 {
opp-hz = <1500000000>;
opp-hz = /bits/ 64 <1500000000>;
opp-microvolt = <1010000 1100000 1110000>;
opp-microamp = <95000>;
clock-latency-ns = <400000>;
@ -379,7 +379,7 @@ Example 4: Handling multiple regulators
opp-shared;
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000>, /* Supply 0 */
<960000>, /* Supply 1 */
<960000>; /* Supply 2 */
@ -392,7 +392,7 @@ Example 4: Handling multiple regulators
/* OR */
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
<960000 965000 975000>; /* Supply 2 */
@ -405,7 +405,7 @@ Example 4: Handling multiple regulators
/* OR */
opp00 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
<960000 965000 975000>, /* Supply 1 */
<960000 965000 975000>; /* Supply 2 */
@ -437,12 +437,12 @@ Example 5: Multiple OPP tables
opp-shared;
opp00 {
opp-hz = <600000000>;
opp-hz = /bits/ 64 <600000000>;
...
};
opp01 {
opp-hz = <800000000>;
opp-hz = /bits/ 64 <800000000>;
...
};
};
@ -453,12 +453,12 @@ Example 5: Multiple OPP tables
opp-shared;
opp10 {
opp-hz = <1000000000>;
opp-hz = /bits/ 64 <1000000000>;
...
};
opp11 {
opp-hz = <1100000000>;
opp-hz = /bits/ 64 <1100000000>;
...
};
};

3
Documentation/devicetree/bindings/pci/ti-pci.txt
View File

@ -23,6 +23,9 @@ PCIe Designware Controller
interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt
Optional Property:
- gpios : Should be added if a gpio line is required to drive PERST# line
Example:
axi {
compatible = "simple-bus";

26
Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt 100644
View File

@ -0,0 +1,26 @@
NXP LPC18xx/43xx internal USB OTG PHY binding
---------------------------------------------
This file contains documentation for the internal USB OTG PHY found
in NXP LPC18xx and LPC43xx SoCs.
Required properties:
- compatible : must be "nxp,lpc1850-usb-otg-phy"
- clocks : must be exactly one entry
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
- #phy-cells : must be 0 for this phy
See: Documentation/devicetree/bindings/phy/phy-bindings.txt
The phy node must be a child of the creg syscon node.
Example:
creg: syscon@40043000 {
compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
reg = <0x40043000 0x1000>;
usb0_otg_phy: phy@004 {
compatible = "nxp,lpc1850-usb-otg-phy";
clocks = <&ccu1 CLK_USB0>;
#phy-cells = <0>;
};
};

22
Documentation/devicetree/bindings/phy/sun4i-usb-phy.txt
View File

@ -7,6 +7,8 @@ Required properties:
* allwinner,sun5i-a13-usb-phy
* allwinner,sun6i-a31-usb-phy
* allwinner,sun7i-a20-usb-phy
* allwinner,sun8i-a23-usb-phy
* allwinner,sun8i-a33-usb-phy
- reg : a list of offset + length pairs
- reg-names :
* "phy_ctrl"
@ -17,12 +19,21 @@ Required properties:
- clock-names :
* "usb_phy" for sun4i, sun5i or sun7i
* "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
* "usb0_phy", "usb1_phy" for sun8i
- resets : a list of phandle + reset specifier pairs
- reset-names :
* "usb0_reset"
* "usb1_reset"
* "usb2_reset" for sun4i, sun6i or sun7i
Optional properties:
- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect
- usb0_vbus-supply : regulator phandle for controller usb0 vbus
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
Example:
usbphy: phy@0x01c13400 {
#phy-cells = <1>;
@ -32,6 +43,13 @@ Example:
reg-names = "phy_ctrl", "pmu1", "pmu2";
clocks = <&usb_clk 8>;
clock-names = "usb_phy";
resets = <&usb_clk 1>, <&usb_clk 2>;
reset-names = "usb1_reset", "usb2_reset";
resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
pinctrl-names = "default";
pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
usb0_vbus-supply = <&reg_usb0_vbus>;
usb1_vbus-supply = <&reg_usb1_vbus>;
usb2_vbus-supply = <&reg_usb2_vbus>;
};

16
Documentation/devicetree/bindings/phy/ti-phy.txt
View File

@ -82,6 +82,9 @@ Optional properties:
- id: If there are multiple instance of the same type, in order to
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
PHY). If "id" is not provided, it is set to default value of '1'.
- syscon-pllreset: Handle to system control region that contains the
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
This is usually a subnode of ocp2scp to which it is connected.
@ -100,3 +103,16 @@ usb3phy@4a084400 {
"sysclk",
"refclk";
};
sata_phy: phy@4A096000 {
compatible = "ti,phy-pipe3-sata";
reg = <0x4A096000 0x80>, /* phy_rx */
<0x4A096400 0x64>, /* phy_tx */
<0x4A096800 0x40>; /* pll_ctrl */
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
ctrl-module = <&omap_control_sata>;
clocks = <&sys_clkin1>, <&sata_ref_clk>;
clock-names = "sysclk", "refclk";
syscon-pllreset = <&scm_conf 0x3fc>;
#phy-cells = <0>;
};

36
Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt 100644
View File

@ -0,0 +1,36 @@
* Freescale i.MX6 UltraLite IOMUX Controller
Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
and usage.
Required properties:
- compatible: "fsl,imx6ul-iomuxc"
- fsl,pins: each entry consists of 6 integers and represents the mux and config
setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
input_val> are specified using a PIN_FUNC_ID macro, which can be found in
imx6ul-pinfunc.h under device tree source folder. The last integer CONFIG is
the pad setting value like pull-up on this pin. Please refer to i.MX6 UltraLite
Reference Manual for detailed CONFIG settings.
CONFIG bits definition:
PAD_CTL_HYS (1 << 16)
PAD_CTL_PUS_100K_DOWN (0 << 14)
PAD_CTL_PUS_47K_UP (1 << 14)
PAD_CTL_PUS_100K_UP (2 << 14)
PAD_CTL_PUS_22K_UP (3 << 14)
PAD_CTL_PUE (1 << 13)
PAD_CTL_PKE (1 << 12)
PAD_CTL_ODE (1 << 11)
PAD_CTL_SPEED_LOW (0 << 6)
PAD_CTL_SPEED_MED (1 << 6)
PAD_CTL_SPEED_HIGH (3 << 6)
PAD_CTL_DSE_DISABLE (0 << 3)
PAD_CTL_DSE_260ohm (1 << 3)
PAD_CTL_DSE_130ohm (2 << 3)
PAD_CTL_DSE_87ohm (3 << 3)
PAD_CTL_DSE_65ohm (4 << 3)
PAD_CTL_DSE_52ohm (5 << 3)
PAD_CTL_DSE_43ohm (6 << 3)
PAD_CTL_DSE_37ohm (7 << 3)
PAD_CTL_SRE_FAST (1 << 0)
PAD_CTL_SRE_SLOW (0 << 0)

2
Documentation/devicetree/bindings/power/power_domain.txt
View File

@ -48,7 +48,7 @@ Example 2:
#power-domain-cells = <1>;
};
child: power-controller@12340000 {
child: power-controller@12341000 {
compatible = "foo,power-controller";
reg = <0x12341000 0x1000>;
power-domains = <&parent 0>;

48
Documentation/devicetree/bindings/power/qcom,coincell-charger.txt 100644
View File

@ -0,0 +1,48 @@
Qualcomm Coincell Charger:
The hardware block controls charging for a coincell or capacitor that is
used to provide power backup for certain features of the power management
IC (PMIC)
- compatible:
Usage: required
Value type: <string>
Definition: must be: "qcom,pm8941-coincell"
- reg:
Usage: required
Value type: <u32>
Definition: base address of the coincell charger registers
- qcom,rset-ohms:
Usage: required
Value type: <u32>
Definition: resistance (in ohms) for current-limiting resistor
must be one of: 800, 1200, 1700, 2100
- qcom,vset-millivolts:
Usage: required
Value type: <u32>
Definition: voltage (in millivolts) to apply for charging
must be one of: 2500, 3000, 3100, 3200
- qcom,charger-disable:
Usage: optional
Value type: <boolean>
Definition: definining this property disables charging
This charger is a sub-node of one of the 8941 PMIC blocks, and is specified
as a child node in DTS of that node. See ../mfd/qcom,spmi-pmic.txt and
../mfd/qcom-pm8xxx.txt
Example:
pm8941@0 {
coincell@2800 {
compatible = "qcom,pm8941-coincell";
reg = <0x2800>;
qcom,rset-ohms = <2100>;
qcom,vset-millivolts = <3000>;
};
};

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