Merge branches 'for-4.6/upstream-fixes', 'for-4.7/asus', 'for-4.7/hidraw' and 'for-4.7/thingm' into for-linus

This commit is contained in:
Jiri Kosina 2016-05-17 12:38:03 +02:00
commit 27fd38c522
6990 changed files with 367347 additions and 180013 deletions

View File

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

View File

@ -3054,6 +3054,7 @@ D: PLX USB338x driver
D: PCA9634 driver
D: Option GTM671WFS
D: Fintek F81216A
D: AD5761 iio driver
D: Various kernel hacks
S: Qtechnology A/S
S: Valby Langgade 142

View File

@ -1,29 +0,0 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file is deprecated and scheduled to be removed in 2014,
because its not possible to express the 'soft and hard block'
state of the rfkill driver.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file is deprecated because there no longer is a way to
claim just control over a single rfkill instance.
This file is scheduled to be removed in 2012.
Values: 0: Kernel handles events

View File

@ -0,0 +1,13 @@
rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
What: /sys/class/rfkill/rfkill[0-9]+/claim
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: This file was deprecated because there no longer was a way to
claim just control over a single rfkill instance.
This file was scheduled to be removed in 2012, and was removed
in 2016.
Values: 0: Kernel handles events

View File

@ -100,4 +100,5 @@ Description:
Users: libraw1394
libdc1394
tools like jujuutils, fwhack, ...
libhinawa
tools like linux-firewire-utils, fwhack, ...

View File

@ -2,9 +2,8 @@ rfkill - radio frequency (RF) connector kill switch support
For details to this subsystem look at Documentation/rfkill.txt.
For the deprecated /sys/class/rfkill/*/state and
/sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/obsolete/sysfs-class-rfkill.
For the deprecated /sys/class/rfkill/*/claim knobs of this interface look in
Documentation/ABI/removed/sysfs-class-rfkill.
What: /sys/class/rfkill
Date: 09-Jul-2007
@ -42,6 +41,28 @@ Values: A numeric value.
1: true
What: /sys/class/rfkill/rfkill[0-9]+/state
Date: 09-Jul-2007
KernelVersion v2.6.22
Contact: linux-wireless@vger.kernel.org
Description: Current state of the transmitter.
This file was scheduled to be removed in 2014, but due to its
large number of users it will be sticking around for a bit
longer. Despite it being marked as stabe, the newer "hard" and
"soft" interfaces should be preffered, since it is not possible
to express the 'soft and hard block' state of the rfkill driver
through this interface. There will likely be another attempt to
remove it in the future.
Values: A numeric value.
0: RFKILL_STATE_SOFT_BLOCKED
transmitter is turned off by software
1: RFKILL_STATE_UNBLOCKED
transmitter is (potentially) active
2: RFKILL_STATE_HARD_BLOCKED
transmitter is forced off by something outside of
the driver's control.
What: /sys/class/rfkill/rfkill[0-9]+/hard
Date: 12-March-2010
KernelVersion v2.6.34

View File

@ -0,0 +1,87 @@
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.

View File

@ -496,8 +496,11 @@ Description:
1kohm_to_gnd: connected to ground via an 1kOhm resistor,
6kohm_to_gnd: connected to ground via a 6kOhm resistor,
20kohm_to_gnd: connected to ground via a 20kOhm resistor,
90kohm_to_gnd: connected to ground via a 90kOhm resistor,
100kohm_to_gnd: connected to ground via an 100kOhm resistor,
125kohm_to_gnd: connected to ground via an 125kOhm resistor,
500kohm_to_gnd: connected to ground via a 500kOhm resistor,
640kohm_to_gnd: connected to ground via a 640kOhm resistor,
three_state: left floating.
For a list of available output power down options read
outX_powerdown_mode_available. If Y is not present the
@ -1491,3 +1494,10 @@ Description:
This ABI is especially applicable for humidity sensors
to heatup the device and get rid of any condensation
in some humidity environment
What: /sys/bus/iio/devices/iio:deviceX/in_ph_raw
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Raw (unscaled no offset etc.) pH reading of a substance as a negative
base-10 logarithm of hydrodium ions in a litre of water.

View File

