mirror of
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-08-05 16:54:27 +00:00
Linux 4.3-rc1
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAABAgAGBQJV9LbmAAoJEHm+PkMAQRiGb40IAJWcETZb6hoCUIrGZX+4Znqy UXYY9BwybF+3yPsTKWRUWQGifNhUiW7ejNgMO3QYG+E1RgJ6uj8Mym9I11+x3a9D beIem8Ftf1Zwt71zg6DpUCNhlRIfa3TTnbQMIYmoIihVwYWVve1/rMPD5kgafF6P Xnp7QSUh7uCK/G06sksK9aB2GkRgvoMKfAgTHmj094f24udl87NyUo8O8mP5QWX2 b0S5ZwlDRL64sio59QyxZK87f0TGnquDBLe6Gcl3wJQx/g3RzRpSxEkumylwx+S4 u9xeHlorOkg8a+k62TgbC6GP0Y6Ptk+yMF6UFCPsifwQTRvJubrA2ofdfPuggCk= =aqcb -----END PGP SIGNATURE----- Merge tag 'v4.3-rc1' into perf/core, to refresh the tree Signed-off-by: Ingo Molnar <mingo@kernel.org>
This commit is contained in:
Ingo Molnar
commit
d2bb1d42b9
7555 changed files with 450074 additions and 198162 deletions
6
.gitignore
vendored
6
.gitignore
vendored
|
|
@ -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
13
CREDITS
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
23
Documentation/ABI/testing/sysfs-hypervisor-pmu
Normal 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
|
||||
|
|
@ -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/>
|
||||
|
||||
|
|
|
|||
|
|
@ -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);
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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">
|
||||
|
|
|
|||
|
|
@ -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 $< >$@
|
||||
|
|
|
|||
|
|
@ -163,9 +163,8 @@ are called:</para>
|
|||
<para>where N enumerates the DVB PCI cards in a system starting
|
||||
from 0, and M enumerates the devices of each type within each
|
||||
adapter, starting from 0, too. We will omit the “
|
||||
<constant>/dev/dvb/adapterN/</constant>” 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>” 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>
|
||||
|
|
|
|||
|
|
@ -3414,7 +3414,7 @@ giving priority to the center of the metered area.</entry>
|
|||
<row>
|
||||
<entry><constant>V4L2_EXPOSURE_METERING_MATRIX</constant> </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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -90,6 +90,11 @@ the Atmel website: http://www.atmel.com.
|
|||
+ Datasheet
|
||||
http://www.atmel.com/Images/Atmel-11238-32-bit-Cortex-A5-Microcontroller-SAMA5D4_Datasheet.pdf
|
||||
|
||||
- sama5d2 family
|
||||
- sama5d27
|
||||
+ Datasheet
|
||||
Coming soon
|
||||
|
||||
|
||||
Linux kernel information
|
||||
------------------------
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -1109,7 +1109,7 @@ it will loop and handle as many sectors (on a bio-segment granularity)
|
|||
as specified.
|
||||
|
||||
Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the
|
||||
right thing to use is bio_endio(bio, uptodate) instead.
|
||||
right thing to use is bio_endio(bio) instead.
|
||||
|
||||
If the driver is dropping the io_request_lock from its request_fn strategy,
|
||||
then it just needs to replace that with q->queue_lock instead.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ particular, presenting the illusion of partially completed biovecs so that
|
|||
normal code doesn't have to deal with bi_bvec_done.
|
||||
|
||||
* Driver code should no longer refer to biovecs directly; we now have
|
||||
bio_iovec() and bio_iovec_iter() macros that return literal struct biovecs,
|
||||
bio_iovec() and bio_iter_iovec() macros that return literal struct biovecs,
|
||||
constructed from the raw biovecs but taking into account bi_bvec_done and
|
||||
bi_size.
|
||||
|
||||
|
|
@ -109,3 +109,11 @@ Other implications:
|
|||
over all the biovecs in the new bio - which is silly as it's not needed.
|
||||
|
||||
So, don't use bi_vcnt anymore.
|
||||
|
||||
* The current interface allows the block layer to split bios as needed, so we
|
||||
could eliminate a lot of complexity particularly in stacked drivers. Code
|
||||
that creates bios can then create whatever size bios are convenient, and
|
||||
more importantly stacked drivers don't have to deal with both their own bio
|
||||
size limitations and the limitations of the underlying devices. Thus
|
||||
there's no need to define ->merge_bvec_fn() callbacks for individual block
|
||||
drivers.
|
||||
|
|
|
|||
|
|
@ -20,7 +20,7 @@ This shows the size of internal allocation of the device in bytes, if
|
|||
reported by the device. A value of '0' means device does not support
|
||||
the discard functionality.
|
||||
|
||||
discard_max_bytes (RO)
|
||||
discard_max_hw_bytes (RO)
|
||||
----------------------
|
||||
Devices that support discard functionality may have internal limits on
|
||||
the number of bytes that can be trimmed or unmapped in a single operation.
|
||||
|
|
@ -29,6 +29,14 @@ number of bytes that can be discarded in a single operation. Discard
|
|||
requests issued to the device must not exceed this limit. A discard_max_bytes
|
||||
value of 0 means that the device does not support discard functionality.
|
||||
|
||||
discard_max_bytes (RW)
|
||||
----------------------
|
||||
While discard_max_hw_bytes is the hardware limit for the device, this
|
||||
setting is the software limit. Some devices exhibit large latencies when
|
||||
large discards are issued, setting this value lower will make Linux issue
|
||||
smaller discards and potentially help reduce latencies induced by large
|
||||
discard operations.
|
||||
|
||||
discard_zeroes_data (RO)
|
||||
------------------------
|
||||
When read, this file will show if the discarded block are zeroed by the
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
85
Documentation/cgroups/pids.txt
Normal 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
|
||||
#
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>]
|
||||
|
||||
|
|
|
|||
17
Documentation/devicetree/bindings/arc/archs-pct.txt
Normal file
17
Documentation/devicetree/bindings/arc/archs-pct.txt
Normal file
|
|
@ -0,0 +1,17 @@
|
|||
* ARC HS Performance Counters
|
||||
|
||||
The ARC HS can be configured with a pipeline performance monitor for counting
|
||||
CPU and cache events like cache misses and hits. Like conventional PCT there
|
||||
are 100+ hardware conditions dynamically mapped to upto 32 counters.
|
||||
It also supports overflow interrupts.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should contain
|
||||
"snps,archs-pct"
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
compatible = "snps,archs-pct";
|
||||
};
|
||||
|
|
@ -27,6 +27,8 @@ compatible: must be one of:
|
|||
o "atmel,at91sam9xe"
|
||||
* "atmel,sama5" for SoCs using a Cortex-A5, shall be extended with the specific
|
||||
SoC family:
|
||||
o "atmel,sama5d2" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d27"
|
||||
o "atmel,sama5d3" shall be extended with the specific SoC compatible:
|
||||
- "atmel,sama5d31"
|
||||
- "atmel,sama5d33"
|
||||
|
|
@ -50,6 +52,7 @@ System Timer (ST) required properties:
|
|||
- reg: Should contain registers location and length
|
||||
- interrupts: Should contain interrupt for the ST which is the IRQ line
|
||||
shared across all System Controller members.
|
||||
- clocks: phandle to input clock.
|
||||
Its subnodes can be:
|
||||
- watchdog: compatible should be "atmel,at91rm9200-wdt"
|
||||
|
||||
|
|
@ -61,7 +64,7 @@ TC/TCLIB Timer required properties:
|
|||
Note that you can specify several interrupt cells if the TC
|
||||
block has one interrupt per channel.
|
||||
- clock-names: tuple listing input clock names.
|
||||
Required elements: "t0_clk"
|
||||
Required elements: "t0_clk", "slow_clk"
|
||||
Optional elements: "t1_clk", "t2_clk"
|
||||
- clocks: phandles to input clocks.
|
||||
|
||||
|
|
@ -89,12 +92,14 @@ RSTC Reset Controller required properties:
|
|||
- compatible: Should be "atmel,<chip>-rstc".
|
||||
<chip> can be "at91sam9260" or "at91sam9g45" or "sama5d3"
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
RAMC SDRAM/DDR Controller required properties:
|
||||
|
|
@ -117,6 +122,7 @@ required properties:
|
|||
- compatible: Should be "atmel,<chip>-shdwc".
|
||||
<chip> can be "at91sam9260", "at91sam9rl" or "at91sam9x5".
|
||||
- reg: Should contain registers location and length
|
||||
- clocks: phandle to input clock.
|
||||
|
||||
optional properties:
|
||||
- atmel,wakeup-mode: String, operation mode of the wakeup mode.
|
||||
|
|
@ -135,9 +141,10 @@ optional at91sam9x5 properties:
|
|||
|
||||
Example:
|
||||
|
||||
rstc@fffffd00 {
|
||||
compatible = "atmel,at91sam9260-rstc";
|
||||
reg = <0xfffffd00 0x10>;
|
||||
shdwc@fffffd10 {
|
||||
compatible = "atmel,at91sam9260-shdwc";
|
||||
reg = <0xfffffd10 0x10>;
|
||||
clocks = <&clk32k>;
|
||||
};
|
||||
|
||||
Special Function Registers (SFR)
|
||||
|
|
|
|||
9
Documentation/devicetree/bindings/arm/bcm/ns2.txt
Normal file
9
Documentation/devicetree/bindings/arm/bcm/ns2.txt
Normal 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";
|
||||
|
|
@ -0,0 +1,14 @@
|
|||
Raspberry Pi VideoCore firmware driver
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "raspberrypi,bcm2835-firmware"
|
||||
- mboxes: Phandle to the firmware device's Mailbox.
|
||||
(See: ../mailbox/mailbox.txt for more information)
|
||||
|
||||
Example:
|
||||
|
||||
firmware {
|
||||
compatible = "raspberrypi,bcm2835-firmware";
|
||||
mboxes = <&mailbox>;
|
||||
};
|
||||
|
|
@ -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),
|
||||
|
|
|
|||
|
|
@ -20,6 +20,8 @@ And in addition, the compatible shall be extended with the specific
|
|||
board. Currently known boards are:
|
||||
|
||||
"buffalo,lschlv2"
|
||||
"buffalo,lswvl"
|
||||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"dlink,dns-320"
|
||||
|
|
|
|||
|
|
@ -1,12 +1,15 @@
|
|||
MediaTek mt65xx & mt81xx Platforms Device Tree Bindings
|
||||
MediaTek mt65xx, mt67xx & mt81xx Platforms Device Tree Bindings
|
||||
|
||||
Boards with a MediaTek mt65xx/mt81xx SoC shall have the following property:
|
||||
Boards with a MediaTek mt65xx/mt67xx/mt81xx SoC shall have the
|
||||
following property:
|
||||
|
||||
Required root node property:
|
||||
|
||||
compatible: Must contain one of
|
||||
"mediatek,mt6580"
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
"mediatek,mt8173"
|
||||
|
|
@ -14,12 +17,18 @@ compatible: Must contain one of
|
|||
|
||||
Supported boards:
|
||||
|
||||
- Evaluation board for MT6580:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6580-evbp1", "mediatek,mt6580";
|
||||
- bq Aquaris5 smart phone:
|
||||
Required root node properties:
|
||||
- compatible = "mundoreader,bq-aquaris5", "mediatek,mt6589";
|
||||
- Evaluation board for MT6592:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6592-evb", "mediatek,mt6592";
|
||||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
Mediatek 65xx/81xx sysirq
|
||||
+Mediatek 65xx/67xx/81xx sysirq
|
||||
|
||||
Mediatek SOCs sysirq support controllable irq inverter for each GIC SPI
|
||||
interrupt.
|
||||
|
|
@ -8,9 +8,11 @@ Required properties:
|
|||
"mediatek,mt8173-sysirq"
|
||||
"mediatek,mt8135-sysirq"
|
||||
"mediatek,mt8127-sysirq"
|
||||
"mediatek,mt6795-sysirq"
|
||||
"mediatek,mt6592-sysirq"
|
||||
"mediatek,mt6589-sysirq"
|
||||
"mediatek,mt6582-sysirq"
|
||||
"mediatek,mt6580-sysirq"
|
||||
"mediatek,mt6577-sysirq"
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Use the same format as specified by GIC in
|
||||
|
|
|
|||
|
|
@ -135,6 +135,9 @@ Boards:
|
|||
- AM335X OrionLXm : Substation Automation Platform
|
||||
compatible = "novatech,am335x-lxm", "ti,am33xx"
|
||||
|
||||
- AM335X phyBOARD-WEGA: Single Board Computer dev kit
|
||||
compatible = "phytec,am335x-wega", "phytec,am335x-phycore-som", "ti,am33xx"
|
||||
|
||||
- OMAP5 EVM : Evaluation Module
|
||||
compatible = "ti,omap5-evm", "ti,omap5"
|
||||
|
||||
|
|
|
|||
|
|
@ -26,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.
|
||||
|
||||
|
|
|
|||
|
|
@ -26,3 +26,38 @@ Rockchip platforms device tree bindings
|
|||
- ChipSPARK PopMetal-RK3288 board:
|
||||
Required root node properties:
|
||||
- compatible = "chipspark,popmetal-rk3288", "rockchip,rk3288";
|
||||
|
||||
- Netxeon R89 board:
|
||||
Required root node properties:
|
||||
- compatible = "netxeon,r89", "rockchip,rk3288";
|
||||
|
||||
- Google Jerry (Hisense Chromebook C11 and more):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-jerry-rev7", "google,veyron-jerry-rev6",
|
||||
"google,veyron-jerry-rev5", "google,veyron-jerry-rev4",
|
||||
"google,veyron-jerry-rev3", "google,veyron-jerry",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Minnie (Asus Chromebook Flip C100P):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-minnie-rev4", "google,veyron-minnie-rev3",
|
||||
"google,veyron-minnie-rev2", "google,veyron-minnie-rev1",
|
||||
"google,veyron-minnie-rev0", "google,veyron-minnie",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Pinky (dev-board):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-pinky-rev2", "google,veyron-pinky",
|
||||
"google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Google Speedy (Asus C201 Chromebook):
|
||||
Required root node properties:
|
||||
- compatible = "google,veyron-speedy-rev9", "google,veyron-speedy-rev8",
|
||||
"google,veyron-speedy-rev7", "google,veyron-speedy-rev6",
|
||||
"google,veyron-speedy-rev5", "google,veyron-speedy-rev4",
|
||||
"google,veyron-speedy-rev3", "google,veyron-speedy-rev2",
|
||||
"google,veyron-speedy", "google,veyron", "rockchip,rk3288";
|
||||
|
||||
- Rockchip R88 board:
|
||||
Required root node properties:
|
||||
- compatible = "rockchip,r88", "rockchip,rk3368";
|
||||
|
|
|
|||
13
Documentation/devicetree/bindings/clock/imx6ul-clock.txt
Normal file
13
Documentation/devicetree/bindings/clock/imx6ul-clock.txt
Normal file
|
|
@ -0,0 +1,13 @@
|
|||
* Clock bindings for Freescale i.MX6 UltraLite
|
||||
|
||||
Required properties:
|
||||
- compatible: Should be "fsl,imx6ul-ccm"
|
||||
- reg: Address and length of the register set
|
||||
- #clock-cells: Should be <1>
|
||||
- clocks: list of clock specifiers, must contain an entry for each required
|
||||
entry in clock-names
|
||||
- clock-names: should include entries "ckil", "osc", "ipp_di0" and "ipp_di1"
|
||||
|
||||
The clock consumer should specify the desired clock by having the clock
|
||||
ID in its "clocks" phandle cell. See include/dt-bindings/clock/imx6ul-clock.h
|
||||
for the full list of i.MX6 UltraLite clock IDs.
|
||||
83
Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
Normal file
83
Documentation/devicetree/bindings/clock/mt8173-cpu-dvfs.txt
Normal 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>;
|
||||
};
|
||||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7778 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7778. It includes two PLLs and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -10,10 +12,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are
|
||||
"plla", "pllb", "b", "out", "p", "s", and "s1".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7778-cpg-clocks";
|
||||
|
|
@ -22,4 +32,17 @@ Example
|
|||
clocks = <&extal_clk>;
|
||||
clock-output-names = "plla", "pllb", "b",
|
||||
"out", "p", "s", "s1";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sdhi0: sd@ffe4c000 {
|
||||
compatible = "renesas,sdhi-r8a7778";
|
||||
reg = <0xffe4c000 0x100>;
|
||||
interrupts = <0 87 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp3_clks R8A7778_CLK_SDHI0>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -1,7 +1,9 @@
|
|||
* Renesas R8A7779 Clock Pulse Generator (CPG)
|
||||
|
||||
The CPG generates core clocks for the R8A7779. It includes one PLL and
|
||||
several fixed ratio dividers
|
||||
several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -12,16 +14,36 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "plla",
|
||||
"z", "zs", "s", "s1", "p", "b", "out".
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@ffc80000 {
|
||||
compatible = "renesas,r8a7779-cpg-clocks";
|
||||
reg = <0 0xffc80000 0 0x30>;
|
||||
reg = <0xffc80000 0x30>;
|
||||
clocks = <&extal_clk>;
|
||||
#clock-cells = <1>;
|
||||
clock-output-names = "plla", "z", "zs", "s", "s1", "p",
|
||||
"b", "out";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
sata: sata@fc600000 {
|
||||
compatible = "renesas,sata-r8a7779", "renesas,rcar-sata";
|
||||
reg = <0xfc600000 0x2000>;
|
||||
interrupts = <0 100 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7779_CLK_SATA>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the R-Car Gen2 SoCs. It includes three PLLs
|
||||
and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -20,10 +22,18 @@ Required Properties:
|
|||
- clock-output-names: The names of the clocks. Supported clocks are "main",
|
||||
"pll0", "pll1", "pll3", "lb", "qspi", "sdh", "sd0", "sd1", "z", "rcan", and
|
||||
"adsp"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@e6150000 {
|
||||
compatible = "renesas,r8a7790-cpg-clocks",
|
||||
|
|
@ -34,4 +44,16 @@ Example
|
|||
clock-output-names = "main", "pll0, "pll1", "pll3",
|
||||
"lb", "qspi", "sdh", "sd0", "sd1", "z",
|
||||
"rcan", "adsp";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
thermal@e61f0000 {
|
||||
compatible = "renesas,thermal-r8a7790", "renesas,rcar-thermal";
|
||||
reg = <0 0xe61f0000 0 0x14>, <0 0xe61f0100 0 0x38>;
|
||||
interrupts = <0 69 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp5_clks R8A7790_CLK_THERMAL>;
|
||||
power-domains = <&cpg_clocks>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -2,6 +2,8 @@
|
|||
|
||||
The CPG generates core clocks for the RZ SoCs. It includes the PLL, variable
|
||||
CPU and GPU clocks, and several fixed ratio dividers.
|
||||
The CPG also provides a Clock Domain for SoC devices, in combination with the
|
||||
CPG Module Stop (MSTP) Clocks.
|
||||
|
||||
Required Properties:
|
||||
|
||||
|
|
@ -14,10 +16,18 @@ Required Properties:
|
|||
- #clock-cells: Must be 1
|
||||
- clock-output-names: The names of the clocks. Supported clocks are "pll",
|
||||
"i", and "g"
|
||||
- #power-domain-cells: Must be 0
|
||||
|
||||
SoC devices that are part of the CPG/MSTP Clock Domain and can be power-managed
|
||||
through an MSTP clock should refer to the CPG device node in their
|
||||
"power-domains" property, as documented by the generic PM domain bindings in
|
||||
Documentation/devicetree/bindings/power/power_domain.txt.
|
||||
|
||||
|
||||
Example
|
||||
-------
|
||||
Examples
|
||||
--------
|
||||
|
||||
- CPG device node:
|
||||
|
||||
cpg_clocks: cpg_clocks@fcfe0000 {
|
||||
#clock-cells = <1>;
|
||||
|
|
@ -26,4 +36,19 @@ Example
|
|||
reg = <0xfcfe0000 0x18>;
|
||||
clocks = <&extal_clk>, <&usb_x1_clk>;
|
||||
clock-output-names = "pll", "i", "g";
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
||||
|
||||
- CPG/MSTP Clock Domain member device node:
|
||||
|
||||
mtu2: timer@fcff0000 {
|
||||
compatible = "renesas,mtu2-r7s72100", "renesas,mtu2";
|
||||
reg = <0xfcff0000 0x400>;
|
||||
interrupts = <0 107 IRQ_TYPE_LEVEL_HIGH>;
|
||||
interrupt-names = "tgi0a";
|
||||
clocks = <&mstp3_clks R7S72100_CLK_MTU2>;
|
||||
clock-names = "fck";
|
||||
power-domains = <&cpg_clocks>;
|
||||
status = "disabled";
|
||||
};
|
||||
|
|
|
|||
|
|
@ -21,8 +21,8 @@ Required properties:
|
|||
"st,stih416-plls-c32-ddr", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-a9", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_0", "st,clkgen-plls-c32"
|
||||
"st,stih407-plls-c32-c0_1", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_0", "st,clkgen-plls-c32"
|
||||
"sst,plls-c32-cx_1", "st,clkgen-plls-c32"
|
||||
|
||||
"st,stih415-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
"st,stih416-gpu-pll-c32", "st,clkgengpu-pll-c32"
|
||||
|
|
|
|||
|
|
@ -0,0 +1,44 @@
|
|||
Tegra124 CPU frequency scaling driver bindings
|
||||
----------------------------------------------
|
||||
|
||||
Both required and optional properties listed below must be defined
|
||||
under node /cpus/cpu@0.
|
||||
|
||||
Required properties:
|
||||
- clocks: Must contain an entry for each entry in clock-names.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- clock-names: Must include the following entries:
|
||||
- cpu_g: Clock mux for the fast CPU cluster.
|
||||
- cpu_lp: Clock mux for the low-power CPU cluster.
|
||||
- pll_x: Fast PLL clocksource.
|
||||
- pll_p: Auxiliary PLL used during fast PLL rate changes.
|
||||
- dfll: Fast DFLL clocksource that also automatically scales CPU voltage.
|
||||
- vdd-cpu-supply: Regulator for CPU voltage
|
||||
|
||||
Optional properties:
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
in unit of nanoseconds.
|
||||
|
||||
Example:
|
||||
--------
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a15";
|
||||
reg = <0>;
|
||||
|
||||
clocks = <&tegra_car TEGRA124_CLK_CCLK_G>,
|
||||
<&tegra_car TEGRA124_CLK_CCLK_LP>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_X>,
|
||||
<&tegra_car TEGRA124_CLK_PLL_P>,
|
||||
<&dfll>;
|
||||
clock-names = "cpu_g", "cpu_lp", "pll_x", "pll_p", "dfll";
|
||||
clock-latency = <300000>;
|
||||
vdd-cpu-supply: <&vdd_cpu>;
|
||||
};
|
||||
|
||||
<...>
|
||||
};
|
||||
|
|
@ -305,12 +305,13 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
Node defines address range and the associated
|
||||
interrupt for the SNVS function. This function
|
||||
monitors security state information & reports
|
||||
security violations.
|
||||
security violations. This also included rtc,
|
||||
system power off and ON/OFF key.
|
||||
|
||||
- compatible
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon".
|
||||
Definition: Must include "fsl,sec-v4.0-mon" and "syscon".
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
|
|
@ -341,7 +342,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
the child address, parent address, & length.
|
||||
|
||||
- interrupts
|
||||
Usage: required
|
||||
Usage: optional
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
|
|
@ -358,7 +359,7 @@ Secure Non-Volatile Storage (SNVS) Node
|
|||
|
||||
EXAMPLE
|
||||
sec_mon@314000 {
|
||||
compatible = "fsl,sec-v4.0-mon";
|
||||
compatible = "fsl,sec-v4.0-mon", "syscon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
|
|
@ -375,16 +376,72 @@ Secure Non-Volatile Storage (SNVS) Low Power (LP) RTC Node
|
|||
Value type: <string>
|
||||
Definition: Must include "fsl,sec-v4.0-mon-rtc-lp".
|
||||
|
||||
- reg
|
||||
- interrupts
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A standard property. Specifies the physical
|
||||
address and length of the SNVS LP configuration registers.
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: Specifies the interrupts generated by this
|
||||
device. The value of the interrupts property
|
||||
consists of one interrupt specifier. The format
|
||||
of the specifier is defined by the binding document
|
||||
describing the node's interrupt parent.
|
||||
|
||||
- regmap
|
||||
Usage: required
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
- offset
|
||||
Usage: option
|
||||
value type: <u32>
|
||||
Definition: LP register offset. default it is 0x34.
|
||||
|
||||
EXAMPLE
|
||||
sec_mon_rtc_lp@314000 {
|
||||
sec_mon_rtc_lp@1 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
interrupts = <93 2>;
|
||||
regmap = <&snvs>;
|
||||
offset = <0x34>;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
System ON/OFF key driver
|
||||
|
||||
The snvs-pwrkey is designed to enable POWER key function which controlled
|
||||
by SNVS ONOFF, the driver can report the status of POWER key and wakeup
|
||||
system if pressed after system suspend.
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: Mush include "fsl,sec-v4.0-pwrkey".
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop_encoded-array>
|
||||
Definition: The SNVS ON/OFF interrupt number to the CPU(s).
|
||||
|
||||
- linux,keycode:
|
||||
Usage: option
|
||||
Value type: <int>
|
||||
Definition: Keycode to emit, KEY_POWER by default.
|
||||
|
||||
- wakeup-source:
|
||||
Usage: option
|
||||
Value type: <boo>
|
||||
Definition: Button can wake-up the system.
|
||||
|
||||
- regmap:
|
||||
Usage: required:
|
||||
Value type: <phandle>
|
||||
Definition: this is phandle to the register map node.
|
||||
|
||||
EXAMPLE:
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&snvs>;
|
||||
interrupts = <0 4 0x4>
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
|
||||
=====================================================================
|
||||
|
|
@ -460,12 +517,20 @@ FULL EXAMPLE
|
|||
compatible = "fsl,sec-v4.0-mon";
|
||||
reg = <0x314000 0x1000>;
|
||||
ranges = <0 0x314000 0x1000>;
|
||||
interrupt-parent = <&mpic>;
|
||||
interrupts = <93 2>;
|
||||
|
||||
sec_mon_rtc_lp@34 {
|
||||
compatible = "fsl,sec-v4.0-mon-rtc-lp";
|
||||
reg = <0x34 0x58>;
|
||||
regmap = <&sec_mon>;
|
||||
offset = <0x34>;
|
||||
interrupts = <93 2>;
|
||||
};
|
||||
|
||||
snvs-pwrkey@0x020cc000 {
|
||||
compatible = "fsl,sec-v4.0-pwrkey";
|
||||
regmap = <&sec_mon>;
|
||||
interrupts = <0 4 0x4>;
|
||||
linux,keycode = <116>; /* KEY_POWER */
|
||||
wakeup;
|
||||
};
|
||||
};
|
||||
|
||||
|
|
|
|||
|
|
@ -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
61
Documentation/devicetree/bindings/dma/adi,axi-dmac.txt
Normal 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
54
Documentation/devicetree/bindings/dma/arm-pl08x.txt
Normal 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
54
Documentation/devicetree/bindings/dma/lpc1850-dmamux.txt
Normal 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";
|
||||
};
|
||||
|
|
@ -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
46
Documentation/devicetree/bindings/dma/sun4i-dma.txt
Normal 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
38
Documentation/devicetree/bindings/dma/zxdma.txt
Normal 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";
|
||||
}
|
||||
|
|
@ -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;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
22
Documentation/devicetree/bindings/gpio/gpio-mpc8xxx.txt
Normal 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";
|
||||
};
|
||||
|
|
@ -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
24
Documentation/devicetree/bindings/gpio/zx296702-gpio.txt
Normal 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>;
|
||||
};
|
||||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
||||
};
|
||||
|
|
|
|||
|
|
@ -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
22
Documentation/devicetree/bindings/i2c/i2c-emev2.txt
Normal 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
33
Documentation/devicetree/bindings/i2c/i2c-lpc2k.txt
Normal 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
74
Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt
Normal 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
45
Documentation/devicetree/bindings/i2c/i2c.txt
Normal 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.
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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::
|
||||
|
|
|
|||
|
|
@ -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
44
Documentation/devicetree/bindings/input/cypress,cyapa.txt
Normal 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;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -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:
|
||||
|
|
|
|||
1
Documentation/devicetree/bindings/input/snvs-pwrkey.txt
Normal file
1
Documentation/devicetree/bindings/input/snvs-pwrkey.txt
Normal file
|
|
@ -0,0 +1 @@
|
|||
See Documentation/devicetree/bindings/crypto/fsl-sec4.txt
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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";
|
||||
};
|
||||
|
|
@ -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 {
|
||||
|
|
|
|||
|
|
@ -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 = <®_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>;
|
||||
|
|
|
|||
|
|
@ -5,9 +5,14 @@ The BCM2835 contains a custom top-level interrupt controller, which supports
|
|||
controller, or the HW block containing it, is referred to occasionally
|
||||
as "armctrl" in the SoC documentation, hence naming of this binding.
|
||||
|
||||
The BCM2836 contains the same interrupt controller with the same
|
||||
interrupts, but the per-CPU interrupt controller is the root, and an
|
||||
interrupt there indicates that the ARMCTRL has an interrupt to handle.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic"
|
||||
- compatible : should be "brcm,bcm2835-armctrl-ic" or
|
||||
"brcm,bcm2836-armctrl-ic"
|
||||
- reg : Specifies base physical address and size of the registers.
|
||||
- interrupt-controller : Identifies the node as an interrupt controller
|
||||
- #interrupt-cells : Specifies the number of cells needed to encode an
|
||||
|
|
@ -20,6 +25,12 @@ Required properties:
|
|||
The 2nd cell contains the interrupt number within the bank. Valid values
|
||||
are 0..7 for bank 0, and 0..31 for bank 1.
|
||||
|
||||
Additional required properties for brcm,bcm2836-armctrl-ic:
|
||||
- interrupt-parent : Specifies the parent interrupt controller when this
|
||||
controller is the second level.
|
||||
- interrupts : Specifies the interrupt on the parent for this interrupt
|
||||
controller to handle.
|
||||
|
||||
The interrupt sources are as follows:
|
||||
|
||||
Bank 0:
|
||||
|
|
@ -102,9 +113,21 @@ Bank 2:
|
|||
|
||||
Example:
|
||||
|
||||
/* BCM2835, first level */
|
||||
intc: interrupt-controller {
|
||||
compatible = "brcm,bcm2835-armctrl-ic";
|
||||
reg = <0x7e00b200 0x200>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
|
||||
/* BCM2836, second level */
|
||||
intc: interrupt-controller {
|
||||
compatible = "brcm,bcm2836-armctrl-ic";
|
||||
reg = <0x7e00b200 0x200>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
|
||||
interrupt-parent = <&local_intc>;
|
||||
interrupts = <8>;
|
||||
};
|
||||
|
|
|
|||
|
|
@ -0,0 +1,37 @@
|
|||
BCM2836 per-CPU interrupt controller
|
||||
|
||||
The BCM2836 has a per-cpu interrupt controller for the timer, PMU
|
||||
events, and SMP IPIs. One of the CPUs may receive interrupts for the
|
||||
peripheral (GPU) events, which chain to the BCM2835-style interrupt
|
||||
controller.
|
||||
|
||||
Required properties:
|
||||
|
||||
- compatible: Should be "brcm,bcm2836-l1-intc"
|
||||
- reg: Specifies base physical address and size of the
|
||||
registers
|
||||
- interrupt-controller: Identifies the node as an interrupt controller
|
||||
- #interrupt-cells: Specifies the number of cells needed to encode an
|
||||
interrupt source. The value shall be 1
|
||||
|
||||
Please refer to interrupts.txt in this directory for details of the common
|
||||
Interrupt Controllers bindings used by client devices.
|
||||
|
||||
The interrupt sources are as follows:
|
||||
|
||||
0: CNTPSIRQ
|
||||
1: CNTPNSIRQ
|
||||
2: CNTHPIRQ
|
||||
3: CNTVIRQ
|
||||
8: GPU_FAST
|
||||
9: PMU_FAST
|
||||
|
||||
Example:
|
||||
|
||||
local_intc: local_intc {
|
||||
compatible = "brcm,bcm2836-l1-intc";
|
||||
reg = <0x40000000 0x100>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <1>;
|
||||
interrupt-parent = <&local_intc>;
|
||||
};
|
||||
135
Documentation/devicetree/bindings/interrupt-controller/msi.txt
Normal file
135
Documentation/devicetree/bindings/interrupt-controller/msi.txt
Normal 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>;
|
||||
};
|
||||
};
|
||||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
25
Documentation/devicetree/bindings/ipmi.txt
Normal 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>;
|
||||
};
|
||||
Some files were not shown because too many files have changed in this diff Show more
Loading…
Add table
Reference in a new issue