UbiquitousOS
/
OpenCloudOS-Kernel
mirror of https://gitee.com/OpenCloudOS/OpenCloudOS-Kernel.git
11
0
Fork 0
Code Issues Projects Releases Wiki Activity

Merge branch 'fixes-rc1' into omap-for-v4.3/fixes

This commit is contained in:
Tony Lindgren 2015-09-14 13:42:11 -07:00
parent 21b430d23d 60fdcb8863
commit 7168e94729
6818 changed files with 415877 additions and 181261 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
.gitignore vendored
View File

@ -36,6 +36,7 @@
modules.builtin
Module.symvers
*.dwo
*.su
#
# Top-level generic files
@ -44,6 +45,7 @@ Module.symvers
/TAGS
/linux
/vmlinux
/vmlinux.32
/vmlinux-gdb.py
/vmlinuz
/System.map
@ -89,6 +91,9 @@ GRTAGS
GSYMS
GTAGS
# id-utils files
ID
*.orig
*~
\#*#
@ -97,6 +102,7 @@ GTAGS
# Leavings from module signing
#
extra_certificates
signing_key.pem
signing_key.priv
signing_key.x509
x509.genkey

13
CREDITS
View File

@ -20,6 +20,10 @@ D: One of assisting postmasters for vger.kernel.org's lists
S: (ask for current address)
S: Finland
N: Thomas Abraham
E: thomas.ab@samsung.com
D: Samsung pin controller driver
N: Dragos Acostachioaie
E: dragos@iname.com
W: http://www.arbornet.org/~dragos
@ -2988,6 +2992,10 @@ S: 2200 Mission College Blvd
S: Santa Clara, CA 95052
S: USA
N: Anil Ravindranath
E: anil_ravindranath@pmc-sierra.com
D: PMC-Sierra MaxRAID driver
N: Eric S. Raymond
E: esr@thyrsus.com
W: http://www.tuxedo.org/~esr/
@ -3219,6 +3227,11 @@ S: 69 rue Dunois
S: 75013 Paris
S: France
N: Aleksa Sarai
E: cyphar@cyphar.com
W: https://www.cyphar.com/
D: `pids` cgroup subsystem
N: Dipankar Sarma
E: dipankar@in.ibm.com
D: RCU

10
Documentation/ABI/testing/sysfs-class-cxl
View File

@ -223,3 +223,13 @@ Description: write only
Writing 1 will issue a PERST to card which may cause the card
to reload the FPGA depending on load_image_on_perst.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/perst_reloads_same_image
Date: July 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
Trust that when an image is reloaded via PERST, it will not
have changed.
0 = don't trust, the image may be different (default)
1 = trust that the image will not change.
Users: https://github.com/ibm-capi/libcxl

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

@ -77,3 +77,22 @@ Description:
The format is also scrambled, like in the USB mode, and it can
be summarized by converting 76543210 into GECA6420.
HGFEDCBA HFDB7531
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/unpair_remote
Date: July 2015
Contact: linux-input@vger.kernel.org
Description:
Writing the character sequence '*' followed by a newline to
this file will delete all of the current pairings on the
device. Other character sequences are reserved. This file is
write only.
What: /sys/bus/hid/devices/<bus>:<vid>:<pid>.<n>/wacom_remote/<serial_number>/remote_mode
Date: July 2015
Contact: linux-input@vger.kernel.org
Description:
Reading from this file reports the mode status of the
remote as indicated by the LED lights on the device. If no
reports have been received from the paired device, reading
from this file will report '-1'. The mode is read-only
and cannot be set through the driver.

3
Documentation/ABI/testing/sysfs-gpio
View File

@ -16,7 +16,8 @@ Description:
/sys/class/gpio
/export ... asks the kernel to export a GPIO to userspace
/unexport ... to return a GPIO to the kernel
/gpioN ... for each exported GPIO #N
/gpioN ... for each exported GPIO #N OR
/<LINE-NAME> ... for a properly named GPIO line
/value ... always readable, writes fail for input GPIOs
/direction ... r/w as: in, out (default low); write: high, low
/edge ... r/w as: none, falling, rising, both

23
Documentation/ABI/testing/sysfs-hypervisor-pmu Normal file
View File

@ -0,0 +1,23 @@
What: /sys/hypervisor/pmu/pmu_mode
Date: August 2015
KernelVersion: 4.3
Contact: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Description:
Describes mode that Xen's performance-monitoring unit (PMU)
uses. Accepted values are
"off" -- PMU is disabled
"self" -- The guest can profile itself
"hv" -- The guest can profile itself and, if it is
privileged (e.g. dom0), the hypervisor
"all" -- The guest can profile itself, the hypervisor
and all other guests. Only available to
privileged guests.
What: /sys/hypervisor/pmu/pmu_features
Date: August 2015
KernelVersion: 4.3
Contact: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Description:
Describes Xen PMU features (as an integer). A set bit indicates
that the corresponding feature is enabled. See
include/xen/interface/xenpmu.h for available features

17
Documentation/Changes
View File

@ -43,6 +43,7 @@ o udev 081 # udevd --version
o grub 0.93 # grub --version || grub-install --version
o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V
o openssl & libcrypto 1.0.1k # openssl version
Kernel compilation
@ -79,6 +80,17 @@ BC
You will need bc to build kernels 3.10 and higher
OpenSSL
-------
Module signing and external certificate handling use the OpenSSL program and
crypto library to do key creation and signature generation.
You will need openssl to build kernels 3.7 and higher if module signing is
enabled. You will also need openssl development packages to build kernels 4.3
and higher.
System utilities
================
@ -295,6 +307,10 @@ Binutils
--------
o <ftp://ftp.kernel.org/pub/linux/devel/binutils/>
OpenSSL
-------
o <https://www.openssl.org/>
System utilities
****************
@ -392,4 +408,3 @@ o <http://oprofile.sf.net/download/>
NFS-Utils
---------
o <http://nfs.sourceforge.net/>

7
Documentation/DMA-API.txt
View File

@ -104,6 +104,13 @@ crossing restrictions, pass 0 for alloc; passing 4096 says memory allocated
from this pool must not cross 4KByte boundaries.
void *dma_pool_zalloc(struct dma_pool *pool, gfp_t mem_flags,
dma_addr_t *handle)
Wraps dma_pool_alloc() and also zeroes the returned memory if the
allocation attempt succeeded.
void *dma_pool_alloc(struct dma_pool *pool, gfp_t gfp_flags,
dma_addr_t *dma_handle);

2
Documentation/DocBook/alsa-driver-api.tmpl
View File

@ -108,7 +108,7 @@
<sect1><title>ASoC Core API</title>
!Iinclude/sound/soc.h
!Esound/soc/soc-core.c
!Esound/soc/soc-cache.c
<!-- !Esound/soc/soc-cache.c no docbook comments here -->
!Esound/soc/soc-devres.c
!Esound/soc/soc-io.c
!Esound/soc/soc-pcm.c

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

@ -217,6 +217,40 @@ X!Isound/sound_firmware.c
-->
</chapter>
<chapter id="mediadev">
<title>Media Devices</title>
<sect1><title>Video2Linux devices</title>
!Iinclude/media/v4l2-async.h
!Iinclude/media/v4l2-ctrls.h
!Iinclude/media/v4l2-dv-timings.h
!Iinclude/media/v4l2-event.h
!Iinclude/media/v4l2-flash-led-class.h
!Iinclude/media/v4l2-mediabus.h
!Iinclude/media/v4l2-mem2mem.h
!Iinclude/media/v4l2-of.h
!Iinclude/media/v4l2-subdev.h
!Iinclude/media/videobuf2-core.h
!Iinclude/media/videobuf2-memops.h
</sect1>
<sect1><title>Digital TV (DVB) devices</title>
!Idrivers/media/dvb-core/dvb_ca_en50221.h
!Idrivers/media/dvb-core/dvb_frontend.h
!Idrivers/media/dvb-core/dvb_math.h
!Idrivers/media/dvb-core/dvb_ringbuffer.h
!Idrivers/media/dvb-core/dvbdev.h
</sect1>
<sect1><title>Remote Controller devices</title>
!Iinclude/media/rc-core.h
</sect1>
<sect1><title>Media Controller devices</title>
!Iinclude/media/media-device.h
!Iinclude/media/media-devnode.h
!Iinclude/media/media-entity.h
</sect1>
</chapter>
<chapter id="uart16x50">
<title>16x50 UART Driver</title>
!Edrivers/tty/serial/serial_core.c
@ -456,4 +490,31 @@ X!Ilib/fonts/fonts.c
!Edrivers/hsi/hsi.c
</chapter>
<chapter id="pwm">
<title>Pulse-Width Modulation (PWM)</title>
<para>
Pulse-width modulation is a modulation technique primarily used to
control power supplied to electrical devices.
</para>
<para>
The PWM framework provides an abstraction for providers and consumers
of PWM signals. A controller that provides one or more PWM signals is
registered as <structname>struct pwm_chip</structname>. Providers are
expected to embed this structure in a driver-specific structure. This
structure contains fields that describe a particular chip.
</para>
<para>
A chip exposes one or more PWM signal sources, each of which exposed
as a <structname>struct pwm_device</structname>. Operations can be
performed on PWM devices to control the period, duty cycle, polarity
and active state of the signal.
</para>
<para>
Note that PWM devices are exclusive resources: they can always only be
used by one consumer at a time.
</para>
!Iinclude/linux/pwm.h
!Edrivers/pwm/core.c
</chapter>
</book>

24
Documentation/DocBook/drm.tmpl
View File

@ -3982,7 +3982,6 @@ int num_ioctls;</synopsis>
<title>Interrupt Handling</title>
!Pdrivers/gpu/drm/i915/i915_irq.c interrupt handling
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_init intel_irq_init_hw intel_hpd_init
!Fdrivers/gpu/drm/i915/i915_irq.c intel_irq_fini
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_disable_interrupts
!Fdrivers/gpu/drm/i915/i915_irq.c intel_runtime_pm_enable_interrupts
</sect2>
@ -4012,7 +4011,6 @@ int num_ioctls;</synopsis>
<title>Frontbuffer Tracking</title>
!Pdrivers/gpu/drm/i915/intel_frontbuffer.c frontbuffer tracking
!Idrivers/gpu/drm/i915/intel_frontbuffer.c
!Fdrivers/gpu/drm/i915/intel_drv.h intel_frontbuffer_flip
!Fdrivers/gpu/drm/i915/i915_gem.c i915_gem_track_fb
</sect2>
<sect2>
@ -4044,6 +4042,11 @@ int num_ioctls;</synopsis>
probing, so those sections fully apply.
</para>
</sect2>
<sect2>
<title>Hotplug</title>
!Pdrivers/gpu/drm/i915/intel_hotplug.c Hotplug
!Idrivers/gpu/drm/i915/intel_hotplug.c
</sect2>
<sect2>
<title>High Definition Audio</title>
!Pdrivers/gpu/drm/i915/intel_audio.c High Definition Audio over HDMI and Display Port
@ -4193,6 +4196,23 @@ int num_ioctls;</synopsis>
<title>Global GTT views</title>
!Pdrivers/gpu/drm/i915/i915_gem_gtt.c Global GTT views
!Idrivers/gpu/drm/i915/i915_gem_gtt.c
</sect2>
<sect2>
<title>GTT Fences and Swizzling</title>
!Idrivers/gpu/drm/i915/i915_gem_fence.c
<sect3>
<title>Global GTT Fence Handling</title>
!Pdrivers/gpu/drm/i915/i915_gem_fence.c fence register handling
</sect3>
<sect3>
<title>Hardware Tiling and Swizzling Details</title>
!Pdrivers/gpu/drm/i915/i915_gem_fence.c tiling swizzling details
</sect3>
</sect2>
<sect2>
<title>Object Tiling IOCTLs</title>
!Idrivers/gpu/drm/i915/i915_gem_tiling.c
!Pdrivers/gpu/drm/i915/i915_gem_tiling.c buffer object tiling
</sect2>
<sect2>
<title>Buffer Object Eviction</title>

178
Documentation/DocBook/filesystems.tmpl
View File