@ -0,0 +1,54 @@
What: /sys/bus/iio/devices/iio:deviceX/tia_resistanceY
/sys/bus/iio/devices/iio:deviceX/tia_capacitanceY
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the resistance and the capacitance settings for the
Transimpedance Amplifier. Y is 1 for Rf1 and Cf1, Y is 2 for
Rf2 and Cf2 values.
What: /sys/bus/iio/devices/iio:deviceX/tia_separate_en
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Enable or disable separate settings for the TransImpedance
Amplifier above, when disabled both values are set by the
first channel.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_raw
/sys/bus/iio/devices/iio:deviceX/in_intensity_ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get measured values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement.
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_ledY-ledY_ambient_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get differential values from the ADC for these stages. Y is the
specific LED number. The values are expressed in 24-bit twos
complement for the specified LEDs.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_offset
/sys/bus/iio/devices/iio:deviceX/out_current_ledY_ambient_offset
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the offset cancellation DAC setting for these
stages. The values are expressed in 5-bit sign-magnitude.
What: /sys/bus/iio/devices/iio:deviceX/out_current_ledY_raw
Date: December 2015
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the LED current for the specified LED. Y is the
specific LED number.

View File

@ -0,0 +1,15 @@
What: /sys/bus/iio/devices/iio:deviceX/meas_conf
What: /sys/bus/iio/devices/iio:deviceX/meas_conf_available
KernelVersion: 4.5
Contact: linux-iio@vger.kernel.org
Description:
Current configuration and available configurations
for the bias current.
normal - Normal measurement configurations (default)
positivebias - Positive bias configuration
negativebias - Negative bias configuration
disabled - Only available on HMC5983. Disables magnetic
sensor and enables temperature sensor.
Note: The effect of this configuration may vary
according to the device. For exact documentation
check the device's datasheet.

View File

@ -5,3 +5,12 @@ Description:
Specifies the hardware conversion mode used. The three
available modes are "normal", "high-speed" and "low-power",
where the last is the default mode.
What: /sys/bus/iio/devices/iio:deviceX/out_conversion_mode
KernelVersion: 4.6
Contact: linux-iio@vger.kernel.org
Description:
Specifies the hardware conversion mode used within DAC.
The two available modes are "high-power" and "low-power",
where "low-power" mode is the default mode.

View File

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

View File

@ -1,4 +1,20 @@
What: /sys/class/net/<iface>/batman-adv/throughput_override
Date: Feb 2014
Contact: Antonio Quartulli <antonio@meshcoding.com>
description:
Defines the throughput value to be used by B.A.T.M.A.N. V
when estimating the link throughput using this interface.
If the value is set to 0 then batman-adv will try to
estimate the throughput by itself.
What: /sys/class/net/<iface>/batman-adv/elp_interval
Date: Feb 2014
Contact: Linus Lüssing <linus.luessing@web.de>
Description:
Defines the interval in milliseconds in which batman
sends its probing packets for link quality measurements.
What: /sys/class/net/<iface>/batman-adv/iface_status
Date: May 2010
Contact: Marek Lindner <mareklindner@neomailbox.ch>
@ -12,4 +28,3 @@ Description:
The /sys/class/net/<iface>/batman-adv/mesh_iface file
displays the batman mesh interface this <iface>
currently is associated with.

View File

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

View File

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

View File

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

View File

@ -0,0 +1,18 @@
What: /sys/devices/platform/<i2c-demux-name>/available_masters
Date: January 2016
KernelVersion: 4.6
Contact: Wolfram Sang <wsa@the-dreams.de>
Description:
Reading the file will give you a list of masters which can be
selected for a demultiplexed bus. The format is
"<index>:<name>". Example from a Renesas Lager board:
0:/i2c@e6500000 1:/i2c@e6508000
What: /sys/devices/platform/<i2c-demux-name>/current_master
Date: January 2016
KernelVersion: 4.6
Contact: Wolfram Sang <wsa@the-dreams.de>
Description:
This file selects/shows the active I2C master for a demultiplexed
bus. It uses the <index> value from the file 'available_masters'.

View File

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

View File

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

View File

@ -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
Core: ARM Cortex-A9
Armada 380/385 Flavors:
88F6810
88F6820
88F6828
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 390/398 Flavors:
88F6920
88F6928
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
---------------

View File

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

View File

