tmakin/ack-tegra
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge commit df8ba5f160 ("Merge tag 'kgdb-5.14-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/danielt/linux") into android-mainline

Browse Source 
A large step en route to v5.14-rc1

Change-Id: I52bb71dc737044a593d1a9dfd7fe02b31e273ff9
Signed-off-by: Lee Jones <lee.jones@linaro.org>
This commit is contained in:
Lee Jones
2021-07-12 10:59:27 +01:00
parent 8e658623d4 df8ba5f160
commit 293f275f4d
5603 changed files with 553816 additions and 134141 deletions
Download Patch File Download Diff File Expand all files Collapse all files
Documentation/ABI/obsolete/sysfs-bus-iio
+182
View File
@@ -0,0 +1,182 @@
What: /sys/bus/iio/devices/iio:deviceX/buffer/length
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Number of scans contained by the buffer.
Since Kernel 5.11, multiple buffers are supported.
so, it is better to use, instead:
/sys/bus/iio/devices/iio:deviceX/bufferY/length
What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
Description:
Actually start the buffer capture up. Will start trigger
if first device and appropriate.
Since Kernel 5.11, multiple buffers are supported.
so, it is better to use, instead:
/sys/bus/iio/devices/iio:deviceX/bufferY/enable
What: /sys/bus/iio/devices/iio:deviceX/scan_elements
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Directory containing interfaces for elements that will be
captured for a single triggered sample set in the buffer.
Since kernel 5.11 the scan_elements attributes are merged into
the bufferY directory, to be configurable per buffer.
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
What: /sys/.../iio:deviceX/scan_elements/in_proximity_en
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Scan element control for triggered data capture.
Since kernel 5.11 the scan_elements attributes are merged into
the bufferY directory, to be configurable per buffer.
What: /sys/.../iio:deviceX/scan_elements/in_accel_type
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type
What: /sys/.../iio:deviceX/scan_elements/in_magn_type
What: /sys/.../iio:deviceX/scan_elements/in_incli_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
What: /sys/.../iio:deviceX/scan_elements/in_proximity_type
KernelVersion: 2.6.37
Contact: linux-iio@vger.kernel.org
Description:
Description of the scan element data storage within the buffer
and hence the form in which it is read from user-space.
Form is [be|le]:[s|u]bits/storagebits[>>shift].
be or le specifies big or little endian. s or u specifies if
signed (2's complement) or unsigned. bits is the number of bits
of data and storagebits is the space (after padding) that it
occupies in the buffer. shift if specified, is the shift that
needs to be applied prior to masking out unused bits. Some
devices put their data in the middle of the transferred elements
with additional information on both sides. Note that some
devices will have additional information in the unused bits
so to get a clean value, the bits value must be used to mask
the buffer output value appropriately. The storagebits value
also specifies the data alignment. So s48/64>>2 will be a
signed 48 bit integer stored in a 64 bit location aligned to
a 64 bit boundary. To obtain the clean value, shift right 2
and apply a mask to zero the top 16 bits of the result.
For other storage combinations this attribute will be extended
appropriately.
Since kernel 5.11 the scan_elements attributes are merged into
the bufferY directory, to be configurable per buffer.
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
What: /sys/.../iio:deviceX/scan_elements/in_proximity_index
KernelVersion: 2.6.37
Description:
A single positive integer specifying the position of this
scan element in the buffer. Note these are not dependent on
what is enabled and may not be contiguous. Thus for user-space
to establish the full layout these must be used in conjunction
with all _en attributes to establish which channels are present,
and the relevant _type attributes to establish the data storage
format.
Since kernel 5.11 the scan_elements attributes are merged into
the bufferY directory, to be configurable per buffer.
What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark
KernelVersion: 4.2
Contact: linux-iio@vger.kernel.org
Description:
A single positive integer specifying the maximum number of scan
elements to wait for.
Poll will block until the watermark is reached.
Blocking read will wait until the minimum between the requested
read amount or the low water mark is available.
Non-blocking read will retrieve the available samples from the
buffer even if there are less samples then watermark level. This
allows the application to block on poll with a timeout and read
the available samples after the timeout expires and thus have a
maximum delay guarantee.
Since Kernel 5.11, multiple buffers are supported.
so, it is better to use, instead:
/sys/bus/iio/devices/iio:deviceX/bufferY/watermark
What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available
KernelVersion: 4.16
Contact: linux-iio@vger.kernel.org
Description:
A read-only value indicating the bytes of data available in the
buffer. In the case of an output buffer, this indicates the
amount of empty space available to write data to. In the case of
an input buffer, this indicates the amount of data available for
reading.
Since Kernel 5.11, multiple buffers are supported.
so, it is better to use, instead:
/sys/bus/iio/devices/iio:deviceX/bufferY/data_available
Documentation/ABI/stable/sysfs-class-infiniband
-20
View File
@@ -731,26 +731,6 @@ Description:
is the irq number of "sdma3", and M is irq number of "sdma4" in
the /proc/interrupts file.
sysfs interface for Intel(R) X722 iWARP i40iw driver
----------------------------------------------------
What: /sys/class/infiniband/i40iwX/hw_rev
What: /sys/class/infiniband/i40iwX/hca_type
What: /sys/class/infiniband/i40iwX/board_id
Date: Jan, 2016
KernelVersion: v4.10
Contact: linux-rdma@vger.kernel.org
Description:
=============== ==== ========================
hw_rev: (RO) Hardware revision number
hca_type: (RO) Show HCA type (I40IW)
board_id: (RO) I40IW board ID
=============== ==== ========================
sysfs interface for QLogic qedr NIC Driver
------------------------------------------
Documentation/ABI/stable/sysfs-driver-w1_ds2438
+13
View File
@@ -0,0 +1,13 @@
What: /sys/bus/w1/devices/.../page1
Date: April 2021
Contact: Luiz Sampaio <sampaio.ime@gmail.com>
Description: read the contents of the page1 of the DS2438
see Documentation/w1/slaves/w1_ds2438.rst for detailed information
Users: any user space application which wants to communicate with DS2438
What: /sys/bus/w1/devices/.../offset
Date: April 2021
Contact: Luiz Sampaio <sampaio.ime@gmail.com>
Description: write the contents to the offset register of the DS2438
see Documentation/w1/slaves/w1_ds2438.rst for detailed information
Users: any user space application which wants to communicate with DS2438
Documentation/ABI/testing/configfs-usb-gadget-uac2
+2
View File
@@ -8,6 +8,8 @@ Description:
c_chmask capture channel mask
c_srate capture sampling rate
c_ssize capture sample size (bytes)
c_sync capture synchronization type (async/adaptive)
fb_max maximum extra bandwidth in async mode
p_chmask playback channel mask
p_srate playback sampling rate
p_ssize playback sample size (bytes)
Documentation/ABI/testing/debugfs-driver-habanalabs
+8
View File
@@ -207,6 +207,14 @@ Contact: ogabbay@kernel.org
Description: Sets the PCI power state. Valid values are "1" for D0 and "2"
for D3Hot
What: /sys/kernel/debug/habanalabs/hl<n>/skip_reset_on_timeout
Date: Jun 2021
KernelVersion: 5.13
Contact: ynudelman@habana.ai
Description: Sets the skip reset on timeout option for the device. Value of
"0" means device will be reset in case some CS has timed out,
otherwise it will not be reset.
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
Date: Mar 2020
KernelVersion: 5.6
Documentation/ABI/testing/sysfs-bus-counter
+83 -2
View File
@@ -57,6 +57,7 @@ Description:
What: /sys/bus/counter/devices/counterX/countY/count_mode_available
What: /sys/bus/counter/devices/counterX/countY/error_noise_available
What: /sys/bus/counter/devices/counterX/countY/function_available
What: /sys/bus/counter/devices/counterX/countY/prescaler_available
What: /sys/bus/counter/devices/counterX/countY/signalZ_action_available
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@@ -154,6 +155,15 @@ Description:
Count Y. If possible, this should match the name of the
respective channel as it appears in the device datasheet.
What: /sys/bus/counter/devices/counterX/countY/prescaler
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Configure the prescaler value associated with Count Y.
On the FlexTimer, the counter clock source passes through a
prescaler (i.e. a counter). This acts like a clock
divider.
What: /sys/bus/counter/devices/counterX/countY/preset
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@@ -193,6 +203,15 @@ Description:
both edges:
Any state transition.
What: /sys/bus/counter/devices/counterX/countY/spike_filter_ns
KernelVersion: 5.14
Contact: linux-iio@vger.kernel.org
Description:
If the counter device supports programmable spike filter this
attribute indicates the value in nanoseconds where noise pulses
shorter or equal to configured value are ignored. Value 0 means
filter is disabled.
What: /sys/bus/counter/devices/counterX/name
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
@@ -215,11 +234,45 @@ Description:
Read-only attribute that indicates the total number of Signals
belonging to the Counter.
What: /sys/bus/counter/devices/counterX/signalY/signal
What: /sys/bus/counter/devices/counterX/signalY/cable_fault
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Read-only attribute that indicates whether a differential
encoder cable fault (not connected or loose wires) is detected
for the respective channel of Signal Y. Valid attribute values
are boolean. Detection must first be enabled via the
corresponding cable_fault_enable attribute.
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Whether detection of differential encoder cable faults for the
respective channel of Signal Y is enabled. Valid attribute
values are boolean.
What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Filter clock factor for input Signal Y. This prescaler value
affects the inputs of both quadrature pair signals.
What: /sys/bus/counter/devices/counterX/signalY/index_polarity
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Signal data of Signal Y represented as a string.
Active level of index input Signal Y; irrelevant in
non-synchronous load mode.
What: /sys/bus/counter/devices/counterX/signalY/index_polarity_available
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_available
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Discrete set of available values for the respective Signal Y
configuration are listed in this file.
What: /sys/bus/counter/devices/counterX/signalY/name
KernelVersion: 5.2
@@ -228,3 +281,31 @@ Description:
Read-only attribute that indicates the device-specific name of
Signal Y. If possible, this should match the name of the
respective signal as it appears in the device datasheet.
What: /sys/bus/counter/devices/counterX/signalY/signal
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Signal data of Signal Y represented as a string.
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Configure the counter associated with Signal Y for
non-synchronous or synchronous load mode. Synchronous load mode
cannot be selected in non-quadrature (Pulse-Direction) clock
mode.
non-synchronous:
A logic low level is the active level at this index
input. The index function (as enabled via preset_enable)
is performed directly on the active level of the index
input.
synchronous:
Intended for interfacing with encoder Index output in
quadrature clock mode. The active level is configured
via index_polarity. The index function (as enabled via
preset_enable) is performed synchronously with the
quadrature clock on the active level of the index input.
Documentation/ABI/testing/sysfs-bus-counter-104-quad-8
-61
View File
@@ -1,61 +0,0 @@
What: /sys/bus/counter/devices/counterX/signalY/cable_fault
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Read-only attribute that indicates whether a differential
encoder cable fault (not connected or loose wires) is detected
for the respective channel of Signal Y. Valid attribute values
are boolean. Detection must first be enabled via the
corresponding cable_fault_enable attribute.
What: /sys/bus/counter/devices/counterX/signalY/cable_fault_enable
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Whether detection of differential encoder cable faults for the
respective channel of Signal Y is enabled. Valid attribute
values are boolean.
What: /sys/bus/counter/devices/counterX/signalY/filter_clock_prescaler
KernelVersion: 5.7
Contact: linux-iio@vger.kernel.org
Description:
Filter clock factor for input Signal Y. This prescaler value
affects the inputs of both quadrature pair signals.
What: /sys/bus/counter/devices/counterX/signalY/index_polarity
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Active level of index input Signal Y; irrelevant in
non-synchronous load mode.
What: /sys/bus/counter/devices/counterX/signalY/index_polarity_available
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode_available
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Discrete set of available values for the respective Signal Y
configuration are listed in this file.
What: /sys/bus/counter/devices/counterX/signalY/synchronous_mode
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Configure the counter associated with Signal Y for
non-synchronous or synchronous load mode. Synchronous load mode
cannot be selected in non-quadrature (Pulse-Direction) clock
mode.
non-synchronous:
A logic low level is the active level at this index
input. The index function (as enabled via preset_enable)
is performed directly on the active level of the index
input.
synchronous:
Intended for interfacing with encoder Index output in
quadrature clock mode. The active level is configured
via index_polarity. The index function (as enabled via
preset_enable) is performed synchronously with the
quadrature clock on the active level of the index input.
Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec
-16
View File
@@ -1,16 +0,0 @@
What: /sys/bus/counter/devices/counterX/countY/prescaler_available
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Discrete set of available values for the respective Count Y
configuration are listed in this file. Values are delimited by
newline characters.
What: /sys/bus/counter/devices/counterX/countY/prescaler
KernelVersion: 5.2
Contact: linux-iio@vger.kernel.org
Description:
Configure the prescaler value associated with Count Y.
On the FlexTimer, the counter clock source passes through a
prescaler (i.e. a counter). This acts like a clock
divider.
Documentation/ABI/testing/sysfs-bus-cxl
+103
View File
@@ -24,3 +24,106 @@ Description:
(RO) "Persistent Only Capacity" as bytes. Represents the
identically named field in the Identify Memory Device Output
Payload in the CXL-2.0 specification.
What: /sys/bus/cxl/devices/*/devtype
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL device objects export the devtype attribute which mirrors
the same value communicated in the DEVTYPE environment variable
for uevents for devices on the "cxl" bus.
What: /sys/bus/cxl/devices/portX/uport
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL port objects are enumerated from either a platform firmware
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
CXL component registers. The 'uport' symlink connects the CXL
portX object to the device that published the CXL port
capability.
What: /sys/bus/cxl/devices/portX/dportY
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL port objects are enumerated from either a platform firmware
device (ACPI0017 and ACPI0016) or PCIe switch upstream port with
CXL component registers. The 'dportY' symlink identifies one or
more downstream ports that the upstream port may target in its
decode of CXL memory resources. The 'Y' integer reflects the
hardware port unique-id used in the hardware decoder target
list.
What: /sys/bus/cxl/devices/decoderX.Y
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL decoder objects are enumerated from either a platform
firmware description, or a CXL HDM decoder register set in a
PCIe device (see CXL 2.0 section 8.2.5.12 CXL HDM Decoder
Capability Structure). The 'X' in decoderX.Y represents the
cxl_port container of this decoder, and 'Y' represents the
instance id of a given decoder resource.
What: /sys/bus/cxl/devices/decoderX.Y/{start,size}
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
The 'start' and 'size' attributes together convey the physical
address base and number of bytes mapped in the decoder's decode
window. For decoders of devtype "cxl_decoder_root" the address
range is fixed. For decoders of devtype "cxl_decoder_switch" the
address is bounded by the decode range of the cxl_port ancestor
of the decoder's cxl_port, and dynamically updates based on the
active memory regions in that address space.
What: /sys/bus/cxl/devices/decoderX.Y/locked
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
CXL HDM decoders have the capability to lock the configuration
until the next device reset. For decoders of devtype
"cxl_decoder_root" there is no standard facility to unlock them.
For decoders of devtype "cxl_decoder_switch" a secondary bus
reset, of the PCIe bridge that provides the bus for this
decoders uport, unlocks / resets the decoder.
What: /sys/bus/cxl/devices/decoderX.Y/target_list
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
Display a comma separated list of the current decoder target
configuration. The list is ordered by the current configured
interleave order of the decoder's dport instances. Each entry in
the list is a dport id.
What: /sys/bus/cxl/devices/decoderX.Y/cap_{pmem,ram,type2,type3}
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
When a CXL decoder is of devtype "cxl_decoder_root", it
represents a fixed memory window identified by platform
firmware. A fixed window may only support a subset of memory
types. The 'cap_*' attributes indicate whether persistent
memory, volatile memory, accelerator memory, and / or expander
memory may be mapped behind this decoder's memory window.
What: /sys/bus/cxl/devices/decoderX.Y/target_type
Date: June, 2021
KernelVersion: v5.14
Contact: linux-cxl@vger.kernel.org
Description:
When a CXL decoder is of devtype "cxl_decoder_switch", it can
optionally decode either accelerator memory (type-2) or expander
memory (type-3). The 'target_type' attribute indicates the
current setting which may dynamically change based on what
memory regions are activated in this decode hierarchy.
Documentation/ABI/testing/sysfs-bus-iio
+43 -82
View File
@@ -455,6 +455,19 @@ Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration offset (assumed to fix production
inaccuracies).
icm42600: For this device values are real physical offsets
expressed in SI units (m/s^2 for accelerometers and rad/s
for gyroscope)/
What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available
KernelVersion: 5.8
Contact: linux-iio@vger.kernel.org
Description:
Available values of calibbias. Maybe expressed as either of:
- a small discrete set of values like "0 2 4 6 8"
- a range specified as "[min step max]"
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_calibscale
What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_supply_calibscale
@@ -652,6 +665,25 @@ Description:
Output frequency for channel Y in Hz. The number must always be
specified and unique if the output corresponds to a single
channel.
Some drivers have additional constraints:
ADF4371 has an integrated VCO with fundamendal output
frequency ranging from 4000000000 Hz 8000000000 Hz.
out_altvoltage0_frequency:
A divide by 1, 2, 4, 8, 16, 32 or circuit generates
frequencies from 62500000 Hz to 8000000000 Hz.
out_altvoltage1_frequency:
This channel duplicates the channel 0 frequency
out_altvoltage2_frequency:
A frequency doubler generates frequencies from
8000000000 Hz to 16000000000 Hz.
out_altvoltage3_frequency:
A frequency quadrupler generates frequencies from
16000000000 Hz to 32000000000 Hz.
Note: writes to one of the channels will affect the frequency of
all the other channels, since it involves changing the VCO
fundamental output frequency.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_phase
KernelVersion: 3.4.0
@@ -663,6 +695,17 @@ Description:
specified and unique if the output corresponds to a single
channel.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Set/get output current for channel Y. Units after application
of scale and offset are milliamps.
For some devices current channels are used to specify
current supplied to elements used in taking a measurement
of a different type. E.g. LED currents.
What: /sys/bus/iio/devices/iio:deviceX/events
KernelVersion: 2.6.35
Contact: linux-iio@vger.kernel.org
@@ -1195,16 +1238,12 @@ Description:
The name of the trigger source being used, as per string given
in /sys/class/iio/triggerY/name.
What: /sys/bus/iio/devices/iio:deviceX/buffer/length
KernelVersion: 2.6.35
What: /sys/bus/iio/devices/iio:deviceX/bufferY/length
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Description:
Number of scans contained by the buffer.
What: /sys/bus/iio/devices/iio:deviceX/buffer/enable
KernelVersion: 2.6.35
What: /sys/bus/iio/devices/iio:deviceX/bufferY/enable
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
@@ -1212,8 +1251,6 @@ Description:
Actually start the buffer capture up. Will start trigger
if first device and appropriate.
What: /sys/bus/iio/devices/iio:deviceX/scan_elements
KernelVersion: 2.6.37
What: /sys/bus/iio/devices/iio:deviceX/bufferY
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
@@ -1224,34 +1261,6 @@ Description:
Since kernel 5.11 the scan_elements attributes are merged into
the bufferY directory, to be configurable per buffer.
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_en
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_en
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_en
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_en
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_en
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY-voltageZ_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_en
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_en
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_en
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_en
What: /sys/.../iio:deviceX/scan_elements/in_pressure_en
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_en
What: /sys/.../iio:deviceX/scan_elements/in_proximity_en
KernelVersion: 2.6.37
What: /sys/.../iio:deviceX/bufferY/in_accel_x_en
What: /sys/.../iio:deviceX/bufferY/in_accel_y_en
What: /sys/.../iio:deviceX/bufferY/in_accel_z_en
@@ -1284,23 +1293,6 @@ Contact: linux-iio@vger.kernel.org
Description:
Scan element control for triggered data capture.
What: /sys/.../iio:deviceX/scan_elements/in_accel_type
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_type
What: /sys/.../iio:deviceX/scan_elements/in_magn_type
What: /sys/.../iio:deviceX/scan_elements/in_incli_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_type
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_type
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_type
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_type
What: /sys/.../iio:deviceX/scan_elements/in_pressure_type
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_type
What: /sys/.../iio:deviceX/scan_elements/in_proximity_type
KernelVersion: 2.6.37
What: /sys/.../iio:deviceX/bufferY/in_accel_type
What: /sys/.../iio:deviceX/bufferY/in_anglvel_type
What: /sys/.../iio:deviceX/bufferY/in_magn_type
@@ -1347,33 +1339,6 @@ Description:
If the type parameter can take one of a small set of values,
this attribute lists them.
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_supply_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltageY_q_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_i_index
What: /sys/.../iio:deviceX/scan_elements/in_voltage_q_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_accel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_x_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_y_index
What: /sys/.../iio:deviceX/scan_elements/in_anglvel_z_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_x_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_y_index
What: /sys/.../iio:deviceX/scan_elements/in_magn_z_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_magnetic_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_from_north_true_tilt_comp_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_x_index
What: /sys/.../iio:deviceX/scan_elements/in_incli_y_index
What: /sys/.../iio:deviceX/scan_elements/in_timestamp_index
What: /sys/.../iio:deviceX/scan_elements/in_pressureY_index
What: /sys/.../iio:deviceX/scan_elements/in_pressure_index
What: /sys/.../iio:deviceX/scan_elements/in_rot_quaternion_index
What: /sys/.../iio:deviceX/scan_elements/in_proximity_index
KernelVersion: 2.6.37
What: /sys/.../iio:deviceX/bufferY/in_voltageY_index
What: /sys/.../iio:deviceX/bufferY/in_voltageY_supply_index
What: /sys/.../iio:deviceX/bufferY/in_voltageY_i_index
@@ -1613,8 +1578,6 @@ Description:
Specifies number of seconds in which we compute the steps
that occur in order to decide if the consumer is making steps.
What: /sys/bus/iio/devices/iio:deviceX/buffer/watermark
KernelVersion: 4.2
What: /sys/bus/iio/devices/iio:deviceX/bufferY/watermark
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
@@ -1633,8 +1596,6 @@ Description:
the available samples after the timeout expires and thus have a
maximum delay guarantee.
What: /sys/bus/iio/devices/iio:deviceX/buffer/data_available
KernelVersion: 4.16
What: /sys/bus/iio/devices/iio:deviceX/bufferY/data_available
KernelVersion: 5.11
Contact: linux-iio@vger.kernel.org
Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371
-33
View File
@@ -1,28 +1,3 @@
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_frequency
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
Stores the PLL frequency in Hz for channel Y.
Reading returns the actual frequency in Hz.
The ADF4371 has an integrated VCO with fundamendal output
frequency ranging from 4000000000 Hz 8000000000 Hz.
out_altvoltage0_frequency:
A divide by 1, 2, 4, 8, 16, 32 or circuit generates
frequencies from 62500000 Hz to 8000000000 Hz.
out_altvoltage1_frequency:
This channel duplicates the channel 0 frequency
out_altvoltage2_frequency:
A frequency doubler generates frequencies from
8000000000 Hz to 16000000000 Hz.
out_altvoltage3_frequency:
A frequency quadrupler generates frequencies from
16000000000 Hz to 32000000000 Hz.
Note: writes to one of the channels will affect the frequency of
all the other channels, since it involves changing the VCO
fundamental output frequency.
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_name
KernelVersion:
Contact: linux-iio@vger.kernel.org
@@ -34,11 +9,3 @@ Description:
out_altvoltage2_name: RF16x
out_altvoltage3_name: RF32x
What: /sys/bus/iio/devices/iio:deviceX/out_altvoltageY_powerdown
KernelVersion:
Contact: linux-iio@vger.kernel.org
Description:
This attribute allows the user to power down the PLL and it's
RFOut buffers.
Writing 1 causes the specified channel to power down.
Clearing returns to normal operation.
Documentation/ABI/testing/sysfs-bus-iio-health-afe440x
+2 -8
View File
@@ -18,6 +18,8 @@ Description:
respectively which simply helper channels containing the
calculated difference in the value of stage 1 - 2 and 3 - 4.
The values are expressed in 24-bit twos complement.
The LED current for the stage is controlled via
out_currentY_raw.
What: /sys/bus/iio/devices/iio:deviceX/in_intensityY_offset
Date: May 2016
@@ -35,11 +37,3 @@ Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the resistance and the capacitance settings for the
Transimpedance Amplifier during the associated stage.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2016
KernelVersion:
Contact: Andrew F. Davis <afd@ti.com>
Description:
Get and set the LED current for the specified LED active during
this stage. Y is the specific stage number.
Documentation/ABI/testing/sysfs-bus-iio-icm42600
-20
View File
@@ -1,20 +0,0 @@
What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_accel_z_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_x_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_y_calibbias
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_z_calibbias
KernelVersion: 5.8
Contact: linux-iio@vger.kernel.org
Description:
Hardware applied calibration offset (assumed to fix production
inaccuracies). Values represent a real physical offset expressed
in SI units (m/s^2 for accelerometer and rad/s for gyroscope).
What: /sys/bus/iio/devices/iio:deviceX/in_accel_calibbias_available
What: /sys/bus/iio/devices/iio:deviceX/in_anglvel_calibbias_available
KernelVersion: 5.8
Contact: linux-iio@vger.kernel.org
Description:
Range of available values for hardware offset. Values in SI
units (m/s^2 for accelerometer and rad/s for gyroscope).
Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als
+3 -8
View File
@@ -41,14 +41,6 @@ Description:
Get the current light zone (0..4) as defined by the
in_illuminance0_threshY_{falling,rising} thresholds.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_raw
Date: May 2012
KernelVersion: 3.5
Contact: Johan Hovold <jhovold@gmail.com>
Description:
Get output current for channel Y (0..255), that is,
out_currentY_currentZ_raw, where Z is the current zone.
What: /sys/bus/iio/devices/iio:deviceX/out_currentY_currentZ_raw
Date: May 2012
KernelVersion: 3.5
@@ -59,3 +51,6 @@ Description:
These values correspond to the ALS-mapper target registers for
ALS-mapper Y + 1.
Note that out_currentY_raw provides the current for the
current zone.
Documentation/ABI/testing/sysfs-bus-papr-pmem
+5 -3
View File
@@ -39,9 +39,11 @@ KernelVersion: v5.9
Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev,
Description:
(RO) Report various performance stats related to papr-scm NVDIMM
device. Each stat is reported on a new line with each line
composed of a stat-identifier followed by it value. Below are
currently known dimm performance stats which are reported:
device. This attribute is only available for NVDIMM devices
that support reporting NVDIMM performance stats. Each stat is
reported on a new line with each line composed of a
stat-identifier followed by it value. Below are currently known
dimm performance stats which are reported:
* "CtlResCt" : Controller Reset Count
* "CtlResTm" : Controller Reset Elapsed Time
Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor
+31
View File
@@ -0,0 +1,31 @@
What: /sys/bus/spi/devices/.../spi-nor/jedec_id
Date: April 2021
KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) The JEDEC ID of the SPI NOR flash as reported by the
flash device.
What: /sys/bus/spi/devices/.../spi-nor/manufacturer
Date: April 2021
KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) Manufacturer of the SPI NOR flash.
What: /sys/bus/spi/devices/.../spi-nor/partname
Date: April 2021
KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) Part name of the SPI NOR flash.
What: /sys/bus/spi/devices/.../spi-nor/sfdp
Date: April 2021
KernelVersion: 5.14
Contact: linux-mtd@lists.infradead.org
Description: (RO) This attribute is only present if the SPI NOR flash
device supports the "Read SFDP" command (5Ah).
If present, it contains the complete SFDP (serial flash
discoverable parameters) binary data of the flash.
Documentation/ABI/testing/sysfs-bus-thunderbolt
+59 -23
View File
@@ -1,4 +1,4 @@
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
What: /sys/bus/thunderbolt/devices/.../domainX/boot_acl
Date: Jun 2018
KernelVersion: 4.17
Contact: thunderbolt-software@lists.01.org
@@ -21,7 +21,7 @@ Description: Holds a comma separated list of device unique_ids that
If a device is authorized automatically during boot its
boot attribute is set to 1.
What: /sys/bus/thunderbolt/devices/.../domainX/deauthorization
What: /sys/bus/thunderbolt/devices/.../domainX/deauthorization
Date: May 2021
KernelVersion: 5.12
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
@@ -30,7 +30,7 @@ Description: This attribute tells whether the system supports
de-authorize PCIe tunnel by writing 0 to authorized
attribute under each device.
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
What: /sys/bus/thunderbolt/devices/.../domainX/iommu_dma_protection
Date: Mar 2019
KernelVersion: 4.21
Contact: thunderbolt-software@lists.01.org
@@ -39,7 +39,7 @@ Description: This attribute tells whether the system uses IOMMU
it is not (DMA protection is solely based on Thunderbolt
security levels).
What: /sys/bus/thunderbolt/devices/.../domainX/security
What: /sys/bus/thunderbolt/devices/.../domainX/security
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
@@ -61,7 +61,7 @@ Description: This attribute holds current Thunderbolt security level
the BIOS.
======= ==================================================
What: /sys/bus/thunderbolt/devices/.../authorized
What: /sys/bus/thunderbolt/devices/.../authorized
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
@@ -95,14 +95,14 @@ Description: This attribute is used to authorize Thunderbolt devices
EKEYREJECTED if the challenge response did not match.
== ========================================================
What: /sys/bus/thunderbolt/devices/.../boot
What: /sys/bus/thunderbolt/devices/.../boot
Date: Jun 2018
KernelVersion: 4.17
Contact: thunderbolt-software@lists.01.org
Description: This attribute contains 1 if Thunderbolt device was already
authorized on boot and 0 otherwise.
What: /sys/bus/thunderbolt/devices/.../generation
What: /sys/bus/thunderbolt/devices/.../generation
Date: Jan 2020
KernelVersion: 5.5
Contact: Christian Kellner <christian@kellner.me>
@@ -110,7 +110,7 @@ Description: This attribute contains the generation of the Thunderbolt
controller associated with the device. It will contain 4
for USB4.
What: /sys/bus/thunderbolt/devices/.../key
What: /sys/bus/thunderbolt/devices/.../key
Date: Sep 2017
KernelVersion: 4.13
Contact: thunderbolt-software@lists.01.org
@@ -213,12 +213,15 @@ Description: When new NVM image is written to the non-active NVM
restarted with the new NVM firmware. If the image
verification fails an error code is returned instead.
This file will accept writing values "1" or "2"
This file will accept writing values "1", "2" or "3".
- Writing "1" will flush the image to the storage
area and authenticate the image in one action.
- Writing "2" will run some basic validation on the image
and flush it to the storage area.
- Writing "3" will authenticate the image that is
currently written in the storage area. This is only
supported with USB4 devices and retimers.
When read holds status of the last authentication
operation if an error occurred during the process. This
@@ -226,6 +229,20 @@ Description: When new NVM image is written to the non-active NVM
based mailbox before the device is power cycled. Writing
0 here clears the status.
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect
Date: Oct 2020
KernelVersion: v5.9
Contact: Mario Limonciello <mario.limonciello@dell.com>
Description: For supported devices, automatically authenticate the new Thunderbolt
image when the device is disconnected from the host system.
This file will accept writing values "1" or "2"
- Writing "1" will flush the image to the storage
area and prepare the device for authentication on disconnect.
- Writing "2" will run some basic validation on the image
and flush it to the storage area.
What: /sys/bus/thunderbolt/devices/<xdomain>.<service>/key
Date: Jan 2018
KernelVersion: 4.15
@@ -276,6 +293,39 @@ Contact: thunderbolt-software@lists.01.org
Description: This contains XDomain service specific settings as
bitmask. Format: %x
What: /sys/bus/thunderbolt/devices/usb4_portX/link
Date: Sep 2021
KernelVersion: v5.14
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Returns the current link mode. Possible values are
"usb4", "tbt" and "none".
What: /sys/bus/thunderbolt/devices/usb4_portX/offline
Date: Sep 2021
KernelVersion: v5.14
Contact: Rajmohan Mani <rajmohan.mani@intel.com>
Description: Writing 1 to this attribute puts the USB4 port into
offline mode. Only allowed when there is nothing
connected to the port (link attribute returns "none").
Once the port is in offline mode it does not receive any
hotplug events. This is used to update NVM firmware of
on-board retimers. Writing 0 puts the port back to
online mode.
This attribute is only visible if the platform supports
powering on retimers when there is no cable connected.
What: /sys/bus/thunderbolt/devices/usb4_portX/rescan
Date: Sep 2021
KernelVersion: v5.14
Contact: Rajmohan Mani <rajmohan.mani@intel.com>
Description: When the USB4 port is in offline mode writing 1 to this
attribute forces rescan of the sideband for on-board
retimers. Each retimer appear under the USB4 port as if
the USB4 link was up. These retimers act in the same way
as if the cable was connected so upgrading their NVM
firmware can be done the usual way.
What: /sys/bus/thunderbolt/devices/<device>:<port>.<index>/device
Date: Oct 2020
KernelVersion: v5.9
@@ -308,17 +358,3 @@ Date: Oct 2020
KernelVersion: v5.9
Contact: Mika Westerberg <mika.westerberg@linux.intel.com>
Description: Retimer vendor identifier read from the hardware.
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect
Date: Oct 2020
KernelVersion: v5.9
Contact: Mario Limonciello <mario.limonciello@dell.com>
Description: For supported devices, automatically authenticate the new Thunderbolt
image when the device is disconnected from the host system.
This file will accept writing values "1" or "2"
- Writing "1" will flush the image to the storage
area and prepare the device for authentication on disconnect.
- Writing "2" will run some basic validation on the image
and flush it to the storage area.
Documentation/ABI/testing/sysfs-bus-usb
-11
View File
@@ -154,17 +154,6 @@ Description:
files hold a string value (enable or disable) indicating whether
or not USB3 hardware LPM U1 or U2 is enabled for the device.
What: /sys/bus/usb/devices/.../removable
Date: February 2012
Contact: Matthew Garrett <mjg@redhat.com>
Description:
Some information about whether a given USB device is
physically fixed to the platform can be inferred from a
combination of hub descriptor bits and platform-specific data
such as ACPI. This file will read either "removable" or
"fixed" if the information is available, and "unknown"
otherwise.
What: /sys/bus/usb/devices/.../ltm_capable
Date: July 2012
Contact: Sarah Sharp <sarah.a.sharp@linux.intel.com>
Documentation/ABI/testing/sysfs-class-spi-eeprom
+19
View File
@@ -0,0 +1,19 @@
What: /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/fram
Date: June 2021
KernelVersion: 5.14
Contact: Jiri Prchal <jiri.prchal@aksignal.cz>
Description:
Contains the FRAM binary data. Same as EEPROM, just another file
name to indicate that it employs ferroelectric process.
It performs write operations at bus speed - no write delays.
What: /sys/class/spi_master/spi<bus>/spi<bus>.<dev>/sernum
Date: May 2021
KernelVersion: 5.14
Contact: Jiri Prchal <jiri.prchal@aksignal.cz>
Description:
Contains the serial number of the Cypress FRAM (FM25VN) if it is
present. It will be displayed as a 8 byte hex string, as read
from the device.
This is a read-only attribute.
Documentation/ABI/testing/sysfs-devices-removable
+18
View File
@@ -0,0 +1,18 @@
What: /sys/devices/.../removable
Date: May 2021
Contact: Rajat Jain <rajatxjain@gmail.com>
Description:
Information about whether a given device can be removed from the
platform by the user. This is determined by its subsystem in a
bus / platform-specific way. This attribute is only present for
devices that can support determining such information:
"removable": device can be removed from the platform by the user
"fixed": device is fixed to the platform / cannot be removed
by the user.
"unknown": The information is unavailable / cannot be deduced.
Currently this is only supported by USB (which infers the
information from a combination of hub descriptor bits and
platform-specific data such as ACPI) and PCI (which gets this
from ACPI / device tree).
Documentation/ABI/testing/sysfs-driver-ufs
+126
View File
@@ -995,6 +995,132 @@ Description: This entry shows the target state of an UFS UIC link
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_enable
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the status of performance monitor enablement
and it can be used to start/stop the monitor. When the monitor
is stopped, the performance data collected is also cleared.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/monitor_chunk_size
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file tells the monitor to focus on requests transferring
data of specific chunk size (in Bytes). 0 means any chunk size.
It can only be changed when monitor is disabled.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_sectors
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how many sectors (in 512 Bytes) have been
sent from device to host after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_total_busy
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how long (in micro seconds) has been spent
sending data from device to host after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_nr_requests
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how many read requests have been sent after
monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_max
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the maximum latency (in micro seconds) of
read requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_min
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the minimum latency (in micro seconds) of
read requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_avg
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the average latency (in micro seconds) of
read requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/read_req_latency_sum
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the total latency (in micro seconds) of
read requests sent after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_sectors
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how many sectors (in 512 Bytes) have been sent
from host to device after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_total_busy
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how long (in micro seconds) has been spent
sending data from host to device after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_nr_requests
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows how many write requests have been sent after
monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_max
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the maximum latency (in micro seconds) of write
requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_min
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the minimum latency (in micro seconds) of write
requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_avg
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the average latency (in micro seconds) of write
requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/monitor/write_req_latency_sum
Date: January 2021
Contact: Can Guo <cang@codeaurora.org>
Description: This file shows the total latency (in micro seconds) of write
requests after monitor gets started.
The file is read only.
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/wb_presv_us_en
Date: June 2020
Contact: Asutosh Das <asutoshd@codeaurora.org>
Documentation/ABI/testing/sysfs-firmware-memmap
+4
View File
@@ -56,6 +56,10 @@ Description:
- System RAM
- ACPI Tables
- ACPI Non-volatile Storage
- Unusable memory
- Persistent Memory (legacy)
- Persistent Memory
- Soft Reserved
- reserved
Following shell snippet can be used to display that memory
Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst
+3 -3
View File
@@ -21,7 +21,7 @@ Any code that happens after the end of a given RCU grace period is guaranteed
to see the effects of all accesses prior to the beginning of that grace
period that are within RCU read-side critical sections.
Similarly, any code that happens before the beginning of a given RCU grace
period is guaranteed to see the effects of all accesses following the end
period is guaranteed to not see the effects of all accesses following the end
of that grace period that are within RCU read-side critical sections.
Note well that RCU-sched read-side critical sections include any region
@@ -339,14 +339,14 @@ The diagram below shows the path of ordering if the leftmost
leftmost ``rcu_node`` structure offlines its last CPU and if the next
``rcu_node`` structure has no online CPUs).
.. kernel-figure:: TreeRCU-gp-init-1.svg
.. kernel-figure:: TreeRCU-gp-init-2.svg
The final ``rcu_gp_init()`` pass through the ``rcu_node`` tree traverses
breadth-first, setting each ``rcu_node`` structure's ``->gp_seq`` field
to the newly advanced value from the ``rcu_state`` structure, as shown
in the following diagram.
.. kernel-figure:: TreeRCU-gp-init-1.svg
.. kernel-figure:: TreeRCU-gp-init-3.svg
This change will also cause each CPU's next call to
``__note_gp_changes()`` to notice that a new grace period has started,
Documentation/admin-guide/cgroup-v2.rst
+15
View File
@@ -953,6 +953,21 @@ All cgroup core files are prefixed with "cgroup."
it's possible to delete a frozen (and empty) cgroup, as well as
create new sub-cgroups.
cgroup.kill
A write-only single value file which exists in non-root cgroups.
The only allowed value is "1".
Writing "1" to the file causes the cgroup and all descendant cgroups to
be killed. This means that all processes located in the affected cgroup
tree will be killed via SIGKILL.
Killing a cgroup tree will deal with concurrent forks appropriately and
is protected against migrations.
In a threaded cgroup, writing this file fails with EOPNOTSUPP as
killing cgroups is a process directed operation, i.e. it affects
the whole thread-group.
Controllers
===========
Documentation/admin-guide/kernel-parameters.rst
+5
View File
@@ -76,6 +76,11 @@ to change, such as less cores in the CPU list, then N and any ranges using N
will also change. Use the same on a small 4 core system, and "16-N" becomes
"16-3" and now the same boot input will be flagged as invalid (start > end).
The special case-tolerant group name "all" has a meaning of selecting all CPUs,
so that "nohz_full=all" is the equivalent of "nohz_full=0-N".
The semantics of "N" and "all" is supported on a level of bitmaps and holds for
all users of bitmap_parse().
This document may not be entirely up to date and comprehensive. The command
"modinfo -p ${modulename}" shows a current list of all parameters of a loadable
Documentation/admin-guide/kernel-parameters.txt
+52 -1
View File
@@ -301,6 +301,9 @@
allowed anymore to lift isolation
requirements as needed. This option
does not override iommu=pt
force_enable - Force enable the IOMMU on platforms known
to be buggy with IOMMU enabled. Use this
option with care.
amd_iommu_dump= [HW,X86-64]
Enable AMD IOMMU driver option to dump the ACPI table
@@ -1119,6 +1122,11 @@
the driver will use only 32-bit accessors to read/write
the device registers.
liteuart,<addr>
Start an early console on a litex serial port at the
specified address. The serial port must already be
setup and configured. Options are not yet supported.
meson,<addr>
Start an early, polled-mode console on a meson serial
port at the specified address. The serial port must
@@ -1594,6 +1602,23 @@
Documentation/admin-guide/mm/hugetlbpage.rst.
Format: size[KMG]
hugetlb_free_vmemmap=
[KNL] Reguires CONFIG_HUGETLB_PAGE_FREE_VMEMMAP
enabled.
Allows heavy hugetlb users to free up some more
memory (6 * PAGE_SIZE for each 2MB hugetlb page).
Format: { on | off (default) }
on: enable the feature
off: disable the feature
Built with CONFIG_HUGETLB_PAGE_FREE_VMEMMAP_DEFAULT_ON=y,
the default is on.
This is not compatible with memory_hotplug.memmap_on_memory.
If both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
hung_task_panic=
[KNL] Should the hung task detector generate panics.
Format: 0 | 1
@@ -2018,7 +2043,7 @@
forcing Dual Address Cycle for PCI cards supporting
greater than 32-bit addressing.
iommu.strict= [ARM64] Configure TLB invalidation behaviour
iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour
Format: { "0" | "1" }
0 - Lazy mode.
Request that DMA unmap operations use deferred
@@ -2029,6 +2054,10 @@
1 - Strict mode (default).
DMA unmap operations invalidate IOMMU hardware TLBs
synchronously.
Note: on x86, the default behaviour depends on the
equivalent driver-specific parameters, but a strict
mode explicitly specified by either method takes
precedence.
iommu.passthrough=
[ARM64, X86] Configure DMA to bypass the IOMMU by default.
@@ -2864,6 +2893,10 @@
Note that even when enabled, there are a few cases where
the feature is not effective.
This is not compatible with hugetlb_free_vmemmap. If
both parameters are enabled, hugetlb_free_vmemmap takes
precedence over memory_hotplug.memmap_on_memory.
memtest= [KNL,X86,ARM,PPC,RISCV] Enable memtest
Format: <integer>
default : 0 <disable>
@@ -4330,6 +4363,11 @@
whole algorithm to behave better in low memory
condition.
rcutree.rcu_delay_page_cache_fill_msec= [KNL]
Set the page-cache refill delay (in milliseconds)
in response to low-memory conditions. The range
of permitted values is in the range 0:100000.
rcutree.jiffies_till_first_fqs= [KNL]
Set delay from grace-period initialization to
first attempt to force quiescent states.
@@ -5648,12 +5686,25 @@
Note, echoing 1 into this file without the
tracepoint_printk kernel cmdline option has no effect.
The tp_printk_stop_on_boot (see below) can also be used
to stop the printing of events to console at
late_initcall_sync.
** CAUTION **
Having tracepoints sent to printk() and activating high
frequency tracepoints such as irq or sched, can cause
the system to live lock.
tp_printk_stop_on_boot[FTRACE]
When tp_printk (above) is set, it can cause a lot of noise
on the console. It may be useful to only include the
printing of events during boot up, as user space may
make the system inoperable.
This command line option will stop the printing of events
to console at the late_initcall_sync() time frame.
traceoff_on_warning
[FTRACE] enable this option to disable tracing when a
warning is hit. This turns off "tracing_on". Tracing can
Documentation/admin-guide/mm/hugetlbpage.rst
+11
View File
@@ -60,6 +60,10 @@ HugePages_Surp
the pool above the value in ``/proc/sys/vm/nr_hugepages``. The
maximum number of surplus huge pages is controlled by
``/proc/sys/vm/nr_overcommit_hugepages``.
Note: When the feature of freeing unused vmemmap pages associated
with each hugetlb page is enabled, the number of surplus huge pages
may be temporarily larger than the maximum number of surplus huge
pages when the system is under memory pressure.
Hugepagesize
is the default hugepage size (in Kb).
Hugetlb
@@ -80,6 +84,10 @@ returned to the huge page pool when freed by a task. A user with root
privileges can dynamically allocate more or free some persistent huge pages
by increasing or decreasing the value of ``nr_hugepages``.
Note: When the feature of freeing unused vmemmap pages associated with each
hugetlb page is enabled, we can fail to free the huge pages triggered by
the user when ths system is under memory pressure. Please try again later.
Pages that are used as huge pages are reserved inside the kernel and cannot
be used for other purposes. Huge pages cannot be swapped out under
memory pressure.
@@ -145,6 +153,9 @@ default_hugepagesz
will all result in 256 2M huge pages being allocated. Valid default
huge page size is architecture dependent.
hugetlb_free_vmemmap
When CONFIG_HUGETLB_PAGE_FREE_VMEMMAP is set, this enables freeing
unused vmemmap pages associated with each HugeTLB page.
When multiple huge page sizes are supported, ``/proc/sys/vm/nr_hugepages``
indicates the current number of pre-allocated huge pages of the default size.
Documentation/admin-guide/mm/memory-hotplug.rst
+13
View File
@@ -357,6 +357,19 @@ creates ZONE_MOVABLE as following.
Unfortunately, there is no information to show which memory block belongs
to ZONE_MOVABLE. This is TBD.
Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE
and the feature of freeing unused vmemmap pages associated with each hugetlb
page is enabled.
This can happen when we have plenty of ZONE_MOVABLE memory, but not enough
kernel memory to allocate vmemmmap pages. We may even be able to migrate
huge page contents, but will not be able to dissolve the source huge page.
This will prevent an offline operation and is unfortunate as memory offlining
is expected to succeed on movable zones. Users that depend on memory hotplug
to succeed for movable zones should carefully consider whether the memory
savings gained from this feature are worth the risk of possibly not being
able to offline memory in certain situations.
.. note::
Techniques that rely on long-term pinnings of memory (especially, RDMA and
vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory
Documentation/admin-guide/mm/pagemap.rst
+2
View File
@@ -21,6 +21,8 @@ There are four components to pagemap:
* Bit 55 pte is soft-dirty (see
:ref:`Documentation/admin-guide/mm/soft-dirty.rst <soft_dirty>`)
* Bit 56 page exclusively mapped (since 4.2)
* Bit 57 pte is uffd-wp write-protected (since 5.13) (see
:ref:`Documentation/admin-guide/mm/userfaultfd.rst <userfaultfd>`)
* Bits 57-60 zero
* Bit 61 page is file-page or shared-anon (since 3.5)
* Bit 62 page swapped
Documentation/admin-guide/mm/userfaultfd.rst
+2 -1
View File
@@ -77,7 +77,8 @@ events, except page fault notifications, may be generated:
- ``UFFD_FEATURE_MINOR_HUGETLBFS`` indicates that the kernel supports
``UFFDIO_REGISTER_MODE_MINOR`` registration for hugetlbfs virtual memory
areas.
areas. ``UFFD_FEATURE_MINOR_SHMEM`` is the analogous feature indicating
support for shmem virtual memory areas.
The userland application should set the feature flags it intends to use
when invoking the ``UFFDIO_API`` ioctl, to request that those features be
Documentation/admin-guide/thunderbolt.rst
+29
View File
@@ -256,6 +256,35 @@ Note names of the NVMem devices ``nvm_activeN`` and ``nvm_non_activeN``
depend on the order they are registered in the NVMem subsystem. N in
the name is the identifier added by the NVMem subsystem.
Upgrading on-board retimer NVM when there is no cable connected
---------------------------------------------------------------
If the platform supports, it may be possible to upgrade the retimer NVM
firmware even when there is nothing connected to the USB4
ports. When this is the case the ``usb4_portX`` devices have two special
attributes: ``offline`` and ``rescan``. The way to upgrade the firmware
is to first put the USB4 port into offline mode::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline
This step makes sure the port does not respond to any hotplug events,
and also ensures the retimers are powered on. The next step is to scan
for the retimers::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan
This enumerates and adds the on-board retimers. Now retimer NVM can be
upgraded in the same way than with cable connected (see previous
section). However, the retimer is not disconnected as we are offline
mode) so after writing ``1`` to ``nvm_authenticate`` one should wait for
5 or more seconds before running rescan again::
# echo 1 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/rescan
This point if everything went fine, the port can be put back to
functional state again::
# echo 0 > /sys/bus/thunderbolt/devices/0-0/usb4_port1/offline
Upgrading NVM when host controller is in safe mode
--------------------------------------------------
If the existing NVM is not properly authenticated (or is missing) the
Documentation/core-api/kernel-api.rst
+2 -5
View File
@@ -24,11 +24,8 @@ String Conversions
.. kernel-doc:: lib/vsprintf.c
:export:
.. kernel-doc:: include/linux/kernel.h
:functions: kstrtol
.. kernel-doc:: include/linux/kernel.h
:functions: kstrtoul
.. kernel-doc:: include/linux/kstrtox.h
:functions: kstrtol kstrtoul
.. kernel-doc:: lib/kstrtox.c
:export:
Documentation/dev-tools/kcsan.rst
+36 -51
View File
@@ -27,75 +27,57 @@ Error reports
A typical data race report looks like this::
==================================================================
BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode
BUG: KCSAN: data-race in test_kernel_read / test_kernel_write
write to 0xffff8fee4c40700c of 4 bytes by task 175 on cpu 4:
kernfs_refresh_inode+0x70/0x170
kernfs_iop_permission+0x4f/0x90
inode_permission+0x190/0x200
link_path_walk.part.0+0x503/0x8e0
path_lookupat.isra.0+0x69/0x4d0
filename_lookup+0x136/0x280
user_path_at_empty+0x47/0x60
vfs_statx+0x9b/0x130
__do_sys_newlstat+0x50/0xb0
__x64_sys_newlstat+0x37/0x50
do_syscall_64+0x85/0x260
entry_SYSCALL_64_after_hwframe+0x44/0xa9
write to 0xffffffffc009a628 of 8 bytes by task 487 on cpu 0:
test_kernel_write+0x1d/0x30
access_thread+0x89/0xd0
kthread+0x23e/0x260
ret_from_fork+0x22/0x30
read to 0xffff8fee4c40700c of 4 bytes by task 166 on cpu 6:
generic_permission+0x5b/0x2a0
kernfs_iop_permission+0x66/0x90
inode_permission+0x190/0x200
link_path_walk.part.0+0x503/0x8e0
path_lookupat.isra.0+0x69/0x4d0
filename_lookup+0x136/0x280
user_path_at_empty+0x47/0x60
do_faccessat+0x11a/0x390
__x64_sys_access+0x3c/0x50
do_syscall_64+0x85/0x260
entry_SYSCALL_64_after_hwframe+0x44/0xa9
read to 0xffffffffc009a628 of 8 bytes by task 488 on cpu 6:
test_kernel_read+0x10/0x20
access_thread+0x89/0xd0
kthread+0x23e/0x260
ret_from_fork+0x22/0x30
value changed: 0x00000000000009a6 -> 0x00000000000009b2
Reported by Kernel Concurrency Sanitizer on:
CPU: 6 PID: 166 Comm: systemd-journal Not tainted 5.3.0-rc7+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
CPU: 6 PID: 488 Comm: access_thread Not tainted 5.12.0-rc2+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
The header of the report provides a short summary of the functions involved in
the race. It is followed by the access types and stack traces of the 2 threads
involved in the data race.
involved in the data race. If KCSAN also observed a value change, the observed
old value and new value are shown on the "value changed" line respectively.
The other less common type of data race report looks like this::
==================================================================
BUG: KCSAN: data-race in e1000_clean_rx_irq+0x551/0xb10
BUG: KCSAN: data-race in test_kernel_rmw_array+0x71/0xd0
race at unknown origin, with read to 0xffff933db8a2ae6c of 1 bytes by interrupt on cpu 0:
e1000_clean_rx_irq+0x551/0xb10
e1000_clean+0x533/0xda0
net_rx_action+0x329/0x900
__do_softirq+0xdb/0x2db
irq_exit+0x9b/0xa0
do_IRQ+0x9c/0xf0
ret_from_intr+0x0/0x18
default_idle+0x3f/0x220
arch_cpu_idle+0x21/0x30
do_idle+0x1df/0x230
cpu_startup_entry+0x14/0x20
rest_init+0xc5/0xcb
arch_call_rest_init+0x13/0x2b
start_kernel+0x6db/0x700
race at unknown origin, with read to 0xffffffffc009bdb0 of 8 bytes by task 515 on cpu 2:
test_kernel_rmw_array+0x71/0xd0
access_thread+0x89/0xd0
kthread+0x23e/0x260
ret_from_fork+0x22/0x30
value changed: 0x0000000000002328 -> 0x0000000000002329
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.3.0-rc7+ #2
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.12.0-1 04/01/2014
CPU: 2 PID: 515 Comm: access_thread Not tainted 5.12.0-rc2+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
==================================================================
This report is generated where it was not possible to determine the other
racing thread, but a race was inferred due to the data value of the watched
memory location having changed. These can occur either due to missing
instrumentation or e.g. DMA accesses. These reports will only be generated if
``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y`` (selected by default).
memory location having changed. These reports always show a "value changed"
line. A common reason for reports of this type are missing instrumentation in
the racing thread, but could also occur due to e.g. DMA accesses. Such reports
are shown only if ``CONFIG_KCSAN_REPORT_RACE_UNKNOWN_ORIGIN=y``, which is
enabled by default.
Selective analysis
~~~~~~~~~~~~~~~~~~
@@ -106,7 +88,8 @@ the below options are available:
* KCSAN understands the ``data_race(expr)`` annotation, which tells KCSAN that
any data races due to accesses in ``expr`` should be ignored and resulting
behaviour when encountering a data race is deemed safe.
behaviour when encountering a data race is deemed safe. Please see
`"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
* Disabling data race detection for entire functions can be accomplished by
using the function attribute ``__no_kcsan``::
@@ -128,6 +111,8 @@ the below options are available:
KCSAN_SANITIZE := n
.. _"Marking Shared-Memory Accesses" in the LKMM: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/memory-model/Documentation/access-marking.txt
Furthermore, it is possible to tell KCSAN to show or hide entire classes of
data races, depending on preferences. These can be changed via the following
Kconfig options:
Documentation/dev-tools/kunit/index.rst
+1
View File
@@ -14,6 +14,7 @@ KUnit - Unit Testing for the Linux Kernel
style
faq
tips
running_tips
What is KUnit?
==============
Documentation/dev-tools/kunit/kunit-tool.rst
+180 -8
View File
@@ -22,14 +22,19 @@ not require any virtualization support: it is just a regular program.
What is a .kunitconfig?
=======================
It's just a defconfig that kunit_tool looks for in the base directory.
kunit_tool uses it to generate a .config as you might expect. In addition, it
verifies that the generated .config contains the CONFIG options in the
.kunitconfig; the reason it does this is so that it is easy to be sure that a
CONFIG that enables a test actually ends up in the .config.
It's just a defconfig that kunit_tool looks for in the build directory
(``.kunit`` by default). kunit_tool uses it to generate a .config as you might
expect. In addition, it verifies that the generated .config contains the CONFIG
options in the .kunitconfig; the reason it does this is so that it is easy to
be sure that a CONFIG that enables a test actually ends up in the .config.
How do I use kunit_tool?
========================
It's also possible to pass a separate .kunitconfig fragment to kunit_tool,
which is useful if you have several different groups of tests you wish
to run independently, or if you want to use pre-defined test configs for
certain subsystems.
Getting Started with kunit_tool
===============================
If a kunitconfig is present at the root directory, all you have to do is:
@@ -48,10 +53,177 @@ However, you most likely want to use it with the following options:
.. note::
This command will work even without a .kunitconfig file: if no
.kunitconfig is present, a default one will be used instead.
.kunitconfig is present, a default one will be used instead.
If you wish to use a different .kunitconfig file (such as one provided for
testing a particular subsystem), you can pass it as an option.
.. code-block:: bash
./tools/testing/kunit/kunit.py run --kunitconfig=fs/ext4/.kunitconfig
For a list of all the flags supported by kunit_tool, you can run:
.. code-block:: bash
./tools/testing/kunit/kunit.py run --help
Configuring, Building, and Running Tests
========================================
It's also possible to run just parts of the KUnit build process independently,
which is useful if you want to make manual changes to part of the process.
A .config can be generated from a .kunitconfig by using the ``config`` argument
when running kunit_tool:
.. code-block:: bash
./tools/testing/kunit/kunit.py config
Similarly, if you just want to build a KUnit kernel from the current .config,
you can use the ``build`` argument:
.. code-block:: bash
./tools/testing/kunit/kunit.py build
And, if you already have a built UML kernel with built-in KUnit tests, you can
run the kernel and display the test results with the ``exec`` argument:
.. code-block:: bash
./tools/testing/kunit/kunit.py exec
The ``run`` command which is discussed above is equivalent to running all three
of these in sequence.
All of these commands accept a number of optional command-line arguments. The
``--help`` flag will give a complete list of these, or keep reading this page
for a guide to some of the more useful ones.
Parsing Test Results
====================
KUnit tests output their results in TAP (Test Anything Protocol) format.
kunit_tool will, when running tests, parse this output and print a summary
which is much more pleasant to read. If you wish to look at the raw test
results in TAP format, you can pass the ``--raw_output`` argument.
.. code-block:: bash
./tools/testing/kunit/kunit.py run --raw_output
.. note::
The raw output from test runs may contain other, non-KUnit kernel log
lines.
If you have KUnit results in their raw TAP format, you can parse them and print
the human-readable summary with the ``parse`` command for kunit_tool. This
accepts a filename for an argument, or will read from standard input.
.. code-block:: bash
# Reading from a file
./tools/testing/kunit/kunit.py parse /var/log/dmesg
# Reading from stdin
dmesg | ./tools/testing/kunit/kunit.py parse
This is very useful if you wish to run tests in a configuration not supported
by kunit_tool (such as on real hardware, or an unsupported architecture).
Filtering Tests
===============
It's possible to run only a subset of the tests built into a kernel by passing
a filter to the ``exec`` or ``run`` commands. For example, if you only wanted
to run KUnit resource tests, you could use:
.. code-block:: bash
./tools/testing/kunit/kunit.py run 'kunit-resource*'
This uses the standard glob format for wildcards.
Running Tests on QEMU
=====================
kunit_tool supports running tests on QEMU as well as via UML (as mentioned
elsewhere). The default way of running tests on QEMU requires two flags:
``--arch``
Selects a collection of configs (Kconfig as well as QEMU configs
options, etc) that allow KUnit tests to be run on the specified
architecture in a minimal way; this is usually not much slower than
using UML. The architecture argument is the same as the name of the
option passed to the ``ARCH`` variable used by Kbuild. Not all
architectures are currently supported by this flag, but can be handled
by the ``--qemu_config`` discussed later. If ``um`` is passed (or this
this flag is ignored) the tests will run via UML. Non-UML architectures,
e.g. i386, x86_64, arm, um, etc. Non-UML run on QEMU.
``--cross_compile``
Specifies the use of a toolchain by Kbuild. The argument passed here is
the same passed to the ``CROSS_COMPILE`` variable used by Kbuild. As a
reminder this will be the prefix for the toolchain binaries such as gcc
for example ``sparc64-linux-gnu-`` if you have the sparc toolchain
installed on your system, or
``$HOME/toolchains/microblaze/gcc-9.2.0-nolibc/microblaze-linux/bin/microblaze-linux-``
if you have downloaded the microblaze toolchain from the 0-day website
to a directory in your home directory called ``toolchains``.
In many cases it is likely that you may want to run an architecture which is
not supported by the ``--arch`` flag, or you may want to just run KUnit tests
on QEMU using a non-default configuration. For this use case, you can write
your own QemuConfig. These QemuConfigs are written in Python. They must have an
import line ``from ..qemu_config import QemuArchParams`` at the top of the file
and the file must contain a variable called ``QEMU_ARCH`` that has an instance
of ``QemuArchParams`` assigned to it. An example can be seen in
``tools/testing/kunit/qemu_configs/x86_64.py``.
Once you have a QemuConfig you can pass it into kunit_tool using the
``--qemu_config`` flag; when used this flag replaces the ``--arch`` flag. If we
were to do this with the ``x86_64.py`` example from above, the invocation would
look something like this:
.. code-block:: bash
./tools/testing/kunit/kunit.py run \
--timeout=60 \
--jobs=12 \
--qemu_config=./tools/testing/kunit/qemu_configs/x86_64.py
Other Useful Options
====================
kunit_tool has a number of other command-line arguments which can be useful
when adapting it to fit your environment or needs.
Some of the more useful ones are:
``--help``
Lists all of the available options. Note that different commands
(``config``, ``build``, ``run``, etc) will have different supported
options. Place ``--help`` before the command to list common options,
and after the command for options specific to that command.
``--build_dir``
Specifies the build directory that kunit_tool will use. This is where
the .kunitconfig file is located, as well as where the .config and
compiled kernel will be placed. Defaults to ``.kunit``.
``--make_options``
Specifies additional options to pass to ``make`` when compiling a
kernel (with the ``build`` or ``run`` commands). For example, to enable
compiler warnings, you can pass ``--make_options W=1``.
``--alltests``
Builds a UML kernel with all config options enabled using ``make
allyesconfig``. This allows you to run as many tests as is possible,
but is very slow and prone to breakage as new options are added or
modified. In most cases, enabling all tests which have satisfied
dependencies by adding ``CONFIG_KUNIT_ALL_TESTS=1`` to your
.kunitconfig is preferable.
There are several other options (and new ones are often added), so do check
``--help`` if you're looking for something not mentioned here.
Documentation/dev-tools/kunit/running_tips.rst
+259
View File
@@ -0,0 +1,259 @@
.. SPDX-License-Identifier: GPL-2.0
============================
Tips For Running KUnit Tests
============================
Using ``kunit.py run`` ("kunit tool")
=====================================
Running from any directory
--------------------------
It can be handy to create a bash function like:
.. code-block:: bash
function run_kunit() {
( cd "$(git rev-parse --show-toplevel)" && ./tools/testing/kunit/kunit.py run $@ )
}
.. note::
Early versions of ``kunit.py`` (before 5.6) didn't work unless run from
the kernel root, hence the use of a subshell and ``cd``.
Running a subset of tests
-------------------------
``kunit.py run`` accepts an optional glob argument to filter tests. Currently
this only matches against suite names, but this may change in the future.
Say that we wanted to run the sysctl tests, we could do so via:
.. code-block:: bash
$ echo -e 'CONFIG_KUNIT=y\nCONFIG_KUNIT_ALL_TESTS=y' > .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run 'sysctl*'
We're paying the cost of building more tests than we need this way, but it's
easier than fiddling with ``.kunitconfig`` files or commenting out
``kunit_suite``'s.
However, if we wanted to define a set of tests in a less ad hoc way, the next
tip is useful.
Defining a set of tests
-----------------------
``kunit.py run`` (along with ``build``, and ``config``) supports a
``--kunitconfig`` flag. So if you have a set of tests that you want to run on a
regular basis (especially if they have other dependencies), you can create a
specific ``.kunitconfig`` for them.
E.g. kunit has one for its tests:
.. code-block:: bash
$ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit/.kunitconfig
Alternatively, if you're following the convention of naming your
file ``.kunitconfig``, you can just pass in the dir, e.g.
.. code-block:: bash
$ ./tools/testing/kunit/kunit.py run --kunitconfig=lib/kunit
.. note::
This is a relatively new feature (5.12+) so we don't have any
conventions yet about on what files should be checked in versus just
kept around locally. It's up to you and your maintainer to decide if a
config is useful enough to submit (and therefore have to maintain).
.. note::
Having ``.kunitconfig`` fragments in a parent and child directory is
iffy. There's discussion about adding an "import" statement in these
files to make it possible to have a top-level config run tests from all
child directories. But that would mean ``.kunitconfig`` files are no
longer just simple .config fragments.
One alternative would be to have kunit tool recursively combine configs
automagically, but tests could theoretically depend on incompatible
options, so handling that would be tricky.
Generating code coverage reports under UML
------------------------------------------
.. note::
TODO(brendanhiggins@google.com): There are various issues with UML and
versions of gcc 7 and up. You're likely to run into missing ``.gcda``
files or compile errors. We know one `faulty GCC commit
<https://github.com/gcc-mirror/gcc/commit/8c9434c2f9358b8b8bad2c1990edf10a21645f9d>`_
but not how we'd go about getting this fixed. The compile errors still
need some investigation.
.. note::
TODO(brendanhiggins@google.com): for recent versions of Linux
(5.10-5.12, maybe earlier), there's a bug with gcov counters not being
flushed in UML. This translates to very low (<1%) reported coverage. This is
related to the above issue and can be worked around by replacing the
one call to ``uml_abort()`` (it's in ``os_dump_core()``) with a plain
``exit()``.
This is different from the "normal" way of getting coverage information that is
documented in Documentation/dev-tools/gcov.rst.
Instead of enabling ``CONFIG_GCOV_KERNEL=y``, we can set these options:
.. code-block:: none
CONFIG_DEBUG_KERNEL=y
CONFIG_DEBUG_INFO=y
CONFIG_GCOV=y
Putting it together into a copy-pastable sequence of commands:
.. code-block:: bash
# Append coverage options to the current config
$ echo -e "CONFIG_DEBUG_KERNEL=y\nCONFIG_DEBUG_INFO=y\nCONFIG_GCOV=y" >> .kunit/.kunitconfig
$ ./tools/testing/kunit/kunit.py run
# Extract the coverage information from the build dir (.kunit/)
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/
# From here on, it's the same process as with CONFIG_GCOV_KERNEL=y
# E.g. can generate an HTML report in a tmp dir like so:
$ genhtml -o /tmp/coverage_html coverage.info
If your installed version of gcc doesn't work, you can tweak the steps:
.. code-block:: bash
$ ./tools/testing/kunit/kunit.py run --make_options=CC=/usr/bin/gcc-6
$ lcov -t "my_kunit_tests" -o coverage.info -c -d .kunit/ --gcov-tool=/usr/bin/gcov-6
Running tests manually
======================
Running tests without using ``kunit.py run`` is also an important use case.
Currently it's your only option if you want to test on architectures other than
UML.
As running the tests under UML is fairly straightforward (configure and compile
the kernel, run the ``./linux`` binary), this section will focus on testing
non-UML architectures.
Running built-in tests
----------------------
When setting tests to ``=y``, the tests will run as part of boot and print
results to dmesg in TAP format. So you just need to add your tests to your
``.config``, build and boot your kernel as normal.
So if we compiled our kernel with:
.. code-block:: none
CONFIG_KUNIT=y
CONFIG_KUNIT_EXAMPLE_TEST=y
Then we'd see output like this in dmesg signaling the test ran and passed:
.. code-block:: none
TAP version 14
1..1
# Subtest: example
1..1
# example_simple_test: initializing
ok 1 - example_simple_test
ok 1 - example
Running tests as modules
------------------------
Depending on the tests, you can build them as loadable modules.
For example, we'd change the config options from before to
.. code-block:: none
CONFIG_KUNIT=y
CONFIG_KUNIT_EXAMPLE_TEST=m
Then after booting into our kernel, we can run the test via
.. code-block:: none
$ modprobe kunit-example-test
This will then cause it to print TAP output to stdout.
.. note::
The ``modprobe`` will *not* have a non-zero exit code if any test
failed (as of 5.13). But ``kunit.py parse`` would, see below.
.. note::
You can set ``CONFIG_KUNIT=m`` as well, however, some features will not
work and thus some tests might break. Ideally tests would specify they
depend on ``KUNIT=y`` in their ``Kconfig``'s, but this is an edge case
most test authors won't think about.
As of 5.13, the only difference is that ``current->kunit_test`` will
not exist.
Pretty-printing results
-----------------------
You can use ``kunit.py parse`` to parse dmesg for test output and print out
results in the same familiar format that ``kunit.py run`` does.
.. code-block:: bash
$ ./tools/testing/kunit/kunit.py parse /var/log/dmesg
Retrieving per suite results
----------------------------
Regardless of how you're running your tests, you can enable
``CONFIG_KUNIT_DEBUGFS`` to expose per-suite TAP-formatted results:
.. code-block:: none
CONFIG_KUNIT=y
CONFIG_KUNIT_EXAMPLE_TEST=m
CONFIG_KUNIT_DEBUGFS=y
The results for each suite will be exposed under
``/sys/kernel/debug/kunit/<suite>/results``.
So using our example config:
.. code-block:: bash
$ modprobe kunit-example-test > /dev/null
$ cat /sys/kernel/debug/kunit/example/results
... <TAP output> ...
# After removing the module, the corresponding files will go away
$ modprobe -r kunit-example-test
$ cat /sys/kernel/debug/kunit/example/results
/sys/kernel/debug/kunit/example/results: No such file or directory
Generating code coverage reports
--------------------------------
See Documentation/dev-tools/gcov.rst for details on how to do this.
The only vaguely KUnit-specific advice here is that you probably want to build
your tests as modules. That way you can isolate the coverage from tests from
other code executed during boot, e.g.
.. code-block:: bash
# Reset coverage counters before running the test.
$ echo 0 > /sys/kernel/debug/gcov/reset
$ modprobe kunit-example-test
Documentation/dev-tools/kunit/start.rst
+3 -1
View File
@@ -36,7 +36,7 @@ A good starting point for a ``.kunitconfig`` is the KUnit defconfig:
.. code-block:: bash
cd $PATH_TO_LINUX_REPO
cp arch/um/configs/kunit_defconfig .kunitconfig
cp tools/testing/kunit/configs/default.config .kunitconfig
You can then add any other Kconfig options you wish, e.g.:
@@ -236,5 +236,7 @@ Next Steps
==========
* Check out the Documentation/dev-tools/kunit/tips.rst page for tips on
writing idiomatic KUnit tests.
* Check out the :doc:`running_tips` page for tips on
how to make running KUnit tests easier.
* Optional: see the :doc:`usage` page for a more
in-depth explanation of KUnit.
Documentation/dev-tools/kunit/usage.rst
+41 -14
View File
@@ -467,10 +467,9 @@ fictitious example for ``sha1sum(1)``
.. code-block:: c
/* Note: the cast is to satisfy overly strict type-checking. */
#define TEST_SHA1(in, want) \
sha1sum(in, out); \
KUNIT_EXPECT_STREQ_MSG(test, (char *)out, want, "sha1sum(%s)", in);
KUNIT_EXPECT_STREQ_MSG(test, out, want, "sha1sum(%s)", in);
char out[40];
TEST_SHA1("hello world", "2aae6c35c94fcfb415dbe95f408b9ce91ee846ed");
@@ -509,7 +508,7 @@ In some cases, it can be helpful to write a *table-driven test* instead, e.g.
};
for (i = 0; i < ARRAY_SIZE(cases); ++i) {
sha1sum(cases[i].str, out);
KUNIT_EXPECT_STREQ_MSG(test, (char *)out, cases[i].sha1,
KUNIT_EXPECT_STREQ_MSG(test, out, cases[i].sha1,
"sha1sum(%s)", cases[i].str);
}
@@ -570,7 +569,7 @@ Reusing the same ``cases`` array from above, we can write the test as a
struct sha1_test_case *test_param = (struct sha1_test_case *)(test->param_value);
sha1sum(test_param->str, out);
KUNIT_EXPECT_STREQ_MSG(test, (char *)out, test_param->sha1,
KUNIT_EXPECT_STREQ_MSG(test, out, test_param->sha1,
"sha1sum(%s)", test_param->str);
}
@@ -611,17 +610,45 @@ non-UML architectures:
None of these are reasons not to run your KUnit tests on real hardware; they are
only things to be aware of when doing so.
The biggest impediment will likely be that certain KUnit features and
infrastructure may not support your target environment. For example, at this
time the KUnit Wrapper (``tools/testing/kunit/kunit.py``) does not work outside
of UML. Unfortunately, there is no way around this. Using UML (or even just a
particular architecture) allows us to make a lot of assumptions that make it
possible to do things which might otherwise be impossible.
Currently, the KUnit Wrapper (``tools/testing/kunit/kunit.py``) (aka
kunit_tool) only fully supports running tests inside of UML and QEMU; however,
this is only due to our own time limitations as humans working on KUnit. It is
entirely possible to support other emulators and even actual hardware, but for
now QEMU and UML is what is fully supported within the KUnit Wrapper. Again, to
be clear, this is just the Wrapper. The actualy KUnit tests and the KUnit
library they are written in is fully architecture agnostic and can be used in
virtually any setup, you just won't have the benefit of typing a single command
out of the box and having everything magically work perfectly.
Nevertheless, all core KUnit framework features are fully supported on all
architectures, and using them is straightforward: all you need to do is to take
your kunitconfig, your Kconfig options for the tests you would like to run, and
merge them into whatever config your are using for your platform. That's it!
Again, all core KUnit framework features are fully supported on all
architectures, and using them is straightforward: Most popular architectures
are supported directly in the KUnit Wrapper via QEMU. Currently, supported
architectures on QEMU include:
* i386
* x86_64
* arm
* arm64
* alpha
* powerpc
* riscv
* s390
* sparc
In order to run KUnit tests on one of these architectures via QEMU with the
KUnit wrapper, all you need to do is specify the flags ``--arch`` and
``--cross_compile`` when invoking the KUnit Wrapper. For example, we could run
the default KUnit tests on ARM in the following manner (assuming we have an ARM
toolchain installed):
.. code-block:: bash
tools/testing/kunit/kunit.py run --timeout=60 --jobs=12 --arch=arm --cross_compile=arm-linux-gnueabihf-
Alternatively, if you want to run your tests on real hardware or in some other
emulation environment, all you need to do is to take your kunitconfig, your
Kconfig options for the tests you would like to run, and merge them into
whatever config your are using for your platform. That's it!
For example, let's say you have the following kunitconfig:
Documentation/devicetree/bindings/arm/amlogic,scpi.txt
-27
View File
@@ -1,27 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
----------------------------------------------------------
Required properties
- compatible : should be "amlogic,meson-gxbb-scpi"
AMLOGIC SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "amlogic,meson-gxbb-sram"
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- compatible : should be "amlogic,meson-gxbb-scp-shmem" for SRAM based shared
memory on Amlogic GXBB SoC.
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "amlogic,meson-gxbb-scpi-sensors".
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
Documentation/devicetree/bindings/arm/arm,scmi.txt
-239
View File
@@ -1,239 +0,0 @@
System Control and Management Interface (SCMI) Message Protocol
----------------------------------------------------------
The SCMI is intended to allow agents such as OSPM to manage various functions
that are provided by the hardware platform it is running on, including power
and performance functions.
This binding is intended to define the interface the firmware implementing
the SCMI as described in ARM document number ARM DEN 0056A ("ARM System Control
and Management Interface Platform Design Document")[0] provide for OSPM in
the device tree.
Required properties:
The scmi node with the following properties shall be under the /firmware/ node.
- compatible : shall be "arm,scmi" or "arm,scmi-smc" for smc/hvc transports
- mboxes: List of phandle and mailbox channel specifiers. It should contain
exactly one or two mailboxes, one for transmitting messages("tx")
and another optional for receiving the notifications("rx") if
supported.
- shmem : List of phandle pointing to the shared memory(SHM) area as per
generic mailbox client binding.
- #address-cells : should be '1' if the device has sub-nodes, maps to
protocol identifier for a given sub-node.
- #size-cells : should be '0' as 'reg' property doesn't have any size
associated with it.
- arm,smc-id : SMC id required when using smc or hvc transports
Optional properties:
- mbox-names: shall be "tx" or "rx" depending on mboxes entries.
- interrupts : when using smc or hvc transports, this optional
property indicates that msg completion by the platform is indicated
by an interrupt rather than by the return of the smc call. This
should not be used except when the platform requires such behavior.
- interrupt-names : if "interrupts" is present, interrupt-names must also
be present and have the value "a2p".
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings.
The mailbox is the only permitted method of calling the SCMI firmware.
Mailbox doorbell is used as a mechanism to alert the presence of a
messages and/or notification.
Each protocol supported shall have a sub-node with corresponding compatible
as described in the following sections. If the platform supports dedicated
communication channel for a particular protocol, the 3 properties namely:
mboxes, mbox-names and shmem shall be present in the sub-node corresponding
to that protocol.
Clock/Performance bindings for the clocks/OPPs based on SCMI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Required properties:
- #clock-cells : Should be 1. Contains the Clock ID value used by SCMI commands.
Power domain bindings for the power domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI power domain providers uses the generic power
domain binding[2].
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCMI commands.
Regulator bindings for the SCMI Regulator based on SCMI Message Protocol
------------------------------------------------------------
An SCMI Regulator is permanently bound to a well defined SCMI Voltage Domain,
and should be always positioned as a root regulator.
It does not support any current operation.
SCMI Regulators are grouped under a 'regulators' node which in turn is a child
of the SCMI Voltage protocol node inside the desired SCMI instance node.
This binding uses the common regulator binding[6].
Required properties:
- reg : shall identify an existent SCMI Voltage Domain.
Sensor bindings for the sensors based on SCMI Message Protocol
--------------------------------------------------------------
SCMI provides an API to access the various sensors on the SoC.
Required properties:
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[3].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Reset signal bindings for the reset domains based on SCMI Message Protocol
------------------------------------------------------------
This binding for the SCMI reset domain providers uses the generic reset
signal binding[5].
Required properties:
- #reset-cells : Should be 1. Contains the reset domain ID value used
by SCMI commands.
SRAM and Shared Memory for SCMI
-------------------------------
A small area of SRAM is reserved for SCMI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [4]
Each sub-node represents the reserved area for SCMI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scmi-shmem" for Non-secure SRAM based
shared memory
[0] http://infocenter.arm.com/help/topic/com.arm.doc.den0056a/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/power/power-domain.yaml
[3] Documentation/devicetree/bindings/thermal/thermal*.yaml
[4] Documentation/devicetree/bindings/sram/sram.yaml
[5] Documentation/devicetree/bindings/reset/reset.txt
[6] Documentation/devicetree/bindings/regulator/regulator.yaml
Example:
sram@50000000 {
compatible = "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,scmi-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,scmi-shmem";
reg = <0x200 0x200>;
};
};
mailbox@40000000 {
....
#mbox-cells = <1>;
reg = <0x0 0x40000000 0x0 0x10000>;
};
firmware {
...
scmi {
compatible = "arm,scmi";
mboxes = <&mailbox 0 &mailbox 1>;
mbox-names = "tx", "rx";
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
#address-cells = <1>;
#size-cells = <0>;
scmi_devpd: protocol@11 {
reg = <0x11>;
#power-domain-cells = <1>;
};
scmi_dvfs: protocol@13 {
reg = <0x13>;
#clock-cells = <1>;
};
scmi_clk: protocol@14 {
reg = <0x14>;
#clock-cells = <1>;
};
scmi_sensors0: protocol@15 {
reg = <0x15>;
#thermal-sensor-cells = <1>;
};
scmi_reset: protocol@16 {
reg = <0x16>;
#reset-cells = <1>;
};
scmi_voltage: protocol@17 {
reg = <0x17>;
regulators {
regulator_devX: regulator@0 {
reg = <0x0>;
regulator-max-microvolt = <3300000>;
};
regulator_devY: regulator@9 {
reg = <0x9>;
regulator-min-microvolt = <500000>;
regulator-max-microvolt = <4200000>;
};
...
};
};
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scmi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scmi_clk 4>;
power-domains = <&scmi_devpd 1>;
resets = <&scmi_reset 10>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scmi_sensors0 3>;
...
};
};
Documentation/devicetree/bindings/arm/arm,scpi.txt
-219
View File
@@ -1,219 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
----------------------------------------------------------
Firmware implementing the SCPI described in ARM document number ARM DUI 0922B
("ARM Compute Subsystem SCP: Message Interface Protocols")[0] can be used
by Linux to initiate various system control and power operations.
Required properties:
- compatible : should be
* "arm,scpi" : For implementations complying to SCPI v1.0 or above
* "arm,scpi-pre-1.0" : For implementations complying to all
unversioned releases prior to SCPI v1.0
- mboxes: List of phandle and mailbox channel specifiers
All the channels reserved by remote SCP firmware for use by
SCPI message protocol should be specified in any order
- shmem : List of phandle pointing to the shared memory(SHM) area between the
processors using these mailboxes for IPC, one for each mailbox
SHM can be any memory reserved for the purpose of this communication
between the processors.
See Documentation/devicetree/bindings/mailbox/mailbox.txt
for more details about the generic mailbox controller and
client driver bindings.
Clock bindings for the clocks based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the common clock binding[1].
Container Node
==============
Required properties:
- compatible : should be "arm,scpi-clocks"
All the clocks provided by SCP firmware via SCPI message
protocol much be listed as sub-nodes under this node.
Sub-nodes
=========
Required properties:
- compatible : shall include one of the following
"arm,scpi-dvfs-clocks" - all the clocks that are variable and index based.
These clocks don't provide an entire range of values between the
limits but only discrete points within the range. The firmware
provides the mapping for each such operating frequency and the
index associated with it. The firmware also manages the
voltage scaling appropriately with the clock scaling.
"arm,scpi-variable-clocks" - all the clocks that are variable and provide full
range within the specified range. The firmware provides the
range of values within a specified range.
Other required properties for all clocks(all from common clock binding):
- #clock-cells : Should be 1. Contains the Clock ID value used by SCPI commands.
- clock-output-names : shall be the corresponding names of the outputs.
- clock-indices: The identifying number for the clocks(i.e.clock_id) in the
node. It can be non linear and hence provide the mapping of identifiers
into the clock-output-names array.
SRAM and Shared Memory for SCPI
-------------------------------
A small area of SRAM is reserved for SCPI communication between application
processors and SCP.
The properties should follow the generic mmio-sram description found in [3]
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,scp-shmem" for Non-secure SRAM based
shared memory
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
SCPI provides an API to access the various sensors on the SoC.
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1. This property follows the
thermal device tree bindings[2].
Valid cell values are raw identifiers (Sensor ID)
as used by the firmware. Refer to platform details
for your implementation for the IDs to use.
Power domain bindings for the power domains based on SCPI Message Protocol
------------------------------------------------------------
This binding uses the generic power domain binding[4].
PM domain providers
===================
Required properties:
- #power-domain-cells : Should be 1. Contains the device or the power
domain ID value used by SCPI commands.
- num-domains: Total number of power domains provided by SCPI. This is
needed as the SCPI message protocol lacks a mechanism to
query this information at runtime.
PM domain consumers
===================
Required properties:
- power-domains : A phandle and PM domain specifier as defined by bindings of
the power controller specified by phandle.
[0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
[2] Documentation/devicetree/bindings/thermal/thermal*.yaml
[3] Documentation/devicetree/bindings/sram/sram.yaml
[4] Documentation/devicetree/bindings/power/power-domain.yaml
Example:
sram: sram@50000000 {
compatible = "arm,juno-sram-ns", "mmio-sram";
reg = <0x0 0x50000000 0x0 0x10000>;
#address-cells = <1>;
#size-cells = <1>;
ranges = <0 0x0 0x50000000 0x10000>;
cpu_scp_lpri: scp-shmem@0 {
compatible = "arm,juno-scp-shmem";
reg = <0x0 0x200>;
};
cpu_scp_hpri: scp-shmem@200 {
compatible = "arm,juno-scp-shmem";
reg = <0x200 0x200>;
};
};
mailbox: mailbox0@40000000 {
....
#mbox-cells = <1>;
};
scpi_protocol: scpi@2e000000 {
compatible = "arm,scpi";
mboxes = <&mailbox 0 &mailbox 1>;
shmem = <&cpu_scp_lpri &cpu_scp_hpri>;
clocks {
compatible = "arm,scpi-clocks";
scpi_dvfs: scpi_clocks@0 {
compatible = "arm,scpi-dvfs-clocks";
#clock-cells = <1>;
clock-indices = <0>, <1>, <2>;
clock-output-names = "atlclk", "aplclk","gpuclk";
};
scpi_clk: scpi_clocks@3 {
compatible = "arm,scpi-variable-clocks";
#clock-cells = <1>;
clock-indices = <3>, <4>;
clock-output-names = "pxlclk0", "pxlclk1";
};
};
scpi_sensors0: sensors {
compatible = "arm,scpi-sensors";
#thermal-sensor-cells = <1>;
};
scpi_devpd: scpi-power-domains {
compatible = "arm,scpi-power-domains";
num-domains = <2>;
#power-domain-cells = <1>;
};
};
cpu@0 {
...
reg = <0 0>;
clocks = <&scpi_dvfs 0>;
};
hdlcd@7ff60000 {
...
reg = <0 0x7ff60000 0 0x1000>;
clocks = <&scpi_clk 4>;
power-domains = <&scpi_devpd 1>;
};
thermal-zones {
soc_thermal {
polling-delay-passive = <100>;
polling-delay = <1000>;
/* sensor ID */
thermal-sensors = <&scpi_sensors0 3>;
...
};
};
In the above example, the #clock-cells is set to 1 as required.
scpi_dvfs has 3 output clocks namely: atlclk, aplclk, and gpuclk with 0,
1 and 2 as clock-indices. scpi_clk has 2 output clocks namely: pxlclk0
and pxlclk1 with 3 and 4 as clock-indices.
The first consumer in the example is cpu@0 and it has '0' as the clock
specifier which points to the first entry in the output clocks of
scpi_dvfs i.e. "atlclk".
Similarly the second example is hdlcd@7ff60000 and it has pxlclk1 as input
clock. '4' in the clock specifier here points to the second entry
in the output clocks of scpi_clocks i.e. "pxlclk1"
The thermal-sensors property in the soc_thermal node uses the
temperature sensor provided by SCP firmware to setup a thermal
zone. The ID "3" is the sensor identifier for the temperature sensor
as used by the firmware.
The num-domains property in scpi-power-domains domain specifies that
SCPI provides 2 power domains. The hdlcd node uses the power domain with
domain ID 1.
Documentation/devicetree/bindings/arm/arm,scu.yaml
+46
View File
@@ -0,0 +1,46 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/arm,scu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ARM Snoop Control Unit (SCU)
maintainers:
- Linus Walleij <linus.walleij@linaro.org>
description: |
As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
with a Snoop Control Unit. The register range is usually 256 (0x100)
bytes.
References:
- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
Revision r2p0
- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
Revision r0p1
- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
Manial Revision r2p0
properties:
compatible:
enum:
- arm,cortex-a9-scu
- arm,cortex-a5-scu
- arm,arm11mp-scu
reg:
maxItems: 1
required:
- compatible
- reg
additionalProperties: false
examples:
- |
scu@a0410000 {
compatible = "arm,cortex-a9-scu";
reg = <0xa0410000 0x100>;
};
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt
-31
View File
@@ -1,31 +0,0 @@
OP-TEE Device Tree Bindings
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
* OP-TEE based on ARM TrustZone required properties:
- compatible : should contain "linaro,optee-tz"
- method : The method of calling the OP-TEE Trusted OS. Permitted
values are:
"smc" : SMC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
"hvc" : HVC #0, with the register assignments specified
in drivers/tee/optee/optee_smc.h
Example:
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml
+58
View File
@@ -0,0 +1,58 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/firmware/linaro,optee-tz.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: OP-TEE Device Tree Bindings
maintainers:
- Jens Wiklander <jens.wiklander@linaro.org>
description: |
OP-TEE is a piece of software using hardware features to provide a Trusted
Execution Environment. The security can be provided with ARM TrustZone, but
also by virtualization or a separate chip.
We're using "linaro" as the first part of the compatible property for
the reference implementation maintained by Linaro.
properties:
$nodename:
const: optee
compatible:
const: linaro,optee-tz
method:
enum: [smc, hvc]
description: |
The method of calling the OP-TEE Trusted OS depending on smc or hvc
instruction usage.
SMC #0, register assignments
or
HVC #0, register assignments
register assignments are specified in drivers/tee/optee/optee_smc.h
required:
- compatible
- method
additionalProperties: false
examples:
- |
firmware {
optee {
compatible = "linaro,optee-tz";
method = "smc";
};
};
- |
firmware {
optee {
compatible = "linaro,optee-tz";
method = "hvc";
};
};
Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt
+4 -6
View File
@@ -86,13 +86,11 @@ This binding uses the common clock binding[1].
Required properties:
- compatible: Should be one of:
"fsl,imx8qm-clock"
"fsl,imx8qxp-clock"
"fsl,imx8qm-clk"
"fsl,imx8qxp-clk"
followed by "fsl,scu-clk"
- #clock-cells: Should be either
2: Contains the Resource and Clock ID value.
or
1: Contains the Clock ID value. (DEPRECATED)
- #clock-cells: Should be 2.
Contains the Resource and Clock ID value.
- clocks: List of clock specifiers, must contain an entry for
each required entry in clock-names
- clock-names: Should include entries "xtal_32KHz", "xtal_24MHz"
Documentation/devicetree/bindings/arm/intel,keembay.yaml
+2
View File
@@ -11,6 +11,8 @@ maintainers:
- Daniele Alessandrelli <daniele.alessandrelli@intel.com>
properties:
$nodename:
const: '/'
compatible:
items:
- enum:
Documentation/devicetree/bindings/arm/juno,scpi.txt
-26
View File
@@ -1,26 +0,0 @@
System Control and Power Interface (SCPI) Message Protocol
(in addition to the standard binding in [0])
Juno SRAM and Shared Memory for SCPI
------------------------------------
Required properties:
- compatible : should be "arm,juno-sram-ns" for Non-secure SRAM
Each sub-node represents the reserved area for SCPI.
Required sub-node properties:
- reg : The base offset and size of the reserved area with the SRAM
- compatible : should be "arm,juno-scp-shmem" for Non-secure SRAM based
shared memory on Juno platforms
Sensor bindings for the sensors based on SCPI Message Protocol
--------------------------------------------------------------
Required properties:
- compatible : should be "arm,scpi-sensors".
- #thermal-sensor-cells: should be set to 1.
For Juno R0 and Juno R1 refer to [1] for the
sensor identifiers
[0] Documentation/devicetree/bindings/arm/arm,scpi.txt
[1] http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0922b/apas03s22.html
Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
-86
View File
@@ -1,86 +0,0 @@
Texas Instruments System Control Interface (TI-SCI) Message Protocol
--------------------------------------------------------------------
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
TI-SCI controller Device Node:
=============================
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
Required properties:
-------------------
- compatible: should be "ti,k2g-sci" for TI 66AK2G SoC
should be "ti,am654-sci" for for TI AM654 SoC
- mbox-names:
"rx" - Mailbox corresponding to receive path
"tx" - Mailbox corresponding to transmit path
- mboxes: Mailboxes corresponding to the mbox-names. Each value of the mboxes
property should contain a phandle to the mailbox controller device
node and an args specifier that will be the phandle to the intended
sub-mailbox child node to be used for communication.
See Documentation/devicetree/bindings/mailbox/mailbox.txt for more details
about the generic mailbox controller and client driver bindings. Also see
Documentation/devicetree/bindings/mailbox/ti,message-manager.txt for typical
controller that is used to communicate with this System controllers.
Optional Properties:
-------------------
- reg-names:
debug_messages - Map the Debug message region
- reg: register space corresponding to the debug_messages
- ti,system-reboot-controller: If system reboot can be triggered by SoC reboot
- ti,host-id: Integer value corresponding to the host ID assigned by Firmware
for identification of host processing entities such as virtual
machines
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
ti,host-id = <2>;
mbox-names = "rx", "tx";
mboxes= <&msgmgr &msgmgr_proxy_pmmc_rx>,
<&msgmgr &msgmgr_proxy_pmmc_tx>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
TI-SCI Client Device Node:
=========================
Client nodes are maintained as children of the relevant TI-SCI device node.
Example (K2G):
-------------
pmmc: pmmc {
compatible = "ti,k2g-sci";
...
my_clk_node: clk_node {
...
...
};
my_pd_node: pd_node {
...
...
};
};
Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml
+129
View File
@@ -0,0 +1,129 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/arm/keystone/ti,sci.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI-SCI controller device node bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
Texas Instrument's processors including those belonging to Keystone generation
of processors have separate hardware entity which is now responsible for the
management of the System on Chip (SoC) system. These include various system
level functions as well.
An example of such an SoC is K2G, which contains the system control hardware
block called Power Management Micro Controller (PMMC). This hardware block is
initialized early into boot process and provides services to Operating Systems
on multiple processors including ones running Linux.
See http://processors.wiki.ti.com/index.php/TISCI for protocol definition.
The TI-SCI node describes the Texas Instrument's System Controller entity node.
This parent node may optionally have additional children nodes which describe
specific functionality such as clocks, power domain, reset or additional
functionality as may be required for the SoC. This hierarchy also describes the
relationship between the TI-SCI parent node to the child node.
properties:
$nodename:
pattern: "^system-controller@[0-9a-f]+$"
compatible:
oneOf:
- description: System controller on TI 66AK2G SoC and other K3 SoCs
items:
- const: ti,k2g-sci
- description: System controller on TI AM654 SoC
items:
- const: ti,am654-sci
reg-names:
description: |
Specifies the debug messages memory mapped region that is optionally
made available from TI-SCI controller.
const: debug_messages
reg:
minItems: 1
mbox-names:
description: |
Specifies the mailboxes used to communicate with TI-SCI Controller
made available from TI-SCI controller.
items:
- const: rx
- const: tx
mboxes:
minItems: 2
ti,system-reboot-controller:
description: Determines If system reboot can be triggered by SoC reboot
type: boolean
ti,host-id:
$ref: /schemas/types.yaml#/definitions/uint32
description: |
Value corresponding to the host ID assigned by Firmware
for identification of host processing entities such as virtual machines.
power-controller:
type: object
$ref: /schemas/soc/ti/sci-pm-domain.yaml#
clock-controller:
type: object
$ref: /schemas/clock/ti,sci-clk.yaml#
reset-controller:
type: object
$ref: /schemas/reset/ti,sci-reset.yaml#
required:
- compatible
- mbox-names
- mboxes
additionalProperties: false
examples:
- |
pmmc: system-controller@2921800 {
compatible = "ti,k2g-sci";
ti,system-reboot-controller;
mbox-names = "rx", "tx";
mboxes= <&msgmgr 5 2>,
<&msgmgr 0 0>;
reg-names = "debug_messages";
reg = <0x02921800 0x800>;
};
- |
dmsc: system-controller@44083000 {
compatible = "ti,k2g-sci";
ti,host-id = <12>;
mbox-names = "rx", "tx";
mboxes= <&secure_proxy_main 11>,
<&secure_proxy_main 13>;
reg-names = "debug_messages";
reg = <0x44083000 0x1000>;
k3_pds: power-controller {
compatible = "ti,sci-pm-domain";
#power-domain-cells = <2>;
};
k3_clks: clock-controller {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
k3_reset: reset-controller {
compatible = "ti,sci-reset";
#reset-cells = <2>;
};
};
Documentation/devicetree/bindings/arm/scu.txt
-28
View File
@@ -1,28 +0,0 @@
* ARM Snoop Control Unit (SCU)
As part of the MPCore complex, Cortex-A5 and Cortex-A9 are provided
with a Snoop Control Unit. The register range is usually 256 (0x100)
bytes.
References:
- Cortex-A9: see DDI0407E Cortex-A9 MPCore Technical Reference Manual
Revision r2p0
- Cortex-A5: see DDI0434B Cortex-A5 MPCore Technical Reference Manual
Revision r0p1
- ARM11 MPCore: see DDI0360F ARM 11 MPCore Processor Technical Reference
Manial Revision r2p0
- compatible : Should be:
"arm,cortex-a9-scu"
"arm,cortex-a5-scu"
"arm,arm11mp-scu"
- reg : Specify the base address and the size of the SCU register window.
Example:
scu@a0410000 {
compatible = "arm,cortex-a9-scu";
reg = <0xa0410000 0x100>;
};
Documentation/devicetree/bindings/arm/ux500/boards.txt
+2 -2
View File
@@ -20,13 +20,13 @@ during retention, system won't boot without this):
compatible = "ste,dbx500-backupram"
scu:
see binding for arm/scu.txt
see binding for arm/arm,scu.yaml
interrupt-controller:
see binding for interrupt-controller/arm,gic.txt
timer:
see binding for timer/arm,twd.txt
see binding for timer/arm,twd-timer.yaml
clocks:
see binding for clocks/ux500.txt
Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml
-1
View File
@@ -20,7 +20,6 @@ properties:
reg:
minItems: 2
maxItems: 3
items:
- description: AHCI registers
- description: SATA configuration and IPFS registers
Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml
+11
View File
@@ -53,6 +53,17 @@ required:
- reg
- interrupts
- clocks
- power-domains
if:
not:
properties:
compatible:
contains:
const: renesas,sata-r8a7779
then:
required:
- resets
additionalProperties: false
Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml
-2
View File
@@ -51,7 +51,6 @@ properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: High Frequency Oscillator (usually at 24MHz)
- description: Low Frequency Oscillator (usually at 32kHz)
@@ -60,7 +59,6 @@ properties:
clock-names:
minItems: 2
maxItems: 4
items:
- const: hosc
- const: losc
Documentation/devicetree/bindings/clock/gpio-mux-clock.txt
-19
View File
@@ -1,19 +0,0 @@
Binding for simple gpio clock multiplexer.
This binding uses the common clock binding[1].
[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
Required properties:
- compatible : shall be "gpio-mux-clock".
- clocks: list of two references to parent clocks.
- #clock-cells : from common clock binding; shall be set to 0.
- select-gpios : GPIO reference for selecting the parent clock.
Example:
clock {
compatible = "gpio-mux-clock";
clocks = <&parentclk1>, <&parentclk2>;
#clock-cells = <0>;
select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
};
Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml
+45
View File
@@ -0,0 +1,45 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/gpio-mux-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Simple GPIO clock multiplexer
maintainers:
- Sergej Sawazki <ce3a@gmx.de>
properties:
compatible:
const: gpio-mux-clock
clocks:
items:
- description: First parent clock
- description: Second parent clock
'#clock-cells':
const: 0
select-gpios:
description: GPIO reference for selecting the parent clock.
maxItems: 1
required:
- compatible
- clocks
- '#clock-cells'
- select-gpios
additionalProperties: false
examples:
- |
#include <dt-bindings/gpio/gpio.h>
clock {
compatible = "gpio-mux-clock";
clocks = <&parentclk1>, <&parentclk2>;
#clock-cells = <0>;
select-gpios = <&gpio 1 GPIO_ACTIVE_HIGH>;
};
Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml
+59
View File
@@ -0,0 +1,59 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/hisilicon,hi3559av100-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Hisilicon SOC Clock for HI3559AV100
maintainers:
- Dongjiu Geng <gengdongjiu@huawei.com>
description: |
Hisilicon SOC clock control module which supports the clocks, resets and
power domains on HI3559AV100.
See also:
dt-bindings/clock/hi3559av100-clock.h
properties:
compatible:
enum:
- hisilicon,hi3559av100-clock
- hisilicon,hi3559av100-shub-clock
reg:
minItems: 1
maxItems: 2
'#clock-cells':
const: 1
'#reset-cells':
const: 2
description: |
First cell is reset request register offset.
Second cell is bit offset in reset request register.
required:
- compatible
- reg
- '#clock-cells'
- '#reset-cells'
additionalProperties: false
examples:
- |
soc {
#address-cells = <2>;
#size-cells = <2>;
clock-controller@12010000 {
compatible = "hisilicon,hi3559av100-clock";
#clock-cells = <1>;
#reset-cells = <2>;
reg = <0x0 0x12010000 0x0 0x10000>;
};
};
...
Documentation/devicetree/bindings/clock/idt,versaclock5.yaml
+4 -3
View File
@@ -84,6 +84,7 @@ patternProperties:
idt,slew-percent:
description: The Slew rate control for CMOS single-ended.
enum: [ 80, 85, 90, 100 ]
additionalProperties: false
required:
- compatible
@@ -139,13 +140,13 @@ examples:
clock-names = "xin";
OUT1 {
idt,drive-mode = <VC5_CMOSD>;
idt,voltage-microvolts = <1800000>;
idt,mode = <VC5_CMOSD>;
idt,voltage-microvolt = <1800000>;
idt,slew-percent = <80>;
};
OUT4 {
idt,drive-mode = <VC5_LVDS>;
idt,mode = <VC5_LVDS>;
};
};
};
Documentation/devicetree/bindings/clock/ingenic,cgu.yaml
+6
View File
@@ -22,6 +22,8 @@ select:
enum:
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
- ingenic,jz4760-cgu
- ingenic,jz4760b-cgu
- ingenic,jz4770-cgu
- ingenic,jz4780-cgu
- ingenic,x1000-cgu
@@ -49,6 +51,8 @@ properties:
- enum:
- ingenic,jz4740-cgu
- ingenic,jz4725b-cgu
- ingenic,jz4760-cgu
- ingenic,jz4760b-cgu
- ingenic,jz4770-cgu
- ingenic,jz4780-cgu
- ingenic,x1000-cgu
@@ -93,6 +97,8 @@ required:
patternProperties:
"^usb-phy@[a-f0-9]+$":
allOf: [ $ref: "../phy/ingenic,phy-usb.yaml#" ]
"^mac-phy-ctrl@[a-f0-9]+$":
allOf: [ $ref: "../net/ingenic,mac.yaml#" ]
additionalProperties: false
Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml
+68
View File
@@ -0,0 +1,68 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,camcc-sm8250.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Camera Clock & Reset Controller Binding for SM8250
maintainers:
- Jonathan Marek <jonathan@marek.ca>
description: |
Qualcomm camera clock control module which supports the clocks, resets and
power domains on SM8250.
See also dt-bindings/clock/qcom,camcc-sm8250.h
properties:
compatible:
const: qcom,sm8250-camcc
clocks:
items:
- description: Board XO source
- description: Sleep clock source
clock-names:
items:
- const: bi_tcxo
- const: sleep_clk
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmh.h>
clock-controller@ad00000 {
compatible = "qcom,sm8250-camcc";
reg = <0x0ad00000 0x10000>;
clocks = <&rpmhcc RPMH_CXO_CLK>,
<&sleep_clk>;
clock-names = "bi_tcxo", "sleep_clk";
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
};
...
Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml
+1
View File
@@ -20,6 +20,7 @@ description: |
properties:
compatible:
enum:
- qcom,sc8180x-dispcc
- qcom,sm8150-dispcc
- qcom,sm8250-dispcc
Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml
-1
View File
@@ -46,7 +46,6 @@ properties:
nvmem-cell-names:
minItems: 1
maxItems: 2
items:
- const: calib
- const: calib_backup
Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml
-2
View File
@@ -27,7 +27,6 @@ properties:
- description: Sleep clock source
- description: PLL test clock source (Optional clock)
minItems: 2
maxItems: 3
clock-names:
items:
@@ -35,7 +34,6 @@ properties:
- const: sleep_clk
- const: core_bi_pll_test_se # Optional clock
minItems: 2
maxItems: 3
'#clock-cells':
const: 1
Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml
+72
View File
@@ -0,0 +1,72 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6125.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm Global Clock & Reset Controller Binding for SM6125
maintainers:
- Konrad Dybcio <konrad.dybcio@somainline.org>
description: |
Qualcomm global clock control module which supports the clocks, resets and
power domains on SM6125.
See also:
- dt-bindings/clock/qcom,gcc-sm6125.h
properties:
compatible:
const: qcom,gcc-sm6125
clocks:
items:
- description: Board XO source
- description: Sleep clock source
clock-names:
items:
- const: bi_tcxo
- const: sleep_clk
'#clock-cells':
const: 1
'#reset-cells':
const: 1
'#power-domain-cells':
const: 1
reg:
maxItems: 1
protected-clocks:
description:
Protected clock specifier list as per common clock binding.
required:
- compatible
- clocks
- clock-names
- reg
- '#clock-cells'
- '#reset-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/qcom,rpmcc.h>
clock-controller@1400000 {
compatible = "qcom,gcc-sm6125";
reg = <0x01400000 0x1f0000>;
#clock-cells = <1>;
#reset-cells = <1>;
#power-domain-cells = <1>;
clock-names = "bi_tcxo", "sleep_clk";
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>;
};
...
Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml
-2
View File
@@ -36,7 +36,6 @@ properties:
- description: USB3 phy wrapper pipe clock source (Optional clock)
- description: USB3 phy sec pipe clock source (Optional clock)
minItems: 2
maxItems: 13
clock-names:
items:
@@ -54,7 +53,6 @@ properties:
- const: usb3_phy_wrapper_gcc_usb30_pipe_clk # Optional clock
- const: usb3_uni_phy_sec_gcc_usb30_pipe_clk # Optional clock
minItems: 2
maxItems: 13
'#clock-cells':
const: 1
Documentation/devicetree/bindings/clock/qcom,gcc.yaml
+5 -2
View File
@@ -26,9 +26,10 @@ description: |
- dt-bindings/reset/qcom,gcc-msm8939.h
- dt-bindings/clock/qcom,gcc-msm8660.h
- dt-bindings/reset/qcom,gcc-msm8660.h
- dt-bindings/clock/qcom,gcc-msm8974.h
- dt-bindings/reset/qcom,gcc-msm8974.h
- dt-bindings/clock/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
- dt-bindings/reset/qcom,gcc-msm8974.h (qcom,gcc-msm8226 and qcom,gcc-msm8974)
- dt-bindings/clock/qcom,gcc-msm8994.h
- dt-bindings/clock/qcom,gcc-mdm9607.h
- dt-bindings/clock/qcom,gcc-mdm9615.h
- dt-bindings/reset/qcom,gcc-mdm9615.h
- dt-bindings/clock/qcom,gcc-sdm660.h (qcom,gcc-sdm630 and qcom,gcc-sdm660)
@@ -40,6 +41,8 @@ properties:
- qcom,gcc-ipq4019
- qcom,gcc-ipq6018
- qcom,gcc-ipq8064
- qcom,gcc-mdm9607
- qcom,gcc-msm8226
- qcom,gcc-msm8660
- qcom,gcc-msm8916
- qcom,gcc-msm8939
Documentation/devicetree/bindings/clock/qcom,rpmcc.txt
+1
View File
@@ -12,6 +12,7 @@ Required properties :
"qcom,rpmcc-msm8660", "qcom,rpmcc"
"qcom,rpmcc-apq8060", "qcom,rpmcc"
"qcom,rpmcc-msm8226", "qcom,rpmcc"
"qcom,rpmcc-msm8916", "qcom,rpmcc"
"qcom,rpmcc-msm8936", "qcom,rpmcc"
"qcom,rpmcc-msm8974", "qcom,rpmcc"
Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt
-98
View File
@@ -1,98 +0,0 @@
Device tree Clock bindings for Renesas EMMA Mobile EV2
This binding uses the common clock binding.
* SMU
System Management Unit described in user's manual R19UH0037EJ1000_SMU.
This is not a clock provider, but clocks under SMU depend on it.
Required properties:
- compatible: Should be "renesas,emev2-smu"
- reg: Address and Size of SMU registers
* SMU_CLKDIV
Function block with an input mux and a divider, which corresponds to
"Serial clock generator" in fig."Clock System Overview" of the manual,
and "xxx frequency division setting register" (XXXCLKDIV) registers.
This makes internal (neither input nor output) clock that is provided
to input of xxxGCLK block.
Required properties:
- compatible: Should be "renesas,emev2-smu-clkdiv"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Parent clocks. Input clocks as described in clock-bindings.txt
- #clock-cells: Should be <0>
* SMU_GCLK
Clock gating node shown as "Clock stop processing block" in the
fig."Clock System Overview" of the manual.
Registers are "xxx clock gate control register" (XXXGCLKCTRL).
Required properties:
- compatible: Should be "renesas,emev2-smu-gclk"
- reg: Byte offset from SMU base and Bit position in the register
- clocks: Input clock as described in clock-bindings.txt
- #clock-cells: Should be <0>
Example of provider:
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>, <&pll4_fo>, <&pll1_fo>, <&osc1_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
Example of consumer:
serial@e1020000 {
compatible = "renesas,em-uart";
reg = <0xe1020000 0x38>;
interrupts = <0 8 0>;
clocks = <&usia_u0_sclk>;
clock-names = "sclk";
};
Example of clock-tree description:
This describes a clock path in the clock tree
c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
smu@e0110000 {
compatible = "renesas,emev2-smu";
reg = <0xe0110000 0x10000>;
#address-cells = <2>;
#size-cells = <0>;
c32ki: c32ki {
compatible = "fixed-clock";
clock-frequency = <32768>;
#clock-cells = <0>;
};
pll3_fo: pll3_fo {
compatible = "fixed-factor-clock";
clocks = <&c32ki>;
clock-div = <1>;
clock-mult = <7000>;
#clock-cells = <0>;
};
usia_u0_sclkdiv: usia_u0_sclkdiv {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
};
Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml
+140
View File
@@ -0,0 +1,140 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/renesas,emev2-smu.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas EMMA Mobile EV2 System Management Unit
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
- Magnus Damm <magnus.damm@gmail.com>
description: |
The System Management Unit is described in user's manual R19UH0037EJ1000_SMU.
This is not a clock provider, but clocks under SMU depend on it.
properties:
compatible:
const: renesas,emev2-smu
reg:
maxItems: 1
'#address-cells':
const: 2
'#size-cells':
const: 0
required:
- compatible
- reg
- '#address-cells'
- '#size-cells'
patternProperties:
".*sclkdiv@.*":
type: object
description: |
Function block with an input mux and a divider, which corresponds to
"Serial clock generator" in fig. "Clock System Overview" of the manual,
and "xxx frequency division setting register" (XXXCLKDIV) registers.
This makes internal (neither input nor output) clock that is provided
to input of xxxGCLK block.
properties:
compatible:
const: renesas,emev2-smu-clkdiv
reg:
maxItems: 1
description:
Byte offset from SMU base and Bit position in the register.
clocks:
minItems: 1
maxItems: 4
'#clock-cells':
const: 0
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
".*sclk@.*":
type: object
description: |
Clock gating node shown as "Clock stop processing block" in the
fig. "Clock System Overview" of the manual.
Registers are "xxx clock gate control register" (XXXGCLKCTRL).
properties:
compatible:
const: renesas,emev2-smu-gclk
reg:
maxItems: 1
description:
Byte offset from SMU base and Bit position in the register.
clocks:
maxItems: 1
'#clock-cells':
const: 0
required:
- compatible
- reg
- clocks
- '#clock-cells'
additionalProperties: false
additionalProperties: true
examples:
- |
// Example of clock-tree description:
//
// This describes a clock path in the clock tree
// c32ki -> pll3_fo -> usia_u0_sclkdiv -> usia_u0_sclk
clocks@e0110000 {
compatible = "renesas,emev2-smu";
reg = <0xe0110000 0x10000>;
#address-cells = <2>;
#size-cells = <0>;
c32ki: c32ki {
compatible = "fixed-clock";
clock-frequency = <32768>;
#clock-cells = <0>;
};
pll3_fo: pll3_fo {
compatible = "fixed-factor-clock";
clocks = <&c32ki>;
clock-div = <1>;
clock-mult = <7000>;
#clock-cells = <0>;
};
usia_u0_sclkdiv: usia_u0_sclkdiv@610,0 {
compatible = "renesas,emev2-smu-clkdiv";
reg = <0x610 0>;
clocks = <&pll3_fo>;
#clock-cells = <0>;
};
usia_u0_sclk: usia_u0_sclk@4a0,1 {
compatible = "renesas,emev2-smu-gclk";
reg = <0x4a0 1>;
clocks = <&usia_u0_sclkdiv>;
#clock-cells = <0>;
};
};
Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt
-46
View File
@@ -1,46 +0,0 @@
* Renesas R9A06G032 SYSCTRL
Required Properties:
- compatible: Must be:
- "renesas,r9a06g032-sysctrl"
- reg: Base address and length of the SYSCTRL IO block.
- #clock-cells: Must be 1
- clocks: References to the parent clocks:
- external 40mhz crystal.
- external (optional) 32.768khz
- external (optional) jtag input
- external (optional) RGMII_REFCLK
- clock-names: Must be:
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
- #power-domain-cells: Must be 0
Examples
--------
- SYSCTRL node:
sysctrl: system-controller@4000c000 {
compatible = "renesas,r9a06g032-sysctrl";
reg = <0x4000c000 0x1000>;
#clock-cells = <1>;
clocks = <&ext_mclk>, <&ext_rtc_clk>,
<&ext_jtag_clk>, <&ext_rgmii_ref>;
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
#power-domain-cells = <0>;
};
- Other nodes can use the clocks provided by SYSCTRL as in:
#include <dt-bindings/clock/r9a06g032-sysctrl.h>
uart0: serial@40060000 {
compatible = "snps,dw-apb-uart";
reg = <0x40060000 0x400>;
interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
reg-shift = <2>;
reg-io-width = <4>;
clocks = <&sysctrl R9A06G032_CLK_UART0>, <&sysctrl R9A06G032_HCLK_UART0>;
clock-names = "baudclk", "apb_pclk";
power-domains = <&sysctrl>;
};
Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml
+62
View File
@@ -0,0 +1,62 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/renesas,r9a06g032-sysctrl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Renesas RZ/N1D (R9A06G032) System Controller
maintainers:
- Gareth Williams <gareth.williams.jx@renesas.com>
- Geert Uytterhoeven <geert+renesas@glider.be>
properties:
compatible:
const: renesas,r9a06g032-sysctrl
reg:
maxItems: 1
clocks:
minItems: 1
items:
- description: External 40 MHz crystal
- description: Optional external 32.768 kHz crystal
- description: Optional external JTAG input
- description: Optional external RGMII_REFCLK
clock-names:
minItems: 1
items:
- const: mclk
- const: rtc
- const: jtag
- const: rgmii_ref_ext
'#clock-cells':
const: 1
'#power-domain-cells':
const: 0
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
additionalProperties: false
examples:
- |
sysctrl: system-controller@4000c000 {
compatible = "renesas,r9a06g032-sysctrl";
reg = <0x4000c000 0x1000>;
clocks = <&ext_mclk>, <&ext_rtc_clk>, <&ext_jtag_clk>,
<&ext_rgmii_ref>;
clock-names = "mclk", "rtc", "jtag", "rgmii_ref_ext";
#clock-cells = <1>;
#power-domain-cells = <0>;
};
Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
+83
View File
@@ -0,0 +1,83 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: "http://devicetree.org/schemas/clock/renesas,rzg2l-cpg.yaml#"
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
title: Renesas RZ/G2L Clock Pulse Generator / Module Standby Mode
maintainers:
- Geert Uytterhoeven <geert+renesas@glider.be>
description: |
On Renesas RZ/G2L SoC, the CPG (Clock Pulse Generator) and Module
Standby Mode share the same register block.
They provide the following functionalities:
- The CPG block generates various core clocks,
- The Module Standby Mode block provides two functions:
1. Module Standby, providing a Clock Domain to control the clock supply
to individual SoC devices,
2. Reset Control, to perform a software reset of individual SoC devices.
properties:
compatible:
const: renesas,r9a07g044-cpg # RZ/G2{L,LC}
reg:
maxItems: 1
clocks:
maxItems: 1
clock-names:
description:
Clock source to CPG can be either from external clock input (EXCLK) or
crystal oscillator (XIN/XOUT).
const: extal
'#clock-cells':
description: |
- For CPG core clocks, the two clock specifier cells must be "CPG_CORE"
and a core clock reference, as defined in
<dt-bindings/clock/r9a07g044-cpg.h>
- For module clocks, the two clock specifier cells must be "CPG_MOD" and
a module number, as defined in the <dt-bindings/clock/r9a07g044-cpg.h>.
const: 2
'#power-domain-cells':
description:
SoC devices that are part of the CPG/Module Standby Mode Clock Domain and
can be power-managed through Module Standby should refer to the CPG device
node in their "power-domains" property, as documented by the generic PM
Domain bindings in Documentation/devicetree/bindings/power/power-domain.yaml.
const: 0
'#reset-cells':
description:
The single reset specifier cell must be the module number, as defined in
the <dt-bindings/clock/r9a07g044-cpg.h>.
const: 1
required:
- compatible
- reg
- clocks
- clock-names
- '#clock-cells'
- '#power-domain-cells'
- '#reset-cells'
additionalProperties: false
examples:
- |
cpg: clock-controller@11010000 {
compatible = "renesas,r9a07g044-cpg";
reg = <0x11010000 0x10000>;
clocks = <&extal_clk>;
clock-names = "extal";
#clock-cells = <2>;
#power-domain-cells = <0>;
#reset-cells = <1>;
};
Documentation/devicetree/bindings/clock/silabs,si5341.txt
+10 -6
View File
@@ -24,9 +24,8 @@ it.
The device type, speed grade and revision are determined runtime by probing.
The driver currently only supports XTAL input mode, and does not support any
fancy input configurations. They can still be programmed into the chip and
the driver will leave them "as is".
The driver currently does not support any fancy input configurations. They can
still be programmed into the chip and the driver will leave them "as is".
==I2C device node==
@@ -45,9 +44,9 @@ Required properties:
corresponding to inputs. Use a fixed clock for the "xtal" input.
At least one must be present.
- clock-names: One of: "xtal", "in0", "in1", "in2"
- vdd-supply: Regulator node for VDD
Optional properties:
- vdd-supply: Regulator node for VDD
- vdda-supply: Regulator node for VDDA
- vdds-supply: Regulator node for VDDS
- silabs,pll-m-num, silabs,pll-m-den: Numerator and denominator for PLL
@@ -60,7 +59,14 @@ Optional properties:
be initialized, and always performs the soft-reset routine. Since this will
temporarily stop all output clocks, don't do this if the chip is generating
the CPU clock for example.
- silabs,xaxb-ext-clk: When present, indicates that the XA/XB pins are used
in EXTCLK (external reference clock) rather than XTAL (crystal) mode.
- interrupts: Interrupt for INTRb pin.
- silabs,iovdd-33: When present, indicates that the I2C lines are using 3.3V
rather than 1.8V thresholds.
- vddoX-supply (where X is an output index): Regulator node for VDDO for the
specified output. The driver selects the output VDD_SEL setting based on this
voltage.
- #address-cells: shall be set to 1.
- #size-cells: shall be set to 0.
@@ -77,8 +83,6 @@ Required child node properties:
- reg: number of clock output.
Optional child node properties:
- vdd-supply: Regulator node for VDD for this output. The driver selects default
values for common-mode and amplitude based on the voltage.
- silabs,format: Output format, one of:
1 = differential (defaults to LVDS levels)
2 = low-power (defaults to HCSL levels)
Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml
-1
View File
@@ -40,7 +40,6 @@ properties:
clock-names:
minItems: 1
maxItems: 4
items:
- const: ext-26m
- const: ext-32k
Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml
+4 -2
View File
@@ -54,7 +54,9 @@ properties:
compatible:
items:
- const: st,stm32mp1-rcc
- enum:
- st,stm32mp1-rcc-secure
- st,stm32mp1-rcc
- const: syscon
reg:
@@ -71,7 +73,7 @@ additionalProperties: false
examples:
- |
rcc: rcc@50000000 {
compatible = "st,stm32mp1-rcc", "syscon";
compatible = "st,stm32mp1-rcc-secure", "syscon";
reg = <0x50000000 0x1000>;
#clock-cells = <1>;
#reset-cells = <1>;
Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt
+3
View File
@@ -10,7 +10,10 @@ Required properties:
- compatible : shall be:
"st,clkgen-pll0"
"st,clkgen-pll0-a0"
"st,clkgen-pll0-c0"
"st,clkgen-pll1"
"st,clkgen-pll1-c0"
"st,stih407-clkgen-plla9"
"st,stih418-clkgen-plla9"
Documentation/devicetree/bindings/clock/st/st,flexgen.txt
+10
View File
@@ -64,6 +64,16 @@ Required properties:
audio use case)
"st,flexgen-video", "st,flexgen" (enable clock propagation on parent
and activate synchronous mode)
"st,flexgen-stih407-a0"
"st,flexgen-stih410-a0"
"st,flexgen-stih407-c0"
"st,flexgen-stih410-c0"
"st,flexgen-stih418-c0"
"st,flexgen-stih407-d0"
"st,flexgen-stih410-d0"
"st,flexgen-stih407-d2"
"st,flexgen-stih418-d2"
"st,flexgen-stih407-d3"
- #clock-cells : from common clock binding; shall be set to 1 (multiple clock
outputs).
Documentation/devicetree/bindings/clock/st/st,quadfs.txt
+3
View File
@@ -12,6 +12,9 @@ This binding uses the common clock binding[1].
Required properties:
- compatible : shall be:
"st,quadfs"
"st,quadfs-d0"
"st,quadfs-d2"
"st,quadfs-d3"
"st,quadfs-pll"
Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml
+3 -1
View File
@@ -12,7 +12,9 @@ maintainers:
properties:
compatible:
items:
- const: ti,am654-ehrpwm-tbclk
- enum:
- ti,am654-ehrpwm-tbclk
- ti,am64-epwm-tbclk
- const: syscon
"#clock-cells":
Documentation/devicetree/bindings/clock/ti,lmk04832.yaml
+209
View File
@@ -0,0 +1,209 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,lmk04832.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Clock bindings for the Texas Instruments LMK04832
maintainers:
- Liam Beguin <liambeguin@gmail.com>
description: |
Devicetree binding for the LMK04832, a clock conditioner with JEDEC JESD204B
support. The LMK04832 is pin compatible with the LMK0482x family.
Link to datasheet, https://www.ti.com/lit/ds/symlink/lmk04832.pdf
properties:
compatible:
enum:
- ti,lmk04832
reg:
maxItems: 1
'#address-cells':
const: 1
'#size-cells':
const: 0
'#clock-cells':
const: 1
spi-max-frequency:
maximum: 5000000
clocks:
items:
- description: PLL2 reference clock.
clock-names:
items:
- const: oscin
reset-gpios:
maxItems: 1
ti,spi-4wire-rdbk:
description: |
Select SPI 4wire readback pin configuration.
Available readback pins are,
CLKin_SEL0 0
CLKin_SEL1 1
RESET 2
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
default: 1
ti,vco-hz:
description: Optional to set VCO frequency of the PLL in Hertz.
ti,sysref-ddly:
description: SYSREF digital delay value.
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 8
maximum: 8191
default: 8
ti,sysref-mux:
description: |
SYSREF Mux configuration.
Available options are,
Normal SYNC 0
Re-clocked 1
SYSREF Pulser 2
SYSREF Continuous 3
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2, 3]
default: 3
ti,sync-mode:
description: SYNC pin configuration.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [0, 1, 2]
default: 1
ti,sysref-pulse-count:
description:
Number of SYSREF pulses to send when SYSREF is not in continuous mode.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [1, 2, 4, 8]
default: 4
patternProperties:
"@[0-9a-d]+$":
type: object
description:
Child nodes used to configure output clocks.
properties:
reg:
description:
clock output identifier.
minimum: 0
maximum: 13
ti,clkout-fmt:
description:
Clock output format.
Available options are,
Powerdown 0x00
LVDS 0x01
HSDS 6 mA 0x02
HSDS 8 mA 0x03
LVPECL 1600 mV 0x04
LVPECL 2000 mV 0x05
LCPECL 0x06
CML 16 mA 0x07
CML 24 mA 0x08
CML 32 mA 0x09
CMOS (Off/Inverted) 0x0a
CMOS (Normal/Off) 0x0b
CMOS (Inverted/Inverted) 0x0c
CMOS (Inverted/Normal) 0x0d
CMOS (Normal/Inverted) 0x0e
CMOS (Normal/Normal) 0x0f
$ref: /schemas/types.yaml#/definitions/uint32
minimum: 0
maximum: 15
ti,clkout-sysref:
description:
Select SYSREF clock path for output clock.
type: boolean
required:
- reg
additionalProperties: false
required:
- compatible
- reg
- '#clock-cells'
- clocks
- clock-names
additionalProperties: false
examples:
- |
clocks {
lmk04832_oscin: oscin {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <122880000>;
clock-output-names = "lmk04832-oscin";
};
};
spi0 {
#address-cells = <1>;
#size-cells = <0>;
lmk04832: clock-controller@0 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0>;
compatible = "ti,lmk04832";
spi-max-frequency = <781250>;
reset-gpios = <&gpio_lmk 0 0 0>;
#clock-cells = <1>;
clocks = <&lmk04832_oscin>;
clock-names = "oscin";
ti,spi-4wire-rdbk = <0>;
ti,vco-hz = <2457600000>;
assigned-clocks =
<&lmk04832 0>, <&lmk04832 1>,
<&lmk04832 2>, <&lmk04832 3>,
<&lmk04832 4>,
<&lmk04832 6>, <&lmk04832 7>,
<&lmk04832 10>, <&lmk04832 11>;
assigned-clock-rates =
<122880000>, <384000>,
<122880000>, <384000>,
<122880000>,
<153600000>, <384000>,
<614400000>, <384000>;
clkout0@0 {
reg = <0>;
ti,clkout-fmt = <0x01>; // LVDS
};
clkout1@1 {
reg = <1>;
ti,clkout-fmt = <0x01>; // LVDS
ti,clkout-sysref;
};
};
};
Documentation/devicetree/bindings/clock/ti,sci-clk.txt
-36
View File
@@ -1,36 +0,0 @@
Texas Instruments TI-SCI Clocks
===============================
All clocks on Texas Instruments' SoCs that contain a System Controller,
are only controlled by this entity. Communication between a host processor
running an OS and the System Controller happens through a protocol known
as TI-SCI[1]. This clock implementation plugs into the common clock
framework and makes use of the TI-SCI protocol on clock API requests.
[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt
Required properties:
-------------------
- compatible: Must be "ti,k2g-sci-clk"
- #clock-cells: Shall be 2.
In clock consumers, this cell represents the device ID and clock ID
exposed by the PM firmware. The list of valid values for the device IDs
and clocks IDs for 66AK2G SoC are documented at
http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data
Examples:
--------
pmmc: pmmc {
compatible = "ti,k2g-sci";
k2g_clks: clocks {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
};
uart0: serial@2530c00 {
compatible = "ns16550a";
clocks = <&k2g_clks 0x2c 0>;
};
Documentation/devicetree/bindings/clock/ti,sci-clk.yaml
+49
View File
@@ -0,0 +1,49 @@
# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/ti,sci-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: TI-SCI clock controller node bindings
maintainers:
- Nishanth Menon <nm@ti.com>
description: |
Some TI SoCs contain a system controller (like the Power Management Micro
Controller (PMMC) on Keystone 66AK2G SoC) that are responsible for controlling
the state of the various hardware modules present on the SoC. Communication
between the host processor running an OS and the system controller happens
through a protocol called TI System Control Interface (TI-SCI protocol).
This clock controller node uses the TI SCI protocol to perform various clock
management of various hardware modules (devices) present on the SoC. This
node must be a child node of the associated TI-SCI system controller node.
properties:
$nodename:
pattern: "^clock-controller$"
compatible:
const: ti,k2g-sci-clk
"#clock-cells":
const: 2
description:
The two cells represent values that the TI-SCI controller defines.
The first cell should contain the device ID.
The second cell should contain the clock ID.
Please see http://processors.wiki.ti.com/index.php/TISCI for
protocol documentation for the values to be used for different devices.
additionalProperties: false
examples:
- |
k3_clks: clock-controller {
compatible = "ti,k2g-sci-clk";
#clock-cells = <2>;
};
Documentation/devicetree/bindings/clock/ti/dpll.txt
+20
View File
@@ -42,6 +42,11 @@ Required properties:
"idlest" - contains the idle status register base address
"mult-div1" - contains the multiplier / divider register base address
"autoidle" - contains the autoidle register base address (optional)
"ssc-deltam" - DPLL supports spread spectrum clocking (SSC), contains
the frequency spreading register base address (optional)
"ssc-modfreq" - DPLL supports spread spectrum clocking (SSC), contains
the modulation frequency register base address
(optional)
ti,am3-* dpll types do not have autoidle register
ti,omap2-* dpll type does not support idlest / autoidle registers
@@ -51,6 +56,14 @@ Optional properties:
- ti,low-power-stop : DPLL supports low power stop mode, gating output
- ti,low-power-bypass : DPLL output matches rate of parent bypass clock
- ti,lock : DPLL locks in programmed rate
- ti,min-div : the minimum divisor to start from to round the DPLL
target rate
- ti,ssc-deltam : DPLL supports spread spectrum clocking, frequency
spreading in permille (10th of a percent)
- ti,ssc-modfreq-hz : DPLL supports spread spectrum clocking, spread
spectrum modulation frequency
- ti,ssc-downspread : DPLL supports spread spectrum clocking, boolean
to enable the downspread feature
Examples:
dpll_core_ck: dpll_core_ck@44e00490 {
@@ -83,3 +96,10 @@ Examples:
clocks = <&sys_ck>, <&sys_ck>;
reg = <0x0500>, <0x0540>;
};
dpll_disp_ck: dpll_disp_ck {
#clock-cells = <0>;
compatible = "ti,am3-dpll-no-gate-clock";
clocks = <&sys_clkin_ck>, <&sys_clkin_ck>;
reg = <0x0498>, <0x0448>, <0x0454>, <0x044c>, <0x0450>;
};
Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml
-2
View File
@@ -30,7 +30,6 @@ properties:
- description: Module clock
- description: MBus clock
minItems: 2
maxItems: 3
clock-names:
items:
@@ -38,7 +37,6 @@ properties:
- const: mod
- const: ram
minItems: 2
maxItems: 3
resets:
maxItems: 1
Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml
+53
View File
@@ -0,0 +1,53 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/crypto/arm,cryptocell.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Arm TrustZone CryptoCell cryptographic engine
maintainers:
- Gilad Ben-Yossef <gilad@benyossef.com>
properties:
compatible:
enum:
- arm,cryptocell-713-ree
- arm,cryptocell-703-ree
- arm,cryptocell-712-ree
- arm,cryptocell-710-ree
- arm,cryptocell-630p-ree
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 1
power-domains:
maxItems: 1
resets:
maxItems: 1
dma-coherent: true
required:
- compatible
- reg
- interrupts
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/arm-gic.h>
arm_cc712: crypto@80000000 {
compatible = "arm,cryptocell-712-ree";
reg = <0x80000000 0x10000>;
interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>;
};
Documentation/devicetree/bindings/crypto/arm-cryptocell.txt
-25
View File
@@ -1,25 +0,0 @@
Arm TrustZone CryptoCell cryptographic engine
Required properties:
- compatible: Should be one of -
"arm,cryptocell-713-ree"
"arm,cryptocell-703-ree"
"arm,cryptocell-712-ree"
"arm,cryptocell-710-ree"
"arm,cryptocell-630p-ree"
- reg: Base physical address of the engine and length of memory mapped region.
- interrupts: Interrupt number for the device.
Optional properties:
- clocks: Reference to the crypto engine clock.
- dma-coherent: Present if dma operations are coherent.
Examples:
arm_cc712: crypto@80000000 {
compatible = "arm,cryptocell-712-ree";
interrupt-parent = <&intc>;
interrupts = < 0 30 4 >;
reg = < 0x80000000 0x10000 >;
};
Documentation/devicetree/bindings/crypto/fsl-dcp.yaml
-1
View File
@@ -27,7 +27,6 @@ properties:
- description: MXS DCP DCP interrupt
- description: MXS DCP secure interrupt
minItems: 2
maxItems: 3
clocks:
maxItems: 1
Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml
-6
View File
@@ -26,14 +26,12 @@ properties:
reg:
minItems: 1
maxItems: 2
items:
- description: Display Backend registers
- description: SAT registers
reg-names:
minItems: 1
maxItems: 2
items:
- const: be
- const: sat
@@ -43,7 +41,6 @@ properties:
clocks:
minItems: 3
maxItems: 4
items:
- description: The backend interface clock
- description: The backend module clock
@@ -52,7 +49,6 @@ properties:
clock-names:
minItems: 3
maxItems: 4
items:
- const: ahb
- const: mod
@@ -61,14 +57,12 @@ properties:
resets:
minItems: 1
maxItems: 2
items:
- description: The Backend reset line
- description: The SAT reset line
reset-names:
minItems: 1
maxItems: 2
items:
- const: be
- const: sat
Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml
-1
View File
@@ -24,7 +24,6 @@ properties:
clocks:
minItems: 1
maxItems: 2
items:
- description: Bus Clock
- description: Module Clock
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml
-4
View File
@@ -46,7 +46,6 @@ properties:
clocks:
minItems: 3
maxItems: 6
items:
- description: Bus Clock
- description: Register Clock
@@ -57,7 +56,6 @@ properties:
clock-names:
minItems: 3
maxItems: 6
items:
- const: iahb
- const: isfr
@@ -68,14 +66,12 @@ properties:
resets:
minItems: 1
maxItems: 2
items:
- description: HDMI Controller Reset
- description: HDCP Reset
reset-names:
minItems: 1
maxItems: 2
items:
- const: ctrl
- const: hdcp
Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml
-2
View File
@@ -27,7 +27,6 @@ properties:
clocks:
minItems: 2
maxItems: 4
items:
- description: Bus Clock
- description: Module Clock
@@ -36,7 +35,6 @@ properties:
clock-names:
minItems: 2
maxItems: 4
items:
- const: bus
- const: mod
Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml
-2
View File
@@ -48,7 +48,6 @@ properties:
clocks:
minItems: 2
maxItems: 6
items:
- description: The TCON TOP interface clock
- description: The TCON TOP TV0 clock
@@ -59,7 +58,6 @@ properties:
clock-names:
minItems: 2
maxItems: 6
items:
- const: bus
- const: tcon-tv0
Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml
+3 -1
View File
@@ -11,7 +11,9 @@ maintainers:
properties:
compatible:
const: brcm,bcm2835-vec
enum:
- brcm,bcm2711-vec
- brcm,bcm2835-vec
reg:
maxItems: 1
Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt
-143
View File
@@ -1,143 +0,0 @@
Analog Devices ADV7511(W)/13/33/35 HDMI Encoders
------------------------------------------------
The ADV7511, ADV7511W, ADV7513, ADV7533 and ADV7535 are HDMI audio and video
transmitters compatible with HDMI 1.4 and DVI 1.0. They support color space
conversion, S/PDIF, CEC and HDCP. ADV7533/5 supports the DSI interface for input
pixels, while the others support RGB interface.
Required properties:
- compatible: Should be one of:
"adi,adv7511"
"adi,adv7511w"
"adi,adv7513"
"adi,adv7533"
"adi,adv7535"
- reg: I2C slave addresses
The ADV7511 internal registers are split into four pages exposed through
different I2C addresses, creating four register maps. Each map has it own
I2C address and acts as a standard slave device on the I2C bus. The main
address is mandatory, others are optional and revert to defaults if not
specified.
The ADV7511 supports a large number of input data formats that differ by their
color depth, color format, clock mode, bit justification and random
arrangement of components on the data bus. The combination of the following
properties describe the input and map directly to the video input tables of the
ADV7511 datasheet that document all the supported combinations.
- adi,input-depth: Number of bits per color component at the input (8, 10 or
12).
- adi,input-colorspace: The input color space, one of "rgb", "yuv422" or
"yuv444".
- adi,input-clock: The input clock type, one of "1x" (one clock cycle per
pixel), "2x" (two clock cycles per pixel), "ddr" (one clock cycle per pixel,
data driven on both edges).
The following input format properties are required except in "rgb 1x" and
"yuv444 1x" modes, in which case they must not be specified.
- adi,input-style: The input components arrangement variant (1, 2 or 3), as
listed in the input format tables in the datasheet.
- adi,input-justification: The input bit justification ("left", "evenly",
"right").
- avdd-supply: A 1.8V supply that powers up the AVDD pin on the chip.
- dvdd-supply: A 1.8V supply that powers up the DVDD pin on the chip.
- pvdd-supply: A 1.8V supply that powers up the PVDD pin on the chip.
- dvdd-3v-supply: A 3.3V supply that powers up the pin called DVDD_3V
on the chip.
- bgvdd-supply: A 1.8V supply that powers up the BGVDD pin. This is
needed only for ADV7511.
The following properties are required for ADV7533 and ADV7535:
- adi,dsi-lanes: Number of DSI data lanes connected to the DSI host. It should
be one of 1, 2, 3 or 4.
- a2vdd-supply: 1.8V supply that powers up the A2VDD pin on the chip.
- v3p3-supply: A 3.3V supply that powers up the V3P3 pin on the chip.
- v1p2-supply: A supply that powers up the V1P2 pin on the chip. It can be
either 1.2V or 1.8V for ADV7533 but only 1.8V for ADV7535.
Optional properties:
- interrupts: Specifier for the ADV7511 interrupt
- pd-gpios: Specifier for the GPIO connected to the power down signal
- adi,clock-delay: Video data clock delay relative to the pixel clock, in ps
(-1200 ps .. 1600 ps). Defaults to no delay.
- adi,embedded-sync: The input uses synchronization signals embedded in the
data stream (similar to BT.656). Defaults to separate H/V synchronization
signals.
- adi,disable-timing-generator: Only for ADV7533 and ADV7535. Disables the
internal timing generator. The chip will rely on the sync signals in the
DSI data lanes, rather than generate its own timings for HDMI output.
- clocks: from common clock binding: reference to the CEC clock.
- clock-names: from common clock binding: must be "cec".
- reg-names : Names of maps with programmable addresses.
It can contain any map needing a non-default address.
Possible maps names are : "main", "edid", "cec", "packet"
Required nodes:
The ADV7511 has two video ports. Their connections are modelled using the OF
graph bindings specified in Documentation/devicetree/bindings/graph.txt.
- Video port 0 for the RGB, YUV or DSI input. In the case of ADV7533/5, the
remote endpoint phandle should be a reference to a valid mipi_dsi_host device
node.
- Video port 1 for the HDMI output
- Audio port 2 for the HDMI audio input
Example
-------
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
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>;
adv7511w_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};
Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml
+240
View File
@@ -0,0 +1,240 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/adi,adv7511.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADV7511/11W/13 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
The ADV7511, ADV7511W and ADV7513 are HDMI audio and video
transmitters compatible with HDMI 1.4 and DVI 1.0. They support color
space conversion, S/PDIF, CEC and HDCP. The transmitter input is
parallel RGB or YUV data.
properties:
compatible:
enum:
- adi,adv7511
- adi,adv7511w
- adi,adv7513
reg:
description: |
I2C slave addresses.
The ADV7511/11W/13 internal registers are split into four pages
exposed through different I2C addresses, creating four register
maps. Each map has it own I2C address and acts as a standard slave
device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
minItems: 1
maxItems: 4
reg-names:
description:
Names of maps with programmable addresses. It can contain any map
needing a non-default address.
minItems: 1
items:
- const: main
- const: edid
- const: cec
- const: packet
clocks:
description: Reference to the CEC clock.
maxItems: 1
clock-names:
const: cec
interrupts:
maxItems: 1
pd-gpios:
description: GPIO connected to the power down signal.
maxItems: 1
avdd-supply:
description: A 1.8V supply that powers up the AVDD pin.
dvdd-supply:
description: A 1.8V supply that powers up the DVDD pin.
pvdd-supply:
description: A 1.8V supply that powers up the PVDD pin.
dvdd-3v-supply:
description: A 3.3V supply that powers up the DVDD_3V pin.
bgvdd-supply:
description: A 1.8V supply that powers up the BGVDD pin.
adi,input-depth:
description: Number of bits per color component at the input.
allOf:
- $ref: /schemas/types.yaml#/definitions/uint32
- enum: [ 8, 10, 12 ]
adi,input-colorspace:
description: Input color space.
enum: [ rgb, yuv422, yuv444 ]
adi,input-clock:
description: |
Input clock type.
"1x": one clock cycle per pixel
"2x": two clock cycles per pixel
"dd": one clock cycle per pixel, data driven on both edges
enum: [ 1x, 2x, dd ]
adi,clock-delay:
description:
Video data clock delay relative to the pixel clock, in ps
(-1200ps .. 1600 ps).
$ref: /schemas/types.yaml#/definitions/uint32
default: 0
adi,embedded-sync:
description:
If defined, the input uses synchronization signals embedded in the
data stream (similar to BT.656).
type: boolean
adi,input-style:
description:
Input components arrangement variant as listed in the input
format tables in the datasheet.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3 ]
adi,input-justification:
description: Input bit justification.
enum: [ left, evenly, right ]
ports:
description:
The ADV7511(W)/13 has two video ports and one audio port. This node
models their connections as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
Documentation/devicetree/bindings/graph.txt
type: object
properties:
port@0:
description: Video port for the RGB or YUV input.
type: object
port@1:
description: Video port for the HDMI output.
type: object
port@2:
description: Audio port for the HDMI output.
type: object
# adi,input-colorspace and adi,input-clock are required except in
# "rgb 1x" and "yuv444 1x" modes, in which case they must not be
# specified.
if:
not:
properties:
adi,input-colorspace:
contains:
enum: [ rgb, yuv444 ]
adi,input-clock:
contains:
const: 1x
then:
required:
- adi,input-style
- adi,input-justification
else:
properties:
adi,input-style: false
adi,input-justification: false
required:
- compatible
- reg
- ports
- adi,input-depth
- adi,input-colorspace
- adi,input-clock
- avdd-supply
- dvdd-supply
- pvdd-supply
- dvdd-3v-supply
- bgvdd-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c@e6500000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe6500000>;
adv7511w: hdmi@39 {
compatible = "adi,adv7511w";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
avdd-supply = <&v1v8>;
dvdd-supply = <&v1v8>;
pvdd-supply = <&v1v8>;
dvdd-3v-supply = <&v3v3>;
bgvdd-supply = <&v1v8>;
adi,input-depth = <8>;
adi,input-colorspace = "yuv422";
adi,input-clock = "1x";
adi,input-style = <3>;
adi,input-justification = "right";
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7511w_in: endpoint {
remote-endpoint = <&dpi_out>;
};
};
port@1 {
reg = <1>;
adv7511_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};
};
...
Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml
+184
View File
@@ -0,0 +1,184 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/adi,adv7533.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Analog Devices ADV7533/35 HDMI Encoders
maintainers:
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
description: |
The ADV7533 and ADV7535 are HDMI audio and video transmitters
compatible with HDMI 1.4 and DVI 1.0. They support color space
conversion, S/PDIF, CEC and HDCP. The transmitter input is MIPI DSI.
properties:
compatible:
enum:
- adi,adv7533
- adi,adv7535
reg:
description: |
I2C slave addresses.
The ADV7533/35 internal registers are split into four pages
exposed through different I2C addresses, creating four register
maps. Each map has it own I2C address and acts as a standard slave
device on the I2C bus. The main address is mandatory, others are
optional and revert to defaults if not specified.
minItems: 1
maxItems: 4
reg-names:
description:
Names of maps with programmable addresses. It can contain any map
needing a non-default address.
minItems: 1
items:
- const: main
- const: edid
- const: cec
- const: packet
clocks:
description: Reference to the CEC clock.
maxItems: 1
clock-names:
const: cec
interrupts:
maxItems: 1
pd-gpios:
description: GPIO connected to the power down signal.
maxItems: 1
avdd-supply:
description: A 1.8V supply that powers up the AVDD pin.
dvdd-supply:
description: A 1.8V supply that powers up the DVDD pin.
pvdd-supply:
description: A 1.8V supply that powers up the PVDD pin.
a2vdd-supply:
description: A 1.8V supply that powers up the A2VDD pin.
v3p3-supply:
description: A 3.3V supply that powers up the V3P3 pin.
v1p2-supply:
description:
A supply that powers up the V1P2 pin. It can be either 1.2V
or 1.8V for ADV7533 but only 1.8V for ADV7535.
adi,disable-timing-generator:
description:
Disables the internal timing generator. The chip will rely on the
sync signals in the DSI data lanes, rather than generating its own
timings for HDMI output.
type: boolean
adi,dsi-lanes:
description: Number of DSI data lanes connected to the DSI host.
$ref: /schemas/types.yaml#/definitions/uint32
enum: [ 1, 2, 3, 4 ]
ports:
description:
The ADV7533/35 has two video ports and one audio port. This node
models their connections as documented in
Documentation/devicetree/bindings/media/video-interfaces.txt
Documentation/devicetree/bindings/graph.txt
type: object
properties:
port@0:
description:
Video port for the DSI input. The remote endpoint phandle
should be a reference to a valid mipi_dsi_host_device.
type: object
port@1:
description: Video port for the HDMI output.
type: object
port@2:
description: Audio port for the HDMI output.
type: object
required:
- compatible
- reg
- ports
- adi,dsi-lanes
- avdd-supply
- dvdd-supply
- pvdd-supply
- a2vdd-supply
- v3p3-supply
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
i2c@e6500000 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0 0xe6500000>;
adv7533: hdmi@39 {
compatible = "adi,adv7533";
/*
* The EDID page will be accessible on address 0x66 on the I2C
* bus. All other maps continue to use their default addresses.
*/
reg = <0x39>, <0x66>;
reg-names = "main", "edid";
interrupt-parent = <&gpio3>;
interrupts = <29 IRQ_TYPE_EDGE_FALLING>;
clocks = <&cec_clock>;
clock-names = "cec";
adi,dsi-lanes = <4>;
avdd-supply = <&v1v8>;
dvdd-supply = <&v1v8>;
pvdd-supply = <&v1v8>;
a2vdd-supply = <&v1v8>;
v3p3-supply = <&v3v3>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
adv7533_in: endpoint {
remote-endpoint = <&dsi_out>;
};
};
port@1 {
reg = <1>;
adv7533_out: endpoint {
remote-endpoint = <&hdmi_connector_in>;
};
};
port@2 {
reg = <2>;
codec_endpoint: endpoint {
remote-endpoint = <&i2s0_cpu_endpoint>;
};
};
};
};
};
...
Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml
+9 -4
View File
@@ -18,7 +18,6 @@ properties:
reg:
minItems: 1
maxItems: 2
items:
- description:
Register block of mhdptx apb registers up to PHY mapped area (AUX_CONFIG_P).
@@ -26,13 +25,15 @@ properties:
included in the associated PHY.
- description:
Register block for DSS_EDP0_INTG_CFG_VP registers in case of TI J7 SoCs.
- description:
Register block of mhdptx sapb registers.
reg-names:
minItems: 1
maxItems: 2
items:
- const: mhdptx
- const: j721e-intg
- const: mhdptx-sapb
clocks:
maxItems: 1
@@ -99,14 +100,18 @@ allOf:
properties:
reg:
minItems: 2
maxItems: 3
reg-names:
minItems: 2
maxItems: 3
else:
properties:
reg:
maxItems: 1
minItems: 1
maxItems: 2
reg-names:
maxItems: 1
minItems: 1
maxItems: 2
required:
- compatible
Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml
+82
View File
@@ -0,0 +1,82 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/google,cros-ec-anx7688.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ChromeOS EC ANX7688 HDMI to DP Converter through Type-C Port
maintainers:
- Nicolas Boichat <drinkcat@chromium.org>
- Enric Balletbo i Serra <enric.balletbo@collabora.com>
description: |
ChromeOS EC ANX7688 is a display bridge that converts HDMI 2.0 to
DisplayPort 1.3 Ultra-HDi (4096x2160p60). It is an Analogix ANX7688 chip
which is connected to and operated by the ChromeOS Embedded Controller
(See google,cros-ec.yaml). It is accessed using I2C tunneling through
the EC and therefore its node should be a child of an EC I2C tunnel node
(See google,cros-ec-i2c-tunnel.yaml).
properties:
compatible:
const: google,cros-ec-anx7688
reg:
maxItems: 1
description: I2C address of the device.
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
description: Video port for HDMI input.
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: USB Type-c connector.
required:
- port@0
- port@1
required:
- compatible
- reg
- ports
additionalProperties: false
examples:
- |
i2c_tunnel_b: i2c-tunnel1 {
compatible = "google,cros-ec-i2c-tunnel";
google,remote-bus = <1>;
#address-cells = <1>;
#size-cells = <0>;
anx7688: anx7688@2c {
compatible = "google,cros-ec-anx7688";
reg = <0x2c>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
anx7688_in: endpoint {
remote-endpoint = <&hdmi0_out>;
};
};
port@1 {
reg = <1>;
anx7688_out: endpoint {
remote-endpoint = <&typec_connector>;
};
};
};
};
};
Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml
+124
View File
@@ -0,0 +1,124 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/ite,it66121.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: ITE it66121 HDMI bridge Device Tree Bindings
maintainers:
- Phong LE <ple@baylibre.com>
- Neil Armstrong <narmstrong@baylibre.com>
description: |
The IT66121 is a high-performance and low-power single channel HDMI
transmitter, fully compliant with HDMI 1.3a, HDCP 1.2 and backward compatible
to DVI 1.0 specifications.
properties:
compatible:
const: ite,it66121
reg:
maxItems: 1
reset-gpios:
maxItems: 1
description: GPIO connected to active low reset
vrf12-supply:
description: Regulator for 1.2V analog core power.
vcn33-supply:
description: Regulator for 3.3V digital core power.
vcn18-supply:
description: Regulator for 1.8V IO core power.
interrupts:
maxItems: 1
ports:
$ref: /schemas/graph.yaml#/properties/ports
properties:
port@0:
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: DPI input port.
properties:
endpoint:
$ref: /schemas/graph.yaml#/$defs/endpoint-base
unevaluatedProperties: false
properties:
bus-width:
description:
Endpoint bus width.
enum:
- 12 # 12 data lines connected and dual-edge mode
- 24 # 24 data lines connected and single-edge mode
default: 24
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: HDMI Connector port.
required:
- port@0
- port@1
required:
- compatible
- reg
- reset-gpios
- vrf12-supply
- vcn33-supply
- vcn18-supply
- interrupts
- ports
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/gpio/gpio.h>
i2c {
#address-cells = <1>;
#size-cells = <0>;
it66121hdmitx: hdmitx@4c {
compatible = "ite,it66121";
pinctrl-names = "default";
pinctrl-0 = <&ite_pins_default>;
vcn33-supply = <&mt6358_vcn33_wifi_reg>;
vcn18-supply = <&mt6358_vcn18_reg>;
vrf12-supply = <&mt6358_vrf12_reg>;
reset-gpios = <&pio 160 GPIO_ACTIVE_LOW>;
interrupt-parent = <&pio>;
interrupts = <4 IRQ_TYPE_LEVEL_LOW>;
reg = <0x4c>;
ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
it66121_in: endpoint {
bus-width = <12>;
remote-endpoint = <&display_out>;
};
};
port@1 {
reg = <1>;
hdmi_conn_out: endpoint {
remote-endpoint = <&hdmi_conn_in>;
};
};
};
};
};
Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml
+2 -1
View File
@@ -29,7 +29,8 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description:
Primary MIPI port for MIPI input

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