@ -146,36 +146,30 @@
The journalling layer is easy to use. You need to
first of all create a journal_t data structure. There are
two calls to do this dependent on how you decide to allocate the physical
media on which the journal resides. The journal_init_inode() call
is for journals stored in filesystem inodes, or the journal_init_dev()
call can be use for journal stored on a raw device (in a continuous range
media on which the journal resides. The jbd2_journal_init_inode() call
is for journals stored in filesystem inodes, or the jbd2_journal_init_dev()
call can be used for journal stored on a raw device (in a continuous range
of blocks). A journal_t is a typedef for a struct pointer, so when
you are finally finished make sure you call journal_destroy() on it
you are finally finished make sure you call jbd2_journal_destroy() on it
to free up any used kernel memory.
</para>
<para>
Once you have got your journal_t object you need to 'mount' or load the journal
file, unless of course you haven't initialised it yet - in which case you
need to call journal_create().
file. The journalling layer expects the space for the journal was already
allocated and initialized properly by the userspace tools. When loading the
journal you must call jbd2_journal_load() to process journal contents. If the
client file system detects the journal contents does not need to be processed
(or even need not have valid contents), it may call jbd2_journal_wipe() to
clear the journal contents before calling jbd2_journal_load().
</para>
<para>
Most of the time however your journal file will already have been created, but
before you load it you must call journal_wipe() to empty the journal file.
Hang on, you say , what if the filesystem wasn't cleanly umount()'d . Well, it is the
job of the client file system to detect this and skip the call to journal_wipe().
</para>
<para>
In either case the next call should be to journal_load() which prepares the
journal file for use. Note that journal_wipe(..,0) calls journal_skip_recovery()
for you if it detects any outstanding transactions in the journal and similarly
journal_load() will call journal_recover() if necessary.
I would advise reading fs/ext3/super.c for examples on this stage.
[RGG: Why is the journal_wipe() call necessary - doesn't this needlessly
complicate the API. Or isn't a good idea for the journal layer to hide
dirty mounts from the client fs]
Note that jbd2_journal_wipe(..,0) calls jbd2_journal_skip_recovery() for you if
it detects any outstanding transactions in the journal and similarly
jbd2_journal_load() will call jbd2_journal_recover() if necessary. I would
advise reading ext4_load_journal() in fs/ext4/super.c for examples on this
stage.
</para>
<para>
@ -189,41 +183,41 @@ You still need to actually journal your filesystem changes, this
is done by wrapping them into transactions. Additionally you
also need to wrap the modification of each of the buffers
with calls to the journal layer, so it knows what the modifications
you are actually making are. To do this use journal_start() which
you are actually making are. To do this use jbd2_journal_start() which
returns a transaction handle.
</para>
<para>
journal_start()
and its counterpart journal_stop(), which indicates the end of a transaction
are nestable calls, so you can reenter a transaction if necessary,
but remember you must call journal_stop() the same number of times as
journal_start() before the transaction is completed (or more accurately
leaves the update phase). Ext3/VFS makes use of this feature to simplify
quota support.
jbd2_journal_start()
and its counterpart jbd2_journal_stop(), which indicates the end of a
transaction are nestable calls, so you can reenter a transaction if necessary,
but remember you must call jbd2_journal_stop() the same number of times as
jbd2_journal_start() before the transaction is completed (or more accurately
leaves the update phase). Ext4/VFS makes use of this feature to simplify
handling of inode dirtying, quota support, etc.
</para>
<para>
Inside each transaction you need to wrap the modifications to the
individual buffers (blocks). Before you start to modify a buffer you
need to call journal_get_{create,write,undo}_access() as appropriate,
need to call jbd2_journal_get_{create,write,undo}_access() as appropriate,
this allows the journalling layer to copy the unmodified data if it
needs to. After all the buffer may be part of a previously uncommitted
transaction.
At this point you are at last ready to modify a buffer, and once
you are have done so you need to call journal_dirty_{meta,}data().
you are have done so you need to call jbd2_journal_dirty_{meta,}data().
Or if you've asked for access to a buffer you now know is now longer
required to be pushed back on the device you can call journal_forget()
required to be pushed back on the device you can call jbd2_journal_forget()
in much the same way as you might have used bforget() in the past.
</para>
<para>
A journal_flush() may be called at any time to commit and checkpoint
A jbd2_journal_flush() may be called at any time to commit and checkpoint
all your transactions.
</para>
<para>
Then at umount time , in your put_super() you can then call journal_destroy()
Then at umount time , in your put_super() you can then call jbd2_journal_destroy()
to clean up your in-core journal object.
</para>
@ -231,82 +225,74 @@ to clean up your in-core journal object.
Unfortunately there a couple of ways the journal layer can cause a deadlock.
The first thing to note is that each task can only have
a single outstanding transaction at any one time, remember nothing
commits until the outermost journal_stop(). This means
commits until the outermost jbd2_journal_stop(). This means
you must complete the transaction at the end of each file/inode/address
etc. operation you perform, so that the journalling system isn't re-entered
on another journal. Since transactions can't be nested/batched
across differing journals, and another filesystem other than
yours (say ext3) may be modified in a later syscall.
yours (say ext4) may be modified in a later syscall.
</para>
<para>
The second case to bear in mind is that journal_start() can
The second case to bear in mind is that jbd2_journal_start() can
block if there isn't enough space in the journal for your transaction
(based on the passed nblocks param) - when it blocks it merely(!) needs to
wait for transactions to complete and be committed from other tasks,
so essentially we are waiting for journal_stop(). So to avoid
deadlocks you must treat journal_start/stop() as if they
so essentially we are waiting for jbd2_journal_stop(). So to avoid
deadlocks you must treat jbd2_journal_start/stop() as if they
were semaphores and include them in your semaphore ordering rules to prevent
deadlocks. Note that journal_extend() has similar blocking behaviour to
journal_start() so you can deadlock here just as easily as on journal_start().
deadlocks. Note that jbd2_journal_extend() has similar blocking behaviour to
jbd2_journal_start() so you can deadlock here just as easily as on
jbd2_journal_start().
</para>
<para>
Try to reserve the right number of blocks the first time. ;-). This will
be the maximum number of blocks you are going to touch in this transaction.
I advise having a look at at least ext3_jbd.h to see the basis on which
ext3 uses to make these decisions.
I advise having a look at at least ext4_jbd.h to see the basis on which
ext4 uses to make these decisions.
</para>
<para>
Another wriggle to watch out for is your on-disk block allocation strategy.
why? Because, if you undo a delete, you need to ensure you haven't reused any
of the freed blocks in a later transaction. One simple way of doing this
is make sure any blocks you allocate only have checkpointed transactions
listed against them. Ext3 does this in ext3_test_allocatable().
Why? Because, if you do a delete, you need to ensure you haven't reused any
of the freed blocks until the transaction freeing these blocks commits. If you
reused these blocks and crash happens, there is no way to restore the contents
of the reallocated blocks at the end of the last fully committed transaction.
One simple way of doing this is to mark blocks as free in internal in-memory
block allocation structures only after the transaction freeing them commits.
Ext4 uses journal commit callback for this purpose.
</para>
<para>
Lock is also providing through journal_{un,}lock_updates(),
ext3 uses this when it wants a window with a clean and stable fs for a moment.
eg.
With journal commit callbacks you can ask the journalling layer to call a
callback function when the transaction is finally committed to disk, so that
you can do some of your own management. You ask the journalling layer for
calling the callback by simply setting journal->j_commit_callback function
pointer and that function is called after each transaction commit. You can also
use transaction->t_private_list for attaching entries to a transaction that
need processing when the transaction commits.
</para>
<para>
JBD2 also provides a way to block all transaction updates via
jbd2_journal_{un,}lock_updates(). Ext4 uses this when it wants a window with a
clean and stable fs for a moment. E.g.
</para>
<programlisting>
journal_lock_updates() //stop new stuff happening..
journal_flush() // checkpoint everything.
jbd2_journal_lock_updates() //stop new stuff happening..
jbd2_journal_flush() // checkpoint everything.
..do stuff on stable fs
journal_unlock_updates() // carry on with filesystem use.
jbd2_journal_unlock_updates() // carry on with filesystem use.
</programlisting>
<para>
The opportunities for abuse and DOS attacks with this should be obvious,
if you allow unprivileged userspace to trigger codepaths containing these
calls.
</para>
<para>
A new feature of jbd since 2.5.25 is commit callbacks with the new
journal_callback_set() function you can now ask the journalling layer
to call you back when the transaction is finally committed to disk, so that
you can do some of your own management. The key to this is the journal_callback
struct, this maintains the internal callback information but you can
extend it like this:-
</para>
<programlisting>
struct myfs_callback_s {
//Data structure element required by jbd..
struct journal_callback for_jbd;
// Stuff for myfs allocated together.
myfs_inode* i_commited;
}
</programlisting>
<para>
this would be useful if you needed to know when data was committed to a
particular inode.
</para>
</sect2>
@ -319,36 +305,6 @@ being each mount, each modification (transaction) and each changed buffer
to tell the journalling layer about them.
</para>
<para>
Here is a some pseudo code to give you an idea of how it works, as
an example.
</para>
<programlisting>
journal_t* my_jnrl = journal_create();
journal_init_{dev,inode}(jnrl,...)
if (clean) journal_wipe();
journal_load();
foreach(transaction) { /*transactions must be
completed before
a syscall returns to
userspace*/
handle_t * xct=journal_start(my_jnrl);
foreach(bh) {
journal_get_{create,write,undo}_access(xact,bh);
if ( myfs_modify(bh) ) { /* returns true
if makes changes */
journal_dirty_{meta,}data(xact,bh);
} else {
journal_forget(bh);
}
}
journal_stop(xct);
}
journal_destroy(my_jrnl);
</programlisting>
</sect2>
</sect1>
@ -357,13 +313,13 @@ an example.
<title>Data Types</title>
<para>
The journalling layer uses typedefs to 'hide' the concrete definitions
of the structures used. As a client of the JBD layer you can
of the structures used. As a client of the JBD2 layer you can
just rely on the using the pointer as a magic cookie of some sort.
Obviously the hiding is not enforced as this is 'C'.
</para>
<sect2 id="structures"><title>Structures</title>
!Iinclude/linux/jbd.h
!Iinclude/linux/jbd2.h
</sect2>
</sect1>
@ -375,11 +331,11 @@ an example.
manage transactions
</para>
<sect2 id="journal_level"><title>Journal Level</title>
!Efs/jbd/journal.c
!Ifs/jbd/recovery.c
!Efs/jbd2/journal.c
!Ifs/jbd2/recovery.c
</sect2>
<sect2 id="transaction_level"><title>Transasction Level</title>
!Efs/jbd/transaction.c
!Efs/jbd2/transaction.c
</sect2>
</sect1>
<sect1 id="see_also">

3
Documentation/DocBook/media/Makefile
View File

@ -199,7 +199,8 @@ DVB_DOCUMENTED = \
#
install_media_images = \
$(Q)-cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
$(Q)-mkdir $(MEDIA_OBJ_DIR)/media_api; \
cp $(OBJIMGFILES) $(MEDIA_SRC_DIR)/*.svg $(MEDIA_SRC_DIR)/v4l/*.svg $(MEDIA_OBJ_DIR)/media_api
$(MEDIA_OBJ_DIR)/%: $(MEDIA_SRC_DIR)/%.b64
$(Q)base64 -d $< >$@

5
Documentation/DocBook/media/dvb/intro.xml
View File

@ -163,9 +163,8 @@ are called:</para>
<para>where N enumerates the DVB PCI cards in a system starting
from&#x00A0;0, and M enumerates the devices of each type within each
adapter, starting from&#x00A0;0, too. We will omit the &#8220;
<constant>/dev/dvb/adapterN/</constant>&#8221; in the further dicussion
of these devices. The naming scheme for the devices is the same wheter
devfs is used or not.</para>
<constant>/dev/dvb/adapterN/</constant>&#8221; in the further discussion
of these devices.</para>
<para>More details about the data structures and function calls of all
the devices are described in the following chapters.</para>

2
Documentation/DocBook/media/v4l/controls.xml
View File

@ -3414,7 +3414,7 @@ giving priority to the center of the metered area.</entry>
<row>
<entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant>&nbsp;</entry>
<entry>A multi-zone metering. The light intensity is measured
in several points of the frame and the the results are combined. The
in several points of the frame and the results are combined. The
algorithm of the zones selection and their significance in calculating the
final value is device dependent.</entry>
</row>

2
Documentation/DocBook/media/v4l/media-ioc-device-info.xml
View File

@ -102,7 +102,7 @@
</row>
<row>
<entry>__u32</entry>
<entry><structfield>media_version</structfield></entry>
<entry><structfield>driver_version</structfield></entry>
<entry>Media device driver version, formatted with the
<constant>KERNEL_VERSION()</constant> macro. Together with the
<structfield>driver</structfield> field this identifies a particular

38
Documentation/DocBook/media/v4l/vidioc-expbuf.xml
View File

@ -62,28 +62,28 @@ buffer as a DMABUF file at any time after buffers have been allocated with the
&VIDIOC-REQBUFS; ioctl.</para>
<para> To export a buffer, applications fill &v4l2-exportbuffer;. The
<structfield> type </structfield> field is set to the same buffer type as was
previously used with &v4l2-requestbuffers;<structfield> type </structfield>.
Applications must also set the <structfield> index </structfield> field. Valid
<structfield>type</structfield> field is set to the same buffer type as was
previously used with &v4l2-requestbuffers; <structfield>type</structfield>.
Applications must also set the <structfield>index</structfield> field. Valid
index numbers range from zero to the number of buffers allocated with
&VIDIOC-REQBUFS; (&v4l2-requestbuffers;<structfield> count </structfield>)
minus one. For the multi-planar API, applications set the <structfield> plane
</structfield> field to the index of the plane to be exported. Valid planes
&VIDIOC-REQBUFS; (&v4l2-requestbuffers; <structfield>count</structfield>)
minus one. For the multi-planar API, applications set the <structfield>plane</structfield>
field to the index of the plane to be exported. Valid planes
range from zero to the maximal number of valid planes for the currently active
format. For the single-planar API, applications must set <structfield> plane
</structfield> to zero. Additional flags may be posted in the <structfield>
flags </structfield> field. Refer to a manual for open() for details.
format. For the single-planar API, applications must set <structfield>plane</structfield>
to zero. Additional flags may be posted in the <structfield>flags</structfield>
field. Refer to a manual for open() for details.
Currently only O_CLOEXEC, O_RDONLY, O_WRONLY, and O_RDWR are supported. All
other fields must be set to zero.
In the case of multi-planar API, every plane is exported separately using
multiple <constant> VIDIOC_EXPBUF </constant> calls. </para>
multiple <constant>VIDIOC_EXPBUF</constant> calls.</para>
<para> After calling <constant>VIDIOC_EXPBUF</constant> the <structfield> fd
</structfield> field will be set by a driver. This is a DMABUF file
<para>After calling <constant>VIDIOC_EXPBUF</constant> the <structfield>fd</structfield>
field will be set by a driver. This is a DMABUF file
descriptor. The application may pass it to other DMABUF-aware devices. Refer to
<link linkend="dmabuf">DMABUF importing</link> for details about importing
DMABUF files into V4L2 nodes. It is recommended to close a DMABUF file when it
is no longer used to allow the associated memory to be reclaimed. </para>
is no longer used to allow the associated memory to be reclaimed.</para>
</refsect1>
<refsect1>
@ -170,9 +170,9 @@ multi-planar API. Otherwise this value must be set to zero. </entry>
<row>
<entry>__u32</entry>
<entry><structfield>flags</structfield></entry>
<entry>Flags for the newly created file, currently only <constant>
O_CLOEXEC </constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY
</constant>, and <constant>O_RDWR</constant> are supported, refer to the manual
<entry>Flags for the newly created file, currently only
<constant>O_CLOEXEC</constant>, <constant>O_RDONLY</constant>, <constant>O_WRONLY</constant>,
and <constant>O_RDWR</constant> are supported, refer to the manual
of open() for more details.</entry>
</row>
<row>
@ -200,9 +200,9 @@ set the array to zero.</entry>
<term><errorcode>EINVAL</errorcode></term>
<listitem>
<para>A queue is not in MMAP mode or DMABUF exporting is not
supported or <structfield> flags </structfield> or <structfield> type
</structfield> or <structfield> index </structfield> or <structfield> plane
</structfield> fields are invalid.</para>
supported or <structfield>flags</structfield> or <structfield>type</structfield>
or <structfield>index</structfield> or <structfield>plane</structfield> fields
are invalid.</para>
</listitem>
</varlistentry>
</variablelist>

2
Documentation/DocBook/media/v4l/vidioc-g-parm.xml
View File

@ -267,7 +267,7 @@ is intended for still imaging applications. The idea is to get the
best possible image quality that the hardware can deliver. It is not
defined how the driver writer may achieve that; it will depend on the
hardware and the ingenuity of the driver writer. High quality mode is
a different mode from the the regular motion video capture modes. In
a different mode from the regular motion video capture modes. In
high quality mode:<itemizedlist>
<listitem>
<para>The driver may be able to capture higher

2
Documentation/DocBook/media/v4l/vidioc-queryctrl.xml
View File

@ -616,7 +616,7 @@ pointer to memory containing the payload of the control.</entry>
<entry><constant>V4L2_CTRL_FLAG_EXECUTE_ON_WRITE</constant></entry>
<entry>0x0200</entry>
<entry>The value provided to the control will be propagated to the driver
even if remains constant. This is required when the control represents an action
even if it remains constant. This is required when the control represents an action
on the hardware. For example: clearing an error flag or triggering the flash. All the
controls of the type <constant>V4L2_CTRL_TYPE_BUTTON</constant> have this flag set.</entry>
</row>

2
Documentation/SubmittingPatches
View File

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

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

@ -1,26 +1,192 @@
/sys/module/acpi/parameters/:
ACPICA Trace Facility
trace_method_name
The AML method name that the user wants to trace
Copyright (C) 2015, Intel Corporation
Author: Lv Zheng <lv.zheng@intel.com>
trace_debug_layer
The temporary debug_layer used when tracing the method.
Using 0xffffffff by default if it is 0.
trace_debug_level
The temporary debug_level used when tracing the method.
Using 0x00ffffff by default if it is 0.
Abstract:
trace_state
This document describes the functions and the interfaces of the method
tracing facility.
1. Functionalities and usage examples:
ACPICA provides method tracing capability. And two functions are
currently implemented using this capability.
A. Log reducer
ACPICA subsystem provides debugging outputs when CONFIG_ACPI_DEBUG is
enabled. The debugging messages which are deployed via
ACPI_DEBUG_PRINT() macro can be reduced at 2 levels - per-component
level (known as debug layer, configured via
/sys/module/acpi/parameters/debug_layer) and per-type level (known as
debug level, configured via /sys/module/acpi/parameters/debug_level).
But when the particular layer/level is applied to the control method
evaluations, the quantity of the debugging outputs may still be too
large to be put into the kernel log buffer. The idea thus is worked out
to only enable the particular debug layer/level (normally more detailed)
logs when the control method evaluation is started, and disable the
detailed logging when the control method evaluation is stopped.
The following command examples illustrate the usage of the "log reducer"
functionality:
a. Filter out the debug layer/level matched logs when control methods
are being evaluated:
# cd /sys/module/acpi/parameters
# echo "0xXXXXXXXX" > trace_debug_layer
# echo "0xYYYYYYYY" > trace_debug_level
# echo "enable" > trace_state
b. Filter out the debug layer/level matched logs when the specified
control method is being evaluated:
# cd /sys/module/acpi/parameters
# echo "0xXXXXXXXX" > trace_debug_layer
# echo "0xYYYYYYYY" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "method" > /sys/module/acpi/parameters/trace_state
c. Filter out the debug layer/level matched logs when the specified
control method is being evaluated for the first time:
# cd /sys/module/acpi/parameters
# echo "0xXXXXXXXX" > trace_debug_layer
# echo "0xYYYYYYYY" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "method-once" > /sys/module/acpi/parameters/trace_state
Where:
0xXXXXXXXX/0xYYYYYYYY: Refer to Documentation/acpi/debug.txt for
possible debug layer/level masking values.
\PPPP.AAAA.TTTT.HHHH: Full path of a control method that can be found
in the ACPI namespace. It needn't be an entry
of a control method evaluation.
B. AML tracer
There are special log entries added by the method tracing facility at
the "trace points" the AML interpreter starts/stops to execute a control
method, or an AML opcode. Note that the format of the log entries are
subject to change:
[ 0.186427] exdebug-0398 ex_trace_point : Method Begin [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
[ 0.186630] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905c88:If] execution.
[ 0.186820] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:LEqual] execution.
[ 0.187010] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905a20:-NamePath-] execution.
[ 0.187214] exdebug-0398 ex_trace_point : Opcode End [0xf5905a20:-NamePath-] execution.
[ 0.187407] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
[ 0.187594] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
[ 0.187789] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:LEqual] execution.
[ 0.187980] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905cc0:Return] execution.
[ 0.188146] exdebug-0398 ex_trace_point : Opcode Begin [0xf5905f60:One] execution.
[ 0.188334] exdebug-0398 ex_trace_point : Opcode End [0xf5905f60:One] execution.
[ 0.188524] exdebug-0398 ex_trace_point : Opcode End [0xf5905cc0:Return] execution.
[ 0.188712] exdebug-0398 ex_trace_point : Opcode End [0xf5905c88:If] execution.
[ 0.188903] exdebug-0398 ex_trace_point : Method End [0xf58394d8:\_SB.PCI0.LPCB.ECOK] execution.
Developers can utilize these special log entries to track the AML
interpretion, thus can aid issue debugging and performance tuning. Note
that, as the "AML tracer" logs are implemented via ACPI_DEBUG_PRINT()
macro, CONFIG_ACPI_DEBUG is also required to be enabled for enabling
"AML tracer" logs.
The following command examples illustrate the usage of the "AML tracer"
functionality:
a. Filter out the method start/stop "AML tracer" logs when control
methods are being evaluated:
# cd /sys/module/acpi/parameters
# echo "0x80" > trace_debug_layer
# echo "0x10" > trace_debug_level
# echo "enable" > trace_state
b. Filter out the method start/stop "AML tracer" when the specified
control method is being evaluated:
# cd /sys/module/acpi/parameters
# echo "0x80" > trace_debug_layer
# echo "0x10" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "method" > trace_state
c. Filter out the method start/stop "AML tracer" logs when the specified
control method is being evaluated for the first time:
# cd /sys/module/acpi/parameters
# echo "0x80" > trace_debug_layer
# echo "0x10" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "method-once" > trace_state
d. Filter out the method/opcode start/stop "AML tracer" when the
specified control method is being evaluated:
# cd /sys/module/acpi/parameters
# echo "0x80" > trace_debug_layer
# echo "0x10" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "opcode" > trace_state
e. Filter out the method/opcode start/stop "AML tracer" when the
specified control method is being evaluated for the first time:
# cd /sys/module/acpi/parameters
# echo "0x80" > trace_debug_layer
# echo "0x10" > trace_debug_level
# echo "\PPPP.AAAA.TTTT.HHHH" > trace_method_name
# echo "opcode-opcode" > trace_state
Note that all above method tracing facility related module parameters can
be used as the boot parameters, for example:
acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10 \
acpi.trace_method_name=\_SB.LID0._LID acpi.trace_state=opcode-once
2. Interface descriptions:
All method tracing functions can be configured via ACPI module
parameters that are accessible at /sys/module/acpi/parameters/:
trace_method_name
The full path of the AML method that the user wants to trace.
Note that the full path shouldn't contain the trailing "_"s in its
name segments but may contain "\" to form an absolute path.
trace_debug_layer
The temporary debug_layer used when the tracing feature is enabled.
Using ACPI_EXECUTER (0x80) by default, which is the debug_layer
used to match all "AML tracer" logs.
trace_debug_level
The temporary debug_level used when the tracing feature is enabled.
Using ACPI_LV_TRACE_POINT (0x10) by default, which is the
debug_level used to match all "AML tracer" logs.
trace_state
The status of the tracing feature.
"enabled" means this feature is enabled
and the AML method is traced every time it's executed.
"1" means this feature is enabled and the AML method
will only be traced during the next execution.
"disabled" means this feature is disabled.
Users can enable/disable this debug tracing feature by
"echo string > /sys/module/acpi/parameters/trace_state".
"string" should be one of "enable", "disable" and "1".
Users can enable/disable this debug tracing feature by executing
the following command:
# echo string > /sys/module/acpi/parameters/trace_state
Where "string" should be one of the followings:
"disable"
Disable the method tracing feature.
"enable"
Enable the method tracing feature.
ACPICA debugging messages matching
"trace_debug_layer/trace_debug_level" during any method
execution will be logged.
"method"
Enable the method tracing feature.
ACPICA debugging messages matching
"trace_debug_layer/trace_debug_level" during method execution
of "trace_method_name" will be logged.
"method-once"
Enable the method tracing feature.
ACPICA debugging messages matching
"trace_debug_layer/trace_debug_level" during method execution
of "trace_method_name" will be logged only once.
"opcode"
Enable the method tracing feature.
ACPICA debugging messages matching
"trace_debug_layer/trace_debug_level" during method/opcode
execution of "trace_method_name" will be logged.
"opcode-once"
Enable the method tracing feature.
ACPICA debugging messages matching
"trace_debug_layer/trace_debug_level" during method/opcode
execution of "trace_method_name" will be logged only once.
Note that, the difference between the "enable" and other feature
enabling options are:
1. When "enable" is specified, since
"trace_debug_layer/trace_debug_level" shall apply to all control
method evaluations, after configuring "trace_state" to "enable",
"trace_method_name" will be reset to NULL.
2. When "method/opcode" is specified, if
"trace_method_name" is NULL when "trace_state" is configured to
these options, the "trace_debug_layer/trace_debug_level" will
apply to all control method evaluations.

11
Documentation/arm64/booting.txt
View File

@ -81,7 +81,7 @@ The decompressed kernel image contains a 64-byte header as follows:
u64 res3 = 0; /* reserved */
u64 res4 = 0; /* reserved */
u32 magic = 0x644d5241; /* Magic number, little endian, "ARM\x64" */
u32 res5; /* reserved (used for PE COFF offset) */
u32 res5; /* reserved (used for PE COFF offset) */
Header notes:
@ -103,7 +103,7 @@ Header notes:
- The flags field (introduced in v3.17) is a little-endian 64-bit field
composed as follows:
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
Bit 0: Kernel endianness. 1 if BE, 0 if LE.
Bits 1-63: Reserved.
- When image_size is zero, a bootloader should attempt to keep as much
@ -115,11 +115,14 @@ The Image must be placed text_offset bytes from a 2MB aligned base
address near the start of usable system RAM and called there. Memory
below that base address is currently unusable by Linux, and therefore it
is strongly recommended that this location is the start of system RAM.
The region between the 2 MB aligned base address and the start of the
image has no special significance to the kernel, and may be used for
other purposes.
At least image_size bytes from the start of the image must be free for
use by the kernel.
Any memory described to the kernel (even that below the 2MB aligned base
address) which is not marked as reserved from the kernel e.g. with a
Any memory described to the kernel (even that below the start of the
image) which is not marked as reserved from the kernel (e.g., with a
memreserve region in the device tree) will be considered as available to
the kernel.