@ -1,93 +0,0 @@
This driver is for Compaq's SMART2 Intelligent Disk Array Controllers.
Supported Cards:
----------------
This driver is known to work with the following cards:
* SMART (EISA)
* SMART-2/E (EISA)
* SMART-2/P
* SMART-2DH
* SMART-2SL
* SMART-221
* SMART-3100ES
* SMART-3200
* Integrated Smart Array Controller
* SA 4200
* SA 4250ES
* SA 431
* RAID LC2 Controller
It should also work with some really old Disk array adapters, but I am
unable to test against these cards:
* IDA
* IDA-2
* IAES
EISA Controllers:
-----------------
If you want to use an EISA controller you'll have to supply some
modprobe/lilo parameters. If the driver is compiled into the kernel, must
give it the controller's IO port address at boot time (it is not
necessary to specify the IRQ). For example, if you had two SMART-2/E
controllers, in EISA slots 1 and 2 you'd give it a boot argument like
this:
smart2=0x1000,0x2000
If you were loading the driver as a module, you'd give load it like this:
modprobe cpqarray eisa=0x1000,0x2000
You can use EISA and PCI adapters at the same time.
Device Naming:
--------------
You need some entries in /dev for the ida device. MAKEDEV in the /dev
directory can make device nodes for you automatically. The device setup is
as follows:
Major numbers:
72 ida0
73 ida1
74 ida2
75 ida3
76 ida4
77 ida5
78 ida6
79 ida7
Minor numbers:
b7 b6 b5 b4 b3 b2 b1 b0
|----+----| |----+----|
| |
| +-------- Partition ID (0=wholedev, 1-15 partition)
|
+-------------------- Logical Volume number
The device naming scheme is:
/dev/ida/c0d0 Controller 0, disk 0, whole device
/dev/ida/c0d0p1 Controller 0, disk 0, partition 1
/dev/ida/c0d0p2 Controller 0, disk 0, partition 2
/dev/ida/c0d0p3 Controller 0, disk 0, partition 3
/dev/ida/c1d1 Controller 1, disk 1, whole device
/dev/ida/c1d1p1 Controller 1, disk 1, partition 1
/dev/ida/c1d1p2 Controller 1, disk 1, partition 2
/dev/ida/c1d1p3 Controller 1, disk 1, partition 3
Changelog:
==========
10-28-2004 : General cleanup, syntax fixes for in-kernel driver version.
James Nelson <james4765@gmail.com>
1999 : Original Document

View File

@ -24,5 +24,3 @@ net_prio.txt
- Network priority cgroups details and usages.
pids.txt
- Process number cgroups details and usages.
unified-hierarchy.txt
- Description the new/next cgroup interface.

View File

@ -8,7 +8,7 @@ Original copyright statements from cpusets.txt:
Portions Copyright (C) 2004 BULL SA.
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Christoph Lameter <cl@linux.com>
CONTENTS:
=========

View File

@ -6,7 +6,7 @@ Written by Simon.Derr@bull.net
Portions Copyright (c) 2004-2006 Silicon Graphics, Inc.
Modified by Paul Jackson <pj@sgi.com>
Modified by Christoph Lameter <clameter@sgi.com>
Modified by Christoph Lameter <cl@linux.com>
Modified by Paul Menage <menage@google.com>
Modified by Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com>

View File

@ -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
@ -132,6 +137,12 @@ strongly discouraged for production use. It is recommended to decide
the hierarchies and controller associations before starting using the
controllers after system boot.
During transition to v2, system management software might still
automount the v1 cgroup filesystem and so hijack all controllers
during boot, before manual intervention is possible. To make testing
and experimenting easier, the kernel parameter cgroup_no_v1= allows
disabling controllers in v1 and make them always available in v2.
2-2. Organizing Processes
@ -843,6 +854,15 @@ PAGE_SIZE multiple when read back.
Amount of memory used to cache filesystem data,
including tmpfs and shared memory.
kernel_stack
Amount of memory allocated to kernel stacks.
slab
Amount of memory used for storing in-kernel data
structures.
sock
Amount of memory used in network transmission buffers
@ -871,6 +891,16 @@ PAGE_SIZE multiple when read back.
on the internal memory management lists used by the
page reclaim algorithm
slab_reclaimable
Part of "slab" that might be reclaimed, such as
dentries and inodes.
slab_unreclaimable
Part of "slab" that cannot be reclaimed on memory
pressure.
pgfault
Total number of page faults incurred
@ -896,7 +926,7 @@ PAGE_SIZE multiple when read back.
limit, anonymous meomry of the cgroup will not be swapped out.
5-2-2. General Usage
5-2-2. Usage Guidelines
"memory.high" is the main mechanism to control memory usage.
Over-committing on high limit (sum of high limits > available memory)
@ -1089,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
@ -1368,6 +1540,12 @@ system than killing the group. Otherwise, memory.max is there to
limit this type of spillover and ultimately contain buggy or even
malicious applications.
Setting the original memory.limit_in_bytes below the current usage was
subject to a race condition, where concurrent charges could cause the
limit setting to fail. memory.max on the other hand will first set the
limit to prevent new charges, and then reclaim and OOM kill until the
new limit is met - or the task writing to memory.max is killed.
The combined memory+swap accounting and limiting is replaced by real
control over swap space.

