Merge linux-block/for-4.3/core into md/for-linux
There were a few conflicts that are fairly easy to resolve. Signed-off-by: NeilBrown <neilb@suse.com>
This commit is contained in:
NeilBrown
Коммит
e89c6fdf9e
|
|
@ -0,0 +1 @@
|
|||
Christoph Hellwig <hch@lst.de>
|
||||
1
.mailmap
1
.mailmap
|
|
@ -17,6 +17,7 @@ Aleksey Gorelov <aleksey_gorelov@phoenix.com>
|
|||
Al Viro <viro@ftp.linux.org.uk>
|
||||
Al Viro <viro@zenIV.linux.org.uk>
|
||||
Andreas Herrmann <aherrman@de.ibm.com>
|
||||
Andrey Ryabinin <ryabinin.a.a@gmail.com> <a.ryabinin@samsung.com>
|
||||
Andrew Morton <akpm@linux-foundation.org>
|
||||
Andrew Vasquez <andrew.vasquez@qlogic.com>
|
||||
Andy Adamson <andros@citi.umich.edu>
|
||||
|
|
|
|||
5
CREDITS
5
CREDITS
|
|
@ -3219,6 +3219,11 @@ S: 69 rue Dunois
|
|||
S: 75013 Paris
|
||||
S: France
|
||||
|
||||
N: Aleksa Sarai
|
||||
E: cyphar@cyphar.com
|
||||
W: https://www.cyphar.com/
|
||||
D: `pids` cgroup subsystem
|
||||
|
||||
N: Dipankar Sarma
|
||||
E: dipankar@in.ibm.com
|
||||
D: RCU
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -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.
|
||||
|
|
@ -77,3 +77,22 @@ Description:
|
|||
The format is also scrambled, like in the USB mode, and it can
|
||||
be summarized by converting 76543210 into GECA6420.
|
||||
HGFEDCBA HFDB7531
|
||||
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/unpair_remote
|
||||
Date: July 2015
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Writing the character sequence '*' followed by a newline to
|
||||
this file will delete all of the current pairings on the
|
||||
device. Other character sequences are reserved. This file is
|
||||
write only.
|
||||
|
||||
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/remote_mode
|
||||
Date: July 2015
|
||||
Contact: linux-input@vger.kernel.org
|
||||
Description:
|
||||
Reading from this file reports the mode status of the
|
||||
remote as indicated by the LED lights on the device. If no
|
||||
reports have been received from the paired device, reading
|
||||
from this file will report '-1'. The mode is read-only
|
||||
and cannot be set through the driver.
|
||||
|
|
|
|||
|
|
@ -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,14 +56,17 @@ 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
|
||||
KERNELDOCXMLREF = $(srctree)/scripts/kernel-doc-xml-ref
|
||||
KERNELDOC = $(srctree)/scripts/kernel-doc
|
||||
DOCPROC = $(objtree)/scripts/docproc
|
||||
|
||||
|
|
@ -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 $@
|
||||
|
||||
|
|
@ -218,6 +234,9 @@ clean-files := $(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
|
||||
|
|
@ -291,7 +291,7 @@ sending him e-mail.
|
|||
|
||||
If you have a patch that fixes an exploitable security bug, send that patch
|
||||
to security@kernel.org. For severe bugs, a short embargo may be considered
|
||||
to allow distrbutors to get the patch out to users; in such cases,
|
||||
to allow distributors to get the patch out to users; in such cases,
|
||||
obviously, the patch should not be sent to any public lists.
|
||||
|
||||
Patches that fix a severe bug in a released kernel should be directed
|
||||
|
|
@ -340,7 +340,7 @@ on the changes you are submitting. It is important for a kernel
|
|||
developer to be able to "quote" your changes, using standard e-mail
|
||||
tools, so that they may comment on specific portions of your code.
|
||||
|
||||
For this reason, all patches should be submitting e-mail "inline".
|
||||
For this reason, all patches should be submitted by e-mail "inline".
|
||||
WARNING: Be wary of your editor's word-wrap corrupting your patch,
|
||||
if you choose to cut-n-paste your patch.
|
||||
|
||||
|
|
@ -739,7 +739,7 @@ interest on a single line; it should look something like:
|
|||
|
||||
git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus
|
||||
|
||||
to get these changes:"
|
||||
to get these changes:
|
||||
|
||||
A pull request should also include an overall message saying what will be
|
||||
included in the request, a "git shortlog" listing of the patches
|
||||
|
|
@ -796,7 +796,7 @@ NO!!!! No more huge patch bombs to linux-kernel@vger.kernel.org people!
|
|||
<https://lkml.org/lkml/2005/7/11/336>
|
||||
|
||||
Kernel Documentation/CodingStyle:
|
||||
<http://users.sosdg.org/~qiyong/lxr/source/Documentation/CodingStyle>
|
||||
<Documentation/CodingStyle>
|
||||
|
||||
Linus Torvalds's mail on the canonical patch format:
|
||||
<http://lkml.org/lkml/2005/4/7/183>
|
||||
|
|
|
|||
|
|
@ -1,26 +1,192 @@
|
|||
/sys/module/acpi/parameters/:
|
||||
ACPICA Trace Facility
|
||||
|
||||
trace_method_name
|
||||
The AML method name that the user wants to trace
|
||||
Copyright (C) 2015, Intel Corporation
|
||||
Author: Lv Zheng <lv.zheng@intel.com>
|
||||
|
||||
trace_debug_layer
|
||||
The temporary debug_layer used when tracing the method.
|
||||
Using 0xffffffff by default if it is 0.
|
||||
|
||||
trace_debug_level
|
||||
The temporary debug_level used when tracing the method.
|
||||
Using 0x00ffffff by default if it is 0.
|
||||
Abstract:
|
||||
|
||||
trace_state
|
||||
This document describes the functions and the interfaces of the method
|
||||
tracing facility.
|
||||
|
||||
1. Functionalities and usage examples:
|
||||
|
||||
ACPICA provides method tracing capability. And two functions are
|
||||
currently implemented using this capability.
|
||||
|
||||
A. Log reducer
|
||||
ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is
|
||||
enabled. The debugging messages which are deployed via
|
||||
ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component
|
||||
level (known as debug layer, configured via
|
||||
/sys/module/acpi/parameters/debug_layer) and per-type level (known as
|
||||
debug level, configured via /sys/module/acpi/parameters/debug_level).
|
||||
|
||||
But when the particular layer/level is applied to the control method
|
||||
evaluations, the quantity of the debugging outputs may still be too
|
||||
large to be put into the kernel log buffer. The idea thus is worked out
|
||||
to only enable the particular debug layer/level (normally more detailed)
|
||||
logs when the control method evaluation is started, and disable the
|
||||
detailed logging when the control method evaluation is stopped.
|
||||
|
||||
The following command examples illustrate the usage of the "log reducer"
|
||||
functionality:
|
||||
a. Filter out the debug layer/level matched logs when control methods
|
||||
are being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "enable" > trace_state
|
||||
b. Filter out the debug layer/level matched logs when the specified
|
||||
control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method" > /sys/module/acpi/parameters/trace_state
|
||||
c. Filter out the debug layer/level matched logs when the specified
|
||||
control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0xXXXXXXXX" > trace_debug_layer
|
||||
# echo "0xYYYYYYYY" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method-once" > /sys/module/acpi/parameters/trace_state
|
||||
Where:
|
||||
0xXXXXXXXX/0xYYYYYYYY: Refer to Documentation/acpi/debug.txt for
|
||||
possible debug layer/level masking values.
|
||||
\PPPP.AAAA.TTTT.HHHH: Full path of a control method that can be found
|
||||
in the ACPI namespace. It needn't be an entry
|
||||
of a control method evaluation.
|
||||
|
||||
B. AML tracer
|
||||
|
||||
There are special log entries added by the method tracing facility at
|
||||
the "trace points" the AML interpreter starts/stops to execute a control
|
||||
method, or an AML opcode. Note that the format of the log entries are
|
||||
subject to change:
|
||||
[ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
[ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution.
|
||||
[ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution.
|
||||
[ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution.
|
||||
[ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution.
|
||||
[ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
|
||||
[ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
|
||||
[ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution.
|
||||
[ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution.
|
||||
[ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
|
||||
[ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
|
||||
[ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution.
|
||||
[ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution.
|
||||
[ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
|
||||
|
||||
Developers can utilize these special log entries to track the AML
|
||||
interpretion, thus can aid issue debugging and performance tuning. Note
|
||||
that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT()
|
||||
macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling
|
||||
"AML tracer" logs.
|
||||
|
||||
The following command examples illustrate the usage of the "AML tracer"
|
||||
functionality:
|
||||
a. Filter out the method start/stop "AML tracer" logs when control
|
||||
methods are being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "enable" > trace_state
|
||||
b. Filter out the method start/stop "AML tracer" when the specified
|
||||
control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method" > trace_state
|
||||
c. Filter out the method start/stop "AML tracer" logs when the specified
|
||||
control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "method-once" > trace_state
|
||||
d. Filter out the method/opcode start/stop "AML tracer" when the
|
||||
specified control method is being evaluated:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "opcode" > trace_state
|
||||
e. Filter out the method/opcode start/stop "AML tracer" when the
|
||||
specified control method is being evaluated for the first time:
|
||||
# cd /sys/module/acpi/parameters
|
||||
# echo "0x80" > trace_debug_layer
|
||||
# echo "0x10" > trace_debug_level
|
||||
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
|
||||
# echo "opcode-opcode" > trace_state
|
||||
|
||||
Note that all above method tracing facility related module parameters can
|
||||
be used as the boot parameters, for example:
|
||||
acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \
|
||||
acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once
|
||||
|
||||
2. Interface descriptions:
|
||||
|
||||
All method tracing functions can be configured via ACPI module
|
||||
parameters that are accessible at /sys/module/acpi/parameters/:
|
||||
|
||||
trace_method_name
|
||||
The full path of the AML method that the user wants to trace.
|
||||
Note that the full path shouldn't contain the trailing "_"s in its
|
||||
name segments but may contain "\" to form an absolute path.
|
||||
|
||||
trace_debug_layer
|
||||
The temporary debug_layer used when the tracing feature is enabled.
|
||||
Using ACPI_EXECUTER (0x80) by default, which is the debug_layer
|
||||
used to match all "AML tracer" logs.
|
||||
|
||||
trace_debug_level
|
||||
The temporary debug_level used when the tracing feature is enabled.
|
||||
Using ACPI_LV_TRACE_POINT (0x10) by default, which is the
|
||||
debug_level used to match all "AML tracer" logs.
|
||||
|
||||
trace_state
|
||||
The status of the tracing feature.
|
||||
|
||||
"enabled" means this feature is enabled
|
||||
and the AML method is traced every time it's executed.
|
||||
|
||||
"1" means this feature is enabled and the AML method
|
||||
will only be traced during the next execution.
|
||||
|
||||
"disabled" means this feature is disabled.
|
||||
Users can enable/disable this debug tracing feature by
|
||||
"echo string > /sys/module/acpi/parameters/trace_state".
|
||||
"string" should be one of "enable", "disable" and "1".
|
||||
Users can enable/disable this debug tracing feature by executing
|
||||
the following command:
|
||||
# echo string > /sys/module/acpi/parameters/trace_state
|
||||
Where "string" should be one of the followings:
|
||||
"disable"
|
||||
Disable the method tracing feature.
|
||||
"enable"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during any method
|
||||
execution will be logged.
|
||||
"method"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method execution
|
||||
of "trace_method_name" will be logged.
|
||||
"method-once"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method execution
|
||||
of "trace_method_name" will be logged only once.
|
||||
"opcode"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method/opcode
|
||||
execution of "trace_method_name" will be logged.
|
||||
"opcode-once"
|
||||
Enable the method tracing feature.
|
||||
ACPICA debugging messages matching
|
||||
"trace_debug_layer/trace_debug_level" during method/opcode
|
||||
execution of "trace_method_name" will be logged only once.
|
||||
Note that, the difference between the "enable" and other feature
|
||||
enabling options are:
|
||||
1. When "enable" is specified, since
|
||||
"trace_debug_layer/trace_debug_level" shall apply to all control
|
||||
method evaluations, after configuring "trace_state" to "enable",
|
||||
"trace_method_name" will be reset to NULL.
|
||||
2. When "method/opcode" is specified, if
|
||||
"trace_method_name" is NULL when "trace_state" is configured to
|
||||
these options, the "trace_debug_layer/trace_debug_level" will
|
||||
apply to all control method evaluations.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,527 @@
|
|||
Adding a New System Call
|
||||
========================
|
||||
|
||||
This document describes what's involved in adding a new system call to the
|
||||
Linux kernel, over and above the normal submission advice in
|
||||
Documentation/SubmittingPatches.
|
||||
|
||||
|
||||
System Call Alternatives
|
||||
------------------------
|
||||
|
||||
The first thing to consider when adding a new system call is whether one of
|
||||
the alternatives might be suitable instead. Although system calls are the
|
||||
most traditional and most obvious interaction points between userspace and the
|
||||
kernel, there are other possibilities -- choose what fits best for your
|
||||
interface.
|
||||
|
||||
- If the operations involved can be made to look like a filesystem-like
|
||||
object, it may make more sense to create a new filesystem or device. This
|
||||
also makes it easier to encapsulate the new functionality in a kernel module
|
||||
rather than requiring it to be built into the main kernel.
|
||||
- If the new functionality involves operations where the kernel notifies
|
||||
userspace that something has happened, then returning a new file
|
||||
descriptor for the relevant object allows userspace to use
|
||||
poll/select/epoll to receive that notification.
|
||||
- However, operations that don't map to read(2)/write(2)-like operations
|
||||
have to be implemented as ioctl(2) requests, which can lead to a
|
||||
somewhat opaque API.
|
||||
- If you're just exposing runtime system information, a new node in sysfs
|
||||
(see Documentation/filesystems/sysfs.txt) or the /proc filesystem may be
|
||||
more appropriate. However, access to these mechanisms requires that the
|
||||
relevant filesystem is mounted, which might not always be the case (e.g.
|
||||
in a namespaced/sandboxed/chrooted environment). Avoid adding any API to
|
||||
debugfs, as this is not considered a 'production' interface to userspace.
|
||||
- If the operation is specific to a particular file or file descriptor, then
|
||||
an additional fcntl(2) command option may be more appropriate. However,
|
||||
fcntl(2) is a multiplexing system call that hides a lot of complexity, so
|
||||
this option is best for when the new function is closely analogous to
|
||||
existing fcntl(2) functionality, or the new functionality is very simple
|
||||
(for example, getting/setting a simple flag related to a file descriptor).
|
||||
- If the operation is specific to a particular task or process, then an
|
||||
additional prctl(2) command option may be more appropriate. As with
|
||||
fcntl(2), this system call is a complicated multiplexor so is best reserved
|
||||
for near-analogs of existing prctl() commands or getting/setting a simple
|
||||
flag related to a process.
|
||||
|
||||
|
||||
Designing the API: Planning for Extension
|
||||
-----------------------------------------
|
||||
|
||||
A new system call forms part of the API of the kernel, and has to be supported
|
||||
indefinitely. As such, it's a very good idea to explicitly discuss the
|
||||
interface on the kernel mailing list, and it's important to plan for future
|
||||
extensions of the interface.
|
||||
|
||||
(The syscall table is littered with historical examples where this wasn't done,
|
||||
together with the corresponding follow-up system calls -- eventfd/eventfd2,
|
||||
dup2/dup3, inotify_init/inotify_init1, pipe/pipe2, renameat/renameat2 -- so
|
||||
learn from the history of the kernel and plan for extensions from the start.)
|
||||
|
||||
For simpler system calls that only take a couple of arguments, the preferred
|
||||
way to allow for future extensibility is to include a flags argument to the
|
||||
system call. To make sure that userspace programs can safely use flags
|
||||
between kernel versions, check whether the flags value holds any unknown
|
||||
flags, and reject the system call (with EINVAL) if it does:
|
||||
|
||||
if (flags & ~(THING_FLAG1 | THING_FLAG2 | THING_FLAG3))
|
||||
return -EINVAL;
|
||||
|
||||
(If no flags values are used yet, check that the flags argument is zero.)
|
||||
|
||||
For more sophisticated system calls that involve a larger number of arguments,
|
||||
it's preferred to encapsulate the majority of the arguments into a structure
|
||||
that is passed in by pointer. Such a structure can cope with future extension
|
||||
by including a size argument in the structure:
|
||||
|
||||
struct xyzzy_params {
|
||||
u32 size; /* userspace sets p->size = sizeof(struct xyzzy_params) */
|
||||
u32 param_1;
|
||||
u64 param_2;
|
||||
u64 param_3;
|
||||
};
|
||||
|
||||
As long as any subsequently added field, say param_4, is designed so that a
|
||||
zero value gives the previous behaviour, then this allows both directions of
|
||||
version mismatch:
|
||||
|
||||
- To cope with a later userspace program calling an older kernel, the kernel
|
||||
code should check that any memory beyond the size of the structure that it
|
||||
expects is zero (effectively checking that param_4 == 0).
|
||||
- To cope with an older userspace program calling a newer kernel, the kernel
|
||||
code can zero-extend a smaller instance of the structure (effectively
|
||||
setting param_4 = 0).
|
||||
|
||||
See perf_event_open(2) and the perf_copy_attr() function (in
|
||||
kernel/events/core.c) for an example of this approach.
|
||||
|
||||
|
||||
Designing the API: Other Considerations
|
||||
---------------------------------------
|
||||
|
||||
If your new system call allows userspace to refer to a kernel object, it
|
||||
should use a file descriptor as the handle for that object -- don't invent a
|
||||
new type of userspace object handle when the kernel already has mechanisms and
|
||||
well-defined semantics for using file descriptors.
|
||||
|
||||
If your new xyzzy(2) system call does return a new file descriptor, then the
|
||||
flags argument should include a value that is equivalent to setting O_CLOEXEC
|
||||
on the new FD. This makes it possible for userspace to close the timing
|
||||
window between xyzzy() and calling fcntl(fd, F_SETFD, FD_CLOEXEC), where an
|
||||
unexpected fork() and execve() in another thread could leak a descriptor to
|
||||
the exec'ed program. (However, resist the temptation to re-use the actual value
|
||||
of the O_CLOEXEC constant, as it is architecture-specific and is part of a
|
||||
numbering space of O_* flags that is fairly full.)
|
||||
|
||||
If your system call returns a new file descriptor, you should also consider
|
||||
what it means to use the poll(2) family of system calls on that file
|
||||
descriptor. Making a file descriptor ready for reading or writing is the
|
||||
normal way for the kernel to indicate to userspace that an event has
|
||||
occurred on the corresponding kernel object.
|
||||
|
||||
If your new xyzzy(2) system call involves a filename argument:
|
||||
|
||||
int sys_xyzzy(const char __user *path, ..., unsigned int flags);
|
||||
|
||||
you should also consider whether an xyzzyat(2) version is more appropriate:
|
||||
|
||||
int sys_xyzzyat(int dfd, const char __user *path, ..., unsigned int flags);
|
||||
|
||||
This allows more flexibility for how userspace specifies the file in question;
|
||||
in particular it allows userspace to request the functionality for an
|
||||
already-opened file descriptor using the AT_EMPTY_PATH flag, effectively giving
|
||||
an fxyzzy(3) operation for free:
|
||||
|
||||
- xyzzyat(AT_FDCWD, path, ..., 0) is equivalent to xyzzy(path,...)
|
||||
- xyzzyat(fd, "", ..., AT_EMPTY_PATH) is equivalent to fxyzzy(fd, ...)
|
||||
|
||||
(For more details on the rationale of the *at() calls, see the openat(2) man
|
||||
page; for an example of AT_EMPTY_PATH, see the statat(2) man page.)
|
||||
|
||||
If your new xyzzy(2) system call involves a parameter describing an offset
|
||||
within a file, make its type loff_t so that 64-bit offsets can be supported
|
||||
even on 32-bit architectures.
|
||||
|
||||
If your new xyzzy(2) system call involves privileged functionality, it needs
|
||||
to be governed by the appropriate Linux capability bit (checked with a call to
|
||||
capable()), as described in the capabilities(7) man page. Choose an existing
|
||||
capability bit that governs related functionality, but try to avoid combining
|
||||
lots of only vaguely related functions together under the same bit, as this
|
||||
goes against capabilities' purpose of splitting the power of root. In
|
||||
particular, avoid adding new uses of the already overly-general CAP_SYS_ADMIN
|
||||
capability.
|
||||
|
||||
If your new xyzzy(2) system call manipulates a process other than the calling
|
||||
process, it should be restricted (using a call to ptrace_may_access()) so that
|
||||
only a calling process with the same permissions as the target process, or
|
||||
with the necessary capabilities, can manipulate the target process.
|
||||
|
||||
Finally, be aware that some non-x86 architectures have an easier time if
|
||||
system call parameters that are explicitly 64-bit fall on odd-numbered
|
||||
arguments (i.e. parameter 1, 3, 5), to allow use of contiguous pairs of 32-bit
|
||||
registers. (This concern does not apply if the arguments are part of a
|
||||
structure that's passed in by pointer.)
|
||||
|
||||
|
||||
Proposing the API
|
||||
-----------------
|
||||
|
||||
To make new system calls easy to review, it's best to divide up the patchset
|
||||
into separate chunks. These should include at least the following items as
|
||||
distinct commits (each of which is described further below):
|
||||
|
||||
- The core implementation of the system call, together with prototypes,
|
||||
generic numbering, Kconfig changes and fallback stub implementation.
|
||||
- Wiring up of the new system call for one particular architecture, usually
|
||||
x86 (including all of x86_64, x86_32 and x32).
|
||||
- A demonstration of the use of the new system call in userspace via a
|
||||
selftest in tools/testing/selftests/.
|
||||
- A draft man-page for the new system call, either as plain text in the
|
||||
cover letter, or as a patch to the (separate) man-pages repository.
|
||||
|
||||
New system call proposals, like any change to the kernel's API, should always
|
||||
be cc'ed to linux-api@vger.kernel.org.
|
||||
|
||||
|
||||
Generic System Call Implementation
|
||||
----------------------------------
|
||||
|
||||
The main entry point for your new xyzzy(2) system call will be called
|
||||
sys_xyzzy(), but you add this entry point with the appropriate
|
||||
SYSCALL_DEFINEn() macro rather than explicitly. The 'n' indicates the number
|
||||
of arguments to the system call, and the macro takes the system call name
|
||||
followed by the (type, name) pairs for the parameters as arguments. Using
|
||||
this macro allows metadata about the new system call to be made available for
|
||||
other tools.
|
||||
|
||||
The new entry point also needs a corresponding function prototype, in
|
||||
include/linux/syscalls.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long sys_xyzzy(...);
|
||||
|
||||
Some architectures (e.g. x86) have their own architecture-specific syscall
|
||||
tables, but several other architectures share a generic syscall table. Add your
|
||||
new system call to the generic list by adding an entry to the list in
|
||||
include/uapi/asm-generic/unistd.h:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SYSCALL(__NR_xyzzy, sys_xyzzy)
|
||||
|
||||
Also update the __NR_syscalls count to reflect the additional system call, and
|
||||
note that if multiple new system calls are added in the same merge window,
|
||||
your new syscall number may get adjusted to resolve conflicts.
|
||||
|
||||
The file kernel/sys_ni.c provides a fallback stub implementation of each system
|
||||
call, returning -ENOSYS. Add your new system call here too:
|
||||
|
||||
cond_syscall(sys_xyzzy);
|
||||
|
||||
Your new kernel functionality, and the system call that controls it, should
|
||||
normally be optional, so add a CONFIG option (typically to init/Kconfig) for
|
||||
it. As usual for new CONFIG options:
|
||||
|
||||
- Include a description of the new functionality and system call controlled
|
||||
by the option.
|
||||
- Make the option depend on EXPERT if it should be hidden from normal users.
|
||||
- Make any new source files implementing the function dependent on the CONFIG
|
||||
option in the Makefile (e.g. "obj-$(CONFIG_XYZZY_SYSCALL) += xyzzy.c").
|
||||
- Double check that the kernel still builds with the new CONFIG option turned
|
||||
off.
|
||||
|
||||
To summarize, you need a commit that includes:
|
||||
|
||||
- CONFIG option for the new function, normally in init/Kconfig
|
||||
- SYSCALL_DEFINEn(xyzzy, ...) for the entry point
|
||||
- corresponding prototype in include/linux/syscalls.h
|
||||
- generic table entry in include/uapi/asm-generic/unistd.h
|
||||
- fallback stub in kernel/sys_ni.c
|
||||
|
||||
|
||||
x86 System Call Implementation
|
||||
------------------------------
|
||||
|
||||
To wire up your new system call for x86 platforms, you need to update the
|
||||
master syscall tables. Assuming your new system call isn't special in some
|
||||
way (see below), this involves a "common" entry (for x86_64 and x32) in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl:
|
||||
|
||||
333 common xyzzy sys_xyzzy
|
||||
|
||||
and an "i386" entry in arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy
|
||||
|
||||
Again, these numbers are liable to be changed if there are conflicts in the
|
||||
relevant merge window.
|
||||
|
||||
|
||||
Compatibility System Calls (Generic)
|
||||
------------------------------------
|
||||
|
||||
For most system calls the same 64-bit implementation can be invoked even when
|
||||
the userspace program is itself 32-bit; even if the system call's parameters
|
||||
include an explicit pointer, this is handled transparently.
|
||||
|
||||
However, there are a couple of situations where a compatibility layer is
|
||||
needed to cope with size differences between 32-bit and 64-bit.
|
||||
|
||||
The first is if the 64-bit kernel also supports 32-bit userspace programs, and
|
||||
so needs to parse areas of (__user) memory that could hold either 32-bit or
|
||||
64-bit values. In particular, this is needed whenever a system call argument
|
||||
is:
|
||||
|
||||
- a pointer to a pointer
|
||||
- a pointer to a struct containing a pointer (e.g. struct iovec __user *)
|
||||
- a pointer to a varying sized integral type (time_t, off_t, long, ...)
|
||||
- a pointer to a struct containing a varying sized integral type.
|
||||
|
||||
The second situation that requires a compatibility layer is if one of the
|
||||
system call's arguments has a type that is explicitly 64-bit even on a 32-bit
|
||||
architecture, for example loff_t or __u64. In this case, a value that arrives
|
||||
at a 64-bit kernel from a 32-bit application will be split into two 32-bit
|
||||
values, which then need to be re-assembled in the compatibility layer.
|
||||
|
||||
(Note that a system call argument that's a pointer to an explicit 64-bit type
|
||||
does *not* need a compatibility layer; for example, splice(2)'s arguments of
|
||||
type loff_t __user * do not trigger the need for a compat_ system call.)
|
||||
|
||||
The compatibility version of the system call is called compat_sys_xyzzy(), and
|
||||
is added with the COMPAT_SYSCALL_DEFINEn() macro, analogously to
|
||||
SYSCALL_DEFINEn. This version of the implementation runs as part of a 64-bit
|
||||
kernel, but expects to receive 32-bit parameter values and does whatever is
|
||||
needed to deal with them. (Typically, the compat_sys_ version converts the
|
||||
values to 64-bit versions and either calls on to the sys_ version, or both of
|
||||
them call a common inner implementation function.)
|
||||
|
||||
The compat entry point also needs a corresponding function prototype, in
|
||||
include/linux/compat.h, marked as asmlinkage to match the way that system
|
||||
calls are invoked:
|
||||
|
||||
asmlinkage long compat_sys_xyzzy(...);
|
||||
|
||||
If the system call involves a structure that is laid out differently on 32-bit
|
||||
and 64-bit systems, say struct xyzzy_args, then the include/linux/compat.h
|
||||
header file should also include a compat version of the structure (struct
|
||||
compat_xyzzy_args) where each variable-size field has the appropriate compat_
|
||||
type that corresponds to the type in struct xyzzy_args. The
|
||||
compat_sys_xyzzy() routine can then use this compat_ structure to parse the
|
||||
arguments from a 32-bit invocation.
|
||||
|
||||
For example, if there are fields:
|
||||
|
||||
struct xyzzy_args {
|
||||
const char __user *ptr;
|
||||
__kernel_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
in struct xyzzy_args, then struct compat_xyzzy_args would have:
|
||||
|
||||
struct compat_xyzzy_args {
|
||||
compat_uptr_t ptr;
|
||||
compat_long_t varying_val;
|
||||
u64 fixed_val;
|
||||
/* ... */
|
||||
};
|
||||
|
||||
The generic system call list also needs adjusting to allow for the compat
|
||||
version; the entry in include/uapi/asm-generic/unistd.h should use
|
||||
__SC_COMP rather than __SYSCALL:
|
||||
|
||||
#define __NR_xyzzy 292
|
||||
__SC_COMP(__NR_xyzzy, sys_xyzzy, compat_sys_xyzzy)
|
||||
|
||||
To summarize, you need:
|
||||
|
||||
- a COMPAT_SYSCALL_DEFINEn(xyzzy, ...) for the compat entry point
|
||||
- corresponding prototype in include/linux/compat.h
|
||||
- (if needed) 32-bit mapping struct in include/linux/compat.h
|
||||
- instance of __SC_COMP not __SYSCALL in include/uapi/asm-generic/unistd.h
|
||||
|
||||
|
||||
Compatibility System Calls (x86)
|
||||
--------------------------------
|
||||
|
||||
To wire up the x86 architecture of a system call with a compatibility version,
|
||||
the entries in the syscall tables need to be adjusted.
|
||||
|
||||
First, the entry in arch/x86/entry/syscalls/syscall_32.tbl gets an extra
|
||||
column to indicate that a 32-bit userspace program running on a 64-bit kernel
|
||||
should hit the compat entry point:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy compat_sys_xyzzy
|
||||
|
||||
Second, you need to figure out what should happen for the x32 ABI version of
|
||||
the new system call. There's a choice here: the layout of the arguments
|
||||
should either match the 64-bit version or the 32-bit version.
|
||||
|
||||
If there's a pointer-to-a-pointer involved, the decision is easy: x32 is
|
||||
ILP32, so the layout should match the 32-bit version, and the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is split so that x32 programs hit the
|
||||
compatibility wrapper:
|
||||
|
||||
333 64 xyzzy sys_xyzzy
|
||||
...
|
||||
555 x32 xyzzy compat_sys_xyzzy
|
||||
|
||||
If no pointers are involved, then it is preferable to re-use the 64-bit system
|
||||
call for the x32 ABI (and consequently the entry in
|
||||
arch/x86/entry/syscalls/syscall_64.tbl is unchanged).
|
||||
|
||||
In either case, you should check that the types involved in your argument
|
||||
layout do indeed map exactly from x32 (-mx32) to either the 32-bit (-m32) or
|
||||
64-bit (-m64) equivalents.
|
||||
|
||||
|
||||
System Calls Returning Elsewhere
|
||||
--------------------------------
|
||||
|
||||
For most system calls, once the system call is complete the user program
|
||||
continues exactly where it left off -- at the next instruction, with the
|
||||
stack the same and most of the registers the same as before the system call,
|
||||
and with the same virtual memory space.
|
||||
|
||||
However, a few system calls do things differently. They might return to a
|
||||
different location (rt_sigreturn) or change the memory space (fork/vfork/clone)
|
||||
or even architecture (execve/execveat) of the program.
|
||||
|
||||
To allow for this, the kernel implementation of the system call may need to
|
||||
save and restore additional registers to the kernel stack, allowing complete
|
||||
control of where and how execution continues after the system call.
|
||||
|
||||
This is arch-specific, but typically involves defining assembly entry points
|
||||
that save/restore additional registers and invoke the real system call entry
|
||||
point.
|
||||
|
||||
For x86_64, this is implemented as a stub_xyzzy entry point in
|
||||
arch/x86/entry/entry_64.S, and the entry in the syscall table
|
||||
(arch/x86/entry/syscalls/syscall_64.tbl) is adjusted to match:
|
||||
|
||||
333 common xyzzy stub_xyzzy
|
||||
|
||||
The equivalent for 32-bit programs running on a 64-bit kernel is normally
|
||||
called stub32_xyzzy and implemented in arch/x86/entry/entry_64_compat.S,
|
||||
with the corresponding syscall table adjustment in
|
||||
arch/x86/entry/syscalls/syscall_32.tbl:
|
||||
|
||||
380 i386 xyzzy sys_xyzzy stub32_xyzzy
|
||||
|
||||
If the system call needs a compatibility layer (as in the previous section)
|
||||
then the stub32_ version needs to call on to the compat_sys_ version of the
|
||||
system call rather than the native 64-bit version. Also, if the x32 ABI
|
||||
implementation is not common with the x86_64 version, then its syscall
|
||||
table will also need to invoke a stub that calls on to the compat_sys_
|
||||
version.
|
||||
|
||||
For completeness, it's also nice to set up a mapping so that user-mode Linux
|
||||
still works -- its syscall table will reference stub_xyzzy, but the UML build
|
||||
doesn't include arch/x86/entry/entry_64.S implementation (because UML
|
||||
simulates registers etc). Fixing this is as simple as adding a #define to
|
||||
arch/x86/um/sys_call_table_64.c:
|
||||
|
||||
#define stub_xyzzy sys_xyzzy
|
||||
|
||||
|
||||
Other Details
|
||||
-------------
|
||||
|
||||
Most of the kernel treats system calls in a generic way, but there is the
|
||||
occasional exception that may need updating for your particular system call.
|
||||
|
||||
The audit subsystem is one such special case; it includes (arch-specific)
|
||||
functions that classify some special types of system call -- specifically
|
||||
file open (open/openat), program execution (execve/exeveat) or socket
|
||||
multiplexor (socketcall) operations. If your new system call is analogous to
|
||||
one of these, then the audit system should be updated.
|
||||
|
||||
More generally, if there is an existing system call that is analogous to your
|
||||
new system call, it's worth doing a kernel-wide grep for the existing system
|
||||
call to check there are no other special cases.
|
||||
|
||||
|
||||
Testing
|
||||
-------
|
||||
|
||||
A new system call should obviously be tested; it is also useful to provide
|
||||
reviewers with a demonstration of how user space programs will use the system
|
||||
call. A good way to combine these aims is to include a simple self-test
|
||||
program in a new directory under tools/testing/selftests/.
|
||||
|
||||
For a new system call, there will obviously be no libc wrapper function and so
|
||||
the test will need to invoke it using syscall(); also, if the system call
|
||||
involves a new userspace-visible structure, the corresponding header will need
|
||||
to be installed to compile the test.
|
||||
|
||||
Make sure the selftest runs successfully on all supported architectures. For
|
||||
example, check that it works when compiled as an x86_64 (-m64), x86_32 (-m32)
|
||||
and x32 (-mx32) ABI program.
|
||||
|
||||
For more extensive and thorough testing of new functionality, you should also
|
||||
consider adding tests to the Linux Test Project, or to the xfstests project
|
||||
for filesystem-related changes.
|
||||
- https://linux-test-project.github.io/
|
||||
- git://git.kernel.org/pub/scm/fs/xfs/xfstests-dev.git
|
||||
|
||||
|
||||
Man Page
|
||||
--------
|
||||
|
||||
All new system calls should come with a complete man page, ideally using groff
|
||||
markup, but plain text will do. If groff is used, it's helpful to include a
|
||||
pre-rendered ASCII version of the man page in the cover email for the
|
||||
patchset, for the convenience of reviewers.
|
||||
|
||||
The man page should be cc'ed to linux-man@vger.kernel.org
|
||||
For more details, see https://www.kernel.org/doc/man-pages/patches.html
|
||||
|
||||
References and Sources
|
||||
----------------------
|
||||
|
||||
- LWN article from Michael Kerrisk on use of flags argument in system calls:
|
||||
https://lwn.net/Articles/585415/
|
||||
- LWN article from Michael Kerrisk on how to handle unknown flags in a system
|
||||
call: https://lwn.net/Articles/588444/
|
||||
- LWN article from Jake Edge describing constraints on 64-bit system call
|
||||
arguments: https://lwn.net/Articles/311630/
|
||||
- Pair of LWN articles from David Drysdale that describe the system call
|
||||
implementation paths in detail for v3.14:
|
||||
- https://lwn.net/Articles/604287/
|
||||
- https://lwn.net/Articles/604515/
|
||||
- Architecture-specific requirements for system calls are discussed in the
|
||||
syscall(2) man-page:
|
||||
http://man7.org/linux/man-pages/man2/syscall.2.html#NOTES
|
||||
- Collated emails from Linus Torvalds discussing the problems with ioctl():
|
||||
http://yarchive.net/comp/linux/ioctl.html
|
||||
- "How to not invent kernel interfaces", Arnd Bergmann,
|
||||
http://www.ukuug.org/events/linux2007/2007/papers/Bergmann.pdf
|
||||
- LWN article from Michael Kerrisk on avoiding new uses of CAP_SYS_ADMIN:
|
||||
https://lwn.net/Articles/486306/
|
||||
- Recommendation from Andrew Morton that all related information for a new
|
||||
system call should come in the same email thread:
|
||||
https://lkml.org/lkml/2014/7/24/641
|
||||
- Recommendation from Michael Kerrisk that a new system call should come with
|
||||
a man page: https://lkml.org/lkml/2014/6/13/309
|
||||
- Suggestion from Thomas Gleixner that x86 wire-up should be in a separate
|
||||
commit: https://lkml.org/lkml/2014/11/19/254
|
||||
- Suggestion from Greg Kroah-Hartman that it's good for new system calls to
|
||||
come with a man-page & selftest: https://lkml.org/lkml/2014/3/19/710
|
||||
- Discussion from Michael Kerrisk of new system call vs. prctl(2) extension:
|
||||
https://lkml.org/lkml/2014/6/3/411
|
||||
- Suggestion from Ingo Molnar that system calls that involve multiple
|
||||
arguments should encapsulate those arguments in a struct, which includes a
|
||||
size field for future extensibility: https://lkml.org/lkml/2015/7/30/117
|
||||
- Numbering oddities arising from (re-)use of O_* numbering space flags:
|
||||
- commit 75069f2b5bfb ("vfs: renumber FMODE_NONOTIFY and add to uniqueness
|
||||
check")
|
||||
- commit 12ed2e36c98a ("fanotify: FMODE_NONOTIFY and __O_SYNC in sparc
|
||||
conflict")
|
||||
- commit bb458c644a59 ("Safer ABI for O_TMPFILE")
|
||||
- Discussion from Matthew Wilcox about restrictions on 64-bit arguments:
|
||||
https://lkml.org/lkml/2008/12/12/187
|
||||
- Recommendation from Greg Kroah-Hartman that unknown flags should be
|
||||
policed: https://lkml.org/lkml/2014/7/17/577
|
||||
- Recommendation from Linus Torvalds that x32 system calls should prefer
|
||||
compatibility with 64-bit versions rather than 32-bit versions:
|
||||
https://lkml.org/lkml/2011/8/31/244
|
||||
|
|
@ -90,6 +90,11 @@ the Atmel website: http://www.atmel.com.
|
|||
+ Datasheet
|
||||
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
|
||||
|
||||
- sama5d2 family
|
||||
- sama5d27
|
||||
+ Datasheet
|
||||
Coming soon
|
||||
|
||||
|
||||
Linux kernel information
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -15,6 +15,7 @@ executing kernel.
|
|||
|
||||
|
||||
1. Non-Secure mode
|
||||
|
||||
Address: sysram_ns_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -28,6 +29,7 @@ Offset Value Purpose
|
|||
|
||||
|
||||
2. Secure mode
|
||||
|
||||
Address: sysram_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
|
|
@ -40,14 +42,25 @@ Offset Value Purpose
|
|||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0800 exynos_cpu_resume AFTR
|
||||
0x0800 exynos_cpu_resume AFTR, suspend
|
||||
0x0800 mcpm_entry_point (Exynos542x with MCPM) AFTR, suspend
|
||||
0x0804 0xfcba0d10 (Magic cookie) AFTR
|
||||
0x0804 0x00000bad (Magic cookie) System suspend
|
||||
0x0814 exynos4_secondary_startup (Exynos4210 r1.1) Secondary CPU boot
|
||||
0x0818 0xfcba0d10 (Magic cookie, Exynos4210 r1.1) AFTR
|
||||
0x081C exynos_cpu_resume (Exynos4210 r1.1) AFTR
|
||||
|
||||
|
||||
3. Other (regardless of secure/non-secure mode)
|
||||
|
||||
Address: pmu_base_addr
|
||||
Offset Value Purpose
|
||||
=============================================================================
|
||||
0x0908 Non-zero (only Exynos3250) Secondary CPU boot up indicator
|
||||
|
||||
|
||||
4. Glossary
|
||||
|
||||
AFTR - ARM Off Top Running, a low power mode, Cortex cores and many other
|
||||
modules are power gated, except the TOP modules
|
||||
MCPM - Multi-Cluster Power Management
|
||||
|
|
|
|||
|
|
@ -0,0 +1,73 @@
|
|||
TI Keystone Linux Overview
|
||||
--------------------------
|
||||
|
||||
Introduction
|
||||
------------
|
||||
Keystone range of SoCs are based on ARM Cortex-A15 MPCore Processors
|
||||
and c66x DSP cores. This document describes essential information required
|
||||
for users to run Linux on Keystone based EVMs from Texas Instruments.
|
||||
|
||||
Following SoCs & EVMs are currently supported:-
|
||||
|
||||
------------ K2HK SoC and EVM --------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Hawking/Kepler SoC
|
||||
TCI6636K2H & TCI6636K2K: See documentation at
|
||||
http://www.ti.com/product/tci6638k2k
|
||||
http://www.ti.com/product/tci6638k2h
|
||||
|
||||
EVM:
|
||||
http://www.advantech.com/Support/TI-EVM/EVMK2HX_sd.aspx
|
||||
|
||||
------------ K2E SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Edison SoC
|
||||
K2E - 66AK2E05: See documentation at
|
||||
http://www.ti.com/product/66AK2E05/technicaldocuments
|
||||
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2e-evm.html
|
||||
|
||||
------------ K2L SoC and EVM ---------------------------------------------------
|
||||
|
||||
a.k.a Keystone 2 Lamarr SoC
|
||||
K2L - TCI6630K2L: See documentation at
|
||||
http://www.ti.com/product/TCI6630K2L/technicaldocuments
|
||||
EVM:
|
||||
https://www.einfochips.com/index.php/partnerships/texas-instruments/k2l-evm.html
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
All of the K2 SoCs/EVMs share a common defconfig, keystone_defconfig and same
|
||||
image is used to boot on individual EVMs. The platform configuration is
|
||||
specified through DTS. Following are the DTS used:-
|
||||
K2HK EVM : k2hk-evm.dts
|
||||
K2E EVM : k2e-evm.dts
|
||||
K2L EVM : k2l-evm.dts
|
||||
|
||||
The device tree documentation for the keystone machines are located at
|
||||
Documentation/devicetree/bindings/arm/keystone/keystone.txt
|
||||
|
||||
Known issues & workaround
|
||||
-------------------------
|
||||
|
||||
Some of the device drivers used on keystone are re-used from that from
|
||||
DaVinci and other TI SoCs. These device drivers may use clock APIs directly.
|
||||
Some of the keystone specific drivers such as netcp uses run time power
|
||||
management API instead to enable clock. As this API has limitations on
|
||||
keystone, following workaround is needed to boot Linux.
|
||||
|
||||
Add 'clk_ignore_unused' to the bootargs env variable in u-boot. Otherwise
|
||||
clock frameworks will try to disable clocks that are unused and disable
|
||||
the hardware. This is because netcp related power domain and clock
|
||||
domains are enabled in u-boot as run time power management API currently
|
||||
doesn't enable clocks for netcp due to a limitation. This workaround is
|
||||
expected to be removed in the future when proper API support becomes
|
||||
available. Until then, this work around is needed.
|
||||
|
||||
|
||||
Document Author
|
||||
---------------
|
||||
Murali Karicheri <m-karicheri2@ti.com>
|
||||
Copyright 2015 Texas Instruments
|
||||
|
|
@ -1109,7 +1109,7 @@ it will loop and handle as many sectors (on a bio-segment granularity)
|
|||
as specified.
|
||||
|
||||
Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the
|
||||
right thing to use is bio_endio(bio, uptodate) instead.
|
||||
right thing to use is bio_endio(bio) instead.
|
||||
|
||||
If the driver is dropping the io_request_lock from its request_fn strategy,
|
||||
then it just needs to replace that with q->queue_lock instead.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ particular, presenting the illusion of partially completed biovecs so that
|
|||
normal code doesn't have to deal with bi_bvec_done.
|
||||
|
||||
* Driver code should no longer refer to biovecs directly; we now have
|
||||
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
|
||||
bio_iovec() and bio_iter_iovec() macros that return literal struct biovecs,
|
||||
constructed from the raw biovecs but taking into account bi_bvec_done and
|
||||
bi_size.
|
||||
|
||||
|
|
@ -109,3 +109,11 @@ Other implications:
|
|||
over all the biovecs in the new bio - which is silly as it's not needed.
|
||||
|
||||
So, don't use bi_vcnt anymore.
|
||||
|
||||
* The current interface allows the block layer to split bios as needed, so we
|
||||
could eliminate a lot of complexity particularly in stacked drivers. Code
|
||||
that creates bios can then create whatever size bios are convenient, and
|
||||
more importantly stacked drivers don't have to deal with both their own bio
|
||||
size limitations and the limitations of the underlying devices. Thus
|
||||
there's no need to define ->merge_bvec_fn() callbacks for individual block
|
||||
drivers.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This shows the size of internal allocation of the device in bytes, if
|
|||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
discard_max_hw_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
|
|
@ -29,6 +29,14 @@ number of bytes that can be discarded in a single operation. Discard
|
|||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_max_bytes (RW)
|
||||
----------------------
|
||||
While discard_max_hw_bytes is the hardware limit for the device, this
|
||||
setting is the software limit. Some devices exhibit large latencies when
|
||||
large discards are issued, setting this value lower will make Linux issue
|
||||
smaller discards and potentially help reduce latencies induced by large
|
||||
discard operations.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
|
|
|
|||
|
|
@ -22,6 +22,8 @@ net_cls.txt
|
|||
- Network classifier cgroups details and usages.
|
||||
net_prio.txt
|
||||
- Network priority cgroups details and usages.
|
||||
pids.txt
|
||||
- Process number cgroups details and usages.
|
||||
resource_counter.txt
|
||||
- Resource Counter API.
|
||||
unified-hierarchy.txt
|
||||
|
|
|
|||
|
|
@ -0,0 +1,85 @@
|
|||
Process Number Controller
|
||||
=========================
|
||||
|
||||
Abstract
|
||||
--------
|
||||
|
||||
The process number controller is used to allow a cgroup hierarchy to stop any
|
||||
new tasks from being fork()'d or clone()'d after a certain limit is reached.
|
||||
|
||||
Since it is trivial to hit the task limit without hitting any kmemcg limits in
|
||||
place, PIDs are a fundamental resource. As such, PID exhaustion must be
|
||||
preventable in the scope of a cgroup hierarchy by allowing resource limiting of
|
||||
the number of tasks in a cgroup.
|
||||
|
||||
Usage
|
||||
-----
|
||||
|
||||
In order to use the `pids` controller, set the maximum number of tasks in
|
||||
pids.max (this is not available in the root cgroup for obvious reasons). The
|
||||
number of processes currently in the cgroup is given by pids.current.
|
||||
|
||||
Organisational operations are not blocked by cgroup policies, so it is possible
|
||||
to have pids.current > pids.max. This can be done by either setting the limit to
|
||||
be smaller than pids.current, or attaching enough processes to the cgroup such
|
||||
that pids.current > pids.max. However, it is not possible to violate a cgroup
|
||||
policy through fork() or clone(). fork() and clone() will return -EAGAIN if the
|
||||
creation of a new process would cause a cgroup policy to be violated.
|
||||
|
||||
To set a cgroup to have no limit, set pids.max to "max". This is the default for
|
||||
all new cgroups (N.B. that PID limits are hierarchical, so the most stringent
|
||||
limit in the hierarchy is followed).
|
||||
|
||||
pids.current tracks all child cgroup hierarchies, so parent/pids.current is a
|
||||
superset of parent/child/pids.current.
|
||||
|
||||
Example
|
||||
-------
|
||||
|
||||
First, we mount the pids controller:
|
||||
# mkdir -p /sys/fs/cgroup/pids
|
||||
# mount -t cgroup -o pids none /sys/fs/cgroup/pids
|
||||
|
||||
Then we create a hierarchy, set limits and attach processes to it:
|
||||
# mkdir -p /sys/fs/cgroup/pids/parent/child
|
||||
# echo 2 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# echo $$ > /sys/fs/cgroup/pids/parent/cgroup.procs
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
#
|
||||
|
||||
It should be noted that attempts to overcome the set limit (2 in this case) will
|
||||
fail:
|
||||
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
# ( /bin/echo "Here's some processes for you." | cat )
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
||||
Even if we migrate to a child cgroup (which doesn't have a set limit), we will
|
||||
not be able to overcome the most stringent limit in the hierarchy (in this case,
|
||||
parent's):
|
||||
|
||||
# echo $$ > /sys/fs/cgroup/pids/parent/child/cgroup.procs
|
||||
# cat /sys/fs/cgroup/pids/parent/pids.current
|
||||
2
|
||||
# cat /sys/fs/cgroup/pids/parent/child/pids.current
|
||||
2
|
||||
# cat /sys/fs/cgroup/pids/parent/child/pids.max
|
||||
max
|
||||
# ( /bin/echo "Here's some processes for you." | cat )
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
||||
We can set a limit that is smaller than pids.current, which will stop any new
|
||||
processes from being forked at all (note that the shell itself counts towards
|
||||
pids.current):
|
||||
|
||||
# echo 1 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# /bin/echo "We can't even spawn a single process now."
|
||||
sh: fork: Resource temporary unavailable
|
||||
# echo 0 > /sys/fs/cgroup/pids/parent/pids.max
|
||||
# /bin/echo "We can't even spawn a single process now."
|
||||
sh: fork: Resource temporary unavailable
|
||||
#
|
||||
|
|
@ -23,10 +23,13 @@ CONTENTS
|
|||
5. Other Changes
|
||||
5-1. [Un]populated Notification
|
||||
5-2. Other Core Changes
|
||||
5-3. Per-Controller Changes
|
||||
5-3-1. blkio
|
||||
5-3-2. cpuset
|
||||
5-3-3. memory
|
||||
5-3. Controller File Conventions
|
||||
5-3-1. Format
|
||||
5-3-2. Control Knobs
|
||||
5-4. Per-Controller Changes
|
||||
5-4-1. blkio
|
||||
5-4-2. cpuset
|
||||
5-4-3. memory
|
||||
6. Planned Changes
|
||||
6-1. CAP for resource control
|
||||
|
||||
|
|
@ -372,14 +375,75 @@ supported and the interface files "release_agent" and
|
|||
- The "cgroup.clone_children" file is removed.
|
||||
|
||||
|
||||
5-3. Per-Controller Changes
|
||||
5-3. Controller File Conventions
|
||||
|
||||
5-3-1. blkio
|
||||
5-3-1. Format
|
||||
|
||||
In general, all controller files should be in one of the following
|
||||
formats whenever possible.
|
||||
|
||||
- Values only files
|
||||
|
||||
VAL0 VAL1...\n
|
||||
|
||||
- Flat keyed files
|
||||
|
||||
KEY0 VAL0\n
|
||||
KEY1 VAL1\n
|
||||
...
|
||||
|
||||
- Nested keyed files
|
||||
|
||||
KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01...
|
||||
KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11...
|
||||
...
|
||||
|
||||
For a writeable file, the format for writing should generally match
|
||||
reading; however, controllers may allow omitting later fields or
|
||||
implement restricted shortcuts for most common use cases.
|
||||
|
||||
For both flat and nested keyed files, only the values for a single key
|
||||
can be written at a time. For nested keyed files, the sub key pairs
|
||||
may be specified in any order and not all pairs have to be specified.
|
||||
|
||||
|
||||
5-3-2. Control Knobs
|
||||
|
||||
- Settings for a single feature should generally be implemented in a
|
||||
single file.
|
||||
|
||||
- In general, the root cgroup should be exempt from resource control
|
||||
and thus shouldn't have resource control knobs.
|
||||
|
||||
- If a controller implements ratio based resource distribution, the
|
||||
control knob should be named "weight" and have the range [1, 10000]
|
||||
and 100 should be the default value. The values are chosen to allow
|
||||
enough and symmetric bias in both directions while keeping it
|
||||
intuitive (the default is 100%).
|
||||
|
||||
- If a controller implements an absolute resource guarantee and/or
|
||||
limit, the control knobs should be named "min" and "max"
|
||||
respectively. If a controller implements best effort resource
|
||||
gurantee and/or limit, the control knobs should be named "low" and
|
||||
"high" respectively.
|
||||
|
||||
In the above four control files, the special token "max" should be
|
||||
used to represent upward infinity for both reading and writing.
|
||||
|
||||
- If a setting has configurable default value and specific overrides,
|
||||
the default settings should be keyed with "default" and appear as
|
||||
the first entry in the file. Specific entries can use "default" as
|
||||
its value to indicate inheritance of the default value.
|
||||
|
||||
|
||||
5-4. Per-Controller Changes
|
||||
|
||||
5-4-1. blkio
|
||||
|
||||
- blk-throttle becomes properly hierarchical.
|
||||
|
||||
|
||||
5-3-2. cpuset
|
||||
5-4-2. cpuset
|
||||
|
||||
- Tasks are kept in empty cpusets after hotplug and take on the masks
|
||||
of the nearest non-empty ancestor, instead of being moved to it.
|
||||
|
|
@ -388,7 +452,7 @@ supported and the interface files "release_agent" and
|
|||
masks of the nearest non-empty ancestor.
|
||||
|
||||
|
||||
5-3-3. memory
|
||||
5-4-3. memory
|
||||
|
||||
- use_hierarchy is on by default and the cgroup file for the flag is
|
||||
not created.
|
||||
|
|
|
|||
|
|
@ -71,12 +71,8 @@ the operations defined in clk.h:
|
|||
long (*round_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long *parent_rate);
|
||||
long (*determine_rate)(struct clk_hw *hw,
|
||||
unsigned long rate,
|
||||
unsigned long min_rate,
|
||||
unsigned long max_rate,
|
||||
unsigned long *best_parent_rate,
|
||||
struct clk_hw **best_parent_clk);
|
||||
int (*determine_rate)(struct clk_hw *hw,
|
||||
struct clk_rate_request *req);
|
||||
int (*set_parent)(struct clk_hw *hw, u8 index);
|
||||
u8 (*get_parent)(struct clk_hw *hw);
|
||||
int (*set_rate)(struct clk_hw *hw,
|
||||
|
|
|
|||
|
|
@ -55,16 +55,13 @@ transition notifiers.
|
|||
----------------------------
|
||||
|
||||
These are notified when a new policy is intended to be set. Each
|
||||
CPUFreq policy notifier is called three times for a policy transition:
|
||||
CPUFreq policy notifier is called twice for a policy transition:
|
||||
|
||||
1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
|
||||
they see a need for this - may it be thermal considerations or
|
||||
hardware limitations.
|
||||
|
||||
2.) During CPUFREQ_INCOMPATIBLE only changes may be done in order to avoid
|
||||
hardware failure.
|
||||
|
||||
3.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
|
||||
2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
|
||||
- if two hardware drivers failed to agree on a new policy before this
|
||||
stage, the incompatible hardware shall be shut down, and the user
|
||||
informed of this.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,17 @@
|
|||
* ARC HS Performance Counters
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,archs-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,archs-pct";
|
||||
};
|
||||
|
|
@ -27,6 +27,8 @@ compatible: must be one of:
|
|||
o "atmel,at91sam9xe"
|
||||
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
||||
SoC family:
|
||||
o "atmel,sama5d2" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d27"
|
||||
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d31"
|
||||
- "atmel,sama5d33"
|
||||
|
|
@ -50,6 +52,7 @@ System Timer (ST) required properties:
|
|||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
|
|
@ -61,7 +64,7 @@ TC/TCLIB Timer required properties:
|
|||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
- clock-names: tuple listing input clock names.
|
||||
Required elements: "t0_clk"
|
||||
Required elements: "t0_clk", "slow_clk"
|
||||
Optional elements: "t1_clk", "t2_clk"
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
|
|
@ -87,14 +90,16 @@ One interrupt per TC channel in a TC block:
|
|||
|
||||
RSTC Reset Controller required properties:
|
||||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45"
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
|
|
@ -117,6 +122,7 @@ required properties:
|
|||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
|
|
@ -135,9 +141,10 @@ optional at91sam9x5 properties:
|
|||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
|
|
|||
|
|
@ -0,0 +1,9 @@
|
|||
Broadcom North Star 2 (NS2) device tree bindings
|
||||
------------------------------------------------
|
||||
|
||||
Boards with NS2 shall have the following properties:
|
||||
|
||||
Required root node property:
|
||||
|
||||
NS2 SVK board
|
||||
compatible = "brcm,ns2-svk", "brcm,ns2";
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Raspberry Pi VideoCore firmware driver
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "raspberrypi,bcm2835-firmware"
|
||||
- mboxes: Phandle to the firmware device's Mailbox.
|
||||
(See: ../mailbox/mailbox.txt for more information)
|
||||
|
||||
Example:
|
||||
|
||||
firmware {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
};
|
||||
|
|
@ -17,6 +17,7 @@ its hardware characteristcs.
|
|||
- "arm,coresight-tmc", "arm,primecell";
|
||||
- "arm,coresight-funnel", "arm,primecell";
|
||||
- "arm,coresight-etm3x", "arm,primecell";
|
||||
- "arm,coresight-etm4x", "arm,primecell";
|
||||
- "qcom,coresight-replicator1x", "arm,primecell";
|
||||
|
||||
* reg: physical base address and length of the register
|
||||
|
|
|
|||
|
|
@ -199,6 +199,7 @@ nodes to be present and contain the properties described below.
|
|||
"qcom,kpss-acc-v1"
|
||||
"qcom,kpss-acc-v2"
|
||||
"rockchip,rk3066-smp"
|
||||
"ste,dbx500-smp"
|
||||
|
||||
- cpu-release-addr
|
||||
Usage: required for systems that have an "enable-method"
|
||||
|
|
|
|||
|
|
@ -127,6 +127,24 @@ Example:
|
|||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
|
||||
Hisilicon Hi6220 SRAM controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "hisilicon,hi6220-sramctrl", "syscon"
|
||||
- reg : Register address and size
|
||||
|
||||
Hisilicon's SoCs use sram for multiple purpose; on Hi6220 there have several
|
||||
SRAM banks for power management, modem, security, etc. Further, use "syscon"
|
||||
managing the common sram which can be shared by multiple modules.
|
||||
|
||||
Example:
|
||||
/*for Hi6220*/
|
||||
sram: sram@fff80000 {
|
||||
compatible = "hisilicon,hi6220-sramctrl", "syscon";
|
||||
reg = <0x0 0xfff80000 0x0 0x12000>;
|
||||
};
|
||||
|
||||
-----------------------------------------------------------------------
|
||||
Hisilicon HiP01 system controller
|
||||
|
||||
|
|
|
|||
|
|
@ -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,83 @@
|
|||
Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
|
||||
|
||||
Required properties:
|
||||
- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names.
|
||||
- clock-names: Should contain the following:
|
||||
"cpu" - The multiplexer for clock input of CPU cluster.
|
||||
"intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
|
||||
source (usually MAINPLL) when the original CPU PLL is under
|
||||
transition and not stable yet.
|
||||
Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
|
||||
generic clock consumer properties.
|
||||
- proc-supply: Regulator for Vproc of CPU cluster.
|
||||
|
||||
Optional properties:
|
||||
- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver
|
||||
needs to do "voltage tracking" to step by step scale up/down Vproc and
|
||||
Vsram to fit SoC specific needs. When absent, the voltage scaling
|
||||
flow is handled by hardware, hence no software "voltage tracking" is
|
||||
needed.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x000>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA53SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu1: cpu@1 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a53";
|
||||
reg = <0x001>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA53SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu2: cpu@100 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x100>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA57SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
cpu3: cpu@101 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a57";
|
||||
reg = <0x101>;
|
||||
enable-method = "psci";
|
||||
cpu-idle-states = <&CPU_SLEEP_0>;
|
||||
clocks = <&infracfg CLK_INFRA_CA57SEL>,
|
||||
<&apmixedsys CLK_APMIXED_MAINPLL>;
|
||||
clock-names = "cpu", "intermediate";
|
||||
};
|
||||
|
||||
&cpu0 {
|
||||
proc-supply = <&mt6397_vpca15_reg>;
|
||||
};
|
||||
|
||||
&cpu1 {
|
||||
proc-supply = <&mt6397_vpca15_reg>;
|
||||
};
|
||||
|
||||
&cpu2 {
|
||||
proc-supply = <&da9211_vcpu_reg>;
|
||||
sram-supply = <&mt6397_vsramca7_reg>;
|
||||
};
|
||||
|
||||
&cpu3 {
|
||||
proc-supply = <&da9211_vcpu_reg>;
|
||||
sram-supply = <&mt6397_vsramca7_reg>;
|
||||
};
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
NVIDIA Tegra124 DFLL FCPU clocksource
|
||||
|
||||
This binding uses the common clock binding:
|
||||
Documentation/devicetree/bindings/clock/clock-bindings.txt
|
||||
|
||||
The DFLL IP block on Tegra is a root clocksource designed for clocking
|
||||
the fast CPU cluster. It consists of a free-running voltage controlled
|
||||
oscillator connected to the CPU voltage rail (VDD_CPU), and a closed loop
|
||||
control module that will automatically adjust the VDD_CPU voltage by
|
||||
communicating with an off-chip PMIC either via an I2C bus or via PWM signals.
|
||||
Currently only the I2C mode is supported by these bindings.
|
||||
|
||||
Required properties:
|
||||
- compatible : should be "nvidia,tegra124-dfll"
|
||||
- reg : Defines the following set of registers, in the order listed:
|
||||
- registers for the DFLL control logic.
|
||||
- registers for the I2C output logic.
|
||||
- registers for the integrated I2C master controller.
|
||||
- look-up table RAM for voltage register values.
|
||||
- interrupts: Should contain the DFLL block interrupt.
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- soc: Clock source for the DFLL control logic.
|
||||
- ref: The closed loop reference clock
|
||||
- i2c: Clock source for the integrated I2C master.
|
||||
- resets: Must contain an entry for each entry in reset-names.
|
||||
See ../reset/reset.txt for details.
|
||||
- reset-names: Must include the following entries:
|
||||
- dvco: Reset control for the DFLL DVCO.
|
||||
- #clock-cells: Must be 0.
|
||||
- clock-output-names: Name of the clock output.
|
||||
- vdd-cpu-supply: Regulator for the CPU voltage rail that the DFLL
|
||||
hardware will start controlling. The regulator will be queried for
|
||||
the I2C register, control values and supported voltages.
|
||||
|
||||
Required properties for the control loop parameters:
|
||||
- nvidia,sample-rate: Sample rate of the DFLL control loop.
|
||||
- nvidia,droop-ctrl: See the register CL_DVFS_DROOP_CTRL in the TRM.
|
||||
- nvidia,force-mode: See the field DFLL_PARAMS_FORCE_MODE in the TRM.
|
||||
- nvidia,cf: Numeric value, see the field DFLL_PARAMS_CF_PARAM in the TRM.
|
||||
- nvidia,ci: Numeric value, see the field DFLL_PARAMS_CI_PARAM in the TRM.
|
||||
- nvidia,cg: Numeric value, see the field DFLL_PARAMS_CG_PARAM in the TRM.
|
||||
|
||||
Optional properties for the control loop parameters:
|
||||
- nvidia,cg-scale: Boolean value, see the field DFLL_PARAMS_CG_SCALE in the TRM.
|
||||
|
||||
Required properties for I2C mode:
|
||||
- nvidia,i2c-fs-rate: I2C transfer rate, if using full speed mode.
|
||||
|
||||
Example:
|
||||
|
||||
clock@0,70110000 {
|
||||
compatible = "nvidia,tegra124-dfll";
|
||||
reg = <0 0x70110000 0 0x100>, /* DFLL control */
|
||||
<0 0x70110000 0 0x100>, /* I2C output control */
|
||||
<0 0x70110100 0 0x100>, /* Integrated I2C controller */
|
||||
<0 0x70110200 0 0x100>; /* Look-up table RAM */
|
||||
interrupts = <GIC_SPI 62 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&tegra_car TEGRA124_CLK_DFLL_SOC>,
|
||||
<&tegra_car TEGRA124_CLK_DFLL_REF>,
|
||||
<&tegra_car TEGRA124_CLK_I2C5>;
|
||||
clock-names = "soc", "ref", "i2c";
|
||||
resets = <&tegra_car TEGRA124_RST_DFLL_DVCO>;
|
||||
reset-names = "dvco";
|
||||
#clock-cells = <0>;
|
||||
clock-output-names = "dfllCPU_out";
|
||||
vdd-cpu-supply = <&vdd_cpu>;
|
||||
status = "okay";
|
||||
|
||||
nvidia,sample-rate = <12500>;
|
||||
nvidia,droop-ctrl = <0x00000f00>;
|
||||
nvidia,force-mode = <1>;
|
||||
nvidia,cf = <10>;
|
||||
nvidia,ci = <0>;
|
||||
nvidia,cg = <2>;
|
||||
|
||||
nvidia,i2c-fs-rate = <400000>;
|
||||
};
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7778 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7778. It includes two PLLs and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -10,10 +12,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are
|
||||
"plla", "pllb", "b", "out", "p", "s", and "s1".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7778-cpg-clocks";
|
||||
|
|
@ -22,4 +32,17 @@ Example
|
|||
clocks = <&extal_clk>;
|
||||
clock-output-names = "plla", "pllb", "b",
|
||||
"out", "p", "s", "s1";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sdhi0: sd@ffe4c000 {
|
||||
compatible = "renesas,sdhi-r8a7778";
|
||||
reg = <0xffe4c000 0x100>;
|
||||
interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7779 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7779. It includes one PLL and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -12,16 +14,36 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "plla",
|
||||
"z", "zs", "s", "s1", "p", "b", "out".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7779-cpg-clocks";
|
||||
reg = <0 0xffc80000 0 0x30>;
|
||||
reg = <0xffc80000 0x30>;
|
||||
clocks = <&extal_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "plla", "z", "zs", "s", "s1", "p",
|
||||
"b", "out";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sata: sata@fc600000 {
|
||||
compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
|
||||
reg = <0xfc600000 0x2000>;
|
||||
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7779_CLK_SATA>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
|
||||
and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -20,10 +22,18 @@ Required Properties:
|
|||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
||||
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
|
||||
"adsp"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@e6150000 {
|
||||
compatible = "renesas,r8a7790-cpg-clocks",
|
||||
|
|
@ -34,4 +44,16 @@ Example
|
|||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
||||
"lb", "qspi", "sdh", "sd0", "sd1", "z",
|
||||
"rcan", "adsp";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
thermal@e61f0000 {
|
||||
compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
|
||||
reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
|
||||
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
|
||||
CPU and GPU clocks, and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -14,10 +16,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "pll",
|
||||
"i", and "g"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@fcfe0000 {
|
||||
#clock-cells = <1>;
|
||||
|
|
@ -26,4 +36,19 @@ Example
|
|||
reg = <0xfcfe0000 0x18>;
|
||||
clocks = <&extal_clk>, <&usb_x1_clk>;
|
||||
clock-output-names = "pll", "i", "g";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
mtu2: timer@fcff0000 {
|
||||
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
|
||||
reg = <0xfcff0000 0x400>;
|
||||
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tgi0a";
|
||||
clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,61 @@
|
|||
* Rockchip RK3368 Clock and Reset Unit
|
||||
|
||||
The RK3368 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "rockchip,rk3368-cru"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files"
|
||||
If missing, pll rates are not changeable, due to the missing pll lock status.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All available clocks are defined as
|
||||
preprocessor macros in the dt-bindings/clock/rk3368-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
|
||||
External clocks:
|
||||
|
||||
There are several clocks that are generated outside the SoC. It is expected
|
||||
that they are defined using standard clock bindings with following
|
||||
clock-output-names:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "ext_i2s" - external I2S clock - optional,
|
||||
- "ext_gmac" - external GMAC clock - optional
|
||||
- "ext_hsadc" - external HSADC clock - optional,
|
||||
- "ext_isp" - external ISP clock - optional,
|
||||
- "ext_jtag" - external JTAG clock - optional
|
||||
- "ext_vip" - external VIP clock - optional,
|
||||
- "usbotg_out" - output clock of the pll in the otg phy
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
cru: clock-controller@ff760000 {
|
||||
compatible = "rockchip,rk3368-cru";
|
||||
reg = <0x0 0xff760000 0x0 0x1000>;
|
||||
rockchip,grf = <&grf>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock generated by the clock
|
||||
controller:
|
||||
|
||||
uart0: serial@10124000 {
|
||||
compatible = "snps,dw-apb-uart";
|
||||
reg = <0x10124000 0x400>;
|
||||
interrupts = <GIC_SPI 34 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <1>;
|
||||
clocks = <&cru SCLK_UART0>;
|
||||
};
|
||||
|
|
@ -21,8 +21,8 @@ Required properties:
|
|||
"st,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_0", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_1", "st,clkgen-plls-c32"
|
||||
|
||||
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,64 @@
|
|||
Clock bindings for ST-Ericsson Ux500 clocks
|
||||
|
||||
Required properties :
|
||||
- compatible : shall contain only one of the following:
|
||||
"stericsson,u8500-clks"
|
||||
"stericsson,u8540-clks"
|
||||
"stericsson,u9540-clks"
|
||||
- reg : shall contain base register location and length for
|
||||
CLKRST1, 2, 3, 5, and 6 in an array. Note the absence of
|
||||
CLKRST4, which does not exist.
|
||||
|
||||
Required subnodes:
|
||||
- prcmu-clock: a subnode with one clock cell for PRCMU (power,
|
||||
reset, control unit) clocks. The cell indicates which PRCMU
|
||||
clock in the prcmu-clock node the consumer wants to use.
|
||||
- prcc-periph-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) peripheral clocks.
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- prcc-kernel-clock: a subnode with two clock cells for
|
||||
PRCC (programmable reset- and clock controller) kernel clocks
|
||||
The first cell indicates which PRCC block the consumer
|
||||
wants to use, possible values are 1, 2, 3, 5, 6. The second
|
||||
cell indicates which clock inside the PRCC block it wants,
|
||||
possible values are 0 thru 31.
|
||||
- rtc32k-clock: a subnode with zero clock cells for the 32kHz
|
||||
RTC clock.
|
||||
- smp-twd-clock: a subnode for the ARM SMP Timer Watchdog cluster
|
||||
with zero clock cells.
|
||||
|
||||
Example:
|
||||
|
||||
clocks {
|
||||
compatible = "stericsson,u8500-clks";
|
||||
/*
|
||||
* Registers for the CLKRST block on peripheral
|
||||
* groups 1, 2, 3, 5, 6,
|
||||
*/
|
||||
reg = <0x8012f000 0x1000>, <0x8011f000 0x1000>,
|
||||
<0x8000f000 0x1000>, <0xa03ff000 0x1000>,
|
||||
<0xa03cf000 0x1000>;
|
||||
|
||||
prcmu_clk: prcmu-clock {
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
prcc_pclk: prcc-periph-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
prcc_kclk: prcc-kernel-clock {
|
||||
#clock-cells = <2>;
|
||||
};
|
||||
|
||||
rtc_clk: rtc32k-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
|
||||
smp_twd_clk: smp-twd-clock {
|
||||
#clock-cells = <0>;
|
||||
};
|
||||
};
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
Tegra124 CPU frequency scaling driver bindings
|
||||
----------------------------------------------
|
||||
|
||||
Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- cpu_g: Clock mux for the fast CPU cluster.
|
||||
- cpu_lp: Clock mux for the low-power CPU cluster.
|
||||
- pll_x: Fast PLL clocksource.
|
||||
- pll_p: Auxiliary PLL used during fast PLL rate changes.
|
||||
- dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
|
||||
- vdd-cpu-supply: Regulator for CPU voltage
|
||||
|
||||
Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0>;
|
||||
|
||||
clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
|
||||
<&tegra_car TEGRA124_CLK_CCLK_LP>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_X>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_P>,
|
||||
<&dfll>;
|
||||
clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
|
||||
clock-latency = <300000>;
|
||||
vdd-cpu-supply: <&vdd_cpu>;
|
||||
};
|
||||
|
||||
<...>
|
||||
};
|
||||
|
|
@ -106,6 +106,18 @@ PROPERTIES
|
|||
to the interrupt parent to which the child domain
|
||||
is being mapped.
|
||||
|
||||
- clocks
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: A list of phandle and clock specifier pairs describing
|
||||
the clocks required for enabling and disabling SEC 4.0.
|
||||
|
||||
- clock-names
|
||||
Usage: required if SEC 4.0 requires explicit enablement of clocks
|
||||
Value type: <string>
|
||||
Definition: A list of clock name strings in the same order as the
|
||||
clocks property.
|
||||
|
||||
Note: All other standard properties (see the ePAPR) are allowed
|
||||
but are optional.
|
||||
|
||||
|
|
@ -120,6 +132,11 @@ EXAMPLE
|
|||
ranges = <0 0x300000 0x10000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <92 2>;
|
||||
clocks = <&clks IMX6QDL_CLK_CAAM_MEM>,
|
||||
<&clks IMX6QDL_CLK_CAAM_ACLK>,
|
||||
<&clks IMX6QDL_CLK_CAAM_IPG>,
|
||||
<&clks IMX6QDL_CLK_EIM_SLOW>;
|
||||
clock-names = "mem", "aclk", "ipg", "emi_slow";
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -288,12 +305,13 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
Node defines address range and the associated
|
||||
interrupt for the SNVS function. This function
|
||||
monitors security state information & reports
|
||||
security violations.
|
||||
security violations. This also included rtc,
|
||||
system power off and ON/OFF key.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon".
|
||||
Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
|
@ -324,7 +342,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Usage: optional
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
|
|
@ -341,7 +359,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
|
||||
EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
|
|
@ -358,16 +376,72 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
|||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- regmap
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
- offset
|
||||
Usage: option
|
||||
value type: <u32>
|
||||
Definition: LP register offset. default it is 0x34.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
sec_mon_rtc_lp@1 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
interrupts = <93 2>;
|
||||
regmap = <&snvs>;
|
||||
offset = <0x34>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
System ON/OFF key driver
|
||||
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Mush include "fsl,sec-v4.0-pwrkey".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: The SNVS ON/OFF interrupt number to the CPU(s).
|
||||
|
||||
- linux,keycode:
|
||||
Usage: option
|
||||
Value type: <int>
|
||||
Definition: Keycode to emit, KEY_POWER by default.
|
||||
|
||||
- wakeup-source:
|
||||
Usage: option
|
||||
Value type: <boo>
|
||||
Definition: Button can wake-up the system.
|
||||
|
||||
- regmap:
|
||||
Usage: required:
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
EXAMPLE:
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&snvs>;
|
||||
interrupts = <0 4 0x4>
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -443,12 +517,20 @@ FULL EXAMPLE
|
|||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
interrupts = <0 4 0x4>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,23 @@
|
|||
* Allwinner Security System found on A20 SoC
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "allwinner,sun4i-a10-crypto".
|
||||
- reg: Should contain the Security System register location and length.
|
||||
- interrupts: Should contain the IRQ line for the Security System.
|
||||
- clocks : List of clock specifiers, corresponding to ahb and ss.
|
||||
- clock-names : Name of the functional clock, should be
|
||||
* "ahb" : AHB gating clock
|
||||
* "mod" : SS controller clock
|
||||
|
||||
Optional properties:
|
||||
- resets : phandle + reset specifier pair
|
||||
- reset-names : must contain "ahb"
|
||||
|
||||
Example:
|
||||
crypto: crypto-engine@01c15000 {
|
||||
compatible = "allwinner,sun4i-a10-crypto";
|
||||
reg = <0x01c15000 0x1000>;
|
||||
interrupts = <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&ahb_gates 5>, <&ss_clk>;
|
||||
clock-names = "ahb", "mod";
|
||||
};
|
||||
|
|
@ -11,15 +11,14 @@ to various devfreq devices. The devfreq devices would use the event data when
|
|||
derterming the current state of each IP.
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "samsung,exynos-ppmu".
|
||||
- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2.
|
||||
- reg: physical base address of each PPMU and length of memory mapped region.
|
||||
|
||||
Optional properties:
|
||||
- clock-names : the name of clock used by the PPMU, "ppmu"
|
||||
- clocks : phandles for clock specified in "clock-names" property
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Example1 : PPMU nodes in exynos3250.dtsi are listed below.
|
||||
Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
|
||||
|
||||
ppmu_dmc0: ppmu_dmc0@106a0000 {
|
||||
compatible = "samsung,exynos-ppmu";
|
||||
|
|
@ -108,3 +107,41 @@ Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
|
|||
};
|
||||
};
|
||||
};
|
||||
|
||||
Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
|
||||
|
||||
ppmu_d0_cpu: ppmu_d0_cpu@10480000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x10480000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d0_general: ppmu_d0_general@10490000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x10490000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d0_rt: ppmu_d0_rt@104a0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104a0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_cpu: ppmu_d1_cpu@104b0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104b0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_general: ppmu_d1_general@104c0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104c0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
ppmu_d1_rt: ppmu_d1_rt@104d0000 {
|
||||
compatible = "samsung,exynos-ppmu-v2";
|
||||
reg = <0x104d0000 0x2000>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
This document describes the generic device tree binding for MSI controllers and
|
||||
their master(s).
|
||||
|
||||
Message Signaled Interrupts (MSIs) are a class of interrupts generated by a
|
||||
write to an MMIO address.
|
||||
|
||||
MSIs were originally specified by PCI (and are used with PCIe), but may also be
|
||||
used with other busses, and hence a mechanism is required to relate devices on
|
||||
those busses to the MSI controllers which they are capable of using,
|
||||
potentially including additional information.
|
||||
|
||||
MSIs are distinguished by some combination of:
|
||||
|
||||
- The doorbell (the MMIO address written to).
|
||||
|
||||
Devices may be configured by software to write to arbitrary doorbells which
|
||||
they can address. An MSI controller may feature a number of doorbells.
|
||||
|
||||
- The payload (the value written to the doorbell).
|
||||
|
||||
Devices may be configured to write an arbitrary payload chosen by software.
|
||||
MSI controllers may have restrictions on permitted payloads.
|
||||
|
||||
- Sideband information accompanying the write.
|
||||
|
||||
Typically this is neither configurable nor probeable, and depends on the path
|
||||
taken through the memory system (i.e. it is a property of the combination of
|
||||
MSI controller and device rather than a property of either in isolation).
|
||||
|
||||
|
||||
MSI controllers:
|
||||
================
|
||||
|
||||
An MSI controller signals interrupts to a CPU when a write is made to an MMIO
|
||||
address by some master. An MSI controller may feature a number of doorbells.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
|
||||
- msi-controller: Identifies the node as an MSI controller.
|
||||
|
||||
Optional properties:
|
||||
--------------------
|
||||
|
||||
- #msi-cells: The number of cells in an msi-specifier, required if not zero.
|
||||
|
||||
Typically this will encode information related to sideband data, and will
|
||||
not encode doorbells or payloads as these can be configured dynamically.
|
||||
|
||||
The meaning of the msi-specifier is defined by the device tree binding of
|
||||
the specific MSI controller.
|
||||
|
||||
|
||||
MSI clients
|
||||
===========
|
||||
|
||||
MSI clients are devices which generate MSIs. For each MSI they wish to
|
||||
generate, the doorbell and payload may be configured, though sideband
|
||||
information may not be configurable.
|
||||
|
||||
Required properties:
|
||||
--------------------
|
||||
|
||||
- msi-parent: A list of phandle + msi-specifier pairs, one for each MSI
|
||||
controller which the device is capable of using.
|
||||
|
||||
This property is unordered, and MSIs may be allocated from any combination of
|
||||
MSI controllers listed in the msi-parent property.
|
||||
|
||||
If a device has restrictions on the allocation of MSIs, these restrictions
|
||||
must be described with additional properties.
|
||||
|
||||
When #msi-cells is non-zero, busses with an msi-parent will require
|
||||
additional properties to describe the relationship between devices on the bus
|
||||
and the set of MSIs they can potentially generate.
|
||||
|
||||
|
||||
Example
|
||||
=======
|
||||
|
||||
/ {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
msi_a: msi-controller@a {
|
||||
reg = <0xa 0xf00>;
|
||||
compatible = "vendor-a,some-controller";
|
||||
msi-controller;
|
||||
/* No sideband data, so #msi-cells omitted */
|
||||
};
|
||||
|
||||
msi_b: msi-controller@b {
|
||||
reg = <0xb 0xf00>;
|
||||
compatible = "vendor-b,another-controller";
|
||||
msi-controller;
|
||||
/* Each device has some unique ID */
|
||||
#msi-cells = <1>;
|
||||
};
|
||||
|
||||
msi_c: msi-controller@c {
|
||||
reg = <0xb 0xf00>;
|
||||
compatible = "vendor-b,another-controller";
|
||||
msi-controller;
|
||||
/* Each device has some unique ID */
|
||||
#msi-cells = <1>;
|
||||
};
|
||||
|
||||
dev@0 {
|
||||
reg = <0x0 0xf00>;
|
||||
compatible = "vendor-c,some-device";
|
||||
|
||||
/* Can only generate MSIs to msi_a */
|
||||
msi-parent = <&msi_a>;
|
||||
};
|
||||
|
||||
dev@1 {
|
||||
reg = <0x1 0xf00>;
|
||||
compatible = "vendor-c,some-device";
|
||||
|
||||
/*
|
||||
* Can generate MSIs to either A or B.
|
||||
*/
|
||||
msi-parent = <&msi_a>, <&msi_b 0x17>;
|
||||
};
|
||||
|
||||
dev@2 {
|
||||
reg = <0x2 0xf00>;
|
||||
compatible = "vendor-c,some-device";
|
||||
/*
|
||||
* Has different IDs at each MSI controller.
|
||||
* Can generate MSIs to all of the MSI controllers.
|
||||
*/
|
||||
msi-parent = <&msi_a>, <&msi_b 0x17>, <&msi_c 0x53>;
|
||||
};
|
||||
};
|
||||
|
|
@ -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;
|
||||
|
|
|
|||
|
|
@ -1,7 +1,8 @@
|
|||
* Freescale Quad Serial Peripheral Interface(QuadSPI)
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "fsl,vf610-qspi" or "fsl,imx6sx-qspi"
|
||||
- compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
|
||||
"fsl,imx7d-qspi", "fsl,imx6ul-qspi"
|
||||
- reg : the first contains the register location and length,
|
||||
the second contains the memory mapping address and length
|
||||
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,58 @@
|
|||
* NXP SPI Flash Interface (SPIFI)
|
||||
|
||||
NXP SPIFI is a specialized SPI interface for serial Flash devices.
|
||||
It supports one Flash device with 1-, 2- and 4-bits width in SPI
|
||||
mode 0 or 3. The controller operates in either command or memory
|
||||
mode. In memory mode the Flash is accessible from the CPU as
|
||||
normal memory.
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "nxp,lpc1773-spifi"
|
||||
- reg : the first contains the register location and length,
|
||||
the second contains the memory mapping address and length
|
||||
- reg-names: Should contain the reg names "spifi" and "flash"
|
||||
- interrupts : Should contain the interrupt for the device
|
||||
- clocks : The clocks needed by the SPIFI controller
|
||||
- clock-names : Should contain the clock names "spifi" and "reg"
|
||||
|
||||
Optional properties:
|
||||
- resets : phandle + reset specifier
|
||||
|
||||
The SPI Flash must be a child of the SPIFI node and must have a
|
||||
compatible property as specified in bindings/mtd/jedec,spi-nor.txt
|
||||
|
||||
Optionally it can also contain the following properties.
|
||||
- spi-cpol : Controller only supports mode 0 and 3 so either
|
||||
both spi-cpol and spi-cpha should be present or
|
||||
none of them
|
||||
- spi-cpha : See above
|
||||
- spi-rx-bus-width : Used to select how many pins that are used
|
||||
for input on the controller
|
||||
|
||||
See bindings/spi/spi-bus.txt for more information.
|
||||
|
||||
Example:
|
||||
spifi: spifi@40003000 {
|
||||
compatible = "nxp,lpc1773-spifi";
|
||||
reg = <0x40003000 0x1000>, <0x14000000 0x4000000>;
|
||||
reg-names = "spifi", "flash";
|
||||
interrupts = <30>;
|
||||
clocks = <&ccu1 CLK_SPIFI>, <&ccu1 CLK_CPU_SPIFI>;
|
||||
clock-names = "spifi", "reg";
|
||||
resets = <&rgu 53>;
|
||||
|
||||
flash@0 {
|
||||
compatible = "jedec,spi-nor";
|
||||
spi-cpol;
|
||||
spi-cpha;
|
||||
spi-rx-bus-width = <4>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
|
||||
partition@0 {
|
||||
label = "data";
|
||||
reg = <0 0x200000>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
|
|
@ -11,6 +11,7 @@ Required properties:
|
|||
|
||||
Optional properties:
|
||||
|
||||
- dmas: dma data channel, see dma.txt binding doc
|
||||
- marvell,nand-enable-arbiter: Set to enable the bus arbiter
|
||||
- marvell,nand-keep-config: Set to keep the NAND controller config as set
|
||||
by the bootloader
|
||||
|
|
@ -32,6 +33,8 @@ Example:
|
|||
compatible = "marvell,pxa3xx-nand";
|
||||
reg = <0x43100000 90>;
|
||||
interrupts = <45>;
|
||||
dmas = <&pdma 97 0>;
|
||||
dma-names = "data";
|
||||
#address-cells = <1>;
|
||||
|
||||
marvell,nand-enable-arbiter;
|
||||
|
|
|
|||
|
|
@ -2,7 +2,11 @@ TI SoC Ethernet Switch Controller Device Tree Bindings
|
|||
------------------------------------------------------
|
||||
|
||||
Required properties:
|
||||
- compatible : Should be "ti,cpsw"
|
||||
- compatible : Should be one of the below:-
|
||||
"ti,cpsw" for backward compatible
|
||||
"ti,am335x-cpsw" for AM335x controllers
|
||||
"ti,am4372-cpsw" for AM437x controllers
|
||||
"ti,dra7-cpsw" for DRA7x controllers
|
||||
- reg : physical base address and size of the cpsw
|
||||
registers map
|
||||
- interrupts : property with a value describing the interrupt
|
||||
|
|
|
|||
|
|
@ -4,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";
|
||||
};
|
||||
|
|
@ -88,7 +88,7 @@ This defines voltage-current-frequency combinations along with other related
|
|||
properties.
|
||||
|
||||
Required properties:
|
||||
- opp-hz: Frequency in Hz
|
||||
- opp-hz: Frequency in Hz, expressed as a 64-bit big-endian integer.
|
||||
|
||||
Optional properties:
|
||||
- opp-microvolt: voltage in micro Volts.
|
||||
|
|
@ -158,20 +158,20 @@ Example 1: Single cluster Dual-core ARM cortex A9, switch DVFS states together.
|
|||
opp-shared;
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000 975000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp01 {
|
||||
opp-hz = <1100000000>;
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <980000 1000000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp02 {
|
||||
opp-hz = <1200000000>;
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
clock-latency-ns = <290000>;
|
||||
turbo-mode;
|
||||
|
|
@ -237,20 +237,20 @@ independently.
|
|||
*/
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000 975000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp01 {
|
||||
opp-hz = <1100000000>;
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <980000 1000000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp02 {
|
||||
opp-hz = <1200000000>;
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000;
|
||||
lock-latency-ns = <290000>;
|
||||
|
|
@ -313,20 +313,20 @@ DVFS state together.
|
|||
opp-shared;
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000 975000 985000>;
|
||||
opp-microamp = <70000>;
|
||||
clock-latency-ns = <300000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp01 {
|
||||
opp-hz = <1100000000>;
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
opp-microvolt = <980000 1000000 1010000>;
|
||||
opp-microamp = <80000>;
|
||||
clock-latency-ns = <310000>;
|
||||
};
|
||||
opp02 {
|
||||
opp-hz = <1200000000>;
|
||||
opp-hz = /bits/ 64 <1200000000>;
|
||||
opp-microvolt = <1025000>;
|
||||
opp-microamp = <90000>;
|
||||
clock-latency-ns = <290000>;
|
||||
|
|
@ -339,20 +339,20 @@ DVFS state together.
|
|||
opp-shared;
|
||||
|
||||
opp10 {
|
||||
opp-hz = <1300000000>;
|
||||
opp-hz = /bits/ 64 <1300000000>;
|
||||
opp-microvolt = <1045000 1050000 1055000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
opp-suspend;
|
||||
};
|
||||
opp11 {
|
||||
opp-hz = <1400000000>;
|
||||
opp-hz = /bits/ 64 <1400000000>;
|
||||
opp-microvolt = <1075000>;
|
||||
opp-microamp = <100000>;
|
||||
clock-latency-ns = <400000>;
|
||||
};
|
||||
opp12 {
|
||||
opp-hz = <1500000000>;
|
||||
opp-hz = /bits/ 64 <1500000000>;
|
||||
opp-microvolt = <1010000 1100000 1110000>;
|
||||
opp-microamp = <95000>;
|
||||
clock-latency-ns = <400000>;
|
||||
|
|
@ -379,7 +379,7 @@ Example 4: Handling multiple regulators
|
|||
opp-shared;
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000>, /* Supply 0 */
|
||||
<960000>, /* Supply 1 */
|
||||
<960000>; /* Supply 2 */
|
||||
|
|
@ -392,7 +392,7 @@ Example 4: Handling multiple regulators
|
|||
/* OR */
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
|
||||
<960000 965000 975000>, /* Supply 1 */
|
||||
<960000 965000 975000>; /* Supply 2 */
|
||||
|
|
@ -405,7 +405,7 @@ Example 4: Handling multiple regulators
|
|||
/* OR */
|
||||
|
||||
opp00 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
opp-microvolt = <970000 975000 985000>, /* Supply 0 */
|
||||
<960000 965000 975000>, /* Supply 1 */
|
||||
<960000 965000 975000>; /* Supply 2 */
|
||||
|
|
@ -437,12 +437,12 @@ Example 5: Multiple OPP tables
|
|||
opp-shared;
|
||||
|
||||
opp00 {
|
||||
opp-hz = <600000000>;
|
||||
opp-hz = /bits/ 64 <600000000>;
|
||||
...
|
||||
};
|
||||
|
||||
opp01 {
|
||||
opp-hz = <800000000>;
|
||||
opp-hz = /bits/ 64 <800000000>;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -453,12 +453,12 @@ Example 5: Multiple OPP tables
|
|||
opp-shared;
|
||||
|
||||
opp10 {
|
||||
opp-hz = <1000000000>;
|
||||
opp-hz = /bits/ 64 <1000000000>;
|
||||
...
|
||||
};
|
||||
|
||||
opp11 {
|
||||
opp-hz = <1100000000>;
|
||||
opp-hz = /bits/ 64 <1100000000>;
|
||||
...
|
||||
};
|
||||
};
|
||||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -82,6 +82,9 @@ Optional properties:
|
|||
- id: If there are multiple instance of the same type, in order to
|
||||
differentiate between each instance "id" can be used (e.g., multi-lane PCIe
|
||||
PHY). If "id" is not provided, it is set to default value of '1'.
|
||||
- syscon-pllreset: Handle to system control region that contains the
|
||||
CTRL_CORE_SMA_SW_0 register and register offset to the CTRL_CORE_SMA_SW_0
|
||||
register that contains the SATA_PLL_SOFT_RESET bit. Only valid for sata_phy.
|
||||
|
||||
This is usually a subnode of ocp2scp to which it is connected.
|
||||
|
||||
|
|
@ -100,3 +103,16 @@ usb3phy@4a084400 {
|
|||
"sysclk",
|
||||
"refclk";
|
||||
};
|
||||
|
||||
sata_phy: phy@4A096000 {
|
||||
compatible = "ti,phy-pipe3-sata";
|
||||
reg = <0x4A096000 0x80>, /* phy_rx */
|
||||
<0x4A096400 0x64>, /* phy_tx */
|
||||
<0x4A096800 0x40>; /* pll_ctrl */
|
||||
reg-names = "phy_rx", "phy_tx", "pll_ctrl";
|
||||
ctrl-module = <&omap_control_sata>;
|
||||
clocks = <&sys_clkin1>, <&sata_ref_clk>;
|
||||
clock-names = "sysclk", "refclk";
|
||||
syscon-pllreset = <&scm_conf 0x3fc>;
|
||||
#phy-cells = <0>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,36 @@
|
|||
* Freescale i.MX6 UltraLite IOMUX Controller
|
||||
|
||||
Please refer to fsl,imx-pinctrl.txt in this directory for common binding part
|
||||
and usage.
|
||||
|
||||
Required properties:
|
||||
- compatible: "fsl,imx6ul-iomuxc"
|
||||
- fsl,pins: each entry consists of 6 integers and represents the mux and config
|
||||
setting for one pin. The first 5 integers <mux_reg conf_reg input_reg mux_val
|
||||
input_val> are specified using a PIN_FUNC_ID macro, which can be found in
|
||||
imx6ul-pinfunc.h under device tree source folder. The last integer CONFIG is
|
||||
the pad setting value like pull-up on this pin. Please refer to i.MX6 UltraLite
|
||||
Reference Manual for detailed CONFIG settings.
|
||||
|
||||
CONFIG bits definition:
|
||||
PAD_CTL_HYS (1 << 16)
|
||||
PAD_CTL_PUS_100K_DOWN (0 << 14)
|
||||
PAD_CTL_PUS_47K_UP (1 << 14)
|
||||
PAD_CTL_PUS_100K_UP (2 << 14)
|
||||
PAD_CTL_PUS_22K_UP (3 << 14)
|
||||
PAD_CTL_PUE (1 << 13)
|
||||
PAD_CTL_PKE (1 << 12)
|
||||
PAD_CTL_ODE (1 << 11)
|
||||
PAD_CTL_SPEED_LOW (0 << 6)
|
||||
PAD_CTL_SPEED_MED (1 << 6)
|
||||
PAD_CTL_SPEED_HIGH (3 << 6)
|
||||
PAD_CTL_DSE_DISABLE (0 << 3)
|
||||
PAD_CTL_DSE_260ohm (1 << 3)
|
||||
PAD_CTL_DSE_130ohm (2 << 3)
|
||||
PAD_CTL_DSE_87ohm (3 << 3)
|
||||
PAD_CTL_DSE_65ohm (4 << 3)
|
||||
PAD_CTL_DSE_52ohm (5 << 3)
|
||||
PAD_CTL_DSE_43ohm (6 << 3)
|
||||
PAD_CTL_DSE_37ohm (7 << 3)
|
||||
PAD_CTL_SRE_FAST (1 << 0)
|
||||
PAD_CTL_SRE_SLOW (0 << 0)
|
||||
|
|
@ -48,7 +48,7 @@ Example 2:
|
|||
#power-domain-cells = <1>;
|
||||
};
|
||||
|
||||
child: power-controller@12340000 {
|
||||
child: power-controller@12341000 {
|
||||
compatible = "foo,power-controller";
|
||||
reg = <0x12341000 0x1000>;
|
||||
power-domains = <&parent 0>;
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
Некоторые файлы не были показаны из-за слишком большого количества измененных файлов Показать больше
Загрузка…
Ссылка в новой задаче