4
Documentation/atomic_ops.txt
View File

@ -266,7 +266,9 @@ with the given old and new values. Like all atomic_xxx operations,
atomic_cmpxchg will only satisfy its atomicity semantics as long as all
other accesses of *v are performed through atomic_xxx operations.
atomic_cmpxchg must provide explicit memory barriers around the operation.
atomic_cmpxchg must provide explicit memory barriers around the operation,
although if the comparison fails then no memory ordering guarantees are
required.
The semantics for atomic_cmpxchg are the same as those defined for 'cas'
below.

2
Documentation/block/biodoc.txt
View File

@ -1109,7 +1109,7 @@ it will loop and handle as many sectors (on a bio-segment granularity)
as specified.
Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the
right thing to use is bio_endio(bio, uptodate) instead.
right thing to use is bio_endio(bio) instead.
If the driver is dropping the io_request_lock from its request_fn strategy,
then it just needs to replace that with q->queue_lock instead.

10
Documentation/block/biovecs.txt
View File

@ -24,7 +24,7 @@ particular, presenting the illusion of partially completed biovecs so that
normal code doesn't have to deal with bi_bvec_done.
* Driver code should no longer refer to biovecs directly; we now have
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
bio_iovec() and bio_iter_iovec() macros that return literal struct biovecs,
constructed from the raw biovecs but taking into account bi_bvec_done and
bi_size.
@ -109,3 +109,11 @@ Other implications:
over all the biovecs in the new bio - which is silly as it's not needed.
So, don't use bi_vcnt anymore.
* The current interface allows the block layer to split bios as needed, so we
could eliminate a lot of complexity particularly in stacked drivers. Code
that creates bios can then create whatever size bios are convenient, and
more importantly stacked drivers don't have to deal with both their own bio
size limitations and the limitations of the underlying devices. Thus
there's no need to define ->merge_bvec_fn() callbacks for individual block
drivers.

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

@ -20,7 +20,7 @@ This shows the size of internal allocation of the device in bytes, if
reported by the device. A value of '0' means device does not support
the discard functionality.
discard_max_bytes (RO)
discard_max_hw_bytes (RO)
----------------------
Devices that support discard functionality may have internal limits on
the number of bytes that can be trimmed or unmapped in a single operation.
@ -29,6 +29,14 @@ number of bytes that can be discarded in a single operation. Discard
requests issued to the device must not exceed this limit. A discard_max_bytes
value of 0 means that the device does not support discard functionality.
discard_max_bytes (RW)
----------------------
While discard_max_hw_bytes is the hardware limit for the device, this
setting is the software limit. Some devices exhibit large latencies when
large discards are issued, setting this value lower will make Linux issue
smaller discards and potentially help reduce latencies induced by large
discard operations.
discard_zeroes_data (RO)
------------------------
When read, this file will show if the discarded block are zeroed by the

3
Documentation/blockdev/zram.txt
View File

@ -144,7 +144,8 @@ mem_used_max RW the maximum amount memory zram have consumed to
store compressed data
mem_limit RW the maximum amount of memory ZRAM can use to store
the compressed data
num_migrated RO the number of objects migrated migrated by compaction
pages_compacted RO the number of pages freed during compaction
(available only via zram<id>/mm_stat node)
compact WO trigger memory compaction
WARNING

2
Documentation/cgroups/00-INDEX
View File

@ -22,6 +22,8 @@ net_cls.txt
- Network classifier cgroups details and usages.
net_prio.txt
- Network priority cgroups details and usages.
pids.txt
- Process number cgroups details and usages.
resource_counter.txt
- Resource Counter API.
unified-hierarchy.txt

24
Documentation/cgroups/blkio-controller.txt
View File

@ -201,7 +201,7 @@ Proportional weight policy files
specifies the number of bytes.
- blkio.io_serviced
- Number of IOs completed to/from the disk by the group. These
- Number of IOs (bio) issued to the disk by the group. These
are further divided by the type of operation - read or write, sync
or async. First two fields specify the major and minor number of the
device, third field specifies the operation type and the fourth field
@ -327,18 +327,11 @@ Note: If both BW and IOPS rules are specified for a device, then IO is
subjected to both the constraints.
- blkio.throttle.io_serviced
- Number of IOs (bio) completed to/from the disk by the group (as
seen by throttling policy). These are further divided by the type
of operation - read or write, sync or async. First two fields specify
the major and minor number of the device, third field specifies the
operation type and the fourth field specifies the number of IOs.
blkio.io_serviced does accounting as seen by CFQ and counts are in
number of requests (struct request). On the other hand,
blkio.throttle.io_serviced counts number of IO in terms of number
of bios as seen by throttling policy. These bios can later be
merged by elevator and total number of requests completed can be
lesser.
- Number of IOs (bio) issued to the disk by the group. These
are further divided by the type of operation - read or write, sync
or async. First two fields specify the major and minor number of the
device, third field specifies the operation type and the fourth field
specifies the number of IOs.
- blkio.throttle.io_service_bytes
- Number of bytes transferred to/from the disk by the group. These
@ -347,11 +340,6 @@ Note: If both BW and IOPS rules are specified for a device, then IO is
device, third field specifies the operation type and the fourth field
specifies the number of bytes.
These numbers should roughly be same as blkio.io_service_bytes as
updated by CFQ. The difference between two is that
blkio.io_service_bytes will not be updated if CFQ is not operating
on request queue.
Common files among various policies
-----------------------------------
- blkio.reset_stats

85
Documentation/cgroups/pids.txt Normal file
View File