View File

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

View File

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

View File

@ -0,0 +1,29 @@
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";

View File

@ -0,0 +1,10 @@
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";

View File

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

View File

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

View File

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

View File

@ -0,0 +1,16 @@
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";

View File

@ -0,0 +1,24 @@
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";

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,51 @@
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.

View File

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

View File

@ -11,8 +11,10 @@ Required properties:
- compatible : compatible string, one of:
- "allwinner,sun4i-a10-ahci"
- "hisilicon,hisi-ahci"
- "cavium,octeon-7130-ahci"
- "ibm,476gtr-ahci"
- "marvell,armada-380-ahci"
- "marvell,armada-3700-ahci"
- "snps,dwc-ahci"
- "snps,exynos5440-ahci"
- "snps,spear-ahci"

View File

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

View File

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

View File

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

View File

@ -0,0 +1,52 @@
* 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";
...
};
};

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,41 @@
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";
};

View File

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

View File

@ -0,0 +1,79 @@
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>;
};
};
};
...
};

View File

@ -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";
};

View File

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

View File

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

View File

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

View File

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

View File

@ -0,0 +1,7 @@
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.

View File

@ -0,0 +1,16 @@
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.

View File

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

View File

@ -0,0 +1,50 @@
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>;
};
};
};

View File

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

View File

@ -0,0 +1,17 @@
Android Goldfish Audio
Android goldfish audio device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-audio" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish_audio@9030000 {
compatible = "google,goldfish-audio";
reg = <0x9030000 0x100>;
interrupts = <0x4>;
};

View File

@ -0,0 +1,17 @@
Android Goldfish Events Keypad
Android goldfish events keypad device generated by android emulator.
Required properties:
- compatible : should contain "google,goldfish-events-keypad" to match emulator
- reg : <registers mapping>
- interrupts : <interrupt mapping>
Example:
goldfish-events@9040000 {
compatible = "google,goldfish-events-keypad";
reg = <0x9040000 0x1000>;
interrupts = <0x5>;
};

View File

@ -0,0 +1,135 @@
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.

View File

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

View File

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

View File

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

View File

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

View File

@ -1,8 +1,10 @@
Freescale MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC triaxial accelerometer
Freescale MMA8451Q, MMA8452Q, MMA8453Q, MMA8652FC or MMA8653FC
triaxial accelerometer
Required properties:
- compatible: should contain one of
* "fsl,mma8451"
* "fsl,mma8452"
* "fsl,mma8453"
* "fsl,mma8652"

View File

@ -0,0 +1,28 @@
* AT91 SAMA5D2 Analog to Digital Converter (ADC)
Required properties:
- compatible: Should be "atmel,sama5d2-adc".
- reg: Should contain ADC registers location and length.
- interrupts: Should contain the IRQ line for the ADC.
- clocks: phandle to device clock.
- clock-names: Must be "adc_clk".
- vref-supply: Supply used as reference for conversions.
- vddana-supply: Supply for the adc device.
- atmel,min-sample-rate-hz: Minimum sampling rate, it depends on SoC.
- atmel,max-sample-rate-hz: Maximum sampling rate, it depends on SoC.
- atmel,startup-time-ms: Startup time expressed in ms, it depends on SoC.
Example:
adc: adc@fc030000 {
compatible = "atmel,sama5d2-adc";
reg = <0xfc030000 0x100>;
interrupts = <40 IRQ_TYPE_LEVEL_HIGH 7>;
clocks = <&adc_clk>;
clock-names = "adc_clk";
atmel,min-sample-rate-hz = <200000>;
atmel,max-sample-rate-hz = <20000000>;
atmel,startup-time-ms = <4>;
vddana-supply = <&vdd_3v3_lp_reg>;
vref-supply = <&vdd_3v3_lp_reg>;
}

