提交 bae6692c 编写于 作者: L Luca Coelho

Merge tag 'mac80211-next-for-davem-2016-04-13' of...

Merge tag 'mac80211-next-for-davem-2016-04-13' of git://git.kernel.org/pub/scm/linux/kernel/git/jberg/mac80211-next into master

To synchronize with Kalle, here's just a big change that affects
all drivers - removing the duplicated enum ieee80211_band and
replacing it by enum nl80211_band. On top of that, just a small
documentation update.

要显示的变更太多。

To preserve performance only 1000 of 1000+ files are displayed.
......@@ -33,6 +33,7 @@ Björn Steinbrink <B.Steinbrink@gmx.de>
Brian Avery <b.avery@hp.com>
Brian King <brking@us.ibm.com>
Christoph Hellwig <hch@lst.de>
Christophe Ricard <christophe.ricard@gmail.com>
Corey Minyard <minyard@acm.org>
Damian Hobson-Garcia <dhobsong@igel.co.jp>
David Brownell <david-b@pacbell.net>
......
......@@ -100,4 +100,5 @@ Description:
Users: libraw1394
libdc1394
tools like jujuutils, fwhack, ...
libhinawa
tools like linux-firewire-utils, fwhack, ...
What: /sys/fs/orangefs/perf_counters/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Counters and settings for various caches.
Read only.
What: /sys/fs/orangefs/perf_counter_reset
Date: June 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
echo a 0 or a 1 into perf_counter_reset to
reset all the counters in
/sys/fs/orangefs/perf_counters
except ones with PINT_PERF_PRESERVE set.
What: /sys/fs/orangefs/perf_time_interval_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Length of perf counter intervals in
seconds.
What: /sys/fs/orangefs/perf_history_size
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
The perf_counters cache statistics have N, or
perf_history_size, samples. The default is
one.
Every perf_time_interval_secs the (first)
samples are reset.
If N is greater than one, the "current" set
of samples is reset, and the samples from the
other N-1 intervals remain available.
What: /sys/fs/orangefs/op_timeout_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Service operation timeout in seconds.
What: /sys/fs/orangefs/slot_timeout_secs
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
"Slot" timeout in seconds. A "slot"
is an indexed buffer in the shared
memory segment used for communication
between the kernel module and userspace.
Slots are requested and waited for,
the wait times out after slot_timeout_secs.
What: /sys/fs/orangefs/acache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Attribute cache configurable settings.
What: /sys/fs/orangefs/ncache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Name cache configurable settings.
What: /sys/fs/orangefs/capcache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Capability cache configurable settings.
What: /sys/fs/orangefs/ccache/*
Date: Jun 2015
Contact: Mike Marshall <hubcap@omnibond.com>
Description:
Credential cache configurable settings.
......@@ -159,7 +159,7 @@ Description: read only
Decimal value of the Per Process MMIO space length.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<afu>m/pp_mmio_off
What: /sys/class/cxl/<afu>m/pp_mmio_off (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
......@@ -183,7 +183,7 @@ Description: read only
Identifies the revision level of the PSL.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/base_image
What: /sys/class/cxl/<card>/base_image (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
......@@ -193,7 +193,7 @@ Description: read only
during the initial program load.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/image_loaded
What: /sys/class/cxl/<card>/image_loaded (not in a guest)
Date: September 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
......@@ -201,7 +201,7 @@ Description: read only
onto the card.
Users: https://github.com/ibm-capi/libcxl
What: /sys/class/cxl/<card>/load_image_on_perst
What: /sys/class/cxl/<card>/load_image_on_perst (not in a guest)
Date: December 2014
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
......@@ -224,7 +224,7 @@ Description: write only
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
What: /sys/class/cxl/<card>/perst_reloads_same_image (not in a guest)
Date: July 2015
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
......
......@@ -271,3 +271,72 @@ Description: Parameters for the CPU cache attributes
- WriteBack: data is written only to the cache line and
the modified cache line is written to main
memory only when it is replaced
What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
'cpuX/cpufreq/throttle_stats' directory contains the CPU frequency
throttle stat attributes for the chip. The throttle stats of a cpu
is common across all the cpus belonging to a chip. Below are the
throttle attributes exported in the 'throttle_stats' directory:
- turbo_stat : This file gives the total number of times the max
frequency is throttled to lower frequency in turbo (at and above
nominal frequency) range of frequencies.
- sub_turbo_stat : This file gives the total number of times the
max frequency is throttled to lower frequency in sub-turbo(below
nominal frequency) range of frequencies.
- unthrottle : This file gives the total number of times the max
frequency is unthrottled after being throttled.
- powercap : This file gives the total number of times the max
frequency is throttled due to 'Power Capping'.
- overtemp : This file gives the total number of times the max
frequency is throttled due to 'CPU Over Temperature'.
- supply_fault : This file gives the total number of times the
max frequency is throttled due to 'Power Supply Failure'.
- overcurrent : This file gives the total number of times the
max frequency is throttled due to 'Overcurrent'.
- occ_reset : This file gives the total number of times the max
frequency is throttled due to 'OCC Reset'.
The sysfs attributes representing different throttle reasons like
powercap, overtemp, supply_fault, overcurrent and occ_reset map to
the reasons provided by OCC firmware for throttling the frequency.
What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/turbo_stat
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/sub_turbo_stat
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/unthrottle
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/powercap
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overtemp
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/supply_fault
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overcurrent
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
'policyX/throttle_stats' directory and all the attributes are same as
the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory and
attributes which give the frequency throttle information of the chip.
......@@ -179,3 +179,19 @@ Description: This file controls the USB 3 functionality, valid values are:
Note that toggling this value requires a reboot for changes to
take effect.
Users: KToshiba
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/cooling_method
Date: 2016
KernelVersion: 4.6
Contact: Azael Avalos <coproscefalo@gmail.com>
Description: This file controls the Cooling Method feature.
Reading this file prints two values, the first is the actual cooling method
and the second is the maximum cooling method supported.
When the maximum cooling method is ONE, valid values are:
* 0 -> Maximum Performance
* 1 -> Battery Optimized
When the maximum cooling method is TWO, valid values are:
* 0 -> Maximum Performance
* 1 -> Performance
* 2 -> Battery Optimized
Users: KToshiba
......@@ -98,3 +98,17 @@ Date: October 2015
Contact: "Chao Yu" <chao2.yu@samsung.com>
Description:
Controls the count of nid pages to be readaheaded.
What: /sys/fs/f2fs/<disk>/dirty_nats_ratio
Date: January 2016
Contact: "Chao Yu" <chao2.yu@samsung.com>
Description:
Controls dirty nat entries ratio threshold, if current
ratio exceeds configured threshold, checkpoint will
be triggered for flushing dirty nat entries.
What: /sys/fs/f2fs/<disk>/lifetime_write_kbytes
Date: January 2016
Contact: "Shuoran Liu" <liushuoran@huawei.com>
Description:
Shows total written kbytes issued to disk.
What: /sys/devices/platform/<i2c-demux-name>/cur_master
Date: January 2016
KernelVersion: 4.6
Contact: Wolfram Sang <wsa@the-dreams.de>
Description:
This file selects the active I2C master for a demultiplexed bus.
Write 0 there for the first master, 1 for the second etc. Reading the file will
give you a list with the active master marked. Example from a Renesas Lager
board:
root@Lager:~# cat /sys/devices/platform/i2c@8/cur_master
* 0 - /i2c@9
1 - /i2c@e6520000
2 - /i2c@e6530000
root@Lager:~# echo 2 > /sys/devices/platform/i2c@8/cur_master
root@Lager:~# cat /sys/devices/platform/i2c@8/cur_master
0 - /i2c@9
1 - /i2c@e6520000
* 2 - /i2c@e6530000
......@@ -100,3 +100,29 @@ allocated by dma_alloc_attrs() function from individual pages if it can
be mapped as contiguous chunk into device dma address space. By
specifying this attribute the allocated buffer is forced to be contiguous
also in physical memory.
DMA_ATTR_ALLOC_SINGLE_PAGES
---------------------------
This is a hint to the DMA-mapping subsystem that it's probably not worth
the time to try to allocate memory to in a way that gives better TLB
efficiency (AKA it's not worth trying to build the mapping out of larger
pages). You might want to specify this if:
- You know that the accesses to this memory won't thrash the TLB.
You might know that the accesses are likely to be sequential or
that they aren't sequential but it's unlikely you'll ping-pong
between many addresses that are likely to be in different physical
pages.
- You know that the penalty of TLB misses while accessing the
memory will be small enough to be inconsequential. If you are
doing a heavy operation like decryption or decompression this
might be the case.
- You know that the DMA mapping is fairly transitory. If you expect
the mapping to have a short lifetime then it may be worth it to
optimize allocation (avoid coming up with large pages) instead of
getting the slight performance win of larger pages.
Setting this hint doesn't guarantee that you won't get huge pages, but it
means that we won't try quite as hard to get them.
NOTE: At the moment DMA_ATTR_ALLOC_SINGLE_PAGES is only implemented on ARM,
though ARM64 patches will likely be posted soon.
......@@ -75,7 +75,6 @@
<chapter>
<title>Device registration</title>
!Pinclude/net/cfg80211.h Device registration
!Finclude/net/cfg80211.h ieee80211_band
!Finclude/net/cfg80211.h ieee80211_channel_flags
!Finclude/net/cfg80211.h ieee80211_channel
!Finclude/net/cfg80211.h ieee80211_rate_flags
......
......@@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >Description/Restrictions</td>
</tr>
<tr>
<td rowspan="37" valign="top" >DRM</td>
<td rowspan="42" valign="top" >DRM</td>
<td valign="top" >Generic</td>
<td valign="top" >“rotation”</td>
<td valign="top" >BITMASK</td>
......@@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >property to suggest an Y offset for a connector</td>
</tr>
<tr>
<td rowspan="3" valign="top" >Optional</td>
<td rowspan="8" valign="top" >Optional</td>
<td valign="top" >“scaling mode”</td>
<td valign="top" >ENUM</td>
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
......@@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
<td valign="top" >TBD</td>
</tr>
<tr>
<td valign="top" >“DEGAMMA_LUT”</td>
<td valign="top" >BLOB</td>
<td valign="top" >0</td>
<td valign="top" >CRTC</td>
<td valign="top" >DRM property to set the degamma lookup table
(LUT) mapping pixel data from the framebuffer before it is
given to the transformation matrix. The data is an interpreted
as an array of struct drm_color_lut elements. Hardware might
choose not to use the full precision of the LUT elements nor
use all the elements of the LUT (for example the hardware
might choose to interpolate between LUT[0] and LUT[4]). </td>
</tr>
<tr>
<td valign="top" >“DEGAMMA_LUT_SIZE”</td>
<td valign="top" >RANGE | IMMUTABLE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >CRTC</td>
<td valign="top" >DRM property to gives the size of the lookup
table to be set on the DEGAMMA_LUT property (the size depends
on the underlying hardware).</td>
</tr>
<tr>
<td valign="top" >“CTM”</td>
<td valign="top" >BLOB</td>
<td valign="top" >0</td>
<td valign="top" >CRTC</td>
<td valign="top" >DRM property to set the current
transformation matrix (CTM) apply to pixel data after the
lookup through the degamma LUT and before the lookup through
the gamma LUT. The data is an interpreted as a struct
drm_color_ctm.</td>
</tr>
<tr>
<td valign="top" >“GAMMA_LUT”</td>
<td valign="top" >BLOB</td>
<td valign="top" >0</td>
<td valign="top" >CRTC</td>
<td valign="top" >DRM property to set the gamma lookup table
(LUT) mapping pixel data after to the transformation matrix to
data sent to the connector. The data is an interpreted as an
array of struct drm_color_lut elements. Hardware might choose
not to use the full precision of the LUT elements nor use all
the elements of the LUT (for example the hardware might choose
to interpolate between LUT[0] and LUT[4]).</td>
</tr>
<tr>
<td valign="top" >“GAMMA_LUT_SIZE”</td>
<td valign="top" >RANGE | IMMUTABLE</td>
<td valign="top" >Min=0, Max=UINT_MAX</td>
<td valign="top" >CRTC</td>
<td valign="top" >DRM property to gives the size of the lookup
table to be set on the GAMMA_LUT property (the size depends on
the underlying hardware).</td>
</tr>
<tr>
<td rowspan="20" valign="top" >i915</td>
<td rowspan="2" valign="top" >Generic</td>
<td valign="top" >"Broadcast RGB"</td>
......@@ -2886,52 +2941,8 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
</sect2>
<sect2>
<title>File Operations</title>
<synopsis>const struct file_operations *fops</synopsis>
<abstract>File operations for the DRM device node.</abstract>
<para>
Drivers must define the file operations structure that forms the DRM
userspace API entry point, even though most of those operations are
implemented in the DRM core. The <methodname>open</methodname>,
<methodname>release</methodname> and <methodname>ioctl</methodname>
operations are handled by
<programlisting>
.owner = THIS_MODULE,
.open = drm_open,
.release = drm_release,
.unlocked_ioctl = drm_ioctl,
#ifdef CONFIG_COMPAT
.compat_ioctl = drm_compat_ioctl,
#endif
</programlisting>
</para>
<para>
Drivers that implement private ioctls that requires 32/64bit
compatibility support must provide their own
<methodname>compat_ioctl</methodname> handler that processes private
ioctls and calls <function>drm_compat_ioctl</function> for core ioctls.
</para>
<para>
The <methodname>read</methodname> and <methodname>poll</methodname>
operations provide support for reading DRM events and polling them. They
are implemented by
<programlisting>
.poll = drm_poll,
.read = drm_read,
.llseek = no_llseek,
</programlisting>
</para>
<para>
The memory mapping implementation varies depending on how the driver
manages memory. Pre-GEM drivers will use <function>drm_mmap</function>,
while GEM-aware drivers will use <function>drm_gem_mmap</function>. See
<xref linkend="drm-gem"/>.
<programlisting>
.mmap = drm_gem_mmap,
</programlisting>
</para>
<para>
No other file operation is supported by the DRM API.
</para>
!Pdrivers/gpu/drm/drm_fops.c file operations
!Edrivers/gpu/drm/drm_fops.c
</sect2>
<sect2>
<title>IOCTLs</title>
......@@ -3319,6 +3330,12 @@ int num_ioctls;</synopsis>
!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc
!Idrivers/gpu/drm/i915/intel_csr.c
</sect2>
<sect2>
<title>Video BIOS Table (VBT)</title>
!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
!Idrivers/gpu/drm/i915/intel_bios.c
!Idrivers/gpu/drm/i915/intel_bios.h
</sect2>
</sect1>
<sect1>
......@@ -3460,6 +3477,7 @@ int num_ioctls;</synopsis>
</sect1>
<sect1>
<title>Public constants</title>
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler_flags_t
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
</sect1>
......@@ -3488,6 +3506,10 @@ int num_ioctls;</synopsis>
<title>Backlight control</title>
!Pdrivers/platform/x86/apple-gmux.c Backlight control
</sect2>
<sect2>
<title>Public functions</title>
!Iinclude/linux/apple-gmux.h
</sect2>
</sect1>
</chapter>
......
......@@ -22,7 +22,7 @@ Orion family
88F5281
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
88F6183
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-orion5x
Linux kernel plat directory: arch/arm/plat-orion
......@@ -52,7 +52,7 @@ Kirkwood family
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr131 ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
......@@ -71,7 +71,7 @@ Discovery family
MV76100
Not supported by the Linux kernel.
Core: Feroceon ARMv5 compatible
Core: Feroceon 88fr571-vd ARMv5 compatible
Linux kernel mach directory: arch/arm/mach-mv78xx0
Linux kernel plat directory: arch/arm/plat-orion
......@@ -86,20 +86,26 @@ EBU Armada family
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
Core: Sheeva ARMv7 compatible PJ4B
Armada 375 Flavors:
88F6720
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
Armada 380/385 Flavors:
88F6810
88F6820
88F6828
Armada 390/398 Flavors:
88F6920
88F6928
Core: ARM Cortex-A9
Armada 38x Flavors:
88F6810 Armada 380
88F6820 Armada 385
88F6828 Armada 388
Product infos: http://www.marvell.com/embedded-processors/armada-38x/
Functional Spec: https://marvellcorp.wufoo.com/forms/marvell-armada-38x-functional-specifications/
Core: ARM Cortex-A9
Armada 39x Flavors:
88F6920 Armada 390
88F6928 Armada 398
Product infos: http://www.marvell.com/embedded-processors/armada-39x/
Core: ARM Cortex-A9
Armada XP Flavors:
MV78230
......@@ -112,12 +118,43 @@ EBU Armada family
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78230_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78260_OS.PDF
http://www.marvell.com/embedded-processors/armada-xp/assets/HW_MV78460_OS.PDF
Core: Sheeva ARMv7 compatible
Core: Sheeva ARMv7 compatible Dual-core or Quad-core PJ4B-MP
Linux kernel mach directory: arch/arm/mach-mvebu
Linux kernel plat directory: none
EBU Armada family ARMv8
-----------------------
Armada 3710/3720 Flavors:
88F3710
88F3720
Core: ARM Cortex A53 (ARMv8)
Homepage: http://www.marvell.com/embedded-processors/armada-3700/
Product Brief: http://www.marvell.com/embedded-processors/assets/PB-88F3700-FNL.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-37*
Armada 7K Flavors:
88F7020 (AP806 Dual + one CP110)
88F7040 (AP806 Quad + one CP110)
Core: ARM Cortex A72
Homepage: http://www.marvell.com/embedded-processors/armada-70xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada7020PB-Jan2016.pdf
http://www.marvell.com/embedded-processors/assets/Armada7040PB-Jan2016.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-70*
Armada 8K Flavors:
88F8020 (AP806 Dual + two CP110)
88F8040 (AP806 Quad + two CP110)
Core: ARM Cortex A72
Homepage: http://www.marvell.com/embedded-processors/armada-80xx/
Product Brief: http://www.marvell.com/embedded-processors/assets/Armada8020PB-Jan2016.pdf
http://www.marvell.com/embedded-processors/assets/Armada8040PB-Jan2016.pdf
Device tree files: arch/arm64/boot/dts/marvell/armada-80*
Avanta family
-------------
......@@ -135,6 +172,15 @@ Avanta family
Linux kernel mach directory: no code in mainline yet, planned for the future
Linux kernel plat directory: no code in mainline yet, planned for the future
Storage family
--------------
Armada SP:
88RC1580
Product infos: http://www.marvell.com/storage/armada-sp/
Core: Sheeva ARMv7 comatible Quad-core PJ4C
(not supported in upstream Linux kernel)
Dove family (application processor)
-----------------------------------
......@@ -155,7 +201,7 @@ PXA 2xx/3xx/93x/95x family
Flavors:
PXA21x, PXA25x, PXA26x
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale1 core
PXA270, PXA271, PXA272
Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_pb.pdf
Design guide : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_design_guide.pdf
......@@ -163,7 +209,7 @@ PXA 2xx/3xx/93x/95x family
Specification : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_emts.pdf
Specification update : http://www.marvell.com/application-processors/pxa-family/assets/pxa_27x_spec_update.pdf
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale2 core
PXA300, PXA310, PXA320
PXA 300 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA300_PB_R4.pdf
PXA 310 Product Brief : http://www.marvell.com/application-processors/pxa-family/assets/PXA310_PB_R4.pdf
......@@ -174,10 +220,10 @@ PXA 2xx/3xx/93x/95x family
Specification Update : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_Spec_Update.zip
Reference Manual : http://www.marvell.com/application-processors/pxa-family/assets/PXA3xx_TavorP_BootROM_Ref_Manual.pdf
Application processor only
Core: ARMv5 XScale core
Core: ARMv5 XScale3 core
PXA930, PXA935
Application processor with Communication processor
Core: ARMv5 XScale core
Core: ARMv5 XScale3 core
PXA955
Application processor with Communication processor
Core: ARMv7 compatible Sheeva PJ4 core
......@@ -196,7 +242,7 @@ PXA 2xx/3xx/93x/95x family
Linux kernel mach directory: arch/arm/mach-pxa
Linux kernel plat directory: arch/arm/plat-pxa
MMP/MMP2 family (communication processor)
MMP/MMP2/MMP3 family (communication processor)
-----------------------------------------
Flavors:
......@@ -209,16 +255,32 @@ MMP/MMP2 family (communication processor)
Boot ROM manual : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_ref_manual.pdf
App node package : http://www.marvell.com/application-processors/armada-100/assets/armada_16x_app_note_package.pdf
Application processor only
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
PXA910
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
PXA910/PXA920
Homepage : http://www.marvell.com/communication-processors/pxa910/
Product Brief : http://www.marvell.com/communication-processors/pxa910/assets/Marvell_PXA910_Platform-001_PB_final.pdf
Application processor with Communication processor
Core: ARMv5 compatible Marvell PJ1 (Mohawk)
MMP2, a.k.a Armada 610
Core: ARMv5 compatible Marvell PJ1 88sv331 (Mohawk)
PXA688, a.k.a. MMP2, a.k.a Armada 610
Product Brief : http://www.marvell.com/application-processors/armada-600/assets/armada610_pb.pdf
Application processor only
Core: ARMv7 compatible Sheeva PJ4 core
Core: ARMv7 compatible Sheeva PJ4 88sv581x core
PXA2128, a.k.a. MMP3 (OLPC XO4, Linux support not upstream)
Product Brief : http://www.marvell.com/application-processors/armada/pxa2128/assets/Marvell-ARMADA-PXA2128-SoC-PB.pdf
Application processor only
Core: Dual-core ARMv7 compatible Sheeva PJ4C core
PXA960/PXA968/PXA978 (Linux support not upstream)
Application processor with Communication Processor
Core: ARMv7 compatible Sheeva PJ4 core
PXA986/PXA988 (Linux support not upstream)
Application processor with Communication Processor
Core: Dual-core ARMv7 compatible Sheeva PJ4B-MP core
PXA1088/PXA1920 (Linux support not upstream)
Application processor with Communication Processor
Core: quad-core ARMv7 Cortex-A7
PXA1908/PXA1928/PXA1936
Application processor with Communication Processor
Core: multi-core ARMv8 Cortex-A53
Comments:
......@@ -237,6 +299,10 @@ Berlin family (Multimedia Solutions)
-------------------------------------
Flavors:
88DE3010, Armada 1000 (no Linux support)
Core: Marvell PJ1 (ARMv5TE), Dual-core
Product Brief: http://www.marvell.com.cn/digital-entertainment/assets/armada_1000_pb.pdf
88DE3005, Armada 1500-mini
88DE3005, Armada 1500 Mini
Design name: BG2CD
Core: ARM Cortex-A9, PL310 L2CC
......@@ -247,14 +313,16 @@ Berlin family (Multimedia Solutions)
Homepage: http://www.marvell.com/multimedia-solutions/armada-1500-mini-plus/
88DE3100, Armada 1500
Design name: BG2
Core: Marvell PJ4B (ARMv7), Tauros3 L2CC
Product Brief: http://www.marvell.com/multimedia-solutions/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
Core: Marvell PJ4B-MP (ARMv7), Tauros3 L2CC
Product Brief: http://www.marvell.com/digital-entertainment/armada-1500/assets/Marvell-ARMADA-1500-Product-Brief.pdf
88DE3114, Armada 1500 Pro
Design name: BG2Q
Core: Quad Core ARM Cortex-A9, PL310 L2CC
88DE????
88DE3214, Armada 1500 Pro 4K
Design name: BG3
Core: ARM Cortex-A15, CA15 integrated L2CC
88DE3218, ARMADA 1500 Ultra
Core: ARM Cortex-A53
Homepage: http://www.marvell.com/multimedia-solutions/
Directory: arch/arm/mach-berlin
......@@ -263,6 +331,49 @@ Berlin family (Multimedia Solutions)
* This line of SoCs is based on Marvell Sheeva or ARM Cortex CPUs
with Synopsys DesignWare (IRQ, GPIO, Timers, ...) and PXA IP (SDHCI, USB, ETH, ...).
CPU Cores
---------
The XScale cores were designed by Intel, and shipped by Marvell in the older
PXA processors. Feroceon is a Marvell designed core that developed in-house,
and that evolved into Sheeva. The XScale and Feroceon cores were phased out
over time and replaced with Sheeva cores in later products, which subsequently
got replaced with licensed ARM Cortex-A cores.
XScale 1
CPUID 0x69052xxx
ARMv5, iWMMXt
XScale 2
CPUID 0x69054xxx
ARMv5, iWMMXt
XScale 3
CPUID 0x69056xxx or 0x69056xxx
ARMv5, iWMMXt
Feroceon-1850 88fr331 "Mohawk"
CPUID 0x5615331x or 0x41xx926x
ARMv5TE, single issue
Feroceon-2850 88fr531-vd "Jolteon"
CPUID 0x5605531x or 0x41xx926x
ARMv5TE, VFP, dual-issue
Feroceon 88fr571-vd "Jolteon"
CPUID 0x5615571x
ARMv5TE, VFP, dual-issue
Feroceon 88fr131 "Mohawk-D"
CPUID 0x5625131x
ARMv5TE, single-issue in-order
Sheeva PJ1 88sv331 "Mohawk"
CPUID 0x561584xx
ARMv5, single-issue iWMMXt v2
Sheeva PJ4 88sv581x "Flareon"
CPUID 0x560f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B 88sv581x
CPUID 0x561f581x
ARMv7, idivt, optional iWMMXt v2
Sheeva PJ4B-MP / PJ4C
CPUID 0x562f584x
ARMv7, idivt/idiva, LPAE, optional iWMMXt v2 and/or NEON
Long-term plans
---------------
......
......@@ -72,6 +72,5 @@ SunXi family
* Octa ARM Cortex-A7 based SoCs
- Allwinner A83T
+ Not Supported
+ Datasheet
http://dl.linux-sunxi.org/A83T/A83T_datasheet_Revision_1.1.pdf
......@@ -47,6 +47,11 @@ CONTENTS
5-3. IO
5-3-1. IO Interface Files
5-3-2. Writeback
6. Namespace
6-1. Basics
6-2. The Root and Views
6-3. Migration and setns(2)
6-4. Interaction with Other Namespaces
P. Information on Kernel Programming
P-1. Filesystem Support for Writeback
D. Deprecated v1 Core Features
......@@ -1114,6 +1119,148 @@ writeback as follows.
vm.dirty[_background]_ratio.
6. Namespace
6-1. Basics
cgroup namespace provides a mechanism to virtualize the view of the
"/proc/$PID/cgroup" file and cgroup mounts. The CLONE_NEWCGROUP clone
flag can be used with clone(2) and unshare(2) to create a new cgroup
namespace. The process running inside the cgroup namespace will have
its "/proc/$PID/cgroup" output restricted to cgroupns root. The
cgroupns root is the cgroup of the process at the time of creation of
the cgroup namespace.
Without cgroup namespace, the "/proc/$PID/cgroup" file shows the
complete path of the cgroup of a process. In a container setup where
a set of cgroups and namespaces are intended to isolate processes the
"/proc/$PID/cgroup" file may leak potential system level information
to the isolated processes. For Example:
# cat /proc/self/cgroup
0::/batchjobs/container_id1
The path '/batchjobs/container_id1' can be considered as system-data
and undesirable to expose to the isolated processes. cgroup namespace
can be used to restrict visibility of this path. For example, before
creating a cgroup namespace, one would see:
# ls -l /proc/self/ns/cgroup
lrwxrwxrwx 1 root root 0 2014-07-15 10:37 /proc/self/ns/cgroup -> cgroup:[4026531835]
# cat /proc/self/cgroup
0::/batchjobs/container_id1
After unsharing a new namespace, the view changes.
# ls -l /proc/self/ns/cgroup
lrwxrwxrwx 1 root root 0 2014-07-15 10:35 /proc/self/ns/cgroup -> cgroup:[4026532183]
# cat /proc/self/cgroup
0::/
When some thread from a multi-threaded process unshares its cgroup
namespace, the new cgroupns gets applied to the entire process (all
the threads). This is natural for the v2 hierarchy; however, for the
legacy hierarchies, this may be unexpected.
A cgroup namespace is alive as long as there are processes inside or
mounts pinning it. When the last usage goes away, the cgroup
namespace is destroyed. The cgroupns root and the actual cgroups
remain.
6-2. The Root and Views
The 'cgroupns root' for a cgroup namespace is the cgroup in which the
process calling unshare(2) is running. For example, if a process in
/batchjobs/container_id1 cgroup calls unshare, cgroup
/batchjobs/container_id1 becomes the cgroupns root. For the
init_cgroup_ns, this is the real root ('/') cgroup.
The cgroupns root cgroup does not change even if the namespace creator
process later moves to a different cgroup.
# ~/unshare -c # unshare cgroupns in some cgroup
# cat /proc/self/cgroup
0::/
# mkdir sub_cgrp_1
# echo 0 > sub_cgrp_1/cgroup.procs
# cat /proc/self/cgroup
0::/sub_cgrp_1
Each process gets its namespace-specific view of "/proc/$PID/cgroup"
Processes running inside the cgroup namespace will be able to see
cgroup paths (in /proc/self/cgroup) only inside their root cgroup.
From within an unshared cgroupns:
# sleep 100000 &
[1] 7353
# echo 7353 > sub_cgrp_1/cgroup.procs
# cat /proc/7353/cgroup
0::/sub_cgrp_1
From the initial cgroup namespace, the real cgroup path will be
visible:
$ cat /proc/7353/cgroup
0::/batchjobs/container_id1/sub_cgrp_1
From a sibling cgroup namespace (that is, a namespace rooted at a
different cgroup), the cgroup path relative to its own cgroup
namespace root will be shown. For instance, if PID 7353's cgroup
namespace root is at '/batchjobs/container_id2', then it will see
# cat /proc/7353/cgroup
0::/../container_id2/sub_cgrp_1
Note that the relative path always starts with '/' to indicate that
its relative to the cgroup namespace root of the caller.
6-3. Migration and setns(2)
Processes inside a cgroup namespace can move into and out of the
namespace root if they have proper access to external cgroups. For
example, from inside a namespace with cgroupns root at
/batchjobs/container_id1, and assuming that the global hierarchy is
still accessible inside cgroupns:
# cat /proc/7353/cgroup
0::/sub_cgrp_1
# echo 7353 > batchjobs/container_id2/cgroup.procs
# cat /proc/7353/cgroup
0::/../container_id2
Note that this kind of setup is not encouraged. A task inside cgroup
namespace should only be exposed to its own cgroupns hierarchy.
setns(2) to another cgroup namespace is allowed when:
(a) the process has CAP_SYS_ADMIN against its current user namespace
(b) the process has CAP_SYS_ADMIN against the target cgroup
namespace's userns
No implicit cgroup changes happen with attaching to another cgroup
namespace. It is expected that the someone moves the attaching
process under the target cgroup namespace root.
6-4. Interaction with Other Namespaces
Namespace specific cgroup hierarchy can be mounted by a process
running inside a non-init cgroup namespace.
# mount -t cgroup2 none $MOUNT_POINT
This will mount the unified cgroup hierarchy with cgroupns root as the
filesystem root. The process needs CAP_SYS_ADMIN against its user and
mount namespaces.
The virtualization of /proc/self/cgroup file combined with restricting
the view of cgroup hierarchy by namespace-private cgroupfs mount
provides a properly isolated cgroup view inside the container.
P. Information on Kernel Programming
This section contains kernel programming information in the areas
......
......@@ -13,8 +13,15 @@ Boards with the Amlogic Meson8b SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson8b";
Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
Required root node property:
compatible: "amlogic,meson-gxbb";
Board compatible values:
- "geniatech,atv1200" (Meson6)
- "minix,neo-x8" (Meson8)
- "tronfy,mxq" (Meson8b)
- "hardkernel,odroid-c1" (Meson8b)
- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
......@@ -123,7 +123,9 @@ Required nodes:
- syscon: some subnode of the RealView SoC node must be a
system controller node pointing to the control registers,
with the compatible string set to one of these tuples:
with the compatible string set to one of these:
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
"arm,realview-eb-syscon", "syscon"
"arm,realview-pb1176-syscon", "syscon"
"arm,realview-pb11mp-syscon", "syscon"
......@@ -180,6 +182,7 @@ described under the RS1 memory mapping.
Required properties (in root node):
compatible = "arm,juno"; /* For Juno r0 board */
compatible = "arm,juno-r1"; /* For Juno r1 board */
compatible = "arm,juno-r2"; /* For Juno r2 board */
Required nodes:
The description for the board must include:
......
Axis Communications AB
ARTPEC series SoC Device Tree Bindings
ARTPEC-6 ARM SoC
================
Required root node properties:
- compatible = "axis,artpec6";
ARTPEC-6 System Controller
--------------------------
The ARTPEC-6 has a system controller with mixed functions controlling DMA, PCIe
and resets.
Required properties:
- compatible: "axis,artpec6-syscon", "syscon"
- reg: Address and length of the register bank.
Example:
syscon {
compatible = "axis,artpec6-syscon", "syscon";
reg = <0xf8000000 0x48>;
};
ARTPEC-6 Development board:
---------------------------
Required root node properties:
- compatible = "axis,artpec6-dev-board", "axis,artpec6";
Broadcom Vulcan device tree bindings
------------------------------------
Boards with Broadcom Vulcan shall have the following root property:
Broadcom Vulcan Evaluation Board:
compatible = "brcm,vulcan-eval", "brcm,vulcan-soc";
Generic Vulcan board:
compatible = "brcm,vulcan-soc";
......@@ -34,6 +34,7 @@ specific to ARM.
Definition: must contain one of the following:
"arm,cci-400"
"arm,cci-500"
"arm,cci-550"
- reg
Usage: required
......@@ -101,6 +102,7 @@ specific to ARM.
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
secure acces to CCI registers
"arm,cci-500-pmu,r0"
"arm,cci-550-pmu,r0"
- reg:
Usage: required
Value type: Integer cells. A register entry, expressed
......
......@@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
"arm,cortex-r5"
"arm,cortex-r7"
"brcm,brahma-b15"
"brcm,vulcan"
"cavium,thunder"
"faraday,fa526"
"intel,sa110"
......@@ -178,6 +179,7 @@ nodes to be present and contain the properties described below.
"marvell,sheeva-v5"
"nvidia,tegra132-denver"
"qcom,krait"
"qcom,kryo"
"qcom,scorpion"
- enable-method
Value type: <stringlist>
......@@ -250,7 +252,7 @@ nodes to be present and contain the properties described below.
Usage: optional
Value type: <prop-encoded-array>
Definition: A u32 value that represents the running time dynamic
power coefficient in units of mW/MHz/uVolt^2. The
power coefficient in units of mW/MHz/uV^2. The
coefficient can either be calculated from power
measurements or derived by analysis.
......
......@@ -22,6 +22,8 @@ SoCs:
compatible = "ti,k2l", "ti,keystone"
- Keystone 2 Edison
compatible = "ti,k2e", "ti,keystone"
- K2G
compatible = "ti,k2g", "ti,keystone"
Boards:
- Keystone 2 Hawking/Kepler EVM
......@@ -32,3 +34,6 @@ Boards:
- Keystone 2 Edison EVM
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
- K2G EVM
compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
Marvell Armada 37xx Platforms Device Tree Bindings
--------------------------------------------------
Boards using a SoC of the Marvell Armada 37xx family must carry the
following root node property:
- compatible: must contain "marvell,armada3710"
In addition, boards using the Marvell Armada 3720 SoC shall have the
following property before the previous one:
- compatible: must contain "marvell,armada3720"
Example:
compatible = "marvell,armada-3720-db", "marvell,armada3720", "marvell,armada3710";
Marvell Armada 7K/8K Platforms Device Tree Bindings
---------------------------------------------------
Boards using a SoC of the Marvell Armada 7K or 8K families must carry
the following root node property:
- compatible, with one of the following values:
- "marvell,armada7020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
when the SoC being used is the Armada 7020
- "marvell,armada7040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
when the SoC being used is the Armada 7040
- "marvell,armada8020", "marvell,armada-ap806-dual", "marvell,armada-ap806"
when the SoC being used is the Armada 8020
- "marvell,armada8040", "marvell,armada-ap806-quad", "marvell,armada-ap806"
when the SoC being used is the Armada 8040
Example:
compatible = "marvell,armada7040-db", "marvell,armada7040",
"marvell,armada-ap806-quad", "marvell,armada-ap806";
......@@ -19,9 +19,12 @@ SoC. Currently known SoC compatibles are:
And in addition, the compatible shall be extended with the specific
board. Currently known boards are:
"buffalo,linkstation-lsqvl"
"buffalo,linkstation-lsvl"
"buffalo,linkstation-lswsxl"
"buffalo,linkstation-lswxl"
"buffalo,linkstation-lswvl"
"buffalo,lschlv2"
"buffalo,lswvl"
"buffalo,lswxl"
"buffalo,lsxhl"
"buffalo,lsxl"
"cloudengines,pogo02"
......
......@@ -11,6 +11,7 @@ compatible: Must contain one of
"mediatek,mt6589"
"mediatek,mt6592"
"mediatek,mt6795"
"mediatek,mt7623"
"mediatek,mt8127"
"mediatek,mt8135"
"mediatek,mt8173"
......@@ -33,6 +34,9 @@ Supported boards:
- Evaluation board for MT6795(Helio X10):
Required root node properties:
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
- Evaluation board for MT7623:
Required root node properties:
- compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
- MTK mt8127 tablet moose EVB:
Required root node properties:
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
......
......@@ -155,7 +155,7 @@ Boards:
compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
- AM43x EPOS EVM
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
compatible = "ti,am43x-epos-evm", "ti,am43", "ti,am438x"
- AM437x GP EVM
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
......
......@@ -25,6 +25,7 @@ Required properties:
"qcom,scorpion-pmu"
"qcom,scorpion-mp-pmu"
"qcom,krait-pmu"
"cavium,thunder-pmu"
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
interrupt (PPI) then 1 interrupt should be specified.
......@@ -46,6 +47,16 @@ Optional properties:
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
events.
- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
(SDER) is accessible. This will cause the driver to do
any setup required that is only possible in ARMv7 secure
state. If not present the ARMv7 SDER will not be touched,
which means the PMU may fail to operate unless external
code (bootloader or security monitor) has performed the
appropriate initialisation. Note that this property is
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
in Non-secure state.
Example:
pmu {
......
QCOM device tree bindings
-------------------------
Some qcom based bootloaders identify the dtb blob based on a set of
device properties like SoC and platform and revisions of those components.
To support this scheme, we encode this information into the board compatible
string.
Each board must specify a top-level board compatible string with the following
format:
compatible = "qcom,<SoC>[-<soc_version>][-<foundry_id>]-<board>[/<subtype>][-<board_version>]"
The 'SoC' and 'board' elements are required. All other elements are optional.
The 'SoC' element must be one of the following strings:
apq8016
apq8074
apq8084
apq8096
msm8916
msm8974
msm8996
The 'board' element must be one of the following strings:
cdp
liquid
dragonboard
mtp
sbc
The 'soc_version' and 'board_version' elements take the form of v<Major>.<Minor>
where the minor number may be omitted when it's zero, i.e. v1.0 is the same
as v1. If all versions of the 'board_version' elements match, then a
wildcard '*' should be used, e.g. 'v*'.
The 'foundry_id' and 'subtype' elements are one or more digits from 0 to 9.
Examples:
"qcom,msm8916-v1-cdp-pm8916-v2.1"
A CDP board with an msm8916 SoC, version 1 paired with a pm8916 PMIC of version
2.1.
"qcom,apq8074-v2.0-2-dragonboard/1-v0.1"
A dragonboard board v0.1 of subtype 1 with an apq8074 SoC version 2, made in
foundry 2.
......@@ -11,5 +11,6 @@ using one of the following compatible strings:
allwinner,sun7i-a20
allwinner,sun8i-a23
allwinner,sun8i-a33
allwinner,sun8i-a83t
allwinner,sun8i-h3
allwinner,sun9i-a80
......@@ -14,6 +14,7 @@ Required properties:
- "cavium,octeon-7130-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "marvell,armada-3700-ahci"
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"
......
......@@ -46,6 +46,9 @@ Timing properties for child nodes. All are optional and default to 0.
- gpmc,adv-on-ns: Assertion time
- gpmc,adv-rd-off-ns: Read deassertion time
- gpmc,adv-wr-off-ns: Write deassertion time
- gpmc,adv-aad-mux-on-ns: Assertion time for AAD
- gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD
- gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD
WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
- gpmc,we-on-ns Assertion time
......@@ -54,6 +57,8 @@ Timing properties for child nodes. All are optional and default to 0.
OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
- gpmc,oe-on-ns: Assertion time
- gpmc,oe-off-ns: Deassertion time
- gpmc,oe-aad-mux-on-ns: Assertion time for AAD
- gpmc,oe-aad-mux-off-ns: Deassertion time for AAD
Access time and cycle time timings (in nanoseconds) corresponding to
GPMC_CONFIG5:
......
......@@ -8,7 +8,10 @@ Required properties:
- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
- #clock-cells : from common clock binding; Should always be set to 0.
- reg : Address and length of the axi-clkgen register set.
- clocks : Phandle and clock specifier for the parent clock.
- clocks : Phandle and clock specifier for the parent clock(s). This must
either reference one clock if only the first clock input is connected or two
if both clock inputs are connected. For the later case the clock connected
to the first input must be specified first.
Optional properties:
- clock-output-names : From common clock binding.
......
......@@ -92,6 +92,7 @@ PLL and leaf clock compatible strings for Cygnus are:
"brcm,cygnus-lcpll0"
"brcm,cygnus-mipipll"
"brcm,cygnus-asiu-clk"
"brcm,cygnus-audiopll"
The following table defines the set of PLL/clock index and ID for Cygnus.
These clock IDs are defined in:
......@@ -131,6 +132,11 @@ These clock IDs are defined in:
ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED
ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED
audiopll crystal 0 BCM_CYGNUS_AUDIOPLL
ch0_audio audiopll 1 BCM_CYGNUS_AUDIOPLL_CH0
ch1_audio audiopll 2 BCM_CYGNUS_AUDIOPLL_CH1
ch2_audio audiopll 3 BCM_CYGNUS_AUDIOPLL_CH2
Northstar and Northstar Plus
------
PLL and leaf clock compatible strings for Northstar and Northstar Plus are:
......
* NXP LPC1850 CREG clocks
The NXP LPC18xx/43xx CREG (Configuration Registers) block contains
control registers for two low speed clocks. One of the clocks is a
32 kHz oscillator driver with power up/down and clock gating. Next
is a fixed divider that creates a 1 kHz clock from the 32 kHz osc.
These clocks are used by the RTC and the Event Router peripherials.
The 32 kHz can also be routed to other peripherials to enable low
power modes.
This binding uses the common clock binding:
Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible:
Should be "nxp,lpc1850-creg-clk"
- #clock-cells:
Shall have value <1>.
- clocks:
Shall contain a phandle to the fixed 32 kHz crystal.
The creg-clk node must be a child of the creg syscon node.
The following clocks are available from the clock node.
Clock ID Name
0 1 kHz clock
1 32 kHz Oscillator
Example:
soc {
creg: syscon@40043000 {
compatible = "nxp,lpc1850-creg", "syscon", "simple-mfd";
reg = <0x40043000 0x1000>;
creg_clk: clock-controller {
compatible = "nxp,lpc1850-creg-clk";
clocks = <&xtal32>;
#clock-cells = <1>;
};
...
};
rtc: rtc@40046000 {
...
clocks = <&creg_clk 0>, <&ccu1 CLK_CPU_BUS>;
clock-names = "rtc", "reg";
...
};
};
......@@ -3,7 +3,7 @@ Binding for Qualcomm Atheros AR7xxx/AR9XXX PLL controller
The PPL controller provides the 3 main clocks of the SoC: CPU, DDR and AHB.
Required Properties:
- compatible: has to be "qca,<soctype>-cpu-intc" and one of the following
- compatible: has to be "qca,<soctype>-pll" and one of the following
fallbacks:
- "qca,ar7100-pll"
- "qca,ar7240-pll"
......@@ -21,8 +21,8 @@ Optional properties:
Example:
memory-controller@18050000 {
compatible = "qca,ar9132-ppl", "qca,ar9130-pll";
pll-controller@18050000 {
compatible = "qca,ar9132-pll", "qca,ar9130-pll";
reg = <0x18050000 0x20>;
clock-names = "ref";
......
......@@ -7,6 +7,7 @@ Required properties :
"qcom,gcc-apq8064"
"qcom,gcc-apq8084"
"qcom,gcc-ipq8064"
"qcom,gcc-ipq4019"
"qcom,gcc-msm8660"
"qcom,gcc-msm8916"
"qcom,gcc-msm8960"
......
......@@ -61,7 +61,7 @@ Examples
reg = <0 0xe6e88000 0 64>;
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cpg CPG_MOD 310>;
clock-names = "sci_ick";
clock-names = "fck";
dmas = <&dmac1 0x13>, <&dmac1 0x12>;
dma-names = "tx", "rx";
power-domains = <&cpg>;
......
......@@ -18,6 +18,7 @@ Required properties:
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
......@@ -39,12 +40,14 @@ Required properties:
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
"allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
......@@ -57,6 +60,7 @@ Required properties:
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
......
Binding for Texas Instruments ADPLL clock.
Binding status: Unstable - ABI compatibility may be broken in the future
This binding uses the common clock binding[1]. It assumes a
register-mapped ADPLL with two to three selectable input clocks
and three to four children.
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be one of "ti,dm814-adpll-s-clock" or
"ti,dm814-adpll-lj-clock" depending on the type of the ADPLL
- #clock-cells : from common clock binding; shall be set to 1.
- clocks : link phandles of parent clocks clkinp and clkinpulow, note
that the adpll-s-clock also has an optional clkinphif
- reg : address and length of the register set for controlling the ADPLL.
Examples:
adpll_mpu_ck: adpll@40 {
#clock-cells = <1>;
compatible = "ti,dm814-adpll-s-clock";
reg = <0x40 0x40>;
clocks = <&devosc_ck &devosc_ck &devosc_ck>;
clock-names = "clkinp", "clkinpulow", "clkinphif";
clock-output-names = "481c5040.adpll.dcoclkldo",
"481c5040.adpll.clkout",
"481c5040.adpll.clkoutx2",
"481c5040.adpll.clkouthif";
};
adpll_dsp_ck: adpll@80 {
#clock-cells = <1>;
compatible = "ti,dm814-adpll-lj-clock";
reg = <0x80 0x30>;
clocks = <&devosc_ck &devosc_ck>;
clock-names = "clkinp", "clkinpulow";
clock-output-names = "481c5080.adpll.dcoclkldo",
"481c5080.adpll.clkout",
"481c5080.adpll.clkoutldo";
};
......@@ -9,6 +9,8 @@ Required properties:
"apm,xgene-socpll-clock" - for a X-Gene SoC PLL clock
"apm,xgene-pcppll-clock" - for a X-Gene PCP PLL clock
"apm,xgene-device-clock" - for a X-Gene device clock
"apm,xgene-socpll-v2-clock" - for a X-Gene SoC PLL v2 clock
"apm,xgene-pcppll-v2-clock" - for a X-Gene PCP PLL v2 clock
Required properties for SoC or PCP PLL clocks:
- reg : shall be the physical PLL register address for the pll clock.
......
ARM HDLCD
This is a display controller found on several development platforms produced
by ARM Ltd and in more modern of its' Fast Models. The HDLCD is an RGB
streamer that reads the data from a framebuffer and sends it to a single
digital encoder (DVI or HDMI).
Required properties:
- compatible: "arm,hdlcd"
- reg: Physical base address and length of the controller's registers.
- interrupts: One interrupt used by the display controller to notify the
interrupt controller when any of the interrupt sources programmed in
the interrupt mask register have activated.
- clocks: A list of phandle + clock-specifier pairs, one for each
entry in 'clock-names'.
- clock-names: A list of clock names. For HDLCD it should contain:
- "pxlclk" for the clock feeding the output PLL of the controller.
Required sub-nodes:
- port: The HDLCD connection to an encoder chip. The connection is modeled
using the OF graph bindings specified in
Documentation/devicetree/bindings/graph.txt.
Optional properties:
- memory-region: phandle to a node describing memory (see
Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt) to be
used for the framebuffer; if not present, the framebuffer may be located
anywhere in memory.
Example:
/ {
...
hdlcd@2b000000 {
compatible = "arm,hdlcd";
reg = <0 0x2b000000 0 0x1000>;
interrupts = <GIC_SPI 85 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&oscclk5>;
clock-names = "pxlclk";
port {
hdlcd_output: endpoint@0 {
remote-endpoint = <&hdmi_enc_input>;
};
};
};
/* HDMI encoder on I2C bus */
i2c@7ffa0000 {
....
hdmi-transmitter@70 {
compatible = ".....";
reg = <0x70>;
port@0 {
hdmi_enc_input: endpoint {
remote-endpoint = <&hdlcd_output>;
};
hdmi_enc_output: endpoint {
remote-endpoint = <&hdmi_1_port>;
};
};
};
};
hdmi1: connector@1 {
compatible = "hdmi-connector";
type = "a";
port {
hdmi_1_port: endpoint {
remote-endpoint = <&hdmi_enc_output>;
};
};
};
...
};
......@@ -35,6 +35,12 @@ Optional properties for HDMI:
as an interrupt/status bit in the HDMI controller
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
Required properties for V3D:
- compatible: Should be "brcm,bcm2835-v3d"
- reg: Physical base address and length of the V3D's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Example:
pixelvalve@7e807000 {
compatible = "brcm,bcm2835-pixelvalve2";
......@@ -60,6 +66,12 @@ hdmi: hdmi@7e902000 {
clock-names = "pixel", "hdmi";
};
v3d: v3d@7ec00000 {
compatible = "brcm,bcm2835-v3d";
reg = <0x7ec00000 0x1000>;
interrupts = <1 10>;
};
vc4: gpu {
compatible = "brcm,bcm2835-vc4";
};
......@@ -6,6 +6,7 @@ Required properties:
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
- reg: physical base address and length of the registers set for the device
- interrupts: should contain DSI interrupt
......
......@@ -12,7 +12,8 @@ Required properties:
"samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
"samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
"samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
"samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
"samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
"samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
- reg: physical base address and length of the FIMD registers set.
......
......@@ -44,9 +44,34 @@ Optional properties:
- 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.
- port: DSI controller output port, containing one endpoint subnode.
DSI Endpoint properties:
- remote-endpoint: set to phandle of the connected panel's endpoint.
See Documentation/devicetree/bindings/graph.txt for device graph info.
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
to the physical lanes on the given platform. The value contained in
index n describes what logical data lane is mapped to the physical data
lane n (DATAn, where n lies between 0 and 3).
For example:
qcom,data-lane-map = <3 0 1 2>;
The above mapping describes that the logical data lane DATA3 is mapped to
the physical data lane DATA0, logical DATA0 to physical DATA1, logic DATA1
to phys DATA2 and logic DATA2 to phys DATA3.
There are only a limited number of physical to logical mappings possible:
"0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
"3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
"2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
"1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
"0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
"1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
"2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
"3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
DSI PHY:
Required properties:
......@@ -131,6 +156,7 @@ Example:
port {
dsi0_out: endpoint {
remote-endpoint = <&panel_in>;
lanes = <0 1 2 3>;
};
};
};
......
......@@ -11,6 +11,7 @@ Required properties:
- reg: Physical base address and length of the controller's registers
- reg-names: "core_physical"
- interrupts: The interrupt signal from the hdmi block.
- power-domains: Should be <&mmcc MDSS_GDSC>.
- clocks: device clocks
See ../clocks/clock-bindings.txt for details.
- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
......@@ -18,6 +19,8 @@ Required properties:
- qcom,hdmi-tx-hpd-gpio: hpd pin
- core-vdda-supply: phandle to supply regulator
- hdmi-mux-supply: phandle to mux regulator
- phys: the phandle for the HDMI PHY device
- phy-names: the name of the corresponding PHY device
Optional properties:
- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
......@@ -27,15 +30,38 @@ Optional properties:
- pinctrl-0: the default pinctrl state (active)
- pinctrl-1: the "sleep" pinctrl state
HDMI PHY:
Required properties:
- compatible: Could be the following
* "qcom,hdmi-phy-8660"
* "qcom,hdmi-phy-8960"
* "qcom,hdmi-phy-8974"
* "qcom,hdmi-phy-8084"
* "qcom,hdmi-phy-8996"
- #phy-cells: Number of cells in a PHY specifier; Should be 0.
- reg: Physical base address and length of the registers of the PHY sub blocks.
- reg-names: The names of register regions. The following regions are required:
* "hdmi_phy"
* "hdmi_pll"
For HDMI PHY on msm8996, these additional register regions are required:
* "hdmi_tx_l0"
* "hdmi_tx_l1"
* "hdmi_tx_l3"
* "hdmi_tx_l4"
- power-domains: Should be <&mmcc MDSS_GDSC>.
- clocks: device clocks
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
- core-vdda-supply: phandle to vdda regulator device node
Example:
/ {
...
hdmi: qcom,hdmi-tx-8960@4a00000 {
hdmi: hdmi@4a00000 {
compatible = "qcom,hdmi-tx-8960";
reg-names = "core_physical";
reg = <0x04a00000 0x1000>;
reg = <0x04a00000 0x2f0>;
interrupts = <GIC_SPI 79 0>;
power-domains = <&mmcc MDSS_GDSC>;
clock-names =
......@@ -54,5 +80,21 @@ Example:
pinctrl-names = "default", "sleep";
pinctrl-0 = <&hpd_active &ddc_active &cec_active>;
pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>;
phys = <&hdmi_phy>;
phy-names = "hdmi_phy";
};
hdmi_phy: phy@4a00400 {
compatible = "qcom,hdmi-phy-8960";
reg-names = "hdmi_phy",
"hdmi_pll";
reg = <0x4a00400 0x60>,
<0x4a00500 0x100>;
#phy-cells = <0>;
power-domains = <&mmcc MDSS_GDSC>;
clock-names = "slave_iface_clk";
clocks = <&mmcc HDMI_S_AHB_CLK>;
core-vdda-supply = <&pm8921_hdmi_mvs>;
};
};
LG 12.0" (1920x1280 pixels) TFT LCD panel
Required properties:
- compatible: should be "lg,lp120up1"
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
United Radiant Technology UMSH-8596MD-xT 7.0" WVGA TFT LCD panel
Supported are LVDS versions (-11T, -19T) and parallel ones
(-T, -1T, -7T, -20T).
Required properties:
- compatible: should be one of:
"urt,umsh-8596md-t",
"urt,umsh-8596md-1t",
"urt,umsh-8596md-7t",
"urt,umsh-8596md-11t",
"urt,umsh-8596md-19t",
"urt,umsh-8596md-20t".
This binding is compatible with the simple-panel binding, which is specified
in simple-panel.txt in this directory.
......@@ -8,6 +8,7 @@ Required Properties:
- "renesas,du-r8a7791" for R8A7791 (R-Car M2-W) compatible DU
- "renesas,du-r8a7793" for R8A7793 (R-Car M2-N) compatible DU
- "renesas,du-r8a7794" for R8A7794 (R-Car E2) compatible DU
- "renesas,du-r8a7795" for R8A7795 (R-Car H3) compatible DU
- reg: A list of base address and length of each memory resource, one for
each entry in the reg-names property.
......@@ -24,7 +25,7 @@ Required Properties:
- clock-names: Name of the clocks. This property is model-dependent.
- R8A7779 uses a single functional clock. The clock doesn't need to be
named.
- R8A779[0134] use one functional clock per channel and one clock per LVDS
- R8A779[01345] use one functional clock per channel and one clock per LVDS
encoder (if available). The functional clocks must be named "du.x" with
"x" being the channel numerical index. The LVDS clocks must be named
"lvds.x" with "x" being the LVDS encoder numerical index.
......@@ -41,13 +42,14 @@ bindings specified in Documentation/devicetree/bindings/graph.txt.
The following table lists for each supported model the port number
corresponding to each DU output.
Port 0 Port1 Port2
Port 0 Port1 Port2 Port3
-----------------------------------------------------------------------------
R8A7779 (H1) DPAD 0 DPAD 1 -
R8A7790 (H2) DPAD LVDS 0 LVDS 1
R8A7791 (M2-W) DPAD LVDS 0 -
R8A7793 (M2-N) DPAD LVDS 0 -
R8A7794 (E2) DPAD 0 DPAD 1 -
R8A7779 (H1) DPAD 0 DPAD 1 - -
R8A7790 (H2) DPAD LVDS 0 LVDS 1 -
R8A7791 (M2-W) DPAD LVDS 0 - -
R8A7793 (M2-N) DPAD LVDS 0 - -
R8A7794 (E2) DPAD 0 DPAD 1 - -
R8A7795 (H3) DPAD HDMI 0 HDMI 1 LVDS
Example: R8A7790 (R-Car H2) DU
......
Rockchip specific extensions to the Innosilicon HDMI
================================
Required properties:
- compatible:
"rockchip,rk3036-inno-hdmi";
- reg:
Physical base address and length of the controller's registers.
- clocks, clock-names:
Phandle to hdmi controller clock, name should be "pclk"
- interrupts:
HDMI interrupt number
- ports:
Contain one port node with endpoint definitions as defined in
Documentation/devicetree/bindings/graph.txt.
- pinctrl-0, pinctrl-name:
Switch the iomux of HPD/CEC pins to HDMI function.
Example:
hdmi: hdmi@20034000 {
compatible = "rockchip,rk3036-inno-hdmi";
reg = <0x20034000 0x4000>;
interrupts = <GIC_SPI 45 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&cru PCLK_HDMI>;
clock-names = "pclk";
pinctrl-names = "default";
pinctrl-0 = <&hdmi_ctl>;
status = "disabled";
hdmi_in: port {
#address-cells = <1>;
#size-cells = <0>;
hdmi_in_lcdc: endpoint@0 {
reg = <0>;
remote-endpoint = <&lcdc_out_hdmi>;
};
};
};
&pinctrl {
hdmi {
hdmi_ctl: hdmi-ctl {
rockchip,pins = <1 8 RK_FUNC_1 &pcfg_pull_none>,
<1 9 RK_FUNC_1 &pcfg_pull_none>,
<1 10 RK_FUNC_1 &pcfg_pull_none>,
<1 11 RK_FUNC_1 &pcfg_pull_none>;
};
};
};
......@@ -12,6 +12,8 @@ Required properties:
Optional properties:
- #dma-channels: Number of DMA channels supported by the controller (defaults
to 32 when not specified)
- #dma-requests: Number of DMA requestor lines supported by the controller
(defaults to 32 when not specified)
"marvell,pdma-1.0"
Used platforms: pxa25x, pxa27x, pxa3xx, pxa93x, pxa168, pxa910, pxa688.
......
Pinctrl-based I2C Bus DeMux
This binding describes an I2C bus demultiplexer that uses pin multiplexing to
route the I2C signals, and represents the pin multiplexing configuration using
the pinctrl device tree bindings. This may be used to select one I2C IP core at
runtime which may have a better feature set for a given task than another I2C
IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
if your current runtime configuration hits an errata of the internal IP core.
+-------------------------------+
| SoC |
| | +-----+ +-----+
| +------------+ | | dev | | dev |
| |I2C IP Core1|--\ | +-----+ +-----+
| +------------+ \-------+ | | |
| |Pinctrl|--|------+--------+
| +------------+ +-------+ |
| |I2C IP Core2|--/ |
| +------------+ |
| |
+-------------------------------+
Required properties:
- compatible: "i2c-demux-pinctrl"
- i2c-parent: List of phandles of I2C masters available for selection. The first
one will be used as default.
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
parents.
Furthermore, I2C mux properties and child nodes. See mux.txt in this directory.
Example:
Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
HDMI, so the bus is named "i2c-hdmi":
i2chdmi: i2c@8 {
compatible = "i2c-demux-pinctrl";
i2c-parent = <&gpioi2c>, <&iic2>, <&i2c2>;
i2c-bus-name = "i2c-hdmi";
#address-cells = <1>;
#size-cells = <0>;
ak4643: sound-codec@12 {
compatible = "asahi-kasei,ak4643";
#sound-dai-cells = <0>;
reg = <0x12>;
};
composite-in@20 {
compatible = "adi,adv7180";
reg = <0x20>;
remote = <&vin1>;
port {
adv7180: endpoint {
bus-width = <8>;
remote-endpoint = <&vin1ep0>;
};
};
};
hdmi@39 {
compatible = "adi,adv7511w";
reg = <0x39>;
interrupt-parent = <&gpio1>;
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
adi,input-depth = <8>;
adi,input-colorspace = "rgb";
adi,input-clock = "1x";
adi,input-style = <1>;
adi,input-justification = "evenly";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511_in: endpoint {
remote-endpoint = <&du_out_lvds0>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_con>;
};
};
};
};
};
And for clarification, here are the snipplets for the i2c-parents:
gpioi2c: i2c@9 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "i2c-gpio";
status = "disabled";
gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */
&gpio5 5 GPIO_ACTIVE_HIGH /* scl */
>;
i2c-gpio,delay-us = <5>;
};
...
&i2c2 {
pinctrl-0 = <&i2c2_pins>;
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
};
...
&iic2 {
pinctrl-0 = <&iic2_pins>;
pinctrl-names = "i2c-hdmi";
clock-frequency = <100000>;
};
Please note:
- pinctrl properties for the parent I2C controllers need a pinctrl state
with the same name as i2c-bus-name, not "default"!
- the i2c masters must have their status "disabled". This driver will
enable them at runtime when needed.
......@@ -11,7 +11,7 @@ Required properties:
Optional properties:
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
The absence of the propoerty indicates the default frequency 100 kHz.
The absence of the property indicates the default frequency 100 kHz.
- dmas: A list of two dma specifiers, one for each entry in dma-names.
- dma-names: should contain "tx" and "rx".
- scl-gpios: specify the gpio related to SCL pin
......
......@@ -17,7 +17,7 @@ Required properties:
Optional properties:
- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this
propoerty indicates the default frequency 100 kHz.
property indicates the default frequency 100 kHz.
- clocks: clock specifier.
- i2c-scl-falling-time-ns: see i2c.txt
......
......@@ -8,7 +8,7 @@ Required properties :
Optional properties:
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
The absence of the propoerty indicates the default frequency 100 kHz.
The absence of the property indicates the default frequency 100 kHz.
Examples :
......
......@@ -6,14 +6,17 @@ Required properties:
- interrupts : IIC controller unterrupt
- #address-cells = <1>
- #size-cells = <0>
- clocks: Input clock specifier. Refer to common clock bindings.
Optional properties:
- Child nodes conforming to i2c bus binding
- clock-names: Input clock name, should be 'pclk'.
Example:
axi_iic_0: i2c@40800000 {
compatible = "xlnx,xps-iic-2.00.a";
clocks = <&clkc 15>;
interrupts = < 1 2 >;
reg = < 0x40800000 0x10000 >;
......
......@@ -29,6 +29,8 @@ Optional properties:
ti,vref-delay-usecs vref supply delay in usecs, 0 for
external vref (u16).
ti,vref-mv The VREF voltage, in millivolts (u16).
Set to 0 to use internal refernce
(ADS7846).
ti,keep-vref-on set to keep vref on for differential
measurements as well
ti,swap-xy swap x and y axis
......
......@@ -21,6 +21,8 @@ Mbigen main node required properties:
- reg: Specifies the base physical address and size of the Mbigen
registers.
Mbigen sub node required properties:
------------------------------------------
- interrupt controller: Identifies the node as an interrupt controller
- msi-parent: Specifies the MSI controller this mbigen use.
......@@ -45,13 +47,23 @@ Mbigen main node required properties:
Examples:
mbigen_device_gmac:intc {
mbigen_chip_dsa {
compatible = "hisilicon,mbigen-v2";
reg = <0x0 0xc0080000 0x0 0x10000>;
interrupt-controller;
msi-parent = <&its_dsa 0x40b1c>;
num-pins = <9>;
#interrupt-cells = <2>;
mbigen_gmac:intc_gmac {
interrupt-controller;
msi-parent = <&its_dsa 0x40b1c>;
num-pins = <9>;
#interrupt-cells = <2>;
};
mbigen_i2c:intc_i2c {
interrupt-controller;
msi-parent = <&its_dsa 0x40b0e>;
num-pins = <2>;
#interrupt-cells = <2>;
};
};
Devices connect to mbigen required properties:
......
* Mediatek IOMMU Architecture Implementation
Some Mediatek SOCs contain a Multimedia Memory Management Unit (M4U) which
uses the ARM Short-Descriptor translation table format for address translation.
About the M4U Hardware Block Diagram, please check below:
EMI (External Memory Interface)
|
m4u (Multimedia Memory Management Unit)
|
SMI Common(Smart Multimedia Interface Common)
|
+----------------+-------
| |
| |
SMI larb0 SMI larb1 ... SoCs have several SMI local arbiter(larb).
(display) (vdec)
| |
| |
+-----+-----+ +----+----+
| | | | | |
| | |... | | | ... There are different ports in each larb.
| | | | | |
OVL0 RDMA0 WDMA0 MC PP VLD
As above, The Multimedia HW will go through SMI and M4U while it
access EMI. SMI is a bridge between m4u and the Multimedia HW. It contain
smi local arbiter and smi common. It will control whether the Multimedia
HW should go though the m4u for translation or bypass it and talk
directly with EMI. And also SMI help control the power domain and clocks for
each local arbiter.
Normally we specify a local arbiter(larb) for each multimedia HW
like display, video decode, and camera. And there are different ports
in each larb. Take a example, There are many ports like MC, PP, VLD in the
video decode local arbiter, all these ports are according to the video HW.
Required properties:
- compatible : must be "mediatek,mt8173-m4u".
- reg : m4u register base and size.
- interrupts : the interrupt of m4u.
- clocks : must contain one entry for each clock-names.
- clock-names : must be "bclk", It is the block clock of m4u.
- mediatek,larbs : List of phandle to the local arbiters in the current Socs.
Refer to bindings/memory-controllers/mediatek,smi-larb.txt. It must sort
according to the local arbiter index, like larb0, larb1, larb2...
- iommu-cells : must be 1. This is the mtk_m4u_id according to the HW.
Specifies the mtk_m4u_id as defined in
dt-binding/memory/mt8173-larb-port.h.
Example:
iommu: iommu@10205000 {
compatible = "mediatek,mt8173-m4u";
reg = <0 0x10205000 0 0x1000>;
interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>;
clocks = <&infracfg CLK_INFRA_M4U>;
clock-names = "bclk";
mediatek,larbs = <&larb0 &larb1 &larb2 &larb3 &larb4 &larb5>;
#iommu-cells = <1>;
};
Example for a client device:
display {
compatible = "mediatek,mt8173-disp";
iommus = <&iommu M4U_PORT_DISP_OVL0>,
<&iommu M4U_PORT_DISP_RDMA0>;
...
};
......@@ -7,23 +7,34 @@ connected to the IPMMU through a port called micro-TLB.
Required Properties:
- compatible: Must contain SoC-specific and generic entries from below.
- compatible: Must contain SoC-specific and generic entry below in case
the device is compatible with the R-Car Gen2 VMSA-compatible IPMMU.
- "renesas,ipmmu-r8a73a4" for the R8A73A4 (R-Mobile APE6) IPMMU.
- "renesas,ipmmu-r8a7790" for the R8A7790 (R-Car H2) IPMMU.
- "renesas,ipmmu-r8a7791" for the R8A7791 (R-Car M2-W) IPMMU.
- "renesas,ipmmu-r8a7793" for the R8A7793 (R-Car M2-N) IPMMU.
- "renesas,ipmmu-r8a7794" for the R8A7794 (R-Car E2) IPMMU.
- "renesas,ipmmu-r8a7795" for the R8A7795 (R-Car H3) IPMMU.
- "renesas,ipmmu-vmsa" for generic R-Car Gen2 VMSA-compatible IPMMU.
- reg: Base address and size of the IPMMU registers.
- interrupts: Specifiers for the MMU fault interrupts. For instances that
support secure mode two interrupts must be specified, for non-secure and
secure mode, in that order. For instances that don't support secure mode a
single interrupt must be specified.
single interrupt must be specified. Not required for cache IPMMUs.
- #iommu-cells: Must be 1.
Optional properties:
- renesas,ipmmu-main: reference to the main IPMMU instance in two cells.
The first cell is a phandle to the main IPMMU and the second cell is
the interrupt bit number associated with the particular cache IPMMU device.
The interrupt bit number needs to match the main IPMMU IMSSTR register.
Only used by cache IPMMU instances.
Each bus master connected to an IPMMU must reference the IPMMU in its device
node with the following property:
......
......@@ -23,28 +23,24 @@ MMUs.
for window 1, 2 and 3.
* M2M Scalers and G2D in Exynos5420 has one System MMU on the read channel and
the other System MMU on the write channel.
The drivers must consider how to handle those System MMUs. One of the idea is
to implement child devices or sub-devices which are the client devices of the
System MMU.
Note:
The current DT binding for the Exynos System MMU is incomplete.
The following properties can be removed or changed, if found incompatible with
the "Generic IOMMU Binding" support for attaching devices to the IOMMU.
For information on assigning System MMU controller to its peripheral devices,
see generic IOMMU bindings.
Required properties:
- compatible: Should be "samsung,exynos-sysmmu"
- reg: A tuple of base address and size of System MMU registers.
- #iommu-cells: Should be <0>.
- interrupt-parent: The phandle of the interrupt controller of System MMU
- interrupts: An interrupt specifier for interrupt signal of System MMU,
according to the format defined by a particular interrupt
controller.
- clock-names: Should be "sysmmu" if the System MMU is needed to gate its clock.
- clock-names: Should be "sysmmu" or a pair of "aclk" and "pclk" to gate
SYSMMU core clocks.
Optional "master" if the clock to the System MMU is gated by
another gate clock other than "sysmmu".
Exynos4 SoCs, there needs no "master" clock.
Exynos5 SoCs, some System MMUs must have "master" clocks.
- clocks: Required if the System MMU is needed to gate its clock.
another gate clock other core (usually main gate clock
of peripheral device this SYSMMU belongs to).
- clocks: Phandles for respective clocks described by clock-names.
- power-domains: Required if the System MMU is needed to gate its power.
Please refer to the following document:
Documentation/devicetree/bindings/power/pd-samsung.txt
......@@ -57,6 +53,7 @@ Examples:
power-domains = <&pd_gsc>;
clocks = <&clock CLK_GSCL0>;
clock-names = "gscl";
iommus = <&sysmmu_gsc0>;
};
sysmmu_gsc0: sysmmu@13E80000 {
......@@ -67,4 +64,5 @@ Examples:
clock-names = "sysmmu", "master";
clocks = <&clock CLK_SMMU_GSCL0>, <&clock CLK_GSCL0>;
power-domains = <&pd_gsc>;
#iommu-cells = <0>;
};
Hisilicon Hi6220 Mailbox Driver
===============================
Hisilicon Hi6220 mailbox supports up to 32 channels. Each channel
is unidirectional with a maximum message size of 8 words. I/O is
performed using register access (there is no DMA) and the cell
raises an interrupt when messages are received.
Mailbox Device Node:
====================
Required properties:
--------------------
- compatible: Shall be "hisilicon,hi6220-mbox"
- reg: Contains the mailbox register address range (base
address and length); the first item is for IPC
registers, the second item is shared buffer for
slots.
- #mbox-cells: Common mailbox binding property to identify the number
of cells required for the mailbox specifier. Must be 3.
<&phandle slot_id dst_irq ack_irq>
phandle: Label name of mailbox controller
slot_id: Slot id used either for TX or RX
dst_irq: IRQ identifier index number which used by MCU
ack_irq: IRQ identifier index number with generating a
TX/RX interrupt to application processor,
mailbox driver uses it to acknowledge interrupt
- interrupts: Contains the interrupt information for the mailbox
device. The format is dependent on which interrupt
controller the SoCs use.
Optional Properties:
--------------------
- hi6220,mbox-tx-noirq: Property of MCU firmware's feature, so mailbox driver
use this flag to ask MCU to enable "automatic idle
flag" mode or IRQ generated mode to acknowledge a TX
completion.
Example:
--------
mailbox: mailbox@f7510000 {
compatible = "hisilicon,hi6220-mbox";
reg = <0x0 0xf7510000 0x0 0x1000>, /* IPC_S */
<0x0 0x06dff800 0x0 0x0800>; /* Mailbox */
interrupt-parent = <&gic>;
interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <3>;
};
Mailbox client
===============
Required properties:
--------------------
- compatible: Many (See the client docs).
- mboxes: Standard property to specify a Mailbox (See ./mailbox.txt)
Cells must match 'mbox-cells' (See Mailbox Device Node above).
Optional Properties:
--------------------
- mbox-names: Name given to channels seen in the 'mboxes' property.
Example:
--------
stub_clock: stub_clock {
compatible = "hisilicon,hi6220-stub-clk";
hisilicon,hi6220-clk-sram = <&sram>;
#clock-cells = <1>;
mbox-names = "mbox-tx", "mbox-rx";
mboxes = <&mailbox 1 0 11>, <&mailbox 0 1 10>;
};
Rockchip mailbox
The Rockchip mailbox is used by the Rockchip CPU cores to communicate
requests to MCU processor.
Refer to ./mailbox.txt for generic information about mailbox device-tree
bindings.
Required properties:
- compatible: should be one of the following.
- "rockchip,rk3368-mbox" for rk3368
- reg: physical base address of the controller and length of memory mapped
region.
- interrupts: The interrupt number to the cpu. The interrupt specifier format
depends on the interrupt controller.
- #mbox-cells: Common mailbox binding property to identify the number
of cells required for the mailbox specifier. Should be 1
Example:
--------
/* RK3368 */
mbox: mbox@ff6b0000 {
compatible = "rockchip,rk3368-mailbox";
reg = <0x0 0xff6b0000 0x0 0x1000>,
interrupts = <GIC_SPI 146 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 147 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 148 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>;
#mbox-cells = <1>;
};
......@@ -44,7 +44,7 @@ Optional properties
Example:
mailbox_test {
compatible = "mailbox_test";
compatible = "mailbox-test";
reg = <0x[shared_memory_address], [shared_memory_size]>;
mboxes = <&mailbox2 0 1>, <&mailbox0 2 1>;
mbox-names = "tx", "rx";
......
Texas Instruments' Message Manager Driver
========================================
The Texas Instruments' Message Manager is a mailbox controller that has
configurable queues selectable at SoC(System on Chip) integration. The Message
manager is broken up into queues in different address regions that are called
"proxies" - each instance is unidirectional and is instantiated at SoC
integration level to indicate receive or transmit path.
Message Manager Device Node:
===========================
Required properties:
--------------------
- compatible: Shall be: "ti,k2g-message-manager"
- reg-names queue_proxy_region - Map the queue proxy region.
queue_state_debug_region - Map the queue state debug
region.
- reg: Contains the register map per reg-names.
- #mbox-cells Shall be 2. Contains the queue ID and proxy ID in that
order referring to the transfer path.
- interrupt-names: Contains interrupt names matching the rx transfer path
for a given SoC. Receive interrupts shall be of the
format: "rx_<QID>_<PID>".
For ti,k2g-message-manager, this shall contain:
"rx_005_002", "rx_057_002"
- interrupts: Contains the interrupt information corresponding to
interrupt-names property.
Example(K2G):
------------
msgmgr: msgmgr@02a00000 {
compatible = "ti,k2g-message-manager";
#mbox-cells = <2>;
reg-names = "queue_proxy_region", "queue_state_debug_region";
reg = <0x02a00000 0x400000>, <0x028c3400 0x400>;
interrupt-names = "rx_005", "rx_057";
interrupts = <GIC_SPI 324 IRQ_TYPE_LEVEL_HIGH>,
<GIC_SPI 327 IRQ_TYPE_LEVEL_HIGH>;
};
pmmc: pmmc {
[...]
mbox-names = "rx", "tx";
# RX queue ID is 5, proxy ID is 2
# TX queue ID is 0, proxy ID is 0
mboxes= <&msgmgr 5 2>,
<&msgmgr 0 0>;
[...]
};
The APM X-Gene SLIMpro mailbox is used to communicate messages between
the ARM64 processors and the Cortex M3 (dubbed SLIMpro). It uses a simple
interrupt based door bell mechanism and can exchange simple messages using the
internal registers.
There are total of 8 interrupts in this mailbox. Each used for an individual
door bell (or mailbox channel).
Required properties:
- compatible: Should be as "apm,xgene-slimpro-mbox".
- reg: Contains the mailbox register address range.
- interrupts: 8 interrupts must be from 0 to 7, interrupt 0 define the
the interrupt for mailbox channel 0 and interrupt 1 for
mailbox channel 1 and so likewise for the reminder.
- #mbox-cells: only one to specify the mailbox channel number.
Example:
Mailbox Node:
mailbox: mailbox@10540000 {
compatible = "apm,xgene-slimpro-mbox";
reg = <0x0 0x10540000 0x0 0xa000>;
#mbox-cells = <1>;
interrupts = <0x0 0x0 0x4>,
<0x0 0x1 0x4>,
<0x0 0x2 0x4>,
<0x0 0x3 0x4>,
<0x0 0x4 0x4>,
<0x0 0x5 0x4>,
<0x0 0x6 0x4>,
<0x0 0x7 0x4>,
};
SMI (Smart Multimedia Interface) Common
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
Required properties:
- compatible : must be "mediatek,mt8173-smi-common"
- reg : the register and size of the SMI block.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
- clock-names : must contain 2 entries, as follows:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
They may be the same if both source clocks are the same.
Example:
smi_common: smi@14022000 {
compatible = "mediatek,mt8173-smi-common";
reg = <0 0x14022000 0 0x1000>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>;
clocks = <&mmsys CLK_MM_SMI_COMMON>,
<&mmsys CLK_MM_SMI_COMMON>;
clock-names = "apb", "smi";
};
SMI (Smart Multimedia Interface) Local Arbiter
The hardware block diagram please check bindings/iommu/mediatek,iommu.txt
Required properties:
- compatible : must be "mediatek,mt8173-smi-larb"
- reg : the register and size of this local arbiter.
- mediatek,smi : a phandle to the smi_common node.
- power-domains : a phandle to the power domain of this local arbiter.
- clocks : Must contain an entry for each entry in clock-names.
- clock-names: must contain 2 entries, as follows:
- "apb" : Advanced Peripheral Bus clock, It's the clock for setting
the register.
- "smi" : It's the clock for transfer data and command.
Example:
larb1: larb@16010000 {
compatible = "mediatek,mt8173-smi-larb";
reg = <0 0x16010000 0 0x1000>;
mediatek,smi = <&smi_common>;
power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>;
clocks = <&vdecsys CLK_VDEC_CKEN>,
<&vdecsys CLK_VDEC_LARB_CKEN>;
clock-names = "apb", "smi";
};
Device Tree Bindings for the Arasan SDHCI Controller
The bindings follow the mmc[1], clock[2] and interrupt[3] bindings. Only
deviations are documented here.
The bindings follow the mmc[1], clock[2], interrupt[3] and phy[4] bindings.
Only deviations are documented here.
[1] Documentation/devicetree/bindings/mmc/mmc.txt
[2] Documentation/devicetree/bindings/clock/clock-bindings.txt
[3] Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
[4] Documentation/devicetree/bindings/phy/phy-bindings.txt
Required Properties:
- compatible: Compatibility string. Must be 'arasan,sdhci-8.9a' or
......@@ -17,6 +18,10 @@ Required Properties:
- interrupt-parent: Phandle for the interrupt controller that services
interrupts for this device.
Required Properties for "arasan,sdhci-5.1":
- phys: From PHY bindings: Phandle for the Generic PHY for arasan.
- phy-names: MUST be "phy_arasan".
Example:
sdhci@e0100000 {
compatible = "arasan,sdhci-8.9a";
......@@ -26,3 +31,14 @@ Example:
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
} ;
sdhci@e2800000 {
compatible = "arasan,sdhci-5.1";
reg = <0xe2800000 0x1000>;
clock-names = "clk_xin", "clk_ahb";
clocks = <&cru 8>, <&cru 18>;
interrupt-parent = <&gic>;
interrupts = <0 24 4>;
phys = <&emmc_phy>;
phy-names = "phy_arasan";
} ;
......@@ -4,7 +4,10 @@ This file documents differences between the core properties described
by mmc.txt and the properties that represent the IPROC SDHCI controller.
Required properties:
- compatible : Should be "brcm,sdhci-iproc-cygnus".
- compatible : Should be one of the following
"brcm,bcm2835-sdhci"
"brcm,sdhci-iproc-cygnus"
- clocks : The clock feeding the SDHCI controller.
Optional properties:
......
* Microchip PIC32 SDHCI Controller
This file documents differences between the core properties in mmc.txt
and the properties used by the sdhci-pic32 driver.
Required properties:
- compatible: Should be "microchip,pic32mzda-sdhci"
- interrupts: Should contain interrupt
- clock-names: Should be "base_clk", "sys_clk".
See: Documentation/devicetree/bindings/resource-names.txt
- clocks: Phandle to the clock.
See: Documentation/devicetree/bindings/clock/clock-bindings.txt
- pinctrl-names: A pinctrl state names "default" must be defined.
- pinctrl-0: Phandle referencing pin configuration of the SDHCI controller.
See: Documentation/devicetree/bindings/pinctrl/pinctrl-binding.txt
Example:
sdhci@1f8ec000 {
compatible = "microchip,pic32mzda-sdhci";
reg = <0x1f8ec000 0x100>;
interrupts = <191 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&REFCLKO4>, <&PBCLK5>;
clock-names = "base_clk", "sys_clk";
bus-width = <4>;
cap-sd-highspeed;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_sdhc1>;
};
......@@ -13,6 +13,8 @@ Required Properties:
- "rockchip,rk2928-dw-mshc": for Rockchip RK2928 and following,
before RK3288
- "rockchip,rk3288-dw-mshc": for Rockchip RK3288
- "rockchip,rk3036-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3036
- "rockchip,rk3368-dw-mshc", "rockchip,rk3288-dw-mshc": for Rockchip RK3368
Optional Properties:
* clocks: from common clock binding: if ciu_drive and ciu_sample are
......
......@@ -22,6 +22,7 @@ Required properties:
"renesas,sdhi-r8a7792" - SDHI IP on R8A7792 SoC
"renesas,sdhi-r8a7793" - SDHI IP on R8A7793 SoC
"renesas,sdhi-r8a7794" - SDHI IP on R8A7794 SoC
"renesas,sdhi-r8a7795" - SDHI IP on R8A7795 SoC
Optional properties:
- toshiba,mmc-wrprotect-disable: write-protect detection is unavailable
Atmel NAND flash
Required properties:
- compatible : should be "atmel,at91rm9200-nand" or "atmel,sama5d4-nand".
- compatible: The possible values are:
"atmel,at91rm9200-nand"
"atmel,sama5d2-nand"
"atmel,sama5d4-nand"
- reg : should specify localbus address and size used for the chip,
and hardware ECC controller if available.
If the hardware ECC is PMECC, it should contain address and size for
......@@ -21,10 +24,11 @@ Optional properties:
- nand-ecc-mode : String, operation mode of the NAND ecc mode, soft by default.
Supported values are: "none", "soft", "hw", "hw_syndrome", "hw_oob_first",
"soft_bch".
- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware.
Only supported by at91sam9x5 or later sam9 product.
- atmel,has-pmecc : boolean to enable Programmable Multibit ECC hardware,
capable of BCH encoding and decoding, on devices where it is present.
- atmel,pmecc-cap : error correct capability for Programmable Multibit ECC
Controller. Supported values are: 2, 4, 8, 12, 24.
Controller. Supported values are: 2, 4, 8, 12, 24. If the compatible string
is "atmel,sama5d2-nand", 32 is also valid.
- atmel,pmecc-sector-size : sector size for ECC computation. Supported values
are: 512, 1024.
- atmel,pmecc-lookup-table-offset : includes two offsets of lookup table in ROM
......@@ -32,15 +36,16 @@ Optional properties:
sector size 1024. If not specified, driver will build the table in runtime.
- nand-bus-width : 8 or 16 bus width if not present 8
- nand-on-flash-bbt: boolean to enable on flash bbt option if not present false
- Nand Flash Controller(NFC) is a slave driver under Atmel nand flash
- Required properties:
- compatible : "atmel,sama5d3-nfc".
- reg : should specify the address and size used for NFC command registers,
NFC registers and NFC Sram. NFC Sram address and size can be absent
if don't want to use it.
- clocks: phandle to the peripheral clock
- Optional properties:
- atmel,write-by-sram: boolean to enable NFC write by sram.
Nand Flash Controller(NFC) is an optional sub-node
Required properties:
- compatible : "atmel,sama5d3-nfc" or "atmel,sama5d4-nfc".
- reg : should specify the address and size used for NFC command registers,
NFC registers and NFC SRAM. NFC SRAM address and size can be absent
if don't want to use it.
- clocks: phandle to the peripheral clock
Optional properties:
- atmel,write-by-sram: boolean to enable NFC write by SRAM.
Examples:
nand0: nand@40000000,0 {
......
......@@ -3,7 +3,9 @@
Required properties:
- compatible : Should be "fsl,vf610-qspi", "fsl,imx6sx-qspi",
"fsl,imx7d-qspi", "fsl,imx6ul-qspi",
"fsl,ls1021-qspi"
"fsl,ls1021a-qspi"
or
"fsl,ls2080a-qspi" followed by "fsl,ls1021a-qspi"
- reg : the first contains the register location and length,
the second contains the memory mapping address and length
- reg-names: Should contain the reg names "QuadSPI" and "QuadSPI-memory"
......@@ -19,6 +21,7 @@ Optional properties:
But if there are two NOR flashes connected to the
bus, you should enable this property.
(Please check the board's schematic.)
- big-endian : That means the IP register is big endian
Example:
......
* Qualcomm NAND controller
Required properties:
- compatible: should be "qcom,ipq806x-nand"
- reg: MMIO address range
- clocks: must contain core clock and always on clock
- clock-names: must contain "core" for the core clock and "aon" for the
always on clock
- dmas: DMA specifier, consisting of a phandle to the ADM DMA
controller node and the channel number to be used for
NAND. Refer to dma.txt and qcom_adm.txt for more details
- dma-names: must be "rxtx"
- qcom,cmd-crci: must contain the ADM command type CRCI block instance
number specified for the NAND controller on the given
platform
- qcom,data-crci: must contain the ADM data type CRCI block instance
number specified for the NAND controller on the given
platform
- #address-cells: <1> - subnodes give the chip-select number
- #size-cells: <0>
* NAND chip-select
Each controller may contain one or more subnodes to represent enabled
chip-selects which (may) contain NAND flash chips. Their properties are as
follows.
Required properties:
- compatible: should contain "qcom,nandcs"
- reg: a single integer representing the chip-select
number (e.g., 0, 1, 2, etc.)
- #address-cells: see partition.txt
- #size-cells: see partition.txt
- nand-ecc-strength: see nand.txt
- nand-ecc-step-size: must be 512. see nand.txt for more details.
Optional properties:
- nand-bus-width: see nand.txt
Each nandcs device node may optionally contain a 'partitions' sub-node, which
further contains sub-nodes describing the flash partition mapping. See
partition.txt for more detail.
Example:
nand@1ac00000 {
compatible = "qcom,ebi2-nandc";
reg = <0x1ac00000 0x800>;
clocks = <&gcc EBI2_CLK>,
<&gcc EBI2_AON_CLK>;
clock-names = "core", "aon";
dmas = <&adm_dma 3>;
dma-names = "rxtx";
qcom,cmd-crci = <15>;
qcom,data-crci = <3>;
#address-cells = <1>;
#size-cells = <0>;
nandcs@0 {
compatible = "qcom,nandcs";
reg = <0>;
nand-ecc-strength = <4>;
nand-ecc-step-size = <512>;
nand-bus-width = <8>;
partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
partition@0 {
label = "boot-nand";
reg = <0 0x58a0000>;
};
partition@58a0000 {
label = "fs-nand";
reg = <0x58a0000 0x4000000>;
};
};
};
};
......@@ -59,6 +59,8 @@ Optional properties:
- snps,fb: fixed-burst
- snps,mb: mixed-burst
- snps,rb: rebuild INCRx Burst
- snps,tso: this enables the TSO feature otherwise it will be managed by
MAC HW capability register.
- mdio: with compatible = "snps,dwmac-mdio", create and register mdio bus.
Examples:
......
......@@ -5,12 +5,18 @@ Required properties:
* "qcom,ath10k"
* "qcom,ipq4019-wifi"
PCI based devices uses compatible string "qcom,ath10k" and takes only
calibration data via "qcom,ath10k-calibration-data". Rest of the properties
are not applicable for PCI based devices.
PCI based devices uses compatible string "qcom,ath10k" and takes calibration
data along with board specific data via "qcom,ath10k-calibration-data".
Rest of the properties are not applicable for PCI based devices.
AHB based devices (i.e. ipq4019) uses compatible string "qcom,ipq4019-wifi"
and also uses most of the properties defined in this doc.
and also uses most of the properties defined in this doc (except
"qcom,ath10k-calibration-data"). It uses "qcom,ath10k-pre-calibration-data"
to carry pre calibration data.
In general, entry "qcom,ath10k-pre-calibration-data" and
"qcom,ath10k-calibration-data" conflict with each other and only one
can be provided per device.
Optional properties:
- reg: Address and length of the register set for the device.
......@@ -35,8 +41,11 @@ Optional properties:
- qcom,msi_addr: MSI interrupt address.
- qcom,msi_base: Base value to add before writing MSI data into
MSI address register.
- qcom,ath10k-calibration-data : calibration data as an array, the
length can vary between hw versions
- qcom,ath10k-calibration-data : calibration data + board specific data
as an array, the length can vary between
hw versions.
- qcom,ath10k-pre-calibration-data : pre calibration data as an array,
the length can vary between hw versions.
Example (to supply the calibration data alone):
......@@ -105,5 +114,5 @@ wifi0: wifi@a000000 {
"legacy";
qcom,msi_addr = <0x0b006040>;
qcom,msi_base = <0x40>;
qcom,ath10k-calibration-data = [ 01 02 03 ... ];
qcom,ath10k-pre-calibration-data = [ 01 02 03 ... ];
};
......@@ -14,7 +14,7 @@ information.
Required properties:
- compatible: should contain the platform identifier such as:
"fsl,ls1021a-pcie", "snps,dw-pcie"
"fsl,ls2080a-pcie", "snps,dw-pcie"
"fsl,ls2080a-pcie", "fsl,ls2085a-pcie", "snps,dw-pcie"
- reg: base addresses and lengths of the PCIe controller
- interrupts: A list of interrupt outputs of the controller. Must contain an
entry for each entry in the interrupt-names property.
......
......@@ -134,12 +134,12 @@ mfio80 ddr_debug, mips_trace_data, mips_debug
mfio81 dreq0, mips_trace_data, eth_debug
mfio82 dreq1, mips_trace_data, eth_debug
mfio83 mips_pll_lock, mips_trace_data, usb_debug
mfio84 sys_pll_lock, mips_trace_data, usb_debug
mfio85 wifi_pll_lock, mips_trace_data, sdhost_debug
mfio86 bt_pll_lock, mips_trace_data, sdhost_debug
mfio87 rpu_v_pll_lock, dreq2, socif_debug
mfio88 rpu_l_pll_lock, dreq3, socif_debug
mfio89 audio_pll_lock, dreq4, dreq5
mfio84 audio_pll_lock, mips_trace_data, usb_debug
mfio85 rpu_v_pll_lock, mips_trace_data, sdhost_debug
mfio86 rpu_l_pll_lock, mips_trace_data, sdhost_debug
mfio87 sys_pll_lock, dreq2, socif_debug
mfio88 wifi_pll_lock, dreq3, socif_debug
mfio89 bt_pll_lock, dreq4, dreq5
tck
trstn
tdi
......
......@@ -91,6 +91,9 @@ mpp60 60 gpio, dev(ale1), uart1(rxd), sata0(prsnt), pcie(rstout),
mpp61 61 gpo, dev(we1), uart1(txd), audio(lrclk)
mpp62 62 gpio, dev(a2), uart1(cts), tdm(drx), pcie(clkreq0),
audio(mclk), uart0(cts)
mpp63 63 gpo, spi0(sck), tclk
mpp63 63 gpio, spi0(sck), tclk
mpp64 64 gpio, spi0(miso), spi0(cs1)
mpp65 65 gpio, spi0(mosi), spi0(cs2)
Note: According to the datasheet mpp63 is a gpo but there is at least
one example of a gpio usage on the board D-Link DNS-327L
......@@ -35,6 +35,8 @@ Required properties:
- "rockchip,rk3288-io-voltage-domain" for rk3288
- "rockchip,rk3368-io-voltage-domain" for rk3368
- "rockchip,rk3368-pmu-io-voltage-domain" for rk3368 pmu-domains
- "rockchip,rk3399-io-voltage-domain" for rk3399
- "rockchip,rk3399-pmu-io-voltage-domain" for rk3399 pmu-domains
- rockchip,grf: phandle to the syscon managing the "general register files"
......@@ -79,6 +81,15 @@ Possible supplies for rk3368 pmu-domains:
- pmu-supply: The supply connected to PMUIO_VDD.
- vop-supply: The supply connected to LCDC_VDD.
Possible supplies for rk3399:
- bt656-supply: The supply connected to APIO2_VDD.
- audio-supply: The supply connected to APIO5_VDD.
- sdmmc-supply: The supply connected to SDMMC0_VDD.
- gpio1830 The supply connected to APIO4_VDD.
Possible supplies for rk3399 pmu-domains:
- pmu1830-supply:The supply connected to PMUIO2_VDD.
Example:
io-domains {
......
......@@ -315,6 +315,16 @@ PROPERTIES
Value type: <phandle>
Definition: A phandle for 1EEE1588 timer.
- pcsphy-handle
Usage required for "fsl,fman-memac" MACs
Value type: <phandle>
Definition: A phandle for pcsphy.
- tbi-handle
Usage required for "fsl,fman-dtsec" MACs
Value type: <phandle>
Definition: A phandle for tbiphy.
EXAMPLE
fman1_tx28: port@a8000 {
......@@ -340,6 +350,7 @@ ethernet@e0000 {
reg = <0xe0000 0x1000>;
fsl,fman-ports = <&fman1_rx8 &fman1_tx28>;
ptp-timer = <&ptp-timer>;
tbi-handle = <&tbi0>;
};
============================================================================
......@@ -415,6 +426,13 @@ PROPERTIES
The settings and programming routines for internal/external
MDIO are different. Must be included for internal MDIO.
For internal PHY device on internal mdio bus, a PHY node should be created.
See the definition of the PHY node in booting-without-of.txt for an
example of how to define a PHY (Internal PHY has no interrupt line).
- For "fsl,fman-mdio" compatible internal mdio bus, the PHY is TBI PHY.
- For "fsl,fman-memac-mdio" compatible internal mdio bus, the PHY is PCS PHY,
PCS PHY addr must be '0'.
EXAMPLE
Example for FMan v2 external MDIO:
......@@ -425,12 +443,29 @@ mdio@f1000 {
interrupts = <101 2 0 0>;
};
Example for FMan v2 internal MDIO:
mdio@e3120 {
compatible = "fsl,fman-mdio";
reg = <0xe3120 0xee0>;
fsl,fman-internal-mdio;
tbi1: tbi-phy@8 {
reg = <0x8>;
device_type = "tbi-phy";
};
};
Example for FMan v3 internal MDIO:
mdio@f1000 {
compatible = "fsl,fman-memac-mdio";
reg = <0xf1000 0x1000>;
fsl,fman-internal-mdio;
pcsphy6: ethernet-phy@0 {
reg = <0x0>;
};
};
=============================================================================
......@@ -568,6 +603,7 @@ fman@400000 {
cell-index = <0>;
reg = <0xe0000 0x1000>;
fsl,fman-ports = <&fman1_rx_0x8 &fman1_tx_0x28>;
tbi-handle = <&tbi5>;
};
ethernet@e2000 {
......@@ -575,6 +611,7 @@ fman@400000 {
cell-index = <1>;
reg = <0xe2000 0x1000>;
fsl,fman-ports = <&fman1_rx_0x9 &fman1_tx_0x29>;
tbi-handle = <&tbi6>;
};
ethernet@e4000 {
......@@ -582,6 +619,7 @@ fman@400000 {
cell-index = <2>;
reg = <0xe4000 0x1000>;
fsl,fman-ports = <&fman1_rx_0xa &fman1_tx_0x2a>;
tbi-handle = <&tbi7>;
};
ethernet@e6000 {
......@@ -589,6 +627,7 @@ fman@400000 {
cell-index = <3>;
reg = <0xe6000 0x1000>;
fsl,fman-ports = <&fman1_rx_0xb &fman1_tx_0x2b>;
tbi-handle = <&tbi8>;
};
ethernet@e8000 {
......@@ -596,6 +635,7 @@ fman@400000 {
cell-index = <4>;
reg = <0xf0000 0x1000>;
fsl,fman-ports = <&fman1_rx_0xc &fman1_tx_0x2c>;
tbi-handle = <&tbi9>;
ethernet@f0000 {
cell-index = <8>;
......
Standard Unit Suffixes for Property names
Properties which have a unit of measure are recommended to have a unit
suffix appended to the property name. The list below contains the
recommended suffixes. Other variations exist in bindings, but should not
be used in new bindings or added here. The inconsistency in the unit
prefixes is due to selecting the most commonly used variants.
It is also recommended to use the units listed here and not add additional
unit prefixes.
Time/Frequency
----------------------------------------
-mhz : megahertz
-hz : Hertz (preferred)
-sec : seconds
-ms : milliseconds
-us : microseconds
-ns : nanoseconds
Distance
----------------------------------------
-mm : millimeters
Electricity
----------------------------------------
-microamp : micro amps
-ohms : Ohms
-micro-ohms : micro Ohms
-microvolt : micro volts
Temperature
----------------------------------------
-celsius : Degrees Celsius
-millicelsius : Degreee milli-Celsius
Pressure
----------------------------------------
-kpascal : kiloPascal
Pistachio Reset Controller
=============================================================================
This binding describes a reset controller device that is used to enable and
disable individual IP blocks within the Pistachio SoC using "soft reset"
control bits found in the Pistachio SoC top level registers.
The actual action taken when soft reset is asserted is hardware dependent.
However, when asserted it may not be possible to access the hardware's
registers, and following an assert/deassert sequence the hardware's previous
state may no longer be valid.
Please refer to Documentation/devicetree/bindings/reset/reset.txt
for common reset controller binding usage.
Required properties:
- compatible: Contains "img,pistachio-reset"
- #reset-cells: Contains 1
Example:
cr_periph: clk@18148000 {
compatible = "img,pistachio-cr-periph", "syscon", "simple-mfd";
reg = <0x18148000 0x1000>;
clocks = <&clk_periph PERIPH_CLK_SYS>;
clock-names = "sys";
#clock-cells = <1>;
pistachio_reset: reset-controller {
compatible = "img,pistachio-reset";
#reset-cells = <1>;
};
};
Specifying reset control of devices
=======================================
Device nodes should specify the reset channel required in their "resets"
property, containing a phandle to the pistachio reset device node and an
index specifying which reset to use, as described in
Documentation/devicetree/bindings/reset/reset.txt.
Example:
spdif_out: spdif-out@18100d00 {
...
resets = <&pistachio_reset PISTACHIO_RESET_SPDIF_OUT>;
reset-names = "rst";
...
};
Macro definitions for the supported resets can be found in:
include/dt-bindings/reset/pistachio-resets.h
* Maxim MCP795 SPI Serial Real-Time Clock
Required properties:
- compatible: Should contain "maxim,mcp795".
- reg: SPI address for chip
Example:
mcp795: rtc@0 {
compatible = "maxim,mcp795";
reg = <0>;
};
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
此差异已折叠。
Markdown is supported
0% .
You are about to add 0 people to the discussion. Proceed with caution.
先完成此消息的编辑!
想要评论请 注册