@ -0,0 +1,85 @@
Process Number Controller
=========================
Abstract
--------
The process number controller is used to allow a cgroup hierarchy to stop any
new tasks from being fork()'d or clone()'d after a certain limit is reached.
Since it is trivial to hit the task limit without hitting any kmemcg limits in
place, PIDs are a fundamental resource. As such, PID exhaustion must be
preventable in the scope of a cgroup hierarchy by allowing resource limiting of
the number of tasks in a cgroup.
Usage
-----
In order to use the `pids` controller, set the maximum number of tasks in
pids.max (this is not available in the root cgroup for obvious reasons). The
number of processes currently in the cgroup is given by pids.current.
Organisational operations are not blocked by cgroup policies, so it is possible
to have pids.current > pids.max. This can be done by either setting the limit to
be smaller than pids.current, or attaching enough processes to the cgroup such
that pids.current > pids.max. However, it is not possible to violate a cgroup
policy through fork() or clone(). fork() and clone() will return -EAGAIN if the
creation of a new process would cause a cgroup policy to be violated.
To set a cgroup to have no limit, set pids.max to "max". This is the default for
all new cgroups (N.B. that PID limits are hierarchical, so the most stringent
limit in the hierarchy is followed).
pids.current tracks all child cgroup hierarchies, so parent/pids.current is a
superset of parent/child/pids.current.
Example
-------
First, we mount the pids controller:
# mkdir -p /sys/fs/cgroup/pids
# mount -t cgroup -o pids none /sys/fs/cgroup/pids
Then we create a hierarchy, set limits and attach processes to it:
# mkdir -p /sys/fs/cgroup/pids/parent/child
# echo 2 > /sys/fs/cgroup/pids/parent/pids.max
# echo $$ > /sys/fs/cgroup/pids/parent/cgroup.procs
# cat /sys/fs/cgroup/pids/parent/pids.current
2
#
It should be noted that attempts to overcome the set limit (2 in this case) will
fail:
# cat /sys/fs/cgroup/pids/parent/pids.current
2
# ( /bin/echo "Here's some processes for you." | cat )
sh: fork: Resource temporary unavailable
#
Even if we migrate to a child cgroup (which doesn't have a set limit), we will
not be able to overcome the most stringent limit in the hierarchy (in this case,
parent's):
# echo $$ > /sys/fs/cgroup/pids/parent/child/cgroup.procs
# cat /sys/fs/cgroup/pids/parent/pids.current
2
# cat /sys/fs/cgroup/pids/parent/child/pids.current
2
# cat /sys/fs/cgroup/pids/parent/child/pids.max
max
# ( /bin/echo "Here's some processes for you." | cat )
sh: fork: Resource temporary unavailable
#
We can set a limit that is smaller than pids.current, which will stop any new
processes from being forked at all (note that the shell itself counts towards
pids.current):
# echo 1 > /sys/fs/cgroup/pids/parent/pids.max
# /bin/echo "We can't even spawn a single process now."
sh: fork: Resource temporary unavailable
# echo 0 > /sys/fs/cgroup/pids/parent/pids.max
# /bin/echo "We can't even spawn a single process now."
sh: fork: Resource temporary unavailable
#

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

@ -23,10 +23,13 @@ CONTENTS
5. Other Changes
5-1. [Un]populated Notification
5-2. Other Core Changes
5-3. Per-Controller Changes
5-3-1. blkio
5-3-2. cpuset
5-3-3. memory
5-3. Controller File Conventions
5-3-1. Format
5-3-2. Control Knobs
5-4. Per-Controller Changes
5-4-1. io
5-4-2. cpuset
5-4-3. memory
6. Planned Changes
6-1. CAP for resource control
@ -200,7 +203,7 @@ other issues. The mapping from nice level to weight isn't obvious or
universal, and there are various other knobs which simply aren't
available for tasks.
The blkio controller implicitly creates a hidden leaf node for each
The io controller implicitly creates a hidden leaf node for each
cgroup to host the tasks. The hidden leaf has its own copies of all
the knobs with "leaf_" prefixed. While this allows equivalent control
over internal tasks, it's with serious drawbacks. It always adds an
@ -372,14 +375,128 @@ supported and the interface files "release_agent" and
- The "cgroup.clone_children" file is removed.
5-3. Per-Controller Changes
5-3. Controller File Conventions
5-3-1. blkio
5-3-1. Format
- blk-throttle becomes properly hierarchical.
In general, all controller files should be in one of the following
formats whenever possible.
- Values only files
VAL0 VAL1...\n
- Flat keyed files
KEY0 VAL0\n
KEY1 VAL1\n
...
- Nested keyed files
KEY0 SUB_KEY0=VAL00 SUB_KEY1=VAL01...
KEY1 SUB_KEY0=VAL10 SUB_KEY1=VAL11...
...
For a writeable file, the format for writing should generally match
reading; however, controllers may allow omitting later fields or
implement restricted shortcuts for most common use cases.
For both flat and nested keyed files, only the values for a single key
can be written at a time. For nested keyed files, the sub key pairs
may be specified in any order and not all pairs have to be specified.
5-3-2. cpuset
5-3-2. Control Knobs
- Settings for a single feature should generally be implemented in a
single file.
- In general, the root cgroup should be exempt from resource control
and thus shouldn't have resource control knobs.
- If a controller implements ratio based resource distribution, the
control knob should be named "weight" and have the range [1, 10000]
and 100 should be the default value. The values are chosen to allow
enough and symmetric bias in both directions while keeping it
intuitive (the default is 100%).
- If a controller implements an absolute resource guarantee and/or
limit, the control knobs should be named "min" and "max"
respectively. If a controller implements best effort resource
gurantee and/or limit, the control knobs should be named "low" and
"high" respectively.
In the above four control files, the special token "max" should be
used to represent upward infinity for both reading and writing.
- If a setting has configurable default value and specific overrides,
the default settings should be keyed with "default" and appear as
the first entry in the file. Specific entries can use "default" as
its value to indicate inheritance of the default value.
5-4. Per-Controller Changes
5-4-1. io
- blkio is renamed to io. The interface is overhauled anyway. The
new name is more in line with the other two major controllers, cpu
and memory, and better suited given that it may be used for cgroup
writeback without involving block layer.
- Everything including stat is always hierarchical making separate
recursive stat files pointless and, as no internal node can have
tasks, leaf weights are meaningless. The operation model is
simplified and the interface is overhauled accordingly.
io.stat
The stat file. The reported stats are from the point where
bio's are issued to request_queue. The stats are counted
independent of which policies are enabled. Each line in the
file follows the following format. More fields may later be
added at the end.
$MAJ:$MIN rbytes=$RBYTES wbytes=$WBYTES rios=$RIOS wrios=$WIOS
io.weight
The weight setting, currently only available and effective if
cfq-iosched is in use for the target device. The weight is
between 1 and 10000 and defaults to 100. The first line
always contains the default weight in the following format to
use when per-device setting is missing.
default $WEIGHT
Subsequent lines list per-device weights of the following
format.
$MAJ:$MIN $WEIGHT
Writing "$WEIGHT" or "default $WEIGHT" changes the default
setting. Writing "$MAJ:$MIN $WEIGHT" sets per-device weight
while "$MAJ:$MIN default" clears it.
This file is available only on non-root cgroups.
io.max
The maximum bandwidth and/or iops setting, only available if
blk-throttle is enabled. The file is of the following format.
$MAJ:$MIN rbps=$RBPS wbps=$WBPS riops=$RIOPS wiops=$WIOPS
${R|W}BPS are read/write bytes per second and ${R|W}IOPS are
read/write IOs per second. "max" indicates no limit. Writing
to the file follows the same format but the individual
settings may be ommitted or specified in any order.
This file is available only on non-root cgroups.
5-4-2. cpuset
- Tasks are kept in empty cpusets after hotplug and take on the masks
of the nearest non-empty ancestor, instead of being moved to it.
@ -388,7 +505,7 @@ supported and the interface files "release_agent" and
masks of the nearest non-empty ancestor.
5-3-3. memory
5-4-3. memory
- use_hierarchy is on by default and the cgroup file for the flag is
not created.

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

@ -55,16 +55,13 @@ transition notifiers.
----------------------------
These are notified when a new policy is intended to be set. Each
CPUFreq policy notifier is called three times for a policy transition:
CPUFreq policy notifier is called twice for a policy transition:
1.) During CPUFREQ_ADJUST all CPUFreq notifiers may change the limit if
they see a need for this - may it be thermal considerations or
hardware limitations.
2.) During CPUFREQ_INCOMPATIBLE only changes may be done in order to avoid
hardware failure.
3.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
2.) And during CPUFREQ_NOTIFY all notifiers are informed of the new policy
- if two hardware drivers failed to agree on a new policy before this
stage, the incompatible hardware shall be shut down, and the user
informed of this.

31
Documentation/device-mapper/dm-raid.txt
View File

@ -209,6 +209,37 @@ include:
"repair" - Initiate a repair of the array.
"reshape"- Currently unsupported (-EINVAL).
Discard Support
---------------
The implementation of discard support among hardware vendors varies.
When a block is discarded, some storage devices will return zeroes when
the block is read. These devices set the 'discard_zeroes_data'
attribute. Other devices will return random data. Confusingly, some
devices that advertise 'discard_zeroes_data' will not reliably return
zeroes when discarded blocks are read! Since RAID 4/5/6 uses blocks
from a number of devices to calculate parity blocks and (for performance
reasons) relies on 'discard_zeroes_data' being reliable, it is important
that the devices be consistent. Blocks may be discarded in the middle
of a RAID 4/5/6 stripe and if subsequent read results are not
consistent, the parity blocks may be calculated differently at any time;
making the parity blocks useless for redundancy. It is important to
understand how your hardware behaves with discards if you are going to
enable discards with RAID 4/5/6.
Since the behavior of storage devices is unreliable in this respect,
even when reporting 'discard_zeroes_data', by default RAID 4/5/6
discard support is disabled -- this ensures data integrity at the
expense of losing some performance.
Storage devices that properly support 'discard_zeroes_data' are
increasingly whitelisted in the kernel and can thus be trusted.
For trusted devices, the following dm-raid module parameter can be set
to safely enable discard support for RAID 4/5/6:
'devices_handle_discards_safely'
Version History
---------------
1.0.0 Initial version. Support for RAID 4/5/6

4
Documentation/device-mapper/statistics.txt
View File

@ -121,6 +121,10 @@ Messages
Output format:
<region_id>: <start_sector>+<length> <step> <program_id> <aux_data>
precise_timestamps histogram:n1,n2,n3,...
The strings "precise_timestamps" and "histogram" are printed only
if they were specified when creating the region.
@stats_print <region_id> [<starting_line> <number_of_lines>]

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

@ -0,0 +1,9 @@
Broadcom North Star 2 (NS2) device tree bindings
------------------------------------------------
Boards with NS2 shall have the following properties:
Required root node property:
NS2 SVK board
compatible = "brcm,ns2-svk", "brcm,ns2";

6
Documentation/devicetree/bindings/arm/l2cc.txt
View File

@ -67,6 +67,12 @@ Optional properties:
disable if zero.
- arm,prefetch-offset : Override prefetch offset value. Valid values are
0-7, 15, 23, and 31.
- arm,shared-override : The default behavior of the pl310 cache controller with
respect to the shareable attribute is to transform "normal memory
non-cacheable transactions" into "cacheable no allocate" (for reads) or
"write through no write allocate" (for writes).
On systems where this may cause DMA buffer corruption, this property must be
specified to indicate that such transforms are precluded.
- prefetch-data : Data prefetch. Value: <0> (forcibly disable), <1>
(forcibly enable), property absent (retain settings set by firmware)
- prefetch-instr : Instruction prefetch. Value: <0> (forcibly disable),

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

@ -1,6 +1,7 @@
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:
@ -8,6 +9,7 @@ compatible: Must contain one of
"mediatek,mt6580"
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt6795"
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
@ -24,6 +26,9 @@ Supported boards:
- 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";

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

@ -1,4 +1,4 @@
Mediatek 65xx/81xx sysirq
+Mediatek 65xx/67xx/81xx sysirq
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
interrupt.
@ -8,6 +8,7 @@ Required properties:
"mediatek,mt8173-sysirq"
"mediatek,mt8135-sysirq"
"mediatek,mt8127-sysirq"
"mediatek,mt6795-sysirq"
"mediatek,mt6592-sysirq"
"mediatek,mt6589-sysirq"
"mediatek,mt6582-sysirq"

12
Documentation/devicetree/bindings/arm/pmu.txt
View File

@ -26,13 +26,19 @@ Required properties:
Optional properties:
- interrupt-affinity : Valid only when using SPIs, specifies a list of phandles
to CPU nodes corresponding directly to the affinity of
- interrupt-affinity : When using SPIs, specifies a list of phandles to CPU
nodes corresponding directly to the affinity of
the SPIs listed in the interrupts property.
This property should be present when there is more than
When using a PPI, specifies a list of phandles to CPU
nodes corresponding to the set of CPUs which have
a PMU of this type signalling the PPI listed in the
interrupts property.
This property should be present when there is more than
a single SPI.
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
events.

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

@ -0,0 +1,83 @@
Device Tree Clock bindins for CPU DVFS of Mediatek MT8173 SoC
Required properties:
- clocks: A list of phandle + clock-specifier pairs for the clocks listed in clock names.
- clock-names: Should contain the following:
"cpu" - The multiplexer for clock input of CPU cluster.
"intermediate" - A parent of "cpu" clock which is used as "intermediate" clock
source (usually MAINPLL) when the original CPU PLL is under
transition and not stable yet.
Please refer to Documentation/devicetree/bindings/clk/clock-bindings.txt for
generic clock consumer properties.
- proc-supply: Regulator for Vproc of CPU cluster.
Optional properties:
- sram-supply: Regulator for Vsram of CPU cluster. When present, the cpufreq driver
needs to do "voltage tracking" to step by step scale up/down Vproc and
Vsram to fit SoC specific needs. When absent, the voltage scaling
flow is handled by hardware, hence no software "voltage tracking" is
needed.
Example:
--------
cpu0: cpu@0 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x000>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&infracfg CLK_INFRA_CA53SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
};
cpu1: cpu@1 {
device_type = "cpu";
compatible = "arm,cortex-a53";
reg = <0x001>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&infracfg CLK_INFRA_CA53SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
};
cpu2: cpu@100 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x100>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&infracfg CLK_INFRA_CA57SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
};
cpu3: cpu@101 {
device_type = "cpu";
compatible = "arm,cortex-a57";
reg = <0x101>;
enable-method = "psci";
cpu-idle-states = <&CPU_SLEEP_0>;
clocks = <&infracfg CLK_INFRA_CA57SEL>,
<&apmixedsys CLK_APMIXED_MAINPLL>;
clock-names = "cpu", "intermediate";
};
&cpu0 {
proc-supply = <&mt6397_vpca15_reg>;
};
&cpu1 {
proc-supply = <&mt6397_vpca15_reg>;
};
&cpu2 {
proc-supply = <&da9211_vcpu_reg>;
sram-supply = <&mt6397_vsramca7_reg>;
};
&cpu3 {
proc-supply = <&da9211_vcpu_reg>;
sram-supply = <&mt6397_vsramca7_reg>;
};

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

@ -11,15 +11,14 @@ to various devfreq devices. The devfreq devices would use the event data when
derterming the current state of each IP.
Required properties:
- compatible: Should be "samsung,exynos-ppmu".
- compatible: Should be "samsung,exynos-ppmu" or "samsung,exynos-ppmu-v2.
- reg: physical base address of each PPMU and length of memory mapped region.
Optional properties:
- clock-names : the name of clock used by the PPMU, "ppmu"
- clocks : phandles for clock specified in "clock-names" property
- #clock-cells: should be 1.
Example1 : PPMU nodes in exynos3250.dtsi are listed below.
Example1 : PPMUv1 nodes in exynos3250.dtsi are listed below.
ppmu_dmc0: ppmu_dmc0@106a0000 {
compatible = "samsung,exynos-ppmu";
@ -108,3 +107,41 @@ Example2 : Events of each PPMU node in exynos3250-rinato.dts are listed below.
};
};
};
Example3 : PPMUv2 nodes in exynos5433.dtsi are listed below.
ppmu_d0_cpu: ppmu_d0_cpu@10480000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x10480000 0x2000>;
status = "disabled";
};
ppmu_d0_general: ppmu_d0_general@10490000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x10490000 0x2000>;
status = "disabled";
};
ppmu_d0_rt: ppmu_d0_rt@104a0000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x104a0000 0x2000>;
status = "disabled";
};
ppmu_d1_cpu: ppmu_d1_cpu@104b0000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x104b0000 0x2000>;
status = "disabled";
};
ppmu_d1_general: ppmu_d1_general@104c0000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x104c0000 0x2000>;
status = "disabled";
};
ppmu_d1_rt: ppmu_d1_rt@104d0000 {
compatible = "samsung,exynos-ppmu-v2";
reg = <0x104d0000 0x2000>;
status = "disabled";
};

61
Documentation/devicetree/bindings/dma/adi,axi-dmac.txt Normal file
View File

