mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
synced 2025-01-12 00:38:55 +00:00
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:
commit
27fd38c522
1
.mailmap
1
.mailmap
@ -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>
|
||||
|
1
CREDITS
1
CREDITS
@ -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
|
||||
|
@ -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
|
13
Documentation/ABI/removed/sysfs-class-rfkill
Normal file
13
Documentation/ABI/removed/sysfs-class-rfkill
Normal 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
|
@ -100,4 +100,5 @@ Description:
|
||||
|
||||
Users: libraw1394
|
||||
libdc1394
|
||||
tools like jujuutils, fwhack, ...
|
||||
libhinawa
|
||||
tools like linux-firewire-utils, fwhack, ...
|
||||
|
@ -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
|
||||
|
87
Documentation/ABI/stable/sysfs-fs-orangefs
Normal file
87
Documentation/ABI/stable/sysfs-fs-orangefs
Normal 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.
|
@ -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.
|
||||
|
54
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x
Normal file
54
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x
Normal 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.
|
15
Documentation/ABI/testing/sysfs-bus-iio-magnetometer-hmc5843
Normal file
15
Documentation/ABI/testing/sysfs-bus-iio-magnetometer-hmc5843
Normal 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.
|
@ -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.
|
||||
|
@ -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
|
||||
|
@ -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.
|
||||
|
||||
|
@ -271,3 +271,72 @@ Description: Parameters for the CPU cache attributes
|
||||
- WriteBack: data is written only to the cache line and
|
||||
the modified cache line is written to main
|
||||
memory only when it is replaced
|
||||
|
||||
What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/turbo_stat
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/sub_turbo_stat
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/unthrottle
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/powercap
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overtemp
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/supply_fault
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/overcurrent
|
||||
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
|
||||
Date: March 2016
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
|
||||
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
|
||||
attributes
|
||||
|
||||
'cpuX/cpufreq/throttle_stats' directory contains the CPU frequency
|
||||
throttle stat attributes for the chip. The throttle stats of a cpu
|
||||
is common across all the cpus belonging to a chip. Below are the
|
||||
throttle attributes exported in the 'throttle_stats' directory:
|
||||
|
||||
- turbo_stat : This file gives the total number of times the max
|
||||
frequency is throttled to lower frequency in turbo (at and above
|
||||
nominal frequency) range of frequencies.
|
||||
|
||||
- sub_turbo_stat : This file gives the total number of times the
|
||||
max frequency is throttled to lower frequency in sub-turbo(below
|
||||
nominal frequency) range of frequencies.
|
||||
|
||||
- unthrottle : This file gives the total number of times the max
|
||||
frequency is unthrottled after being throttled.
|
||||
|
||||
- powercap : This file gives the total number of times the max
|
||||
frequency is throttled due to 'Power Capping'.
|
||||
|
||||
- overtemp : This file gives the total number of times the max
|
||||
frequency is throttled due to 'CPU Over Temperature'.
|
||||
|
||||
- supply_fault : This file gives the total number of times the
|
||||
max frequency is throttled due to 'Power Supply Failure'.
|
||||
|
||||
- overcurrent : This file gives the total number of times the
|
||||
max frequency is throttled due to 'Overcurrent'.
|
||||
|
||||
- occ_reset : This file gives the total number of times the max
|
||||
frequency is throttled due to 'OCC Reset'.
|
||||
|
||||
The sysfs attributes representing different throttle reasons like
|
||||
powercap, overtemp, supply_fault, overcurrent and occ_reset map to
|
||||
the reasons provided by OCC firmware for throttling the frequency.
|
||||
|
||||
What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/turbo_stat
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/sub_turbo_stat
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/unthrottle
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/powercap
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overtemp
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/supply_fault
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/overcurrent
|
||||
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
|
||||
Date: March 2016
|
||||
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
|
||||
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
|
||||
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
|
||||
attributes
|
||||
|
||||
'policyX/throttle_stats' directory and all the attributes are same as
|
||||
the /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats directory and
|
||||
attributes which give the frequency throttle information of the chip.
|
||||
|
@ -179,3 +179,19 @@ Description: This file controls the USB 3 functionality, valid values are:
|
||||
Note that toggling this value requires a reboot for changes to
|
||||
take effect.
|
||||
Users: KToshiba
|
||||
|
||||
What: /sys/devices/LNXSYSTM:00/LNXSYBUS:00/TOS{1900,620{0,7,8}}:00/cooling_method
|
||||
Date: 2016
|
||||
KernelVersion: 4.6
|
||||
Contact: Azael Avalos <coproscefalo@gmail.com>
|
||||
Description: This file controls the Cooling Method feature.
|
||||
Reading this file prints two values, the first is the actual cooling method
|
||||
and the second is the maximum cooling method supported.
|
||||
When the maximum cooling method is ONE, valid values are:
|
||||
* 0 -> Maximum Performance
|
||||
* 1 -> Battery Optimized
|
||||
When the maximum cooling method is TWO, valid values are:
|
||||
* 0 -> Maximum Performance
|
||||
* 1 -> Performance
|
||||
* 2 -> Battery Optimized
|
||||
Users: KToshiba
|
||||
|
@ -98,3 +98,17 @@ Date: October 2015
|
||||
Contact: "Chao Yu" <chao2.yu@samsung.com>
|
||||
Description:
|
||||
Controls the count of nid pages to be readaheaded.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/dirty_nats_ratio
|
||||
Date: January 2016
|
||||
Contact: "Chao Yu" <chao2.yu@samsung.com>
|
||||
Description:
|
||||
Controls dirty nat entries ratio threshold, if current
|
||||
ratio exceeds configured threshold, checkpoint will
|
||||
be triggered for flushing dirty nat entries.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/lifetime_write_kbytes
|
||||
Date: January 2016
|
||||
Contact: "Shuoran Liu" <liushuoran@huawei.com>
|
||||
Description:
|
||||
Shows total written kbytes issued to disk.
|
||||
|
18
Documentation/ABI/testing/sysfs-platform-i2c-demux-pinctrl
Normal file
18
Documentation/ABI/testing/sysfs-platform-i2c-demux-pinctrl
Normal 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'.
|
@ -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.
|
||||
|
@ -1816,7 +1816,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||
<td valign="top" >Description/Restrictions</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="37" valign="top" >DRM</td>
|
||||
<td rowspan="42" valign="top" >DRM</td>
|
||||
<td valign="top" >Generic</td>
|
||||
<td valign="top" >“rotation”</td>
|
||||
<td valign="top" >BITMASK</td>
|
||||
@ -2068,7 +2068,7 @@ void intel_crt_init(struct drm_device *dev)
|
||||
<td valign="top" >property to suggest an Y offset for a connector</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="3" valign="top" >Optional</td>
|
||||
<td rowspan="8" valign="top" >Optional</td>
|
||||
<td valign="top" >“scaling mode”</td>
|
||||
<td valign="top" >ENUM</td>
|
||||
<td valign="top" >{ "None", "Full", "Center", "Full aspect" }</td>
|
||||
@ -2092,6 +2092,61 @@ void intel_crt_init(struct drm_device *dev)
|
||||
<td valign="top" >TBD</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“DEGAMMA_LUT”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the degamma lookup table
|
||||
(LUT) mapping pixel data from the framebuffer before it is
|
||||
given to the transformation matrix. The data is an interpreted
|
||||
as an array of struct drm_color_lut elements. Hardware might
|
||||
choose not to use the full precision of the LUT elements nor
|
||||
use all the elements of the LUT (for example the hardware
|
||||
might choose to interpolate between LUT[0] and LUT[4]). </td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“DEGAMMA_LUT_SIZE”</td>
|
||||
<td valign="top" >RANGE | IMMUTABLE</td>
|
||||
<td valign="top" >Min=0, Max=UINT_MAX</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to gives the size of the lookup
|
||||
table to be set on the DEGAMMA_LUT property (the size depends
|
||||
on the underlying hardware).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“CTM”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the current
|
||||
transformation matrix (CTM) apply to pixel data after the
|
||||
lookup through the degamma LUT and before the lookup through
|
||||
the gamma LUT. The data is an interpreted as a struct
|
||||
drm_color_ctm.</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“GAMMA_LUT”</td>
|
||||
<td valign="top" >BLOB</td>
|
||||
<td valign="top" >0</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to set the gamma lookup table
|
||||
(LUT) mapping pixel data after to the transformation matrix to
|
||||
data sent to the connector. The data is an interpreted as an
|
||||
array of struct drm_color_lut elements. Hardware might choose
|
||||
not to use the full precision of the LUT elements nor use all
|
||||
the elements of the LUT (for example the hardware might choose
|
||||
to interpolate between LUT[0] and LUT[4]).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td valign="top" >“GAMMA_LUT_SIZE”</td>
|
||||
<td valign="top" >RANGE | IMMUTABLE</td>
|
||||
<td valign="top" >Min=0, Max=UINT_MAX</td>
|
||||
<td valign="top" >CRTC</td>
|
||||
<td valign="top" >DRM property to gives the size of the lookup
|
||||
table to be set on the GAMMA_LUT property (the size depends on
|
||||
the underlying hardware).</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td rowspan="20" valign="top" >i915</td>
|
||||
<td rowspan="2" valign="top" >Generic</td>
|
||||
<td valign="top" >"Broadcast RGB"</td>
|
||||
@ -2886,52 +2941,8 @@ void (*postclose) (struct drm_device *, struct drm_file *);</synopsis>
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>File Operations</title>
|
||||
<synopsis>const struct file_operations *fops</synopsis>
|
||||
<abstract>File operations for the DRM device node.</abstract>
|
||||
<para>
|
||||
Drivers must define the file operations structure that forms the DRM
|
||||
userspace API entry point, even though most of those operations are
|
||||
implemented in the DRM core. The <methodname>open</methodname>,
|
||||
<methodname>release</methodname> and <methodname>ioctl</methodname>
|
||||
operations are handled by
|
||||
<programlisting>
|
||||
.owner = THIS_MODULE,
|
||||
.open = drm_open,
|
||||
.release = drm_release,
|
||||
.unlocked_ioctl = drm_ioctl,
|
||||
#ifdef CONFIG_COMPAT
|
||||
.compat_ioctl = drm_compat_ioctl,
|
||||
#endif
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
Drivers that implement private ioctls that requires 32/64bit
|
||||
compatibility support must provide their own
|
||||
<methodname>compat_ioctl</methodname> handler that processes private
|
||||
ioctls and calls <function>drm_compat_ioctl</function> for core ioctls.
|
||||
</para>
|
||||
<para>
|
||||
The <methodname>read</methodname> and <methodname>poll</methodname>
|
||||
operations provide support for reading DRM events and polling them. They
|
||||
are implemented by
|
||||
<programlisting>
|
||||
.poll = drm_poll,
|
||||
.read = drm_read,
|
||||
.llseek = no_llseek,
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
The memory mapping implementation varies depending on how the driver
|
||||
manages memory. Pre-GEM drivers will use <function>drm_mmap</function>,
|
||||
while GEM-aware drivers will use <function>drm_gem_mmap</function>. See
|
||||
<xref linkend="drm-gem"/>.
|
||||
<programlisting>
|
||||
.mmap = drm_gem_mmap,
|
||||
</programlisting>
|
||||
</para>
|
||||
<para>
|
||||
No other file operation is supported by the DRM API.
|
||||
</para>
|
||||
!Pdrivers/gpu/drm/drm_fops.c file operations
|
||||
!Edrivers/gpu/drm/drm_fops.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>IOCTLs</title>
|
||||
@ -3319,6 +3330,12 @@ int num_ioctls;</synopsis>
|
||||
!Pdrivers/gpu/drm/i915/intel_csr.c csr support for dmc
|
||||
!Idrivers/gpu/drm/i915/intel_csr.c
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Video BIOS Table (VBT)</title>
|
||||
!Pdrivers/gpu/drm/i915/intel_bios.c Video BIOS Table (VBT)
|
||||
!Idrivers/gpu/drm/i915/intel_bios.c
|
||||
!Idrivers/gpu/drm/i915/intel_bios.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
|
||||
<sect1>
|
||||
@ -3460,6 +3477,7 @@ int num_ioctls;</synopsis>
|
||||
</sect1>
|
||||
<sect1>
|
||||
<title>Public constants</title>
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_handler_flags_t
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_client_id
|
||||
!Finclude/linux/vga_switcheroo.h vga_switcheroo_state
|
||||
</sect1>
|
||||
@ -3488,6 +3506,10 @@ int num_ioctls;</synopsis>
|
||||
<title>Backlight control</title>
|
||||
!Pdrivers/platform/x86/apple-gmux.c Backlight control
|
||||
</sect2>
|
||||
<sect2>
|
||||
<title>Public functions</title>
|
||||
!Iinclude/linux/apple-gmux.h
|
||||
</sect2>
|
||||
</sect1>
|
||||
</chapter>
|
||||
|
||||
|
@ -22,7 +22,7 @@ Orion family
|
||||
88F5281
|
||||
Datasheet : http://www.ocmodshop.com/images/reviews/networking/qnap_ts409u/marvel_88f5281_data_sheet.pdf
|
||||
88F6183
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr331 (88f51xx) or 88fr531-vd (88f52xx) ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-orion5x
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
|
||||
@ -52,7 +52,7 @@ Kirkwood family
|
||||
Hardware Spec : http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
Homepage: http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr131 ARMv5 compatible
|
||||
Linux kernel mach directory: arch/arm/mach-mvebu
|
||||
Linux kernel plat directory: none
|
||||
|
||||
@ -71,7 +71,7 @@ Discovery family
|
||||
MV76100
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Core: Feroceon ARMv5 compatible
|
||||
Core: Feroceon 88fr571-vd ARMv5 compatible
|
||||
|
||||
Linux kernel mach directory: arch/arm/mach-mv78xx0
|
||||
Linux kernel plat directory: arch/arm/plat-orion
|
||||
@ -86,20 +86,26 @@ EBU Armada family
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/Marvell_ARMADA_370_SoC.pdf
|
||||
Hardware Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-datasheet.pdf
|
||||
Functional Spec: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA370-FunctionalSpec-datasheet.pdf
|
||||
Core: Sheeva ARMv7 compatible PJ4B
|
||||
|
||||
Armada 375 Flavors:
|
||||
88F6720
|
||||
Product Brief: http://www.marvell.com/embedded-processors/armada-300/assets/ARMADA_375_SoC-01_product_brief.pdf
|
||||
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
|
||||
---------------
|
||||
|
||||
|
@ -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
|
||||
|
@ -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
|
@ -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.
|
||||
|
@ -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:
|
||||
=========
|
||||
|
@ -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>
|
||||
|
||||
|
@ -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.
|
||||
|
||||
|
@ -13,8 +13,15 @@ Boards with the Amlogic Meson8b SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson8b";
|
||||
|
||||
Boards with the Amlogic Meson GXBaby SoC shall have the following properties:
|
||||
Required root node property:
|
||||
compatible: "amlogic,meson-gxbb";
|
||||
|
||||
Board compatible values:
|
||||
- "geniatech,atv1200" (Meson6)
|
||||
- "minix,neo-x8" (Meson8)
|
||||
- "tronfy,mxq" (Meson8b)
|
||||
- "hardkernel,odroid-c1" (Meson8b)
|
||||
- "tronsmart,vega-s95-pro", "tronsmart,vega-s95" (Meson gxbb)
|
||||
- "tronsmart,vega-s95-meta", "tronsmart,vega-s95" (Meson gxbb)
|
||||
- "tronsmart,vega-s95-telos", "tronsmart,vega-s95" (Meson gxbb)
|
||||
|
@ -123,7 +123,9 @@ Required nodes:
|
||||
|
||||
- syscon: some subnode of the RealView SoC node must be a
|
||||
system controller node pointing to the control registers,
|
||||
with the compatible string set to one of these tuples:
|
||||
with the compatible string set to one of these:
|
||||
"arm,realview-eb11mp-revb-syscon", "arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-eb11mp-revc-syscon", "arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-eb-syscon", "syscon"
|
||||
"arm,realview-pb1176-syscon", "syscon"
|
||||
"arm,realview-pb11mp-syscon", "syscon"
|
||||
@ -180,6 +182,7 @@ described under the RS1 memory mapping.
|
||||
Required properties (in root node):
|
||||
compatible = "arm,juno"; /* For Juno r0 board */
|
||||
compatible = "arm,juno-r1"; /* For Juno r1 board */
|
||||
compatible = "arm,juno-r2"; /* For Juno r2 board */
|
||||
|
||||
Required nodes:
|
||||
The description for the board must include:
|
||||
|
29
Documentation/devicetree/bindings/arm/axis.txt
Normal file
29
Documentation/devicetree/bindings/arm/axis.txt
Normal 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";
|
@ -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";
|
@ -34,6 +34,7 @@ specific to ARM.
|
||||
Definition: must contain one of the following:
|
||||
"arm,cci-400"
|
||||
"arm,cci-500"
|
||||
"arm,cci-550"
|
||||
|
||||
- reg
|
||||
Usage: required
|
||||
@ -101,6 +102,7 @@ specific to ARM.
|
||||
"arm,cci-400-pmu" - DEPRECATED, permitted only where OS has
|
||||
secure acces to CCI registers
|
||||
"arm,cci-500-pmu,r0"
|
||||
"arm,cci-550-pmu,r0"
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: Integer cells. A register entry, expressed
|
||||
|
@ -167,6 +167,7 @@ nodes to be present and contain the properties described below.
|
||||
"arm,cortex-r5"
|
||||
"arm,cortex-r7"
|
||||
"brcm,brahma-b15"
|
||||
"brcm,vulcan"
|
||||
"cavium,thunder"
|
||||
"faraday,fa526"
|
||||
"intel,sa110"
|
||||
@ -178,6 +179,7 @@ nodes to be present and contain the properties described below.
|
||||
"marvell,sheeva-v5"
|
||||
"nvidia,tegra132-denver"
|
||||
"qcom,krait"
|
||||
"qcom,kryo"
|
||||
"qcom,scorpion"
|
||||
- enable-method
|
||||
Value type: <stringlist>
|
||||
@ -250,7 +252,7 @@ nodes to be present and contain the properties described below.
|
||||
Usage: optional
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: A u32 value that represents the running time dynamic
|
||||
power coefficient in units of mW/MHz/uVolt^2. The
|
||||
power coefficient in units of mW/MHz/uV^2. The
|
||||
coefficient can either be calculated from power
|
||||
measurements or derived by analysis.
|
||||
|
||||
|
@ -22,6 +22,8 @@ SoCs:
|
||||
compatible = "ti,k2l", "ti,keystone"
|
||||
- Keystone 2 Edison
|
||||
compatible = "ti,k2e", "ti,keystone"
|
||||
- K2G
|
||||
compatible = "ti,k2g", "ti,keystone"
|
||||
|
||||
Boards:
|
||||
- Keystone 2 Hawking/Kepler EVM
|
||||
@ -32,3 +34,6 @@ Boards:
|
||||
|
||||
- Keystone 2 Edison EVM
|
||||
compatible = "ti,k2e-evm", "ti,k2e", "ti,keystone"
|
||||
|
||||
- K2G EVM
|
||||
compatible = "ti,k2g-evm", "ti,k2g", "ti-keystone"
|
||||
|
@ -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";
|
@ -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";
|
@ -19,9 +19,12 @@ SoC. Currently known SoC compatibles are:
|
||||
And in addition, the compatible shall be extended with the specific
|
||||
board. Currently known boards are:
|
||||
|
||||
"buffalo,linkstation-lsqvl"
|
||||
"buffalo,linkstation-lsvl"
|
||||
"buffalo,linkstation-lswsxl"
|
||||
"buffalo,linkstation-lswxl"
|
||||
"buffalo,linkstation-lswvl"
|
||||
"buffalo,lschlv2"
|
||||
"buffalo,lswvl"
|
||||
"buffalo,lswxl"
|
||||
"buffalo,lsxhl"
|
||||
"buffalo,lsxl"
|
||||
"cloudengines,pogo02"
|
@ -11,6 +11,7 @@ compatible: Must contain one of
|
||||
"mediatek,mt6589"
|
||||
"mediatek,mt6592"
|
||||
"mediatek,mt6795"
|
||||
"mediatek,mt7623"
|
||||
"mediatek,mt8127"
|
||||
"mediatek,mt8135"
|
||||
"mediatek,mt8173"
|
||||
@ -33,6 +34,9 @@ Supported boards:
|
||||
- Evaluation board for MT6795(Helio X10):
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt6795-evb", "mediatek,mt6795";
|
||||
- Evaluation board for MT7623:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt7623-evb", "mediatek,mt7623";
|
||||
- MTK mt8127 tablet moose EVB:
|
||||
Required root node properties:
|
||||
- compatible = "mediatek,mt8127-moose", "mediatek,mt8127";
|
||||
|
@ -155,7 +155,7 @@ Boards:
|
||||
compatible = "compulab,am437x-sbc-t43", "compulab,am437x-cm-t43", "ti,am4372", "ti,am43"
|
||||
|
||||
- AM43x EPOS EVM
|
||||
compatible = "ti,am43x-epos-evm", "ti,am4372", "ti,am43"
|
||||
compatible = "ti,am43x-epos-evm", "ti,am43", "ti,am438x"
|
||||
|
||||
- AM437x GP EVM
|
||||
compatible = "ti,am437x-gp-evm", "ti,am4372", "ti,am43"
|
||||
|
@ -25,6 +25,7 @@ Required properties:
|
||||
"qcom,scorpion-pmu"
|
||||
"qcom,scorpion-mp-pmu"
|
||||
"qcom,krait-pmu"
|
||||
"cavium,thunder-pmu"
|
||||
- interrupts : 1 combined interrupt or 1 per core. If the interrupt is a per-cpu
|
||||
interrupt (PPI) then 1 interrupt should be specified.
|
||||
|
||||
@ -46,6 +47,16 @@ Optional properties:
|
||||
- qcom,no-pc-write : Indicates that this PMU doesn't support the 0xc and 0xd
|
||||
events.
|
||||
|
||||
- secure-reg-access : Indicates that the ARMv7 Secure Debug Enable Register
|
||||
(SDER) is accessible. This will cause the driver to do
|
||||
any setup required that is only possible in ARMv7 secure
|
||||
state. If not present the ARMv7 SDER will not be touched,
|
||||
which means the PMU may fail to operate unless external
|
||||
code (bootloader or security monitor) has performed the
|
||||
appropriate initialisation. Note that this property is
|
||||
not valid for non-ARMv7 CPUs or ARMv7 CPUs booting Linux
|
||||
in Non-secure state.
|
||||
|
||||
Example:
|
||||
|
||||
pmu {
|
||||
|
51
Documentation/devicetree/bindings/arm/qcom.txt
Normal file
51
Documentation/devicetree/bindings/arm/qcom.txt
Normal 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.
|
@ -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
|
||||
|
@ -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"
|
||||
|
@ -46,6 +46,9 @@ Timing properties for child nodes. All are optional and default to 0.
|
||||
- gpmc,adv-on-ns: Assertion time
|
||||
- gpmc,adv-rd-off-ns: Read deassertion time
|
||||
- gpmc,adv-wr-off-ns: Write deassertion time
|
||||
- gpmc,adv-aad-mux-on-ns: Assertion time for AAD
|
||||
- gpmc,adv-aad-mux-rd-off-ns: Read deassertion time for AAD
|
||||
- gpmc,adv-aad-mux-wr-off-ns: Write deassertion time for AAD
|
||||
|
||||
WE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
|
||||
- gpmc,we-on-ns Assertion time
|
||||
@ -54,6 +57,8 @@ Timing properties for child nodes. All are optional and default to 0.
|
||||
OE signals timings (in nanoseconds) corresponding to GPMC_CONFIG4:
|
||||
- gpmc,oe-on-ns: Assertion time
|
||||
- gpmc,oe-off-ns: Deassertion time
|
||||
- gpmc,oe-aad-mux-on-ns: Assertion time for AAD
|
||||
- gpmc,oe-aad-mux-off-ns: Deassertion time for AAD
|
||||
|
||||
Access time and cycle time timings (in nanoseconds) corresponding to
|
||||
GPMC_CONFIG5:
|
||||
|
@ -8,7 +8,10 @@ Required properties:
|
||||
- compatible : shall be "adi,axi-clkgen-1.00.a" or "adi,axi-clkgen-2.00.a".
|
||||
- #clock-cells : from common clock binding; Should always be set to 0.
|
||||
- reg : Address and length of the axi-clkgen register set.
|
||||
- clocks : Phandle and clock specifier for the parent clock.
|
||||
- clocks : Phandle and clock specifier for the parent clock(s). This must
|
||||
either reference one clock if only the first clock input is connected or two
|
||||
if both clock inputs are connected. For the later case the clock connected
|
||||
to the first input must be specified first.
|
||||
|
||||
Optional properties:
|
||||
- clock-output-names : From common clock binding.
|
||||
|
@ -92,6 +92,7 @@ PLL and leaf clock compatible strings for Cygnus are:
|
||||
"brcm,cygnus-lcpll0"
|
||||
"brcm,cygnus-mipipll"
|
||||
"brcm,cygnus-asiu-clk"
|
||||
"brcm,cygnus-audiopll"
|
||||
|
||||
The following table defines the set of PLL/clock index and ID for Cygnus.
|
||||
These clock IDs are defined in:
|
||||
@ -131,6 +132,11 @@ These clock IDs are defined in:
|
||||
ch4_unused mipipll 5 BCM_CYGNUS_MIPIPLL_CH4_UNUSED
|
||||
ch5_unused mipipll 6 BCM_CYGNUS_MIPIPLL_CH5_UNUSED
|
||||
|
||||
audiopll crystal 0 BCM_CYGNUS_AUDIOPLL
|
||||
ch0_audio audiopll 1 BCM_CYGNUS_AUDIOPLL_CH0
|
||||
ch1_audio audiopll 2 BCM_CYGNUS_AUDIOPLL_CH1
|
||||
ch2_audio audiopll 3 BCM_CYGNUS_AUDIOPLL_CH2
|
||||
|
||||
Northstar and Northstar Plus
|
||||
------
|
||||
PLL and leaf clock compatible strings for Northstar and Northstar Plus are:
|
||||
|
52
Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
Normal file
52
Documentation/devicetree/bindings/clock/lpc1850-creg-clk.txt
Normal 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";
|
||||
...
|
||||
};
|
||||
};
|
@ -3,7 +3,7 @@ Binding for Qualcomm Atheros AR7xxx/AR9XXX PLL controller
|
||||
The PPL controller provides the 3 main clocks of the SoC: CPU, DDR and AHB.
|
||||
|
||||
Required Properties:
|
||||
- compatible: has to be "qca,<soctype>-cpu-intc" and one of the following
|
||||
- compatible: has to be "qca,<soctype>-pll" and one of the following
|
||||
fallbacks:
|
||||
- "qca,ar7100-pll"
|
||||
- "qca,ar7240-pll"
|
||||
@ -21,8 +21,8 @@ Optional properties:
|
||||
|
||||
Example:
|
||||
|
||||
memory-controller@18050000 {
|
||||
compatible = "qca,ar9132-ppl", "qca,ar9130-pll";
|
||||
pll-controller@18050000 {
|
||||
compatible = "qca,ar9132-pll", "qca,ar9130-pll";
|
||||
reg = <0x18050000 0x20>;
|
||||
|
||||
clock-names = "ref";
|
||||
|
@ -7,6 +7,7 @@ Required properties :
|
||||
"qcom,gcc-apq8064"
|
||||
"qcom,gcc-apq8084"
|
||||
"qcom,gcc-ipq8064"
|
||||
"qcom,gcc-ipq4019"
|
||||
"qcom,gcc-msm8660"
|
||||
"qcom,gcc-msm8916"
|
||||
"qcom,gcc-msm8960"
|
||||
|
@ -61,7 +61,7 @@ Examples
|
||||
reg = <0 0xe6e88000 0 64>;
|
||||
interrupts = <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&cpg CPG_MOD 310>;
|
||||
clock-names = "sci_ick";
|
||||
clock-names = "fck";
|
||||
dmas = <&dmac1 0x13>, <&dmac1 0x12>;
|
||||
dma-names = "tx", "rx";
|
||||
power-domains = <&cpg>;
|
||||
|
@ -18,6 +18,7 @@ Required properties:
|
||||
"allwinner,sun4i-a10-cpu-clk" - for the CPU multiplexer clock
|
||||
"allwinner,sun4i-a10-axi-clk" - for the AXI clock
|
||||
"allwinner,sun8i-a23-axi-clk" - for the AXI clock on A23
|
||||
"allwinner,sun4i-a10-gates-clk" - for generic gates on all compatible SoCs
|
||||
"allwinner,sun4i-a10-axi-gates-clk" - for the AXI gates
|
||||
"allwinner,sun4i-a10-ahb-clk" - for the AHB clock
|
||||
"allwinner,sun5i-a13-ahb-clk" - for the AHB clock on A13
|
||||
@ -39,12 +40,14 @@ Required properties:
|
||||
"allwinner,sun6i-a31-apb0-clk" - for the APB0 clock on A31
|
||||
"allwinner,sun8i-a23-apb0-clk" - for the APB0 clock on A23
|
||||
"allwinner,sun9i-a80-apb0-clk" - for the APB0 bus clock on A80
|
||||
"allwinner,sun8i-a83t-apb0-gates-clk" - for the APB0 gates on A83T
|
||||
"allwinner,sun4i-a10-apb0-gates-clk" - for the APB0 gates on A10
|
||||
"allwinner,sun5i-a13-apb0-gates-clk" - for the APB0 gates on A13
|
||||
"allwinner,sun5i-a10s-apb0-gates-clk" - for the APB0 gates on A10s
|
||||
"allwinner,sun6i-a31-apb0-gates-clk" - for the APB0 gates on A31
|
||||
"allwinner,sun7i-a20-apb0-gates-clk" - for the APB0 gates on A20
|
||||
"allwinner,sun8i-a23-apb0-gates-clk" - for the APB0 gates on A23
|
||||
"allwinner,sun8i-h3-apb0-gates-clk" - for the APB0 gates on H3
|
||||
"allwinner,sun9i-a80-apb0-gates-clk" - for the APB0 gates on A80
|
||||
"allwinner,sun4i-a10-apb1-clk" - for the APB1 clock
|
||||
"allwinner,sun9i-a80-apb1-clk" - for the APB1 bus clock on A80
|
||||
@ -57,6 +60,7 @@ Required properties:
|
||||
"allwinner,sun9i-a80-apb1-gates-clk" - for the APB1 gates on A80
|
||||
"allwinner,sun6i-a31-apb2-gates-clk" - for the APB2 gates on A31
|
||||
"allwinner,sun8i-a23-apb2-gates-clk" - for the APB2 gates on A23
|
||||
"allwinner,sun8i-a83t-bus-gates-clk" - for the bus gates on A83T
|
||||
"allwinner,sun8i-h3-bus-gates-clk" - for the bus gates on H3
|
||||
"allwinner,sun9i-a80-apbs-gates-clk" - for the APBS gates on A80
|
||||
"allwinner,sun4i-a10-dram-gates-clk" - for the DRAM gates on A10
|
||||
|
41
Documentation/devicetree/bindings/clock/ti/adpll.txt
Normal file
41
Documentation/devicetree/bindings/clock/ti/adpll.txt
Normal 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";
|
||||
};
|
@ -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.
|
||||
|
79
Documentation/devicetree/bindings/display/arm,hdlcd.txt
Normal file
79
Documentation/devicetree/bindings/display/arm,hdlcd.txt
Normal 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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
};
|
@ -35,6 +35,12 @@ Optional properties for HDMI:
|
||||
as an interrupt/status bit in the HDMI controller
|
||||
itself). See bindings/pinctrl/brcm,bcm2835-gpio.txt
|
||||
|
||||
Required properties for V3D:
|
||||
- compatible: Should be "brcm,bcm2835-v3d"
|
||||
- reg: Physical base address and length of the V3D's registers
|
||||
- interrupts: The interrupt number
|
||||
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
|
||||
|
||||
Example:
|
||||
pixelvalve@7e807000 {
|
||||
compatible = "brcm,bcm2835-pixelvalve2";
|
||||
@ -60,6 +66,12 @@ hdmi: hdmi@7e902000 {
|
||||
clock-names = "pixel", "hdmi";
|
||||
};
|
||||
|
||||
v3d: v3d@7ec00000 {
|
||||
compatible = "brcm,bcm2835-v3d";
|
||||
reg = <0x7ec00000 0x1000>;
|
||||
interrupts = <1 10>;
|
||||
};
|
||||
|
||||
vc4: gpu {
|
||||
compatible = "brcm,bcm2835-vc4";
|
||||
};
|
||||
|
@ -6,6 +6,7 @@ Required properties:
|
||||
"samsung,exynos4210-mipi-dsi" /* for Exynos4 SoCs */
|
||||
"samsung,exynos4415-mipi-dsi" /* for Exynos4415 SoC */
|
||||
"samsung,exynos5410-mipi-dsi" /* for Exynos5410/5420/5440 SoCs */
|
||||
"samsung,exynos5422-mipi-dsi" /* for Exynos5422/5800 SoCs */
|
||||
"samsung,exynos5433-mipi-dsi" /* for Exynos5433 SoCs */
|
||||
- reg: physical base address and length of the registers set for the device
|
||||
- interrupts: should contain DSI interrupt
|
||||
|
@ -12,7 +12,8 @@ Required properties:
|
||||
"samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */
|
||||
"samsung,exynos4210-fimd"; /* for Exynos4 SoCs */
|
||||
"samsung,exynos4415-fimd"; /* for Exynos4415 SoC */
|
||||
"samsung,exynos5250-fimd"; /* for Exynos5 SoCs */
|
||||
"samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */
|
||||
"samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */
|
||||
|
||||
- reg: physical base address and length of the FIMD registers set.
|
||||
|
||||
|
@ -44,9 +44,34 @@ Optional properties:
|
||||
- pinctrl-names: the pin control state names; should contain "default"
|
||||
- pinctrl-0: the default pinctrl state (active)
|
||||
- pinctrl-n: the "sleep" pinctrl state
|
||||
- port: DSI controller output port. This contains one endpoint subnode, with its
|
||||
remote-endpoint set to the phandle of the connected panel's endpoint.
|
||||
See Documentation/devicetree/bindings/graph.txt for device graph info.
|
||||
- port: DSI controller output port, containing one endpoint subnode.
|
||||
|
||||
DSI Endpoint properties:
|
||||
- remote-endpoint: set to phandle of the connected panel's endpoint.
|
||||
See Documentation/devicetree/bindings/graph.txt for device graph info.
|
||||
- qcom,data-lane-map: this describes how the logical DSI lanes are mapped
|
||||
to the physical lanes on the given platform. The value contained in
|
||||
index n describes what logical data lane is mapped to the physical data
|
||||
lane n (DATAn, where n lies between 0 and 3).
|
||||
|
||||
For example:
|
||||
|
||||
qcom,data-lane-map = <3 0 1 2>;
|
||||
|
||||
The above mapping describes that the logical data lane DATA3 is mapped to
|
||||
the physical data lane DATA0, logical DATA0 to physical DATA1, logic DATA1
|
||||
to phys DATA2 and logic DATA2 to phys DATA3.
|
||||
|
||||
There are only a limited number of physical to logical mappings possible:
|
||||
|
||||
"0123": Logic 0->Phys 0; Logic 1->Phys 1; Logic 2->Phys 2; Logic 3->Phys 3;
|
||||
"3012": Logic 3->Phys 0; Logic 0->Phys 1; Logic 1->Phys 2; Logic 2->Phys 3;
|
||||
"2301": Logic 2->Phys 0; Logic 3->Phys 1; Logic 0->Phys 2; Logic 1->Phys 3;
|
||||
"1230": Logic 1->Phys 0; Logic 2->Phys 1; Logic 3->Phys 2; Logic 0->Phys 3;
|
||||
"0321": Logic 0->Phys 0; Logic 3->Phys 1; Logic 2->Phys 2; Logic 1->Phys 3;
|
||||
"1032": Logic 1->Phys 0; Logic 0->Phys 1; Logic 3->Phys 2; Logic 2->Phys 3;
|
||||
"2103": Logic 2->Phys 0; Logic 1->Phys 1; Logic 0->Phys 2; Logic 3->Phys 3;
|
||||
"3210": Logic 3->Phys 0; Logic 2->Phys 1; Logic 1->Phys 2; Logic 0->Phys 3;
|
||||
|
||||
DSI PHY:
|
||||
Required properties:
|
||||
@ -131,6 +156,7 @@ Example:
|
||||
port {
|
||||
dsi0_out: endpoint {
|
||||
remote-endpoint = <&panel_in>;
|
||||
lanes = <0 1 2 3>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
@ -11,6 +11,7 @@ Required properties:
|
||||
- reg: Physical base address and length of the controller's registers
|
||||
- reg-names: "core_physical"
|
||||
- interrupts: The interrupt signal from the hdmi block.
|
||||
- power-domains: Should be <&mmcc MDSS_GDSC>.
|
||||
- clocks: device clocks
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- qcom,hdmi-tx-ddc-clk-gpio: ddc clk pin
|
||||
@ -18,6 +19,8 @@ Required properties:
|
||||
- qcom,hdmi-tx-hpd-gpio: hpd pin
|
||||
- core-vdda-supply: phandle to supply regulator
|
||||
- hdmi-mux-supply: phandle to mux regulator
|
||||
- phys: the phandle for the HDMI PHY device
|
||||
- phy-names: the name of the corresponding PHY device
|
||||
|
||||
Optional properties:
|
||||
- qcom,hdmi-tx-mux-en-gpio: hdmi mux enable pin
|
||||
@ -27,15 +30,38 @@ Optional properties:
|
||||
- pinctrl-0: the default pinctrl state (active)
|
||||
- pinctrl-1: the "sleep" pinctrl state
|
||||
|
||||
HDMI PHY:
|
||||
Required properties:
|
||||
- compatible: Could be the following
|
||||
* "qcom,hdmi-phy-8660"
|
||||
* "qcom,hdmi-phy-8960"
|
||||
* "qcom,hdmi-phy-8974"
|
||||
* "qcom,hdmi-phy-8084"
|
||||
* "qcom,hdmi-phy-8996"
|
||||
- #phy-cells: Number of cells in a PHY specifier; Should be 0.
|
||||
- reg: Physical base address and length of the registers of the PHY sub blocks.
|
||||
- reg-names: The names of register regions. The following regions are required:
|
||||
* "hdmi_phy"
|
||||
* "hdmi_pll"
|
||||
For HDMI PHY on msm8996, these additional register regions are required:
|
||||
* "hdmi_tx_l0"
|
||||
* "hdmi_tx_l1"
|
||||
* "hdmi_tx_l3"
|
||||
* "hdmi_tx_l4"
|
||||
- power-domains: Should be <&mmcc MDSS_GDSC>.
|
||||
- clocks: device clocks
|
||||
See Documentation/devicetree/bindings/clocks/clock-bindings.txt for details.
|
||||
- core-vdda-supply: phandle to vdda regulator device node
|
||||
|
||||
Example:
|
||||
|
||||
/ {
|
||||
...
|
||||
|
||||
hdmi: qcom,hdmi-tx-8960@4a00000 {
|
||||
hdmi: hdmi@4a00000 {
|
||||
compatible = "qcom,hdmi-tx-8960";
|
||||
reg-names = "core_physical";
|
||||
reg = <0x04a00000 0x1000>;
|
||||
reg = <0x04a00000 0x2f0>;
|
||||
interrupts = <GIC_SPI 79 0>;
|
||||
power-domains = <&mmcc MDSS_GDSC>;
|
||||
clock-names =
|
||||
@ -54,5 +80,21 @@ Example:
|
||||
pinctrl-names = "default", "sleep";
|
||||
pinctrl-0 = <&hpd_active &ddc_active &cec_active>;
|
||||
pinctrl-1 = <&hpd_suspend &ddc_suspend &cec_suspend>;
|
||||
|
||||
phys = <&hdmi_phy>;
|
||||
phy-names = "hdmi_phy";
|
||||
};
|
||||
|
||||
hdmi_phy: phy@4a00400 {
|
||||
compatible = "qcom,hdmi-phy-8960";
|
||||
reg-names = "hdmi_phy",
|
||||
"hdmi_pll";
|
||||
reg = <0x4a00400 0x60>,
|
||||
<0x4a00500 0x100>;
|
||||
#phy-cells = <0>;
|
||||
power-domains = <&mmcc MDSS_GDSC>;
|
||||
clock-names = "slave_iface_clk";
|
||||
clocks = <&mmcc HDMI_S_AHB_CLK>;
|
||||
core-vdda-supply = <&pm8921_hdmi_mvs>;
|
||||
};
|
||||
};
|
||||
|
@ -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.
|
@ -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.
|
@ -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
|
||||
|
@ -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>;
|
||||
};
|
||||
};
|
||||
|
||||
};
|
@ -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.
|
||||
|
17
Documentation/devicetree/bindings/goldfish/audio.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/audio.txt
Normal 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>;
|
||||
};
|
17
Documentation/devicetree/bindings/goldfish/events.txt
Normal file
17
Documentation/devicetree/bindings/goldfish/events.txt
Normal 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>;
|
||||
};
|
135
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
Normal file
135
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt
Normal 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.
|
@ -11,7 +11,7 @@ Required properties:
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
The absence of the property indicates the default frequency 100 kHz.
|
||||
- dmas: A list of two dma specifiers, one for each entry in dma-names.
|
||||
- dma-names: should contain "tx" and "rx".
|
||||
- scl-gpios: specify the gpio related to SCL pin
|
||||
|
@ -17,7 +17,7 @@ Required properties:
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this
|
||||
propoerty indicates the default frequency 100 kHz.
|
||||
property indicates the default frequency 100 kHz.
|
||||
- clocks: clock specifier.
|
||||
|
||||
- i2c-scl-falling-time-ns: see i2c.txt
|
||||
|
@ -8,7 +8,7 @@ Required properties :
|
||||
|
||||
Optional properties:
|
||||
- clock-frequency : Constains desired I2C/HS-I2C bus clock frequency in Hz.
|
||||
The absence of the propoerty indicates the default frequency 100 kHz.
|
||||
The absence of the property indicates the default frequency 100 kHz.
|
||||
|
||||
Examples :
|
||||
|
||||
|
@ -6,14 +6,17 @@ Required properties:
|
||||
- interrupts : IIC controller unterrupt
|
||||
- #address-cells = <1>
|
||||
- #size-cells = <0>
|
||||
- clocks: Input clock specifier. Refer to common clock bindings.
|
||||
|
||||
Optional properties:
|
||||
- Child nodes conforming to i2c bus binding
|
||||
- clock-names: Input clock name, should be 'pclk'.
|
||||
|
||||
Example:
|
||||
|
||||
axi_iic_0: i2c@40800000 {
|
||||
compatible = "xlnx,xps-iic-2.00.a";
|
||||
clocks = <&clkc 15>;
|
||||
interrupts = < 1 2 >;
|
||||
reg = < 0x40800000 0x10000 >;
|
||||
|
||||
|
@ -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"
|
||||
|
@ -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>;
|
||||
}
|
58
Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
Normal file
58
Documentation/devicetree/bindings/iio/adc/fsl,imx25-gcq.txt
Normal 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>;
|
||||
};
|
||||
};
|
@ -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"
|
||||
|
19
Documentation/devicetree/bindings/iio/adc/ti-adc0832.txt
Normal file
19
Documentation/devicetree/bindings/iio/adc/ti-adc0832.txt
Normal 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>;
|
||||
};
|
@ -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>;
|
||||
};
|
20
Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
Normal file
20
Documentation/devicetree/bindings/iio/dac/vf610-dac.txt
Normal 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>;
|
||||
};
|
34
Documentation/devicetree/bindings/iio/health/afe4403.txt
Normal file
34
Documentation/devicetree/bindings/iio/health/afe4403.txt
Normal 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>;
|
||||
};
|
||||
};
|
30
Documentation/devicetree/bindings/iio/health/afe4404.txt
Normal file
30
Documentation/devicetree/bindings/iio/health/afe4404.txt
Normal 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>;
|
||||
};
|
||||
};
|
@ -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>;
|
||||
};
|
||||
|
26
Documentation/devicetree/bindings/iio/light/opt3001.txt
Normal file
26
Documentation/devicetree/bindings/iio/light/opt3001.txt
Normal 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>;
|
||||
};
|
@ -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
|
||||
|
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
39
Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
Normal file
39
Documentation/devicetree/bindings/input/rmi4/rmi_f01.txt
Normal 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>;
|
||||
};
|
||||
};
|
||||
};
|
53
Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
Normal file
53
Documentation/devicetree/bindings/input/rmi4/rmi_i2c.txt
Normal 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>;
|
||||
};
|
||||
};
|
||||
};
|
57
Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
Normal file
57
Documentation/devicetree/bindings/input/rmi4/rmi_spi.txt
Normal 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
Loading…
x
Reference in New Issue
Block a user