View File

@ -0,0 +1,58 @@
Freescale i.MX25 ADC GCQ device
This is a generic conversion queue device that can convert any of the
analog inputs using the ADC unit of the i.MX25.
Required properties:
- compatible: Should be "fsl,imx25-gcq".
- reg: Should be the register range of the module.
- interrupts: Should be the interrupt number of the module.
Typically this is <1>.
- interrupt-parent: phandle to the tsadc module of the i.MX25.
- #address-cells: Should be <1> (setting for the subnodes)
- #size-cells: Should be <0> (setting for the subnodes)
Optional properties:
- vref-ext-supply: The regulator supplying the ADC reference voltage.
Required when at least one subnode uses the this reference.
- vref-xp-supply: The regulator supplying the ADC reference voltage on pin XP.
Required when at least one subnode uses this reference.
- vref-yp-supply: The regulator supplying the ADC reference voltage on pin YP.
Required when at least one subnode uses this reference.
Sub-nodes:
Optionally you can define subnodes which define the reference voltage
for the analog inputs.
Required properties for subnodes:
- reg: Should be the number of the analog input.
0: xp
1: yp
2: xn
3: yn
4: wiper
5: inaux0
6: inaux1
7: inaux2
Optional properties for subnodes:
- fsl,adc-refp: specifies the positive reference input as defined in
<dt-bindings/iio/adc/fsl-imx25-gcq.h>
- fsl,adc-refn: specifies the negative reference input as defined in
<dt-bindings/iio/adc/fsl-imx25-gcq.h>
Example:
adc: adc@50030800 {
compatible = "fsl,imx25-gcq";
reg = <0x50030800 0x60>;
interrupt-parent = <&tscadc>;
interrupts = <1>;
#address-cells = <1>;
#size-cells = <0>;
inaux@5 {
reg = <5>;
fsl,adc-refp = <MX25_ADC_REFP_INT>;
fsl,adc-refn = <MX25_ADC_REFN_NGND>;
};
};

View File

@ -6,6 +6,7 @@ Required properties:
"microchip,mcp3422" or
"microchip,mcp3423" or
"microchip,mcp3424" or
"microchip,mcp3425" or
"microchip,mcp3426" or
"microchip,mcp3427" or
"microchip,mcp3428"

View File

@ -0,0 +1,19 @@
* Texas Instruments' ADC0831/ADC0832/ADC0832/ADC0838
Required properties:
- compatible: Should be one of
* "ti,adc0831"
* "ti,adc0832"
* "ti,adc0834"
* "ti,adc0838"
- reg: spi chip select number for the device
- vref-supply: The regulator supply for ADC reference voltage
- spi-max-frequency: Max SPI frequency to use (< 400000)
Example:
adc@0 {
compatible = "ti,adc0832";
reg = <0>;
vref-supply = <&vdd_supply>;
spi-max-frequency = <200000>;
};

View File