@ -0,0 +1,61 @@
Analog Device AXI-DMAC DMA controller
Required properties:
- compatible: Must be "adi,axi-dmac-1.00.a".
- reg: Specification for the controllers memory mapped register map.
- interrupts: Specification for the controllers interrupt.
- clocks: Phandle and specifier to the controllers AXI interface clock
- #dma-cells: Must be 1.
Required sub-nodes:
- adi,channels: This sub-node must contain a sub-node for each DMA channel. For
the channel sub-nodes the following bindings apply. They must match the
configuration options of the peripheral as it was instantiated.
Required properties for adi,channels sub-node:
- #size-cells: Must be 0
- #address-cells: Must be 1
Required channel sub-node properties:
- reg: Which channel this node refers to.
- adi,length-width: Width of the DMA transfer length register.
- adi,source-bus-width,
adi,destination-bus-width: Width of the source or destination bus in bits.
- adi,source-bus-type,
adi,destination-bus-type: Type of the source or destination bus. Must be one
of the following:
0 (AXI_DMAC_TYPE_AXI_MM): Memory mapped AXI interface
1 (AXI_DMAC_TYPE_AXI_STREAM): Streaming AXI interface
2 (AXI_DMAC_TYPE_AXI_FIFO): FIFO interface
Optional channel properties:
- adi,cyclic: Must be set if the channel supports hardware cyclic DMA
transfers.
- adi,2d: Must be set if the channel supports hardware 2D DMA transfers.
DMA clients connected to the AXI-DMAC DMA controller must use the format
described in the dma.txt file using a one-cell specifier. The value of the
specifier refers to the DMA channel index.
Example:
dma: dma@7c420000 {
compatible = "adi,axi-dmac-1.00.a";
reg = <0x7c420000 0x10000>;
interrupts = <0 57 0>;
clocks = <&clkc 16>;
#dma-cells = <1>;
adi,channels {
#size-cells = <0>;
#address-cells = <1>;
dma-channel@0 {
reg = <0>;
adi,source-bus-width = <32>;
adi,source-bus-type = <ADI_AXI_DMAC_TYPE_MM_AXI>;
adi,destination-bus-width = <64>;
adi,destination-bus-type = <ADI_AXI_DMAC_TYPE_FIFO>;
};
};
};

54
Documentation/devicetree/bindings/dma/arm-pl08x.txt Normal file
View File

@ -0,0 +1,54 @@
* ARM PrimeCells PL080 and PL081 and derivatives DMA controller
Required properties:
- compatible: "arm,pl080", "arm,primecell";
"arm,pl081", "arm,primecell";
- reg: Address range of the PL08x registers
- interrupt: The PL08x interrupt number
- clocks: The clock running the IP core clock
- clock-names: Must contain "apb_pclk"
- lli-bus-interface-ahb1: if AHB master 1 is eligible for fetching LLIs
- lli-bus-interface-ahb2: if AHB master 2 is eligible for fetching LLIs
- mem-bus-interface-ahb1: if AHB master 1 is eligible for fetching memory contents
- mem-bus-interface-ahb2: if AHB master 2 is eligible for fetching memory contents
- #dma-cells: must be <2>. First cell should contain the DMA request,
second cell should contain either 1 or 2 depending on
which AHB master that is used.
Optional properties:
- dma-channels: contains the total number of DMA channels supported by the DMAC
- dma-requests: contains the total number of DMA requests supported by the DMAC
- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32
64, 128 or 256 bytes are legal values
- memcpy-bus-width: the bus width used for memcpy: 8, 16 or 32 are legal
values
Clients
Required properties:
- dmas: List of DMA controller phandle, request channel and AHB master id
- dma-names: Names of the aforementioned requested channels
Example:
dmac0: dma-controller@10130000 {
compatible = "arm,pl080", "arm,primecell";
reg = <0x10130000 0x1000>;
interrupt-parent = <&vica>;
interrupts = <15>;
clocks = <&hclkdma0>;
clock-names = "apb_pclk";
lli-bus-interface-ahb1;
lli-bus-interface-ahb2;
mem-bus-interface-ahb2;
memcpy-burst-size = <256>;
memcpy-bus-width = <32>;
#dma-cells = <2>;
};
device@40008000 {
...
dmas = <&dmac0 0 2
&dmac0 1 2>;
dma-names = "tx", "rx";
...
};

54
Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt Normal file
View File

@ -0,0 +1,54 @@
NXP LPC18xx/43xx DMA MUX (DMA request router)
Required properties:
- compatible: "nxp,lpc1850-dmamux"
- reg: Memory map for accessing module
- #dma-cells: Should be set to <3>.
* 1st cell contain the master dma request signal
* 2nd cell contain the mux value (0-3) for the peripheral
* 3rd cell contain either 1 or 2 depending on the AHB
master used.
- dma-requests: Number of DMA requests for the mux
- dma-masters: phandle pointing to the DMA controller
The DMA controller node need to have the following poroperties:
- dma-requests: Number of DMA requests the controller can handle
Example:
dmac: dma@40002000 {
compatible = "nxp,lpc1850-gpdma", "arm,pl080", "arm,primecell";
arm,primecell-periphid = <0x00041080>;
reg = <0x40002000 0x1000>;
interrupts = <2>;
clocks = <&ccu1 CLK_CPU_DMA>;
clock-names = "apb_pclk";
#dma-cells = <2>;
dma-channels = <8>;
dma-requests = <16>;
lli-bus-interface-ahb1;
lli-bus-interface-ahb2;
mem-bus-interface-ahb1;
mem-bus-interface-ahb2;
memcpy-burst-size = <256>;
memcpy-bus-width = <32>;
};
dmamux: dma-mux {
compatible = "nxp,lpc1850-dmamux";
#dma-cells = <3>;
dma-requests = <64>;
dma-masters = <&dmac>;
};
uart0: serial@40081000 {
compatible = "nxp,lpc1850-uart", "ns16550a";
reg = <0x40081000 0x1000>;
reg-shift = <2>;
interrupts = <24>;
clocks = <&ccu2 CLK_APB0_UART0>, <&ccu1 CLK_CPU_UART0>;
clock-names = "uartclk", "reg";
dmas = <&dmamux 1 1 2
&dmamux 2 1 2>;
dma-names = "tx", "rx";
};

10
Documentation/devicetree/bindings/dma/mv-xor.txt
View File

@ -12,10 +12,13 @@ XOR engine has. Those sub-nodes have the following required
properties:
- interrupts: interrupt of the XOR channel
And the following optional properties:
The sub-nodes used to contain one or several of the following
properties, but they are now deprecated:
- dmacap,memcpy to indicate that the XOR channel is capable of memcpy operations
- dmacap,memset to indicate that the XOR channel is capable of memset operations
- dmacap,xor to indicate that the XOR channel is capable of xor operations
- dmacap,interrupt to indicate that the XOR channel is capable of
generating interrupts
Example:
@ -28,13 +31,8 @@ xor@d0060900 {
xor00 {
interrupts = <51>;
dmacap,memcpy;
dmacap,xor;
};
xor01 {
interrupts = <52>;
dmacap,memcpy;
dmacap,xor;
dmacap,memset;
};
};

46
Documentation/devicetree/bindings/dma/sun4i-dma.txt Normal file
View File

@ -0,0 +1,46 @@
Allwinner A10 DMA Controller
This driver follows the generic DMA bindings defined in dma.txt.
Required properties:
- compatible: Must be "allwinner,sun4i-a10-dma"
- reg: Should contain the registers base address and length
- interrupts: Should contain a reference to the interrupt used by this device
- clocks: Should contain a reference to the parent AHB clock
- #dma-cells : Should be 2, first cell denoting normal or dedicated dma,
second cell holding the request line number.
Example:
dma: dma-controller@01c02000 {
compatible = "allwinner,sun4i-a10-dma";
reg = <0x01c02000 0x1000>;
interrupts = <27>;
clocks = <&ahb_gates 6>;
#dma-cells = <2>;
};
Clients:
DMA clients connected to the Allwinner A10 DMA controller must use the
format described in the dma.txt file, using a three-cell specifier for
each channel: a phandle plus two integer cells.
The three cells in order are:
1. A phandle pointing to the DMA controller.
2. Whether it is using normal (0) or dedicated (1) channels
3. The port ID as specified in the datasheet
Example:
spi2: spi@01c17000 {
compatible = "allwinner,sun4i-a10-spi";
reg = <0x01c17000 0x1000>;
interrupts = <0 12 4>;
clocks = <&ahb_gates 22>, <&spi2_clk>;
clock-names = "ahb", "mod";
dmas = <&dma 1 29>, <&dma 1 28>;
dma-names = "rx", "tx";
status = "disabled";
#address-cells = <1>;
#size-cells = <0>;
};

38
Documentation/devicetree/bindings/dma/zxdma.txt Normal file
View File

@ -0,0 +1,38 @@
* ZTE ZX296702 DMA controller
Required properties:
- compatible: Should be "zte,zx296702-dma"
- reg: Should contain DMA registers location and length.
- interrupts: Should contain one interrupt shared by all channel
- #dma-cells: see dma.txt, should be 1, para number
- dma-channels: physical channels supported
- dma-requests: virtual channels supported, each virtual channel
have specific request line
- clocks: clock required
Example:
Controller:
dma: dma-controller@0x09c00000{
compatible = "zte,zx296702-dma";
reg = <0x09c00000 0x1000>;
clocks = <&topclk ZX296702_DMA_ACLK>;
interrupts = <GIC_SPI 66 IRQ_TYPE_LEVEL_HIGH>;
#dma-cells = <1>;
dma-channels = <24>;
dma-requests = <24>;
};
Client:
Use specific request line passing from dmax
For example, spdif0 tx channel request line is 4
spdif0: spdif0@0b004000 {
#sound-dai-cells = <0>;
compatible = "zte,zx296702-spdif";
reg = <0x0b004000 0x1000>;
clocks = <&lsp0clk ZX296702_SPDIF0_DIV>;
clock-names = "tx";
interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>;
dmas = <&dma 4>;
dma-names = "tx";
}

41
Documentation/devicetree/bindings/drm/msm/dsi.txt
View File

@ -30,20 +30,27 @@ Optional properties:
- panel@0: Node of panel connected to this DSI controller.
See files in Documentation/devicetree/bindings/panel/ for each supported
panel.
- qcom,dual-panel-mode: Boolean value indicating if the DSI controller is
- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is
driving a panel which needs 2 DSI links.
- qcom,master-panel: Boolean value indicating if the DSI controller is driving
- qcom,master-dsi: Boolean value indicating if the DSI controller is driving
the master link of the 2-DSI panel.
- qcom,sync-dual-panel: Boolean value indicating if the DSI controller is
- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is
driving a 2-DSI panel whose 2 links need receive command simultaneously.
- interrupt-parent: phandle to the MDP block if the interrupt signal is routed
through MDP block
- pinctrl-names: the pin control state names; should contain "default"
- pinctrl-0: the default pinctrl state (active)
- pinctrl-n: the "sleep" pinctrl state
- port: DSI controller output port. This contains one endpoint subnode, with its
remote-endpoint set to the phandle of the connected panel's endpoint.
See Documentation/devicetree/bindings/graph.txt for device graph info.
DSI PHY:
Required properties:
- compatible: Could be the following
* "qcom,dsi-phy-28nm-hpm"
* "qcom,dsi-phy-28nm-lp"
* "qcom,dsi-phy-20nm"
- reg: Physical base address and length of the registers of PLL, PHY and PHY
regulator
- reg-names: The names of register regions. The following regions are required:
@ -59,6 +66,10 @@ Required properties:
* "iface_clk"
- vddio-supply: phandle to vdd-io regulator device node
Optional properties:
- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY
regulator is wanted.
Example:
mdss_dsi0: qcom,mdss_dsi@fd922800 {
compatible = "qcom,mdss-dsi-ctrl";
@ -90,9 +101,13 @@ Example:
qcom,dsi-phy = <&mdss_dsi_phy0>;
qcom,dual-panel-mode;
qcom,master-panel;
qcom,sync-dual-panel;
qcom,dual-dsi-mode;
qcom,master-dsi;
qcom,sync-dual-dsi;
pinctrl-names = "default", "sleep";
pinctrl-0 = <&mdss_dsi_active>;
pinctrl-1 = <&mdss_dsi_suspend>;
panel: panel@0 {
compatible = "sharp,lq101r1sx01";
@ -101,6 +116,18 @@ Example:
power-supply = <...>;
backlight = <...>;
port {
panel_in: endpoint {
remote-endpoint = <&dsi0_out>;
};
};
};
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
};
};
};
@ -117,4 +144,6 @@ Example:
clock-names = "iface_clk";
clocks = <&mmcc MDSS_AHB_CLK>;
vddio-supply = <&pma8084_l12>;
qcom,dsi-phy-regulator-ldo-mode;
};

3
Documentation/devicetree/bindings/drm/msm/hdmi.txt
View File

@ -2,8 +2,9 @@ Qualcomm adreno/snapdragon hdmi output
Required properties:
- compatible: one of the following
* "qcom,hdmi-tx-8994"
* "qcom,hdmi-tx-8084"
* "qcom,hdmi-tx-8074"
* "qcom,hdmi-tx-8974"
* "qcom,hdmi-tx-8660"
* "qcom,hdmi-tx-8960"
- reg: Physical base address and length of the controller's registers

35
Documentation/devicetree/bindings/gpio/brcm,brcmstb-gpio.txt
View File

@ -33,6 +33,13 @@ Optional properties:
- interrupt-parent:
phandle of the parent interrupt controller
- interrupts-extended:
Alternate form of specifying interrupts and parents that allows for
multiple parents. This takes precedence over 'interrupts' and
'interrupt-parent'. Wakeup-capable GPIO controllers often route their
wakeup interrupt lines through a different interrupt controller than the
primary interrupt line, making this property necessary.
- #interrupt-cells:
Should be <2>. The first cell is the GPIO number, the second should specify
flags. The following subset of flags is supported:
@ -47,19 +54,33 @@ Optional properties:
- interrupt-controller:
Marks the device node as an interrupt controller
- interrupt-names:
The name of the IRQ resource used by this controller
- wakeup-source:
GPIOs for this controller can be used as a wakeup source
Example:
upg_gio: gpio@f040a700 {
#gpio-cells = <0x2>;
#interrupt-cells = <0x2>;
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf040a700 0x80>;
interrupt-parent = <0xf>;
interrupt-parent = <&irq0_intc>;
interrupts = <0x6>;
interrupt-names = "upg_gio";
brcm,gpio-bank-widths = <0x20 0x20 0x20 0x18>;
brcm,gpio-bank-widths = <32 32 32 24>;
};
upg_gio_aon: gpio@f04172c0 {
#gpio-cells = <2>;
#interrupt-cells = <2>;
compatible = "brcm,bcm7445-gpio", "brcm,brcmstb-gpio";
gpio-controller;
interrupt-controller;
reg = <0xf04172c0 0x40>;
interrupt-parent = <&irq0_aon_intc>;
interrupts = <0x6>;
interrupts-extended = <&irq0_aon_intc 0x6>,
<&aon_pm_l2_intc 0x5>;
wakeup-source;
brcm,gpio-bank-widths = <18 4>;
};

3
Documentation/devicetree/bindings/gpio/gpio-etraxfs.txt
View File

@ -2,8 +2,9 @@ Axis ETRAX FS General I/O controller bindings
Required properties:
- compatible:
- compatible: one of:
- "axis,etraxfs-gio"
- "axis,artpec3-gio"
- reg: Physical base address and length of the controller's registers.
- #gpio-cells: Should be 3
- The first cell is the gpio offset number.

22
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt Normal file
View File

@ -0,0 +1,22 @@
* Freescale MPC512x/MPC8xxx GPIO controller
Required properties:
- compatible : Should be "fsl,<soc>-gpio"
The following <soc>s are known to be supported:
mpc5121, mpc5125, mpc8349, mpc8572, mpc8610, pq3, qoriq
- reg : Address and length of the register set for the device
- interrupts : Should be the port interrupt shared by all 32 pins.
- #gpio-cells : Should be two. The first cell is the pin number and
the second cell is used to specify the gpio polarity:
0 = active high
1 = active low
Example:
gpio0: gpio@1100 {
compatible = "fsl,mpc5125-gpio";
#gpio-cells = <2>;
reg = <0x1100 0x080>;
interrupts = <78 0x8>;
status = "okay";
};

