Merge branch 'linus' into x86/urgent, to be able to merge a dependent fix
Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
Коммит
95cd2ea7d5
|
|
@ -0,0 +1 @@
|
|||
Christoph Hellwig <hch@lst.de>
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
What: /sys/bus/vmbus/devices/vmbus_*/id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus child_relid of the device's primary channel
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/class_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface type GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/device_id
|
||||
Date: Jul 2009
|
||||
KernelVersion: 2.6.31
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The VMBus interface instance GUID of the device
|
||||
Users: tools/hv/lsvmbus
|
||||
|
||||
What: /sys/bus/vmbus/devices/vmbus_*/channel_vp_mapping
|
||||
Date: Jul 2015
|
||||
KernelVersion: 4.2.0
|
||||
Contact: K. Y. Srinivasan <kys@microsoft.com>
|
||||
Description: The mapping of which primary/sub channels are bound to which
|
||||
Virtual Processors.
|
||||
Format: <channel's child_relid:the bound cpu's number>
|
||||
Users: tools/hv/lsvmbus
|
||||
|
|
@ -5,4 +5,4 @@ Description:
|
|||
The attributes:
|
||||
|
||||
qlen - depth of loopback queue
|
||||
bulk_buflen - buffer length
|
||||
buflen - buffer length
|
||||
|
|
|
|||
|
|
@ -9,4 +9,4 @@ Description:
|
|||
isoc_maxpacket - 0 - 1023 (fs), 0 - 1024 (hs/ss)
|
||||
isoc_mult - 0..2 (hs/ss only)
|
||||
isoc_maxburst - 0..15 (ss only)
|
||||
qlen - buffer length
|
||||
buflen - buffer length
|
||||
|
|
|
|||
|
|
@ -112,7 +112,7 @@ KernelVersion: 3.19
|
|||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (RW) Mask to apply to all the context ID comparator.
|
||||
|
||||
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_val
|
||||
What: /sys/bus/coresight/devices/<memory_map>.[etm|ptm]/ctxid_pid
|
||||
Date: November 2014
|
||||
KernelVersion: 3.19
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
|
|
|
|||
|
|
@ -249,7 +249,7 @@ KernelVersion: 4.01
|
|||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
Description: (RW) Select which context ID comparator to work with.
|
||||
|
||||
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_val
|
||||
What: /sys/bus/coresight/devices/<memory_map>.etm/ctxid_pid
|
||||
Date: April 2015
|
||||
KernelVersion: 4.01
|
||||
Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
|
||||
|
|
|
|||
|
|
@ -413,6 +413,11 @@ Description:
|
|||
to compute the calories burnt by the user.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_accel_scale_available
|
||||
What: /sys/.../iio:deviceX/in_anglvel_scale_available
|
||||
What: /sys/.../iio:deviceX/in_magn_scale_available
|
||||
What: /sys/.../iio:deviceX/in_illuminance_scale_available
|
||||
What: /sys/.../iio:deviceX/in_intensity_scale_available
|
||||
What: /sys/.../iio:deviceX/in_proximity_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltageX_scale_available
|
||||
What: /sys/.../iio:deviceX/in_voltage-voltage_scale_available
|
||||
What: /sys/.../iio:deviceX/out_voltageX_scale_available
|
||||
|
|
@ -488,7 +493,7 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
Specifies the output powerdown mode.
|
||||
DAC output stage is disconnected from the amplifier and
|
||||
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
|
||||
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
|
||||
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
|
||||
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
|
||||
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
|
||||
|
|
@ -498,9 +503,9 @@ Description:
|
|||
outX_powerdown_mode_available. If Y is not present the
|
||||
mode is shared across all outputs.
|
||||
|
||||
What: /sys/.../iio:deviceX/out_votlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_voltageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_voltage_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvotlageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltageY_powerdown_mode_available
|
||||
What: /sys/.../iio:deviceX/out_altvoltage_powerdown_mode_available
|
||||
KernelVersion: 2.6.38
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
@ -1035,13 +1040,6 @@ Contact: linux-iio@vger.kernel.org
|
|||
Description:
|
||||
Number of scans contained by the buffer.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/bytes_per_datum
|
||||
KernelVersion: 2.6.37
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Bytes per scan. Due to alignment fun, the scan may be larger
|
||||
than implied directly by the scan_element parameters.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
|
||||
KernelVersion: 2.6.35
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
|
|
|
|||
|
|
@ -9,3 +9,12 @@ Description:
|
|||
automated testing or in situations, where other trigger methods
|
||||
are not applicable. For example no RTC or spare GPIOs.
|
||||
X is the IIO index of the trigger.
|
||||
|
||||
What: /sys/bus/iio/devices/triggerX/name
|
||||
KernelVersion: 2.6.39
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The name attribute holds a description string for the current
|
||||
trigger. In order to associate the trigger with an IIO device
|
||||
one should write this name string to
|
||||
/sys/bus/iio/devices/iio:deviceY/trigger/current_trigger.
|
||||
|
|
|
|||
|
|
@ -114,6 +114,20 @@ Description:
|
|||
enabled for the device. Developer can write y/Y/1 or n/N/0 to
|
||||
the file to enable/disable the feature.
|
||||
|
||||
What: /sys/bus/usb/devices/.../power/usb3_hardware_lpm
|
||||
Date: June 2015
|
||||
Contact: Kevin Strasser <kevin.strasser@linux.intel.com>
|
||||
Description:
|
||||
If CONFIG_PM is set and a USB 3.0 lpm-capable device is plugged
|
||||
in to a xHCI host which supports link PM, it will check if U1
|
||||
and U2 exit latencies have been set in the BOS descriptor; if
|
||||
the check is is passed and the host supports USB3 hardware LPM,
|
||||
USB3 hardware LPM will be enabled for the device and the USB
|
||||
device directory will contain a file named
|
||||
power/usb3_hardware_lpm. The file holds a string value (enable
|
||||
or disable) indicating whether or not USB3 hardware LPM is
|
||||
enabled for the device.
|
||||
|
||||
What: /sys/bus/usb/devices/.../removable
|
||||
Date: February 2012
|
||||
Contact: Matthew Garrett <mjg@redhat.com>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,45 @@
|
|||
What: /sys/class/power_supply/twl4030_ac/max_current
|
||||
/sys/class/power_supply/twl4030_usb/max_current
|
||||
Description:
|
||||
Read/Write limit on current which may
|
||||
be drawn from the ac (Accessory Charger) or
|
||||
USB port.
|
||||
|
||||
Value is in micro-Amps.
|
||||
|
||||
Value is set automatically to an appropriate
|
||||
value when a cable is plugged or unplugged.
|
||||
|
||||
Value can the set by writing to the attribute.
|
||||
The change will only persist until the next
|
||||
plug event. These event are reported via udev.
|
||||
|
||||
|
||||
What: /sys/class/power_supply/twl4030_usb/mode
|
||||
Description:
|
||||
Changing mode for USB port.
|
||||
Writing to this can disable charging.
|
||||
|
||||
Possible values are:
|
||||
"auto" - draw power as appropriate for detected
|
||||
power source and battery status.
|
||||
"off" - do not draw any power.
|
||||
"continuous"
|
||||
- activate mode described as "linear" in
|
||||
TWL data sheets. This uses whatever
|
||||
current is available and doesn't switch off
|
||||
when voltage drops.
|
||||
|
||||
This is useful for unstable power sources
|
||||
such as bicycle dynamo, but care should
|
||||
be taken that battery is not over-charged.
|
||||
|
||||
What: /sys/class/power_supply/twl4030_ac/mode
|
||||
Description:
|
||||
Changing mode for 'ac' port.
|
||||
Writing to this can disable charging.
|
||||
|
||||
Possible values are:
|
||||
"auto" - draw power as appropriate for detected
|
||||
power source and battery status.
|
||||
"off" - do not draw any power.
|
||||
|
|
@ -1,22 +0,0 @@
|
|||
What: /sys/devices/*/<our-device>/eeprom
|
||||
Date: August 2013
|
||||
Contact: Oliver Schinagl <oliver@schinagl.nl>
|
||||
Description: read-only access to the SID (Security-ID) on current
|
||||
A-series SoC's from Allwinner. Currently supports A10, A10s, A13
|
||||
and A20 CPU's. The earlier A1x series of SoCs exports 16 bytes,
|
||||
whereas the newer A20 SoC exposes 512 bytes split into sections.
|
||||
Besides the 16 bytes of SID, there's also an SJTAG area,
|
||||
HDMI-HDCP key and some custom keys. Below a quick overview, for
|
||||
details see the user manual:
|
||||
0x000 128 bit root-key (sun[457]i)
|
||||
0x010 128 bit boot-key (sun7i)
|
||||
0x020 64 bit security-jtag-key (sun7i)
|
||||
0x028 16 bit key configuration (sun7i)
|
||||
0x02b 16 bit custom-vendor-key (sun7i)
|
||||
0x02c 320 bit low general key (sun7i)
|
||||
0x040 32 bit read-control access (sun7i)
|
||||
0x064 224 bit low general key (sun7i)
|
||||
0x080 2304 bit HDCP-key (sun7i)
|
||||
0x1a0 768 bit high general key (sun7i)
|
||||
Users: any user space application which wants to read the SID on
|
||||
Allwinner's A-series of CPU's.
|
||||
|
|
@ -929,13 +929,11 @@ The C Programming Language, Second Edition
|
|||
by Brian W. Kernighan and Dennis M. Ritchie.
|
||||
Prentice Hall, Inc., 1988.
|
||||
ISBN 0-13-110362-8 (paperback), 0-13-110370-9 (hardback).
|
||||
URL: http://cm.bell-labs.com/cm/cs/cbook/
|
||||
|
||||
The Practice of Programming
|
||||
by Brian W. Kernighan and Rob Pike.
|
||||
Addison-Wesley, Inc., 1999.
|
||||
ISBN 0-201-61586-X.
|
||||
URL: http://cm.bell-labs.com/cm/cs/tpop/
|
||||
|
||||
GNU manuals - where in compliance with K&R and this text - for cpp, gcc,
|
||||
gcc internals and indent, all available from http://www.gnu.org/manual/
|
||||
|
|
|
|||
|
|
@ -15,7 +15,7 @@ DOCBOOKS := z8530book.xml device-drivers.xml \
|
|||
80211.xml debugobjects.xml sh.xml regulator.xml \
|
||||
alsa-driver-api.xml writing-an-alsa-driver.xml \
|
||||
tracepoint.xml drm.xml media_api.xml w1.xml \
|
||||
writing_musb_glue_layer.xml crypto-API.xml
|
||||
writing_musb_glue_layer.xml crypto-API.xml iio.xml
|
||||
|
||||
include Documentation/DocBook/media/Makefile
|
||||
|
||||
|
|
@ -56,16 +56,19 @@ htmldocs: $(HTML)
|
|||
|
||||
MAN := $(patsubst %.xml, %.9, $(BOOKS))
|
||||
mandocs: $(MAN)
|
||||
find $(obj)/man -name '*.9' | xargs gzip -f
|
||||
find $(obj)/man -name '*.9' | xargs gzip -nf
|
||||
|
||||
installmandocs: mandocs
|
||||
mkdir -p /usr/local/man/man9/
|
||||
install $(obj)/man/*.9.gz /usr/local/man/man9/
|
||||
find $(obj)/man -name '*.9.gz' -printf '%h %f\n' | \
|
||||
sort -k 2 -k 1 | uniq -f 1 | sed -e 's: :/:' | \
|
||||
xargs install -m 644 -t /usr/local/man/man9/
|
||||
|
||||
###
|
||||
#External programs used
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
|
||||
XMLTOFLAGS = -m $(srctree)/$(src)/stylesheet.xsl
|
||||
XMLTOFLAGS += --skip-validation
|
||||
|
|
@ -89,7 +92,7 @@ define rule_docproc
|
|||
) > $(dir $@).$(notdir $@).cmd
|
||||
endef
|
||||
|
||||
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) FORCE
|
||||
%.xml: %.tmpl $(KERNELDOC) $(DOCPROC) $(KERNELDOCXMLREF) FORCE
|
||||
$(call if_changed_rule,docproc)
|
||||
|
||||
# Tell kbuild to always build the programs
|
||||
|
|
@ -140,7 +143,20 @@ quiet_cmd_db2html = HTML $@
|
|||
echo '<a HREF="$(patsubst %.html,%,$(notdir $@))/index.html"> \
|
||||
$(patsubst %.html,%,$(notdir $@))</a><p>' > $@
|
||||
|
||||
%.html: %.xml
|
||||
###
|
||||
# Rules to create an aux XML and .db, and use them to re-process the DocBook XML
|
||||
# to fill internal hyperlinks
|
||||
gen_aux_xml = :
|
||||
quiet_gen_aux_xml = echo ' XMLREF $@'
|
||||
silent_gen_aux_xml = :
|
||||
%.aux.xml: %.xml
|
||||
@$($(quiet)gen_aux_xml)
|
||||
@rm -rf $@
|
||||
@(cat $< | egrep "^<refentry id" | egrep -o "\".*\"" | cut -f 2 -d \" > $<.db)
|
||||
@$(KERNELDOCXMLREF) -db $<.db $< > $@
|
||||
.PRECIOUS: %.aux.xml
|
||||
|
||||
%.html: %.aux.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
exit 1)
|
||||
|
|
@ -150,12 +166,12 @@ quiet_cmd_db2html = HTML $@
|
|||
cp $(PNG-$(basename $(notdir $@))) $(patsubst %.html,%,$@); fi
|
||||
|
||||
quiet_cmd_db2man = MAN $@
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man $< ; fi
|
||||
cmd_db2man = if grep -q refentry $<; then xmlto man $(XMLTOFLAGS) -o $(obj)/man/$(*F) $< ; fi
|
||||
%.9 : %.xml
|
||||
@(which xmlto > /dev/null 2>&1) || \
|
||||
(echo "*** You need to install xmlto ***"; \
|
||||
exit 1)
|
||||
$(Q)mkdir -p $(obj)/man
|
||||
$(Q)mkdir -p $(obj)/man/$(*F)
|
||||
$(call cmd,db2man)
|
||||
@touch $@
|
||||
|
||||
|
|
@ -209,15 +225,18 @@ dochelp:
|
|||
###
|
||||
# Temporary files left by various tools
|
||||
clean-files := $(DOCBOOKS) \
|
||||
$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.tex, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.log, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.out, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.ps, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.dvi, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.tex, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.log, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.out, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.ps, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.pdf, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.html, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.9, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.aux.xml, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.xml.db, $(DOCBOOKS)) \
|
||||
$(patsubst %.xml, %.xml, $(DOCBOOKS)) \
|
||||
$(index)
|
||||
|
||||
clean-dirs := $(patsubst %.xml,%,$(DOCBOOKS)) man
|
||||
|
|
|
|||
|
|
@ -585,7 +585,7 @@ kernel crypto API | IPSEC Layer
|
|||
+-----------+ |
|
||||
| | (1)
|
||||
| aead | <----------------------------------- esp_output
|
||||
| (seqniv) | ---+
|
||||
| (seqiv) | ---+
|
||||
+-----------+ |
|
||||
| (2)
|
||||
+-----------+ |
|
||||
|
|
@ -1101,7 +1101,7 @@ kernel crypto API | Caller
|
|||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
[1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -1661,7 +1661,7 @@ read(opfd, out, outlen);
|
|||
</para>
|
||||
|
||||
<para>
|
||||
[1] http://www.chronox.de/libkcapi.html
|
||||
[1] <ulink url="http://www.chronox.de/libkcapi.html">http://www.chronox.de/libkcapi.html</ulink>
|
||||
</para>
|
||||
|
||||
</sect1>
|
||||
|
|
@ -1687,7 +1687,7 @@ read(opfd, out, outlen);
|
|||
!Pinclude/linux/crypto.h Block Cipher Algorithm Definitions
|
||||
!Finclude/linux/crypto.h crypto_alg
|
||||
!Finclude/linux/crypto.h ablkcipher_alg
|
||||
!Finclude/linux/crypto.h aead_alg
|
||||
!Finclude/crypto/aead.h aead_alg
|
||||
!Finclude/linux/crypto.h blkcipher_alg
|
||||
!Finclude/linux/crypto.h cipher_alg
|
||||
!Finclude/crypto/rng.h rng_alg
|
||||
|
|
|
|||
|
|
@ -66,6 +66,7 @@
|
|||
!Ekernel/time/hrtimer.c
|
||||
</sect1>
|
||||
<sect1><title>Workqueues and Kevents</title>
|
||||
!Iinclude/linux/workqueue.h
|
||||
!Ekernel/workqueue.c
|
||||
</sect1>
|
||||
<sect1><title>Internal Functions</title>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,697 @@
|
|||
<?xml version="1.0" encoding="UTF-8"?>
|
||||
<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.1.2/docbookx.dtd" []>
|
||||
|
||||
<book id="iioid">
|
||||
<bookinfo>
|
||||
<title>Industrial I/O driver developer's guide </title>
|
||||
|
||||
<authorgroup>
|
||||
<author>
|
||||
<firstname>Daniel</firstname>
|
||||
<surname>Baluta</surname>
|
||||
<affiliation>
|
||||
<address>
|
||||
<email>daniel.baluta@intel.com</email>
|
||||
</address>
|
||||
</affiliation>
|
||||
</author>
|
||||
</authorgroup>
|
||||
|
||||
<copyright>
|
||||
<year>2015</year>
|
||||
<holder>Intel Corporation</holder>
|
||||
</copyright>
|
||||
|
||||
<legalnotice>
|
||||
<para>
|
||||
This documentation is free software; you can redistribute
|
||||
it and/or modify it under the terms of the GNU General Public
|
||||
License version 2.
|
||||
</para>
|
||||
</legalnotice>
|
||||
</bookinfo>
|
||||
|
||||
<toc></toc>
|
||||
|
||||
<chapter id="intro">
|
||||
<title>Introduction</title>
|
||||
<para>
|
||||
The main purpose of the Industrial I/O subsystem (IIO) is to provide
|
||||
support for devices that in some sense perform either analog-to-digital
|
||||
conversion (ADC) or digital-to-analog conversion (DAC) or both. The aim
|
||||
is to fill the gap between the somewhat similar hwmon and input
|
||||
subsystems.
|
||||
Hwmon is directed at low sample rate sensors used to monitor and
|
||||
control the system itself, like fan speed control or temperature
|
||||
measurement. Input is, as its name suggests, focused on human interaction
|
||||
input devices (keyboard, mouse, touchscreen). In some cases there is
|
||||
considerable overlap between these and IIO.
|
||||
</para>
|
||||
<para>
|
||||
Devices that fall into this category include:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
analog to digital converters (ADCs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
accelerometers
|
||||
</listitem>
|
||||
<listitem>
|
||||
capacitance to digital converters (CDCs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
digital to analog converters (DACs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
gyroscopes
|
||||
</listitem>
|
||||
<listitem>
|
||||
inertial measurement units (IMUs)
|
||||
</listitem>
|
||||
<listitem>
|
||||
color and light sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
magnetometers
|
||||
</listitem>
|
||||
<listitem>
|
||||
pressure sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
proximity sensors
|
||||
</listitem>
|
||||
<listitem>
|
||||
temperature sensors
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Usually these sensors are connected via SPI or I2C. A common use case of the
|
||||
sensors devices is to have combined functionality (e.g. light plus proximity
|
||||
sensor).
|
||||
</para>
|
||||
</chapter>
|
||||
<chapter id='iiosubsys'>
|
||||
<title>Industrial I/O core</title>
|
||||
<para>
|
||||
The Industrial I/O core offers:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
a unified framework for writing drivers for many different types of
|
||||
embedded sensors.
|
||||
</listitem>
|
||||
<listitem>
|
||||
a standard interface to user space applications manipulating sensors.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
The implementation can be found under <filename>
|
||||
drivers/iio/industrialio-*</filename>
|
||||
</para>
|
||||
<sect1 id="iiodevice">
|
||||
<title> Industrial I/O devices </title>
|
||||
|
||||
!Finclude/linux/iio/iio.h iio_dev
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_alloc
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_free
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_register
|
||||
!Fdrivers/iio/industrialio-core.c iio_device_unregister
|
||||
|
||||
<para>
|
||||
An IIO device usually corresponds to a single hardware sensor and it
|
||||
provides all the information needed by a driver handling a device.
|
||||
Let's first have a look at the functionality embedded in an IIO
|
||||
device then we will show how a device driver makes use of an IIO
|
||||
device.
|
||||
</para>
|
||||
<para>
|
||||
There are two ways for a user space application to interact
|
||||
with an IIO driver.
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/</filename>, this
|
||||
represents a hardware sensor and groups together the data
|
||||
channels of the same chip.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/dev/iio:deviceX</filename>, character device node
|
||||
interface used for buffered data transfer and for events information
|
||||
retrieval.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
A typical IIO driver will register itself as an I2C or SPI driver and will
|
||||
create two routines, <function> probe </function> and <function> remove
|
||||
</function>. At <function>probe</function>:
|
||||
<itemizedlist>
|
||||
<listitem>call <function>iio_device_alloc</function>, which allocates memory
|
||||
for an IIO device.
|
||||
</listitem>
|
||||
<listitem> initialize IIO device fields with driver specific information
|
||||
(e.g. device name, device channels).
|
||||
</listitem>
|
||||
<listitem>call <function> iio_device_register</function>, this registers the
|
||||
device with the IIO core. After this call the device is ready to accept
|
||||
requests from user space applications.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
At <function>remove</function>, we free the resources allocated in
|
||||
<function>probe</function> in reverse order:
|
||||
<itemizedlist>
|
||||
<listitem><function>iio_device_unregister</function>, unregister the device
|
||||
from the IIO core.
|
||||
</listitem>
|
||||
<listitem><function>iio_device_free</function>, free the memory allocated
|
||||
for the IIO device.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<sect2 id="iioattr"> <title> IIO device sysfs interface </title>
|
||||
<para>
|
||||
Attributes are sysfs files used to expose chip info and also allowing
|
||||
applications to set various configuration parameters. For device
|
||||
with index X, attributes can be found under
|
||||
<filename>/sys/bus/iio/iio:deviceX/ </filename> directory.
|
||||
Common attributes are:
|
||||
<itemizedlist>
|
||||
<listitem><filename>name</filename>, description of the physical
|
||||
chip.
|
||||
</listitem>
|
||||
<listitem><filename>dev</filename>, shows the major:minor pair
|
||||
associated with <filename>/dev/iio:deviceX</filename> node.
|
||||
</listitem>
|
||||
<listitem><filename>sampling_frequency_available</filename>,
|
||||
available discrete set of sampling frequency values for
|
||||
device.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Available standard attributes for IIO devices are described in the
|
||||
<filename>Documentation/ABI/testing/sysfs-bus-iio </filename> file
|
||||
in the Linux kernel sources.
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="iiochannel"> <title> IIO device channels </title>
|
||||
!Finclude/linux/iio/iio.h iio_chan_spec structure.
|
||||
<para>
|
||||
An IIO device channel is a representation of a data channel. An
|
||||
IIO device can have one or multiple channels. For example:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
a thermometer sensor has one channel representing the
|
||||
temperature measurement.
|
||||
</listitem>
|
||||
<listitem>
|
||||
a light sensor with two channels indicating the measurements in
|
||||
the visible and infrared spectrum.
|
||||
</listitem>
|
||||
<listitem>
|
||||
an accelerometer can have up to 3 channels representing
|
||||
acceleration on X, Y and Z axes.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
An IIO channel is described by the <type> struct iio_chan_spec
|
||||
</type>. A thermometer driver for the temperature sensor in the
|
||||
example above would have to describe its channel as follows:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec temp_channel[] = {
|
||||
{
|
||||
.type = IIO_TEMP,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
|
||||
},
|
||||
};
|
||||
|
||||
</programlisting>
|
||||
Channel sysfs attributes exposed to userspace are specified in
|
||||
the form of <emphasis>bitmasks</emphasis>. Depending on their
|
||||
shared info, attributes can be set in one of the following masks:
|
||||
<itemizedlist>
|
||||
<listitem><emphasis>info_mask_separate</emphasis>, attributes will
|
||||
be specific to this channel</listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_type</emphasis>,
|
||||
attributes are shared by all channels of the same type</listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_dir</emphasis>, attributes
|
||||
are shared by all channels of the same direction </listitem>
|
||||
<listitem><emphasis>info_mask_shared_by_all</emphasis>,
|
||||
attributes are shared by all channels</listitem>
|
||||
</itemizedlist>
|
||||
When there are multiple data channels per channel type we have two
|
||||
ways to distinguish between them:
|
||||
<itemizedlist>
|
||||
<listitem> set <emphasis> .modified</emphasis> field of <type>
|
||||
iio_chan_spec</type> to 1. Modifiers are specified using
|
||||
<emphasis>.channel2</emphasis> field of the same
|
||||
<type>iio_chan_spec</type> structure and are used to indicate a
|
||||
physically unique characteristic of the channel such as its direction
|
||||
or spectral response. For example, a light sensor can have two channels,
|
||||
one for infrared light and one for both infrared and visible light.
|
||||
</listitem>
|
||||
<listitem> set <emphasis>.indexed </emphasis> field of
|
||||
<type>iio_chan_spec</type> to 1. In this case the channel is
|
||||
simply another instance with an index specified by the
|
||||
<emphasis>.channel</emphasis> field.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
Here is how we can make use of the channel's modifiers:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec light_channels[] = {
|
||||
{
|
||||
.type = IIO_INTENSITY,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_LIGHT_IR,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
{
|
||||
.type = IIO_INTENSITY,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_LIGHT_BOTH,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
{
|
||||
.type = IIO_LIGHT,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_PROCESSED),
|
||||
.info_mask_shared = BIT(IIO_CHAN_INFO_SAMP_FREQ),
|
||||
},
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
This channel's definition will generate two separate sysfs files
|
||||
for raw data retrieval:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_intensity_ir_raw</filename>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_intensity_both_raw</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
one file for processed data:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/in_illuminance_input
|
||||
</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
and one shared sysfs file for sampling frequency:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/iio:deviceX/sampling_frequency.
|
||||
</filename>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
<para>
|
||||
Here is how we can make use of the channel's indexing:
|
||||
<programlisting>
|
||||
static const struct iio_chan_spec light_channels[] = {
|
||||
{
|
||||
.type = IIO_VOLTAGE,
|
||||
.indexed = 1,
|
||||
.channel = 0,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
},
|
||||
{
|
||||
.type = IIO_VOLTAGE,
|
||||
.indexed = 1,
|
||||
.channel = 1,
|
||||
.info_mask_separate = BIT(IIO_CHAN_INFO_RAW),
|
||||
},
|
||||
}
|
||||
</programlisting>
|
||||
This will generate two separate attributes files for raw data
|
||||
retrieval:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/in_voltage0_raw</filename>,
|
||||
representing voltage measurement for channel 0.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/in_voltage1_raw</filename>,
|
||||
representing voltage measurement for channel 1.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="iiobuffer"> <title> Industrial I/O buffers </title>
|
||||
!Finclude/linux/iio/buffer.h iio_buffer
|
||||
!Edrivers/iio/industrialio-buffer.c
|
||||
|
||||
<para>
|
||||
The Industrial I/O core offers a way for continuous data capture
|
||||
based on a trigger source. Multiple data channels can be read at once
|
||||
from <filename>/dev/iio:deviceX</filename> character device node,
|
||||
thus reducing the CPU load.
|
||||
</para>
|
||||
|
||||
<sect2 id="iiobuffersysfs">
|
||||
<title>IIO buffer sysfs interface </title>
|
||||
<para>
|
||||
An IIO buffer has an associated attributes directory under <filename>
|
||||
/sys/bus/iio/iio:deviceX/buffer/</filename>. Here are the existing
|
||||
attributes:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<emphasis>length</emphasis>, the total number of data samples
|
||||
(capacity) that can be stored by the buffer.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>enable</emphasis>, activate buffer capture.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
</para>
|
||||
</sect2>
|
||||
<sect2 id="iiobuffersetup"> <title> IIO buffer setup </title>
|
||||
<para>The meta information associated with a channel reading
|
||||
placed in a buffer is called a <emphasis> scan element </emphasis>.
|
||||
The important bits configuring scan elements are exposed to
|
||||
userspace applications via the <filename>
|
||||
/sys/bus/iio/iio:deviceX/scan_elements/</filename> directory. This
|
||||
file contains attributes of the following form:
|
||||
<itemizedlist>
|
||||
<listitem><emphasis>enable</emphasis>, used for enabling a channel.
|
||||
If and only if its attribute is non zero, then a triggered capture
|
||||
will contain data samples for this channel.
|
||||
</listitem>
|
||||
<listitem><emphasis>type</emphasis>, description of the scan element
|
||||
data storage within the buffer and hence the form in which it is
|
||||
read from user space. Format is <emphasis>
|
||||
[be|le]:[s|u]bits/storagebitsXrepeat[>>shift] </emphasis>.
|
||||
<itemizedlist>
|
||||
<listitem> <emphasis>be</emphasis> or <emphasis>le</emphasis>, specifies
|
||||
big or little endian.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>s </emphasis>or <emphasis>u</emphasis>, specifies if
|
||||
signed (2's complement) or unsigned.
|
||||
</listitem>
|
||||
<listitem><emphasis>bits</emphasis>, is the number of valid data
|
||||
bits.
|
||||
</listitem>
|
||||
<listitem><emphasis>storagebits</emphasis>, is the number of bits
|
||||
(after padding) that it occupies in the buffer.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>shift</emphasis>, if specified, is the shift that needs
|
||||
to be applied prior to masking out unused bits.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>repeat</emphasis>, specifies the number of bits/storagebits
|
||||
repetitions. When the repeat element is 0 or 1, then the repeat
|
||||
value is omitted.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
For example, a driver for a 3-axis accelerometer with 12 bit
|
||||
resolution where data is stored in two 8-bits registers as
|
||||
follows:
|
||||
<programlisting>
|
||||
7 6 5 4 3 2 1 0
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|D3 |D2 |D1 |D0 | X | X | X | X | (LOW byte, address 0x06)
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|
||||
7 6 5 4 3 2 1 0
|
||||
+---+---+---+---+---+---+---+---+
|
||||
|D11|D10|D9 |D8 |D7 |D6 |D5 |D4 | (HIGH byte, address 0x07)
|
||||
+---+---+---+---+---+---+---+---+
|
||||
</programlisting>
|
||||
|
||||
will have the following scan element type for each axis:
|
||||
<programlisting>
|
||||
$ cat /sys/bus/iio/devices/iio:device0/scan_elements/in_accel_y_type
|
||||
le:s12/16>>4
|
||||
</programlisting>
|
||||
A user space application will interpret data samples read from the
|
||||
buffer as two byte little endian signed data, that needs a 4 bits
|
||||
right shift before masking out the 12 valid bits of data.
|
||||
</para>
|
||||
<para>
|
||||
For implementing buffer support a driver should initialize the following
|
||||
fields in <type>iio_chan_spec</type> definition:
|
||||
<programlisting>
|
||||
struct iio_chan_spec {
|
||||
/* other members */
|
||||
int scan_index
|
||||
struct {
|
||||
char sign;
|
||||
u8 realbits;
|
||||
u8 storagebits;
|
||||
u8 shift;
|
||||
u8 repeat;
|
||||
enum iio_endian endianness;
|
||||
} scan_type;
|
||||
};
|
||||
</programlisting>
|
||||
The driver implementing the accelerometer described above will
|
||||
have the following channel definition:
|
||||
<programlisting>
|
||||
struct struct iio_chan_spec accel_channels[] = {
|
||||
{
|
||||
.type = IIO_ACCEL,
|
||||
.modified = 1,
|
||||
.channel2 = IIO_MOD_X,
|
||||
/* other stuff here */
|
||||
.scan_index = 0,
|
||||
.scan_type = {
|
||||
.sign = 's',
|
||||
.realbits = 12,
|
||||
.storgebits = 16,
|
||||
.shift = 4,
|
||||
.endianness = IIO_LE,
|
||||
},
|
||||
}
|
||||
/* similar for Y (with channel2 = IIO_MOD_Y, scan_index = 1)
|
||||
* and Z (with channel2 = IIO_MOD_Z, scan_index = 2) axis
|
||||
*/
|
||||
}
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Here <emphasis> scan_index </emphasis> defines the order in which
|
||||
the enabled channels are placed inside the buffer. Channels with a lower
|
||||
scan_index will be placed before channels with a higher index. Each
|
||||
channel needs to have a unique scan_index.
|
||||
</para>
|
||||
<para>
|
||||
Setting scan_index to -1 can be used to indicate that the specific
|
||||
channel does not support buffered capture. In this case no entries will
|
||||
be created for the channel in the scan_elements directory.
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1 id="iiotrigger"> <title> Industrial I/O triggers </title>
|
||||
!Finclude/linux/iio/trigger.h iio_trigger
|
||||
!Edrivers/iio/industrialio-trigger.c
|
||||
<para>
|
||||
In many situations it is useful for a driver to be able to
|
||||
capture data based on some external event (trigger) as opposed
|
||||
to periodically polling for data. An IIO trigger can be provided
|
||||
by a device driver that also has an IIO device based on hardware
|
||||
generated events (e.g. data ready or threshold exceeded) or
|
||||
provided by a separate driver from an independent interrupt
|
||||
source (e.g. GPIO line connected to some external system, timer
|
||||
interrupt or user space writing a specific file in sysfs). A
|
||||
trigger may initiate data capture for a number of sensors and
|
||||
also it may be completely unrelated to the sensor itself.
|
||||
</para>
|
||||
|
||||
<sect2 id="iiotrigsysfs"> <title> IIO trigger sysfs interface </title>
|
||||
There are two locations in sysfs related to triggers:
|
||||
<itemizedlist>
|
||||
<listitem><filename>/sys/bus/iio/devices/triggerY</filename>,
|
||||
this file is created once an IIO trigger is registered with
|
||||
the IIO core and corresponds to trigger with index Y. Because
|
||||
triggers can be very different depending on type there are few
|
||||
standard attributes that we can describe here:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<emphasis>name</emphasis>, trigger name that can be later
|
||||
used for association with a device.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<emphasis>sampling_frequency</emphasis>, some timer based
|
||||
triggers use this attribute to specify the frequency for
|
||||
trigger calls.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>/sys/bus/iio/devices/iio:deviceX/trigger/</filename>, this
|
||||
directory is created once the device supports a triggered
|
||||
buffer. We can associate a trigger with our device by writing
|
||||
the trigger's name in the <filename>current_trigger</filename> file.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iiotrigattr"> <title> IIO trigger setup</title>
|
||||
|
||||
<para>
|
||||
Let's see a simple example of how to setup a trigger to be used
|
||||
by a driver.
|
||||
|
||||
<programlisting>
|
||||
struct iio_trigger_ops trigger_ops = {
|
||||
.set_trigger_state = sample_trigger_state,
|
||||
.validate_device = sample_validate_device,
|
||||
}
|
||||
|
||||
struct iio_trigger *trig;
|
||||
|
||||
/* first, allocate memory for our trigger */
|
||||
trig = iio_trigger_alloc(dev, "trig-%s-%d", name, idx);
|
||||
|
||||
/* setup trigger operations field */
|
||||
trig->ops = &trigger_ops;
|
||||
|
||||
/* now register the trigger with the IIO core */
|
||||
iio_trigger_register(trig);
|
||||
</programlisting>
|
||||
</para>
|
||||
</sect2>
|
||||
|
||||
<sect2 id="iiotrigsetup"> <title> IIO trigger ops</title>
|
||||
!Finclude/linux/iio/trigger.h iio_trigger_ops
|
||||
<para>
|
||||
Notice that a trigger has a set of operations attached:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<function>set_trigger_state</function>, switch the trigger on/off
|
||||
on demand.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<function>validate_device</function>, function to validate the
|
||||
device when the current trigger gets changed.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</sect2>
|
||||
</sect1>
|
||||
<sect1 id="iiotriggered_buffer">
|
||||
<title> Industrial I/O triggered buffers </title>
|
||||
<para>
|
||||
Now that we know what buffers and triggers are let's see how they
|
||||
work together.
|
||||
</para>
|
||||
<sect2 id="iiotrigbufsetup"> <title> IIO triggered buffer setup</title>
|
||||
!Edrivers/iio/industrialio-triggered-buffer.c
|
||||
!Finclude/linux/iio/iio.h iio_buffer_setup_ops
|
||||
|
||||
|
||||
<para>
|
||||
A typical triggered buffer setup looks like this:
|
||||
<programlisting>
|
||||
const struct iio_buffer_setup_ops sensor_buffer_setup_ops = {
|
||||
.preenable = sensor_buffer_preenable,
|
||||
.postenable = sensor_buffer_postenable,
|
||||
.postdisable = sensor_buffer_postdisable,
|
||||
.predisable = sensor_buffer_predisable,
|
||||
};
|
||||
|
||||
irqreturn_t sensor_iio_pollfunc(int irq, void *p)
|
||||
{
|
||||
pf->timestamp = iio_get_time_ns();
|
||||
return IRQ_WAKE_THREAD;
|
||||
}
|
||||
|
||||
irqreturn_t sensor_trigger_handler(int irq, void *p)
|
||||
{
|
||||
u16 buf[8];
|
||||
int i = 0;
|
||||
|
||||
/* read data for each active channel */
|
||||
for_each_set_bit(bit, active_scan_mask, masklength)
|
||||
buf[i++] = sensor_get_data(bit)
|
||||
|
||||
iio_push_to_buffers_with_timestamp(indio_dev, buf, timestamp);
|
||||
|
||||
iio_trigger_notify_done(trigger);
|
||||
return IRQ_HANDLED;
|
||||
}
|
||||
|
||||
/* setup triggered buffer, usually in probe function */
|
||||
iio_triggered_buffer_setup(indio_dev, sensor_iio_polfunc,
|
||||
sensor_trigger_handler,
|
||||
sensor_buffer_setup_ops);
|
||||
</programlisting>
|
||||
</para>
|
||||
The important things to notice here are:
|
||||
<itemizedlist>
|
||||
<listitem><function> iio_buffer_setup_ops</function>, the buffer setup
|
||||
functions to be called at predefined points in the buffer configuration
|
||||
sequence (e.g. before enable, after disable). If not specified, the
|
||||
IIO core uses the default <type>iio_triggered_buffer_setup_ops</type>.
|
||||
</listitem>
|
||||
<listitem><function>sensor_iio_pollfunc</function>, the function that
|
||||
will be used as top half of poll function. It should do as little
|
||||
processing as possible, because it runs in interrupt context. The most
|
||||
common operation is recording of the current timestamp and for this reason
|
||||
one can use the IIO core defined <function>iio_pollfunc_store_time
|
||||
</function> function.
|
||||
</listitem>
|
||||
<listitem><function>sensor_trigger_handler</function>, the function that
|
||||
will be used as bottom half of the poll function. This runs in the
|
||||
context of a kernel thread and all the processing takes place here.
|
||||
It usually reads data from the device and stores it in the internal
|
||||
buffer together with the timestamp recorded in the top half.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
<chapter id='iioresources'>
|
||||
<title> Resources </title>
|
||||
IIO core may change during time so the best documentation to read is the
|
||||
source code. There are several locations where you should look:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<filename>drivers/iio/</filename>, contains the IIO core plus
|
||||
and directories for each sensor type (e.g. accel, magnetometer,
|
||||
etc.)
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>include/linux/iio/</filename>, contains the header
|
||||
files, nice to read for the internal kernel interfaces.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>include/uapi/linux/iio/</filename>, contains files to be
|
||||
used by user space applications.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>tools/iio/</filename>, contains tools for rapidly
|
||||
testing buffers, events and device creation.
|
||||
</listitem>
|
||||
<listitem>
|
||||
<filename>drivers/staging/iio/</filename>, contains code for some
|
||||
drivers or experimental features that are not yet mature enough
|
||||
to be moved out.
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
Besides the code, there are some good online documentation sources:
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<ulink url="http://marc.info/?l=linux-iio"> Industrial I/O mailing
|
||||
list </ulink>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<ulink url="http://wiki.analog.com/software/linux/docs/iio/iio">
|
||||
Analog Device IIO wiki page </ulink>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<ulink url="https://fosdem.org/2015/schedule/event/iiosdr/">
|
||||
Using the Linux IIO framework for SDR, Lars-Peter Clausen's
|
||||
presentation at FOSDEM </ulink>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
</para>
|
||||
</chapter>
|
||||
</book>
|
||||
|
||||
<!--
|
||||
vim: softtabstop=2:shiftwidth=2:expandtab:textwidth=72
|
||||
-->
|
||||
|
|
@ -5,6 +5,7 @@
|
|||
<param name="funcsynopsis.tabular.threshold">80</param>
|
||||
<param name="callout.graphics">0</param>
|
||||
<!-- <param name="paper.type">A4</param> -->
|
||||
<param name="generate.consistent.ids">1</param>
|
||||
<param name="generate.section.toc.level">2</param>
|
||||
<param name="use.id.as.filename">1</param>
|
||||
</stylesheet>
|
||||
|
|
|
|||
|
|
@ -218,16 +218,16 @@ The development process
|
|||
Linux kernel development process currently consists of a few different
|
||||
main kernel "branches" and lots of different subsystem-specific kernel
|
||||
branches. These different branches are:
|
||||
- main 3.x kernel tree
|
||||
- 3.x.y -stable kernel tree
|
||||
- 3.x -git kernel patches
|
||||
- main 4.x kernel tree
|
||||
- 4.x.y -stable kernel tree
|
||||
- 4.x -git kernel patches
|
||||
- subsystem specific kernel trees and patches
|
||||
- the 3.x -next kernel tree for integration tests
|
||||
- the 4.x -next kernel tree for integration tests
|
||||
|
||||
3.x kernel tree
|
||||
4.x kernel tree
|
||||
-----------------
|
||||
3.x kernels are maintained by Linus Torvalds, and can be found on
|
||||
kernel.org in the pub/linux/kernel/v3.x/ directory. Its development
|
||||
4.x kernels are maintained by Linus Torvalds, and can be found on
|
||||
kernel.org in the pub/linux/kernel/v4.x/ directory. Its development
|
||||
process is as follows:
|
||||
- As soon as a new kernel is released a two weeks window is open,
|
||||
during this period of time maintainers can submit big diffs to
|
||||
|
|
@ -262,20 +262,20 @@ mailing list about kernel releases:
|
|||
released according to perceived bug status, not according to a
|
||||
preconceived timeline."
|
||||
|
||||
3.x.y -stable kernel tree
|
||||
4.x.y -stable kernel tree
|
||||
---------------------------
|
||||
Kernels with 3-part versions are -stable kernels. They contain
|
||||
relatively small and critical fixes for security problems or significant
|
||||
regressions discovered in a given 3.x kernel.
|
||||
regressions discovered in a given 4.x kernel.
|
||||
|
||||
This is the recommended branch for users who want the most recent stable
|
||||
kernel and are not interested in helping test development/experimental
|
||||
versions.
|
||||
|
||||
If no 3.x.y kernel is available, then the highest numbered 3.x
|
||||
If no 4.x.y kernel is available, then the highest numbered 4.x
|
||||
kernel is the current stable kernel.
|
||||
|
||||
3.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
|
||||
4.x.y are maintained by the "stable" team <stable@vger.kernel.org>, and
|
||||
are released as needs dictate. The normal release period is approximately
|
||||
two weeks, but it can be longer if there are no pressing problems. A
|
||||
security-related problem, instead, can cause a release to happen almost
|
||||
|
|
@ -285,7 +285,7 @@ The file Documentation/stable_kernel_rules.txt in the kernel tree
|
|||
documents what kinds of changes are acceptable for the -stable tree, and
|
||||
how the release process works.
|
||||
|
||||
3.x -git patches
|
||||
4.x -git patches
|
||||
------------------
|
||||
These are daily snapshots of Linus' kernel tree which are managed in a
|
||||
git repository (hence the name.) These patches are usually released
|
||||
|
|
@ -317,9 +317,9 @@ revisions to it, and maintainers can mark patches as under review,
|
|||
accepted, or rejected. Most of these patchwork sites are listed at
|
||||
http://patchwork.kernel.org/.
|
||||
|
||||
3.x -next kernel tree for integration tests
|
||||
4.x -next kernel tree for integration tests
|
||||
---------------------------------------------
|
||||
Before updates from subsystem trees are merged into the mainline 3.x
|
||||
Before updates from subsystem trees are merged into the mainline 4.x
|
||||
tree, they need to be integration-tested. For this purpose, a special
|
||||
testing repository exists into which virtually all subsystem trees are
|
||||
pulled on an almost daily basis:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,7 @@ This guide gives a quick cheat sheet for some basic understanding.
|
|||
Some Keywords
|
||||
|
||||
DMAR - DMA remapping
|
||||
DRHD - DMA Engine Reporting Structure
|
||||
DRHD - DMA Remapping Hardware Unit Definition
|
||||
RMRR - Reserved memory Region Reporting Structure
|
||||
ZLR - Zero length reads from PCI devices
|
||||
IOVA - IO Virtual address.
|
||||
|
|
|
|||
|
|
@ -28,7 +28,7 @@ o You must use one of the rcu_dereference() family of primitives
|
|||
o Avoid cancellation when using the "+" and "-" infix arithmetic
|
||||
operators. For example, for a given variable "x", avoid
|
||||
"(x-x)". There are similar arithmetic pitfalls from other
|
||||
arithmetic operatiors, such as "(x*0)", "(x/(x+1))" or "(x%1)".
|
||||
arithmetic operators, such as "(x*0)", "(x/(x+1))" or "(x%1)".
|
||||
The compiler is within its rights to substitute zero for all of
|
||||
these expressions, so that subsequent accesses no longer depend
|
||||
on the rcu_dereference(), again possibly resulting in bugs due
|
||||
|
|
|
|||
|
|
@ -26,12 +26,6 @@ CONFIG_RCU_CPU_STALL_TIMEOUT
|
|||
Stall-warning messages may be enabled and disabled completely via
|
||||
/sys/module/rcupdate/parameters/rcu_cpu_stall_suppress.
|
||||
|
||||
CONFIG_RCU_CPU_STALL_INFO
|
||||
|
||||
This kernel configuration parameter causes the stall warning to
|
||||
print out additional per-CPU diagnostic information, including
|
||||
information on scheduling-clock ticks and RCU's idle-CPU tracking.
|
||||
|
||||
RCU_STALL_DELAY_DELTA
|
||||
|
||||
Although the lockdep facility is extremely useful, it does add
|
||||
|
|
@ -101,15 +95,13 @@ interact. Please note that it is not possible to entirely eliminate this
|
|||
sort of false positive without resorting to things like stop_machine(),
|
||||
which is overkill for this sort of problem.
|
||||
|
||||
If the CONFIG_RCU_CPU_STALL_INFO kernel configuration parameter is set,
|
||||
more information is printed with the stall-warning message, for example:
|
||||
Recent kernels will print a long form of the stall-warning message:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (63959 ticks this GP) idle=241/3fffffffffffffff/0 softirq=82/543
|
||||
(t=65000 jiffies)
|
||||
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, even more information is
|
||||
printed:
|
||||
In kernels with CONFIG_RCU_FAST_NO_HZ, more information is printed:
|
||||
|
||||
INFO: rcu_preempt detected stall on CPU
|
||||
0: (64628 ticks this GP) idle=dd5/3fffffffffffffff/0 softirq=82/543 last_accelerate: a345/d342 nonlazy_posted: 25 .D
|
||||
|
|
@ -171,6 +163,23 @@ message will be about three times the interval between the beginning
|
|||
of the stall and the first message.
|
||||
|
||||
|
||||
Stall Warnings for Expedited Grace Periods
|
||||
|
||||
If an expedited grace period detects a stall, it will place a message
|
||||
like the following in dmesg:
|
||||
|
||||
INFO: rcu_sched detected expedited stalls on CPUs: { 1 2 6 } 26009 jiffies s: 1043
|
||||
|
||||
This indicates that CPUs 1, 2, and 6 have failed to respond to a
|
||||
reschedule IPI, that the expedited grace period has been going on for
|
||||
26,009 jiffies, and that the expedited grace-period sequence counter is
|
||||
1043. The fact that this last value is odd indicates that an expedited
|
||||
grace period is in flight.
|
||||
|
||||
It is entirely possible to see stall warnings from normal and from
|
||||
expedited grace periods at about the same time from the same run.
|
||||
|
||||
|
||||
What Causes RCU CPU Stall Warnings?
|
||||
|
||||
So your kernel printed an RCU CPU stall warning. The next question is
|
||||
|
|
|
|||
|
|
@ -237,42 +237,26 @@ o "ktl" is the low-order 16 bits (in hexadecimal) of the count of
|
|||
|
||||
The output of "cat rcu/rcu_preempt/rcuexp" looks as follows:
|
||||
|
||||
s=21872 d=21872 w=0 tf=0 wd1=0 wd2=0 n=0 sc=21872 dt=21872 dl=0 dx=21872
|
||||
s=21872 wd0=0 wd1=0 wd2=0 wd3=5 n=0 enq=0 sc=21872
|
||||
|
||||
These fields are as follows:
|
||||
|
||||
o "s" is the starting sequence number.
|
||||
o "s" is the sequence number, with an odd number indicating that
|
||||
an expedited grace period is in progress.
|
||||
|
||||
o "d" is the ending sequence number. When the starting and ending
|
||||
numbers differ, there is an expedited grace period in progress.
|
||||
|
||||
o "w" is the number of times that the sequence numbers have been
|
||||
in danger of wrapping.
|
||||
|
||||
o "tf" is the number of times that contention has resulted in a
|
||||
failure to begin an expedited grace period.
|
||||
|
||||
o "wd1" and "wd2" are the number of times that an attempt to
|
||||
start an expedited grace period found that someone else had
|
||||
completed an expedited grace period that satisfies the
|
||||
o "wd0", "wd1", "wd2", and "wd3" are the number of times that an
|
||||
attempt to start an expedited grace period found that someone
|
||||
else had completed an expedited grace period that satisfies the
|
||||
attempted request. "Our work is done."
|
||||
|
||||
o "n" is number of times that contention was so great that
|
||||
the request was demoted from an expedited grace period to
|
||||
a normal grace period.
|
||||
o "n" is number of times that a concurrent CPU-hotplug operation
|
||||
forced a fallback to a normal grace period.
|
||||
|
||||
o "enq" is the number of quiescent states still outstanding.
|
||||
|
||||
o "sc" is the number of times that the attempt to start a
|
||||
new expedited grace period succeeded.
|
||||
|
||||
o "dt" is the number of times that we attempted to update
|
||||
the "d" counter.
|
||||
|
||||
o "dl" is the number of times that we failed to update the "d"
|
||||
counter.
|
||||
|
||||
o "dx" is the number of times that we succeeded in updating
|
||||
the "d" counter.
|
||||
|
||||
|
||||
The output of "cat rcu/rcu_preempt/rcugp" looks as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -883,7 +883,7 @@ All: lockdep-checked RCU-protected pointer access
|
|||
|
||||
rcu_access_pointer
|
||||
rcu_dereference_raw
|
||||
rcu_lockdep_assert
|
||||
RCU_LOCKDEP_WARN
|
||||
rcu_sleep_check
|
||||
RCU_NONIDLE
|
||||
|
||||
|
|
|
|||
|
|
@ -90,11 +90,11 @@ patch.
|
|||
|
||||
Make sure your patch does not include any extra files which do not
|
||||
belong in a patch submission. Make sure to review your patch -after-
|
||||
generated it with diff(1), to ensure accuracy.
|
||||
generating it with diff(1), to ensure accuracy.
|
||||
|
||||
If your changes produce a lot of deltas, you need to split them into
|
||||
individual patches which modify things in logical stages; see section
|
||||
#3. This will facilitate easier reviewing by other kernel developers,
|
||||
#3. This will facilitate review by other kernel developers,
|
||||
very important if you want your patch accepted.
|
||||
|
||||
If you're using git, "git rebase -i" can help you with this process. If
|
||||
|
|
@ -267,7 +267,7 @@ You should always copy the appropriate subsystem maintainer(s) on any patch
|
|||
to code that they maintain; look through the MAINTAINERS file and the
|
||||
source code revision history to see who those maintainers are. The
|
||||
script scripts/get_maintainer.pl can be very useful at this step. If you
|
||||
cannot find a maintainer for the subsystem your are working on, Andrew
|
||||
cannot find a maintainer for the subsystem you are working on, Andrew
|
||||
Morton (akpm@linux-foundation.org) serves as a maintainer of last resort.
|
||||
|
||||
You should also normally choose at least one mailing list to receive a copy
|
||||
|
|
@ -340,7 +340,7 @@ on the changes you are submitting. It is important for a kernel
|
|||
developer to be able to "quote" your changes, using standard e-mail
|
||||
tools, so that they may comment on specific portions of your code.
|
||||
|
||||
For this reason, all patches should be submitting e-mail "inline".
|
||||
For this reason, all patches should be submitted by e-mail "inline".
|
||||
WARNING: Be wary of your editor's word-wrap corrupting your patch,
|
||||
if you choose to cut-n-paste your patch.
|
||||
|
||||
|
|
@ -739,7 +739,7 @@ interest on a single line; it should look something like:
|
|||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
to get these changes:
|
||||
|
||||
A pull request should also include an overall message saying what will be
|
||||
included in the request, a "git shortlog" listing of the patches
|
||||
|
|
@ -796,7 +796,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
|||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
|
||||
<Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
|
|
|||
|
|
@ -0,0 +1,527 @@
|
|||
Adding a New System Call
|
||||
========================
|
||||
|
||||
This document describes what's involved in adding a new system call to the
|
||||
Linux kernel, over and above the normal submission advice in
|
||||
Documentation/SubmittingPatches.
|
||||
|
||||
|
||||
System Call Alternatives
|
||||
------------------------
|
||||
|
||||
The first thing to consider when adding a new system call is whether one of
|
||||
the alternatives might be suitable instead. Although system calls are the
|
||||
most traditional and most obvious interaction points between userspace and the
|
||||
kernel, there are other possibilities -- choose what fits best for your
|
||||
interface.
|
||||
|
||||
- If the operations involved can be made to look like a filesystem-like
|
||||
object, it may make more sense to create a new filesystem or device. This
|
||||
also makes it easier to encapsulate the new functionality in a kernel module
|
||||
rather than requiring it to be built into the main kernel.
|
||||
- If the new functionality involves operations where the kernel notifies
|
||||
userspace that something has happened, then returning a new file
|
||||
descriptor for the relevant object allows userspace to use
|
||||
poll/select/epoll to receive that notification.
|
||||
- However, operations that don't map to read(2)/write(2)-like operations
|
||||
have to be implemented as ioctl(2) requests, which can lead to a
|
||||
somewhat opaque API.
|
||||
- If you're just exposing runtime system information, a new node in sysfs
|
||||
(see Documentation/filesystems/sysfs.txt) or the /proc filesystem may be
|
||||
more appropriate. However, access to these mechanisms requires that the
|
||||
relevant filesystem is mounted, which might not always be the case (e.g.
|
||||
in a namespaced/sandboxed/chrooted environment). Avoid adding any API to
|
||||
debugfs, as this is not considered a 'production' interface to userspace.
|
||||
- If the operation is specific to a particular file or file descriptor, then
|
||||
an additional fcntl(2) command option may be more appropriate. However,
|
||||
fcntl(2) is a multiplexing system call that hides a lot of complexity, so
|
||||
this option is best for when the new function is closely analogous to
|
||||
existing fcntl(2) functionality, or the new functionality is very simple
|
||||
(for example, getting/setting a simple flag related to a file descriptor).
|
||||
- If the operation is specific to a particular task or process, then an
|
||||
additional prctl(2) command option may be more appropriate. As with
|
||||
fcntl(2), this system call is a complicated multiplexor so is best reserved
|
||||
for near-analogs of existing prctl() commands or getting/setting a simple
|
||||
flag related to a process.
|
||||
|
||||
|
||||
Designing the API: Planning for Extension
|
||||
-----------------------------------------
|
||||
|
||||
A new system call forms part of the API of the kernel, and has to be supported
|
||||
indefinitely. As such, it's a very good idea to explicitly discuss the
|
||||
interface on the kernel mailing list, and it's important to plan for future
|
||||
extensions of the interface.
|
||||
|
||||
(The syscall table is littered with historical examples where this wasn't done,
|
||||
together with the corresponding follow-up system calls -- eventfd/eventfd2,
|
||||
dup2/dup3, inotify_init/inotify_init1, pipe/pipe2, renameat/renameat2 -- so
|
||||
learn from the history of the kernel and plan for extensions from the start.)
|
||||
|
||||
For simpler system calls that only take a couple of arguments, the preferred
|
||||
way to allow for future extensibility is to include a flags argument to the
|
||||
system call. To make sure that userspace programs can safely use flags
|
||||
between kernel versions, check whether the flags value holds any unknown
|
||||
flags, and reject the system call (with EINVAL) if it does:
|
||||
|
||||
if (flags & ~(THING_FLAG1 | THING_FLAG2 | THING_FLAG3))
|
||||
return -EINVAL;
|
||||
|
||||
(If no flags values are used yet, check that the flags argument is zero.)
|
||||
|
||||
For more sophisticated system calls that involve a larger number of arguments,
|
||||
it's preferred to encapsulate the majority of the arguments into a structure
|
||||
that is passed in by pointer. Such a structure can cope with future extension
|
||||
by including a size argument in the structure:
|
||||
|
||||
struct xyzzy_params {
|
||||
u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
|
||||
u32 param_1;
|
||||
u64 param_2;
|
||||
u64 param_3;
|
||||
};
|
||||
|
||||
As long as any subsequently added field, say param_4, is designed so that a
|
||||
zero value gives the previous behaviour, then this allows both directions of
|
||||
version mismatch:
|
||||
|
||||
- To cope with a later userspace program calling an older kernel, the kernel
|
||||
code should check that any memory beyond the size of the structure that it
|
||||
expects is zero (effectively checking that param_4 == 0).
|
||||
- To cope with an older userspace program calling a newer kernel, the kernel
|
||||
code can zero-extend a smaller instance of the structure (effectively
|
||||
setting param_4 = 0).
|
||||
|
||||
See perf_event_open(2) and the perf_copy_attr() function (in
|
||||
kernel/events/core.c) for an example of this approach.
|
||||
|
||||
|
||||
Designing the API: Other Considerations
|
||||
---------------------------------------
|
||||
|
||||
If your new system call allows userspace to refer to a kernel object, it
|
||||
should use a file descriptor as the handle for that object -- don't invent a
|
||||
new type of userspace object handle when the kernel already has mechanisms and
|
||||
well-defined semantics for using file descriptors.
|
||||
|
||||
If your new xyzzy(2) system call does return a new file descriptor, then the
|
||||
flags argument should include a value that is equivalent to setting O_CLOEXEC
|
||||
on the new FD. This makes it possible for userspace to close the timing
|
||||
window between xyzzy() and calling fcntl(fd, F_SETFD, FD_CLOEXEC), where an
|
||||
unexpected fork() and execve() in another thread could leak a descriptor to
|
||||
the exec'ed program. (However, resist the temptation to re-use the actual value
|
||||
of the O_CLOEXEC constant, as it is architecture-specific and is part of a
|
||||
numbering space of O_* flags that is fairly full.)
|
||||
|
||||
If your system call returns a new file descriptor, you should also consider
|
||||
what it means to use the poll(2) family of system calls on that file
|
||||
descriptor. Making a file descriptor ready for reading or writing is the
|
||||
normal way for the kernel to indicate to userspace that an event has
|
||||
occurred on the corresponding kernel object.
|
||||
|
||||
If your new xyzzy(2) system call involves a filename argument:
|
||||
|
||||
int sys_xyzzy(const char __user *path, ..., unsigned int flags);
|
||||
|
||||
you should also consider whether an xyzzyat(2) version is more appropriate:
|
||||
|
||||
int sys_xyzzyat(int dfd, const char __user *path, ..., unsigned int flags);
|
||||
|
||||
This allows more flexibility for how userspace specifies the file in question;
|
||||
in particular it allows userspace to request the functionality for an
|
||||
already-opened file descriptor using the AT_EMPTY_PATH flag, effectively giving
|
||||
an fxyzzy(3) operation for free:
|
||||
|
||||
- xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
|
||||
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
|
||||
|
||||
(For more details on the rationale of the *at() calls, see the openat(2) man
|
||||
page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
|
||||
|
||||
If your new xyzzy(2) system call involves a parameter describing an offset
|
||||
within a file, make its type loff_t so that 64-bit offsets can be supported
|
||||
even on 32-bit architectures.
|
||||
|
||||
If your new xyzzy(2) system call involves privileged functionality, it needs
|
||||
to be governed by the appropriate Linux capability bit (checked with a call to
|
||||
capable()), as described in the capabilities(7) man page. Choose an existing
|
||||
capability bit that governs related functionality, but try to avoid combining
|
||||
lots of only vaguely related functions together under the same bit, as this
|
||||
goes against capabilities' purpose of splitting the power of root. In
|
||||
particular, avoid adding new uses of the already overly-general CAP_SYS_ADMIN
|
||||
capability.
|
||||
|
||||
If your new xyzzy(2) system call manipulates a process other than the calling
|
||||
process, it should be restricted (using a call to ptrace_may_access()) so that
|
||||
only a calling process with the same permissions as the target process, or
|
||||
with the necessary capabilities, can manipulate the target process.
|
||||
|
||||
Finally, be aware that some non-x86 architectures have an easier time if
|
||||
system call parameters that are explicitly 64-bit fall on odd-numbered
|
||||
arguments (i.e. parameter 1, 3, 5), to allow use of contiguous pairs of 32-bit
|
||||
registers. (This concern does not apply if the arguments are part of a
|
||||
structure that's passed in by pointer.)
|
||||
|
||||
|
||||
Proposing the API
|
||||
-----------------
|
||||
|
||||
To make new system calls easy to review, it's best to divide up the patchset
|
||||
into separate chunks. These should include at least the following items as
|
||||
distinct commits (each of which is described further below):
|
||||
|
||||
- The core implementation of the system call, together with prototypes,
|
||||
generic numbering, Kconfig changes and fallback stub implementation.
|
||||
- Wiring up of the new system call for one particular architecture, usually
|
||||
x86 (including all of x86_64, x86_32 and x32).
|
||||
- A demonstration of the use of the new system call in userspace via a
|
||||
selftest in tools/testing/selftests/.
|
||||
- A draft man-page for the new system call, either as plain text in the
|
||||
cover letter, or as a patch to the (separate) man-pages repository.
|
||||
|
||||
New system call proposals, like any change to the kernel's API, should always
|
||||
be cc'ed to linux-api@vger.kernel.org.
|
||||
|
||||
|
||||
Generic System Call Implementation
|
||||
----------------------------------
|
||||
|
||||
The main entry point for your new xyzzy(2) system call will be called
|
||||
sys_xyzzy(), but you add this entry point with the appropriate
|
||||
SYSCALL_DEFINEn() macro rather than explicitly. The 'n' indicates the number
|
||||
of arguments to the system call, and the macro takes the system call name
|
||||
followed by the (type, name) pairs for the parameters as arguments. Using
|
||||
this macro allows metadata about the new system call to be made available for
|
||||
other tools.
|
||||
|
||||
The new entry point also needs a corresponding function prototype, in
|
||||
include/linux/syscalls.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long sys_xyzzy(...);
|
||||
|
||||
Some architectures (e.g. x86) have their own architecture-specific syscall
|
||||
tables, but several other architectures share a generic syscall table. Add your
|
||||
new system call to the generic list by adding an entry to the list in
|
||||
include/uapi/asm-generic/unistd.h:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SYSCALL(__NR_xyzzy, sys_xyzzy)
|
||||
|
||||
Also update the __NR_syscalls count to reflect the additional system call, and
|
||||
note that if multiple new system calls are added in the same merge window,
|
||||
your new syscall number may get adjusted to resolve conflicts.
|
||||
|
||||
The file kernel/sys_ni.c provides a fallback stub implementation of each system
|
||||
call, returning -ENOSYS. Add your new system call here too:
|
||||
|
||||
cond_syscall(sys_xyzzy);
|
||||
|
||||
Your new kernel functionality, and the system call that controls it, should
|
||||
normally be optional, so add a CONFIG option (typically to init/Kconfig) for
|
||||
it. As usual for new CONFIG options:
|
||||
|
||||
- Include a description of the new functionality and system call controlled
|
||||
by the option.
|
||||
- Make the option depend on EXPERT if it should be hidden from normal users.
|
||||
- Make any new source files implementing the function dependent on the CONFIG
|
||||
option in the Makefile (e.g. "obj-$(CONFIG_XYZZY_SYSCALL) += xyzzy.c").
|
||||
- Double check that the kernel still builds with the new CONFIG option turned
|
||||
off.
|
||||
|
||||
To summarize, you need a commit that includes:
|
||||
|
||||
- CONFIG option for the new function, normally in init/Kconfig
|
||||
- SYSCALL_DEFINEn(xyzzy, ...) for the entry point
|
||||
- corresponding prototype in include/linux/syscalls.h
|
||||
- generic table entry in include/uapi/asm-generic/unistd.h
|
||||
- fallback stub in kernel/sys_ni.c
|
||||
|
||||
|
||||
x86 System Call Implementation
|
||||
------------------------------
|
||||
|
||||
To wire up your new system call for x86 platforms, you need to update the
|
||||
master syscall tables. Assuming your new system call isn't special in some
|
||||
way (see below), this involves a "common" entry (for x86_64 and x32) in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl:
|
||||
|
||||
333 common xyzzy sys_xyzzy
|
||||
|
||||
and an "i386" entry in arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy
|
||||
|
||||
Again, these numbers are liable to be changed if there are conflicts in the
|
||||
relevant merge window.
|
||||
|
||||
|
||||
Compatibility System Calls (Generic)
|
||||
------------------------------------
|
||||
|
||||
For most system calls the same 64-bit implementation can be invoked even when
|
||||
the userspace program is itself 32-bit; even if the system call's parameters
|
||||
include an explicit pointer, this is handled transparently.
|
||||
|
||||
However, there are a couple of situations where a compatibility layer is
|
||||
needed to cope with size differences between 32-bit and 64-bit.
|
||||
|
||||
The first is if the 64-bit kernel also supports 32-bit userspace programs, and
|
||||
so needs to parse areas of (__user) memory that could hold either 32-bit or
|
||||
64-bit values. In particular, this is needed whenever a system call argument
|
||||
is:
|
||||
|
||||
- a pointer to a pointer
|
||||
- a pointer to a struct containing a pointer (e.g. struct iovec __user *)
|
||||
- a pointer to a varying sized integral type (time_t, off_t, long, ...)
|
||||
- a pointer to a struct containing a varying sized integral type.
|
||||
|
||||
The second situation that requires a compatibility layer is if one of the
|
||||
system call's arguments has a type that is explicitly 64-bit even on a 32-bit
|
||||
architecture, for example loff_t or __u64. In this case, a value that arrives
|
||||
at a 64-bit kernel from a 32-bit application will be split into two 32-bit
|
||||
values, which then need to be re-assembled in the compatibility layer.
|
||||
|
||||
(Note that a system call argument that's a pointer to an explicit 64-bit type
|
||||
does *not* need a compatibility layer; for example, splice(2)'s arguments of
|
||||
type loff_t __user * do not trigger the need for a compat_ system call.)
|
||||
|
||||
The compatibility version of the system call is called compat_sys_xyzzy(), and
|
||||
is added with the COMPAT_SYSCALL_DEFINEn() macro, analogously to
|
||||
SYSCALL_DEFINEn. This version of the implementation runs as part of a 64-bit
|
||||
kernel, but expects to receive 32-bit parameter values and does whatever is
|
||||
needed to deal with them. (Typically, the compat_sys_ version converts the
|
||||
values to 64-bit versions and either calls on to the sys_ version, or both of
|
||||
them call a common inner implementation function.)
|
||||
|
||||
The compat entry point also needs a corresponding function prototype, in
|
||||
include/linux/compat.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long compat_sys_xyzzy(...);
|
||||
|
||||
If the system call involves a structure that is laid out differently on 32-bit
|
||||
and 64-bit systems, say struct xyzzy_args, then the include/linux/compat.h
|
||||
header file should also include a compat version of the structure (struct
|
||||
compat_xyzzy_args) where each variable-size field has the appropriate compat_
|
||||
type that corresponds to the type in struct xyzzy_args. The
|
||||
compat_sys_xyzzy() routine can then use this compat_ structure to parse the
|
||||
arguments from a 32-bit invocation.
|
||||
|
||||
For example, if there are fields:
|
||||
|
||||
struct xyzzy_args {
|
||||
const char __user *ptr;
|
||||
__kernel_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
in struct xyzzy_args, then struct compat_xyzzy_args would have:
|
||||
|
||||
struct compat_xyzzy_args {
|
||||
compat_uptr_t ptr;
|
||||
compat_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
The generic system call list also needs adjusting to allow for the compat
|
||||
version; the entry in include/uapi/asm-generic/unistd.h should use
|
||||
__SC_COMP rather than __SYSCALL:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SC_COMP(__NR_xyzzy, sys_xyzzy, compat_sys_xyzzy)
|
||||
|
||||
To summarize, you need:
|
||||
|
||||
- a COMPAT_SYSCALL_DEFINEn(xyzzy, ...) for the compat entry point
|
||||
- corresponding prototype in include/linux/compat.h
|
||||
- (if needed) 32-bit mapping struct in include/linux/compat.h
|
||||
- instance of __SC_COMP not __SYSCALL in include/uapi/asm-generic/unistd.h
|
||||
|
||||
|
||||
Compatibility System Calls (x86)
|
||||
--------------------------------
|
||||
|
||||
To wire up the x86 architecture of a system call with a compatibility version,
|
||||
the entries in the syscall tables need to be adjusted.
|
||||
|
||||
First, the entry in arch/x86/entry/syscalls/syscall_32.tbl gets an extra
|
||||
column to indicate that a 32-bit userspace program running on a 64-bit kernel
|
||||
should hit the compat entry point:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy compat_sys_xyzzy
|
||||
|
||||
Second, you need to figure out what should happen for the x32 ABI version of
|
||||
the new system call. There's a choice here: the layout of the arguments
|
||||
should either match the 64-bit version or the 32-bit version.
|
||||
|
||||
If there's a pointer-to-a-pointer involved, the decision is easy: x32 is
|
||||
ILP32, so the layout should match the 32-bit version, and the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is split so that x32 programs hit the
|
||||
compatibility wrapper:
|
||||
|
||||
333 64 xyzzy sys_xyzzy
|
||||
...
|
||||
555 x32 xyzzy compat_sys_xyzzy
|
||||
|
||||
If no pointers are involved, then it is preferable to re-use the 64-bit system
|
||||
call for the x32 ABI (and consequently the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is unchanged).
|
||||
|
||||
In either case, you should check that the types involved in your argument
|
||||
layout do indeed map exactly from x32 (-mx32) to either the 32-bit (-m32) or
|
||||
64-bit (-m64) equivalents.
|
||||
|
||||
|
||||
System Calls Returning Elsewhere
|
||||
--------------------------------
|
||||
|
||||
For most system calls, once the system call is complete the user program
|
||||
continues exactly where it left off -- at the next instruction, with the
|
||||
stack the same and most of the registers the same as before the system call,
|
||||
and with the same virtual memory space.
|
||||
|
||||
However, a few system calls do things differently. They might return to a
|
||||
different location (rt_sigreturn) or change the memory space (fork/vfork/clone)
|
||||
or even architecture (execve/execveat) of the program.
|
||||
|
||||
To allow for this, the kernel implementation of the system call may need to
|
||||
save and restore additional registers to the kernel stack, allowing complete
|
||||
control of where and how execution continues after the system call.
|
||||
|
||||
This is arch-specific, but typically involves defining assembly entry points
|
||||
that save/restore additional registers and invoke the real system call entry
|
||||
point.
|
||||
|
||||
For x86_64, this is implemented as a stub_xyzzy entry point in
|
||||
arch/x86/entry/entry_64.S, and the entry in the syscall table
|
||||
(arch/x86/entry/syscalls/syscall_64.tbl) is adjusted to match:
|
||||
|
||||
333 common xyzzy stub_xyzzy
|
||||
|
||||
The equivalent for 32-bit programs running on a 64-bit kernel is normally
|
||||
called stub32_xyzzy and implemented in arch/x86/entry/entry_64_compat.S,
|
||||
with the corresponding syscall table adjustment in
|
||||
arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy stub32_xyzzy
|
||||
|
||||
If the system call needs a compatibility layer (as in the previous section)
|
||||
then the stub32_ version needs to call on to the compat_sys_ version of the
|
||||
system call rather than the native 64-bit version. Also, if the x32 ABI
|
||||
implementation is not common with the x86_64 version, then its syscall
|
||||
table will also need to invoke a stub that calls on to the compat_sys_
|
||||
version.
|
||||
|
||||
For completeness, it's also nice to set up a mapping so that user-mode Linux
|
||||
still works -- its syscall table will reference stub_xyzzy, but the UML build
|
||||
doesn't include arch/x86/entry/entry_64.S implementation (because UML
|
||||
simulates registers etc). Fixing this is as simple as adding a #define to
|
||||
arch/x86/um/sys_call_table_64.c:
|
||||
|
||||
#define stub_xyzzy sys_xyzzy
|
||||
|
||||
|
||||
Other Details
|
||||
-------------
|
||||
|
||||
Most of the kernel treats system calls in a generic way, but there is the
|
||||
occasional exception that may need updating for your particular system call.
|
||||
|
||||
The audit subsystem is one such special case; it includes (arch-specific)
|
||||
functions that classify some special types of system call -- specifically
|
||||
file open (open/openat), program execution (execve/exeveat) or socket
|
||||
multiplexor (socketcall) operations. If your new system call is analogous to
|
||||
one of these, then the audit system should be updated.
|
||||
|
||||
More generally, if there is an existing system call that is analogous to your
|
||||
new system call, it's worth doing a kernel-wide grep for the existing system
|
||||
call to check there are no other special cases.
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
A new system call should obviously be tested; it is also useful to provide
|
||||
reviewers with a demonstration of how user space programs will use the system
|
||||
call. A good way to combine these aims is to include a simple self-test
|
||||
program in a new directory under tools/testing/selftests/.
|
||||
|
||||
For a new system call, there will obviously be no libc wrapper function and so
|
||||
the test will need to invoke it using syscall(); also, if the system call
|
||||
involves a new userspace-visible structure, the corresponding header will need
|
||||
to be installed to compile the test.
|
||||
|
||||
Make sure the selftest runs successfully on all supported architectures. For
|
||||
example, check that it works when compiled as an x86_64 (-m64), x86_32 (-m32)
|
||||
and x32 (-mx32) ABI program.
|
||||
|
||||
For more extensive and thorough testing of new functionality, you should also
|
||||
consider adding tests to the Linux Test Project, or to the xfstests project
|
||||
for filesystem-related changes.
|
||||
- https://linux-test-project.github.io/
|
||||
- git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
|
||||
|
||||
|
||||
Man Page
|
||||
--------
|
||||
|
||||
All new system calls should come with a complete man page, ideally using groff
|
||||
markup, but plain text will do. If groff is used, it's helpful to include a
|
||||
pre-rendered ASCII version of the man page in the cover email for the
|
||||
patchset, for the convenience of reviewers.
|
||||
|
||||
The man page should be cc'ed to linux-man@vger.kernel.org
|
||||
For more details, see https://www.kernel.org/doc/man-pages/patches.html
|
||||
|
||||
References and Sources
|
||||
----------------------
|
||||
|
||||
- LWN article from Michael Kerrisk on use of flags argument in system calls:
|
||||
https://lwn.net/Articles/585415/
|
||||
- LWN article from Michael Kerrisk on how to handle unknown flags in a system
|
||||
call: https://lwn.net/Articles/588444/
|
||||
- LWN article from Jake Edge describing constraints on 64-bit system call
|
||||
arguments: https://lwn.net/Articles/311630/
|
||||
- Pair of LWN articles from David Drysdale that describe the system call
|
||||
implementation paths in detail for v3.14:
|
||||
- https://lwn.net/Articles/604287/
|
||||
- https://lwn.net/Articles/604515/
|
||||
- Architecture-specific requirements for system calls are discussed in the
|
||||
syscall(2) man-page:
|
||||
http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
|
||||
- Collated emails from Linus Torvalds discussing the problems with ioctl():
|
||||
http://yarchive.net/comp/linux/ioctl.html
|
||||
- "How to not invent kernel interfaces", Arnd Bergmann,
|
||||
http://www.ukuug.org/events/linux2007/2007/papers/Bergmann.pdf
|
||||
- LWN article from Michael Kerrisk on avoiding new uses of CAP_SYS_ADMIN:
|
||||
https://lwn.net/Articles/486306/
|
||||
- Recommendation from Andrew Morton that all related information for a new
|
||||
system call should come in the same email thread:
|
||||
https://lkml.org/lkml/2014/7/24/641
|
||||
- Recommendation from Michael Kerrisk that a new system call should come with
|
||||
a man page: https://lkml.org/lkml/2014/6/13/309
|
||||
- Suggestion from Thomas Gleixner that x86 wire-up should be in a separate
|
||||
commit: https://lkml.org/lkml/2014/11/19/254
|
||||
- Suggestion from Greg Kroah-Hartman that it's good for new system calls to
|
||||
come with a man-page & selftest: https://lkml.org/lkml/2014/3/19/710
|
||||
- Discussion from Michael Kerrisk of new system call vs. prctl(2) extension:
|
||||
https://lkml.org/lkml/2014/6/3/411
|
||||
- Suggestion from Ingo Molnar that system calls that involve multiple
|
||||
arguments should encapsulate those arguments in a struct, which includes a
|
||||
size field for future extensibility: https://lkml.org/lkml/2015/7/30/117
|
||||
- Numbering oddities arising from (re-)use of O_* numbering space flags:
|
||||
- commit 75069f2b5bfb ("vfs: renumber FMODE_NONOTIFY and add to uniqueness
|
||||
check")
|
||||
- commit 12ed2e36c98a ("fanotify: FMODE_NONOTIFY and __O_SYNC in sparc
|
||||
conflict")
|
||||
- commit bb458c644a59 ("Safer ABI for O_TMPFILE")
|
||||
- Discussion from Matthew Wilcox about restrictions on 64-bit arguments:
|
||||
https://lkml.org/lkml/2008/12/12/187
|
||||
- Recommendation from Greg Kroah-Hartman that unknown flags should be
|
||||
policed: https://lkml.org/lkml/2014/7/17/577
|
||||
- Recommendation from Linus Torvalds that x32 system calls should prefer
|
||||
compatibility with 64-bit versions rather than 32-bit versions:
|
||||
https://lkml.org/lkml/2011/8/31/244
|
||||
|
|
@ -90,6 +90,11 @@ the Atmel website: http://www.atmel.com.
|
|||
+ Datasheet
|
||||
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
|
||||
|
||||
- sama5d2 family
|
||||
- sama5d27
|
||||
+ Datasheet
|
||||
Coming soon
|
||||
|
||||
|
||||
Linux kernel information
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ executing kernel.
|
|||
|
||||
|
||||
1. Non-Secure mode
|
||||
|
||||
Address: sysram_ns_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -28,6 +29,7 @@ Offset Value Purpose
|
|||
|
||||
|
||||
2. Secure mode
|
||||
|
||||
Address: sysram_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -40,14 +42,25 @@ Offset Value Purpose
|
|||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0800 exynos_cpu_resume AFTR
|
||||
0x0800 exynos_cpu_resume AFTR, suspend
|
||||
0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend
|
||||
0x0804 0xfcba0d10 (Magic cookie) AFTR
|
||||
0x0804 0x00000bad (Magic cookie) System suspend
|
||||
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
|
||||
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
|
||||
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
|
||||
|
||||
|
||||
3. Other (regardless of secure/non-secure mode)
|
||||
|
||||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
|
||||
|
||||
|
||||
4. Glossary
|
||||
|
||||
AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other
|
||||
modules are power gated, except the TOP modules
|
||||
MCPM - Multi-Cluster Power Management
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
TI Keystone Linux Overview
|
||||
--------------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
Keystone range of SoCs are based on ARM Cortex-A15 MPCore Processors
|
||||
and c66x DSP cores. This document describes essential information required
|
||||
for users to run Linux on Keystone based EVMs from Texas Instruments.
|
||||
|
||||
Following SoCs & EVMs are currently supported:-
|
||||
|
||||
------------ K2HK SoC and EVM --------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Hawking/Kepler SoC
|
||||
TCI6636K2H & TCI6636K2K: See documentation at
|
||||
http://www.ti.com/product/tci6638k2k
|
||||
http://www.ti.com/product/tci6638k2h
|
||||
|
||||
EVM:
|
||||
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
|
||||
|
||||
------------ K2E SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Edison SoC
|
||||
K2E - 66AK2E05: See documentation at
|
||||
http://www.ti.com/product/66AK2E05/technicaldocuments
|
||||
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
|
||||
|
||||
------------ K2L SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Lamarr SoC
|
||||
K2L - TCI6630K2L: See documentation at
|
||||
http://www.ti.com/product/TCI6630K2L/technicaldocuments
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
All of the K2 SoCs/EVMs share a common defconfig, keystone_defconfig and same
|
||||
image is used to boot on individual EVMs. The platform configuration is
|
||||
specified through DTS. Following are the DTS used:-
|
||||
K2HK EVM : k2hk-evm.dts
|
||||
K2E EVM : k2e-evm.dts
|
||||
K2L EVM : k2l-evm.dts
|
||||
|
||||
The device tree documentation for the keystone machines are located at
|
||||
Documentation/devicetree/bindings/arm/keystone/keystone.txt
|
||||
|
||||
Known issues & workaround
|
||||
-------------------------
|
||||
|
||||
Some of the device drivers used on keystone are re-used from that from
|
||||
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
|
||||
Some of the keystone specific drivers such as netcp uses run time power
|
||||
management API instead to enable clock. As this API has limitations on
|
||||
keystone, following workaround is needed to boot Linux.
|
||||
|
||||
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
|
||||
clock frameworks will try to disable clocks that are unused and disable
|
||||
the hardware. This is because netcp related power domain and clock
|
||||
domains are enabled in u-boot as run time power management API currently
|
||||
doesn't enable clocks for netcp due to a limitation. This workaround is
|
||||
expected to be removed in the future when proper API support becomes
|
||||
available. Until then, this work around is needed.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
Murali Karicheri <m-karicheri2@ti.com>
|
||||
Copyright 2015 Texas Instruments
|
||||
|
|
@ -71,12 +71,8 @@ the operations defined in clk.h:
|
|||
long (*round_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long *parent_rate);
|
||||
long (*determine_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long min_rate,
|
||||
unsigned long max_rate,
|
||||
unsigned long *best_parent_rate,
|
||||
struct clk_hw **best_parent_clk);
|
||||
int (*determine_rate)(struct clk_hw *hw,
|
||||
struct clk_rate_request *req);
|
||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw,
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
* ARC HS Performance Counters
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,archs-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,archs-pct";
|
||||
};
|
||||
|
|
@ -27,6 +27,8 @@ compatible: must be one of:
|
|||
o "atmel,at91sam9xe"
|
||||
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
||||
SoC family:
|
||||
o "atmel,sama5d2" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d27"
|
||||
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d31"
|
||||
- "atmel,sama5d33"
|
||||
|
|
@ -50,6 +52,7 @@ System Timer (ST) required properties:
|
|||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
|
|
@ -61,7 +64,7 @@ TC/TCLIB Timer required properties:
|
|||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
- clock-names: tuple listing input clock names.
|
||||
Required elements: "t0_clk"
|
||||
Required elements: "t0_clk", "slow_clk"
|
||||
Optional elements: "t1_clk", "t2_clk"
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
|
|
@ -87,14 +90,16 @@ One interrupt per TC channel in a TC block:
|
|||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45"
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
|
|
@ -117,6 +122,7 @@ required properties:
|
|||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
|
|
@ -135,9 +141,10 @@ optional at91sam9x5 properties:
|
|||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
Broadcom North Star 2 (NS2) device tree bindings
|
||||
------------------------------------------------
|
||||
|
||||
Boards with NS2 shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
NS2 SVK board
|
||||
compatible = "brcm,ns2-svk", "brcm,ns2";
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Raspberry Pi VideoCore firmware driver
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "raspberrypi,bcm2835-firmware"
|
||||
- mboxes: Phandle to the firmware device's Mailbox.
|
||||
(See: ../mailbox/mailbox.txt for more information)
|
||||
|
||||
Example:
|
||||
|
||||
firmware {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
};
|
||||
|
|
@ -17,6 +17,7 @@ its hardware characteristcs.
|
|||
- "arm,coresight-tmc", "arm,primecell";
|
||||
- "arm,coresight-funnel", "arm,primecell";
|
||||
- "arm,coresight-etm3x", "arm,primecell";
|
||||
- "arm,coresight-etm4x", "arm,primecell";
|
||||
- "qcom,coresight-replicator1x", "arm,primecell";
|
||||
|
||||
* reg: physical base address and length of the register
|
||||
|
|
|
|||
|
|
@ -127,6 +127,24 @@ Example:
|
|||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
|
||||
Hisilicon Hi6220 SRAM controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,hi6220-sramctrl", "syscon"
|
||||
- reg : Register address and size
|
||||
|
||||
Hisilicon's SoCs use sram for multiple purpose; on Hi6220 there have several
|
||||
SRAM banks for power management, modem, security, etc. Further, use "syscon"
|
||||
managing the common sram which can be shared by multiple modules.
|
||||
|
||||
Example:
|
||||
/*for Hi6220*/
|
||||
sram: sram@fff80000 {
|
||||
compatible = "hisilicon,hi6220-sramctrl", "syscon";
|
||||
reg = <0x0 0xfff80000 0x0 0x12000>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon HiP01 system controller
|
||||
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ And in addition, the compatible shall be extended with the specific
|
|||
board. Currently known boards are:
|
||||
|
||||
"buffalo,lschlv2"
|
||||
"buffalo,lswvl"
|
||||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"dlink,dns-320"
|
||||
|
|
|
|||
|
|
@ -1,12 +1,15 @@
|
|||
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
|
||||
MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings
|
||||
|
||||
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
|
||||
Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: Must contain one of
|
||||
"mediatek,mt6580"
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
"mediatek,mt8173"
|
||||
|
|
@ -14,12 +17,18 @@ compatible: Must contain one of
|
|||
|
||||
Supported boards:
|
||||
|
||||
- Evaluation board for MT6580:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
|
||||
- bq Aquaris5 smart phone:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
|
||||
- Evaluation board for MT6592:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
|
||||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Mediatek 65xx/81xx sysirq
|
||||
+Mediatek 65xx/67xx/81xx sysirq
|
||||
|
||||
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
|
||||
interrupt.
|
||||
|
|
@ -8,9 +8,11 @@ Required properties:
|
|||
"mediatek,mt8173-sysirq"
|
||||
"mediatek,mt8135-sysirq"
|
||||
"mediatek,mt8127-sysirq"
|
||||
"mediatek,mt6795-sysirq"
|
||||
"mediatek,mt6592-sysirq"
|
||||
"mediatek,mt6589-sysirq"
|
||||
"mediatek,mt6582-sysirq"
|
||||
"mediatek,mt6580-sysirq"
|
||||
"mediatek,mt6577-sysirq"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Use the same format as specified by GIC in
|
||||
|
|
|
|||
|
|
@ -135,6 +135,9 @@ Boards:
|
|||
- AM335X OrionLXm : Substation Automation Platform
|
||||
compatible = "novatech,am335x-lxm", "ti,am33xx"
|
||||
|
||||
- AM335X phyBOARD-WEGA: Single Board Computer dev kit
|
||||
compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
||||
|
|
|
|||
|
|
@ -26,3 +26,38 @@ Rockchip platforms device tree bindings
|
|||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
||||
- Netxeon R89 board:
|
||||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- Google Jerry (Hisense Chromebook C11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
|
||||
"google,veyron-jerry-rev5", "google,veyron-jerry-rev4",
|
||||
"google,veyron-jerry-rev3", "google,veyron-jerry",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Minnie (Asus Chromebook Flip C100P):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
|
||||
"google,veyron-minnie-rev2", "google,veyron-minnie-rev1",
|
||||
"google,veyron-minnie-rev0", "google,veyron-minnie",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Pinky (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Speedy (Asus C201 Chromebook):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
|
||||
"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
|
||||
"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
|
||||
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
|
||||
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Rockchip R88 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,r88", "rockchip,rk3368";
|
||||
|
|
|
|||
|
|
@ -0,0 +1,46 @@
|
|||
SP810 System Controller
|
||||
-----------------------
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: standard compatible string for a Primecell peripheral,
|
||||
see Documentation/devicetree/bindings/arm/primecell.txt
|
||||
for more details
|
||||
should be: "arm,sp810", "arm,primecell"
|
||||
|
||||
- reg: standard registers property, physical address and size
|
||||
of the control registers
|
||||
|
||||
- clock-names: from the common clock bindings, for more details see
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt;
|
||||
should be: "refclk", "timclk", "apb_pclk"
|
||||
|
||||
- clocks: from the common clock bindings, phandle and clock
|
||||
specifier pairs for the entries of clock-names property
|
||||
|
||||
- #clock-cells: from the common clock bindings;
|
||||
should be: <1>
|
||||
|
||||
- clock-output-names: from the common clock bindings;
|
||||
should be: "timerclken0", "timerclken1", "timerclken2", "timerclken3"
|
||||
|
||||
- assigned-clocks: from the common clock binding;
|
||||
should be: clock specifier for each output clock of this
|
||||
provider node
|
||||
|
||||
- assigned-clock-parents: from the common clock binding;
|
||||
should be: phandle of input clock listed in clocks
|
||||
property with the highest frequency
|
||||
|
||||
Example:
|
||||
v2m_sysctl: sysctl@020000 {
|
||||
compatible = "arm,sp810", "arm,primecell";
|
||||
reg = <0x020000 0x1000>;
|
||||
clocks = <&v2m_refclk32khz>, <&v2m_refclk1mhz>, <&smbclk>;
|
||||
clock-names = "refclk", "timclk", "apb_pclk";
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "timerclken0", "timerclken1", "timerclken2", "timerclken3";
|
||||
assigned-clocks = <&v2m_sysctl 0>, <&v2m_sysctl 1>, <&v2m_sysctl 3>, <&v2m_sysctl 3>;
|
||||
assigned-clock-parents = <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>, <&v2m_refclk1mhz>;
|
||||
|
||||
};
|
||||
|
|
@ -0,0 +1,19 @@
|
|||
Binding for simple gpio clock multiplexer.
|
||||
|
||||
This binding uses the common clock binding[1].
|
||||
|
||||
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
Required properties:
|
||||
- compatible : shall be "gpio-mux-clock".
|
||||
- clocks: list of two references to parent clocks.
|
||||
- #clock-cells : from common clock binding; shall be set to 0.
|
||||
- select-gpios : GPIO reference for selecting the parent clock.
|
||||
|
||||
Example:
|
||||
clock {
|
||||
compatible = "gpio-mux-clock";
|
||||
clocks = <&parentclk1>, <&parentclk2>;
|
||||
#clock-cells = <0>;
|
||||
select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
|
||||
};
|
||||
|
|
@ -15,19 +15,36 @@ Required Properties:
|
|||
- "hisilicon,hi6220-sysctrl"
|
||||
- "hisilicon,hi6220-mediactrl"
|
||||
- "hisilicon,hi6220-pmctrl"
|
||||
- "hisilicon,hi6220-stub-clk"
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
For example:
|
||||
Optional Properties:
|
||||
|
||||
- hisilicon,hi6220-clk-sram: phandle to the syscon managing the SoC internal sram;
|
||||
the driver need use the sram to pass parameters for frequency change.
|
||||
|
||||
- mboxes: use the label reference for the mailbox as the first parameter, the
|
||||
second parameter is the channel number.
|
||||
|
||||
Example 1:
|
||||
sys_ctrl: sys_ctrl@f7030000 {
|
||||
compatible = "hisilicon,hi6220-sysctrl", "syscon";
|
||||
reg = <0x0 0xf7030000 0x0 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2:
|
||||
stub_clock: stub_clock {
|
||||
compatible = "hisilicon,hi6220-stub-clk";
|
||||
hisilicon,hi6220-clk-sram = <&sram>;
|
||||
#clock-cells = <1>;
|
||||
mboxes = <&mailbox 1>;
|
||||
};
|
||||
|
||||
Each clock is assigned an identifier and client nodes use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,13 @@
|
|||
* Clock bindings for Freescale i.MX6 UltraLite
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx6ul-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- clocks: list of clock specifiers, must contain an entry for each required
|
||||
entry in clock-names
|
||||
- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6ul-clock.h
|
||||
for the full list of i.MX6 UltraLite clock IDs.
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
NVIDIA Tegra124 DFLL FCPU clocksource
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
The DFLL IP block on Tegra is a root clocksource designed for clocking
|
||||
the fast CPU cluster. It consists of a free-running voltage controlled
|
||||
oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
|
||||
control module that will automatically adjust the VDD_CPU voltage by
|
||||
communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
|
||||
Currently only the I2C mode is supported by these bindings.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "nvidia,tegra124-dfll"
|
||||
- reg : Defines the following set of registers, in the order listed:
|
||||
- registers for the DFLL control logic.
|
||||
- registers for the I2C output logic.
|
||||
- registers for the integrated I2C master controller.
|
||||
- look-up table RAM for voltage register values.
|
||||
- interrupts: Should contain the DFLL block interrupt.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- soc: Clock source for the DFLL control logic.
|
||||
- ref: The closed loop reference clock
|
||||
- i2c: Clock source for the integrated I2C master.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- dvco: Reset control for the DFLL DVCO.
|
||||
- #clock-cells: Must be 0.
|
||||
- clock-output-names: Name of the clock output.
|
||||
- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
|
||||
hardware will start controlling. The regulator will be queried for
|
||||
the I2C register, control values and supported voltages.
|
||||
|
||||
Required properties for the control loop parameters:
|
||||
- nvidia,sample-rate: Sample rate of the DFLL control loop.
|
||||
- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
|
||||
- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
|
||||
- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
|
||||
- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
|
||||
- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
|
||||
|
||||
Optional properties for the control loop parameters:
|
||||
- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM.
|
||||
|
||||
Required properties for I2C mode:
|
||||
- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
|
||||
|
||||
Example:
|
||||
|
||||
clock@0,70110000 {
|
||||
compatible = "nvidia,tegra124-dfll";
|
||||
reg = <0 0x70110000 0 0x100>, /* DFLL control */
|
||||
<0 0x70110000 0 0x100>, /* I2C output control */
|
||||
<0 0x70110100 0 0x100>, /* Integrated I2C controller */
|
||||
<0 0x70110200 0 0x100>; /* Look-up table RAM */
|
||||
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
|
||||
<&tegra_car TEGRA124_CLK_DFLL_REF>,
|
||||
<&tegra_car TEGRA124_CLK_I2C5>;
|
||||
clock-names = "soc", "ref", "i2c";
|
||||
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
|
||||
reset-names = "dvco";
|
||||
#clock-cells = <0>;
|
||||
clock-output-names = "dfllCPU_out";
|
||||
vdd-cpu-supply = <&vdd_cpu>;
|
||||
status = "okay";
|
||||
|
||||
nvidia,sample-rate = <12500>;
|
||||
nvidia,droop-ctrl = <0x00000f00>;
|
||||
nvidia,force-mode = <1>;
|
||||
nvidia,cf = <10>;
|
||||
nvidia,ci = <0>;
|
||||
nvidia,cg = <2>;
|
||||
|
||||
nvidia,i2c-fs-rate = <400000>;
|
||||
};
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7778 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7778. It includes two PLLs and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -10,10 +12,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are
|
||||
"plla", "pllb", "b", "out", "p", "s", and "s1".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7778-cpg-clocks";
|
||||
|
|
@ -22,4 +32,17 @@ Example
|
|||
clocks = <&extal_clk>;
|
||||
clock-output-names = "plla", "pllb", "b",
|
||||
"out", "p", "s", "s1";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sdhi0: sd@ffe4c000 {
|
||||
compatible = "renesas,sdhi-r8a7778";
|
||||
reg = <0xffe4c000 0x100>;
|
||||
interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7779 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7779. It includes one PLL and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -12,16 +14,36 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "plla",
|
||||
"z", "zs", "s", "s1", "p", "b", "out".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7779-cpg-clocks";
|
||||
reg = <0 0xffc80000 0 0x30>;
|
||||
reg = <0xffc80000 0x30>;
|
||||
clocks = <&extal_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "plla", "z", "zs", "s", "s1", "p",
|
||||
"b", "out";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sata: sata@fc600000 {
|
||||
compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
|
||||
reg = <0xfc600000 0x2000>;
|
||||
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7779_CLK_SATA>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
|
||||
and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -20,10 +22,18 @@ Required Properties:
|
|||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
||||
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
|
||||
"adsp"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@e6150000 {
|
||||
compatible = "renesas,r8a7790-cpg-clocks",
|
||||
|
|
@ -34,4 +44,16 @@ Example
|
|||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
||||
"lb", "qspi", "sdh", "sd0", "sd1", "z",
|
||||
"rcan", "adsp";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
thermal@e61f0000 {
|
||||
compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
|
||||
reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
|
||||
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
|
||||
CPU and GPU clocks, and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -14,10 +16,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "pll",
|
||||
"i", and "g"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@fcfe0000 {
|
||||
#clock-cells = <1>;
|
||||
|
|
@ -26,4 +36,19 @@ Example
|
|||
reg = <0xfcfe0000 0x18>;
|
||||
clocks = <&extal_clk>, <&usb_x1_clk>;
|
||||
clock-output-names = "pll", "i", "g";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
mtu2: timer@fcff0000 {
|
||||
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
|
||||
reg = <0xfcff0000 0x400>;
|
||||
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tgi0a";
|
||||
clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
* Rockchip RK3368 Clock and Reset Unit
|
||||
|
||||
The RK3368 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "rockchip,rk3368-cru"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||
If missing, pll rates are not changeable, due to the missing pll lock status.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All available clocks are defined as
|
||||
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
|
||||
External clocks:
|
||||
|
||||
There are several clocks that are generated outside the SoC. It is expected
|
||||
that they are defined using standard clock bindings with following
|
||||
clock-output-names:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "ext_i2s" - external I2S clock - optional,
|
||||
- "ext_gmac" - external GMAC clock - optional
|
||||
- "ext_hsadc" - external HSADC clock - optional,
|
||||
- "ext_isp" - external ISP clock - optional,
|
||||
- "ext_jtag" - external JTAG clock - optional
|
||||
- "ext_vip" - external VIP clock - optional,
|
||||
- "usbotg_out" - output clock of the pll in the otg phy
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
cru: clock-controller@ff760000 {
|
||||
compatible = "rockchip,rk3368-cru";
|
||||
reg = <0x0 0xff760000 0x0 0x1000>;
|
||||
rockchip,grf = <&grf>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock generated by the clock
|
||||
controller:
|
||||
|
||||
uart0: serial@10124000 {
|
||||
compatible = "snps,dw-apb-uart";
|
||||
reg = <0x10124000 0x400>;
|
||||
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <1>;
|
||||
clocks = <&cru SCLK_UART0>;
|
||||
};
|
||||
|
|
@ -21,8 +21,8 @@ Required properties:
|
|||
"st,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_0", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_1", "st,clkgen-plls-c32"
|
||||
|
||||
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
Clock bindings for ST-Ericsson Ux500 clocks
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain only one of the following:
|
||||
"stericsson,u8500-clks"
|
||||
"stericsson,u8540-clks"
|
||||
"stericsson,u9540-clks"
|
||||
- reg : shall contain base register location and length for
|
||||
CLKRST1, 2, 3, 5, and 6 in an array. Note the absence of
|
||||
CLKRST4, which does not exist.
|
||||
|
||||
Required subnodes:
|
||||
- prcmu-clock: a subnode with one clock cell for PRCMU (power,
|
||||
reset, control unit) clocks. The cell indicates which PRCMU
|
||||
clock in the prcmu-clock node the consumer wants to use.
|
||||
- prcc-periph-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) peripheral clocks.
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- prcc-kernel-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) kernel clocks
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- rtc32k-clock: a subnode with zero clock cells for the 32kHz
|
||||
RTC clock.
|
||||
- smp-twd-clock: a subnode for the ARM SMP Timer Watchdog cluster
|
||||
with zero clock cells.
|
||||
|
||||
Example:
|
||||
|
||||
clocks {
|
||||
compatible = "stericsson,u8500-clks";
|
||||
/*
|
||||
* Registers for the CLKRST block on peripheral
|
||||
* groups 1, 2, 3, 5, 6,
|
||||
*/
|
||||
reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>,
|
||||
<0x8000f000 0x1000>, <0xa03ff000 0x1000>,
|
||||
<0xa03cf000 0x1000>;
|
||||
|
||||
prcmu_clk: prcmu-clock {
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
prcc_pclk: prcc-periph-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
prcc_kclk: prcc-kernel-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
rtc_clk: rtc32k-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
smp_twd_clk: smp-twd-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Tegra124 CPU frequency scaling driver bindings
|
||||
----------------------------------------------
|
||||
|
||||
Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- cpu_g: Clock mux for the fast CPU cluster.
|
||||
- cpu_lp: Clock mux for the low-power CPU cluster.
|
||||
- pll_x: Fast PLL clocksource.
|
||||
- pll_p: Auxiliary PLL used during fast PLL rate changes.
|
||||
- dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
|
||||
- vdd-cpu-supply: Regulator for CPU voltage
|
||||
|
||||
Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0>;
|
||||
|
||||
clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
|
||||
<&tegra_car TEGRA124_CLK_CCLK_LP>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_X>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_P>,
|
||||
<&dfll>;
|
||||
clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
|
||||
clock-latency = <300000>;
|
||||
vdd-cpu-supply: <&vdd_cpu>;
|
||||
};
|
||||
|
||||
<...>
|
||||
};
|
||||
|
|
@ -106,6 +106,18 @@ PROPERTIES
|
|||
to the interrupt parent to which the child domain
|
||||
is being mapped.
|
||||
|
||||
- clocks
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: A list of phandle and clock specifier pairs describing
|
||||
the clocks required for enabling and disabling SEC 4.0.
|
||||
|
||||
- clock-names
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <string>
|
||||
Definition: A list of clock name strings in the same order as the
|
||||
clocks property.
|
||||
|
||||
Note: All other standard properties (see the ePAPR) are allowed
|
||||
but are optional.
|
||||
|
||||
|
|
@ -120,6 +132,11 @@ EXAMPLE
|
|||
ranges = <0 0x300000 0x10000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <92 2>;
|
||||
clocks = <&clks IMX6QDL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6QDL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6QDL_CLK_CAAM_IPG>,
|
||||
<&clks IMX6QDL_CLK_EIM_SLOW>;
|
||||
clock-names = "mem", "aclk", "ipg", "emi_slow";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -288,12 +305,13 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
Node defines address range and the associated
|
||||
interrupt for the SNVS function. This function
|
||||
monitors security state information & reports
|
||||
security violations.
|
||||
security violations. This also included rtc,
|
||||
system power off and ON/OFF key.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon".
|
||||
Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
|
@ -324,7 +342,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Usage: optional
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
|
|
@ -341,7 +359,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
|
||||
EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
|
|
@ -358,16 +376,72 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
|||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- regmap
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
- offset
|
||||
Usage: option
|
||||
value type: <u32>
|
||||
Definition: LP register offset. default it is 0x34.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
sec_mon_rtc_lp@1 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
interrupts = <93 2>;
|
||||
regmap = <&snvs>;
|
||||
offset = <0x34>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
System ON/OFF key driver
|
||||
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Mush include "fsl,sec-v4.0-pwrkey".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: The SNVS ON/OFF interrupt number to the CPU(s).
|
||||
|
||||
- linux,keycode:
|
||||
Usage: option
|
||||
Value type: <int>
|
||||
Definition: Keycode to emit, KEY_POWER by default.
|
||||
|
||||
- wakeup-source:
|
||||
Usage: option
|
||||
Value type: <boo>
|
||||
Definition: Button can wake-up the system.
|
||||
|
||||
- regmap:
|
||||
Usage: required:
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
EXAMPLE:
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&snvs>;
|
||||
interrupts = <0 4 0x4>
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -443,12 +517,20 @@ FULL EXAMPLE
|
|||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
interrupts = <0 4 0x4>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Allwinner Security System found on A20 SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "allwinner,sun4i-a10-crypto".
|
||||
- reg: Should contain the Security System register location and length.
|
||||
- interrupts: Should contain the IRQ line for the Security System.
|
||||
- clocks : List of clock specifiers, corresponding to ahb and ss.
|
||||
- clock-names : Name of the functional clock, should be
|
||||
* "ahb" : AHB gating clock
|
||||
* "mod" : SS controller clock
|
||||
|
||||
Optional properties:
|
||||
- resets : phandle + reset specifier pair
|
||||
- reset-names : must contain "ahb"
|
||||
|
||||
Example:
|
||||
crypto: crypto-engine@01c15000 {
|
||||
compatible = "allwinner,sun4i-a10-crypto";
|
||||
reg = <0x01c15000 0x1000>;
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ahb_gates 5>, <&ss_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
};
|
||||
|
|
@ -10,8 +10,11 @@ Required Properties:
|
|||
|
||||
Optional Properties:
|
||||
- ti,wakeup : To enable the wakeup comparator in probe
|
||||
- ti,enable-id-detection: Perform ID detection.
|
||||
- ti,enable-id-detection: Perform ID detection. If id-gpio is specified
|
||||
it performs id-detection using GPIO else using OTG core.
|
||||
- ti,enable-vbus-detection: Perform VBUS detection.
|
||||
- id-gpio: gpio for GPIO ID detection. See gpio binding.
|
||||
- debounce-delay-ms: debounce delay for GPIO ID pin in milliseconds.
|
||||
|
||||
palmas-usb {
|
||||
compatible = "ti,twl6035-usb", "ti,palmas-usb";
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -3,10 +3,16 @@ ltc2978
|
|||
Required properties:
|
||||
- compatible: should contain one of:
|
||||
* "lltc,ltc2974"
|
||||
* "lltc,ltc2975"
|
||||
* "lltc,ltc2977"
|
||||
* "lltc,ltc2978"
|
||||
* "lltc,ltc2980"
|
||||
* "lltc,ltc3880"
|
||||
* "lltc,ltc3882"
|
||||
* "lltc,ltc3883"
|
||||
* "lltc,ltc3886"
|
||||
* "lltc,ltc3887"
|
||||
* "lltc,ltm2987"
|
||||
* "lltc,ltm4676"
|
||||
- reg: I2C slave address
|
||||
|
||||
|
|
@ -17,10 +23,10 @@ Optional properties:
|
|||
standard binding for regulators; see regulator.txt.
|
||||
|
||||
Valid names of regulators depend on number of supplies supported per device:
|
||||
* ltc2974 : vout0 - vout3
|
||||
* ltc2977 : vout0 - vout7
|
||||
* ltc2974, ltc2975 : vout0 - vout3
|
||||
* ltc2977, ltc2980, ltm2987 : vout0 - vout7
|
||||
* ltc2978 : vout0 - vout7
|
||||
* ltc3880 : vout0 - vout1
|
||||
* ltc3880, ltc3882, ltc3886 : vout0 - vout1
|
||||
* ltc3883 : vout0
|
||||
* ltm4676 : vout0 - vout1
|
||||
|
||||
|
|
|
|||
|
|
@ -18,6 +18,7 @@ Required properties:
|
|||
"mcp3202"
|
||||
"mcp3204"
|
||||
"mcp3208"
|
||||
"mcp3301"
|
||||
|
||||
|
||||
Examples:
|
||||
|
|
|
|||
|
|
@ -17,6 +17,11 @@ Recommended properties:
|
|||
- Frequency in normal mode (ADLPC=0, ADHSC=0)
|
||||
- Frequency in high-speed mode (ADLPC=0, ADHSC=1)
|
||||
- Frequency in low-power mode (ADLPC=1, ADHSC=0)
|
||||
- min-sample-time: Minimum sampling time in nanoseconds. This value has
|
||||
to be chosen according to the conversion mode and the connected analog
|
||||
source resistance (R_as) and capacitance (C_as). Refer the datasheet's
|
||||
operating requirements. A safe default across a wide range of R_as and
|
||||
C_as as well as conversion modes is 1000ns.
|
||||
|
||||
Example:
|
||||
adc0: adc@4003b000 {
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -35,6 +35,7 @@ Accelerometers:
|
|||
- st,lsm303dl-accel
|
||||
- st,lsm303dlm-accel
|
||||
- st,lsm330-accel
|
||||
- st,lsm303agr-accel
|
||||
|
||||
Gyroscopes:
|
||||
- st,l3g4200d-gyro
|
||||
|
|
@ -46,6 +47,7 @@ Gyroscopes:
|
|||
- st,lsm330-gyro
|
||||
|
||||
Magnetometers:
|
||||
- st,lsm303agr-magn
|
||||
- st,lsm303dlh-magn
|
||||
- st,lsm303dlhc-magn
|
||||
- st,lsm303dlm-magn
|
||||
|
|
|
|||
|
|
@ -0,0 +1 @@
|
|||
See Documentation/devicetree/bindings/crypto/fsl-sec4.txt
|
||||
|
|
@ -5,9 +5,14 @@ The BCM2835 contains a custom top-level interrupt controller, which supports
|
|||
controller, or the HW block containing it, is referred to occasionally
|
||||
as "armctrl" in the SoC documentation, hence naming of this binding.
|
||||
|
||||
The BCM2836 contains the same interrupt controller with the same
|
||||
interrupts, but the per-CPU interrupt controller is the root, and an
|
||||
interrupt there indicates that the ARMCTRL has an interrupt to handle.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic"
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic" or
|
||||
"brcm,bcm2836-armctrl-ic"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
|
|
@ -20,6 +25,12 @@ Required properties:
|
|||
The 2nd cell contains the interrupt number within the bank. Valid values
|
||||
are 0..7 for bank 0, and 0..31 for bank 1.
|
||||
|
||||
Additional required properties for brcm,bcm2836-armctrl-ic:
|
||||
- interrupt-parent : Specifies the parent interrupt controller when this
|
||||
controller is the second level.
|
||||
- interrupts : Specifies the interrupt on the parent for this interrupt
|
||||
controller to handle.
|
||||
|
||||
The interrupt sources are as follows:
|
||||
|
||||
Bank 0:
|
||||
|
|
@ -102,9 +113,21 @@ Bank 2:
|
|||
|
||||
Example:
|
||||
|
||||
/* BCM2835, first level */
|
||||
intc: interrupt-controller {
|
||||
compatible = "brcm,bcm2835-armctrl-ic";
|
||||
reg = <0x7e00b200 0x200>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
/* BCM2836, second level */
|
||||
intc: interrupt-controller {
|
||||
compatible = "brcm,bcm2836-armctrl-ic";
|
||||
reg = <0x7e00b200 0x200>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
interrupt-parent = <&local_intc>;
|
||||
interrupts = <8>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -29,14 +29,23 @@ Optional properties for child nodes:
|
|||
"ide-disk" - LED indicates disk activity
|
||||
"timer" - LED flashes at a fixed, configurable rate
|
||||
|
||||
- max-microamp : maximum intensity in microamperes of the LED
|
||||
(torch LED for flash devices)
|
||||
- flash-max-microamp : maximum intensity in microamperes of the
|
||||
flash LED; it is mandatory if the LED should
|
||||
support the flash mode
|
||||
- flash-timeout-us : timeout in microseconds after which the flash
|
||||
LED is turned off
|
||||
- led-max-microamp : Maximum LED supply current in microamperes. This property
|
||||
can be made mandatory for the board configurations
|
||||
introducing a risk of hardware damage in case an excessive
|
||||
current is set.
|
||||
For flash LED controllers with configurable current this
|
||||
property is mandatory for the LEDs in the non-flash modes
|
||||
(e.g. torch or indicator).
|
||||
|
||||
Required properties for flash LED child nodes:
|
||||
- flash-max-microamp : Maximum flash LED supply current in microamperes.
|
||||
- flash-max-timeout-us : Maximum timeout in microseconds after which the flash
|
||||
LED is turned off.
|
||||
|
||||
For controllers that have no configurable current the flash-max-microamp
|
||||
property can be omitted.
|
||||
For controllers that have no configurable timeout the flash-max-timeout-us
|
||||
property can be omitted.
|
||||
|
||||
Examples:
|
||||
|
||||
|
|
@ -49,7 +58,7 @@ system-status {
|
|||
camera-flash {
|
||||
label = "Flash";
|
||||
led-sources = <0>, <1>;
|
||||
max-microamp = <50000>;
|
||||
led-max-microamp = <50000>;
|
||||
flash-max-microamp = <320000>;
|
||||
flash-timeout-us = <500000>;
|
||||
flash-max-timeout-us = <500000>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -8,6 +8,9 @@ Each LED is represented as a sub-node of the ns2-leds device.
|
|||
Required sub-node properties:
|
||||
- cmd-gpio: Command LED GPIO. See OF device-tree GPIO specification.
|
||||
- slow-gpio: Slow LED GPIO. See OF device-tree GPIO specification.
|
||||
- modes-map: A mapping between LED modes (off, on or SATA activity blinking) and
|
||||
the corresponding cmd-gpio/slow-gpio values. All the GPIO values combinations
|
||||
should be given in order to avoid having an unknown mode at driver probe time.
|
||||
|
||||
Optional sub-node properties:
|
||||
- label: Name for this LED. If omitted, the label is taken from the node name.
|
||||
|
|
@ -15,6 +18,8 @@ Optional sub-node properties:
|
|||
|
||||
Example:
|
||||
|
||||
#include <dt-bindings/leds/leds-ns2.h>
|
||||
|
||||
ns2-leds {
|
||||
compatible = "lacie,ns2-leds";
|
||||
|
||||
|
|
@ -22,5 +27,9 @@ ns2-leds {
|
|||
label = "ns2:blue:sata";
|
||||
slow-gpio = <&gpio0 29 0>;
|
||||
cmd-gpio = <&gpio0 30 0>;
|
||||
modes-map = <NS_V2_LED_OFF 0 1
|
||||
NS_V2_LED_ON 1 0
|
||||
NS_V2_LED_ON 0 0
|
||||
NS_V2_LED_SATA 1 1>;
|
||||
};
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -1,5 +1,9 @@
|
|||
Binding for Synopsys IntelliDDR Multi Protocol Memory Controller
|
||||
|
||||
This controller has an optional ECC support in half-bus width (16-bit)
|
||||
configuration. The ECC controller corrects one bit error and detects
|
||||
two bit errors.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be 'xlnx,zynq-ddrc-a05'
|
||||
- reg: Base address and size of the controllers memory area
|
||||
|
|
|
|||
|
|
@ -24,6 +24,10 @@ Optional properties:
|
|||
- vcc10-supply: The input supply for LDO_REG6
|
||||
- vcc11-supply: The input supply for LDO_REG8
|
||||
- vcc12-supply: The input supply for SWITCH_REG2
|
||||
- dvs-gpios: buck1/2 can be controlled by gpio dvs, this is GPIO specifiers
|
||||
for 2 host gpio's used for dvs. The format of the gpio specifier depends in
|
||||
the gpio controller. If DVS GPIOs aren't present, voltage changes will happen
|
||||
very quickly with no slow ramp time.
|
||||
|
||||
Regulators: All the regulators of RK808 to be instantiated shall be
|
||||
listed in a child node named 'regulators'. Each regulator is represented
|
||||
|
|
@ -55,7 +59,9 @@ Example:
|
|||
interrupt-parent = <&gpio0>;
|
||||
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&pmic_int>;
|
||||
pinctrl-0 = <&pmic_int &dvs_1 &dvs_2>;
|
||||
dvs-gpios = <&gpio7 11 GPIO_ACTIVE_HIGH>,
|
||||
<&gpio7 15 GPIO_ACTIVE_HIGH>;
|
||||
reg = <0x1b>;
|
||||
rockchip,system-power-controller;
|
||||
wakeup-source;
|
||||
|
|
|
|||
|
|
@ -4,6 +4,10 @@ Required properties:
|
|||
- compatible: "allwinner,sun4i-a10-sid" or "allwinner,sun7i-a20-sid"
|
||||
- reg: Should contain registers location and length
|
||||
|
||||
= Data cells =
|
||||
Are child nodes of qfprom, bindings of which as described in
|
||||
bindings/nvmem/nvmem.txt
|
||||
|
||||
Example for sun4i:
|
||||
sid@01c23800 {
|
||||
compatible = "allwinner,sun4i-a10-sid";
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -23,6 +23,9 @@ PCIe Designware Controller
|
|||
interrupt-map-mask,
|
||||
interrupt-map : as specified in ../designware-pcie.txt
|
||||
|
||||
Optional Property:
|
||||
- gpios : Should be added if a gpio line is required to drive PERST# line
|
||||
|
||||
Example:
|
||||
axi {
|
||||
compatible = "simple-bus";
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -7,6 +7,8 @@ Required properties:
|
|||
* allwinner,sun5i-a13-usb-phy
|
||||
* allwinner,sun6i-a31-usb-phy
|
||||
* allwinner,sun7i-a20-usb-phy
|
||||
* allwinner,sun8i-a23-usb-phy
|
||||
* allwinner,sun8i-a33-usb-phy
|
||||
- reg : a list of offset + length pairs
|
||||
- reg-names :
|
||||
* "phy_ctrl"
|
||||
|
|
@ -17,12 +19,21 @@ Required properties:
|
|||
- clock-names :
|
||||
* "usb_phy" for sun4i, sun5i or sun7i
|
||||
* "usb0_phy", "usb1_phy" and "usb2_phy" for sun6i
|
||||
* "usb0_phy", "usb1_phy" for sun8i
|
||||
- resets : a list of phandle + reset specifier pairs
|
||||
- reset-names :
|
||||
* "usb0_reset"
|
||||
* "usb1_reset"
|
||||
* "usb2_reset" for sun4i, sun6i or sun7i
|
||||
|
||||
Optional properties:
|
||||
- usb0_id_det-gpios : gpio phandle for reading the otg id pin value
|
||||
- usb0_vbus_det-gpios : gpio phandle for detecting the presence of usb0 vbus
|
||||
- usb0_vbus_power-supply: power-supply phandle for usb0 vbus presence detect
|
||||
- usb0_vbus-supply : regulator phandle for controller usb0 vbus
|
||||
- usb1_vbus-supply : regulator phandle for controller usb1 vbus
|
||||
- usb2_vbus-supply : regulator phandle for controller usb2 vbus
|
||||
|
||||
Example:
|
||||
usbphy: phy@0x01c13400 {
|
||||
#phy-cells = <1>;
|
||||
|
|
@ -32,6 +43,13 @@ Example:
|
|||
reg-names = "phy_ctrl", "pmu1", "pmu2";
|
||||
clocks = <&usb_clk 8>;
|
||||
clock-names = "usb_phy";
|
||||
resets = <&usb_clk 1>, <&usb_clk 2>;
|
||||
reset-names = "usb1_reset", "usb2_reset";
|
||||
resets = <&usb_clk 0>, <&usb_clk 1>, <&usb_clk 2>;
|
||||
reset-names = "usb0_reset", "usb1_reset", "usb2_reset";
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&usb0_id_detect_pin>, <&usb0_vbus_detect_pin>;
|
||||
usb0_id_det-gpios = <&pio 7 19 GPIO_ACTIVE_HIGH>; /* PH19 */
|
||||
usb0_vbus_det-gpios = <&pio 7 22 GPIO_ACTIVE_HIGH>; /* PH22 */
|
||||
usb0_vbus-supply = <®_usb0_vbus>;
|
||||
usb1_vbus-supply = <®_usb1_vbus>;
|
||||
usb2_vbus-supply = <®_usb2_vbus>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -6,14 +6,14 @@ PSC in UART mode
|
|||
For PSC in UART mode the needed PSC serial devices
|
||||
are specified by fsl,mpc5121-psc-uart nodes in the
|
||||
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 :
|
||||
- compatible : Should contain "fsl,mpc5121-psc-uart" and "fsl,mpc5121-psc"
|
||||
- cell-index : Index of the PSC in hardware
|
||||
- compatible : Should contain "fsl,<soc>-psc-uart" and "fsl,<soc>-psc"
|
||||
Supported <soc>s: mpc5121, mpc5125
|
||||
- reg : Offset and length of the register set for the PSC device
|
||||
- interrupts : <a b> where a is the interrupt number of the
|
||||
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,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 :
|
||||
- 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
|
||||
FIFO Controller
|
||||
- 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
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -5,6 +5,10 @@ Required properties:
|
|||
- compatible: must be "dlg,da9210"
|
||||
- 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
|
||||
DCDC.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
* Dialog Semiconductor DA9211/DA9213 Voltage Regulator
|
||||
* Dialog Semiconductor DA9211/DA9213/DA9215 Voltage Regulator
|
||||
|
||||
Required properties:
|
||||
- compatible: "dlg,da9211" or "dlg,da9213".
|
||||
- compatible: "dlg,da9211" or "dlg,da9213" or "dlg,da9215"
|
||||
- reg: I2C slave address, usually 0x68.
|
||||
- interrupts: the interrupt outputs of the controller
|
||||
- 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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -25,6 +25,12 @@ Optional properties:
|
|||
-maxim,enable-frequency-shift: boolean, enable 9% frequency shift.
|
||||
-maxim,enable-bias-control: boolean, enable bias control. By enabling this
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
|
@ -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:
|
||||
- compatible: Should be "pwm-regulator"
|
||||
- pwms: OF device-tree PWM specification (see PWM binding pwm.txt)
|
||||
- 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)
|
||||
--------------------
|
||||
- compatible: Should be "pwm-regulator"
|
||||
|
||||
Any property defined as part of the core regulator binding defined in
|
||||
regulator.txt can also be used.
|
||||
- pwms: PWM specification (See: ../pwm/pwm.txt)
|
||||
|
||||
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 {
|
||||
compatible = "pwm-regulator;
|
||||
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>,
|
||||
<1095000 10>,
|
||||
<1076000 20>,
|
||||
<1056000 30>,
|
||||
<1036000 40>,
|
||||
<1016000 50>;
|
||||
|
||||
regulator-min-microvolt = <1016000>;
|
||||
regulator-max-microvolt = <1114000>;
|
||||
regulator-name = "vdd_logic";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -91,13 +91,65 @@ see regulator.txt - with additional custom properties described below:
|
|||
- regulator-initial-mode:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Descrption: 1 = Set initial mode to high power mode (HPM), also referred
|
||||
to as NPM. HPM consumes more ground current than LPM, but
|
||||
Description: 2 = Set initial mode to auto mode (automatically select
|
||||
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
|
||||
available on boost type regulators. For voltage switch type
|
||||
regulators, HPM implies that over current protection and
|
||||
soft start are active all the time. 0 = Set initial mode to
|
||||
low power mode (LPM).
|
||||
soft start are active all the time.
|
||||
|
||||
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:
|
||||
|
||||
|
|
|
|||
|
|
@ -42,6 +42,7 @@ Optional properties:
|
|||
- regulator-system-load: Load in uA present on regulator that is not captured by
|
||||
any consumer request.
|
||||
- regulator-pull-down: Enable pull down resistor when the regulator is disabled.
|
||||
- regulator-over-current-protection: Enable over current protection.
|
||||
|
||||
Deprecated properties:
|
||||
- regulator-compatible: If a regulator chip contains multiple
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -3,6 +3,7 @@ Altera SOCFPGA Reset Manager
|
|||
Required properties:
|
||||
- compatible : "altr,rst-mgr"
|
||||
- reg : Should contain 1 register ranges(address and length)
|
||||
- altr,modrst-offset : Should contain the offset of the first modrst register.
|
||||
- #reset-cells: 1
|
||||
|
||||
Example:
|
||||
|
|
@ -10,4 +11,5 @@ Example:
|
|||
#reset-cells = <1>;
|
||||
compatible = "altr,rst-mgr";
|
||||
reg = <0xffd05000 0x1000>;
|
||||
altr,modrst-offset = <0x10>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -39,4 +39,4 @@ Example:
|
|||
};
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -43,5 +43,5 @@ example:
|
|||
|
||||
Macro definitions for the supported reset channels can be found in:
|
||||
|
||||
include/dt-bindings/reset-controller/stih415-resets.h
|
||||
include/dt-bindings/reset-controller/stih416-resets.h
|
||||
include/dt-bindings/reset/stih415-resets.h
|
||||
include/dt-bindings/reset/stih416-resets.h
|
||||
|
|
|
|||
|
|
@ -42,5 +42,5 @@ example:
|
|||
|
||||
Macro definitions for the supported reset channels can be found in:
|
||||
|
||||
include/dt-bindings/reset-controller/stih415-resets.h
|
||||
include/dt-bindings/reset-controller/stih416-resets.h
|
||||
include/dt-bindings/reset/stih415-resets.h
|
||||
include/dt-bindings/reset/stih416-resets.h
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
@ -5,6 +5,7 @@ Required properties:
|
|||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- interrupts: rtc alarm/event interrupt
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
|
|
@ -12,4 +13,5 @@ rtc@fffffe00 {
|
|||
compatible = "atmel,at91rm9200-rtc";
|
||||
reg = <0xfffffe00 0x100>;
|
||||
interrupts = <1 4 7>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -8,6 +8,7 @@ Required properties:
|
|||
Wakeup generation for event Alarm. It can also be
|
||||
used to control an external PMIC via the
|
||||
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
|
||||
- interrupts: rtc timer, alarm interrupts in order
|
||||
- interrupt-parent: phandle for the interrupt controller
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ Optional properties:
|
|||
memory peripheral interface and USART DMA channel ID, FIFO configuration.
|
||||
Refer to dma.txt and atmel-dma.txt for details.
|
||||
- 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:
|
||||
- at91rm9200: legacy USART support
|
||||
|
|
@ -57,4 +59,5 @@ Example:
|
|||
dmas = <&dma0 2 0x3>,
|
||||
<&dma0 2 0x204>;
|
||||
dma-names = "tx", "rx";
|
||||
atmel,fifo-size = <32>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -6,7 +6,7 @@ Required properties:
|
|||
- interrupts: device interrupt
|
||||
|
||||
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.
|
||||
|
||||
Example:
|
||||
|
|
@ -16,4 +16,8 @@ serial@b00260000 {
|
|||
reg = <0xb0026000 0x1000>;
|
||||
interrupts = <68>;
|
||||
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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -5,10 +5,12 @@ Required properties:
|
|||
* "mediatek,mt8135-uart" for MT8135 compatible UARTS
|
||||
* "mediatek,mt8127-uart" for MT8127 compatible UARTS
|
||||
* "mediatek,mt8173-uart" for MT8173 compatible UARTS
|
||||
* "mediatek,mt6795-uart" for MT6795 compatible UARTS
|
||||
* "mediatek,mt6589-uart" for MT6589 compatible UARTS
|
||||
* "mediatek,mt6582-uart" for MT6582 compatible UARTS
|
||||
* "mediatek,mt6577-uart" for all compatible UARTS (MT8173, MT6589, MT6582,
|
||||
MT6577)
|
||||
* "mediatek,mt6580-uart" for MT6580 compatible UARTS
|
||||
* "mediatek,mt6577-uart" for all compatible UARTS (MT8173, MT6795,
|
||||
MT6589, MT6582, MT6580, MT6577)
|
||||
|
||||
- reg: The base address of the UART register bank.
|
||||
|
||||
|
|
|
|||
|
|
@ -4,6 +4,9 @@ Required properties:
|
|||
- compatible : should be "ti,omap2-uart" for OMAP2 controllers
|
||||
- compatible : should be "ti,omap3-uart" for OMAP3 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
|
||||
- interrupts or interrupts-extended : Should contain the uart interrupt
|
||||
specifier or both the interrupt
|
||||
|
|
|
|||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче