renegade-project/linux-next
2
0
Fork 0
mirror of https://github.com/edk2-porting/linux-next.git synced 2024-12-25 05:34:00 +08:00
Code

Merge branch 'linus' into x86/urgent, to be able to merge a dependent fix

Browse Source 
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar 2015-09-05 09:00:30 +02:00
commit 95cd2ea7d5
3401 changed files with 144883 additions and 71332 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
.get_maintainer.ignore Normal file
View File

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

29
Documentation/ABI/stable/sysfs-bus-vmbus Normal file
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: The attributes:
qlen - depth of loopback queue 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_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
isoc_mult - 0..2 (hs/ss only) isoc_mult - 0..2 (hs/ss only)
isoc_maxburst - 0..15 (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> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Mask to apply to all the context ID comparator. 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 Date: November 2014
KernelVersion: 3.19 KernelVersion: 3.19
Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 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> Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Select which context ID comparator to work with. 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 Date: April 2015
KernelVersion: 4.01 KernelVersion: 4.01
Contact: Mathieu Poirier <mathieu.poirier@linaro.org> 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. to compute the calories burnt by the user.
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available 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_voltageX_scale_available
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
What: /sys/.../iio:deviceX/out_voltageX_scale_available What: /sys/.../iio:deviceX/out_voltageX_scale_available
@ -488,7 +493,7 @@ Contact: linux-iio@vger.kernel.org
Description: Description:
Specifies the output powerdown mode. Specifies the output powerdown mode.
DAC output stage is disconnected from the amplifier and 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, 6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor, 20kohm_to_gnd: connected to ground via a 20kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm 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 outX_powerdown_mode_available. If Y is not present the
mode is shared across all outputs. 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_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 What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
KernelVersion: 2.6.38 KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org Contact: linux-iio@vger.kernel.org
@ -1035,13 +1040,6 @@ Contact: linux-iio@vger.kernel.org
Description: Description:
Number of scans contained by the buffer. 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 What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
KernelVersion: 2.6.35 KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org 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 automated testing or in situations, where other trigger methods
are not applicable. For example no RTC or spare GPIOs. are not applicable. For example no RTC or spare GPIOs.
X is the IIO index of the trigger. 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 enabled for the device. Developer can write y/Y/1 or n/N/0 to
the file to enable/disable the feature. 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 What: /sys/bus/usb/devices/.../removable
Date: February 2012 Date: February 2012
Contact: Matthew Garrett <mjg@redhat.com> Contact: Matthew Garrett <mjg@redhat.com>

45
Documentation/ABI/testing/sysfs-class-power-twl4030 Normal file
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.

2
Documentation/CodingStyle
View File

@ -929,13 +929,11 @@ The C Programming Language, Second Edition
by Brian W. Kernighan and Dennis M. Ritchie. by Brian W. Kernighan and Dennis M. Ritchie.
Prentice Hall, Inc., 1988. Prentice Hall, Inc., 1988.
ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback). ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
URL: http://cm.bell-labs.com/cm/cs/cbook/
The Practice of Programming The Practice of Programming
by Brian W. Kernighan and Rob Pike. by Brian W. Kernighan and Rob Pike.
Addison-Wesley, Inc., 1999. Addison-Wesley, Inc., 1999.
ISBN 0-201-61586-X. 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, 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/ 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 \ 80211.xml debugobjects.xml sh.xml regulator.xml \
alsa-driver-api.xml writing-an-alsa-driver.xml \ alsa-driver-api.xml writing-an-alsa-driver.xml \
tracepoint.xml drm.xml media_api.xml w1.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 include Documentation/DocBook/media/Makefile
@ -56,16 +56,19 @@ htmldocs: $(HTML)
MAN := $(patsubst %.xml, %.9, $(BOOKS)) MAN := $(patsubst %.xml, %.9, $(BOOKS))
mandocs: $(MAN) mandocs: $(MAN)
find $(obj)/man -name '*.9' | xargs gzip -f find $(obj)/man -name '*.9' | xargs gzip -nf
installmandocs: mandocs installmandocs: mandocs
mkdir -p /usr/local/man/man9/ 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 #External programs used
KERNELDOC = $(srctree)/scripts/kernel-doc KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
DOCPROC = $(objtree)/scripts/docproc KERNELDOC = $(srctree)/scripts/kernel-doc
DOCPROC = $(objtree)/scripts/docproc
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
XMLTOFLAGS += --skip-validation XMLTOFLAGS += --skip-validation
@ -89,7 +92,7 @@ define rule_docproc
) > $(dir $@).$(notdir $@).cmd ) > $(dir $@).$(notdir $@).cmd
endef endef
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE %.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
$(call if_changed_rule,docproc) $(call if_changed_rule,docproc)
# Tell kbuild to always build the programs # Tell kbuild to always build the programs
@ -140,7 +143,20 @@ quiet_cmd_db2html = HTML $@
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \ echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@ $(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) || \ @(which xmlto > /dev/null 2>&1) || \
(echo "*** You need to install xmlto ***"; \ (echo "*** You need to install xmlto ***"; \
exit 1) exit 1)
@ -150,12 +166,12 @@ quiet_cmd_db2html = HTML $@
cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
quiet_cmd_db2man = MAN $@ 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 %.9 : %.xml
@(which xmlto > /dev/null 2>&1) || \ @(which xmlto > /dev/null 2>&1) || \
(echo "*** You need to install xmlto ***"; \ (echo "*** You need to install xmlto ***"; \
exit 1) exit 1)
$(Q)mkdir -p $(obj)/man $(Q)mkdir -p $(obj)/man/$(*F)
$(call cmd,db2man) $(call cmd,db2man)
@touch $@ @touch $@
@ -209,15 +225,18 @@ dochelp:
### ###
# Temporary files left by various tools # Temporary files left by various tools
clean-files := $(DOCBOOKS) \ clean-files := $(DOCBOOKS) \
$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \ $(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
$(patsubst %.xml, %.aux, $(DOCBOOKS)) \ $(patsubst %.xml, %.aux, $(DOCBOOKS)) \
$(patsubst %.xml, %.tex, $(DOCBOOKS)) \ $(patsubst %.xml, %.tex, $(DOCBOOKS)) \
$(patsubst %.xml, %.log, $(DOCBOOKS)) \ $(patsubst %.xml, %.log, $(DOCBOOKS)) \
$(patsubst %.xml, %.out, $(DOCBOOKS)) \ $(patsubst %.xml, %.out, $(DOCBOOKS)) \
$(patsubst %.xml, %.ps, $(DOCBOOKS)) \ $(patsubst %.xml, %.ps, $(DOCBOOKS)) \
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \ $(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
$(patsubst %.xml, %.html, $(DOCBOOKS)) \ $(patsubst %.xml, %.html, $(DOCBOOKS)) \
$(patsubst %.xml, %.9, $(DOCBOOKS)) \ $(patsubst %.xml, %.9, $(DOCBOOKS)) \
$(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
$(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \
$(patsubst %.xml, %.xml, $(DOCBOOKS)) \
$(index) $(index)
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man

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

@ -585,7 +585,7 @@ kernel crypto API | IPSEC Layer
+-----------+ | +-----------+ |
| | (1) | | (1)
| aead | <----------------------------------- esp_output | aead | <----------------------------------- esp_output
| (seqniv) | ---+ | (seqiv) | ---+
+-----------+ | +-----------+ |
| (2) | (2)
+-----------+ | +-----------+ |
@ -1101,7 +1101,7 @@ kernel crypto API | Caller
</para> </para>
<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> </para>
</sect1> </sect1>
@ -1661,7 +1661,7 @@ read(opfd, out, outlen);
</para> </para>
<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> </para>
</sect1> </sect1>
@ -1687,7 +1687,7 @@ read(opfd, out, outlen);
!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions !Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
!Finclude/linux/crypto.h crypto_alg !Finclude/linux/crypto.h crypto_alg
!Finclude/linux/crypto.h ablkcipher_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 blkcipher_alg
!Finclude/linux/crypto.h cipher_alg !Finclude/linux/crypto.h cipher_alg
!Finclude/crypto/rng.h rng_alg !Finclude/crypto/rng.h rng_alg

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

@ -66,6 +66,7 @@
!Ekernel/time/hrtimer.c !Ekernel/time/hrtimer.c
</sect1> </sect1>
<sect1><title>Workqueues and Kevents</title> <sect1><title>Workqueues and Kevents</title>
!Iinclude/linux/workqueue.h
!Ekernel/workqueue.c !Ekernel/workqueue.c
</sect1> </sect1>
<sect1><title>Internal Functions</title> <sect1><title>Internal Functions</title>

697
Documentation/DocBook/iio.tmpl Normal file
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="funcsynopsis.tabular.threshold">80</param>
<param name="callout.graphics">0</param> <param name="callout.graphics">0</param>
<!-- <param name="paper.type">A4</param> --> <!-- <param name="paper.type">A4</param> -->
<param name="generate.consistent.ids">1</param>
<param name="generate.section.toc.level">2</param> <param name="generate.section.toc.level">2</param>
<param name="use.id.as.filename">1</param> <param name="use.id.as.filename">1</param>
</stylesheet> </stylesheet>

28
Documentation/HOWTO
View File

@ -218,16 +218,16 @@ The development process
Linux kernel development process currently consists of a few different Linux kernel development process currently consists of a few different
main kernel "branches" and lots of different subsystem-specific kernel main kernel "branches" and lots of different subsystem-specific kernel
branches. These different branches are: branches. These different branches are:
- main 3.x kernel tree - main 4.x kernel tree
- 3.x.y -stable kernel tree - 4.x.y -stable kernel tree
- 3.x -git kernel patches - 4.x -git kernel patches
- subsystem specific kernel trees and 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 4.x kernels are maintained by Linus Torvalds, and can be found on
kernel.org in the pub/linux/kernel/v3.x/ directory. Its development kernel.org in the pub/linux/kernel/v4.x/ directory. Its development
process is as follows: process is as follows:
- As soon as a new kernel is released a two weeks window is open, - 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 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 released according to perceived bug status, not according to a
preconceived timeline." preconceived timeline."
3.x.y -stable kernel tree 4.x.y -stable kernel tree
--------------------------- ---------------------------
Kernels with 3-part versions are -stable kernels. They contain Kernels with 3-part versions are -stable kernels. They contain
relatively small and critical fixes for security problems or significant 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 This is the recommended branch for users who want the most recent stable
kernel and are not interested in helping test development/experimental kernel and are not interested in helping test development/experimental
versions. 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. 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 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 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 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 documents what kinds of changes are acceptable for the -stable tree, and
how the release process works. 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 These are daily snapshots of Linus' kernel tree which are managed in a
git repository (hence the name.) These patches are usually released 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 accepted, or rejected. Most of these patchwork sites are listed at
http://patchwork.kernel.org/. 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 tree, they need to be integration-tested. For this purpose, a special
testing repository exists into which virtually all subsystem trees are testing repository exists into which virtually all subsystem trees are
pulled on an almost daily basis: 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 Some Keywords
DMAR - DMA remapping DMAR - DMA remapping
DRHD - DMA Engine Reporting Structure DRHD - DMA Remapping Hardware Unit Definition
RMRR - Reserved memory Region Reporting Structure RMRR - Reserved memory Region Reporting Structure
ZLR - Zero length reads from PCI devices ZLR - Zero length reads from PCI devices
IOVA - IO Virtual address. 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 o Avoid cancellation when using the "+" and "-" infix arithmetic
operators. For example, for a given variable "x", avoid operators. For example, for a given variable "x", avoid
"(x-x)". There are similar arithmetic pitfalls from other "(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 The compiler is within its rights to substitute zero for all of
these expressions, so that subsequent accesses no longer depend these expressions, so that subsequent accesses no longer depend
on the rcu_dereference(), again possibly resulting in bugs due 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 Stall-warning messages may be enabled and disabled completely via
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress. /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 RCU_STALL_DELAY_DELTA
Although the lockdep facility is extremely useful, it does add 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(), sort of false positive without resorting to things like stop_machine(),
which is overkill for this sort of problem. which is overkill for this sort of problem.
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set, Recent kernels will print a long form of the stall-warning message:
more information is printed with the stall-warning message, for example:
INFO: rcu_preempt detected stall on CPU INFO: rcu_preempt detected stall on CPU
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543 0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
(t=65000 jiffies) (t=65000 jiffies)
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed:
printed:
INFO: rcu_preempt detected stall on CPU 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 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. 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? What Causes RCU CPU Stall Warnings?
So your kernel printed an RCU CPU stall warning. The next question is 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: 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: 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 o "wd0", "wd1", "wd2", and "wd3" are the number of times that an
numbers differ, there is an expedited grace period in progress. attempt to start an expedited grace period found that someone
else had completed an expedited grace period that satisfies the
o "w" is the number of times that the sequence numbers have been
in danger of wrapping.
o "tf" is the number of times that contention has resulted in a
failure to begin an expedited grace period.
o "wd1" and "wd2" are the number of times that an attempt to
start an expedited grace period found that someone else had
completed an expedited grace period that satisfies the
attempted request. "Our work is done." attempted request. "Our work is done."
o "n" is number of times that contention was so great that o "n" is number of times that a concurrent CPU-hotplug operation
the request was demoted from an expedited grace period to forced a fallback to a normal grace period.
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 o "sc" is the number of times that the attempt to start a
new expedited grace period succeeded. 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: 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_access_pointer
rcu_dereference_raw rcu_dereference_raw
rcu_lockdep_assert RCU_LOCKDEP_WARN
rcu_sleep_check rcu_sleep_check
RCU_NONIDLE RCU_NONIDLE

12
Documentation/SubmittingPatches
View File

@ -90,11 +90,11 @@ patch.
Make sure your patch does not include any extra files which do not 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- 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 If your changes produce a lot of deltas, you need to split them into
individual patches which modify things in logical stages; see section 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. very important if you want your patch accepted.
If you're using git, "git rebase -i" can help you with this process. If 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 to code that they maintain; look through the MAINTAINERS file and the
source code revision history to see who those maintainers are. 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 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. 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 You should also normally choose at least one mailing list to receive a copy
@ -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 developer to be able to "quote" your changes, using standard e-mail
tools, so that they may comment on specific portions of your code. 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, WARNING: Be wary of your editor's word-wrap corrupting your patch,
if you choose to cut-n-paste 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 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 A pull request should also include an overall message saying what will be
included in the request, a "git shortlog" listing of the patches 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> <https://lkml.org/lkml/2005/7/11/336>
Kernel Documentation/CodingStyle: Kernel Documentation/CodingStyle:
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle> <Documentation/CodingStyle>
Linus Torvalds's mail on the canonical patch format: Linus Torvalds's mail on the canonical patch format:
<http://lkml.org/lkml/2005/4/7/183> <http://lkml.org/lkml/2005/4/7/183>

527
Documentation/adding-syscalls.txt Normal file
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 + Datasheet
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
- sama5d2 family
- sama5d27
+ Datasheet
Coming soon
Linux kernel information Linux kernel information
------------------------ ------------------------

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

@ -15,6 +15,7 @@ executing kernel.
1. Non-Secure mode 1. Non-Secure mode
Address: sysram_ns_base_addr Address: sysram_ns_base_addr
Offset Value Purpose Offset Value Purpose
============================================================================= =============================================================================
@ -28,6 +29,7 @@ Offset Value Purpose
2. Secure mode 2. Secure mode
Address: sysram_base_addr Address: sysram_base_addr
Offset Value Purpose Offset Value Purpose
============================================================================= =============================================================================
@ -40,14 +42,25 @@ Offset Value Purpose
Address: pmu_base_addr Address: pmu_base_addr
Offset Value Purpose 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 0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR 0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR 0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
3. Other (regardless of secure/non-secure mode) 3. Other (regardless of secure/non-secure mode)
Address: pmu_base_addr Address: pmu_base_addr
Offset Value Purpose Offset Value Purpose
============================================================================= =============================================================================
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator 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 Normal file
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

8
Documentation/clk.txt
View File

@ -71,12 +71,8 @@ the operations defined in clk.h:
long (*round_rate)(struct clk_hw *hw, long (*round_rate)(struct clk_hw *hw,
unsigned long rate, unsigned long rate,
unsigned long *parent_rate); unsigned long *parent_rate);
long (*determine_rate)(struct clk_hw *hw, int (*determine_rate)(struct clk_hw *hw,
unsigned long rate, struct clk_rate_request *req);
unsigned long min_rate,
unsigned long max_rate,
unsigned long *best_parent_rate,
struct clk_hw **best_parent_clk);
int (*set_parent)(struct clk_hw *hw, u8 index); int (*set_parent)(struct clk_hw *hw, u8 index);
u8 (*get_parent)(struct clk_hw *hw); u8 (*get_parent)(struct clk_hw *hw);
int (*set_rate)(struct clk_hw *hw, int (*set_rate)(struct clk_hw *hw,

17
Documentation/devicetree/bindings/arc/archs-pct.txt Normal file
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" o "atmel,at91sam9xe"
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific * "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
SoC family: 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: o "atmel,sama5d3" shall be extended with the specific SoC compatible:
- "atmel,sama5d31" - "atmel,sama5d31"
- "atmel,sama5d33" - "atmel,sama5d33"
@ -50,6 +52,7 @@ System Timer (ST) required properties:
- reg: Should contain registers location and length - reg: Should contain registers location and length
- interrupts: Should contain interrupt for the ST which is the IRQ line - interrupts: Should contain interrupt for the ST which is the IRQ line
shared across all System Controller members. shared across all System Controller members.
- clocks: phandle to input clock.
Its subnodes can be: Its subnodes can be:
- watchdog: compatible should be "atmel,at91rm9200-wdt" - 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 Note that you can specify several interrupt cells if the TC
block has one interrupt per channel. block has one interrupt per channel.
- clock-names: tuple listing input clock names. - clock-names: tuple listing input clock names.
Required elements: "t0_clk" Required elements: "t0_clk", "slow_clk"
Optional elements: "t1_clk", "t2_clk" Optional elements: "t1_clk", "t2_clk"
- clocks: phandles to input clocks. - clocks: phandles to input clocks.
@ -87,14 +90,16 @@ One interrupt per TC channel in a TC block:
RSTC Reset Controller required properties: RSTC Reset Controller required properties:
- compatible: Should be "atmel,<chip>-rstc". - 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 - reg: Should contain registers location and length
- clocks: phandle to input clock.
Example: Example:
rstc@fffffd00 { rstc@fffffd00 {
compatible = "atmel,at91sam9260-rstc"; compatible = "atmel,at91sam9260-rstc";
reg = <0xfffffd00 0x10>; reg = <0xfffffd00 0x10>;
clocks = <&clk32k>;
}; };
RAMC SDRAM/DDR Controller required properties: RAMC SDRAM/DDR Controller required properties:
@ -117,6 +122,7 @@ required properties:
- compatible: Should be "atmel,<chip>-shdwc". - compatible: Should be "atmel,<chip>-shdwc".
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5". <chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
- reg: Should contain registers location and length - reg: Should contain registers location and length
- clocks: phandle to input clock.
optional properties: optional properties:
- atmel,wakeup-mode: String, operation mode of the wakeup mode. - atmel,wakeup-mode: String, operation mode of the wakeup mode.
@ -135,9 +141,10 @@ optional at91sam9x5 properties:
Example: Example:
rstc@fffffd00 { shdwc@fffffd10 {
compatible = "atmel,at91sam9260-rstc"; compatible = "atmel,at91sam9260-shdwc";
reg = <0xfffffd00 0x10>; reg = <0xfffffd10 0x10>;
clocks = <&clk32k>;
}; };
Special Function Registers (SFR) Special Function Registers (SFR)

9
Documentation/devicetree/bindings/arm/bcm/ns2.txt Normal file
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 Normal file
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-tmc", "arm,primecell";
- "arm,coresight-funnel", "arm,primecell"; - "arm,coresight-funnel", "arm,primecell";
- "arm,coresight-etm3x", "arm,primecell"; - "arm,coresight-etm3x", "arm,primecell";
- "arm,coresight-etm4x", "arm,primecell";
- "qcom,coresight-replicator1x", "arm,primecell"; - "qcom,coresight-replicator1x", "arm,primecell";
* reg: physical base address and length of the register * reg: physical base address and length of the register

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

@ -127,6 +127,24 @@ Example:
#clock-cells = <1>; #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 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: board. Currently known boards are:
"buffalo,lschlv2" "buffalo,lschlv2"
"buffalo,lswvl"
"buffalo,lswxl"
"buffalo,lsxhl" "buffalo,lsxhl"
"buffalo,lsxl" "buffalo,lsxl"
"dlink,dns-320" "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: Required root node property:
compatible: Must contain one of compatible: Must contain one of
"mediatek,mt6580"
"mediatek,mt6589" "mediatek,mt6589"
"mediatek,mt6592" "mediatek,mt6592"
"mediatek,mt6795"
"mediatek,mt8127" "mediatek,mt8127"
"mediatek,mt8135" "mediatek,mt8135"
"mediatek,mt8173" "mediatek,mt8173"
@ -14,12 +17,18 @@ compatible: Must contain one of
Supported boards: Supported boards:
- Evaluation board for MT6580:
Required root node properties:
- compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
- bq Aquaris5 smart phone: - bq Aquaris5 smart phone:
Required root node properties: Required root node properties:
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589"; - compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
- Evaluation board for MT6592: - Evaluation board for MT6592:
Required root node properties: Required root node properties:
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592"; - 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: - MTK mt8127 tablet moose EVB:
Required root node properties: Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127"; - 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 Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
interrupt. interrupt.
@ -8,9 +8,11 @@ Required properties:
"mediatek,mt8173-sysirq" "mediatek,mt8173-sysirq"
"mediatek,mt8135-sysirq" "mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq" "mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
"mediatek,mt6592-sysirq" "mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq" "mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq" "mediatek,mt6582-sysirq"
"mediatek,mt6580-sysirq"
"mediatek,mt6577-sysirq" "mediatek,mt6577-sysirq"
- interrupt-controller : Identifies the node as an interrupt controller - interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Use the same format as specified by GIC in - #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 - AM335X OrionLXm : Substation Automation Platform
compatible = "novatech,am335x-lxm", "ti,am33xx" 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 - OMAP5 EVM : Evaluation Module
compatible = "ti,omap5-evm", "ti,omap5" 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: - ChipSPARK PopMetal-RK3288 board:
Required root node properties: Required root node properties:
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288"; - 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 Normal file
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 Normal file
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-sysctrl"
- "hisilicon,hi6220-mediactrl" - "hisilicon,hi6220-mediactrl"
- "hisilicon,hi6220-pmctrl" - "hisilicon,hi6220-pmctrl"
- "hisilicon,hi6220-stub-clk"
- reg: physical base address of the controller and length of memory mapped - reg: physical base address of the controller and length of memory mapped
region. region.
- #clock-cells: should be 1. - #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 { sys_ctrl: sys_ctrl@f7030000 {
compatible = "hisilicon,hi6220-sysctrl", "syscon"; compatible = "hisilicon,hi6220-sysctrl", "syscon";
reg = <0x0 0xf7030000 0x0 0x2000>; reg = <0x0 0xf7030000 0x0 0x2000>;
#clock-cells = <1>; #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 Each clock is assigned an identifier and client nodes use this identifier
to specify the clock which they consume. to specify the clock which they consume.

13
Documentation/devicetree/bindings/clock/imx6ul-clock.txt Normal file
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.

79
Documentation/devicetree/bindings/clock/nvidia,tegra124-dfll.txt Normal file
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) * Renesas R8A7778 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A7778. It includes two PLLs and 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: Required Properties:
@ -10,10 +12,18 @@ Required Properties:
- #clock-cells: Must be 1 - #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are - clock-output-names: The names of the clocks. Supported clocks are
"plla", "pllb", "b", "out", "p", "s", and "s1". "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 { cpg_clocks: cpg_clocks@ffc80000 {
compatible = "renesas,r8a7778-cpg-clocks"; compatible = "renesas,r8a7778-cpg-clocks";
@ -22,4 +32,17 @@ Example
clocks = <&extal_clk>; clocks = <&extal_clk>;
clock-output-names = "plla", "pllb", "b", clock-output-names = "plla", "pllb", "b",
"out", "p", "s", "s1"; "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) * Renesas R8A7779 Clock Pulse Generator (CPG)
The CPG generates core clocks for the R8A7779. It includes one PLL and 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: Required Properties:
@ -12,16 +14,36 @@ Required Properties:
- #clock-cells: Must be 1 - #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "plla", - clock-output-names: The names of the clocks. Supported clocks are "plla",
"z", "zs", "s", "s1", "p", "b", "out". "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 { cpg_clocks: cpg_clocks@ffc80000 {
compatible = "renesas,r8a7779-cpg-clocks"; compatible = "renesas,r8a7779-cpg-clocks";
reg = <0 0xffc80000 0 0x30>; reg = <0xffc80000 0x30>;
clocks = <&extal_clk>; clocks = <&extal_clk>;
#clock-cells = <1>; #clock-cells = <1>;
clock-output-names = "plla", "z", "zs", "s", "s1", "p", clock-output-names = "plla", "z", "zs", "s", "s1", "p",
"b", "out"; "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 The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
and several fixed ratio dividers. 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: Required Properties:
@ -20,10 +22,18 @@ Required Properties:
- clock-output-names: The names of the clocks. Supported clocks are "main", - clock-output-names: The names of the clocks. Supported clocks are "main",
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and "pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
"adsp" "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 { cpg_clocks: cpg_clocks@e6150000 {
compatible = "renesas,r8a7790-cpg-clocks", compatible = "renesas,r8a7790-cpg-clocks",
@ -34,4 +44,16 @@ Example
clock-output-names = "main", "pll0, "pll1", "pll3", clock-output-names = "main", "pll0, "pll1", "pll3",
"lb", "qspi", "sdh", "sd0", "sd1", "z", "lb", "qspi", "sdh", "sd0", "sd1", "z",
"rcan", "adsp"; "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 The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
CPU and GPU clocks, and several fixed ratio dividers. 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: Required Properties:
@ -14,10 +16,18 @@ Required Properties:
- #clock-cells: Must be 1 - #clock-cells: Must be 1
- clock-output-names: The names of the clocks. Supported clocks are "pll", - clock-output-names: The names of the clocks. Supported clocks are "pll",
"i", and "g" "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 { cpg_clocks: cpg_clocks@fcfe0000 {
#clock-cells = <1>; #clock-cells = <1>;
@ -26,4 +36,19 @@ Example
reg = <0xfcfe0000 0x18>; reg = <0xfcfe0000 0x18>;
clocks = <&extal_clk>, <&usb_x1_clk>; clocks = <&extal_clk>, <&usb_x1_clk>;
clock-output-names = "pll", "i", "g"; 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 Normal file
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,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
"st,stih407-plls-c32-a0", "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-a9", "st,clkgen-plls-c32"
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32" "sst,plls-c32-cx_0", "st,clkgen-plls-c32"
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32" "sst,plls-c32-cx_1", "st,clkgen-plls-c32"
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32" "st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32" "st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"

64
Documentation/devicetree/bindings/clock/ux500.txt Normal file
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 Normal file
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 to the interrupt parent to which the child domain
is being mapped. 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 Note: All other standard properties (see the ePAPR) are allowed
but are optional. but are optional.
@ -120,6 +132,11 @@ EXAMPLE
ranges = <0 0x300000 0x10000>; ranges = <0 0x300000 0x10000>;
interrupt-parent = <&mpic>; interrupt-parent = <&mpic>;
interrupts = <92 2>; 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 Node defines address range and the associated
interrupt for the SNVS function. This function interrupt for the SNVS function. This function
monitors security state information & reports monitors security state information & reports
security violations. security violations. This also included rtc,
system power off and ON/OFF key.
- compatible - compatible
Usage: required Usage: required
Value type: <string> Value type: <string>
Definition: Must include "fsl,sec-v4.0-mon". Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
- reg - reg
Usage: required Usage: required
@ -324,7 +342,7 @@ Secure Non-Volatile Storage (SNVS) Node
the child address, parent address, & length. the child address, parent address, & length.
- interrupts - interrupts
Usage: required Usage: optional
Value type: <prop_encoded-array> Value type: <prop_encoded-array>
Definition: Specifies the interrupts generated by this Definition: Specifies the interrupts generated by this
device. The value of the interrupts property device. The value of the interrupts property
@ -341,7 +359,7 @@ Secure Non-Volatile Storage (SNVS) Node
EXAMPLE EXAMPLE
sec_mon@314000 { sec_mon@314000 {
compatible = "fsl,sec-v4.0-mon"; compatible = "fsl,sec-v4.0-mon", "syscon";
reg = <0x314000 0x1000>; reg = <0x314000 0x1000>;
ranges = <0 0x314000 0x1000>; ranges = <0 0x314000 0x1000>;
interrupt-parent = <&mpic>; interrupt-parent = <&mpic>;
@ -358,16 +376,72 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
Value type: <string> Value type: <string>
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp". Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
- reg - interrupts
Usage: required Usage: required
Value type: <prop-encoded-array> Value type: <prop_encoded-array>
Definition: A standard property. Specifies the physical Definition: Specifies the interrupts generated by this
address and length of the SNVS LP configuration registers. 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 EXAMPLE
sec_mon_rtc_lp@314000 { sec_mon_rtc_lp@1 {
compatible = "fsl,sec-v4.0-mon-rtc-lp"; 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"; compatible = "fsl,sec-v4.0-mon";
reg = <0x314000 0x1000>; reg = <0x314000 0x1000>;
ranges = <0 0x314000 0x1000>; ranges = <0 0x314000 0x1000>;
interrupt-parent = <&mpic>;
interrupts = <93 2>;
sec_mon_rtc_lp@34 { sec_mon_rtc_lp@34 {
compatible = "fsl,sec-v4.0-mon-rtc-lp"; 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 Normal file
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";
};

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

@ -10,8 +10,11 @@ Required Properties:
Optional Properties: Optional Properties:
- ti,wakeup : To enable the wakeup comparator in probe - 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. - 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 { palmas-usb {
compatible = "ti,twl6035-usb", "ti,palmas-usb"; compatible = "ti,twl6035-usb", "ti,palmas-usb";

21
Documentation/devicetree/bindings/hwmon/lm70.txt Normal file
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: Required properties:
- compatible: should contain one of: - compatible: should contain one of:
* "lltc,ltc2974" * "lltc,ltc2974"
* "lltc,ltc2975"
* "lltc,ltc2977" * "lltc,ltc2977"
* "lltc,ltc2978" * "lltc,ltc2978"
* "lltc,ltc2980"
* "lltc,ltc3880" * "lltc,ltc3880"
* "lltc,ltc3882"
* "lltc,ltc3883" * "lltc,ltc3883"
* "lltc,ltc3886"
* "lltc,ltc3887"
* "lltc,ltm2987"
* "lltc,ltm4676" * "lltc,ltm4676"
- reg: I2C slave address - reg: I2C slave address
@ -17,10 +23,10 @@ Optional properties:
standard binding for regulators; see regulator.txt. standard binding for regulators; see regulator.txt.
Valid names of regulators depend on number of supplies supported per device: Valid names of regulators depend on number of supplies supported per device:
* ltc2974 : vout0 - vout3 * ltc2974, ltc2975 : vout0 - vout3
* ltc2977 : vout0 - vout7 * ltc2977, ltc2980, ltm2987 : vout0 - vout7
* ltc2978 : vout0 - vout7 * ltc2978 : vout0 - vout7
* ltc3880 : vout0 - vout1 * ltc3880, ltc3882, ltc3886 : vout0 - vout1
* ltc3883 : vout0 * ltc3883 : vout0
* ltm4676 : vout0 - vout1 * ltm4676 : vout0 - vout1

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

@ -18,6 +18,7 @@ Required properties:
"mcp3202" "mcp3202"
"mcp3204" "mcp3204"
"mcp3208" "mcp3208"
"mcp3301"
Examples: 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 normal mode (ADLPC=0, ADHSC=0)
- Frequency in high-speed mode (ADLPC=0, ADHSC=1) - Frequency in high-speed mode (ADLPC=0, ADHSC=1)
- Frequency in low-power mode (ADLPC=1, ADHSC=0) - 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: Example:
adc0: adc@4003b000 { adc0: adc@4003b000 {

13
Documentation/devicetree/bindings/iio/magnetometer/mmc35240.txt Normal file
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,lsm303dl-accel
- st,lsm303dlm-accel - st,lsm303dlm-accel
- st,lsm330-accel - st,lsm330-accel
- st,lsm303agr-accel
Gyroscopes: Gyroscopes:
- st,l3g4200d-gyro - st,l3g4200d-gyro
@ -46,6 +47,7 @@ Gyroscopes:
- st,lsm330-gyro - st,lsm330-gyro
Magnetometers: Magnetometers:
- st,lsm303agr-magn
- st,lsm303dlh-magn - st,lsm303dlh-magn
- st,lsm303dlhc-magn - st,lsm303dlhc-magn
- st,lsm303dlm-magn - st,lsm303dlm-magn

1
Documentation/devicetree/bindings/input/snvs-pwrkey.txt Normal file
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 controller, or the HW block containing it, is referred to occasionally
as "armctrl" in the SoC documentation, hence naming of this binding. 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: 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. - reg : Specifies base physical address and size of the registers.
- interrupt-controller : Identifies the node as an interrupt controller - interrupt-controller : Identifies the node as an interrupt controller
- #interrupt-cells : Specifies the number of cells needed to encode an - #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 The 2nd cell contains the interrupt number within the bank. Valid values
are 0..7 for bank 0, and 0..31 for bank 1. 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: The interrupt sources are as follows:
Bank 0: Bank 0:
@ -102,9 +113,21 @@ Bank 2:
Example: Example:
/* BCM2835, first level */
intc: interrupt-controller { intc: interrupt-controller {
compatible = "brcm,bcm2835-armctrl-ic"; compatible = "brcm,bcm2835-armctrl-ic";
reg = <0x7e00b200 0x200>; reg = <0x7e00b200 0x200>;
interrupt-controller; interrupt-controller;
#interrupt-cells = <2>; #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 Normal file
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>;
};

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

@ -29,14 +29,23 @@ Optional properties for child nodes:
"ide-disk" - LED indicates disk activity "ide-disk" - LED indicates disk activity
"timer" - LED flashes at a fixed, configurable rate "timer" - LED flashes at a fixed, configurable rate
- max-microamp : maximum intensity in microamperes of the LED - led-max-microamp : Maximum LED supply current in microamperes. This property
(torch LED for flash devices) can be made mandatory for the board configurations
- flash-max-microamp : maximum intensity in microamperes of the introducing a risk of hardware damage in case an excessive
flash LED; it is mandatory if the LED should current is set.
support the flash mode For flash LED controllers with configurable current this
- flash-timeout-us : timeout in microseconds after which the flash property is mandatory for the LEDs in the non-flash modes
LED is turned off (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: Examples:
@ -49,7 +58,7 @@ system-status {
camera-flash { camera-flash {
label = "Flash"; label = "Flash";
led-sources = <0>, <1>; led-sources = <0>, <1>;
max-microamp = <50000>; led-max-microamp = <50000>;
flash-max-microamp = <320000>; 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: Required sub-node properties:
- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification. - cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
- slow-gpio: Slow 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: Optional sub-node properties:
- label: Name for this LED. If omitted, the label is taken from the node name. - label: Name for this LED. If omitted, the label is taken from the node name.
@ -15,6 +18,8 @@ Optional sub-node properties:
Example: Example:
#include <dt-bindings/leds/leds-ns2.h>
ns2-leds { ns2-leds {
compatible = "lacie,ns2-leds"; compatible = "lacie,ns2-leds";
@ -22,5 +27,9 @@ ns2-leds {
label = "ns2:blue:sata"; label = "ns2:blue:sata";
slow-gpio = <&gpio0 29 0>; slow-gpio = <&gpio0 29 0>;
cmd-gpio = <&gpio0 30 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 Normal file
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 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: Required properties:
- compatible: Should be 'xlnx,zynq-ddrc-a05' - compatible: Should be 'xlnx,zynq-ddrc-a05'
- reg: Base address and size of the controllers memory area - 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 - vcc10-supply: The input supply for LDO_REG6
- vcc11-supply: The input supply for LDO_REG8 - vcc11-supply: The input supply for LDO_REG8
- vcc12-supply: The input supply for SWITCH_REG2 - 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 Regulators: All the regulators of RK808 to be instantiated shall be
listed in a child node named 'regulators'. Each regulator is represented listed in a child node named 'regulators'. Each regulator is represented
@ -55,7 +59,9 @@ Example:
interrupt-parent = <&gpio0>; interrupt-parent = <&gpio0>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>; interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "default"; 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>; reg = <0x1b>;
rockchip,system-power-controller; rockchip,system-power-controller;
wakeup-source; wakeup-source;

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" - compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
- reg: Should contain registers location and length - 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: Example for sun4i:
sid@01c23800 { sid@01c23800 {
compatible = "allwinner,sun4i-a10-sid"; compatible = "allwinner,sun4i-a10-sid";

80
Documentation/devicetree/bindings/nvmem/nvmem.txt Normal file
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 Normal file
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";
};

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

@ -23,6 +23,9 @@ PCIe Designware Controller
interrupt-map-mask, interrupt-map-mask,
interrupt-map : as specified in ../designware-pcie.txt 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: Example:
axi { axi {
compatible = "simple-bus"; compatible = "simple-bus";

26
Documentation/devicetree/bindings/phy/phy-lpc18xx-usb-otg.txt Normal file
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,sun5i-a13-usb-phy
* allwinner,sun6i-a31-usb-phy * allwinner,sun6i-a31-usb-phy
* allwinner,sun7i-a20-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 : a list of offset + length pairs
- reg-names : - reg-names :
* "phy_ctrl" * "phy_ctrl"
@ -17,12 +19,21 @@ Required properties:
- clock-names : - clock-names :
* "usb_phy" for sun4i, sun5i or sun7i * "usb_phy" for sun4i, sun5i or sun7i
* "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i * "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
* "usb0_phy", "usb1_phy" for sun8i
- resets : a list of phandle + reset specifier pairs - resets : a list of phandle + reset specifier pairs
- reset-names : - reset-names :
* "usb0_reset" * "usb0_reset"
* "usb1_reset" * "usb1_reset"
* "usb2_reset" for sun4i, sun6i or sun7i * "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: Example:
usbphy: phy@0x01c13400 { usbphy: phy@0x01c13400 {
#phy-cells = <1>; #phy-cells = <1>;
@ -32,6 +43,13 @@ Example:
reg-names = "phy_ctrl", "pmu1", "pmu2"; reg-names = "phy_ctrl", "pmu1", "pmu2";
clocks = <&usb_clk 8>; clocks = <&usb_clk 8>;
clock-names = "usb_phy"; clock-names = "usb_phy";
resets = <&usb_clk 1>, <&usb_clk 2>; resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
reset-names = "usb1_reset", "usb2_reset"; 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>;
}; };

36
Documentation/devicetree/bindings/pinctrl/fsl,imx6ul-pinctrl.txt Normal file
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)

48
Documentation/devicetree/bindings/power/qcom,coincell-charger.txt Normal file
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>;
};
};

24
Documentation/devicetree/bindings/powerpc/fsl/mpc5121-psc.txt
View File

@ -6,14 +6,14 @@ PSC in UART mode
For PSC in UART mode the needed PSC serial devices For PSC in UART mode the needed PSC serial devices
are specified by fsl,mpc5121-psc-uart nodes in the are specified by fsl,mpc5121-psc-uart nodes in the
fsl,mpc5121-immr SoC node. Additionally the PSC FIFO fsl,mpc5121-immr SoC node. Additionally the PSC FIFO
Controller node fsl,mpc5121-psc-fifo is requered there: Controller node fsl,mpc5121-psc-fifo is required there:
fsl,mpc5121-psc-uart nodes fsl,mpc512x-psc-uart nodes
-------------------------- --------------------------
Required properties : Required properties :
- compatible : Should contain "fsl,mpc5121-psc-uart" and "fsl,mpc5121-psc" - compatible : Should contain "fsl,<soc>-psc-uart" and "fsl,<soc>-psc"
- cell-index : Index of the PSC in hardware Supported <soc>s: mpc5121, mpc5125
- reg : Offset and length of the register set for the PSC device - reg : Offset and length of the register set for the PSC device
- interrupts : <a b> where a is the interrupt number of the - interrupts : <a b> where a is the interrupt number of the
PSC FIFO Controller and b is a field that represents an PSC FIFO Controller and b is a field that represents an
@ -25,12 +25,21 @@ Recommended properties :
- fsl,rx-fifo-size : the size of the RX fifo slice (a multiple of 4) - fsl,rx-fifo-size : the size of the RX fifo slice (a multiple of 4)
- fsl,tx-fifo-size : the size of the TX fifo slice (a multiple of 4) - fsl,tx-fifo-size : the size of the TX fifo slice (a multiple of 4)
PSC in SPI mode
---------------
fsl,mpc5121-psc-fifo node Similar to the UART mode a PSC can be operated in SPI mode. The compatible used
for that is fsl,mpc5121-psc-spi. It requires a fsl,mpc5121-psc-fifo as well.
The required and recommended properties are identical to the
fsl,mpc5121-psc-uart nodes, just use spi instead of uart in the compatible
string.
fsl,mpc512x-psc-fifo node
------------------------- -------------------------
Required properties : Required properties :
- compatible : Should be "fsl,mpc5121-psc-fifo" - compatible : Should be "fsl,<soc>-psc-fifo"
Supported <soc>s: mpc5121, mpc5125
- reg : Offset and length of the register set for the PSC - reg : Offset and length of the register set for the PSC
FIFO Controller FIFO Controller
- interrupts : <a b> where a is the interrupt number of the - interrupts : <a b> where a is the interrupt number of the
@ -39,6 +48,9 @@ Required properties :
- interrupt-parent : the phandle for the interrupt controller that - interrupt-parent : the phandle for the interrupt controller that
services interrupts for this device. services interrupts for this device.
Recommended properties :
- clocks : specifies the clock needed to operate the fifo controller
- clock-names : name(s) for the clock(s) listed in clocks
Example for a board using PSC0 and PSC1 devices in serial mode: Example for a board using PSC0 and PSC1 devices in serial mode:

4
Documentation/devicetree/bindings/regulator/da9210.txt
View File

@ -5,6 +5,10 @@ Required properties:
- compatible: must be "dlg,da9210" - compatible: must be "dlg,da9210"
- reg: the i2c slave address of the regulator. It should be 0x68. - reg: the i2c slave address of the regulator. It should be 0x68.
Optional properties:
- interrupts: a reference to the DA9210 interrupt, if available.
Any standard regulator properties can be used to configure the single da9210 Any standard regulator properties can be used to configure the single da9210
DCDC. DCDC.

32
Documentation/devicetree/bindings/regulator/da9211.txt
View File

@ -1,7 +1,7 @@
* Dialog Semiconductor DA9211/DA9213 Voltage Regulator * Dialog Semiconductor DA9211/DA9213/DA9215 Voltage Regulator
Required properties: Required properties:
- compatible: "dlg,da9211" or "dlg,da9213". - compatible: "dlg,da9211" or "dlg,da9213" or "dlg,da9215"
- reg: I2C slave address, usually 0x68. - reg: I2C slave address, usually 0x68.
- interrupts: the interrupt outputs of the controller - interrupts: the interrupt outputs of the controller
- regulators: A node that houses a sub-node for each regulator within the - regulators: A node that houses a sub-node for each regulator within the
@ -66,3 +66,31 @@ Example 2) DA9213
}; };
}; };
}; };
Example 3) DA9215
pmic: da9215@68 {
compatible = "dlg,da9215";
reg = <0x68>;
interrupts = <3 27>;
regulators {
BUCKA {
regulator-name = "VBUCKA";
regulator-min-microvolt = < 300000>;
regulator-max-microvolt = <1570000>;
regulator-min-microamp = <4000000>;
regulator-max-microamp = <7000000>;
enable-gpios = <&gpio 27 0>;
};
BUCKB {
regulator-name = "VBUCKB";
regulator-min-microvolt = < 300000>;
regulator-max-microvolt = <1570000>;
regulator-min-microamp = <4000000>;
regulator-max-microamp = <7000000>;
enable-gpios = <&gpio 17 0>;
};
};
};

6
Documentation/devicetree/bindings/regulator/max8973-regulator.txt
View File

@ -25,6 +25,12 @@ Optional properties:
-maxim,enable-frequency-shift: boolean, enable 9% frequency shift. -maxim,enable-frequency-shift: boolean, enable 9% frequency shift.
-maxim,enable-bias-control: boolean, enable bias control. By enabling this -maxim,enable-bias-control: boolean, enable bias control. By enabling this
startup delay can be reduce to 20us from 220us. startup delay can be reduce to 20us from 220us.
-maxim,enable-etr: boolean, enable Enhanced Transient Response.
-maxim,enable-high-etr-sensitivity: boolean, Enhanced transient response
circuit is enabled and set for high sensitivity. If this
property is available then etr will be enable default.
Enhanced transient response (ETR) will affect the configuration of CKADV.
Example: Example:

35
Documentation/devicetree/bindings/regulator/mt6311-regulator.txt Normal file
View File

@ -0,0 +1,35 @@
Mediatek MT6311 Regulator Driver
Required properties:
- compatible: "mediatek,mt6311-regulator"
- reg: I2C slave address, usually 0x6b.
- regulators: List of regulators provided by this controller. It is named
to VDVFS and VBIASN.
The definition for each of these nodes is defined using the standard binding
for regulators at Documentation/devicetree/bindings/regulator/regulator.txt.
The valid names for regulators are:
BUCK:
VDVFS
LDO:
VBIASN
Example:
mt6311: pmic@6b {
compatible = "mediatek,mt6311-regulator";
reg = <0x6b>;
regulators {
mt6311_vcpu_reg: VDVFS {
regulator-name = "VDVFS";
regulator-min-microvolt = < 600000>;
regulator-max-microvolt = <1400000>;
regulator-ramp-delay = <10000>;
};
mt6311_ldo_reg: VBIASN {
regulator-name = "VBIASN";
regulator-min-microvolt = <200000>;
regulator-max-microvolt = <800000>;
};
};
};

65
Documentation/devicetree/bindings/regulator/pwm-regulator.txt
View File

@ -1,27 +1,68 @@
pwm regulator bindings Bindings for the Generic PWM Regulator
======================================
Currently supports 2 modes of operation:
Voltage Table: When in this mode, a voltage table (See below) of
predefined voltage <=> duty-cycle values must be
provided via DT. Limitations are that the regulator can
only operate at the voltages supplied in the table.
Intermediary duty-cycle values which would normally
allow finer grained voltage selection are ignored and
rendered useless. Although more control is given to
the user if the assumptions made in continuous-voltage
mode do not reign true.
Continuous Voltage: This mode uses the regulator's maximum and minimum
supplied voltages specified in the
regulator-{min,max}-microvolt properties to calculate
appropriate duty-cycle values. This allows for a much
more fine grained solution when compared with
voltage-table mode above. This solution does make an
assumption that a %50 duty-cycle value will cause the
regulator voltage to run at half way between the
supplied max_uV and min_uV values.
Required properties: Required properties:
- compatible: Should be "pwm-regulator" --------------------
- pwms: OF device-tree PWM specification (see PWM binding pwm.txt) - compatible: Should be "pwm-regulator"
- voltage-table: voltage and duty table, include 2 members in each set of
brackets, first one is voltage(unit: uv), the next is duty(unit: percent)
Any property defined as part of the core regulator binding defined in - pwms: PWM specification (See: ../pwm/pwm.txt)
regulator.txt can also be used.
Example: Only required for Voltage Table Mode:
- voltage-table: Voltage and Duty-Cycle table consisting of 2 cells
First cell is voltage in microvolts (uV)
Second cell is duty-cycle in percent (%)
NB: To be clear, if voltage-table is provided, then the device will be used
in Voltage Table Mode. If no voltage-table is provided, then the device will
be used in Continuous Voltage Mode.
Any property defined as part of the core regulator binding can also be used.
(See: ../regulator/regulator.txt)
Continuous Voltage Example:
pwm_regulator { pwm_regulator {
compatible = "pwm-regulator; compatible = "pwm-regulator;
pwms = <&pwm1 0 8448 0>; pwms = <&pwm1 0 8448 0>;
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
regulator-name = "vdd_logic";
};
Voltage Table Example:
pwm_regulator {
compatible = "pwm-regulator;
pwms = <&pwm1 0 8448 0>;
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
regulator-name = "vdd_logic";
/* Voltage Duty-Cycle */
voltage-table = <1114000 0>, voltage-table = <1114000 0>,
<1095000 10>, <1095000 10>,
<1076000 20>, <1076000 20>,
<1056000 30>, <1056000 30>,
<1036000 40>, <1036000 40>,
<1016000 50>; <1016000 50>;
regulator-min-microvolt = <1016000>;
regulator-max-microvolt = <1114000>;
regulator-name = "vdd_logic";
}; };

60
Documentation/devicetree/bindings/regulator/qcom,spmi-regulator.txt
View File

@ -91,13 +91,65 @@ see regulator.txt - with additional custom properties described below:
- regulator-initial-mode: - regulator-initial-mode:
Usage: optional Usage: optional
Value type: <u32> Value type: <u32>
Descrption: 1 = Set initial mode to high power mode (HPM), also referred Description: 2 = Set initial mode to auto mode (automatically select
to as NPM. HPM consumes more ground current than LPM, but between HPM and LPM); not available on boost type
regulators.
1 = Set initial mode to high power mode (HPM), also referred
to as NPM. HPM consumes more ground current than LPM, but
it can source significantly higher load current. HPM is not it can source significantly higher load current. HPM is not
available on boost type regulators. For voltage switch type available on boost type regulators. For voltage switch type
regulators, HPM implies that over current protection and regulators, HPM implies that over current protection and
soft start are active all the time. 0 = Set initial mode to soft start are active all the time.
low power mode (LPM).
0 = Set initial mode to low power mode (LPM).
- qcom,ocp-max-retries:
Usage: optional
Value type: <u32>
Description: Maximum number of times to try toggling a voltage switch
off and back on as a result of consecutive over current
events.
- qcom,ocp-retry-delay:
Usage: optional
Value type: <u32>
Description: Time to delay in milliseconds between each voltage switch
toggle after an over current event takes place.
- qcom,pin-ctrl-enable:
Usage: optional
Value type: <u32>
Description: Bit mask specifying which hardware pins should be used to
enable the regulator, if any; supported bits are:
0 = ignore all hardware enable signals
BIT(0) = follow HW0_EN signal
BIT(1) = follow HW1_EN signal
BIT(2) = follow HW2_EN signal
BIT(3) = follow HW3_EN signal
- qcom,pin-ctrl-hpm:
Usage: optional
Value type: <u32>
Description: Bit mask specifying which hardware pins should be used to
force the regulator into high power mode, if any;
supported bits are:
0 = ignore all hardware enable signals
BIT(0) = follow HW0_EN signal
BIT(1) = follow HW1_EN signal
BIT(2) = follow HW2_EN signal
BIT(3) = follow HW3_EN signal
BIT(4) = follow PMIC awake state
- qcom,vs-soft-start-strength:
Usage: optional
Value type: <u32>
Description: This property sets the soft start strength for voltage
switch type regulators; supported values are:
0 = 0.05 uA
1 = 0.25 uA
2 = 0.55 uA
3 = 0.75 uA
Example: Example:

1
Documentation/devicetree/bindings/regulator/regulator.txt
View File

@ -42,6 +42,7 @@ Optional properties:
- regulator-system-load: Load in uA present on regulator that is not captured by - regulator-system-load: Load in uA present on regulator that is not captured by
any consumer request. any consumer request.
- regulator-pull-down: Enable pull down resistor when the regulator is disabled. - regulator-pull-down: Enable pull down resistor when the regulator is disabled.
- regulator-over-current-protection: Enable over current protection.
Deprecated properties: Deprecated properties:
- regulator-compatible: If a regulator chip contains multiple - regulator-compatible: If a regulator chip contains multiple

20
Documentation/devicetree/bindings/reset/ath79-reset.txt Normal file
View File

@ -0,0 +1,20 @@
Binding for Qualcomm Atheros AR7xxx/AR9XXX reset controller
Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required Properties:
- compatible: has to be "qca,<soctype>-reset", "qca,ar7100-reset"
as fallback
- reg: Base address and size of the controllers memory area
- #reset-cells : Specifies the number of cells needed to encode reset
line, should be 1
Example:
reset-controller@1806001c {
compatible = "qca,ar9132-reset", "qca,ar7100-reset";
reg = <0x1806001c 0x4>;
#reset-cells = <1>;
};

84
Documentation/devicetree/bindings/reset/nxp,lpc1850-rgu.txt Normal file
View File

@ -0,0 +1,84 @@
NXP LPC1850 Reset Generation Unit (RGU)
========================================
Please also refer to reset.txt in this directory for common reset
controller binding usage.
Required properties:
- compatible: Should be "nxp,lpc1850-rgu"
- reg: register base and length
- clocks: phandle and clock specifier to RGU clocks
- clock-names: should contain "delay" and "reg"
- #reset-cells: should be 1
See table below for valid peripheral reset numbers. Numbers not
in the table below are either reserved or not applicable for
normal operation.
Reset Peripheral
9 System control unit (SCU)
12 ARM Cortex-M0 subsystem core (LPC43xx only)
13 CPU core
16 LCD controller
17 USB0
18 USB1
19 DMA
20 SDIO
21 External memory controller (EMC)
22 Ethernet
25 Flash bank A
27 EEPROM
28 GPIO
29 Flash bank B
32 Timer0
33 Timer1
34 Timer2
35 Timer3
36 Repetitive Interrupt timer (RIT)
37 State Configurable Timer (SCT)
38 Motor control PWM (MCPWM)
39 QEI
40 ADC0
41 ADC1
42 DAC
44 USART0
45 UART1
46 USART2
47 USART3
48 I2C0
49 I2C1
50 SSP0
51 SSP1
52 I2S0 and I2S1
53 Serial Flash Interface (SPIFI)
54 C_CAN1
55 C_CAN0
56 ARM Cortex-M0 application core (LPC4370 only)
57 SGPIO (LPC43xx only)
58 SPI (LPC43xx only)
60 ADCHS (12-bit ADC) (LPC4370 only)
Refer to NXP LPC18xx or LPC43xx user manual for more details about
the reset signals and the connected block/peripheral.
Reset provider example:
rgu: reset-controller@40053000 {
compatible = "nxp,lpc1850-rgu";
reg = <0x40053000 0x1000>;
clocks = <&cgu BASE_SAFE_CLK>, <&ccu1 CLK_CPU_BUS>;
clock-names = "delay", "reg";
#reset-cells = <1>;
};
Reset consumer example:
mac: ethernet@40010000 {
compatible = "nxp,lpc1850-dwmac", "snps,dwmac-3.611", "snps,dwmac";
reg = <0x40010000 0x2000>;
interrupts = <5>;
interrupt-names = "macirq";
clocks = <&ccu1 CLK_CPU_ETHERNET>;
clock-names = "stmmaceth";
resets = <&rgu 22>;
reset-names = "stmmaceth";
status = "disabled";
};

2
Documentation/devicetree/bindings/reset/socfpga-reset.txt
View File

@ -3,6 +3,7 @@ Altera SOCFPGA Reset Manager
Required properties: Required properties:
- compatible : "altr,rst-mgr" - compatible : "altr,rst-mgr"
- reg : Should contain 1 register ranges(address and length) - reg : Should contain 1 register ranges(address and length)
- altr,modrst-offset : Should contain the offset of the first modrst register.
- #reset-cells: 1 - #reset-cells: 1
Example: Example:
@ -10,4 +11,5 @@ Example:
#reset-cells = <1>; #reset-cells = <1>;
compatible = "altr,rst-mgr"; compatible = "altr,rst-mgr";
reg = <0xffd05000 0x1000>; reg = <0xffd05000 0x1000>;
altr,modrst-offset = <0x10>;
}; };

2
Documentation/devicetree/bindings/reset/st,sti-picophyreset.txt
View File

@ -39,4 +39,4 @@ Example:
}; };
Macro definitions for the supported reset channels can be found in: Macro definitions for the supported reset channels can be found in:
include/dt-bindings/reset-controller/stih407-resets.h include/dt-bindings/reset/stih407-resets.h

4
Documentation/devicetree/bindings/reset/st,sti-powerdown.txt
View File

@ -43,5 +43,5 @@ example:
Macro definitions for the supported reset channels can be found in: Macro definitions for the supported reset channels can be found in:
include/dt-bindings/reset-controller/stih415-resets.h include/dt-bindings/reset/stih415-resets.h
include/dt-bindings/reset-controller/stih416-resets.h include/dt-bindings/reset/stih416-resets.h

4
Documentation/devicetree/bindings/reset/st,sti-softreset.txt
View File

@ -42,5 +42,5 @@ example:
Macro definitions for the supported reset channels can be found in: Macro definitions for the supported reset channels can be found in:
include/dt-bindings/reset-controller/stih415-resets.h include/dt-bindings/reset/stih415-resets.h
include/dt-bindings/reset-controller/stih416-resets.h include/dt-bindings/reset/stih416-resets.h

68
Documentation/devicetree/bindings/reset/zynq-reset.txt Normal file
View File

@ -0,0 +1,68 @@
Xilinx Zynq Reset Manager
The Zynq AP-SoC has several different resets.
See Chapter 26 of the Zynq TRM (UG585) for more information about Zynq resets.
Required properties:
- compatible: "xlnx,zynq-reset"
- reg: SLCR offset and size taken via syscon <0x200 0x48>
- syscon: <&slcr>
This should be a phandle to the Zynq's SLCR registers.
- #reset-cells: Must be 1
The Zynq Reset Manager needs to be a childnode of the SLCR.
Example:
rstc: rstc@200 {
compatible = "xlnx,zynq-reset";
reg = <0x200 0x48>;
#reset-cells = <1>;
syscon = <&slcr>;
};
Reset outputs:
0 : soft reset
32 : ddr reset
64 : topsw reset
96 : dmac reset
128: usb0 reset
129: usb1 reset
160: gem0 reset
161: gem1 reset
164: gem0 rx reset
165: gem1 rx reset
166: gem0 ref reset
167: gem1 ref reset
192: sdio0 reset
193: sdio1 reset
196: sdio0 ref reset
197: sdio1 ref reset
224: spi0 reset
225: spi1 reset
226: spi0 ref reset
227: spi1 ref reset
256: can0 reset
257: can1 reset
258: can0 ref reset
259: can1 ref reset
288: i2c0 reset
289: i2c1 reset
320: uart0 reset
321: uart1 reset
322: uart0 ref reset
323: uart1 ref reset
352: gpio reset
384: lqspi reset
385: qspi ref reset
416: smc reset
417: smc ref reset
448: ocm reset
512: fpga0 out reset
513: fpga1 out reset
514: fpga2 out reset
515: fpga3 out reset
544: a9 reset 0
545: a9 reset 1
552: peri reset

2
Documentation/devicetree/bindings/rtc/atmel,at91rm9200-rtc.txt
View File

@ -5,6 +5,7 @@ Required properties:
- reg: physical base address of the controller and length of memory mapped - reg: physical base address of the controller and length of memory mapped
region. region.
- interrupts: rtc alarm/event interrupt - interrupts: rtc alarm/event interrupt
- clocks: phandle to input clock.
Example: Example:
@ -12,4 +13,5 @@ rtc@fffffe00 {
compatible = "atmel,at91rm9200-rtc"; compatible = "atmel,at91rm9200-rtc";
reg = <0xfffffe00 0x100>; reg = <0xfffffe00 0x100>;
interrupts = <1 4 7>; interrupts = <1 4 7>;
clocks = <&clk32k>;
}; };

26
Documentation/devicetree/bindings/rtc/rtc-mxc.txt Normal file
View File

@ -0,0 +1,26 @@
* Real Time Clock of the i.MX SoCs
RTC controller for the i.MX SoCs
Required properties:
- compatible: Should be "fsl,imx1-rtc" or "fsl,imx21-rtc".
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: IRQ line for the RTC.
- clocks: should contain two entries:
* one for the input reference
* one for the the SoC RTC
- clock-names: should contain:
* "ref" for the input reference clock
* "ipg" for the SoC RTC clock
Example:
rtc@10007000 {
compatible = "fsl,imx21-rtc";
reg = <0x10007000 0x1000>;
interrupts = <22>;
clocks = <&clks IMX27_CLK_CKIL>,
<&clks IMX27_CLK_RTC_IPG_GATE>;
clock-names = "ref", "ipg";
};

1
Documentation/devicetree/bindings/rtc/rtc-omap.txt
View File

@ -8,6 +8,7 @@ Required properties:
Wakeup generation for event Alarm. It can also be Wakeup generation for event Alarm. It can also be
used to control an external PMIC via the used to control an external PMIC via the
pmic_power_en pin. pmic_power_en pin.
- "ti,am4372-rtc" - for RTC IP used similar to that on AM437X SoC family.
- reg: Address range of rtc register set - reg: Address range of rtc register set
- interrupts: rtc timer, alarm interrupts in order - interrupts: rtc timer, alarm interrupts in order
- interrupt-parent: phandle for the interrupt controller - interrupt-parent: phandle for the interrupt controller

3
Documentation/devicetree/bindings/serial/atmel-usart.txt
View File

@ -22,6 +22,8 @@ Optional properties:
memory peripheral interface and USART DMA channel ID, FIFO configuration. memory peripheral interface and USART DMA channel ID, FIFO configuration.
Refer to dma.txt and atmel-dma.txt for details. Refer to dma.txt and atmel-dma.txt for details.
- dma-names: "rx" for RX channel, "tx" for TX channel. - dma-names: "rx" for RX channel, "tx" for TX channel.
- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO
capable USARTs.
<chip> compatible description: <chip> compatible description:
- at91rm9200: legacy USART support - at91rm9200: legacy USART support
@ -57,4 +59,5 @@ Example:
dmas = <&dma0 2 0x3>, dmas = <&dma0 2 0x3>,
<&dma0 2 0x204>; <&dma0 2 0x204>;
dma-names = "tx", "rx"; dma-names = "tx", "rx";
atmel,fifo-size = <32>;
}; };

6
Documentation/devicetree/bindings/serial/axis,etraxfs-uart.txt
View File

@ -6,7 +6,7 @@ Required properties:
- interrupts: device interrupt - interrupts: device interrupt
Optional properties: Optional properties:
- {dtr,dsr,ri,cd}-gpios: specify a GPIO for DTR/DSR/RI/CD - {dtr,dsr,rng,dcd}-gpios: specify a GPIO for DTR/DSR/RI/DCD
line respectively. line respectively.
Example: Example:
@ -16,4 +16,8 @@ serial@b00260000 {
reg = <0xb0026000 0x1000>; reg = <0xb0026000 0x1000>;
interrupts = <68>; interrupts = <68>;
status = "disabled"; status = "disabled";
dtr-gpios = <&sysgpio 0 GPIO_ACTIVE_LOW>;
dsr-gpios = <&sysgpio 1 GPIO_ACTIVE_LOW>;
rng-gpios = <&sysgpio 2 GPIO_ACTIVE_LOW>;
dcd-gpios = <&sysgpio 3 GPIO_ACTIVE_LOW>;
}; };

6
Documentation/devicetree/bindings/serial/mtk-uart.txt
View File

@ -5,10 +5,12 @@ Required properties:
* "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8135-uart" for MT8135 compatible UARTS
* "mediatek,mt8127-uart" for MT8127 compatible UARTS * "mediatek,mt8127-uart" for MT8127 compatible UARTS
* "mediatek,mt8173-uart" for MT8173 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS
* "mediatek,mt6795-uart" for MT6795 compatible UARTS
* "mediatek,mt6589-uart" for MT6589 compatible UARTS * "mediatek,mt6589-uart" for MT6589 compatible UARTS
* "mediatek,mt6582-uart" for MT6582 compatible UARTS * "mediatek,mt6582-uart" for MT6582 compatible UARTS
* "mediatek,mt6577-uart" for all compatible UARTS (MT8173, MT6589, MT6582, * "mediatek,mt6580-uart" for MT6580 compatible UARTS
MT6577) * "mediatek,mt6577-uart" for all compatible UARTS (MT8173, MT6795,
MT6589, MT6582, MT6580, MT6577)
- reg: The base address of the UART register bank. - reg: The base address of the UART register bank.

3
Documentation/devicetree/bindings/serial/omap_serial.txt
View File

@ -4,6 +4,9 @@ Required properties:
- compatible : should be "ti,omap2-uart" for OMAP2 controllers - compatible : should be "ti,omap2-uart" for OMAP2 controllers
- compatible : should be "ti,omap3-uart" for OMAP3 controllers - compatible : should be "ti,omap3-uart" for OMAP3 controllers
- compatible : should be "ti,omap4-uart" for OMAP4 controllers - compatible : should be "ti,omap4-uart" for OMAP4 controllers
- compatible : should be "ti,am4372-uart" for AM437x controllers
- compatible : should be "ti,am3352-uart" for AM335x controllers
- compatible : should be "ti,dra742-uart" for DRA7x controllers
- reg : address and length of the register space - reg : address and length of the register space
- interrupts or interrupts-extended : Should contain the uart interrupt - interrupts or interrupts-extended : Should contain the uart interrupt
specifier or both the interrupt specifier or both the interrupt

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