1
Documentation/devicetree/bindings/gpio/renesas,gpio-rcar.txt
View File

@ -9,6 +9,7 @@ Required Properties:
- "renesas,gpio-r8a7791": for R8A7791 (R-Car M2-W) compatible GPIO controller.
- "renesas,gpio-r8a7793": for R8A7793 (R-Car M2-N) compatible GPIO controller.
- "renesas,gpio-r8a7794": for R8A7794 (R-Car E2) compatible GPIO controller.
- "renesas,gpio-r8a7795": for R8A7795 (R-Car H3) compatible GPIO controller.
- "renesas,gpio-rcar": for generic R-Car GPIO controller.
- reg: Base address and length of each memory resource used by the GPIO

24
Documentation/devicetree/bindings/gpio/zx296702-gpio.txt Normal file
View File

@ -0,0 +1,24 @@
ZTE ZX296702 GPIO controller
Required properties:
- compatible : "zte,zx296702-gpio"
- #gpio-cells : Should be two. The first cell is the pin number and the
second cell is used to specify optional parameters:
- bit 0 specifies polarity (0 for normal, 1 for inverted)
- gpio-controller : Marks the device node as a GPIO controller.
- interrupts : Interrupt mapping for GPIO IRQ.
- gpio-ranges : Interaction with the PINCTRL subsystem.
gpio1: gpio@b008040 {
compatible = "zte,zx296702-gpio";
reg = <0xb008040 0x40>;
gpio-controller;
#gpio-cells = <2>;
gpio-ranges = < &pmx0 0 54 2 &pmx0 2 59 14>;
interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>;
interrupt-parent = <&intc>;
interrupt-controller;
#interrupt-cells = <2>;
clock-names = "gpio_pclk";
clocks = <&lsp0clk ZX296702_GPIO_CLK>;
};

8
Documentation/devicetree/bindings/gpu/nvidia,tegra20-host1x.txt
View File

@ -197,9 +197,11 @@ of the following host1x client modules:
- sor: serial output resource
Required properties:
- compatible: For Tegra124, must contain "nvidia,tegra124-sor". Otherwise,
must contain '"nvidia,<chip>-sor", "nvidia,tegra124-sor"', where <chip>
is tegra132.
- compatible: Should be:
- "nvidia,tegra124-sor": for Tegra124 and Tegra132
- "nvidia,tegra132-sor": for Tegra132
- "nvidia,tegra210-sor": for Tegra210
- "nvidia,tegra210-sor1": for Tegra210
- reg: Physical base address and length of the controller's registers.
- interrupts: The interrupt outputs from the controller.
- clocks: Must contain an entry for each entry in clock-names.

66
Documentation/devicetree/bindings/gpu/st,stih4xx.txt
View File

@ -52,10 +52,9 @@ STMicroelectronics stih4xx platforms
See ../reset/reset.txt for details.
- reset-names: names of the resets listed in resets property in the same
order.
- ranges: to allow probing of subdevices
- sti-hdmi: hdmi output block
must be a child of sti-tvout
must be a child of sti-display-subsystem
Required properties:
- compatible: "st,stih<chip>-hdmi";
- reg: Physical base address of the IP registers and length of memory mapped region.
@ -72,7 +71,7 @@ STMicroelectronics stih4xx platforms
sti-hda:
Required properties:
must be a child of sti-tvout
must be a child of sti-display-subsystem
- compatible: "st,stih<chip>-hda"
- reg: Physical base address of the IP registers and length of memory mapped region.
- reg-names: names of the mapped memory regions listed in regs property in
@ -85,7 +84,7 @@ sti-hda:
sti-dvo:
Required properties:
must be a child of sti-tvout
must be a child of sti-display-subsystem
- compatible: "st,stih<chip>-dvo"
- reg: Physical base address of the IP registers and length of memory mapped region.
- reg-names: names of the mapped memory regions listed in regs property in
@ -195,38 +194,37 @@ Example:
reg-names = "tvout-reg", "hda-reg", "syscfg";
reset-names = "tvout";
resets = <&softreset STIH416_HDTVOUT_SOFTRESET>;
ranges;
};
sti-hdmi@fe85c000 {
compatible = "st,stih416-hdmi";
reg = <0xfe85c000 0x1000>, <0xfe830000 0x10000>;
reg-names = "hdmi-reg", "syscfg";
interrupts = <GIC_SPI 173 IRQ_TYPE_NONE>;
interrupt-names = "irq";
clock-names = "pix", "tmds", "phy", "audio";
clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>;
};
sti-hdmi@fe85c000 {
compatible = "st,stih416-hdmi";
reg = <0xfe85c000 0x1000>, <0xfe830000 0x10000>;
reg-names = "hdmi-reg", "syscfg";
interrupts = <GIC_SPI 173 IRQ_TYPE_NONE>;
interrupt-names = "irq";
clock-names = "pix", "tmds", "phy", "audio";
clocks = <&clockgen_c_vcc CLK_S_PIX_HDMI>, <&clockgen_c_vcc CLK_S_TMDS_HDMI>, <&clockgen_c_vcc CLK_S_HDMI_REJECT_PLL>, <&clockgen_b1 CLK_S_PCM_0>;
};
sti-hda@fe85a000 {
compatible = "st,stih416-hda";
reg = <0xfe85a000 0x400>, <0xfe83085c 0x4>;
reg-names = "hda-reg", "video-dacs-ctrl";
clock-names = "pix", "hddac";
clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>;
};
sti-hda@fe85a000 {
compatible = "st,stih416-hda";
reg = <0xfe85a000 0x400>, <0xfe83085c 0x4>;
reg-names = "hda-reg", "video-dacs-ctrl";
clock-names = "pix", "hddac";
clocks = <&clockgen_c_vcc CLK_S_PIX_HD>, <&clockgen_c_vcc CLK_S_HDDAC>;
};
sti-dvo@8d00400 {
compatible = "st,stih407-dvo";
reg = <0x8d00400 0x200>;
reg-names = "dvo-reg";
clock-names = "dvo_pix", "dvo",
"main_parent", "aux_parent";
clocks = <&clk_s_d2_flexgen CLK_PIX_DVO>, <&clk_s_d2_flexgen CLK_DVO>,
<&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dvo>;
sti,panel = <&panel_dvo>;
};
sti-dvo@8d00400 {
compatible = "st,stih407-dvo";
reg = <0x8d00400 0x200>;
reg-names = "dvo-reg";
clock-names = "dvo_pix", "dvo",
"main_parent", "aux_parent";
clocks = <&clk_s_d2_flexgen CLK_PIX_DVO>, <&clk_s_d2_flexgen CLK_DVO>,
<&clk_s_d2_quadfs 0>, <&clk_s_d2_quadfs 1>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_dvo>;
sti,panel = <&panel_dvo>;
};
sti-hqvdp@9c000000 {
@ -237,7 +235,7 @@ Example:
reset-names = "hqvdp";
resets = <&softreset STIH407_HDQVDP_SOFTRESET>;
st,vtg = <&vtg_main>;
};
};
};
...
};

0
Documentation/devicetree/bindings/i2c/ina209.txt → Documentation/devicetree/bindings/hwmon/ina209.txt
View File

0
Documentation/devicetree/bindings/i2c/ina2xx.txt → Documentation/devicetree/bindings/hwmon/ina2xx.txt
View File

0
Documentation/devicetree/bindings/i2c/max6697.txt → Documentation/devicetree/bindings/hwmon/max6697.txt
View File

6
Documentation/devicetree/bindings/i2c/i2c-cadence.txt
View File

@ -2,7 +2,11 @@ Binding for the Cadence I2C controller
Required properties:
- reg: Physical base address and size of the controller's register area.
- compatible: Compatibility string. Must be 'cdns,i2c-r1p10'.
- compatible: Should contain one of:
* "cdns,i2c-r1p10"
Note: Use this when cadence i2c controller version 1.0 is used.
* "cdns,i2c-r1p14"
Note: Use this when cadence i2c controller version 1.4 is used.
- clocks: Input clock specifier. Refer to common clock bindings.
- interrupts: Interrupt specifier. Refer to interrupt bindings.
- #address-cells: Should be 1.

22
Documentation/devicetree/bindings/i2c/i2c-emev2.txt Normal file
View File

@ -0,0 +1,22 @@
Device tree configuration for Renesas EMEV2 IIC controller
Required properties:
- compatible : "renesas,iic-emev2"
- reg : address start and address range size of device
- interrupts : specifier for the IIC controller interrupt
- clocks : phandle to the IP core SCLK
- clock-names : must be "sclk"
- #address-cells : should be <1>
- #size-cells : should be <0>
Example:
iic0: i2c@e0070000 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "renesas,iic-emev2";
reg = <0xe0070000 0x28>;
interrupts = <0 32 IRQ_TYPE_EDGE_RISING>;
clocks = <&iic0_sclk>;
clock-names = "sclk";
};

33
Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt Normal file
View File

@ -0,0 +1,33 @@
NXP I2C controller for LPC2xxx/178x/18xx/43xx
Required properties:
- compatible: must be "nxp,lpc1788-i2c"
- reg: physical address and length of the device registers
- interrupts: a single interrupt specifier
- clocks: clock for the device
- #address-cells: should be <1>
- #size-cells: should be <0>
Optional properties:
- clock-frequency: the desired I2C bus clock frequency in Hz; in
absence of this property the default value is used (100 kHz).
Example:
i2c0: i2c@400a1000 {
compatible = "nxp,lpc1788-i2c";
reg = <0x400a1000 0x1000>;
interrupts = <18>;
clocks = <&ccu1 CLK_APB1_I2C0>;
#address-cells = <1>;
#size-cells = <0>;
};
&i2c0 {
clock-frequency = <400000>;
lm75@48 {
compatible = "nxp,lm75";
reg = <0x48>;
};
};

74
Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt Normal file
View File

@ -0,0 +1,74 @@
Register-based I2C Bus Mux
This binding describes an I2C bus multiplexer that uses a single register
to route the I2C signals.
Required properties:
- compatible: i2c-mux-reg
- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side
port is connected to.
* Standard I2C mux properties. See mux.txt in this directory.
* I2C child bus nodes. See mux.txt in this directory.
Optional properties:
- reg: this pair of <offset size> specifies the register to control the mux.
The <offset size> depends on its parent node. It can be any memory-mapped
address. The size must be either 1, 2, or 4 bytes. If reg is omitted, the
resource of this device will be used.
- little-endian: The existence indicates the register is in little endian.
- big-endian: The existence indicates the register is in big endian.
If both little-endian and big-endian are omitted, the endianness of the
CPU will be used.
- write-only: The existence indicates the register is write-only.
- idle-state: value to set the muxer to when idle. When no value is
given, it defaults to the last value used.
Whenever an access is made to a device on a child bus, the value set
in the revelant node's reg property will be output to the register.
If an idle state is defined, using the idle-state (optional) property,
whenever an access is not being made to a device on a child bus, the
register will be set according to the idle value.
If an idle state is not defined, the most recently used value will be
left programmed into the register.
Example of a mux on PCIe card, the host is a powerpc SoC (big endian):
i2c-mux {
/* the <offset size> depends on the address translation
* of the parent device. If omitted, device resource
* will be used instead. The size is to determine
* whether iowrite32, iowrite16, or iowrite8 will be used.
*/
reg = <0x6028 0x4>;
little-endian; /* little endian register on PCIe */
compatible = "i2c-mux-reg";
#address-cells = <1>;
#size-cells = <0>;
i2c-parent = <&i2c1>;
i2c@0 {
reg = <0>;
#address-cells = <1>;
#size-cells = <0>;
si5338: clock-generator@70 {
compatible = "silabs,si5338";
reg = <0x70>;
/* other stuff */
};
};
i2c@1 {
/* data is written using iowrite32 */
reg = <1>;
#address-cells = <1>;
#size-cells = <0>;
si5338: clock-generator@70 {
compatible = "silabs,si5338";
reg = <0x70>;
/* other stuff */
};
};
};

45
Documentation/devicetree/bindings/i2c/i2c.txt Normal file
View File

@ -0,0 +1,45 @@
Generic device tree bindings for I2C busses
===========================================
This document describes generic bindings which can be used to describe I2C
busses in a device tree.
Required properties
-------------------
- #address-cells - should be <1>. Read more about addresses below.
- #size-cells - should be <0>.
- compatible - name of I2C bus controller following generic names
recommended practice.
For other required properties e.g. to describe register sets,
clocks, etc. check the binding documentation of the specific driver.
The cells properties above define that an address of children of an I2C bus
are described by a single value. This is usually a 7 bit address. However,
flags can be attached to the address. I2C_TEN_BIT_ADDRESS is used to mark a 10
bit address. It is needed to avoid the ambiguity between e.g. a 7 bit address
of 0x50 and a 10 bit address of 0x050 which, in theory, can be on the same bus.
Another flag is I2C_OWN_SLAVE_ADDRESS to mark addresses on which we listen to
be devices ourselves.
Optional properties
-------------------
These properties may not be supported by all drivers. However, if a driver
wants to support one of the below features, it should adapt the bindings below.
- clock-frequency - frequency of bus clock in Hz.
- wakeup-source - device can be used as a wakeup source.
- interrupts - interrupts used by the device.
- interrupt-names - "irq" and "wakeup" names are recognized by I2C core,
other names are left to individual drivers.
Binding may contain optional "interrupts" property, describing interrupts
used by the device. I2C core will assign "irq" interrupt (or the very first
interrupt if not using interrupt names) as primary interrupt for the slave.
Also, if device is marked as a wakeup source, I2C core will set up "wakeup"
interrupt for the device. If "wakeup" interrupt name is not present in the
binding, then primary interrupt will be used as wakeup interrupt.

2
Documentation/devicetree/bindings/i2c/trivial-devices.txt
View File

@ -95,6 +95,8 @@ stm,m41t00 Serial Access TIMEKEEPER
stm,m41t62 Serial real-time clock (RTC) with alarm
stm,m41t80 M41T80 - SERIAL ACCESS RTC WITH ALARMS
taos,tsl2550 Ambient Light Sensor with SMBUS/Two Wire Serial Interface
ti,ads7828 8-Channels, 12-bit ADC
ti,ads7830 8-Channels, 8-bit ADC
ti,tsc2003 I2C Touch-Screen Controller
ti,tmp102 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface
ti,tmp103 Low Power Digital Temperature Sensor with SMBUS/Two Wire Serial Interface

2
Documentation/devicetree/bindings/input/ads7846.txt
View File

@ -64,7 +64,7 @@ Optional properties:
pendown-gpio (u32).
pendown-gpio GPIO handle describing the pin the !PENIRQ
line is connected to.
linux,wakeup use any event on touchscreen as wakeup event.
wakeup-source use any event on touchscreen as wakeup event.
Example for a TSC2046 chip connected to an McSPI controller of an OMAP SoC::

19
Documentation/devicetree/bindings/input/cap11xx.txt
View File

@ -55,5 +55,24 @@ i2c_controller {
<105>, /* KEY_LEFT */
<109>, /* KEY_PAGEDOWN */
<104>; /* KEY_PAGEUP */
#address-cells = <1>;
#size-cells = <0>;
usr@0 {
label = "cap11xx:green:usr0";
reg = <0>;
};
usr@1 {
label = "cap11xx:green:usr1";
reg = <1>;
};
alive@2 {
label = "cap11xx:green:alive";
reg = <2>;
linux,default_trigger = "heartbeat";
};
};
}

44
Documentation/devicetree/bindings/input/cypress,cyapa.txt Normal file
View File