@ -0,0 +1,22 @@
* Atlas Scientific pH-SM OEM sensor
http://www.atlas-scientific.com/_files/_datasheets/_oem/pH_oem_datasheet.pdf
Required properties:
- compatible: must be "atlas,ph-sm"
- reg: the I2C address of the sensor
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: the sole interrupt generated by the device
Refer to interrupt-controller/interrupts.txt for generic interrupt client
node bindings.
Example:
atlas@65 {
compatible = "atlas,ph-sm";
reg = <0x65>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

View File

@ -0,0 +1,20 @@
Freescale vf610 Digital to Analog Converter bindings
The devicetree bindings are for the new DAC driver written for
vf610 SoCs from Freescale.
Required properties:
- compatible: Should contain "fsl,vf610-dac"
- reg: Offset and length of the register set for the device
- interrupts: Should contain the interrupt for the device
- clocks: The clock is needed by the DAC controller
- clock-names: Must contain "dac" matching entry in the clocks property.
Example:
dac0: dac@400cc000 {
compatible = "fsl,vf610-dac";
reg = <0x400cc000 0x1000>;
interrupts = <55 IRQ_TYPE_LEVEL_HIGH>;
clock-names = "dac";
clocks = <&clks VF610_CLK_DAC0>;
};

View File

@ -0,0 +1,34 @@
Texas Instruments AFE4403 Heart rate and Pulse Oximeter
Required properties:
- compatible : Should be "ti,afe4403".
- reg : SPI chip select address of device.
- tx-supply : Regulator supply to transmitting LEDs.
- interrupt-parent : Phandle to he parent interrupt controller.
- interrupts : The interrupt line the device ADC_RDY pin is
connected to. For details refer to,
../../interrupt-controller/interrupts.txt.
Optional properties:
- reset-gpios : GPIO used to reset the device.
For details refer to, ../../gpio/gpio.txt.
For other required and optional properties of SPI slave nodes
please refer to ../../spi/spi-bus.txt.
Example:
&spi0 {
heart_mon@0 {
compatible = "ti,afe4403";
reg = <0>;
spi-max-frequency = <10000000>;
tx-supply = <&vbat>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
};
};

View File

@ -0,0 +1,30 @@
Texas Instruments AFE4404 Heart rate and Pulse Oximeter
Required properties:
- compatible : Should be "ti,afe4404".
- reg : I2C address of the device.
- tx-supply : Regulator supply to transmitting LEDs.
- interrupt-parent : Phandle to he parent interrupt controller.
- interrupts : The interrupt line the device ADC_RDY pin is
connected to. For details refer to,
../interrupt-controller/interrupts.txt.
Optional properties:
- reset-gpios : GPIO used to reset the device.
For details refer to, ../gpio/gpio.txt.
Example:
&i2c2 {
heart_mon@58 {
compatible = "ti,afe4404";
reg = <0x58>;
tx-supply = <&vbat>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_RISING>;
reset-gpios = <&gpio1 16 GPIO_ACTIVE_LOW>;
};
};

View File

@ -11,11 +11,19 @@ Required properties:
Refer to interrupt-controller/interrupts.txt for generic
interrupt client node bindings.
Optional properties:
- maxim,led-current-microamp: configuration for LED current in microamperes
while the engine is running. First indexed value is the configuration for
the RED LED, and second value is for the IR LED.
Refer to the datasheet for the allowed current values.
Example:
max30100@057 {
compatible = "maxim,max30100";
reg = <57>;
maxim,led-current-microamp = <24000 50000>;
interrupt-parent = <&gpio1>;
interrupts = <16 2>;
};

View File

@ -0,0 +1,26 @@
* Texas Instruments OPT3001 Ambient Light Sensor
The driver supports interrupt-driven and interrupt-less operation, depending
on whether an interrupt property has been populated into the DT. Note that
the optional generation of IIO events on rising/falling light threshold changes
requires the use of interrupts. Without interrupts, only the simple reading
of the current light value is supported through the IIO API.
http://www.ti.com/product/opt3001
Required properties:
- compatible: should be "ti,opt3001"
- reg: the I2C address of the sensor
Optional properties:
- interrupt-parent: should be the phandle for the interrupt controller
- interrupts: interrupt mapping for GPIO IRQ (configure for falling edge)
Example:
opt3001@44 {
compatible = "ti,opt3001";
reg = <0x44>;
interrupt-parent = <&gpio1>;
interrupts = <28 IRQ_TYPE_EDGE_FALLING>;
};

View File

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

View File

@ -0,0 +1,56 @@
Synaptics RMI4 2D Sensor Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices which contain 2D sensors using Function 11 or
Function 12. Complete documentation for transports and other functions
can be found in:
Documentation/devicetree/bindings/input/rmi4.
RMI4 Function 11 and Function 12 are for 2D touch position sensing.
Additional documentation for F11 can be found at:
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
Optional Touch Properties:
Description in Documentation/devicetree/bindings/input/touch
- touchscreen-inverted-x
- touchscreen-inverted-y
- touchscreen-swapped-x-y
- touchscreen-x-mm
- touchscreen-y-mm
Optional Properties:
- syna,clip-x-low: Sets a minimum value for X.
- syna,clip-y-low: Sets a minimum value for Y.
- syna,clip-x-high: Sets a maximum value for X.
- syna,clip-y-high: Sets a maximum value for Y.
- syna,offset-x: Add an offset to X.
- syna,offset-y: Add an offset to Y.
- syna,delta-x-threshold: Set the minimum distance on the X axis required
to generate an interrupt in reduced reporting
mode.
- syna,delta-y-threshold: Set the minimum distance on the Y axis required
to generate an interrupt in reduced reporting
mode.
- syna,sensor-type: Set the sensor type. 1 for touchscreen 2 for touchpad.
- syna,disable-report-mask: Mask for disabling posiiton reporting. Used to
disable reporing absolute position data.
- syna,rezero-wait-ms: Time in miliseconds to wait after issuing a rezero
command.
Example of a RMI4 I2C device with F11:
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
...
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

View File

@ -0,0 +1,39 @@
Synaptics RMI4 F01 Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices which contain Function 1. Complete documentation
for transports and other functions can be found in:
Documentation/devicetree/bindings/input/rmi4.
Additional documentation for F01 can be found at:
http://www.synaptics.com/sites/default/files/511-000136-01-Rev-E-RMI4-Interfacing-Guide.pdf
Optional Properties:
- syna,nosleep-mode: If set the device will run at full power without sleeping.
nosleep has 3 modes, 0 will not change the default
setting, 1 will disable nosleep (allow sleeping),
and 2 will enable nosleep (disabling sleep).
- syna,wakeup-threshold: Defines the amplitude of the disturbance to the
background capacitance that will cause the
device to wake from dozing.
- syna,doze-holdoff-ms: The delay to wait after the last finger lift and the
first doze cycle.
- syna,doze-interval-ms: The time period that the device sleeps between finger
activity.
Example of a RMI4 I2C device with F01:
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
...
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
};
};

View File

@ -0,0 +1,53 @@
Synaptics RMI4 I2C Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices using the I2C transport driver. Complete documentation
for other transports and functions can be found in
Documentation/devicetree/bindings/input/rmi4.
Required Properties:
- compatible: syna,rmi4-i2c
- reg: I2C address
- #address-cells: Set to 1 to indicate that the function child nodes
consist of only on uint32 value.
- #size-cells: Set to 0 to indicate that the function child nodes do not
have a size property.
Optional Properties:
- interrupts: interrupt which the rmi device is connected to.
- interrupt-parent: The interrupt controller.
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- syna,reset-delay-ms: The number of milliseconds to wait after resetting the
device.
Function Parameters:
Parameters specific to RMI functions are contained in child nodes of the rmi device
node. Documentation for the parameters of each function can be found in:
Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
Example:
&i2c1 {
rmi4-i2c-dev@2c {
compatible = "syna,rmi4-i2c";
reg = <0x2c>;
#address-cells = <1>;
#size-cells = <0>;
interrupt-parent = <&gpio>;
interrupts = <4 2>;
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

View File

@ -0,0 +1,57 @@
Synaptics RMI4 SPI Device Binding
The Synaptics RMI4 core is able to support RMI4 devices using different
transports and different functions. This file describes the device tree
bindings for devices using the SPI transport driver. Complete documentation
for other transports and functions can be found in
Documentation/devicetree/bindings/input/rmi4.
Required Properties:
- compatible: syna,rmi4-spi
- reg: Chip select address for the device
- #address-cells: Set to 1 to indicate that the function child nodes
consist of only on uint32 value.
- #size-cells: Set to 0 to indicate that the function child nodes do not
have a size property.
Optional Properties:
- interrupts: interrupt which the rmi device is connected to.
- interrupt-parent: The interrupt controller.
See Documentation/devicetree/bindings/interrupt-controller/interrupts.txt
- spi-rx-delay-us: microsecond delay after a read transfer.
- spi-tx-delay-us: microsecond delay after a write transfer.
Function Parameters:
Parameters specific to RMI functions are contained in child nodes of the rmi device
node. Documentation for the parameters of each function can be found in:
Documentation/devicetree/bindings/input/rmi4/rmi_f*.txt.
Example:
spi@7000d800 {
rmi4-spi-dev@0 {
compatible = "syna,rmi4-spi";
reg = <0x0>;
#address-cells = <1>;
#size-cells = <0>;
spi-max-frequency = <4000000>;
spi-cpha;
spi-cpol;
interrupt-parent = <&gpio>;
interrupts = <TEGRA_GPIO(K, 2) 0x2>;
spi-rx-delay-us = <30>;
rmi4-f01@1 {
reg = <0x1>;
syna,nosleep-mode = <1>;
};
rmi4-f11@11 {
reg = <0x11>;
touchscreen-inverted-y;
syna,sensor-type = <2>;
};
};
};

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