@ -0,0 +1,44 @@
Cypress I2C Touchpad
Required properties:
- compatible: must be "cypress,cyapa".
- reg: I2C address of the chip.
- interrupt-parent: a phandle for the interrupt controller (see interrupt
binding[0]).
- interrupts: interrupt to which the chip is connected (see interrupt
binding[0]).
Optional properties:
- wakeup-source: touchpad can be used as a wakeup source.
- pinctrl-names: should be "default" (see pinctrl binding [1]).
- pinctrl-0: a phandle pointing to the pin settings for the device (see
pinctrl binding [1]).
- vcc-supply: a phandle for the regulator supplying 3.3V power.
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt
Example:
&i2c0 {
/* ... */
/* Cypress Gen3 touchpad */
touchpad@67 {
compatible = "cypress,cyapa";
reg = <0x24>;
interrupt-parent = <&gpio>;
interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
wakeup-source;
};
/* Cypress Gen5 and later touchpad */
touchpad@24 {
compatible = "cypress,cyapa";
reg = <0x24>;
interrupt-parent = <&gpio>;
interrupts = <2 IRQ_TYPE_EDGE_FALLING>; /* GPIO 2 */
wakeup-source;
};
/* ... */
};

3
Documentation/devicetree/bindings/input/elants_i2c.txt
View File

@ -13,6 +13,9 @@ Optional properties:
- pinctrl-names: should be "default" (see pinctrl binding [1]).
- pinctrl-0: a phandle pointing to the pin settings for the device (see
pinctrl binding [1]).
- reset-gpios: reset gpio the chip is connected to.
- vcc33-supply: a phandle for the regulator supplying 3.3V power.
- vccio-supply: a phandle for the regulator supplying IO power.
[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[1]: Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt

2
Documentation/devicetree/bindings/input/gpio-keys-polled.txt
View File

@ -20,7 +20,7 @@ Optional subnode-properties:
If not specified defaults to <1> == EV_KEY.
- debounce-interval: Debouncing interval time in milliseconds.
If not specified defaults to 5.
- gpio-key,wakeup: Boolean, button can wake-up the system.
- wakeup-source: Boolean, button can wake-up the system.
Example nodes:

2
Documentation/devicetree/bindings/input/gpio-keys.txt
View File

@ -23,7 +23,7 @@ Optional subnode-properties:
If not specified defaults to <1> == EV_KEY.
- debounce-interval: Debouncing interval time in milliseconds.
If not specified defaults to 5.
- gpio-key,wakeup: Boolean, button can wake-up the system.
- wakeup-source: Boolean, button can wake-up the system.
- linux,can-disable: Boolean, indicates that button is connected
to dedicated (not shared) interrupt which can be disabled to
suppress events from the button.

2
Documentation/devicetree/bindings/input/gpio-matrix-keypad.txt
View File

@ -19,7 +19,7 @@ Required Properties:
Optional Properties:
- linux,no-autorepeat: do no enable autorepeat feature.
- linux,wakeup: use any event on keypad as wakeup event.
- wakeup-source: use any event on keypad as wakeup event.
- debounce-delay-ms: debounce interval in milliseconds
- col-scan-delay-us: delay, measured in microseconds, that is needed
before we can scan keypad after activating column gpio

2
Documentation/devicetree/bindings/input/qcom,pm8xxx-keypad.txt
View File

@ -33,7 +33,7 @@ PROPERTIES
Value type: <bool>
Definition: don't enable autorepeat feature.
- linux,keypad-wakeup:
- wakeup-source:
Usage: optional
Value type: <bool>
Definition: use any event on keypad as wakeup event.

4
Documentation/devicetree/bindings/input/samsung-keypad.txt
View File

@ -36,9 +36,11 @@ Required Board Specific Properties:
- pinctrl-0: Should specify pin control groups used for this controller.
- pinctrl-names: Should contain only one value - "default".
Optional Properties:
- wakeup-source: use any event on keypad as wakeup event.
Optional Properties specific to linux:
- linux,keypad-no-autorepeat: do no enable autorepeat feature.
- linux,keypad-wakeup: use any event on keypad as wakeup event.
Example:

36
Documentation/devicetree/bindings/input/touchscreen/colibri-vf50-ts.txt Normal file
View File

@ -0,0 +1,36 @@
* Toradex Colibri VF50 Touchscreen driver
Required Properties:
- compatible must be toradex,vf50-touchscreen
- io-channels: adc channels being used by the Colibri VF50 module
- xp-gpios: FET gate driver for input of X+
- xm-gpios: FET gate driver for input of X-
- yp-gpios: FET gate driver for input of Y+
- ym-gpios: FET gate driver for input of Y-
- interrupt-parent: phandle for the interrupt controller
- interrupts: pen irq interrupt for touch detection
- pinctrl-names: "idle", "default", "gpios"
- pinctrl-0: pinctrl node for pen/touch detection state pinmux
- pinctrl-1: pinctrl node for X/Y and pressure measurement (ADC) state pinmux
- pinctrl-2: pinctrl node for gpios functioning as FET gate drivers
- vf50-ts-min-pressure: pressure level at which to stop measuring X/Y values
Example:
touchctrl: vf50_touchctrl {
compatible = "toradex,vf50-touchscreen";
io-channels = <&adc1 0>,<&adc0 0>,
<&adc0 1>,<&adc1 2>;
xp-gpios = <&gpio0 13 GPIO_ACTIVE_LOW>;
xm-gpios = <&gpio2 29 GPIO_ACTIVE_HIGH>;
yp-gpios = <&gpio0 12 GPIO_ACTIVE_LOW>;
ym-gpios = <&gpio0 4 GPIO_ACTIVE_HIGH>;
interrupt-parent = <&gpio0>;
interrupts = <8 IRQ_TYPE_LEVEL_LOW>;
pinctrl-names = "idle","default","gpios";
pinctrl-0 = <&pinctrl_touchctrl_idle>;
pinctrl-1 = <&pinctrl_touchctrl_default>;
pinctrl-2 = <&pinctrl_touchctrl_gpios>;
vf50-ts-min-pressure = <200>;
status = "disabled";
};

36
Documentation/devicetree/bindings/input/touchscreen/imx6ul_tsc.txt Normal file
View File

@ -0,0 +1,36 @@
* Freescale i.MX6UL Touch Controller
Required properties:
- compatible: must be "fsl,imx6ul-tsc".
- reg: this touch controller address and the ADC2 address.
- interrupts: the interrupt of this touch controller and ADC2.
- clocks: the root clock of touch controller and ADC2.
- clock-names; must be "tsc" and "adc".
- xnur-gpio: the X- gpio this controller connect to.
This xnur-gpio returns to low once the finger leave the touch screen (The
last touch event the touch controller capture).
Optional properties:
- measure-delay-time: the value of measure delay time.
Before X-axis or Y-axis measurement, the screen need some time before
even potential distribution ready.
This value depends on the touch screen.
- pre-charge-time: the touch screen need some time to precharge.
This value depends on the touch screen.
Example:
tsc: tsc@02040000 {
compatible = "fsl,imx6ul-tsc";
reg = <0x02040000 0x4000>, <0x0219c000 0x4000>;
interrupts = <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 101 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&clks IMX6UL_CLK_IPG>,
<&clks IMX6UL_CLK_ADC2>;
clock-names = "tsc", "adc";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_tsc>;
xnur-gpio = <&gpio1 3 GPIO_ACTIVE_LOW>;
measure-delay-time = <0xfff>;
pre-charge-time = <0xffff>;
status = "okay";
};

3
Documentation/devicetree/bindings/input/touchscreen/pixcir_i2c_ts.txt
View File

@ -8,6 +8,9 @@ Required properties:
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
Optional properties:
- reset-gpio: GPIO connected to the RESET line of the chip
Example:
i2c@00000000 {

8
Documentation/devicetree/bindings/input/touchscreen/zforce_ts.txt
View File

@ -4,12 +4,12 @@ Required properties:
- compatible: must be "neonode,zforce"
- reg: I2C address of the chip
- interrupts: interrupt to which the chip is connected
- gpios: gpios the chip is connected to
first one is the interrupt gpio and second one the reset gpio
- reset-gpios: reset gpio the chip is connected to
- x-size: horizontal resolution of touchscreen
- y-size: vertical resolution of touchscreen
Optional properties:
- irq-gpios : interrupt gpio the chip is connected to
- vdd-supply: Regulator controlling the controller supply
Example:
@ -23,8 +23,8 @@ Example:
interrupts = <2 0>;
vdd-supply = <&reg_zforce_vdd>;
gpios = <&gpio5 6 0>, /* INT */
<&gpio5 9 0>; /* RST */
reset-gpios = <&gpio5 9 0>; /* RST */
irq-gpios = <&gpio5 6 0>; /* IRQ, optional */
x-size = <800>;
y-size = <600>;

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

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

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

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

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

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

6
Documentation/devicetree/bindings/iommu/arm,smmu.txt
View File

@ -43,6 +43,12 @@ conditions.
** System MMU optional properties:
- dma-coherent : Present if page table walks made by the SMMU are
cache coherent with the CPU.
NOTE: this only applies to the SMMU itself, not
masters connected upstream of the SMMU.
- calxeda,smmu-secure-config-access : Enable proper handling of buggy
implementations that always use secure access to
SMMU configuration registers. In this case non-secure

6
Documentation/devicetree/bindings/iommu/ti,omap-iommu.txt
View File

@ -8,6 +8,11 @@ Required properties:
- ti,hwmods : Name of the hwmod associated with the IOMMU instance
- reg : Address space for the configuration registers
- interrupts : Interrupt specifier for the IOMMU instance
- #iommu-cells : Should be 0. OMAP IOMMUs are all "single-master" devices,
and needs no additional data in the pargs specifier. Please
also refer to the generic bindings document for more info
on this property,
Documentation/devicetree/bindings/iommu/iommu.txt
Optional properties:
- ti,#tlb-entries : Number of entries in the translation look-aside buffer.
@ -18,6 +23,7 @@ Optional properties:
Example:
/* OMAP3 ISP MMU */
mmu_isp: mmu@480bd400 {
#iommu-cells = <0>;
compatible = "ti,omap2-iommu";
reg = <0x480bd400 0x80>;
interrupts = <24>;

25
Documentation/devicetree/bindings/ipmi.txt Normal file
View File

@ -0,0 +1,25 @@
IPMI device
Required properties:
- compatible: should be one of ipmi-kcs, ipmi-smic, or ipmi-bt
- device_type: should be ipmi
- reg: Address and length of the register set for the device
Optional properties:
- interrupts: The interrupt for the device. Without this the interface
is polled.
- reg-size - The size of the register. Defaults to 1
- reg-spacing - The number of bytes between register starts. Defaults to 1
- reg-shift - The amount to shift the registers to the right to get the data
into bit zero.
Example:
smic@fff3a000 {
compatible = "ipmi-smic";
device_type = "ipmi";
reg = <0xfff3a000 0x1000>;
interrupts = <0 24 4>;
reg-size = <4>;
reg-spacing = <4>;
};

26
Documentation/devicetree/bindings/leds/leds-powernv.txt Normal file
View File

@ -0,0 +1,26 @@
Device Tree binding for LEDs on IBM Power Systems
-------------------------------------------------
Required properties:
- compatible : Should be "ibm,opal-v3-led".
- led-mode : Should be "lightpath" or "guidinglight".
Each location code of FRU/Enclosure must be expressed in the
form of a sub-node.
Required properties for the sub nodes:
- led-types : Supported LED types (attention/identify/fault) provided
in the form of string array.
Example:
leds {
compatible = "ibm,opal-v3-led";
led-mode = "lightpath";
U78C9.001.RST0027-P1-C1 {
led-types = "identify", "fault";
};
...
...
};

21
Documentation/devicetree/bindings/media/i2c/adv7604.txt
View File

@ -1,15 +1,17 @@
* Analog Devices ADV7604/11 video decoder with HDMI receiver
* Analog Devices ADV7604/11/12 video decoder with HDMI receiver
The ADV7604 and ADV7611 are multiformat video decoders with an integrated HDMI
receiver. The ADV7604 has four multiplexed HDMI inputs and one analog input,
and the ADV7611 has one HDMI input and no analog input.
The ADV7604 and ADV7611/12 are multiformat video decoders with an integrated
HDMI receiver. The ADV7604 has four multiplexed HDMI inputs and one analog
input, and the ADV7611 has one HDMI input and no analog input. The 7612 is
similar to the 7611 but has 2 HDMI inputs.
These device tree bindings support the ADV7611 only at the moment.
These device tree bindings support the ADV7611/12 only at the moment.
Required Properties:
- compatible: Must contain one of the following
- "adi,adv7611" for the ADV7611
- "adi,adv7612" for the ADV7612
- reg: I2C slave address
@ -22,10 +24,10 @@ port, in accordance with the video interface bindings defined in
Documentation/devicetree/bindings/media/video-interfaces.txt. The port nodes
are numbered as follows.
Port ADV7611
Port ADV7611 ADV7612
------------------------------------------------------------
HDMI 0
Digital output 1
HDMI 0 0, 1
Digital output 1 2
The digital output port node must contain at least one endpoint.
@ -45,6 +47,7 @@ Optional Endpoint Properties:
If none of hsync-active, vsync-active and pclk-sample is specified the
endpoint will use embedded BT.656 synchronization.
- default-input: Select which input is selected after reset.
Example:
@ -58,6 +61,8 @@ Example:
#address-cells = <1>;
#size-cells = <0>;
default-input = <0>;
port@0 {
reg = <0>;
};

48
Documentation/devicetree/bindings/media/i2c/tc358743.txt Normal file
View File

@ -0,0 +1,48 @@
* Toshiba TC358743 HDMI-RX to MIPI CSI2-TX Bridge
The Toshiba TC358743 HDMI-RX to MIPI CSI2-TX (H2C) is a bridge that converts
a HDMI stream to MIPI CSI-2 TX. It is programmable through I2C.
Required Properties:
- compatible: value should be "toshiba,tc358743"
- clocks, clock-names: should contain a phandle link to the reference clock
source, the clock input is named "refclk".
Optional Properties:
- reset-gpios: gpio phandle GPIO connected to the reset pin
- interrupts, interrupt-parent: GPIO connected to the interrupt pin
- data-lanes: should be <1 2 3 4> for four-lane operation,
or <1 2> for two-lane operation
- clock-lanes: should be <0>
- clock-noncontinuous: Presence of this boolean property decides whether the
MIPI CSI-2 clock is continuous or non-continuous.
- link-frequencies: List of allowed link frequencies in Hz. Each frequency is
expressed as a 64-bit big-endian integer. The frequency
is half of the bps per lane due to DDR transmission.
For further information on the MIPI CSI-2 endpoint node properties, see
Documentation/devicetree/bindings/media/video-interfaces.txt.
Example:
tc358743@0f {
compatible = "toshiba,tc358743";
reg = <0x0f>;
clocks = <&hdmi_osc>;
clock-names = "refclk";
reset-gpios = <&gpio6 9 GPIO_ACTIVE_LOW>;
interrupt-parent = <&gpio2>;
interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
port {
tc358743_out: endpoint {
remote-endpoint = <&mipi_csi2_in>;
data-lanes = <1 2 3 4>;
clock-lanes = <0>;
clock-noncontinuous;
link-frequencies = /bits/ 64 <297000000>;
};
};
};

24
Documentation/devicetree/bindings/media/renesas,jpu.txt Normal file
View File

@ -0,0 +1,24 @@
* Renesas JPEG Processing Unit
The JPEG processing unit (JPU) incorporates the JPEG codec with an encoding
and decoding function conforming to the JPEG baseline process, so that the JPU
can encode image data and decode JPEG data quickly.
Required properties:
- compatible: should containg one of the following:
- "renesas,jpu-r8a7790" for R-Car H2
- "renesas,jpu-r8a7791" for R-Car M2-W
- "renesas,jpu-r8a7792" for R-Car V2H
- "renesas,jpu-r8a7793" for R-Car M2-N
- reg: Base address and length of the registers block for the JPU.
- interrupts: JPU interrupt specifier.
- clocks: A phandle + clock-specifier pair for the JPU functional clock.
Example: R8A7790 (R-Car H2) JPU node
jpeg-codec@fe980000 {
compatible = "renesas,jpu-r8a7790";
reg = <0 0xfe980000 0 0x10300>;
interrupts = <0 272 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&mstp1_clks R8A7790_CLK_JPU>;
};

89
Documentation/devicetree/bindings/media/stih407-c8sectpfe.txt Normal file
View File

@ -0,0 +1,89 @@
STMicroelectronics STi c8sectpfe binding
============================================
This document describes the c8sectpfe device bindings that is used to get transport
stream data into the SoC on the TS pins, and into DDR for further processing.
It is typically used in conjunction with one or more demodulator and tuner devices
which converts from the RF to digital domain. Demodulators and tuners are usually
located on an external DVB frontend card connected to SoC TS input pins.
Currently 7 TS input (tsin) channels are supported on the stih407 family SoC.
Required properties (controller (parent) node):
- compatible : Should be "stih407-c8sectpfe"
- reg : Address and length of register sets for each device in
"reg-names"
- reg-names : The names of the register addresses corresponding to the
registers filled in "reg":
- c8sectpfe: c8sectpfe registers
- c8sectpfe-ram: c8sectpfe internal sram
- clocks : phandle list of c8sectpfe clocks
- clock-names : should be "c8sectpfe"
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
- pinctrl-names : a pinctrl state named tsin%d-serial or tsin%d-parallel (where %d is tsin-num)
must be defined for each tsin child node.
- pinctrl-0 : phandle referencing pin configuration for this tsin configuration
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
Required properties (tsin (child) node):
- tsin-num : tsin id of the InputBlock (must be between 0 to 6)
- i2c-bus : phandle to the I2C bus DT node which the demodulators & tuners on this tsin channel are connected.
- rst-gpio : reset gpio for this tsin channel.
Optional properties (tsin (child) node):
- invert-ts-clk : Bool property to control sense of ts input clock (data stored on falling edge of clk).
- serial-not-parallel : Bool property to configure input bus width (serial on ts_data<7>).
- async-not-sync : Bool property to control if data is received in asynchronous mode
(all bits/bytes with ts_valid or ts_packet asserted are valid).
- dvb-card : Describes the NIM card connected to this tsin channel.
Example:
/* stih410 SoC b2120 + b2004a + stv0367-pll(NIMB) + stv0367-tda18212 (NIMA) DT example) */
c8sectpfe@08a20000 {
compatible = "st,stih407-c8sectpfe";
status = "okay";
reg = <0x08a20000 0x10000>, <0x08a00000 0x4000>;
reg-names = "stfe", "stfe-ram";
interrupts = <0 34 0>, <0 35 0>;
interrupt-names = "stfe-error-irq", "stfe-idle-irq";
pinctrl-names = "tsin0-serial", "tsin0-parallel", "tsin3-serial",
"tsin4-serial", "tsin5-serial";
pinctrl-0 = <&pinctrl_tsin0_serial>;
pinctrl-1 = <&pinctrl_tsin0_parallel>;
pinctrl-2 = <&pinctrl_tsin3_serial>;
pinctrl-3 = <&pinctrl_tsin4_serial_alt3>;
pinctrl-4 = <&pinctrl_tsin5_serial_alt1>;
clocks = <&clk_s_c0_flexgen CLK_PROC_STFE>;
clock-names = "stfe";
/* tsin0 is TSA on NIMA */
tsin0: port@0 {
tsin-num = <0>;
serial-not-parallel;
i2c-bus = <&ssc2>;
rst-gpio = <&pio15 4 0>;
dvb-card = <STV0367_TDA18212_NIMA_1>;
};
tsin3: port@3 {
tsin-num = <3>;
serial-not-parallel;
i2c-bus = <&ssc3>;
rst-gpio = <&pio15 7 0>;
dvb-card = <STV0367_TDA18212_NIMB_1>;
};
};

3
Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt
View File

@ -18,6 +18,8 @@ Properties:
interrupt (NAND_EVTER_STAT). If there is only one,
that interrupt reports both types of event.
- little-endian : If this property is absent, the big-endian mode will
be in use as default for registers.
- ranges : Each range corresponds to a single chipselect, and covers
the entire access window as configured.
@ -34,6 +36,7 @@ Example:
#size-cells = <1>;
reg = <0x0 0xffe1e000 0 0x2000>;
interrupts = <16 2 19 2>;
little-endian;
/* NOR, NAND Flashes and CPLD on board */
ranges = <0x0 0x0 0x0 0xee000000 0x02000000

4
Documentation/devicetree/bindings/mfd/atmel-hlcdc.txt
View File

@ -2,7 +2,11 @@ Device-Tree bindings for Atmel's HLCDC (High LCD Controller) MFD driver
Required properties:
- compatible: value should be one of the following:
"atmel,at91sam9n12-hlcdc"
"atmel,at91sam9x5-hlcdc"
"atmel,sama5d2-hlcdc"
"atmel,sama5d3-hlcdc"
"atmel,sama5d4-hlcdc"
- reg: base address and size of the HLCDC device registers.
- clock-names: the name of the 3 clocks requested by the HLCDC device.
Should contain "periph_clk", "sys_clk" and "slow_clk".

4
Documentation/devicetree/bindings/mfd/axp20x.txt
View File

@ -1,12 +1,14 @@
AXP family PMIC device tree bindings
The axp20x family current members :
axp152 (X-Powers)
axp202 (X-Powers)
axp209 (X-Powers)
axp221 (X-Powers)
Required properties:
- compatible: "x-powers,axp202", "x-powers,axp209", "x-powers,axp221"
- compatible: "x-powers,axp152", "x-powers,axp202", "x-powers,axp209",
"x-powers,axp221"
- reg: The I2C slave address for the AXP chip
- interrupt-parent: The parent interrupt controller
- interrupts: SoC NMI / GPIO interrupt connected to the PMIC's IRQ pin

88
Documentation/devicetree/bindings/mfd/da9062.txt Normal file
View File

@ -0,0 +1,88 @@
* Dialog DA9062 Power Management Integrated Circuit (PMIC)
DA9062 consists of a large and varied group of sub-devices:
Device Supply Names Description
------ ------------ -----------
da9062-regulator : : LDOs & BUCKs
da9062-rtc : : Real-Time Clock
da9062-watchdog : : Watchdog Timer
======
Required properties:
- compatible : Should be "dlg,da9062".
- reg : Specifies the I2C slave address (this defaults to 0x58 but it can be
modified to match the chip's OTP settings).
- interrupt-parent : Specifies the reference to the interrupt controller for
the DA9062.
- interrupts : IRQ line information.
- interrupt-controller
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt for
further information on IRQ bindings.
Sub-nodes:
- regulators : This node defines the settings for the LDOs and BUCKs. The
DA9062 regulators are bound using their names listed below:
buck1 : BUCK_1
buck2 : BUCK_2
buck3 : BUCK_3
buck4 : BUCK_4
ldo1 : LDO_1
ldo2 : LDO_2
ldo3 : LDO_3
ldo4 : LDO_4
The component follows the standard regulator framework and the bindings
details of individual regulator device can be found in:
Documentation/devicetree/bindings/regulator/regulator.txt
- rtc : This node defines settings required for the Real-Time Clock associated
with the DA9062. There are currently no entries in this binding, however
compatible = "dlg,da9062-rtc" should be added if a node is created.
- watchdog: This node defines the settings for the watchdog driver associated
with the DA9062 PMIC. The compatible = "dlg,da9062-watchdog" should be added
if a node is created.
Example:
pmic0: da9062@58 {
compatible = "dlg,da9062";
reg = <0x58>;
interrupt-parent = <&gpio6>;
interrupts = <11 IRQ_TYPE_LEVEL_LOW>;
interrupt-controller;
rtc {
compatible = "dlg,da9062-rtc";
};
watchdog {
compatible = "dlg,da9062-watchdog";
};
regulators {
DA9062_BUCK1: buck1 {
regulator-name = "BUCK1";
regulator-min-microvolt = <300000>;
regulator-max-microvolt = <1570000>;
regulator-min-microamp = <500000>;
regulator-max-microamp = <2000000>;
regulator-boot-on;
};
DA9062_LDO1: ldo1 {
regulator-name = "LDO_1";
regulator-min-microvolt = <900000>;
regulator-max-microvolt = <3600000>;
regulator-boot-on;
};
};
};

65
Documentation/devicetree/bindings/mfd/max77686.txt
View File

@ -7,8 +7,9 @@ different i2c slave address,presently for which we are statically creating i2c
client while probing.This document describes the binding for mfd device and
PMIC submodule.
Binding for the built-in 32k clock generator block is defined separately
in bindings/clk/maxim,max77686.txt file.
Bindings for the built-in 32k clock generator block and
regulators are defined in ../clk/maxim,max77686.txt and
../regulator/max77686.txt respectively.
Required properties:
- compatible : Must be "maxim,max77686";
@ -16,67 +17,11 @@ Required properties:
- interrupts : This i2c device has an IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
Optional node:
- voltage-regulators : The regulators of max77686 have to be instantiated
under subnode named "voltage-regulators" using the following format.
regulator_name {
regulator-compatible = LDOn/BUCKn
standard regulator constraints....
};
refer Documentation/devicetree/bindings/regulator/regulator.txt
The regulator-compatible property of regulator should initialized with string
to get matched with their hardware counterparts as follow:
-LDOn : for LDOs, where n can lie in range 1 to 26.
example: LDO1, LDO2, LDO26.
-BUCKn : for BUCKs, where n can lie in range 1 to 9.
example: BUCK1, BUCK5, BUCK9.
Regulators which can be turned off during system suspend:
-LDOn : 2, 6-8, 10-12, 14-16,
-BUCKn : 1-4.
Use standard regulator bindings for it ('regulator-off-in-suspend').
LDO20, LDO21, LDO22, BUCK8 and BUCK9 can be configured to GPIO enable
control. To turn this feature on this property must be added to the regulator
sub-node:
- maxim,ena-gpios : one GPIO specifier enable control (the gpio
flags are actually ignored and always
ACTIVE_HIGH is used)
Example:
max77686@09 {
max77686: pmic@09 {
compatible = "maxim,max77686";
interrupt-parent = <&wakeup_eint>;
interrupts = <26 0>;
reg = <0x09>;
voltage-regulators {
ldo11_reg {
regulator-compatible = "LDO11";
regulator-name = "vdd_ldo11";
regulator-min-microvolt = <1900000>;
regulator-max-microvolt = <1900000>;
regulator-always-on;
};
buck1_reg {
regulator-compatible = "BUCK1";
regulator-name = "vdd_mif";
regulator-min-microvolt = <950000>;
regulator-max-microvolt = <1300000>;
regulator-always-on;
regulator-boot-on;
};
buck9_reg {
regulator-compatible = "BUCK9";
regulator-name = "CAM_ISP_CORE_1.2V";
regulator-min-microvolt = <1000000>;
regulator-max-microvolt = <1200000>;
maxim,ena-gpios = <&gpm0 3 GPIO_ACTIVE_HIGH>;
};
}
};

26
Documentation/devicetree/bindings/mfd/max77802.txt Normal file
View File

@ -0,0 +1,26 @@
Maxim MAX77802 multi-function device
The Maxim MAX77802 is a Power Management IC (PMIC) that contains 10 high
efficiency Buck regulators, 32 Low-DropOut (LDO) regulators used to power
up application processors and peripherals, a 2-channel 32kHz clock outputs,
a Real-Time-Clock (RTC) and a I2C interface to program the individual
regulators, clocks outputs and the RTC.
Bindings for the built-in 32k clock generator block and
regulators are defined in ../clk/maxim,max77802.txt and
../regulator/max77802.txt respectively.
Required properties:
- compatible : Must be "maxim,max77802"
- reg : Specifies the I2C slave address of PMIC block.
- interrupts : I2C device IRQ line connected to the main SoC.
- interrupt-parent : The parent interrupt controller.
Example:
max77802: pmic@09 {
compatible = "maxim,max77802";
interrupt-parent = <&intc>;
interrupts = <26 IRQ_TYPE_NONE>;
reg = <0x09>;
};

4
Documentation/devicetree/bindings/mfd/tc3589x.txt
View File

@ -55,7 +55,7 @@ Optional nodes:
- linux,keymap: the definition can be found in
bindings/input/matrix-keymap.txt
- linux,no-autorepeat: do no enable autorepeat feature.
- linux,wakeup: use any event on keypad as wakeup event.
- wakeup-source: use any event on keypad as wakeup event.
Example:
@ -84,7 +84,6 @@ tc35893@44 {
keypad,num-columns = <8>;
keypad,num-rows = <8>;
linux,no-autorepeat;
linux,wakeup;
linux,keymap = <0x0301006b
0x04010066
0x06040072
@ -103,5 +102,6 @@ tc35893@44 {
0x01030039
0x07060069
0x050500d9>;
wakeup-source;
};
};

2
Documentation/devicetree/bindings/mmc/arasan,sdhci.txt
View File

@ -9,7 +9,7 @@ Device Tree Bindings for the Arasan SDHCI Controller
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
'arasan,sdhci-4.9a'
'arasan,sdhci-4.9a' or 'arasan,sdhci-5.1'
- reg: From mmc bindings: Register location and length.
- clocks: From clock bindings: Handles to clock inputs.
- clock-names: From clock bindings: Tuple including "clk_xin" and "clk_ahb"

6
Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.txt
View File

@ -15,6 +15,7 @@ Required properties:
"fsl,imx6q-usdhc"
"fsl,imx6sl-usdhc"
"fsl,imx6sx-usdhc"
"fsl,imx7d-usdhc"
Optional properties:
- fsl,wp-controller : Indicate to use controller internal write protection
@ -27,6 +28,11 @@ Optional properties:
transparent level shifters on the outputs of the controller. Two cells are
required, first cell specifies minimum slot voltage (mV), second cell
specifies maximum slot voltage (mV). Several ranges could be specified.
- fsl,tuning-step: Specify the increasing delay cell steps in tuning procedure.
The uSDHC use one delay cell as default increasing step to do tuning process.
This property allows user to change the tuning step to more than one delay
cells which is useful for some special boards or cards when the default
tuning step can't find the proper delay window within limited tuning retries.
Examples:

21
Documentation/devicetree/bindings/mmc/sdhci-atmel.txt Normal file
View File

@ -0,0 +1,21 @@
* Atmel SDHCI controller
This file documents the differences between the core properties in
Documentation/devicetree/bindings/mmc/mmc.txt and the properties used by the
sdhci-of-at91 driver.
Required properties:
- compatible: Must be "atmel,sama5d2-sdhci".
- clocks: Phandlers to the clocks.
- clock-names: Must be "hclock", "multclk", "baseclk";
Example:
sdmmc0: sdio-host@a0000000 {
compatible = "atmel,sama5d2-sdhci";
reg = <0xa0000000 0x300>;
interrupts = <31 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&sdmmc0_hclk>, <&sdmmc0_gclk>, <&main>;
clock-names = "hclock", "multclk", "baseclk";
};

2
Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt
View File

@ -102,7 +102,7 @@ not every application needs SDIO irq, e.g. MMC cards.
pinctrl-1 = <&mmc1_idle>;
pinctrl-2 = <&mmc1_sleep>;
...
interrupts-extended = <&intc 64 &gpio2 28 0>;
interrupts-extended = <&intc 64 &gpio2 28 GPIO_ACTIVE_LOW>;
};
mmc1_idle : pinmux_cirq_pin {

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