diff options
Diffstat (limited to 'Documentation')
602 files changed, 20894 insertions, 8179 deletions
diff --git a/Documentation/ABI/obsolete/sysfs-bus-iio b/Documentation/ABI/obsolete/sysfs-bus-iio new file mode 100644 index 000000000000..c9531bb64816 --- /dev/null +++ b/Documentation/ABI/obsolete/sysfs-bus-iio @@ -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 diff --git a/Documentation/ABI/stable/sysfs-class-infiniband b/Documentation/ABI/stable/sysfs-class-infiniband index 348c4ac803ad..9b1bdfa43354 100644 --- a/Documentation/ABI/stable/sysfs-class-infiniband +++ b/Documentation/ABI/stable/sysfs-class-infiniband @@ -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 ------------------------------------------ diff --git a/Documentation/ABI/stable/sysfs-driver-w1_ds2438 b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 new file mode 100644 index 000000000000..d2e7681cc287 --- /dev/null +++ b/Documentation/ABI/stable/sysfs-driver-w1_ds2438 @@ -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 diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index d4356c8b8cd6..26fb8e9b4e61 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -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) diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index e89c6351503c..a5c28f606865 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -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 diff --git a/Documentation/ABI/testing/sysfs-bus-counter b/Documentation/ABI/testing/sysfs-bus-counter index 566bd99fe0a5..20fe5afd4f9e 100644 --- a/Documentation/ABI/testing/sysfs-bus-counter +++ b/Documentation/ABI/testing/sysfs-bus-counter @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 b/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 deleted file mode 100644 index eac32180c40d..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-counter-104-quad-8 +++ /dev/null @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec b/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec deleted file mode 100644 index 7d2e7b363467..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-counter-ftm-quaddec +++ /dev/null @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 2fe7490ad6a8..0b6a2e6e8fbb 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index 6f98b6a9b785..6ad47a67521c 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -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 diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 index 544548ee794c..7fe6935d1448 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-adf4371 @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x b/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x index 66b621f10223..a8e04b41d9ff 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x +++ b/Documentation/ABI/testing/sysfs-bus-iio-health-afe440x @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-icm42600 b/Documentation/ABI/testing/sysfs-bus-iio-icm42600 deleted file mode 100644 index 0bf1fd4f5bf1..000000000000 --- a/Documentation/ABI/testing/sysfs-bus-iio-icm42600 +++ /dev/null @@ -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). diff --git a/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als index 22c5ea670971..c476d48d0f82 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als +++ b/Documentation/ABI/testing/sysfs-bus-iio-light-lm3533-als @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 92e2db0e2d3d..95254cec92bf 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -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 diff --git a/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor new file mode 100644 index 000000000000..d76cd3946434 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-spi-devices-spi-nor @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-thunderbolt b/Documentation/ABI/testing/sysfs-bus-thunderbolt index c41c68f64693..95c21d6c9a84 100644 --- a/Documentation/ABI/testing/sysfs-bus-thunderbolt +++ b/Documentation/ABI/testing/sysfs-bus-thunderbolt @@ -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. diff --git a/Documentation/ABI/testing/sysfs-bus-usb b/Documentation/ABI/testing/sysfs-bus-usb index bf2c1968525f..73eb23bc1f34 100644 --- a/Documentation/ABI/testing/sysfs-bus-usb +++ b/Documentation/ABI/testing/sysfs-bus-usb @@ -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> diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 8ea59fea4709..3348bf80a37c 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -197,8 +197,24 @@ Description: Drivers may emit a CHANGE uevent when a password is set or unset userspace may check it again. - On Dell systems, if Admin password is set, then all BIOS attributes + On Dell and Lenovo systems, if Admin password is set, then all BIOS attributes require password validation. + On Lenovo systems if you change the Admin password the new password is not active until + the next boot. + + Lenovo specific class extensions + ------------------------------ + + On Lenovo systems the following additional settings are available: + + lenovo_encoding: + The encoding method that is used. This can be either "ascii" + or "scancode". Default is set to "ascii" + + lenovo_kbdlang: + The keyboard language method that is used. This is generally a + two char code (e.g. "us", "fr", "gr") and may vary per platform. + Default is set to "us" What: /sys/class/firmware-attributes/*/attributes/pending_reboot Date: February 2021 diff --git a/Documentation/ABI/testing/sysfs-class-spi-eeprom b/Documentation/ABI/testing/sysfs-class-spi-eeprom new file mode 100644 index 000000000000..1ff757982079 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-class-spi-eeprom @@ -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. diff --git a/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa new file mode 100644 index 000000000000..c56dcf15bf29 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-platform-soc-ipa @@ -0,0 +1,78 @@ +What: /sys/devices/platform/soc@X/XXXXXXX.ipa/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The /sys/devices/platform/soc@X/XXXXXXX.ipa/ directory + contains read-only attributes exposing information about + an IPA device. The X values could vary, but are typically + "soc@0/1e40000.ipa". + +What: .../XXXXXXX.ipa/version +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/version file contains the IPA hardware + version, as a period-separated set of two or three integers + (e.g., "3.5.1" or "4.2"). + +What: .../XXXXXXX.ipa/feature/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/ directory contains a set of + attributes describing features implemented by the IPA + hardware. + +What: .../XXXXXXX.ipa/feature/rx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/rx_offload file contains a + string indicating the type of receive checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/feature/tx_offload +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/tx_offload file contains a + string indicating the type of transmit checksum offload + that is supported by the hardware. The possible values + are "MAPv4" or "MAPv5". + +What: .../XXXXXXX.ipa/modem/ +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/modem/ directory contains a set of + attributes describing properties of the modem execution + environment reachable by the IPA hardware. + +What: .../XXXXXXX.ipa/modem/rx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/rx_endpoint_id file contains + the AP endpoint ID that receives packets originating from + the modem execution environment. The "rx" is from the + perspective of the AP; this endpoint is considered an "IPA + producer". An endpoint ID is a small unsigned integer. + +What: .../XXXXXXX.ipa/modem/tx_endpoint_id +Date: June 2021 +KernelVersion: v5.14 +Contact: Alex Elder <elder@kernel.org> +Description: + The .../XXXXXXX.ipa/feature/tx_endpoint_id file contains + the AP endpoint ID used to transmit packets destined for + the modem execution environment. The "tx" is from the + perspective of the AP; this endpoint is considered an "IPA + consumer". An endpoint ID is a small unsigned integer. diff --git a/Documentation/ABI/testing/sysfs-devices-removable b/Documentation/ABI/testing/sysfs-devices-removable new file mode 100644 index 000000000000..bda6c320c8d3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-devices-removable @@ -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). diff --git a/Documentation/ABI/testing/sysfs-driver-ufs b/Documentation/ABI/testing/sysfs-driver-ufs index eaac6898f0c0..b4a5d55fa19f 100644 --- a/Documentation/ABI/testing/sysfs-driver-ufs +++ b/Documentation/ABI/testing/sysfs-driver-ufs @@ -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> diff --git a/Documentation/ABI/testing/sysfs-firmware-memmap b/Documentation/ABI/testing/sysfs-firmware-memmap index 1f6f4d3a32c0..9205122fa4b1 100644 --- a/Documentation/ABI/testing/sysfs-firmware-memmap +++ b/Documentation/ABI/testing/sysfs-firmware-memmap @@ -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 diff --git a/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi new file mode 100644 index 000000000000..7f9e18705861 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-platform-dell-privacy-wmi @@ -0,0 +1,55 @@ +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Display which dell hardware level privacy devices are supported + “Dell Privacy” is a set of HW, FW, and SW features to enhance + Dell’s commitment to platform privacy for MIC, Camera, and + ePrivacy screens. + The supported hardware privacy devices are: +Attributes: + Microphone Mute: + Identifies the local microphone can be muted by hardware, no applications + is available to capture system mic sound + + Camera Shutter: + Identifies camera shutter controlled by hardware, which is a micromechanical + shutter assembly that is built onto the camera module to block capturing images + from outside the laptop + + supported: + The privacy device is supported by this system + + unsupported: + The privacy device is not supported on this system + + For example to check which privacy devices are supported: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_supported_type + [Microphone Mute] [supported] + [Camera Shutter] [supported] + [ePrivacy Screen] [unsupported] + +What: /sys/bus/wmi/devices/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state +Date: Apr 2021 +KernelVersion: 5.13 +Contact: "perry.yuan@dell.com>" +Description: + Allow user space to check current dell privacy device state. + Describes the Device State class exposed by BIOS which can be + consumed by various applications interested in knowing the Privacy + feature capabilities +Attributes: + muted: + Identifies the privacy device is turned off and cannot send stream to OS applications + + unmuted: + Identifies the privacy device is turned on ,audio or camera driver can get + stream from mic and camera module to OS applications + + For example to check all supported current privacy device states: + + # cat /sys/bus/wmi/drivers/dell-privacy/6932965F-1671-4CEB-B988-D3AB0A901919/dell_privacy_current_state + [Microphone] [unmuted] + [Camera Shutter] [unmuted] diff --git a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst index a648b423ba0e..11cdab037bff 100644 --- a/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst +++ b/Documentation/RCU/Design/Memory-Ordering/Tree-RCU-Memory-Ordering.rst @@ -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, diff --git a/Documentation/RCU/checklist.rst b/Documentation/RCU/checklist.rst index 1030119294d0..01cc21f17f7b 100644 --- a/Documentation/RCU/checklist.rst +++ b/Documentation/RCU/checklist.rst @@ -211,27 +211,40 @@ over a rather long period of time, but improvements are always welcome! of the system, especially to real-time workloads running on the rest of the system. -7. As of v4.20, a given kernel implements only one RCU flavor, - which is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. - If the updater uses call_rcu() or synchronize_rcu(), - then the corresponding readers may use rcu_read_lock() and - rcu_read_unlock(), rcu_read_lock_bh() and rcu_read_unlock_bh(), - or any pair of primitives that disables and re-enables preemption, - for example, rcu_read_lock_sched() and rcu_read_unlock_sched(). - If the updater uses synchronize_srcu() or call_srcu(), - then the corresponding readers must use srcu_read_lock() and - srcu_read_unlock(), and with the same srcu_struct. The rules for - the expedited primitives are the same as for their non-expedited - counterparts. Mixing things up will result in confusion and - broken kernels, and has even resulted in an exploitable security - issue. - - One exception to this rule: rcu_read_lock() and rcu_read_unlock() - may be substituted for rcu_read_lock_bh() and rcu_read_unlock_bh() - in cases where local bottom halves are already known to be - disabled, for example, in irq or softirq context. Commenting - such cases is a must, of course! And the jury is still out on - whether the increased speed is worth it. +7. As of v4.20, a given kernel implements only one RCU flavor, which + is RCU-sched for PREEMPTION=n and RCU-preempt for PREEMPTION=y. + If the updater uses call_rcu() or synchronize_rcu(), then + the corresponding readers may use: (1) rcu_read_lock() and + rcu_read_unlock(), (2) any pair of primitives that disables + and re-enables softirq, for example, rcu_read_lock_bh() and + rcu_read_unlock_bh(), or (3) any pair of primitives that disables + and re-enables preemption, for example, rcu_read_lock_sched() and + rcu_read_unlock_sched(). If the updater uses synchronize_srcu() + or call_srcu(), then the corresponding readers must use + srcu_read_lock() and srcu_read_unlock(), and with the same + srcu_struct. The rules for the expedited RCU grace-period-wait + primitives are the same as for their non-expedited counterparts. + + If the updater uses call_rcu_tasks() or synchronize_rcu_tasks(), + then the readers must refrain from executing voluntary + context switches, that is, from blocking. If the updater uses + call_rcu_tasks_trace() or synchronize_rcu_tasks_trace(), then + the corresponding readers must use rcu_read_lock_trace() and + rcu_read_unlock_trace(). If an updater uses call_rcu_tasks_rude() + or synchronize_rcu_tasks_rude(), then the corresponding readers + must use anything that disables interrupts. + + Mixing things up will result in confusion and broken kernels, and + has even resulted in an exploitable security issue. Therefore, + when using non-obvious pairs of primitives, commenting is + of course a must. One example of non-obvious pairing is + the XDP feature in networking, which calls BPF programs from + network-driver NAPI (softirq) context. BPF relies heavily on RCU + protection for its data structures, but because the BPF program + invocation happens entirely within a single local_bh_disable() + section in a NAPI poll cycle, this usage is safe. The reason + that this usage is safe is that readers can use anything that + disables BH when updaters use call_rcu() or synchronize_rcu(). 8. Although synchronize_rcu() is slower than is call_rcu(), it usually results in simpler code. So, unless update performance is diff --git a/Documentation/admin-guide/bootconfig.rst b/Documentation/admin-guide/bootconfig.rst index 452b7dcd7f6b..6a79f2e59396 100644 --- a/Documentation/admin-guide/bootconfig.rst +++ b/Documentation/admin-guide/bootconfig.rst @@ -89,13 +89,35 @@ you can use ``+=`` operator. For example:: In this case, the key ``foo`` has ``bar``, ``baz`` and ``qux``. -However, a sub-key and a value can not co-exist under a parent key. -For example, following config is NOT allowed.:: +Moreover, sub-keys and a value can coexist under a parent key. +For example, following config is allowed.:: foo = value1 - foo.bar = value2 # !ERROR! subkey "bar" and value "value1" can NOT co-exist - foo.bar := value2 # !ERROR! even with the override operator, this is NOT allowed. + foo.bar = value2 + foo := value3 # This will update foo's value. + +Note, since there is no syntax to put a raw value directly under a +structured key, you have to define it outside of the brace. For example:: + + foo { + bar = value1 + bar { + baz = value2 + qux = value3 + } + } + +Also, the order of the value node under a key is fixed. If there +are a value and subkeys, the value is always the first child node +of the key. Thus if user specifies subkeys first, e.g.:: + + foo.bar = value1 + foo = value2 + +In the program (and /proc/bootconfig), it will be shown as below:: + foo = value2 + foo.bar = value1 Comments -------- diff --git a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst index 36d43ae7dc13..16253eda192e 100644 --- a/Documentation/admin-guide/cgroup-v1/blkio-controller.rst +++ b/Documentation/admin-guide/cgroup-v1/blkio-controller.rst @@ -17,36 +17,37 @@ level logical devices like device mapper. HOWTO ===== + Throttling/Upper Limit policy ----------------------------- -- Enable Block IO controller:: +Enable Block IO controller:: CONFIG_BLK_CGROUP=y -- Enable throttling in block layer:: +Enable throttling in block layer:: CONFIG_BLK_DEV_THROTTLING=y -- Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: +Mount blkio controller (see cgroups.txt, Why are cgroups needed?):: mount -t cgroup -o blkio none /sys/fs/cgroup/blkio -- Specify a bandwidth rate on particular device for root group. The format - for policy is "<major>:<minor> <bytes_per_second>":: +Specify a bandwidth rate on particular device for root group. The format +for policy is "<major>:<minor> <bytes_per_second>":: echo "8:16 1048576" > /sys/fs/cgroup/blkio/blkio.throttle.read_bps_device - Above will put a limit of 1MB/second on reads happening for root group - on device having major/minor number 8:16. +This will put a limit of 1MB/second on reads happening for root group +on device having major/minor number 8:16. -- Run dd to read a file and see if rate is throttled to 1MB/s or not:: +Run dd to read a file and see if rate is throttled to 1MB/s or not:: # dd iflag=direct if=/mnt/common/zerofile of=/dev/null bs=4K count=1024 1024+0 records in 1024+0 records out 4194304 bytes (4.2 MB) copied, 4.0001 s, 1.0 MB/s - Limits for writes can be put using blkio.throttle.write_bps_device file. +Limits for writes can be put using blkio.throttle.write_bps_device file. Hierarchical Cgroups ==================== @@ -79,85 +80,89 @@ following:: Various user visible config options =================================== -CONFIG_BLK_CGROUP - - Block IO controller. -CONFIG_BFQ_CGROUP_DEBUG - - Debug help. Right now some additional stats file show up in cgroup + CONFIG_BLK_CGROUP + Block IO controller. + + CONFIG_BFQ_CGROUP_DEBUG + Debug help. Right now some additional stats file show up in cgroup if this option is enabled. -CONFIG_BLK_DEV_THROTTLING - - Enable block device throttling support in block layer. + CONFIG_BLK_DEV_THROTTLING + Enable block device throttling support in block layer. Details of cgroup files ======================= + Proportional weight policy files -------------------------------- -- blkio.weight - - Specifies per cgroup weight. This is default weight of the group - on all the devices until and unless overridden by per device rule. - (See blkio.weight_device). - Currently allowed range of weights is from 10 to 1000. -- blkio.weight_device - - One can specify per cgroup per device rules using this interface. - These rules override the default value of group weight as specified - by blkio.weight. + blkio.bfq.weight + Specifies per cgroup weight. This is default weight of the group + on all the devices until and unless overridden by per device rule + (see `blkio.bfq.weight_device` below). + + Currently allowed range of weights is from 1 to 1000. For more details, + see Documentation/block/bfq-iosched.rst. + + blkio.bfq.weight_device + Specifes per cgroup per device weights, overriding the default group + weight. For more details, see Documentation/block/bfq-iosched.rst. Following is the format:: - # echo dev_maj:dev_minor weight > blkio.weight_device + # echo dev_maj:dev_minor weight > blkio.bfq.weight_device Configure weight=300 on /dev/sdb (8:16) in this cgroup:: - # echo 8:16 300 > blkio.weight_device - # cat blkio.weight_device + # echo 8:16 300 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 Configure weight=500 on /dev/sda (8:0) in this cgroup:: - # echo 8:0 500 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 500 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:0 500 8:16 300 Remove specific weight for /dev/sda in this cgroup:: - # echo 8:0 0 > blkio.weight_device - # cat blkio.weight_device + # echo 8:0 0 > blkio.bfq.weight_device + # cat blkio.bfq.weight_device dev weight 8:16 300 -- blkio.time - - disk time allocated to cgroup per device in milliseconds. First + blkio.time + Disk time allocated to cgroup per device in milliseconds. First two fields specify the major and minor number of the device and third field specifies the disk time allocated to group in milliseconds. -- blkio.sectors - - number of sectors transferred to/from disk by the group. First + blkio.sectors + Number of sectors transferred to/from disk by the group. First two fields specify the major and minor number of the device and third field specifies the number of sectors transferred by the group to/from the device. -- blkio.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of bytes. -- blkio.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.io_service_time - - Total amount of time between request dispatch and request completion + blkio.io_service_time + Total amount of time between request dispatch and request completion for the IOs done by this cgroup. This is in nanoseconds to make it meaningful for flash devices too. For devices with queue depth of 1, this time represents the actual service time. When queue_depth > 1, @@ -170,8 +175,8 @@ Proportional weight policy files specifies the operation type and the fourth field specifies the io_service_time in ns. -- blkio.io_wait_time - - Total amount of time the IOs for this cgroup spent waiting in the + blkio.io_wait_time + Total amount of time the IOs for this cgroup spent waiting in the scheduler queues for service. This can be greater than the total time elapsed since it is cumulative io_wait_time for all IOs. It is not a measure of total time the cgroup spent waiting but rather a measure of @@ -185,24 +190,24 @@ Proportional weight policy files minor number of the device, third field specifies the operation type and the fourth field specifies the io_wait_time in ns. -- blkio.io_merged - - Total number of bios/requests merged into requests belonging to this + blkio.io_merged + Total number of bios/requests merged into requests belonging to this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.io_queued - - Total number of requests queued up at any given instant for this + blkio.io_queued + Total number of requests queued up at any given instant for this cgroup. This is further divided by the type of operation - read or write, sync or async. -- blkio.avg_queue_size - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.avg_queue_size + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. The average queue size for this cgroup over the entire time of this cgroup's existence. Queue size samples are taken each time one of the queues of this cgroup gets a timeslice. -- blkio.group_wait_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.group_wait_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time the cgroup had to wait since it became busy (i.e., went from 0 to 1 request queued) to get a timeslice for one of its queues. This is different from the io_wait_time which is the @@ -212,8 +217,8 @@ Proportional weight policy files will only report the group_wait_time accumulated till the last time it got a timeslice and will not include the current delta. -- blkio.empty_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.empty_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time a cgroup spends without any pending requests when not being served, i.e., it does not include any time spent idling for one of the queues of the cgroup. This is in @@ -221,8 +226,8 @@ Proportional weight policy files the stat will only report the empty_time accumulated till the last time it had a pending request and will not include the current delta. -- blkio.idle_time - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. + blkio.idle_time + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This is the amount of time spent by the IO scheduler idling for a given cgroup in anticipation of a better request than the existing ones from other queues/cgroups. This is in nanoseconds. If this is read @@ -230,60 +235,60 @@ Proportional weight policy files idle_time accumulated till the last idle period and will not include the current delta. -- blkio.dequeue - - Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This + blkio.dequeue + Debugging aid only enabled if CONFIG_BFQ_CGROUP_DEBUG=y. This gives the statistics about how many a times a group was dequeued from service tree of the device. First two fields specify the major and minor number of the device and third field specifies the number of times a group was dequeued from a particular device. -- blkio.*_recursive - - Recursive version of various stats. These files show the + blkio.*_recursive + Recursive version of various stats. These files show the same information as their non-recursive counterparts but include stats from all the descendant cgroups. Throttling/Upper limit policy files ----------------------------------- -- blkio.throttle.read_bps_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_bps_device + Specifies upper limit on READ rate from the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.read_bps_device -- blkio.throttle.write_bps_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_bps_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in bytes per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_bytes_per_second>" > /cgrp/blkio.throttle.write_bps_device -- blkio.throttle.read_iops_device - - Specifies upper limit on READ rate from the device. IO rate is + blkio.throttle.read_iops_device + Specifies upper limit on READ rate from the device. IO rate is specified in IO per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.read_iops_device -- blkio.throttle.write_iops_device - - Specifies upper limit on WRITE rate to the device. IO rate is + blkio.throttle.write_iops_device + Specifies upper limit on WRITE rate to the device. IO rate is specified in io per second. Rules are per device. Following is the format:: echo "<major>:<minor> <rate_io_per_second>" > /cgrp/blkio.throttle.write_iops_device -Note: If both BW and IOPS rules are specified for a device, then IO is - subjected to both the constraints. + Note: If both BW and IOPS rules are specified for a device, then IO is + subjected to both the constraints. -- blkio.throttle.io_serviced - - Number of IOs (bio) issued to the disk by the group. These + blkio.throttle.io_serviced + Number of IOs (bio) issued to the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field specifies the number of IOs. -- blkio.throttle.io_service_bytes - - Number of bytes transferred to/from the disk by the group. These + blkio.throttle.io_service_bytes + Number of bytes transferred to/from the disk by the group. These are further divided by the type of operation - read or write, sync or async. First two fields specify the major and minor number of the device, third field specifies the operation type and the fourth field @@ -291,6 +296,6 @@ Note: If both BW and IOPS rules are specified for a device, then IO is Common files among various policies ----------------------------------- -- blkio.reset_stats - - Writing an int to this file will result in resetting all the stats + blkio.reset_stats + Writing an int to this file will result in resetting all the stats for that cgroup. diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index b1e81aa8598a..5c7377b5bd3e 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -56,6 +56,7 @@ v1 is available under :ref:`Documentation/admin-guide/cgroup-v1/index.rst <cgrou 5-3-3. IO Latency 5-3-3-1. How IO Latency Throttling Works 5-3-3-2. IO Latency Interface Files + 5-3-4. IO Priority 5-4. PID 5-4-1. PID Interface Files 5-5. Cpuset @@ -952,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 =========== @@ -1866,6 +1882,60 @@ IO Latency Interface Files duration of time between evaluation events. Windows only elapse with IO activity. Idle periods extend the most recent window. +IO Priority +~~~~~~~~~~~ + +A single attribute controls the behavior of the I/O priority cgroup policy, +namely the blkio.prio.class attribute. The following values are accepted for +that attribute: + + no-change + Do not modify the I/O priority class. + + none-to-rt + For requests that do not have an I/O priority class (NONE), + change the I/O priority class into RT. Do not modify + the I/O priority class of other requests. + + restrict-to-be + For requests that do not have an I/O priority class or that have I/O + priority class RT, change it into BE. Do not modify the I/O priority + class of requests that have priority class IDLE. + + idle + Change the I/O priority class of all requests into IDLE, the lowest + I/O priority class. + +The following numerical values are associated with the I/O priority policies: + ++-------------+---+ +| no-change | 0 | ++-------------+---+ +| none-to-rt | 1 | ++-------------+---+ +| rt-to-be | 2 | ++-------------+---+ +| all-to-idle | 3 | ++-------------+---+ + +The numerical value that corresponds to each I/O priority class is as follows: + ++-------------------------------+---+ +| IOPRIO_CLASS_NONE | 0 | ++-------------------------------+---+ +| IOPRIO_CLASS_RT (real-time) | 1 | ++-------------------------------+---+ +| IOPRIO_CLASS_BE (best effort) | 2 | ++-------------------------------+---+ +| IOPRIO_CLASS_IDLE | 3 | ++-------------------------------+---+ + +The algorithm to set the I/O priority class for a request is as follows: + +- Translate the I/O priority class policy into a number. +- Change the request I/O priority class into the maximum of the I/O priority + class policy number and the numerical I/O priority class. + PID --- diff --git a/Documentation/admin-guide/device-mapper/writecache.rst b/Documentation/admin-guide/device-mapper/writecache.rst index dce0184e07ca..65427d8dfca6 100644 --- a/Documentation/admin-guide/device-mapper/writecache.rst +++ b/Documentation/admin-guide/device-mapper/writecache.rst @@ -12,7 +12,6 @@ first sector should contain valid superblock from previous invocation. Constructor parameters: 1. type of the cache device - "p" or "s" - - p - persistent memory - s - SSD 2. the underlying device that will be cached @@ -21,7 +20,6 @@ Constructor parameters: size) 5. the number of optional parameters (the parameters with an argument count as two) - start_sector n (default: 0) offset from the start of cache device in 512-byte sectors high_watermark n (default: 50) @@ -53,6 +51,27 @@ Constructor parameters: - some underlying devices perform better with fua, some with nofua. The user should test it + cleaner + when this option is activated (either in the constructor + arguments or by a message), the cache will not promote + new writes (however, writes to already cached blocks are + promoted, to avoid data corruption due to misordered + writes) and it will gradually writeback any cached + data. The userspace can then monitor the cleaning + process with "dmsetup status". When the number of cached + blocks drops to zero, userspace can unload the + dm-writecache target and replace it with dm-linear or + other targets. + max_age n + specifies the maximum age of a block in milliseconds. If + a block is stored in the cache for too long, it will be + written to the underlying device and cleaned up. + metadata_only + only metadata is promoted to the cache. This option + improves performance for heavier REQ_META workloads. + pause_writeback n (default: 3000) + pause writeback if there was some write I/O redirected to + the origin volume in the last n milliseconds Status: 1. error indicator - 0 if there was no error, otherwise error number @@ -77,3 +96,5 @@ Messages: 5. resume the device, so that it will use the linear target 6. the cache device is now inactive and it can be deleted + cleaner + See above "cleaner" constructor documentation. diff --git a/Documentation/admin-guide/kernel-parameters.rst b/Documentation/admin-guide/kernel-parameters.rst index 3996b54158bf..01ba293a2d70 100644 --- a/Documentation/admin-guide/kernel-parameters.rst +++ b/Documentation/admin-guide/kernel-parameters.rst @@ -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 diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index d1c9e9766984..bdb22006f713 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -113,7 +113,7 @@ the GPE dispatcher. This facility can be used to prevent such uncontrolled GPE floodings. - Format: <byte> + Format: <byte> or <bitmap-list> acpi_no_auto_serialize [HW,ACPI] Disable auto-serialization of AML methods @@ -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 @@ -497,16 +500,21 @@ ccw_timeout_log [S390] See Documentation/s390/common_io.rst for details. - cgroup_disable= [KNL] Disable a particular controller - Format: {name of the controller(s) to disable} + cgroup_disable= [KNL] Disable a particular controller or optional feature + Format: {name of the controller(s) or feature(s) to disable} The effects of cgroup_disable=foo are: - foo isn't auto-mounted if you mount all cgroups in a single hierarchy - foo isn't visible as an individually mountable subsystem + - if foo is an optional feature then the feature is + disabled and corresponding cgroup files are not + created {Currently only "memory" controller deal with this and cut the overhead, others just disable the usage. So only cgroup_disable=memory is actually worthy} + Specifying "pressure" disables per-cgroup pressure + stall information accounting feature cgroup_no_v1= [KNL] Disable cgroup controllers and named hierarchies in v1 Format: { { controller | "all" | "named" } @@ -1114,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 @@ -1589,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 @@ -2009,7 +2039,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 @@ -2020,6 +2050,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. @@ -2855,6 +2889,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> @@ -3591,6 +3629,12 @@ off: turn off poisoning (default) on: turn on poisoning + page_reporting.page_reporting_order= + [KNL] Minimal page reporting order + Format: <integer> + Adjust the minimal page reporting order. The page + reporting is disabled when it exceeds (MAX_ORDER-1). + panic= [KNL] Kernel behaviour on panic: delay <timeout> timeout > 0: seconds before rebooting timeout = 0: wait forever @@ -4315,6 +4359,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. @@ -5633,12 +5682,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 diff --git a/Documentation/admin-guide/laptops/laptop-mode.rst b/Documentation/admin-guide/laptops/laptop-mode.rst index c984c4262f2e..b61cc601d298 100644 --- a/Documentation/admin-guide/laptops/laptop-mode.rst +++ b/Documentation/admin-guide/laptops/laptop-mode.rst @@ -101,17 +101,6 @@ this results in concentration of disk activity in a small time interval which occurs only once every 10 minutes, or whenever the disk is forced to spin up by a cache miss. The disk can then be spun down in the periods of inactivity. -If you want to find out which process caused the disk to spin up, you can -gather information by setting the flag /proc/sys/vm/block_dump. When this flag -is set, Linux reports all disk read and write operations that take place, and -all block dirtyings done to files. This makes it possible to debug why a disk -needs to spin up, and to increase battery life even more. The output of -block_dump is written to the kernel output, and it can be retrieved using -"dmesg". When you use block_dump and your kernel logging level also includes -kernel debugging messages, you probably want to turn off klogd, otherwise -the output of block_dump will be logged, causing disk activity that is not -normally there. - Configuration ------------- diff --git a/Documentation/admin-guide/lockup-watchdogs.rst b/Documentation/admin-guide/lockup-watchdogs.rst index 290840c160af..3e09284a8b9b 100644 --- a/Documentation/admin-guide/lockup-watchdogs.rst +++ b/Documentation/admin-guide/lockup-watchdogs.rst @@ -39,7 +39,7 @@ in principle, they should work in any architecture where these subsystems are present. A periodic hrtimer runs to generate interrupts and kick the watchdog -task. An NMI perf event is generated every "watchdog_thresh" +job. An NMI perf event is generated every "watchdog_thresh" (compile-time initialized to 10 and configurable through sysctl of the same name) seconds to check for hardlockups. If any CPU in the system does not receive any hrtimer interrupt during that time the @@ -47,7 +47,7 @@ does not receive any hrtimer interrupt during that time the generate a kernel warning or call panic, depending on the configuration. -The watchdog task is a high priority kernel thread that updates a +The watchdog job runs in a stop scheduling thread that updates a timestamp every time it is scheduled. If that timestamp is not updated for 2*watchdog_thresh seconds (the softlockup threshold) the 'softlockup detector' (coded inside the hrtimer callback function) diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst b/Documentation/admin-guide/mm/hugetlbpage.rst index f7b1c7462991..8abaeb144e44 100644 --- a/Documentation/admin-guide/mm/hugetlbpage.rst +++ b/Documentation/admin-guide/mm/hugetlbpage.rst @@ -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. diff --git a/Documentation/admin-guide/mm/memory-hotplug.rst b/Documentation/admin-guide/mm/memory-hotplug.rst index 05d51d2d8beb..c6bae2d77160 100644 --- a/Documentation/admin-guide/mm/memory-hotplug.rst +++ b/Documentation/admin-guide/mm/memory-hotplug.rst @@ -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 diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index 340a5aee9b80..fb578fbbb76c 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -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 diff --git a/Documentation/admin-guide/mm/userfaultfd.rst b/Documentation/admin-guide/mm/userfaultfd.rst index 3aa38e8b8361..6528036093e1 100644 --- a/Documentation/admin-guide/mm/userfaultfd.rst +++ b/Documentation/admin-guide/mm/userfaultfd.rst @@ -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 diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index 10dd4b111e5c..426162009ce9 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -1297,11 +1297,11 @@ This parameter can be used to control the soft lockup detector. = ================================= The soft lockup detector monitors CPUs for threads that are hogging the CPUs -without rescheduling voluntarily, and thus prevent the 'watchdog/N' threads -from running. The mechanism depends on the CPUs ability to respond to timer -interrupts which are needed for the 'watchdog/N' threads to be woken up by -the watchdog timer function, otherwise the NMI watchdog — if enabled — can -detect a hard lockup condition. +without rescheduling voluntarily, and thus prevent the 'migration/N' threads +from running, causing the watchdog work fail to execute. The mechanism depends +on the CPUs ability to respond to timer interrupts which are needed for the +watchdog work to be queued by the watchdog timer function, otherwise the NMI +watchdog — if enabled — can detect a hard lockup condition. stack_erasing diff --git a/Documentation/admin-guide/sysctl/vm.rst b/Documentation/admin-guide/sysctl/vm.rst index 586cd4b86428..003d5cc3751b 100644 --- a/Documentation/admin-guide/sysctl/vm.rst +++ b/Documentation/admin-guide/sysctl/vm.rst @@ -25,7 +25,6 @@ files can be found in mm/swap.c. Currently, these files are in /proc/sys/vm: - admin_reserve_kbytes -- block_dump - compact_memory - compaction_proactiveness - compact_unevictable_allowed @@ -64,7 +63,7 @@ Currently, these files are in /proc/sys/vm: - overcommit_ratio - page-cluster - panic_on_oom -- percpu_pagelist_fraction +- percpu_pagelist_high_fraction - stat_interval - stat_refresh - numa_stat @@ -106,13 +105,6 @@ On x86_64 this is about 128MB. Changing this takes effect whenever an application requests memory. -block_dump -========== - -block_dump enables block I/O debugging when set to a nonzero value. More -information on block I/O debugging is in Documentation/admin-guide/laptops/laptop-mode.rst. - - compact_memory ============== @@ -790,22 +782,24 @@ panic_on_oom=2+kdump gives you very strong tool to investigate why oom happens. You can get snapshot. -percpu_pagelist_fraction -======================== +percpu_pagelist_high_fraction +============================= -This is the fraction of pages at most (high mark pcp->high) in each zone that -are allocated for each per cpu page list. The min value for this is 8. It -means that we don't allow more than 1/8th of pages in each zone to be -allocated in any single per_cpu_pagelist. This entry only changes the value -of hot per cpu pagelists. User can specify a number like 100 to allocate -1/100th of each zone to each per cpu page list. +This is the fraction of pages in each zone that are can be stored to +per-cpu page lists. It is an upper boundary that is divided depending +on the number of online CPUs. The min value for this is 8 which means +that we do not allow more than 1/8th of pages in each zone to be stored +on per-cpu page lists. This entry only changes the value of hot per-cpu +page lists. A user can specify a number like 100 to allocate 1/100th of +each zone between per-cpu lists. -The batch value of each per cpu pagelist is also updated as a result. It is -set to pcp->high/4. The upper limit of batch is (PAGE_SHIFT * 8) +The batch value of each per-cpu page list remains the same regardless of +the value of the high fraction so allocation latencies are unaffected. -The initial value is zero. Kernel does not use this value at boot time to set -the high water marks for each per cpu page list. If the user writes '0' to this -sysctl, it will revert to this default behavior. +The initial value is zero. Kernel uses this value to set the high pcp->high +mark based on the low watermark for the zone and the number of local +online CPUs. If the user writes '0' to this sysctl, it will revert to +this default behavior. stat_interval @@ -936,12 +930,12 @@ allocations, THP and hugetlbfs pages. To make it sensible with respect to the watermark_scale_factor parameter, the unit is in fractions of 10,000. The default value of -15,000 on !DISCONTIGMEM configurations means that up to 150% of the high -watermark will be reclaimed in the event of a pageblock being mixed due -to fragmentation. The level of reclaim is determined by the number of -fragmentation events that occurred in the recent past. If this value is -smaller than a pageblock then a pageblocks worth of pages will be reclaimed -(e.g. 2MB on 64-bit x86). A boost factor of 0 will disable the feature. +15,000 means that up to 150% of the high watermark will be reclaimed in the +event of a pageblock being mixed due to fragmentation. The level of reclaim +is determined by the number of fragmentation events that occurred in the +recent past. If this value is smaller than a pageblock then a pageblocks +worth of pages will be reclaimed (e.g. 2MB on 64-bit x86). A boost factor +of 0 will disable the feature. watermark_scale_factor diff --git a/Documentation/admin-guide/thunderbolt.rst b/Documentation/admin-guide/thunderbolt.rst index f18e881373c4..2ed79f41a411 100644 --- a/Documentation/admin-guide/thunderbolt.rst +++ b/Documentation/admin-guide/thunderbolt.rst @@ -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 diff --git a/Documentation/block/bfq-iosched.rst b/Documentation/block/bfq-iosched.rst index 66c5a4e54130..df3a8a47f58c 100644 --- a/Documentation/block/bfq-iosched.rst +++ b/Documentation/block/bfq-iosched.rst @@ -553,20 +553,36 @@ throughput sustainable with bfq, because updating the blkio.bfq.* stats is rather costly, especially for some of the stats enabled by CONFIG_BFQ_CGROUP_DEBUG. -Parameters to set ------------------ +Parameters +---------- -For each group, there is only the following parameter to set. +For each group, the following parameters can be set: -weight (namely blkio.bfq.weight or io.bfq-weight): the weight of the -group inside its parent. Available values: 1..1000 (default 100). The -linear mapping between ioprio and weights, described at the beginning -of the tunable section, is still valid, but all weights higher than -IOPRIO_BE_NR*10 are mapped to ioprio 0. + weight + This specifies the default weight for the cgroup inside its parent. + Available values: 1..1000 (default: 100). -Recall that, if low-latency is set, then BFQ automatically raises the -weight of the queues associated with interactive and soft real-time -applications. Unset this tunable if you need/want to control weights. + For cgroup v1, it is set by writing the value to `blkio.bfq.weight`. + + For cgroup v2, it is set by writing the value to `io.bfq.weight`. + (with an optional prefix of `default` and a space). + + The linear mapping between ioprio and weights, described at the beginning + of the tunable section, is still valid, but all weights higher than + IOPRIO_BE_NR*10 are mapped to ioprio 0. + + Recall that, if low-latency is set, then BFQ automatically raises the + weight of the queues associated with interactive and soft real-time + applications. Unset this tunable if you need/want to control weights. + + weight_device + This specifies a per-device weight for the cgroup. The syntax is + `minor:major weight`. A weight of `0` may be used to reset to the default + weight. + + For cgroup v1, it is set by writing the value to `blkio.bfq.weight_device`. + + For cgroup v2, the file name is `io.bfq.weight`. [1] diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index a702f67dd45f..baea6c2abba5 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -12,6 +12,19 @@ BPF instruction-set. The Cilium project also maintains a `BPF and XDP Reference Guide`_ that goes into great technical depth about the BPF Architecture. +libbpf +====== + +Libbpf is a userspace library for loading and interacting with bpf programs. + +.. toctree:: + :maxdepth: 1 + + libbpf/libbpf + libbpf/libbpf_api + libbpf/libbpf_build + libbpf/libbpf_naming_convention + BPF Type Format (BTF) ===================== @@ -84,6 +97,7 @@ Other :maxdepth: 1 ringbuf + llvm_reloc .. Links: .. _networking-filter: ../networking/filter.rst diff --git a/Documentation/bpf/libbpf/libbpf.rst b/Documentation/bpf/libbpf/libbpf.rst new file mode 100644 index 000000000000..1b1e61d5ead1 --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf.rst @@ -0,0 +1,14 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +libbpf +====== + +This is documentation for libbpf, a userspace library for loading and +interacting with bpf programs. + +All general BPF questions, including kernel functionality, libbpf APIs and +their application, should be sent to bpf@vger.kernel.org mailing list. +You can `subscribe <http://vger.kernel.org/vger-lists.html#bpf>`_ to the +mailing list search its `archive <https://lore.kernel.org/bpf/>`_. +Please search the archive before asking new questions. It very well might +be that this was already addressed or answered before. diff --git a/Documentation/bpf/libbpf/libbpf_api.rst b/Documentation/bpf/libbpf/libbpf_api.rst new file mode 100644 index 000000000000..f07eecd054da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_api.rst @@ -0,0 +1,27 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API +=== + +This documentation is autogenerated from header files in libbpf, tools/lib/bpf + +.. kernel-doc:: tools/lib/bpf/libbpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/btf.h + :internal: + +.. kernel-doc:: tools/lib/bpf/xsk.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_tracing.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_core_read.h + :internal: + +.. kernel-doc:: tools/lib/bpf/bpf_endian.h + :internal:
\ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_build.rst b/Documentation/bpf/libbpf/libbpf_build.rst new file mode 100644 index 000000000000..8e8c23e8093d --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_build.rst @@ -0,0 +1,37 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +Building libbpf +=============== + +libelf and zlib are internal dependencies of libbpf and thus are required to link +against and must be installed on the system for applications to work. +pkg-config is used by default to find libelf, and the program called +can be overridden with PKG_CONFIG. + +If using pkg-config at build time is not desired, it can be disabled by +setting NO_PKG_CONFIG=1 when calling make. + +To build both static libbpf.a and shared libbpf.so: + +.. code-block:: bash + + $ cd src + $ make + +To build only static libbpf.a library in directory build/ and install them +together with libbpf headers in a staging directory root/: + +.. code-block:: bash + + $ cd src + $ mkdir build root + $ BUILD_STATIC_ONLY=y OBJDIR=build DESTDIR=root make install + +To build both static libbpf.a and shared libbpf.so against a custom libelf +dependency installed in /build/root/ and install them together with libbpf +headers in a build directory /build/root/: + +.. code-block:: bash + + $ cd src + $ PKG_CONFIG_PATH=/build/root/lib64/pkgconfig DESTDIR=/build/root make
\ No newline at end of file diff --git a/Documentation/bpf/libbpf/libbpf_naming_convention.rst b/Documentation/bpf/libbpf/libbpf_naming_convention.rst new file mode 100644 index 000000000000..3de1d51e41da --- /dev/null +++ b/Documentation/bpf/libbpf/libbpf_naming_convention.rst @@ -0,0 +1,162 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +API naming convention +===================== + +libbpf API provides access to a few logically separated groups of +functions and types. Every group has its own naming convention +described here. It's recommended to follow these conventions whenever a +new function or type is added to keep libbpf API clean and consistent. + +All types and functions provided by libbpf API should have one of the +following prefixes: ``bpf_``, ``btf_``, ``libbpf_``, ``xsk_``, +``btf_dump_``, ``ring_buffer_``, ``perf_buffer_``. + +System call wrappers +-------------------- + +System call wrappers are simple wrappers for commands supported by +sys_bpf system call. These wrappers should go to ``bpf.h`` header file +and map one to one to corresponding commands. + +For example ``bpf_map_lookup_elem`` wraps ``BPF_MAP_LOOKUP_ELEM`` +command of sys_bpf, ``bpf_prog_attach`` wraps ``BPF_PROG_ATTACH``, etc. + +Objects +------- + +Another class of types and functions provided by libbpf API is "objects" +and functions to work with them. Objects are high-level abstractions +such as BPF program or BPF map. They're represented by corresponding +structures such as ``struct bpf_object``, ``struct bpf_program``, +``struct bpf_map``, etc. + +Structures are forward declared and access to their fields should be +provided via corresponding getters and setters rather than directly. + +These objects are associated with corresponding parts of ELF object that +contains compiled BPF programs. + +For example ``struct bpf_object`` represents ELF object itself created +from an ELF file or from a buffer, ``struct bpf_program`` represents a +program in ELF object and ``struct bpf_map`` is a map. + +Functions that work with an object have names built from object name, +double underscore and part that describes function purpose. + +For example ``bpf_object__open`` consists of the name of corresponding +object, ``bpf_object``, double underscore and ``open`` that defines the +purpose of the function to open ELF file and create ``bpf_object`` from +it. + +All objects and corresponding functions other than BTF related should go +to ``libbpf.h``. BTF types and functions should go to ``btf.h``. + +Auxiliary functions +------------------- + +Auxiliary functions and types that don't fit well in any of categories +described above should have ``libbpf_`` prefix, e.g. +``libbpf_get_error`` or ``libbpf_prog_type_by_name``. + +AF_XDP functions +------------------- + +AF_XDP functions should have an ``xsk_`` prefix, e.g. +``xsk_umem__get_data`` or ``xsk_umem__create``. The interface consists +of both low-level ring access functions and high-level configuration +functions. These can be mixed and matched. Note that these functions +are not reentrant for performance reasons. + +ABI +========== + +libbpf can be both linked statically or used as DSO. To avoid possible +conflicts with other libraries an application is linked with, all +non-static libbpf symbols should have one of the prefixes mentioned in +API documentation above. See API naming convention to choose the right +name for a new symbol. + +Symbol visibility +----------------- + +libbpf follow the model when all global symbols have visibility "hidden" +by default and to make a symbol visible it has to be explicitly +attributed with ``LIBBPF_API`` macro. For example: + +.. code-block:: c + + LIBBPF_API int bpf_prog_get_fd_by_id(__u32 id); + +This prevents from accidentally exporting a symbol, that is not supposed +to be a part of ABI what, in turn, improves both libbpf developer- and +user-experiences. + +ABI versionning +--------------- + +To make future ABI extensions possible libbpf ABI is versioned. +Versioning is implemented by ``libbpf.map`` version script that is +passed to linker. + +Version name is ``LIBBPF_`` prefix + three-component numeric version, +starting from ``0.0.1``. + +Every time ABI is being changed, e.g. because a new symbol is added or +semantic of existing symbol is changed, ABI version should be bumped. +This bump in ABI version is at most once per kernel development cycle. + +For example, if current state of ``libbpf.map`` is: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + +, and a new symbol ``bpf_func_c`` is being introduced, then +``libbpf.map`` should be changed like this: + +.. code-block:: c + + LIBBPF_0.0.1 { + global: + bpf_func_a; + bpf_func_b; + local: + \*; + }; + LIBBPF_0.0.2 { + global: + bpf_func_c; + } LIBBPF_0.0.1; + +, where new version ``LIBBPF_0.0.2`` depends on the previous +``LIBBPF_0.0.1``. + +Format of version script and ways to handle ABI changes, including +incompatible ones, described in details in [1]. + +Stand-alone build +------------------- + +Under https://github.com/libbpf/libbpf there is a (semi-)automated +mirror of the mainline's version of libbpf for a stand-alone build. + +However, all changes to libbpf's code base must be upstreamed through +the mainline kernel tree. + +License +------------------- + +libbpf is dual-licensed under LGPL 2.1 and BSD 2-Clause. + +Links +------------------- + +[1] https://www.akkadia.org/drepper/dsohowto.pdf + (Chapter 3. Maintaining APIs and ABIs). diff --git a/Documentation/bpf/llvm_reloc.rst b/Documentation/bpf/llvm_reloc.rst new file mode 100644 index 000000000000..ca8957d5b671 --- /dev/null +++ b/Documentation/bpf/llvm_reloc.rst @@ -0,0 +1,240 @@ +.. SPDX-License-Identifier: (LGPL-2.1 OR BSD-2-Clause) + +==================== +BPF LLVM Relocations +==================== + +This document describes LLVM BPF backend relocation types. + +Relocation Record +================= + +LLVM BPF backend records each relocation with the following 16-byte +ELF structure:: + + typedef struct + { + Elf64_Addr r_offset; // Offset from the beginning of section. + Elf64_Xword r_info; // Relocation type and symbol index. + } Elf64_Rel; + +For example, for the following code:: + + int g1 __attribute__((section("sec"))); + int g2 __attribute__((section("sec"))); + static volatile int l1 __attribute__((section("sec"))); + static volatile int l2 __attribute__((section("sec"))); + int test() { + return g1 + g2 + l1 + l2; + } + +Compiled with ``clang -target bpf -O2 -c test.c``, the following is +the code with ``llvm-objdump -dr test.o``:: + + 0: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll + 0000000000000000: R_BPF_64_64 g1 + 2: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 3: 18 02 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r2 = 0 ll + 0000000000000018: R_BPF_64_64 g2 + 5: 61 20 00 00 00 00 00 00 r0 = *(u32 *)(r2 + 0) + 6: 0f 10 00 00 00 00 00 00 r0 += r1 + 7: 18 01 00 00 08 00 00 00 00 00 00 00 00 00 00 00 r1 = 8 ll + 0000000000000038: R_BPF_64_64 sec + 9: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 10: 0f 10 00 00 00 00 00 00 r0 += r1 + 11: 18 01 00 00 0c 00 00 00 00 00 00 00 00 00 00 00 r1 = 12 ll + 0000000000000058: R_BPF_64_64 sec + 13: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 14: 0f 10 00 00 00 00 00 00 r0 += r1 + 15: 95 00 00 00 00 00 00 00 exit + +There are four relations in the above for four ``LD_imm64`` instructions. +The following ``llvm-readelf -r test.o`` shows the binary values of the four +relocations:: + + Relocation section '.rel.text' at offset 0x190 contains 4 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000600000001 R_BPF_64_64 0000000000000000 g1 + 0000000000000018 0000000700000001 R_BPF_64_64 0000000000000004 g2 + 0000000000000038 0000000400000001 R_BPF_64_64 0000000000000000 sec + 0000000000000058 0000000400000001 R_BPF_64_64 0000000000000000 sec + +Each relocation is represented by ``Offset`` (8 bytes) and ``Info`` (8 bytes). +For example, the first relocation corresponds to the first instruction +(Offset 0x0) and the corresponding ``Info`` indicates the relocation type +of ``R_BPF_64_64`` (type 1) and the entry in the symbol table (entry 6). +The following is the symbol table with ``llvm-readelf -s test.o``:: + + Symbol table '.symtab' contains 8 entries: + Num: Value Size Type Bind Vis Ndx Name + 0: 0000000000000000 0 NOTYPE LOCAL DEFAULT UND + 1: 0000000000000000 0 FILE LOCAL DEFAULT ABS test.c + 2: 0000000000000008 4 OBJECT LOCAL DEFAULT 4 l1 + 3: 000000000000000c 4 OBJECT LOCAL DEFAULT 4 l2 + 4: 0000000000000000 0 SECTION LOCAL DEFAULT 4 sec + 5: 0000000000000000 128 FUNC GLOBAL DEFAULT 2 test + 6: 0000000000000000 4 OBJECT GLOBAL DEFAULT 4 g1 + 7: 0000000000000004 4 OBJECT GLOBAL DEFAULT 4 g2 + +The 6th entry is global variable ``g1`` with value 0. + +Similarly, the second relocation is at ``.text`` offset ``0x18``, instruction 3, +for global variable ``g2`` which has a symbol value 4, the offset +from the start of ``.data`` section. + +The third and fourth relocations refers to static variables ``l1`` +and ``l2``. From ``.rel.text`` section above, it is not clear +which symbols they really refers to as they both refers to +symbol table entry 4, symbol ``sec``, which has ``STT_SECTION`` type +and represents a section. So for static variable or function, +the section offset is written to the original insn +buffer, which is called ``A`` (addend). Looking at +above insn ``7`` and ``11``, they have section offset ``8`` and ``12``. +From symbol table, we can find that they correspond to entries ``2`` +and ``3`` for ``l1`` and ``l2``. + +In general, the ``A`` is 0 for global variables and functions, +and is the section offset or some computation result based on +section offset for static variables/functions. The non-section-offset +case refers to function calls. See below for more details. + +Different Relocation Types +========================== + +Six relocation types are supported. The following is an overview and +``S`` represents the value of the symbol in the symbol table:: + + Enum ELF Reloc Type Description BitSize Offset Calculation + 0 R_BPF_NONE None + 1 R_BPF_64_64 ld_imm64 insn 32 r_offset + 4 S + A + 2 R_BPF_64_ABS64 normal data 64 r_offset S + A + 3 R_BPF_64_ABS32 normal data 32 r_offset S + A + 4 R_BPF_64_NODYLD32 .BTF[.ext] data 32 r_offset S + A + 10 R_BPF_64_32 call insn 32 r_offset + 4 (S + A) / 8 - 1 + +For example, ``R_BPF_64_64`` relocation type is used for ``ld_imm64`` instruction. +The actual to-be-relocated data (0 or section offset) +is stored at ``r_offset + 4`` and the read/write +data bitsize is 32 (4 bytes). The relocation can be resolved with +the symbol value plus implicit addend. Note that the ``BitSize`` is 32 which +means the section offset must be less than or equal to ``UINT32_MAX`` and this +is enforced by LLVM BPF backend. + +In another case, ``R_BPF_64_ABS64`` relocation type is used for normal 64-bit data. +The actual to-be-relocated data is stored at ``r_offset`` and the read/write data +bitsize is 64 (8 bytes). The relocation can be resolved with +the symbol value plus implicit addend. + +Both ``R_BPF_64_ABS32`` and ``R_BPF_64_NODYLD32`` types are for 32-bit data. +But ``R_BPF_64_NODYLD32`` specifically refers to relocations in ``.BTF`` and +``.BTF.ext`` sections. For cases like bcc where llvm ``ExecutionEngine RuntimeDyld`` +is involved, ``R_BPF_64_NODYLD32`` types of relocations should not be resolved +to actual function/variable address. Otherwise, ``.BTF`` and ``.BTF.ext`` +become unusable by bcc and kernel. + +Type ``R_BPF_64_32`` is used for call instruction. The call target section +offset is stored at ``r_offset + 4`` (32bit) and calculated as +``(S + A) / 8 - 1``. + +Examples +======== + +Types ``R_BPF_64_64`` and ``R_BPF_64_32`` are used to resolve ``ld_imm64`` +and ``call`` instructions. For example:: + + __attribute__((noinline)) __attribute__((section("sec1"))) + int gfunc(int a, int b) { + return a * b; + } + static __attribute__((noinline)) __attribute__((section("sec1"))) + int lfunc(int a, int b) { + return a + b; + } + int global __attribute__((section("sec2"))); + int test(int a, int b) { + return gfunc(a, b) + lfunc(a, b) + global; + } + +Compiled with ``clang -target bpf -O2 -c test.c``, we will have +following code with `llvm-objdump -dr test.o``:: + + Disassembly of section .text: + + 0000000000000000 <test>: + 0: bf 26 00 00 00 00 00 00 r6 = r2 + 1: bf 17 00 00 00 00 00 00 r7 = r1 + 2: 85 10 00 00 ff ff ff ff call -1 + 0000000000000010: R_BPF_64_32 gfunc + 3: bf 08 00 00 00 00 00 00 r8 = r0 + 4: bf 71 00 00 00 00 00 00 r1 = r7 + 5: bf 62 00 00 00 00 00 00 r2 = r6 + 6: 85 10 00 00 02 00 00 00 call 2 + 0000000000000030: R_BPF_64_32 sec1 + 7: 0f 80 00 00 00 00 00 00 r0 += r8 + 8: 18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 r1 = 0 ll + 0000000000000040: R_BPF_64_64 global + 10: 61 11 00 00 00 00 00 00 r1 = *(u32 *)(r1 + 0) + 11: 0f 10 00 00 00 00 00 00 r0 += r1 + 12: 95 00 00 00 00 00 00 00 exit + + Disassembly of section sec1: + + 0000000000000000 <gfunc>: + 0: bf 20 00 00 00 00 00 00 r0 = r2 + 1: 2f 10 00 00 00 00 00 00 r0 *= r1 + 2: 95 00 00 00 00 00 00 00 exit + + 0000000000000018 <lfunc>: + 3: bf 20 00 00 00 00 00 00 r0 = r2 + 4: 0f 10 00 00 00 00 00 00 r0 += r1 + 5: 95 00 00 00 00 00 00 00 exit + +The first relocation corresponds to ``gfunc(a, b)`` where ``gfunc`` has a value of 0, +so the ``call`` instruction offset is ``(0 + 0)/8 - 1 = -1``. +The second relocation corresponds to ``lfunc(a, b)`` where ``lfunc`` has a section +offset ``0x18``, so the ``call`` instruction offset is ``(0 + 0x18)/8 - 1 = 2``. +The third relocation corresponds to ld_imm64 of ``global``, which has a section +offset ``0``. + +The following is an example to show how R_BPF_64_ABS64 could be generated:: + + int global() { return 0; } + struct t { void *g; } gbl = { global }; + +Compiled with ``clang -target bpf -O2 -g -c test.c``, we will see a +relocation below in ``.data`` section with command +``llvm-readelf -r test.o``:: + + Relocation section '.rel.data' at offset 0x458 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000000 0000000700000002 R_BPF_64_ABS64 0000000000000000 global + +The relocation says the first 8-byte of ``.data`` section should be +filled with address of ``global`` variable. + +With ``llvm-readelf`` output, we can see that dwarf sections have a bunch of +``R_BPF_64_ABS32`` and ``R_BPF_64_ABS64`` relocations:: + + Relocation section '.rel.debug_info' at offset 0x468 contains 13 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000006 0000000300000003 R_BPF_64_ABS32 0000000000000000 .debug_abbrev + 000000000000000c 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000012 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000016 0000000600000003 R_BPF_64_ABS32 0000000000000000 .debug_line + 000000000000001a 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 000000000000001e 0000000200000002 R_BPF_64_ABS64 0000000000000000 .text + 000000000000002b 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + 0000000000000037 0000000800000002 R_BPF_64_ABS64 0000000000000000 gbl + 0000000000000040 0000000400000003 R_BPF_64_ABS32 0000000000000000 .debug_str + ...... + +The .BTF/.BTF.ext sections has R_BPF_64_NODYLD32 relocations:: + + Relocation section '.rel.BTF' at offset 0x538 contains 1 entries: + Offset Info Type Symbol's Value Symbol's Name + 0000000000000084 0000000800000004 R_BPF_64_NODYLD32 0000000000000000 gbl + + Relocation section '.rel.BTF.ext' at offset 0x548 contains 2 entries: + Offset Info Type Symbol's Value Symbol's Name + 000000000000002c 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text + 0000000000000040 0000000200000004 R_BPF_64_NODYLD32 0000000000000000 .text diff --git a/Documentation/core-api/kernel-api.rst b/Documentation/core-api/kernel-api.rst index 741aa37dc181..2a7444e3a4c2 100644 --- a/Documentation/core-api/kernel-api.rst +++ b/Documentation/core-api/kernel-api.rst @@ -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: diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index d3f335ffc751..83ec4a556c19 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -447,11 +447,10 @@ When a test fails due to a failed ``kmalloc``:: When a test fails due to a missing KASAN report:: - # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:629 - Expected kasan_data->report_expected == kasan_data->report_found, but - kasan_data->report_expected == 1 - kasan_data->report_found == 0 - not ok 28 - kmalloc_double_kzfree + # kmalloc_double_kzfree: EXPECTATION FAILED at lib/test_kasan.c:974 + KASAN failure expected in "kfree_sensitive(ptr)", but none occurred + not ok 44 - kmalloc_double_kzfree + At the end the cumulative status of all KASAN tests is printed. On success:: diff --git a/Documentation/dev-tools/kcsan.rst b/Documentation/dev-tools/kcsan.rst index d85ce238ace7..6a600cf8430b 100644 --- a/Documentation/dev-tools/kcsan.rst +++ b/Documentation/dev-tools/kcsan.rst @@ -27,75 +27,57 @@ Error reports A typical data race report looks like this:: ================================================================== - BUG: KCSAN: data-race in generic_permission / kernfs_refresh_inode - - 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 - - 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 + BUG: KCSAN: data-race in test_kernel_read / test_kernel_write + + 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 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 - - 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 + BUG: KCSAN: data-race in test_kernel_rmw_array+0x71/0xd0 + + 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: diff --git a/Documentation/dev-tools/kunit/index.rst b/Documentation/dev-tools/kunit/index.rst index 25d92a9a05ea..cacb35ec658d 100644 --- a/Documentation/dev-tools/kunit/index.rst +++ b/Documentation/dev-tools/kunit/index.rst @@ -14,6 +14,7 @@ KUnit - Unit Testing for the Linux Kernel style faq tips + running_tips What is KUnit? ============== diff --git a/Documentation/dev-tools/kunit/kunit-tool.rst b/Documentation/dev-tools/kunit/kunit-tool.rst index 29ae2fee8123..c7ff9afe407a 100644 --- a/Documentation/dev-tools/kunit/kunit-tool.rst +++ b/Documentation/dev-tools/kunit/kunit-tool.rst @@ -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. diff --git a/Documentation/dev-tools/kunit/running_tips.rst b/Documentation/dev-tools/kunit/running_tips.rst new file mode 100644 index 000000000000..7d99386cf94a --- /dev/null +++ b/Documentation/dev-tools/kunit/running_tips.rst @@ -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 diff --git a/Documentation/dev-tools/kunit/start.rst b/Documentation/dev-tools/kunit/start.rst index 63ef7b625c13..1e00f9226f74 100644 --- a/Documentation/dev-tools/kunit/start.rst +++ b/Documentation/dev-tools/kunit/start.rst @@ -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. diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 3ee7ab91f712..63f1bb89ebf5 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -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. - -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! +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. + +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: diff --git a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt b/Documentation/devicetree/bindings/arm/amlogic,scpi.txt deleted file mode 100644 index 5ab59da052df..000000000000 --- a/Documentation/devicetree/bindings/arm/amlogic,scpi.txt +++ /dev/null @@ -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 diff --git a/Documentation/devicetree/bindings/arm/arm,scmi.txt b/Documentation/devicetree/bindings/arm/arm,scmi.txt deleted file mode 100644 index 667d58e0a659..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scmi.txt +++ /dev/null @@ -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>; - ... - }; -}; diff --git a/Documentation/devicetree/bindings/arm/arm,scpi.txt b/Documentation/devicetree/bindings/arm/arm,scpi.txt deleted file mode 100644 index bcd6c3ec471e..000000000000 --- a/Documentation/devicetree/bindings/arm/arm,scpi.txt +++ /dev/null @@ -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. diff --git a/Documentation/devicetree/bindings/arm/arm,scu.yaml b/Documentation/devicetree/bindings/arm/arm,scu.yaml new file mode 100644 index 000000000000..dae2aa27e641 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/arm,scu.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt deleted file mode 100644 index d38834c67dff..000000000000 --- a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.txt +++ /dev/null @@ -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"; - }; - }; diff --git a/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml new file mode 100644 index 000000000000..c24047c1fdd5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/firmware/linaro,optee-tz.yaml @@ -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"; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index 395359dc94fd..fd0061712443 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -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" diff --git a/Documentation/devicetree/bindings/arm/intel,keembay.yaml b/Documentation/devicetree/bindings/arm/intel,keembay.yaml index 69cd30872928..107e686ab207 100644 --- a/Documentation/devicetree/bindings/arm/intel,keembay.yaml +++ b/Documentation/devicetree/bindings/arm/intel,keembay.yaml @@ -11,6 +11,8 @@ maintainers: - Daniele Alessandrelli <daniele.alessandrelli@intel.com> properties: + $nodename: + const: '/' compatible: items: - enum: diff --git a/Documentation/devicetree/bindings/arm/juno,scpi.txt b/Documentation/devicetree/bindings/arm/juno,scpi.txt deleted file mode 100644 index 2ace8696bbee..000000000000 --- a/Documentation/devicetree/bindings/arm/juno,scpi.txt +++ /dev/null @@ -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 diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt b/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt deleted file mode 100644 index 6f0cd31c1520..000000000000 --- a/Documentation/devicetree/bindings/arm/keystone/ti,sci.txt +++ /dev/null @@ -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 { - ... - ... - }; - }; diff --git a/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml new file mode 100644 index 000000000000..34f5f877d444 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/keystone/ti,sci.yaml @@ -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>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/scu.txt b/Documentation/devicetree/bindings/arm/scu.txt deleted file mode 100644 index 74d0a780ce51..000000000000 --- a/Documentation/devicetree/bindings/arm/scu.txt +++ /dev/null @@ -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>; -}; diff --git a/Documentation/devicetree/bindings/arm/ux500/boards.txt b/Documentation/devicetree/bindings/arm/ux500/boards.txt index 89408de55bfd..18d55532d31e 100644 --- a/Documentation/devicetree/bindings/arm/ux500/boards.txt +++ b/Documentation/devicetree/bindings/arm/ux500/boards.txt @@ -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 diff --git a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml index a75e9a8f539a..3c7a2425f3e6 100644 --- a/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml +++ b/Documentation/devicetree/bindings/ata/nvidia,tegra-ahci.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: AHCI registers - description: SATA configuration and IPFS registers diff --git a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml index d06096a7ba4b..c060c7914cae 100644 --- a/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml +++ b/Documentation/devicetree/bindings/ata/renesas,rcar-sata.yaml @@ -53,6 +53,17 @@ required: - reg - interrupts - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + const: renesas,sata-r8a7779 +then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml index a27025cd3909..c4b7243ddcf2 100644 --- a/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml +++ b/Documentation/devicetree/bindings/clock/allwinner,sun4i-a10-ccu.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt b/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt deleted file mode 100644 index 2be1e038ca62..000000000000 --- a/Documentation/devicetree/bindings/clock/gpio-mux-clock.txt +++ /dev/null @@ -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>; - }; diff --git a/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml new file mode 100644 index 000000000000..1e21f8b3a4ff --- /dev/null +++ b/Documentation/devicetree/bindings/clock/gpio-mux-clock.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml new file mode 100644 index 000000000000..3ceb29cec704 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/hisilicon,hi3559av100-clock.yaml @@ -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>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index 28675b0b80f1..26ed040bc717 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -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>; }; }; }; diff --git a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml index c65b9458c0b6..6e80dbc8b8b9 100644 --- a/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml +++ b/Documentation/devicetree/bindings/clock/ingenic,cgu.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml new file mode 100644 index 000000000000..9f239c3960d1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,camcc-sm8250.yaml @@ -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>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml index 0cdf53f41f84..6667261dc665 100644 --- a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm8x50.yaml @@ -20,6 +20,7 @@ description: | properties: compatible: enum: + - qcom,sc8180x-dispcc - qcom,sm8150-dispcc - qcom,sm8250-dispcc diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index eacccc88bbf6..8e2eac6cbfb9 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -46,7 +46,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - const: calib_backup diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml index 1121b3934cb9..b0d1c65aa354 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sdx55.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml new file mode 100644 index 000000000000..ab12b391effc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm6125.yaml @@ -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>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml index 78f35832aa41..1122700dcc2b 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-sm8350.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index 490edad25830..8453eeddf30e 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt index b44a0622fb3a..6cf5a7ec2b4c 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt +++ b/Documentation/devicetree/bindings/clock/qcom,rpmcc.txt @@ -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" diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt deleted file mode 100644 index 268ca615459e..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.txt +++ /dev/null @@ -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>; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml new file mode 100644 index 000000000000..4d9a64800481 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,emev2-smu.yaml @@ -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>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt deleted file mode 100644 index aed713cf0831..000000000000 --- a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.txt +++ /dev/null @@ -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>; - }; diff --git a/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml new file mode 100644 index 000000000000..25dbb0fac065 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,r9a06g032-sysctrl.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml new file mode 100644 index 000000000000..30b2e3d0d25d --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/silabs,si5341.txt b/Documentation/devicetree/bindings/clock/silabs,si5341.txt index 504cce3abe46..ce55aba0ce22 100644 --- a/Documentation/devicetree/bindings/clock/silabs,si5341.txt +++ b/Documentation/devicetree/bindings/clock/silabs,si5341.txt @@ -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) diff --git a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml index 4069e09cb62d..47e1ab08c95d 100644 --- a/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml +++ b/Documentation/devicetree/bindings/clock/sprd,sc9863a-clk.yaml @@ -40,7 +40,6 @@ properties: clock-names: minItems: 1 - maxItems: 4 items: - const: ext-26m - const: ext-32k diff --git a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml index 4e385508f516..8b1ecb2ecdd5 100644 --- a/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml +++ b/Documentation/devicetree/bindings/clock/st,stm32mp1-rcc.yaml @@ -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>; diff --git a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt index f207053e0550..d0fa1e02d06d 100644 --- a/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt +++ b/Documentation/devicetree/bindings/clock/st/st,clkgen-pll.txt @@ -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" diff --git a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt index 7ff77fc57dff..55a18939bddd 100644 --- a/Documentation/devicetree/bindings/clock/st/st,flexgen.txt +++ b/Documentation/devicetree/bindings/clock/st/st,flexgen.txt @@ -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). diff --git a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt index d93d49342e60..c4ba2adb0b4f 100644 --- a/Documentation/devicetree/bindings/clock/st/st,quadfs.txt +++ b/Documentation/devicetree/bindings/clock/st/st,quadfs.txt @@ -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" diff --git a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml index 6b419a9878f3..9b537bc876b5 100644 --- a/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml +++ b/Documentation/devicetree/bindings/clock/ti,am654-ehrpwm-tbclk.yaml @@ -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": diff --git a/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml new file mode 100644 index 000000000000..bd8173848253 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,lmk04832.yaml @@ -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; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt b/Documentation/devicetree/bindings/clock/ti,sci-clk.txt deleted file mode 100644 index 4e59dc6b1778..000000000000 --- a/Documentation/devicetree/bindings/clock/ti,sci-clk.txt +++ /dev/null @@ -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>; -}; diff --git a/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml new file mode 100644 index 000000000000..0e370289a053 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti,sci-clk.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/clock/ti/dpll.txt b/Documentation/devicetree/bindings/clock/ti/dpll.txt index df57009ff8e7..37a7cb6ad07d 100644 --- a/Documentation/devicetree/bindings/clock/ti/dpll.txt +++ b/Documentation/devicetree/bindings/clock/ti/dpll.txt @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml index 6ab07eba7778..00648f9d9278 100644 --- a/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml +++ b/Documentation/devicetree/bindings/crypto/allwinner,sun8i-ce.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml new file mode 100644 index 000000000000..9c97874a6dbd --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/arm,cryptocell.yaml @@ -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>; + }; diff --git a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt b/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt deleted file mode 100644 index 6130e6eb4af8..000000000000 --- a/Documentation/devicetree/bindings/crypto/arm-cryptocell.txt +++ /dev/null @@ -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 >; - - }; diff --git a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml index a30bf38a4a49..99be01539fcd 100644 --- a/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml +++ b/Documentation/devicetree/bindings/crypto/fsl-dcp.yaml @@ -27,7 +27,6 @@ properties: - description: MXS DCP DCP interrupt - description: MXS DCP secure interrupt minItems: 2 - maxItems: 3 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml index 12a7df0e38b2..3d8ea3c2d8dd 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-backend.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml index a738d7c12a97..bf0bdf54e5f9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun6i-a31-mipi-dsi.yaml @@ -24,7 +24,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml index 907fb47cc84a..5d42d36608d9 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-dw-hdmi.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml index 501cec16168c..a97366aaf924 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-a83t-hdmi-phy.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml index ec21e8bf2767..61ef7b337218 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun8i-r40-tcon-top.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml index d900cc57b4ec..9b24081a0dbd 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2835-vec.yaml @@ -11,7 +11,9 @@ maintainers: properties: compatible: - const: brcm,bcm2835-vec + enum: + - brcm,bcm2711-vec + - brcm,bcm2835-vec reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt deleted file mode 100644 index 659523f538bf..000000000000 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.txt +++ /dev/null @@ -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>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml new file mode 100644 index 000000000000..d3dd7a79b909 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -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>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml new file mode 100644 index 000000000000..f36209137c8a --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7533.yaml @@ -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>; + }; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml index 63427878715e..b2e8bc6da9d0 100644 --- a/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml +++ b/Documentation/devicetree/bindings/display/bridge/cdns,mhdp8546.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml new file mode 100644 index 000000000000..9f7cc6b757cb --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/google,cros-ec-anx7688.yaml @@ -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>; + }; + }; + }; + }; + }; + diff --git a/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml new file mode 100644 index 000000000000..6ec1d5fbb8bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ite,it66121.yaml @@ -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>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml index 735d0233a7d6..674891ee2f8e 100644 --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt8912b.yaml @@ -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 diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml new file mode 100644 index 000000000000..d101233ae17f --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -0,0 +1,159 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ti,sn65dsi83.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SN65DSI83 and SN65DSI84 DSI to LVDS bridge chip + +maintainers: + - Marek Vasut <marex@denx.de> + +description: | + Texas Instruments SN65DSI83 1x Single-link MIPI DSI + to 1x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi83 + Texas Instruments SN65DSI84 1x Single-link MIPI DSI + to 1x Dual-link or 2x Single-link LVDS + https://www.ti.com/lit/gpn/sn65dsi84 + +properties: + compatible: + enum: + - ti,sn65dsi83 + - ti,sn65dsi84 + + reg: + enum: + - 0x2c + - 0x2d + + enable-gpios: + maxItems: 1 + description: GPIO specifier for bridge_en pin (active high). + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-A input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for MIPI DSI Channel-B input + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + description: array of physical DSI data lane indexes. + minItems: 1 + maxItems: 4 + items: + - const: 1 + - const: 2 + - const: 3 + - const: 4 + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-A output (panel or bridge). + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Video port for LVDS Channel-B output (panel or bridge). + + required: + - port@0 + - port@2 + +required: + - compatible + - reg + - enable-gpios + - ports + +allOf: + - if: + properties: + compatible: + contains: + const: ti,sn65dsi83 + then: + properties: + ports: + properties: + port@1: false + port@3: false + + - if: + properties: + compatible: + contains: + const: ti,sn65dsi84 + then: + properties: + ports: + properties: + port@1: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + bridge@2d { + compatible = "ti,sn65dsi83"; + reg = <0x2d>; + + enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + endpoint { + remote-endpoint = <&dsi0_out>; + data-lanes = <1 2 3 4>; + }; + }; + + port@2 { + reg = <2>; + + endpoint { + remote-endpoint = <&panel_in_lvds>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.txt b/Documentation/devicetree/bindings/display/faraday,tve200.txt deleted file mode 100644 index 82e3bc0b7485..000000000000 --- a/Documentation/devicetree/bindings/display/faraday,tve200.txt +++ /dev/null @@ -1,54 +0,0 @@ -* Faraday TV Encoder TVE200 - -Required properties: - -- compatible: must be one of: - "faraday,tve200" - "cortina,gemini-tvc", "faraday,tve200" - -- reg: base address and size of the control registers block - -- interrupts: contains an interrupt specifier for the interrupt - line from the TVE200 - -- clock-names: should contain "PCLK" for the clock line clocking the - silicon and "TVE" for the 27MHz clock to the video driver - -- clocks: contains phandle and clock specifier pairs for the entries - in the clock-names property. See - Documentation/devicetree/bindings/clock/clock-bindings.txt - -Optional properties: - -- resets: contains the reset line phandle for the block - -Required sub-nodes: - -- port: describes LCD panel signals, following the common binding - for video transmitter interfaces; see - Documentation/devicetree/bindings/media/video-interfaces.txt - This port should have the properties: - reg = <0>; - It should have one endpoint connected to a remote endpoint where - the display is connected. - -Example: - -display-controller@6a000000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "faraday,tve200"; - reg = <0x6a000000 0x1000>; - interrupts = <13 IRQ_TYPE_EDGE_RISING>; - resets = <&syscon GEMINI_RESET_TVC>; - clocks = <&syscon GEMINI_CLK_GATE_TVC>, - <&syscon GEMINI_CLK_TVC>; - clock-names = "PCLK", "TVE"; - - port@0 { - reg = <0>; - display_out: endpoint { - remote-endpoint = <&panel_in>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/faraday,tve200.yaml b/Documentation/devicetree/bindings/display/faraday,tve200.yaml new file mode 100644 index 000000000000..e2ee77767321 --- /dev/null +++ b/Documentation/devicetree/bindings/display/faraday,tve200.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/faraday,tve200.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday TV Encoder TVE200 + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + oneOf: + - const: faraday,tve200 + - items: + - const: cortina,gemini-tvc + - const: faraday,tve200 + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + + clock-names: + items: + - const: PCLK + - const: TVE + + clocks: + minItems: 2 + + resets: + minItems: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - reg + - interrupts + - clock-names + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cortina,gemini-clock.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + display-controller@6a000000 { + compatible = "faraday,tve200"; + reg = <0x6a000000 0x1000>; + interrupts = <13 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_TVC>; + clocks = <&syscon GEMINI_CLK_GATE_TVC>, + <&syscon GEMINI_CLK_TVC>; + clock-names = "PCLK", "TVE"; + + port { + display_out: endpoint { + remote-endpoint = <&panel_in>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml new file mode 100644 index 000000000000..66288b9f0aa6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,cec.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,cec.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI CEC Controller Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The HDMI CEC controller handles hotplug detection and CEC communication. + +properties: + compatible: + enum: + - mediatek,mt7623-cec + - mediatek,mt8167-cec + - mediatek,mt8173-cec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + cec: cec@10013000 { + compatible = "mediatek,mt8173-cec"; + reg = <0x10013000 0xbc>; + interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg CLK_INFRA_CEC>; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml new file mode 100644 index 000000000000..b6fcdfb99ab2 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi-ddc.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi-ddc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI DDC Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. + +properties: + compatible: + enum: + - mediatek,mt7623-hdmi-ddc + - mediatek,mt8167-hdmi-ddc + - mediatek,mt8173-hdmi-ddc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ddc-i2c + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + hdmi_ddc0: i2c@11012000 { + compatible = "mediatek,mt8173-hdmi-ddc"; + reg = <0x11012000 0x1c>; + interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>; + clocks = <&pericfg CLK_PERI_I2C5>; + clock-names = "ddc-i2c"; + }; + +... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt deleted file mode 100644 index b284ca51b913..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.txt +++ /dev/null @@ -1,136 +0,0 @@ -Mediatek HDMI Encoder -===================== - -The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from -its parallel input. - -Required properties: -- compatible: Should be "mediatek,<chip>-hdmi". -- the supported chips are mt2701, mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "pixel", "pll", "bclk", and "spdif". -- phys: phandle link to the HDMI PHY node. - See Documentation/devicetree/bindings/phy/phy-bindings.txt for details. -- phy-names: must contain "hdmi" -- mediatek,syscon-hdmi: phandle link and register offset to the system - configuration registers. For mt8173 this must be offset 0x900 into the - MMSYS_CONFIG region: <&mmsys 0x900>. -- ports: A node containing input and output port nodes with endpoint - definitions as documented in Documentation/devicetree/bindings/graph.txt. -- port@0: The input port in the ports node should be connected to a DPI output - port. -- port@1: The output port in the ports node should be connected to the input - port of a connector node that contains a ddc-i2c-bus property, or to the - input port of an attached bridge chip, such as a SlimPort transmitter. - -HDMI CEC -======== - -The HDMI CEC controller handles hotplug detection and CEC communication. - -Required properties: -- compatible: Should be "mediatek,<chip>-cec" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- interrupts: The interrupt signal from the function block. -- clocks: device clock - -HDMI DDC -======== - -The HDMI DDC i2c controller is used to interface with the HDMI DDC pins. -The Mediatek's I2C controller is used to interface with I2C devices. - -Required properties: -- compatible: Should be "mediatek,<chip>-hdmi-ddc" -- the supported chips are mt7623 and mt8173 -- reg: Physical base address and length of the controller's registers -- clocks: device clock -- clock-names: Should be "ddc-i2c". - -HDMI PHY -======== -See phy/mediatek,hdmi-phy.yaml - -Example: - -cec: cec@10013000 { - compatible = "mediatek,mt8173-cec"; - reg = <0 0x10013000 0 0xbc>; - interrupts = <GIC_SPI 167 IRQ_TYPE_LEVEL_LOW>; - clocks = <&infracfg CLK_INFRA_CEC>; -}; - -hdmi_phy: hdmi-phy@10209100 { - compatible = "mediatek,mt8173-hdmi-phy"; - reg = <0 0x10209100 0 0x24>; - clocks = <&apmixedsys CLK_APMIXED_HDMI_REF>; - clock-names = "pll_ref"; - clock-output-names = "hdmitx_dig_cts"; - mediatek,ibias = <0xa>; - mediatek,ibias_up = <0x1c>; - #clock-cells = <0>; - #phy-cells = <0>; -}; - -hdmi_ddc0: i2c@11012000 { - compatible = "mediatek,mt8173-hdmi-ddc"; - reg = <0 0x11012000 0 0x1c>; - interrupts = <GIC_SPI 81 IRQ_TYPE_LEVEL_LOW>; - clocks = <&pericfg CLK_PERI_I2C5>; - clock-names = "ddc-i2c"; -}; - -hdmi0: hdmi@14025000 { - compatible = "mediatek,mt8173-hdmi"; - reg = <0 0x14025000 0 0x400>; - interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>; - clocks = <&mmsys CLK_MM_HDMI_PIXEL>, - <&mmsys CLK_MM_HDMI_PLLCK>, - <&mmsys CLK_MM_HDMI_AUDIO>, - <&mmsys CLK_MM_HDMI_SPDIF>; - clock-names = "pixel", "pll", "bclk", "spdif"; - pinctrl-names = "default"; - pinctrl-0 = <&hdmi_pin>; - phys = <&hdmi_phy>; - phy-names = "hdmi"; - mediatek,syscon-hdmi = <&mmsys 0x900>; - assigned-clocks = <&topckgen CLK_TOP_HDMI_SEL>; - assigned-clock-parents = <&hdmi_phy>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - - hdmi0_in: endpoint { - remote-endpoint = <&dpi0_out>; - }; - }; - - port@1 { - reg = <1>; - - hdmi0_out: endpoint { - remote-endpoint = <&hdmi_con_in>; - }; - }; - }; -}; - -connector { - compatible = "hdmi-connector"; - type = "a"; - ddc-i2c-bus = <&hdmiddc0>; - - port { - hdmi_con_in: endpoint { - remote-endpoint = <&hdmi0_out>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml new file mode 100644 index 000000000000..111967efa999 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -0,0 +1,133 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek HDMI Encoder Device Tree Bindings + +maintainers: + - CK Hu <ck.hu@mediatek.com> + - Jitao shi <jitao.shi@mediatek.com> + +description: | + The Mediatek HDMI encoder can generate HDMI 1.4a or MHL 2.0 signals from + its parallel input. + +properties: + compatible: + enum: + - mediatek,mt2701-hdmi + - mediatek,mt7623-hdmi + - mediatek,mt8167-hdmi + - mediatek,mt8173-hdmi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Pixel Clock + - description: HDMI PLL + - description: Bit Clock + - description: S/PDIF Clock + + clock-names: + items: + - const: pixel + - const: pll + - const: bclk + - const: spdif + + phys: + maxItems: 1 + + phy-names: + items: + - const: hdmi + + mediatek,syscon-hdmi: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + maxItems: 1 + description: | + phandle link and register offset to the system configuration registers. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: | + Input port node. This port should be connected to a DPI output port. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: | + Output port node. This port should be connected to the input port of a connector + node that contains a ddc-i2c-bus property, or to the input port of an attached + bridge chip, such as a SlimPort transmitter. + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - mediatek,syscon-hdmi + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + hdmi0: hdmi@14025000 { + compatible = "mediatek,mt8173-hdmi"; + reg = <0x14025000 0x400>; + interrupts = <GIC_SPI 206 IRQ_TYPE_LEVEL_LOW>; + clocks = <&mmsys CLK_MM_HDMI_PIXEL>, + <&mmsys CLK_MM_HDMI_PLLCK>, + <&mmsys CLK_MM_HDMI_AUDIO>, + <&mmsys CLK_MM_HDMI_SPDIF>; + clock-names = "pixel", "pll", "bclk", "spdif"; + pinctrl-names = "default"; + pinctrl-0 = <&hdmi_pin>; + phys = <&hdmi_phy>; + phy-names = "hdmi"; + mediatek,syscon-hdmi = <&mmsys 0x900>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + + hdmi0_in: endpoint { + remote-endpoint = <&dpi0_out>; + }; + }; + + port@1 { + reg = <1>; + + hdmi0_out: endpoint { + remote-endpoint = <&hdmi_con_in>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml new file mode 100644 index 000000000000..64d8d9e5e47a --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dp-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MSM Display Port Controller + +maintainers: + - Kuogee Hsieh <khsieh@codeaurora.org> + +description: | + Device tree bindings for DisplayPort host controller for MSM targets + that are compatible with VESA DisplayPort interface specification. + +properties: + compatible: + enum: + - qcom,sc7180-dp + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: AHB clock to enable register access + - description: Display Port AUX clock + - description: Display Port Link clock + - description: Link interface clock between DP and PHY + - description: Display Port Pixel clock + + clock-names: + items: + - const: core_iface + - const: core_aux + - const: ctrl_link + - const: ctrl_link_iface + - const: stream_pixel + + assigned-clocks: + items: + - description: link clock source + - description: pixel clock source + + assigned-clock-parents: + items: + - description: phy 0 parent + - description: phy 1 parent + + phys: + maxItems: 1 + + phy-names: + items: + - const: dp + + operating-points-v2: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input endpoint of the controller + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Output endpoint of the controller + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - phys + - phy-names + - "#sound-dai-cells" + - power-domains + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,dispcc-sc7180.h> + #include <dt-bindings/power/qcom-aoss-qmp.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + displayport-controller@ae90000 { + compatible = "qcom,sc7180-dp"; + reg = <0xae90000 0x1400>; + interrupt-parent = <&mdss>; + interrupts = <12>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_DP_AUX_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_CLK>, + <&dispcc DISP_CC_MDSS_DP_LINK_INTF_CLK>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK>; + clock-names = "core_iface", "core_aux", + "ctrl_link", + "ctrl_link_iface", "stream_pixel"; + + assigned-clocks = <&dispcc DISP_CC_MDSS_DP_LINK_CLK_SRC>, + <&dispcc DISP_CC_MDSS_DP_PIXEL_CLK_SRC>; + + assigned-clock-parents = <&dp_phy 0>, <&dp_phy 1>; + + phys = <&dp_phy>; + phy-names = "dp"; + + #sound-dai-cells = <0>; + + power-domains = <&rpmhpd SC7180_CX>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&dpu_intf0_out>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&typec>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml new file mode 100644 index 000000000000..12a86b1ec1bc --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sc7180.yaml @@ -0,0 +1,228 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sc7180.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SC7180 target + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SC7180 target. + +properties: + compatible: + items: + - const: qcom,sc7180-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock + + clock-names: + items: + - const: iface + - const: ahb + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + + ranges: true + + interconnects: + items: + - description: Interconnect path specifying the port ids for data bus + + interconnect-names: + const: mdp0-mem + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sc7180-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display hf axi clock + - description: Display ahb clock + - description: Display rotator clock + - description: Display lut clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: bus + - const: iface + - const: rot + - const: lut + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF0 (DP) + + required: + - port@0 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sc7180.h> + #include <dt-bindings/clock/qcom,gcc-sc7180.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sc7180-mdss"; + reg = <0xae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "ahb", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmss_noc MASTER_MDP0 &mc_virt SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x800 0x2>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sc7180-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_ROT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "rot", "lut", "core", + "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@2 { + reg = <2>; + dpu_intf0_out: endpoint { + remote-endpoint = <&dp_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml new file mode 100644 index 000000000000..b4ea7c92fb3d --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-sdm845.yaml @@ -0,0 +1,212 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-sdm845.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for SDM845 target + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller, DSI and DP interfaces etc. Device tree + bindings of MDSS and DPU are mentioned for SDM845 target. + +properties: + compatible: + items: + - const: qcom,sdm845-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock from gcc + - description: Display AXI clock + - description: Display core clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#address-cells": true + + "#size-cells": true + + "#interrupt-cells": + const: 1 + + iommus: + items: + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port0 + - description: Phandle to apps_smmu node with SID mask for Hard-Fail port1 + + ranges: true + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,sdm845-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for vbif register set + + reg-names: + items: + - const: mdp + - const: vbif + + clocks: + items: + - description: Display ahb clock + - description: Display axi clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: core + - const: vsync + + interrupts: + maxItems: 1 + + power-domains: + maxItems: 1 + + operating-points-v2: true + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: | + Contains the list of output ports from DPU device. These ports + connect to interfaces that are external to the DPU hardware, + such as DSI, DP etc. Each output port contains an endpoint that + describes how it is connected to an external interface. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF1 (DSI1) + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DPU_INTF2 (DSI2) + + required: + - port@0 + - port@1 + + required: + - compatible + - reg + - reg-names + - clocks + - interrupts + - power-domains + - operating-points-v2 + - ports + +required: + - compatible + - reg + - reg-names + - power-domains + - clocks + - interrupts + - interrupt-controller + - iommus + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + display-subsystem@ae00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,sdm845-mdss"; + reg = <0x0ae00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + iommus = <&apps_smmu 0x880 0x8>, + <&apps_smmu 0xc80 0x8>; + ranges; + + display-controller@ae01000 { + compatible = "qcom,sdm845-dpu"; + reg = <0x0ae01000 0x8f000>, + <0x0aeb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "iface", "bus", "core", "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + power-domains = <&rpmhpd SDM845_CX>; + operating-points-v2 = <&mdp_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + + port@1 { + reg = <1>; + dpu_intf2_out: endpoint { + remote-endpoint = <&dsi1_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dpu.txt b/Documentation/devicetree/bindings/display/msm/dpu.txt deleted file mode 100644 index 586e6eac5b08..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dpu.txt +++ /dev/null @@ -1,141 +0,0 @@ -Qualcomm Technologies, Inc. DPU KMS - -Description: - -Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates -sub-blocks like DPU display controller, DSI and DP interfaces etc. -The DPU display controller is found in SDM845 SoC. - -MDSS: -Required properties: -- compatible: "qcom,sdm845-mdss", "qcom,sc7180-mdss" -- reg: physical base address and length of controller's registers. -- reg-names: register region names. The following region is required: - * "mdss" -- power-domains: a power domain consumer specifier according to - Documentation/devicetree/bindings/power/power_domain.txt -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required: - * "iface" - * "bus" - * "core" -- interrupts: interrupt signal from MDSS. -- interrupt-controller: identifies the node as an interrupt controller. -- #interrupt-cells: specifies the number of cells needed to encode an interrupt - source, should be 1. -- iommus: phandle of iommu device node. -- #address-cells: number of address cells for the MDSS children. Should be 1. -- #size-cells: Should be 1. -- ranges: parent bus address space is the same as the child bus address space. -- interconnects : interconnect path specifier for MDSS according to - Documentation/devicetree/bindings/interconnect/interconnect.txt. Should be - 2 paths corresponding to 2 AXI ports. -- interconnect-names : MDSS will have 2 port names to differentiate between the - 2 interconnect paths defined with interconnect specifier. - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -MDP: -Required properties: -- compatible: "qcom,sdm845-dpu", "qcom,sc7180-dpu" -- reg: physical base address and length of controller's registers. -- reg-names : register region names. The following region is required: - * "mdp" - * "vbif" -- clocks: list of clock specifiers for clocks needed by the device. -- clock-names: device clock names, must be in same order as clocks property. - The following clocks are required. - * "bus" - * "iface" - * "core" - * "vsync" -- interrupts: interrupt line from DPU to MDSS. -- ports: contains the list of output ports from DPU device. These ports connect - to interfaces that are external to the DPU hardware, such as DSI, DP etc. - - Each output port contains an endpoint that describes how it is connected to an - external interface. These are described by the standard properties documented - here: - Documentation/devicetree/bindings/graph.txt - Documentation/devicetree/bindings/media/video-interfaces.txt - - Port 0 -> DPU_INTF1 (DSI1) - Port 1 -> DPU_INTF2 (DSI2) - -Optional properties: -- assigned-clocks: list of clock specifiers for clocks needing rate assignment -- assigned-clock-rates: list of clock frequencies sorted in the same order as - the assigned-clocks property. - -Example: - - mdss: mdss@ae00000 { - compatible = "qcom,sdm845-mdss"; - reg = <0xae00000 0x1000>; - reg-names = "mdss"; - - power-domains = <&clock_dispcc 0>; - - clocks = <&gcc GCC_DISP_AHB_CLK>, <&gcc GCC_DISP_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - clock-names = "iface", "bus", "core"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>; - assigned-clock-rates = <300000000>; - - interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; - interrupt-controller; - #interrupt-cells = <1>; - - interconnects = <&rsc_hlos MASTER_MDP0 &rsc_hlos SLAVE_EBI1>, - <&rsc_hlos MASTER_MDP1 &rsc_hlos SLAVE_EBI1>; - - interconnect-names = "mdp0-mem", "mdp1-mem"; - - iommus = <&apps_iommu 0>; - - #address-cells = <2>; - #size-cells = <1>; - ranges = <0 0 0xae00000 0xb2008>; - - mdss_mdp: mdp@ae01000 { - compatible = "qcom,sdm845-dpu"; - reg = <0 0x1000 0x8f000>, <0 0xb0000 0x2008>; - reg-names = "mdp", "vbif"; - - clocks = <&clock_dispcc DISP_CC_MDSS_AHB_CLK>, - <&clock_dispcc DISP_CC_MDSS_AXI_CLK>, - <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - clock-names = "iface", "bus", "core", "vsync"; - - assigned-clocks = <&clock_dispcc DISP_CC_MDSS_MDP_CLK>, - <&clock_dispcc DISP_CC_MDSS_VSYNC_CLK>; - assigned-clock-rates = <0 0 300000000 19200000>; - - interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dpu_intf1_out: endpoint { - remote-endpoint = <&dsi0_in>; - }; - }; - - port@1 { - reg = <1>; - dpu_intf2_out: endpoint { - remote-endpoint = <&dsi1_in>; - }; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml new file mode 100644 index 000000000000..76348b71f736 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-controller-main.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI controller + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: "../dsi-controller.yaml#" + +properties: + compatible: + items: + - const: qcom,mdss-dsi-ctrl + + reg: + maxItems: 1 + + reg-names: + const: dsi_ctrl + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Display byte clock + - description: Display byte interface clock + - description: Display pixel clock + - description: Display escape clock + - description: Display AHB clock + - description: Display AXI clock + + clock-names: + items: + - const: byte + - const: byte_intf + - const: pixel + - const: core + - const: iface + - const: bus + + phys: + maxItems: 1 + + phy-names: + const: dsi + + "#address-cells": true + + "#size-cells": true + + syscon-sfpb: + description: A phandle to mmss_sfpb syscon node (only for DSIv2). + $ref: "/schemas/types.yaml#/definitions/phandle" + + qcom,dual-dsi-mode: + type: boolean + description: | + Indicates if the DSI controller is driving a panel which needs + 2 DSI links. + + power-domains: + maxItems: 1 + + operating-points-v2: true + + ports: + $ref: "/schemas/graph.yaml#/properties/ports" + description: | + Contains DSI controller input and output ports as children, each + containing one endpoint subnode. + + properties: + port@0: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Input endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + port@1: + $ref: "/schemas/graph.yaml#/properties/port" + description: | + Output endpoints of the controller. + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + properties: + data-lanes: + maxItems: 4 + minItems: 4 + items: + enum: [ 0, 1, 2, 3 ] + + required: + - port@0 + - port@1 + +required: + - compatible + - reg + - reg-names + - interrupts + - clocks + - clock-names + - phys + - phy-names + - power-domains + - operating-points-v2 + - ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + dsi@ae94000 { + compatible = "qcom,mdss-dsi-ctrl"; + reg = <0x0ae94000 0x400>; + reg-names = "dsi_ctrl"; + + #address-cells = <1>; + #size-cells = <0>; + + interrupt-parent = <&mdss>; + interrupts = <4>; + + clocks = <&dispcc DISP_CC_MDSS_BYTE0_CLK>, + <&dispcc DISP_CC_MDSS_BYTE0_INTF_CLK>, + <&dispcc DISP_CC_MDSS_PCLK0_CLK>, + <&dispcc DISP_CC_MDSS_ESC0_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_AXI_CLK>; + clock-names = "byte", + "byte_intf", + "pixel", + "core", + "iface", + "bus"; + + phys = <&dsi0_phy>; + phy-names = "dsi"; + + power-domains = <&rpmhpd SC7180_CX>; + operating-points-v2 = <&dsi_opp_table>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dsi0_in: endpoint { + remote-endpoint = <&dpu_intf1_out>; + }; + }; + + port@1 { + reg = <1>; + dsi0_out: endpoint { + remote-endpoint = <&sn65dsi86_in>; + data-lanes = <0 1 2 3>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml new file mode 100644 index 000000000000..4a26bef19360 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-10nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 10nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-10nm + - const: qcom,dsi-phy-10nm-8998 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vdds-supply: + description: | + Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and + connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + +required: + - compatible + - reg + - reg-names + - vdds-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-10nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vdds-supply = <&vdda_mipi_dsi0_pll>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml new file mode 100644 index 000000000000..72a00cce0147 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-14nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 14nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-14nm + - const: qcom,dsi-phy-14nm-660 + + reg: + items: + - description: dsi phy register set + - description: dsi phy lane register set + - description: dsi pll register set + + reg-names: + items: + - const: dsi_phy + - const: dsi_phy_lane + - const: dsi_pll + + vcca-supply: + description: Phandle to vcca regulator device node. + +required: + - compatible + - reg + - reg-names + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@ae94400 { + compatible = "qcom,dsi-phy-14nm"; + reg = <0x0ae94400 0x200>, + <0x0ae94600 0x280>, + <0x0ae94a00 0x1e0>; + reg-names = "dsi_phy", + "dsi_phy_lane", + "dsi_pll"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml new file mode 100644 index 000000000000..743806d61afe --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-20nm.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-20nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 20nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-20nm + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vcca-supply: + description: Phandle to vcca regulator device node. + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + - vcca-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-20nm"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vcca-supply = <&vcca_reg>; + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml new file mode 100644 index 000000000000..b106007116b4 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-28nm.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-28nm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DSI 28nm PHY + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +allOf: + - $ref: dsi-phy-common.yaml# + +properties: + compatible: + oneOf: + - const: qcom,dsi-phy-28nm-hpm + - const: qcom,dsi-phy-28nm-lp + - const: qcom,dsi-phy-28nm-8960 + + reg: + items: + - description: dsi pll register set + - description: dsi phy register set + - description: dsi phy regulator register set + + reg-names: + items: + - const: dsi_pll + - const: dsi_phy + - const: dsi_phy_regulator + + vddio-supply: + description: Phandle to vdd-io regulator device node. + +required: + - compatible + - reg + - reg-names + - vddio-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,dispcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + dsi-phy@fd922a00 { + compatible = "qcom,dsi-phy-28nm-lp"; + reg = <0xfd922a00 0xd4>, + <0xfd922b00 0x2b0>, + <0xfd922d80 0x7b>; + reg-names = "dsi_pll", + "dsi_phy", + "dsi_phy_regulator"; + + #clock-cells = <1>; + #phy-cells = <0>; + + vddio-supply = <&vddio_reg>; + + clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "iface", "ref"; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml new file mode 100644 index 000000000000..502bdda90235 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-common.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dsi-phy-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Description of Qualcomm Display DSI PHY common dt properties + +maintainers: + - Krishna Manikandan <mkrishn@codeaurora.org> + +description: | + This defines the DSI PHY dt properties which are common for all + dsi phy versions. + +properties: + "#clock-cells": + const: 1 + + "#phy-cells": + const: 0 + + clocks: + items: + - description: Display AHB clock + - description: Board XO source + + clock-names: + items: + - const: iface + - const: ref + +required: + - clocks + - clock-names + - "#clock-cells" + - "#phy-cells" + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi.txt b/Documentation/devicetree/bindings/display/msm/dsi.txt deleted file mode 100644 index b9a64d3ff184..000000000000 --- a/Documentation/devicetree/bindings/display/msm/dsi.txt +++ /dev/null @@ -1,249 +0,0 @@ -Qualcomm Technologies Inc. adreno/snapdragon DSI output - -DSI Controller: -Required properties: -- compatible: - * "qcom,mdss-dsi-ctrl" -- reg: Physical base address and length of the registers of controller -- reg-names: The names of register regions. The following regions are required: - * "dsi_ctrl" -- interrupts: The interrupt signal from the DSI block. -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: Phandles to device clocks. -- clock-names: the following clocks are required: - * "mdp_core" - * "iface" - * "bus" - * "core_mmss" - * "byte" - * "pixel" - * "core" - For DSIv2, we need an additional clock: - * "src" - For DSI6G v2.0 onwards, we need also need the clock: - * "byte_intf" -- assigned-clocks: Parents of "byte" and "pixel" for the given platform. -- assigned-clock-parents: The Byte clock and Pixel clock PLL outputs provided - by a DSI PHY block. See [1] for details on clock bindings. -- vdd-supply: phandle to vdd regulator device node -- vddio-supply: phandle to vdd-io regulator device node -- vdda-supply: phandle to vdda regulator device node -- phys: phandle to DSI PHY device node -- phy-names: the name of the corresponding PHY device -- syscon-sfpb: A phandle to mmss_sfpb syscon node (only for DSIv2) -- ports: Contains 2 DSI controller ports as child nodes. Each port contains - an endpoint subnode as defined in [2] and [3]. - -Optional properties: -- panel@0: Node of panel connected to this DSI controller. - See files in [4] for each supported panel. -- qcom,dual-dsi-mode: Boolean value indicating if the DSI controller is - driving a panel which needs 2 DSI links. -- qcom,master-dsi: Boolean value indicating if the DSI controller is driving - the master link of the 2-DSI panel. -- qcom,sync-dual-dsi: Boolean value indicating if the DSI controller is - driving a 2-DSI panel whose 2 links need receive command simultaneously. -- pinctrl-names: the pin control state names; should contain "default" -- pinctrl-0: the default pinctrl state (active) -- pinctrl-n: the "sleep" pinctrl state -- ports: contains DSI controller input and output ports as children, each - containing one endpoint subnode. - - DSI Endpoint properties: - - remote-endpoint: For port@0, set to phandle of the connected panel/bridge's - input endpoint. For port@1, set to the MDP interface output. See [2] for - device graph info. - - - data-lanes: this describes how the physical DSI data lanes are mapped - to the logical lanes on the given platform. The value contained in - index n describes what physical lane is mapped to the logical lane n - (DATAn, where n lies between 0 and 3). The clock lane position is fixed - and can't be changed. Hence, they aren't a part of the DT bindings. See - [3] for more info on the data-lanes property. - - For example: - - data-lanes = <3 0 1 2>; - - The above mapping describes that the logical data lane DATA0 is mapped to - the physical data lane DATA3, logical DATA1 to physical DATA0, logic DATA2 - to phys DATA1 and logic DATA3 to phys DATA2. - - There are only a limited number of physical to logical mappings possible: - <0 1 2 3> - <1 2 3 0> - <2 3 0 1> - <3 0 1 2> - <0 3 2 1> - <1 0 3 2> - <2 1 0 3> - <3 2 1 0> - -DSI PHY: -Required properties: -- compatible: Could be the following - * "qcom,dsi-phy-28nm-hpm" - * "qcom,dsi-phy-28nm-lp" - * "qcom,dsi-phy-20nm" - * "qcom,dsi-phy-28nm-8960" - * "qcom,dsi-phy-14nm" - * "qcom,dsi-phy-14nm-660" - * "qcom,dsi-phy-10nm" - * "qcom,dsi-phy-10nm-8998" - * "qcom,dsi-phy-7nm" - * "qcom,dsi-phy-7nm-8150" -- reg: Physical base address and length of the registers of PLL, PHY. Some - revisions require the PHY regulator base address, whereas others require the - PHY lane base address. See below for each PHY revision. -- reg-names: The names of register regions. The following regions are required: - For DSI 28nm HPM/LP/8960 PHYs and 20nm PHY: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_regulator" - For DSI 14nm, 10nm and 7nm PHYs: - * "dsi_pll" - * "dsi_phy" - * "dsi_phy_lane" -- clock-cells: Must be 1. The DSI PHY block acts as a clock provider, creating - 2 clocks: A byte clock (index 0), and a pixel clock (index 1). -- power-domains: Should be <&mmcc MDSS_GDSC>. -- clocks: Phandles to device clocks. See [1] for details on clock bindings. -- clock-names: the following clocks are required: - * "iface" - * "ref" (only required for new DTS files/entries) - For 28nm HPM/LP, 28nm 8960 PHYs: -- vddio-supply: phandle to vdd-io regulator device node - For 20nm PHY: -- vddio-supply: phandle to vdd-io regulator device node -- vcca-supply: phandle to vcca regulator device node - For 14nm PHY: -- vcca-supply: phandle to vcca regulator device node - For 10nm and 7nm PHY: -- vdds-supply: phandle to vdds regulator device node - -Optional properties: -- qcom,dsi-phy-regulator-ldo-mode: Boolean value indicating if the LDO mode PHY - regulator is wanted. -- qcom,mdss-mdp-transfer-time-us: Specifies the dsi transfer time for command mode - panels in microseconds. Driver uses this number to adjust - the clock rate according to the expected transfer time. - Increasing this value would slow down the mdp processing - and can result in slower performance. - Decreasing this value can speed up the mdp processing, - but this can also impact power consumption. - As a rule this time should not be higher than the time - that would be expected with the processing at the - dsi link rate since anyways this would be the maximum - transfer time that could be achieved. - If ping pong split is enabled, this time should not be higher - than two times the dsi link rate time. - If the property is not specified, then the default value is 14000 us. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt -[2] Documentation/devicetree/bindings/graph.txt -[3] Documentation/devicetree/bindings/media/video-interfaces.txt -[4] Documentation/devicetree/bindings/display/panel/ - -Example: - dsi0: dsi@fd922800 { - compatible = "qcom,mdss-dsi-ctrl"; - qcom,dsi-host-index = <0>; - interrupt-parent = <&mdp>; - interrupts = <4 0>; - reg-names = "dsi_ctrl"; - reg = <0xfd922800 0x200>; - power-domains = <&mmcc MDSS_GDSC>; - clock-names = - "bus", - "byte", - "core", - "core_mmss", - "iface", - "mdp_core", - "pixel"; - clocks = - <&mmcc MDSS_AXI_CLK>, - <&mmcc MDSS_BYTE0_CLK>, - <&mmcc MDSS_ESC0_CLK>, - <&mmcc MMSS_MISC_AHB_CLK>, - <&mmcc MDSS_AHB_CLK>, - <&mmcc MDSS_MDP_CLK>, - <&mmcc MDSS_PCLK0_CLK>; - - assigned-clocks = - <&mmcc BYTE0_CLK_SRC>, - <&mmcc PCLK0_CLK_SRC>; - assigned-clock-parents = - <&dsi_phy0 0>, - <&dsi_phy0 1>; - - vdda-supply = <&pma8084_l2>; - vdd-supply = <&pma8084_l22>; - vddio-supply = <&pma8084_l12>; - - phys = <&dsi_phy0>; - phy-names ="dsi-phy"; - - qcom,dual-dsi-mode; - qcom,master-dsi; - qcom,sync-dual-dsi; - - qcom,mdss-mdp-transfer-time-us = <12000>; - - pinctrl-names = "default", "sleep"; - pinctrl-0 = <&dsi_active>; - pinctrl-1 = <&dsi_suspend>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - dsi0_in: endpoint { - remote-endpoint = <&mdp_intf1_out>; - }; - }; - - port@1 { - reg = <1>; - dsi0_out: endpoint { - remote-endpoint = <&panel_in>; - data-lanes = <0 1 2 3>; - }; - }; - }; - - panel: panel@0 { - compatible = "sharp,lq101r1sx01"; - reg = <0>; - link2 = <&secondary>; - - power-supply = <...>; - backlight = <...>; - - port { - panel_in: endpoint { - remote-endpoint = <&dsi0_out>; - }; - }; - }; - }; - - dsi_phy0: dsi-phy@fd922a00 { - compatible = "qcom,dsi-phy-28nm-hpm"; - qcom,dsi-phy-index = <0>; - reg-names = - "dsi_pll", - "dsi_phy", - "dsi_phy_regulator"; - reg = <0xfd922a00 0xd4>, - <0xfd922b00 0x2b0>, - <0xfd922d80 0x7b>; - clock-names = "iface"; - clocks = <&mmcc MDSS_AHB_CLK>; - #clock-cells = <1>; - vddio-supply = <&pma8084_l12>; - - qcom,dsi-phy-regulator-ldo-mode; - }; diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/panel/lvds.yaml index 31164608ba1d..49460c9dceea 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/panel/lvds.yaml @@ -51,37 +51,37 @@ properties: - "jeida-18" - 18-bit data mapping compatible with the [JEIDA], [LDI] and [VESA] specifications. Data are transferred as follows on 3 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - "jeida-24" - 24-bit data mapping compatible with the [DSIM] and [LDI] specifications. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< - DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< - DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G2__><__R7__><__R6__><__R5__><__R4__><__R3__><__R2__>< + DATA1 ><__B3__><__B2__><__G7__><__G6__><__G5__><__G4__><__G3__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B7__><__B6__><__B5__><__B4__>< + DATA3 ><_CTL3_><__B1__><__B0__><__G1__><__G0__><__R1__><__R0__>< - "vesa-24" - 24-bit data mapping compatible with the [VESA] specification. Data are transferred as follows on 4 LVDS lanes. - Slot 0 1 2 3 4 5 6 - ________________ _________________ - Clock \_______________________/ - ______ ______ ______ ______ ______ ______ ______ - DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< - DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< - DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< - DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< + Slot 0 1 2 3 4 5 6 + ________________ _________________ + Clock \_______________________/ + ______ ______ ______ ______ ______ ______ ______ + DATA0 ><__G0__><__R5__><__R4__><__R3__><__R2__><__R1__><__R0__>< + DATA1 ><__B1__><__B0__><__G5__><__G4__><__G3__><__G2__><__G1__>< + DATA2 ><_CTL2_><_CTL1_><_CTL0_><__B5__><__B4__><__B3__><__B2__>< + DATA3 ><_CTL3_><__B7__><__B6__><__G7__><__G6__><__R7__><__R6__>< Control signals are mapped as follows. diff --git a/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml new file mode 100644 index 000000000000..4cb75a5f2e3a --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/samsung,lms397kf04.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/samsung,lms397kf04.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung LMS397KF04 display panel + +description: The datasheet claims this is based around a display controller + named DB7430 with a separate backlight controller. + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: panel-common.yaml# + +properties: + compatible: + const: samsung,lms397kf04 + + reg: true + + reset-gpios: true + + vci-supply: + description: regulator that supplies the VCI analog voltage + usually around 3.0 V + + vccio-supply: + description: regulator that supplies the VCCIO voltage usually + around 1.8 V + + backlight: true + + spi-max-frequency: + $ref: /schemas/types.yaml#/definitions/uint32 + description: inherited as a SPI client node, the datasheet specifies + maximum 300 ns minimum cycle which gives around 3 MHz max frequency + maximum: 3000000 + + port: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + panel@0 { + compatible = "samsung,lms397kf04"; + spi-max-frequency = <3000000>; + reg = <0>; + vci-supply = <&lcd_3v0_reg>; + vccio-supply = <&lcd_1v8_reg>; + reset-gpios = <&gpio 1 GPIO_ACTIVE_LOW>; + backlight = <&ktd259>; + + port { + panel_in: endpoint { + remote-endpoint = <&display_out>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 121596f106da..5f4345d43020 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -55,7 +55,7 @@ properties: maxItems: 1 ports: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/properties/ports description: | The connections to the DU output video ports are modeled using the OF graph bindings specified in Documentation/devicetree/bindings/graph.txt. diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml index 75cd9c686e98..da3b889ad8fc 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-hdmi.yaml @@ -29,7 +29,6 @@ properties: clocks: minItems: 2 - maxItems: 5 items: - {} - {} @@ -41,7 +40,6 @@ properties: clock-names: minItems: 2 - maxItems: 5 items: - {} - {} diff --git a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml index 679daed4124e..ed310bbe3afe 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-dsi.yaml @@ -29,7 +29,6 @@ properties: - description: DSI bus clock - description: Pixel clock minItems: 2 - maxItems: 3 clock-names: items: @@ -37,7 +36,6 @@ properties: - const: ref - const: px_clk minItems: 2 - maxItems: 3 resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml index d54f9ca207af..4ae3d75492d3 100644 --- a/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml +++ b/Documentation/devicetree/bindings/display/st,stm32-ltdc.yaml @@ -22,7 +22,6 @@ properties: - description: events interrupt line. - description: errors interrupt line. minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml index 403d57977ee7..d88bd93f4b80 100644 --- a/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml +++ b/Documentation/devicetree/bindings/display/xlnx/xlnx,zynqmp-dpsub.yaml @@ -65,7 +65,6 @@ properties: The APB clock and at least one video clock are mandatory, the audio clock is optional. minItems: 2 - maxItems: 4 items: - description: dp_apb_clk is the APB clock - description: dp_aud_clk is the Audio clock @@ -78,13 +77,11 @@ properties: clock-names: oneOf: - minItems: 2 - maxItems: 3 items: - const: dp_apb_clk - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - enum: [ dp_vtc_pixel_clk_in, dp_live_video_in_clk ] - minItems: 3 - maxItems: 4 items: - const: dp_apb_clk - const: dp_aud_clk @@ -116,7 +113,6 @@ properties: maxItems: 2 phy-names: minItems: 1 - maxItems: 2 items: - const: dp-phy0 - const: dp-phy1 diff --git a/Documentation/devicetree/bindings/dma/altr,msgdma.yaml b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml new file mode 100644 index 000000000000..a4f9fe23dcd9 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/altr,msgdma.yaml @@ -0,0 +1,61 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/altr,msgdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Altera mSGDMA IP core + +maintainers: + - Olivier Dautricourt <olivier.dautricourt@orolia.com> + +description: | + Altera / Intel modular Scatter-Gather Direct Memory Access (mSGDMA) + intellectual property (IP) + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + const: altr,socfpga-msgdma + + reg: + items: + - description: Control and Status Register Slave Port + - description: Descriptor Slave Port + - description: Response Slave Port + + reg-names: + items: + - const: csr + - const: desc + - const: resp + + interrupts: + maxItems: 1 + + "#dma-cells": + const: 1 + description: + The cell identifies the channel id (must be 0) + +required: + - compatible + - reg + - reg-names + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + msgdma_controller: dma-controller@ff200b00 { + compatible = "altr,socfpga-msgdma"; + reg = <0xff200b00 0x100>, <0xff200c00 0x100>, <0xff200d00 0x100>; + reg-names = "csr", "desc", "resp"; + interrupts = <0 67 IRQ_TYPE_LEVEL_HIGH>; + #dma-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.txt b/Documentation/devicetree/bindings/dma/arm-pl08x.txt deleted file mode 100644 index 0ba81f79266f..000000000000 --- a/Documentation/devicetree/bindings/dma/arm-pl08x.txt +++ /dev/null @@ -1,59 +0,0 @@ -* ARM PrimeCells PL080 and PL081 and derivatives DMA controller - -Required properties: -- compatible: "arm,pl080", "arm,primecell"; - "arm,pl081", "arm,primecell"; - "faraday,ftdmac020", "arm,primecell" -- arm,primecell-periphid: on the FTDMAC020 the primecell ID is not hard-coded - in the hardware and must be specified here as <0x0003b080>. This number - follows the PrimeCell standard numbering using the JEP106 vendor code 0x38 - for Faraday Technology. -- reg: Address range of the PL08x registers -- interrupt: The PL08x interrupt number -- clocks: The clock running the IP core clock -- clock-names: Must contain "apb_pclk" -- lli-bus-interface-ahb1: if AHB master 1 is eligible for fetching LLIs -- lli-bus-interface-ahb2: if AHB master 2 is eligible for fetching LLIs -- mem-bus-interface-ahb1: if AHB master 1 is eligible for fetching memory contents -- mem-bus-interface-ahb2: if AHB master 2 is eligible for fetching memory contents -- #dma-cells: must be <2>. First cell should contain the DMA request, - second cell should contain either 1 or 2 depending on - which AHB master that is used. - -Optional properties: -- dma-channels: contains the total number of DMA channels supported by the DMAC -- dma-requests: contains the total number of DMA requests supported by the DMAC -- memcpy-burst-size: the size of the bursts for memcpy: 1, 4, 8, 16, 32 - 64, 128 or 256 bytes are legal values -- memcpy-bus-width: the bus width used for memcpy in bits: 8, 16 or 32 are legal - values, the Faraday FTDMAC020 can also accept 64 bits - -Clients -Required properties: -- dmas: List of DMA controller phandle, request channel and AHB master id -- dma-names: Names of the aforementioned requested channels - -Example: - -dmac0: dma-controller@10130000 { - compatible = "arm,pl080", "arm,primecell"; - reg = <0x10130000 0x1000>; - interrupt-parent = <&vica>; - interrupts = <15>; - clocks = <&hclkdma0>; - clock-names = "apb_pclk"; - lli-bus-interface-ahb1; - lli-bus-interface-ahb2; - mem-bus-interface-ahb2; - memcpy-burst-size = <256>; - memcpy-bus-width = <32>; - #dma-cells = <2>; -}; - -device@40008000 { - ... - dmas = <&dmac0 0 2 - &dmac0 1 2>; - dma-names = "tx", "rx"; - ... -}; diff --git a/Documentation/devicetree/bindings/dma/arm-pl08x.yaml b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml new file mode 100644 index 000000000000..3bd9eea543ca --- /dev/null +++ b/Documentation/devicetree/bindings/dma/arm-pl08x.yaml @@ -0,0 +1,136 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/arm-pl08x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PrimeCells PL080 and PL081 and derivatives DMA controller + +maintainers: + - Vinod Koul <vkoul@kernel.org> + +allOf: + - $ref: "dma-controller.yaml#" + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + enum: + - arm,pl080 + - arm,pl081 + required: + - compatible + +properties: + compatible: + oneOf: + - items: + - enum: + - arm,pl080 + - arm,pl081 + - const: arm,primecell + - items: + - const: faraday,ftdma020 + - const: arm,pl080 + - const: arm,primecell + + reg: + maxItems: 1 + description: Address range of the PL08x registers + + interrupts: + minItems: 1 + description: The PL08x interrupt number + + clocks: + minItems: 1 + description: The clock running the IP core clock + + clock-names: + maxItems: 1 + + lli-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching LLIs + + lli-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching LLIs + + mem-bus-interface-ahb1: + type: boolean + description: if AHB master 1 is eligible for fetching memory contents + + mem-bus-interface-ahb2: + type: boolean + description: if AHB master 2 is eligible for fetching memory contents + + memcpy-burst-size: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 1 + - 4 + - 8 + - 16 + - 32 + - 64 + - 128 + - 256 + description: the size of the bursts for memcpy + + memcpy-bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 8 + - 16 + - 32 + - 64 + description: bus width used for memcpy in bits. FTDMAC020 also accept 64 bits + +required: + - reg + - interrupts + - clocks + - clock-names + - "#dma-cells" + +unevaluatedProperties: false + +examples: + - | + dmac0: dma-controller@10130000 { + compatible = "arm,pl080", "arm,primecell"; + reg = <0x10130000 0x1000>; + interrupt-parent = <&vica>; + interrupts = <15>; + clocks = <&hclkdma0>; + clock-names = "apb_pclk"; + lli-bus-interface-ahb1; + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + #include <dt-bindings/clock/cortina,gemini-clock.h> + dma-controller@67000000 { + compatible = "faraday,ftdma020", "arm,pl080", "arm,primecell"; + /* Faraday Technology FTDMAC020 variant */ + arm,primecell-periphid = <0x0003b080>; + reg = <0x67000000 0x1000>; + interrupts = <9 IRQ_TYPE_EDGE_RISING>; + resets = <&syscon GEMINI_RESET_DMAC>; + clocks = <&syscon GEMINI_CLK_AHB>; + clock-names = "apb_pclk"; + /* Bus interface AHB1 (AHB0) is totally tilted */ + lli-bus-interface-ahb2; + mem-bus-interface-ahb2; + memcpy-burst-size = <256>; + memcpy-bus-width = <32>; + #dma-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml index e302147e53c6..e614fe3187bb 100644 --- a/Documentation/devicetree/bindings/dma/qcom,gpi.yaml +++ b/Documentation/devicetree/bindings/dma/qcom,gpi.yaml @@ -21,6 +21,7 @@ properties: enum: - qcom,sdm845-gpi-dma - qcom,sm8150-gpi-dma + - qcom,sm8250-gpi-dma reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml index 7f2a54bc732d..d8142cbd13d3 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rcar-dmac.yaml @@ -52,7 +52,6 @@ properties: interrupt-names: minItems: 9 - maxItems: 17 items: - const: error - pattern: "^ch([0-9]|1[0-5])$" diff --git a/Documentation/devicetree/bindings/dma/renesas,shdma.txt b/Documentation/devicetree/bindings/dma/renesas,shdma.txt deleted file mode 100644 index a91920a49433..000000000000 --- a/Documentation/devicetree/bindings/dma/renesas,shdma.txt +++ /dev/null @@ -1,84 +0,0 @@ -* SHDMA Device Tree bindings - -Sh-/r-mobile and R-Car systems often have multiple identical DMA controller -instances, capable of serving any of a common set of DMA slave devices, using -the same configuration. To describe this topology we require all compatible -SHDMA DT nodes to be placed under a DMA multiplexer node. All such compatible -DMAC instances have the same number of channels and use the same DMA -descriptors. Therefore respective DMA DT bindings can also all be placed in the -multiplexer node. Even if there is only one such DMAC instance on a system, it -still has to be placed under such a multiplexer node. - -* DMA multiplexer - -Required properties: -- compatible: should be "renesas,shdma-mux" -- #dma-cells: should be <1>, see "dmas" property below - -Optional properties (currently unused): -- dma-channels: number of DMA channels -- dma-requests: number of DMA request signals - -* DMA controller - -Required properties: -- compatible: should be of the form "renesas,shdma-<soc>", where <soc> should - be replaced with the desired SoC model, e.g. - "renesas,shdma-r8a73a4" for the system DMAC on r8a73a4 SoC - -Example: - dmac: dma-multiplexer@0 { - compatible = "renesas,shdma-mux"; - #dma-cells = <1>; - dma-channels = <20>; - dma-requests = <256>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - dma0: dma-controller@e6700020 { - compatible = "renesas,shdma-r8a73a4"; - reg = <0 0xe6700020 0 0x89e0>; - interrupt-parent = <&gic>; - interrupts = <0 220 4 - 0 200 4 - 0 201 4 - 0 202 4 - 0 203 4 - 0 204 4 - 0 205 4 - 0 206 4 - 0 207 4 - 0 208 4 - 0 209 4 - 0 210 4 - 0 211 4 - 0 212 4 - 0 213 4 - 0 214 4 - 0 215 4 - 0 216 4 - 0 217 4 - 0 218 4 - 0 219 4>; - interrupt-names = "error", - "ch0", "ch1", "ch2", "ch3", - "ch4", "ch5", "ch6", "ch7", - "ch8", "ch9", "ch10", "ch11", - "ch12", "ch13", "ch14", "ch15", - "ch16", "ch17", "ch18", "ch19"; - }; - }; - -* DMA client - -Required properties: -- dmas: a list of <[DMA multiplexer phandle] [MID/RID value]> pairs, - where MID/RID values are fixed handles, specified in the SoC - manual -- dma-names: a list of DMA channel names, one per "dmas" entry - -Example: - dmas = <&dmac 0xd1 - &dmac 0xd2>; - dma-names = "tx", "rx"; diff --git a/Documentation/devicetree/bindings/dma/ti-edma.txt b/Documentation/devicetree/bindings/dma/ti-edma.txt index 29fcd37082e8..f719e1612b0a 100644 --- a/Documentation/devicetree/bindings/dma/ti-edma.txt +++ b/Documentation/devicetree/bindings/dma/ti-edma.txt @@ -33,7 +33,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- @@ -70,7 +70,7 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: ------------------- diff --git a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml index 57e5270a0741..4cfc3a187004 100644 --- a/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml +++ b/Documentation/devicetree/bindings/edac/amazon,al-mc-edac.yaml @@ -30,14 +30,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: uncorrectable error interrupt - description: correctable error interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: ue - const: ce diff --git a/Documentation/devicetree/bindings/eeprom/at24.yaml b/Documentation/devicetree/bindings/eeprom/at24.yaml index 021d8ae42da3..914a423ec449 100644 --- a/Documentation/devicetree/bindings/eeprom/at24.yaml +++ b/Documentation/devicetree/bindings/eeprom/at24.yaml @@ -32,7 +32,6 @@ properties: oneOf: - allOf: - minItems: 1 - maxItems: 2 items: - pattern: "^(atmel|catalyst|microchip|nxp|ramtron|renesas|rohm|st),(24(c|cs|lc|mac)[0-9]+|spd)$" - pattern: "^atmel,(24(c|cs|mac)[0-9]+|spd)$" diff --git a/Documentation/devicetree/bindings/eeprom/at25.yaml b/Documentation/devicetree/bindings/eeprom/at25.yaml index 6a2dc8b3ed14..fbf99e346966 100644 --- a/Documentation/devicetree/bindings/eeprom/at25.yaml +++ b/Documentation/devicetree/bindings/eeprom/at25.yaml @@ -4,14 +4,16 @@ $id: "http://devicetree.org/schemas/eeprom/at25.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: SPI EEPROMs compatible with Atmel's AT25 +title: SPI EEPROMs or FRAMs compatible with Atmel's AT25 maintainers: - Christian Eggers <ceggers@arri.de> properties: $nodename: - pattern: "^eeprom@[0-9a-f]{1,2}$" + anyOf: + - pattern: "^eeprom@[0-9a-f]{1,2}$" + - pattern: "^fram@[0-9a-f]{1,2}$" # There are multiple known vendors who manufacture EEPROM chips compatible # with Atmel's AT25. The compatible string requires two items where the @@ -31,6 +33,7 @@ properties: - microchip,25lc040 - st,m95m02 - st,m95256 + - cypress,fm25 - const: atmel,at25 @@ -47,7 +50,7 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 enum: [1, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536, 131072] description: - Size of the eeprom page. + Size of the eeprom page. FRAMs don't have pages. size: $ref: /schemas/types.yaml#/definitions/uint32 @@ -100,9 +103,19 @@ required: - compatible - reg - spi-max-frequency - - pagesize - - size - - address-width + +allOf: + - if: + properties: + compatible: + not: + contains: + const: cypress,fm25 + then: + required: + - pagesize + - size + - address-width additionalProperties: false @@ -125,4 +138,10 @@ examples: size = <32768>; address-width = <16>; }; + + fram@1 { + compatible = "cypress,fm25", "atmel,at25"; + reg = <1>; + spi-max-frequency = <40000000>; + }; }; diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index a97f39109f8d..ff6ec65145cf 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -91,7 +91,6 @@ properties: interrupts: # Either 1 or 2 interrupts can be present minItems: 1 - maxItems: 2 items: - description: tx or combined interrupt - description: rx interrupt @@ -105,7 +104,6 @@ properties: interrupt-names: # minItems must be specified here because the default would be 2 minItems: 1 - maxItems: 2 items: - const: tx irq - const: rx irq diff --git a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt b/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt deleted file mode 100644 index fc3888e09549..000000000000 --- a/Documentation/devicetree/bindings/extcon/extcon-sm5502.txt +++ /dev/null @@ -1,21 +0,0 @@ - -* SM5502 MUIC (Micro-USB Interface Controller) device - -The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device -which can detect the state of external accessory when external accessory is -attached or detached and button is pressed or released. It is interfaced to -the host controller using an I2C interface. - -Required properties: -- compatible: Should be "siliconmitus,sm5502-muic" -- reg: Specifies the I2C slave address of the MUIC block. It should be 0x25 -- interrupts: Interrupt specifiers for detection interrupt sources. - -Example: - - sm5502@25 { - compatible = "siliconmitus,sm5502-muic"; - interrupt-parent = <&gpx1>; - interrupts = <5 0>; - reg = <0x25>; - }; diff --git a/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml new file mode 100644 index 000000000000..fd2e55088888 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/siliconmitus,sm5502-muic.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/siliconmitus,sm5502-muic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SM5502/SM5504 MUIC (Micro-USB Interface Controller) device + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + +description: + The Silicon Mitus SM5502 is a MUIC (Micro-USB Interface Controller) device + which can detect the state of external accessory when external accessory is + attached or detached and button is pressed or released. It is interfaced to + the host controller using an I2C interface. + +properties: + compatible: + enum: + - siliconmitus,sm5502-muic + - siliconmitus,sm5504-muic + + reg: + maxItems: 1 + description: I2C slave address of the device. Usually 0x25 for SM5502, + 0x14 for SM5504. + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + extcon@25 { + compatible = "siliconmitus,sm5502-muic"; + reg = <0x25>; + interrupt-parent = <&msmgpio>; + interrupts = <12 IRQ_TYPE_EDGE_FALLING>; + }; + }; diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml new file mode 100644 index 000000000000..cebf6ffe70d5 --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -0,0 +1,341 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Management Interface (SCMI) Message Protocol bindings + +maintainers: + - Sudeep Holla <sudeep.holla@arm.com> + +description: | + 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 0056 ("ARM System Control + and Management Interface Platform Design Document")[0] provide for OSPM in + the device tree. + + [0] https://developer.arm.com/documentation/den0056/latest + +properties: + $nodename: + const: scmi + + compatible: + oneOf: + - description: SCMI compliant firmware with mailbox transport + items: + - const: arm,scmi + - description: SCMI compliant firmware with ARM SMC/HVC transport + items: + - const: arm,scmi-smc + + interrupts: + description: + The interrupt that indicates message completion by the platform + rather than by the return of the smc call. This should not be used + except when the platform requires such behavior. + maxItems: 1 + + interrupt-names: + const: a2p + + mbox-names: + description: + Specifies the mailboxes used to communicate with SCMI compliant + firmware. + items: + - const: tx + - const: rx + + mboxes: + description: + 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. + minItems: 1 + maxItems: 2 + + shmem: + description: + List of phandle pointing to the shared memory(SHM) area, for each + transport channel specified. + minItems: 1 + maxItems: 2 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + arm,smc-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + SMC id required when using smc or hvc transports + + protocol@11: + type: object + properties: + reg: + const: 0x11 + + '#power-domain-cells': + const: 1 + + required: + - '#power-domain-cells' + + protocol@13: + type: object + properties: + reg: + const: 0x13 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@14: + type: object + properties: + reg: + const: 0x14 + + '#clock-cells': + const: 1 + + required: + - '#clock-cells' + + protocol@15: + type: object + properties: + reg: + const: 0x15 + + '#thermal-sensor-cells': + const: 1 + + required: + - '#thermal-sensor-cells' + + protocol@16: + type: object + properties: + reg: + const: 0x16 + + '#reset-cells': + const: 1 + + required: + - '#reset-cells' + + protocol@17: + type: object + properties: + reg: + const: 0x17 + + regulators: + type: object + description: + The list of all regulators provided by this SCMI controller. + + patternProperties: + '^regulators@[0-9a-f]+$': + type: object + $ref: "../regulator/regulator.yaml#" + + properties: + reg: + maxItems: 1 + description: Identifier for the voltage regulator. + + required: + - reg + +additionalProperties: false + +patternProperties: + '^protocol@[0-9a-f]+$': + type: object + description: + Each sub-node represents a protocol supported. If the platform + supports a dedicated communication channel for a particular protocol, + then the corresponding transport properties must be present. + + properties: + reg: + maxItems: 1 + + mbox-names: + items: + - const: tx + - const: rx + + mboxes: + minItems: 1 + maxItems: 2 + + shmem: + minItems: 1 + maxItems: 2 + + required: + - reg + +required: + - compatible + - shmem + +if: + properties: + compatible: + contains: + const: arm,scmi +then: + properties: + interrupts: false + interrupt-names: false + + required: + - mboxes + +else: + if: + properties: + compatible: + contains: + const: arm,scmi-smc + then: + required: + - arm,smc-id + +examples: + - | + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, + <&mhuB 0 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; + + #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>; + + mboxes = <&mhuB 1 0>, + <&mhuB 1 1>; + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; + + scmi_clk: protocol@14 { + reg = <0x14>; + #clock-cells = <1>; + }; + + scmi_sensors: protocol@15 { + reg = <0x15>; + #thermal-sensor-cells = <1>; + }; + + scmi_reset: protocol@16 { + reg = <0x16>; + #reset-cells = <1>; + }; + + scmi_voltage: protocol@17 { + reg = <0x17>; + regulators { + #address-cells = <1>; + #size-cells = <0>; + + regulator_devX: regulator@0 { + reg = <0x0>; + regulator-max-microvolt = <3300000>; + }; + + regulator_devY: regulator@9 { + reg = <0x9>; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <4200000>; + }; + }; + }; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@50000000 { + compatible = "mmio-sram"; + reg = <0x0 0x50000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x50000000 0x10000>; + + cpu_scp_lpri0: scp-sram-section@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x80>; + }; + + cpu_scp_lpri1: scp-sram-section@80 { + compatible = "arm,scmi-shmem"; + reg = <0x80 0x80>; + }; + + cpu_scp_hpri0: scp-sram-section@100 { + compatible = "arm,scmi-shmem"; + reg = <0x100 0x80>; + }; + + cpu_scp_hpri2: scp-sram-section@180 { + compatible = "arm,scmi-shmem"; + reg = <0x180 0x80>; + }; + }; + }; + + - | + firmware { + scmi { + compatible = "arm,scmi-smc"; + shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>; + arm,smc-id = <0xc3000001>; + + #address-cells = <1>; + #size-cells = <0>; + + scmi_devpd1: protocol@11 { + reg = <0x11>; + #power-domain-cells = <1>; + }; + + }; + }; + +... diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml new file mode 100644 index 000000000000..d7113b06454b --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -0,0 +1,247 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2021 ARM Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/arm,scpi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: System Control and Power Interface (SCPI) Message Protocol bindings + +maintainers: + - Sudeep Holla <sudeep.holla@arm.com> + +description: | + 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. + + This binding is intended to define the interface the firmware implementing + the SCPI provide for OSPM in the device tree. + + [0] http://infocenter.arm.com/help/topic/com.arm.doc.dui0922b/index.html + +properties: + $nodename: + const: scpi + + compatible: + description: + SCPI compliant firmware complying to SCPI v1.0 and above OR + SCPI compliant firmware complying to all unversioned releases + prior to SCPI v1.0 + oneOf: + - const: arm,scpi # SCPI v1.0 and above + - const: arm,scpi-pre-1.0 # Unversioned SCPI before v1.0 + - items: + - enum: + - amlogic,meson-gxbb-scpi + - const: arm,scpi-pre-1.0 + + mboxes: + description: + 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. + minItems: 1 + + shmem: + description: + 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. + minItems: 1 + + power-controller: + type: object + description: + This sub-node represents SCPI power domain controller. + + properties: + compatible: + const: arm,scpi-power-domains + + '#power-domain-cells': + const: 1 + + num-domains: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + 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. + + required: + - compatible + - '#power-domain-cells' + - num-domains + + additionalProperties: false + + sensors: + type: object + description: | + This sub-node represents SCPI sensors controller. + + properties: + compatible: + oneOf: + - const: arm,scpi-sensors + - items: + - enum: + - amlogic,meson-gxbb-scpi-sensors + - const: arm,scpi-sensors + + '#thermal-sensor-cells': + const: 1 + + required: + - compatible + - '#thermal-sensor-cells' + + additionalProperties: false + + clocks: + type: object + description: + This is the container node. Each sub-node represents one of the types + of clock controller - indexed or full range. + + properties: + compatible: + const: arm,scpi-clocks + + patternProperties: + "^clocks-[0-9a-f]+$": + type: object + description: | + This sub-node represents one of the types of clock controller + - indexed or full range. + + "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. + + properties: + compatible: + oneOf: + - const: arm,scpi-dvfs-clocks + - const: arm,scpi-variable-clocks + + '#clock-cells': + const: 1 + + clock-output-names: true + + clock-indices: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + 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. + + required: + - compatible + - '#clock-cells' + - clock-output-names + - clock-indices + + additionalProperties: false + + required: + - compatible + + additionalProperties: false + +additionalProperties: false + +required: + - compatible + - mboxes + - shmem + +examples: + - | + firmware { + scpi { + compatible = "arm,scpi"; + mboxes = <&mhuA 1>; + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; + + clocks { + compatible = "arm,scpi-clocks"; + + scpi_dvfs: clocks-0 { + compatible = "arm,scpi-dvfs-clocks"; + #clock-cells = <1>; + clock-indices = <0>, <1>, <2>; + clock-output-names = "atlclk", "aplclk","gpuclk"; + }; + + scpi_clk: clocks-1 { + compatible = "arm,scpi-variable-clocks"; + #clock-cells = <1>; + clock-indices = <3>, <4>; + clock-output-names = "pxlclk0", "pxlclk1"; + }; + }; + + scpi_sensors: sensors { + compatible = "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; + + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + 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-sram-section@0 { + compatible = "arm,scp-shmem"; + reg = <0x0 0x200>; + }; + + cpu_scp_hpri: scp-sram-section@200 { + compatible = "arm,scp-shmem"; + reg = <0x200 0x200>; + }; + }; + }; + + - | + firmware { + scpi { + compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; + mboxes = <&mailbox 1 &mailbox 2>; + shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + + scpi_sensors1: sensors { + compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors"; + #thermal-sensor-cells = <1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/fpga/fpga-region.txt b/Documentation/devicetree/bindings/fpga/fpga-region.txt index d787d57491a1..7d3515264838 100644 --- a/Documentation/devicetree/bindings/fpga/fpga-region.txt +++ b/Documentation/devicetree/bindings/fpga/fpga-region.txt @@ -38,7 +38,7 @@ Partial Reconfiguration (PR) Partial Reconfiguration Region (PRR) * Also called a "reconfigurable partition" - * A PRR is a specific section of a FPGA reserved for reconfiguration. + * A PRR is a specific section of an FPGA reserved for reconfiguration. * A base (or static) FPGA image may create a set of PRR's that later may be independently reprogrammed many times. * The size and specific location of each PRR is fixed. @@ -105,7 +105,7 @@ reprogrammed independently while the rest of the system continues to function. Sequence ======== -When a DT overlay that targets a FPGA Region is applied, the FPGA Region will +When a DT overlay that targets an FPGA Region is applied, the FPGA Region will do the following: 1. Disable appropriate FPGA bridges. @@ -134,8 +134,8 @@ The intended use is that a Device Tree overlay (DTO) can be used to reprogram an FPGA while an operating system is running. An FPGA Region that exists in the live Device Tree reflects the current state. -If the live tree shows a "firmware-name" property or child nodes under a FPGA -Region, the FPGA already has been programmed. A DTO that targets a FPGA Region +If the live tree shows a "firmware-name" property or child nodes under an FPGA +Region, the FPGA already has been programmed. A DTO that targets an FPGA Region and adds the "firmware-name" property is taken as a request to reprogram the FPGA. After reprogramming is successful, the overlay is accepted into the live tree. @@ -152,9 +152,9 @@ These FPGA regions are children of FPGA bridges which are then children of the base FPGA region. The "Full Reconfiguration to add PRR's" example below shows this. -If an FPGA Region does not specify a FPGA Manager, it will inherit the FPGA +If an FPGA Region does not specify an FPGA Manager, it will inherit the FPGA Manager specified by its ancestor FPGA Region. This supports both the case -where the same FPGA Manager is used for all of a FPGA as well the case where +where the same FPGA Manager is used for all of an FPGA as well the case where a different FPGA Manager is used for each region. FPGA Regions do not inherit their ancestor FPGA regions' bridges. This prevents @@ -166,7 +166,7 @@ within the static image of the FPGA. Required properties: - compatible : should contain "fpga-region" - fpga-mgr : should contain a phandle to an FPGA Manager. Child FPGA Regions - inherit this property from their ancestor regions. A fpga-mgr property + inherit this property from their ancestor regions. An fpga-mgr property in a region will override any inherited FPGA manager. - #address-cells, #size-cells, ranges : must be present to handle address space mapping for child nodes. @@ -175,12 +175,12 @@ Optional properties: - firmware-name : should contain the name of an FPGA image file located on the firmware search path. If this property shows up in a live device tree it indicates that the FPGA has already been programmed with this image. - If this property is in an overlay targeting a FPGA region, it is a + If this property is in an overlay targeting an FPGA region, it is a request to program the FPGA with that image. - fpga-bridges : should contain a list of phandles to FPGA Bridges that must be controlled during FPGA programming along with the parent FPGA bridge. This property is optional if the FPGA Manager handles the bridges. - If the fpga-region is the child of a fpga-bridge, the list should not + If the fpga-region is the child of an fpga-bridge, the list should not contain the parent bridge. - partial-fpga-config : boolean, set if partial reconfiguration is to be done, otherwise full reconfiguration is done. @@ -279,7 +279,7 @@ Supported Use Models In all cases the live DT must have the FPGA Manager, FPGA Bridges (if any), and a FPGA Region. The target of the Device Tree Overlay is the FPGA Region. Some -uses are specific to a FPGA device. +uses are specific to an FPGA device. * No FPGA Bridges In this case, the FPGA Manager which programs the FPGA also handles the @@ -300,7 +300,7 @@ uses are specific to a FPGA device. bridges need to exist in the FPGA that can gate the buses going to each FPGA region while the buses are enabled for other sections. Before any partial reconfiguration can be done, a base FPGA image must be loaded which includes - PRR's with FPGA bridges. The device tree should have a FPGA region for each + PRR's with FPGA bridges. The device tree should have an FPGA region for each PRR. Device Tree Examples diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt deleted file mode 100644 index 7018aa896835..000000000000 --- a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.txt +++ /dev/null @@ -1,19 +0,0 @@ -Xilinx Zynq FPGA Manager - -Required properties: -- compatible: should contain "xlnx,zynq-devcfg-1.0" -- reg: base address and size for memory mapped io -- interrupts: interrupt for the FPGA manager device -- clocks: phandle for clocks required operation -- clock-names: name for the clock, should be "ref_clk" -- syscon: phandle for access to SLCR registers - -Example: - devcfg: devcfg@f8007000 { - compatible = "xlnx,zynq-devcfg-1.0"; - reg = <0xf8007000 0x100>; - interrupts = <0 8 4>; - clocks = <&clkc 12>; - clock-names = "ref_clk"; - syscon = <&slcr>; - }; diff --git a/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml new file mode 100644 index 000000000000..29daca4be47f --- /dev/null +++ b/Documentation/devicetree/bindings/fpga/xilinx-zynq-fpga-mgr.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/fpga/xilinx-zynq-fpga-mgr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq FPGA Manager Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +properties: + compatible: + const: xlnx,zynq-devcfg-1.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ref_clk + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to syscon block which provide access to SLCR registers + +required: + - compatible + - reg + - clocks + - clock-names + - syscon + +additionalProperties: false + +examples: + - | + devcfg: devcfg@f8007000 { + compatible = "xlnx,zynq-devcfg-1.0"; + reg = <0xf8007000 0x100>; + interrupts = <0 8 4>; + clocks = <&clkc 12>; + clock-names = "ref_clk"; + syscon = <&slcr>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt b/Documentation/devicetree/bindings/gpio/gpio-davinci.txt deleted file mode 100644 index 696ea46227d1..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-davinci.txt +++ /dev/null @@ -1,167 +0,0 @@ -Davinci/Keystone GPIO controller bindings - -Required Properties: -- compatible: should be "ti,dm6441-gpio": for Davinci da850 SoCs - "ti,keystone-gpio": for Keystone 2 66AK2H/K, 66AK2L, - 66AK2E SoCs - "ti,k2g-gpio", "ti,keystone-gpio": for 66AK2G - "ti,am654-gpio", "ti,keystone-gpio": for TI K3 AM654 - "ti,j721e-gpio", "ti,keystone-gpio": for J721E SoCs - "ti,am64-gpio", "ti,keystone-gpio": for AM64 SoCs - -- reg: Physical base address of the controller and the size of memory mapped - registers. - -- gpio-controller : Marks the device node as a gpio controller. - -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) - -- interrupts: Array of GPIO interrupt number. Only banked or unbanked IRQs are - supported at a time. - -- ti,ngpio: The number of GPIO pins supported. - -- ti,davinci-gpio-unbanked: The number of GPIOs that have an individual interrupt - line to processor. - -- clocks: Should contain the device's input clock, and should be defined as per - the appropriate clock bindings consumer usage in, - - Documentation/devicetree/bindings/clock/keystone-gate.txt - for 66AK2HK/66AK2L/66AK2E SoCs or, - - Documentation/devicetree/bindings/clock/ti,sci-clk.txt - for 66AK2G SoCs - -- clock-names: Name should be "gpio"; - -Currently clock-names and clocks are needed for all keystone 2 platforms -Davinci platforms do not have DT clocks as of now. - -The GPIO controller also acts as an interrupt controller. It uses the default -two cells specifier as described in Documentation/devicetree/bindings/ -interrupt-controller/interrupts.txt. - -Example: - -gpio: gpio@1e26000 { - compatible = "ti,dm6441-gpio"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x226000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <42 IRQ_TYPE_EDGE_BOTH 43 IRQ_TYPE_EDGE_BOTH - 44 IRQ_TYPE_EDGE_BOTH 45 IRQ_TYPE_EDGE_BOTH - 46 IRQ_TYPE_EDGE_BOTH 47 IRQ_TYPE_EDGE_BOTH - 48 IRQ_TYPE_EDGE_BOTH 49 IRQ_TYPE_EDGE_BOTH - 50 IRQ_TYPE_EDGE_BOTH>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - interrupt-controller; - #interrupt-cells = <2>; -}; - -leds { - compatible = "gpio-leds"; - - led1 { - label = "davinci:green:usr1"; - gpios = <&gpio 10 GPIO_ACTIVE_HIGH>; - ... - }; - - led2 { - label = "davinci:red:debug1"; - gpios = <&gpio 11 GPIO_ACTIVE_HIGH>; - ... - }; -}; - -Example for 66AK2G: - -gpio0: gpio@2603000 { - compatible = "ti,k2g-gpio", "ti,keystone-gpio"; - reg = <0x02603000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupts = <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <144>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k2g_clks 0x001b 0x0>; - clock-names = "gpio"; -}; - -Example for 66AK2HK/66AK2L/66AK2E: - -gpio0: gpio@260bf00 { - compatible = "ti,keystone-gpio"; - reg = <0x0260bf00 0x100>; - gpio-controller; - #gpio-cells = <2>; - /* HW Interrupts mapped to GPIO pins */ - interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 121 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 124 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 144 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 146 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 147 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 148 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 149 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 150 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; - clocks = <&clkgpio>; - clock-names = "gpio"; - ti,ngpio = <32>; - ti,davinci-gpio-unbanked = <32>; -}; - -Example for K3 AM654: - -wkup_gpio0: wkup_gpio0@42110000 { - compatible = "ti,am654-gpio", "ti,keystone-gpio"; - reg = <0x42110000 0x100>; - gpio-controller; - #gpio-cells = <2>; - interrupt-parent = <&intr_wkup_gpio>; - interrupts = <59 128>, <59 129>, <59 130>, <59 131>; - interrupt-controller; - #interrupt-cells = <2>; - ti,ngpio = <56>; - ti,davinci-gpio-unbanked = <0>; - clocks = <&k3_clks 59 0>; - clock-names = "gpio"; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml new file mode 100644 index 000000000000..f32e09ef937c --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-davinci.yaml @@ -0,0 +1,185 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-davinci.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO controller for Davinci and keystone devices + +maintainers: + - Keerthy <j-keerthy@ti.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - ti,k2g-gpio + - ti,am654-gpio + - ti,j721e-gpio + - ti,am64-gpio + - const: ti,keystone-gpio + + - items: + - enum: + - ti,dm6441-gpio + - ti,keystone-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + gpio-ranges: true + + gpio-line-names: + description: strings describing the names of each gpio line. + minItems: 1 + maxItems: 100 + + "#gpio-cells": + const: 2 + description: + first cell is the pin number and second cell is used to specify optional parameters (unused). + + interrupts: + description: + The interrupts are specified as per the interrupt parent. Only banked + or unbanked IRQs are supported at a time. If the interrupts are + banked then provide list of interrupts corresponding to each bank, else + provide the list of interrupts for each gpio. + minItems: 1 + maxItems: 100 + + ti,ngpio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIO pins supported consecutively. + minimum: 1 + + ti,davinci-gpio-unbanked: + $ref: /schemas/types.yaml#/definitions/uint32 + description: The number of GPIOs that have an individual interrupt line to processor. + minimum: 0 + + clocks: + maxItems: 1 + + clock-names: + const: gpio + + interrupt-controller: true + + power-domains: + maxItems: 1 + + "#interrupt-cells": + const: 2 + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupts + - ti,ngpio + - ti,davinci-gpio-unbanked + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include<dt-bindings/interrupt-controller/arm-gic.h> + + gpio0: gpio@2603000 { + compatible = "ti,k2g-gpio", "ti,keystone-gpio"; + reg = <0x02603000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <GIC_SPI 432 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 433 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 434 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 435 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 436 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 437 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 438 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 439 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 440 IRQ_TYPE_EDGE_RISING>; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <144>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k2g_clks 0x001b 0x0>; + clock-names = "gpio"; + }; + + - | + #include<dt-bindings/interrupt-controller/arm-gic.h> + + gpio1: gpio@260bf00 { + compatible = "ti,keystone-gpio"; + reg = <0x0260bf00 0x100>; + gpio-controller; + #gpio-cells = <2>; + /* HW Interrupts mapped to GPIO pins */ + interrupts = <GIC_SPI 120 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 121 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 122 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 123 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 124 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 125 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 126 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 127 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 128 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 129 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 130 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 131 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 132 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 133 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 134 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 135 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 136 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 137 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 138 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 139 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 140 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 142 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 143 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 144 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 145 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 146 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 147 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 148 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 149 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 150 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 151 IRQ_TYPE_EDGE_RISING>; + clocks = <&clkgpio>; + clock-names = "gpio"; + ti,ngpio = <32>; + ti,davinci-gpio-unbanked = <32>; + }; + + - | + wkup_gpio0: gpio0@42110000 { + compatible = "ti,am654-gpio", "ti,keystone-gpio"; + reg = <0x42110000 0x100>; + gpio-controller; + #gpio-cells = <2>; + interrupt-parent = <&intr_wkup_gpio>; + interrupts = <60>, <61>, <62>, <63>; + interrupt-controller; + #interrupt-cells = <2>; + ti,ngpio = <56>; + ti,davinci-gpio-unbanked = <0>; + clocks = <&k3_clks 59 0>; + clock-names = "gpio"; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-omap.txt b/Documentation/devicetree/bindings/gpio/gpio-omap.txt deleted file mode 100644 index e57b2cb28f6c..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-omap.txt +++ /dev/null @@ -1,45 +0,0 @@ -OMAP GPIO controller bindings - -Required properties: -- compatible: - - "ti,omap2-gpio" for OMAP2 controllers - - "ti,omap3-gpio" for OMAP3 controllers - - "ti,omap4-gpio" for OMAP4 controllers -- reg : Physical base address of the controller and length of memory mapped - region. -- gpio-controller : Marks the device node as a GPIO controller. -- #gpio-cells : Should be two. - - first cell is the pin number - - second cell is used to specify optional parameters (unused) -- interrupt-controller: Mark the device node as an interrupt controller. -- #interrupt-cells : Should be 2. - The first cell is the GPIO number. - The second cell is used to specify flags: - bits[3:0] trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- interrupts : The interrupt the controller is rising as output when an - interrupt occures - -OMAP specific properties: -- ti,hwmods: Name of the hwmod associated to the GPIO: - "gpio<X>", <X> being the 1-based instance number - from the HW spec. -- ti,gpio-always-on: Indicates if a GPIO bank is always powered and - so will never lose its logic state. - - -Example: - -gpio0: gpio@44e07000 { - compatible = "ti,omap4-gpio"; - reg = <0x44e07000 0x1000>; - ti,hwmods = "gpio1"; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - interrupts = <96>; -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt b/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt deleted file mode 100644 index a482455a205b..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-pcf857x.txt +++ /dev/null @@ -1,69 +0,0 @@ -* PCF857x-compatible I/O expanders - -The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be -driven high by a pull-up current source or driven low to ground. This combines -the direction and output level into a single bit per line, which can't be read -back. We can't actually know at initialization time whether a line is configured -(a) as output and driving the signal low/high, or (b) as input and reporting a -low/high value, without knowing the last value written since the chip came out -of reset (if any). The only reliable solution for setting up line direction is -thus to do it explicitly. - -Required Properties: - - - compatible: should be one of the following. - - "maxim,max7328": For the Maxim MAX7378 - - "maxim,max7329": For the Maxim MAX7329 - - "nxp,pca8574": For the NXP PCA8574 - - "nxp,pca8575": For the NXP PCA8575 - - "nxp,pca9670": For the NXP PCA9670 - - "nxp,pca9671": For the NXP PCA9671 - - "nxp,pca9672": For the NXP PCA9672 - - "nxp,pca9673": For the NXP PCA9673 - - "nxp,pca9674": For the NXP PCA9674 - - "nxp,pca9675": For the NXP PCA9675 - - "nxp,pcf8574": For the NXP PCF8574 - - "nxp,pcf8574a": For the NXP PCF8574A - - "nxp,pcf8575": For the NXP PCF8575 - - - reg: I2C slave address. - - - gpio-controller: Marks the device node as a gpio controller. - - #gpio-cells: Should be 2. The first cell is the GPIO number and the second - cell specifies GPIO flags, as defined in <dt-bindings/gpio/gpio.h>. Only the - GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW flags are supported. - -Optional Properties: - - - lines-initial-states: Bitmask that specifies the initial state of each - line. When a bit is set to zero, the corresponding line will be initialized to - the input (pulled-up) state. When the bit is set to one, the line will be - initialized the low-level output state. If the property is not specified - all lines will be initialized to the input state. - - The I/O expander can detect input state changes, and thus optionally act as - an interrupt controller. When the expander interrupt line is connected all the - following properties must be set. For more information please see the - interrupt controller device tree bindings documentation available at - Documentation/devicetree/bindings/interrupt-controller/interrupts.txt. - - - interrupt-controller: Identifies the node as an interrupt controller. - - #interrupt-cells: Number of cells to encode an interrupt source, shall be 2. - - interrupts: Interrupt specifier for the controllers interrupt. - - -Please refer to gpio.txt in this directory for details of the common GPIO -bindings used by client devices. - -Example: PCF8575 I/O expander node - - pcf8575: gpio@20 { - compatible = "nxp,pcf8575"; - reg = <0x20>; - interrupt-parent = <&irqpin2>; - interrupts = <3 0>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt deleted file mode 100644 index 78458adbf4b7..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.txt +++ /dev/null @@ -1,42 +0,0 @@ -Lantiq SoC Serial To Parallel (STP) GPIO controller - -The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a -peripheral controller used to drive external shift register cascades. At most -3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem -to drive the 2 LSBs of the cascade automatically. - - -Required properties: -- compatible : Should be "lantiq,gpio-stp-xway" -- reg : Address and length of the register set for the device -- #gpio-cells : Should be two. The first cell is the pin number and - the second cell is used to specify optional parameters (currently - unused). -- gpio-controller : Marks the device node as a gpio controller. - -Optional properties: -- lantiq,shadow : The default value that we shall assume as already set on the - shift register cascade. -- lantiq,groups : Set the 3 bit mask to select which of the 3 groups are enabled - in the shift register cascade. -- lantiq,dsl : The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit - property can enable this feature. -- lantiq,phy1 : The gphy1 core can control 3 bits of the gpio cascade. -- lantiq,phy2 : The gphy2 core can control 3 bits of the gpio cascade. -- lantiq,rising : use rising instead of falling edge for the shift register - -Example: - -gpio1: stp@e100bb0 { - compatible = "lantiq,gpio-stp-xway"; - reg = <0xE100BB0 0x40>; - #gpio-cells = <2>; - gpio-controller; - - lantiq,shadow = <0xffff>; - lantiq,groups = <0x7>; - lantiq,dsl = <0x3>; - lantiq,phy1 = <0x7>; - lantiq,phy2 = <0x7>; - /* lantiq,rising; */ -}; diff --git a/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml new file mode 100644 index 000000000000..d565c4b63dbf --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-stp-xway.yaml @@ -0,0 +1,99 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-stp-xway.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Lantiq SoC Serial To Parallel (STP) GPIO controller + +description: | + The Serial To Parallel (STP) is found on MIPS based Lantiq socs. It is a + peripheral controller used to drive external shift register cascades. At most + 3 groups of 8 bits can be driven. The hardware is able to allow the DSL modem + and Ethernet PHYs to drive some bytes of the cascade automatically. + +maintainers: + - John Crispin <john@phrozen.org> + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + const: lantiq,gpio-stp-xway + + reg: + maxItems: 1 + + gpio-controller: true + + "#gpio-cells": + description: + The first cell is the pin number and the second cell is used to specify + consumer flags. + const: 2 + + lantiq,shadow: + description: + The default value that we shall assume as already set on the + shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x000000 + maximum: 0xffffff + + lantiq,groups: + description: + Set the 3 bit mask to select which of the 3 groups are enabled + in the shift register cascade. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + + lantiq,dsl: + description: + The dsl core can control the 2 LSBs of the gpio cascade. This 2 bit + property can enable this feature. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x3 + + lantiq,rising: + description: + Use rising instead of falling edge for the shift register. + type: boolean + +patternProperties: + "^lantiq,phy[1-4]$": + description: + The gphy core can control 3 bits of the gpio cascade. In the xRX200 family + phy[1-2] are available, in xRX330 phy[1-3] and in XRX330 phy[1-4]. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x0 + maximum: 0x7 + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio@e100bb0 { + compatible = "lantiq,gpio-stp-xway"; + reg = <0xE100BB0 0x40>; + #gpio-cells = <2>; + gpio-controller; + + pinctrl-0 = <&stp_pins>; + pinctrl-names = "default"; + + lantiq,shadow = <0xffffff>; + lantiq,groups = <0x7>; + lantiq,dsl = <0x3>; + lantiq,phy1 = <0x7>; + lantiq,phy2 = <0x7>; + }; +... diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt b/Documentation/devicetree/bindings/gpio/gpio-zynq.txt deleted file mode 100644 index f693e82b4c0f..000000000000 --- a/Documentation/devicetree/bindings/gpio/gpio-zynq.txt +++ /dev/null @@ -1,36 +0,0 @@ -Xilinx Zynq GPIO controller Device Tree Bindings -------------------------------------------- - -Required properties: -- #gpio-cells : Should be two - - First cell is the GPIO line number - - Second cell is used to specify optional - parameters (unused) -- compatible : Should be "xlnx,zynq-gpio-1.0" or - "xlnx,zynqmp-gpio-1.0" or "xlnx,versal-gpio-1.0 - or "xlnx,pmc-gpio-1.0 -- clocks : Clock specifier (see clock bindings for details) -- gpio-controller : Marks the device node as a GPIO controller. -- interrupts : Interrupt specifier (see interrupt bindings for - details) -- interrupt-controller : Marks the device node as an interrupt controller. -- #interrupt-cells : Should be 2. The first cell is the GPIO number. - The second cell bits[3:0] is used to specify trigger type and level flags: - 1 = low-to-high edge triggered. - 2 = high-to-low edge triggered. - 4 = active high level-sensitive. - 8 = active low level-sensitive. -- reg : Address and length of the register set for the device - -Example: - gpio@e000a000 { - #gpio-cells = <2>; - compatible = "xlnx,zynq-gpio-1.0"; - clocks = <&clkc 42>; - gpio-controller; - interrupt-parent = <&intc>; - interrupts = <0 20 4>; - interrupt-controller; - #interrupt-cells = <2>; - reg = <0xe000a000 0x1000>; - }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml new file mode 100644 index 000000000000..378da2649e66 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/gpio-zynq.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/gpio-zynq.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq GPIO controller Device Tree Bindings + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +properties: + compatible: + const: xlnx,zynq-gpio-1.0 + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + interrupts: + maxItems: 1 + + gpio-controller: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - "#gpio-cells" + - interrupts + - gpio-controller + - interrupt-controller + - "#interrupt-cells" + - clocks + +additionalProperties: false + +examples: + - | + gpio@e000a000 { + #gpio-cells = <2>; + compatible = "xlnx,zynq-gpio-1.0"; + clocks = <&clkc 42>; + gpio-controller; + interrupt-parent = <&intc>; + interrupts = <0 20 4>; + interrupt-controller; + #interrupt-cells = <2>; + reg = <0xe000a000 0x1000>; + }; diff --git a/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml new file mode 100644 index 000000000000..d38de8144656 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/idt,32434-gpio.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/idt,32434-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: IDT 79RC32434 GPIO controller + +maintainers: + - Thomas Bogendoerfer <tsbogend@alpha.franken.de> + +properties: + compatible: + const: idt,32434-gpio + + reg: + maxItems: 2 + + reg-names: + items: + - const: gpio + - const: pic + + gpio-controller: true + + "#gpio-cells": + const: 2 + + ngpios: + minimum: 1 + maximum: 32 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + gpio0: gpio@50004 { + compatible = "idt,32434-gpio"; + reg = <0x50004 0x10>, <0x38030 0x0c>; + reg-names = "gpio", "pic"; + + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&cpuintc>; + interrupts = <6>; + + gpio-controller; + #gpio-cells = <2>; + + ngpios = <14>; + }; diff --git a/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml new file mode 100644 index 000000000000..f0ff66c4c74e --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/nxp,pcf8575.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/nxp,pcf8575.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PCF857x-compatible I/O expanders + +maintainers: + - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> + +description: + The PCF857x-compatible chips have "quasi-bidirectional" I/O lines that can be + driven high by a pull-up current source or driven low to ground. This + combines the direction and output level into a single bit per line, which + can't be read back. We can't actually know at initialization time whether a + line is configured (a) as output and driving the signal low/high, or (b) as + input and reporting a low/high value, without knowing the last value written + since the chip came out of reset (if any). The only reliable solution for + setting up line direction is thus to do it explicitly. + +properties: + compatible: + enum: + - maxim,max7328 + - maxim,max7329 + - nxp,pca8574 + - nxp,pca8575 + - nxp,pca9670 + - nxp,pca9671 + - nxp,pca9672 + - nxp,pca9673 + - nxp,pca9674 + - nxp,pca9675 + - nxp,pcf8574 + - nxp,pcf8574a + - nxp,pcf8575 + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + description: + The first cell is the GPIO number and the second cell specifies GPIO + flags, as defined in <dt-bindings/gpio/gpio.h>. Only the GPIO_ACTIVE_HIGH + and GPIO_ACTIVE_LOW flags are supported. + + lines-initial-states: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Bitmask that specifies the initial state of each line. + When a bit is set to zero, the corresponding line will be initialized to + the input (pulled-up) state. + When the bit is set to one, the line will be initialized to the + low-level output state. + If the property is not specified all lines will be initialized to the + input state. + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + wakeup-source: true + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pcf8575: gpio@20 { + compatible = "nxp,pcf8575"; + reg = <0x20>; + interrupt-parent = <&irqpin2>; + interrupts = <3 0>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt deleted file mode 100644 index f9231df17c2b..000000000000 --- a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.txt +++ /dev/null @@ -1,32 +0,0 @@ -Rockchip RK3328 GRF (General Register Files) GPIO controller. - -In Rockchip RK3328, the output only GPIO_MUTE pin, originally for codec mute -control, can also be used for general purpose. It is manipulated by the -GRF_SOC_CON10 register in GRF. Aside from the GPIO_MUTE pin, the HDMI pins can -also be set in the same way. - -Currently this GPIO controller only supports the mute pin. If needed in the -future, the HDMI pins support can also be added. - -Required properties: -- compatible: Should contain "rockchip,rk3328-grf-gpio". -- gpio-controller: Marks the device node as a gpio controller. -- #gpio-cells: Should be 2. The first cell is the pin number and - the second cell is used to specify the gpio polarity: - 0 = Active high, - 1 = Active low. - -Example: - - grf: syscon@ff100000 { - compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd"; - - grf_gpio: grf-gpio { - compatible = "rockchip,rk3328-grf-gpio"; - gpio-controller; - #gpio-cells = <2>; - }; - }; - -Note: The grf_gpio node should be declared as the child of the GRF (General -Register File) node. The GPIO_MUTE pin is referred to as <&grf_gpio 0>. diff --git a/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml new file mode 100644 index 000000000000..d8cce73ea0ae --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/rockchip,rk3328-grf-gpio.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/rockchip,rk3328-grf-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip RK3328 General Register Files GPIO controller + +description: + The Rockchip RK3328 General Register File (GRF) outputs only the + GPIO_MUTE pin, originally for codec mute control, but it can also be used + for general purpose. It is manipulated by the GRF_SOC_CON10 register. + If needed in the future support for the HDMI pins can also be added. + The GPIO node should be declared as the child of the GRF node. + + The GPIO_MUTE pin is referred to in the format + + <&grf_gpio 0 GPIO_ACTIVE_LOW> + + The first cell is the pin number and + the second cell is used to specify the GPIO polarity + 0 = Active high + 1 = Active low + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + const: rockchip,rk3328-grf-gpio + + gpio-controller: true + + "#gpio-cells": + const: 2 + +required: + - compatible + - gpio-controller + - "#gpio-cells" + +additionalProperties: false + +examples: + - | + grf_gpio: gpio { + compatible = "rockchip,rk3328-grf-gpio"; + gpio-controller; + #gpio-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml new file mode 100644 index 000000000000..7087e4a5013f --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/ti,omap-gpio.yaml @@ -0,0 +1,108 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/ti,omap-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: OMAP GPIO controller bindings + +maintainers: + - Grygorii Strashko <grygorii.strashko@ti.com> + +description: | + The general-purpose interface combines general-purpose input/output (GPIO) banks. + Each GPIO banks provides up to 32 dedicated general-purpose pins with input + and output capabilities; interrupt generation in active mode and wake-up + request generation in idle mode upon the detection of external events. + +properties: + compatible: + oneOf: + - enum: + - ti,omap2-gpio + - ti,omap3-gpio + - ti,omap4-gpio + - items: + - const: ti,am4372-gpio + - const: ti,omap4-gpio + + reg: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + maxItems: 1 + + gpio-ranges: true + + gpio-line-names: + minItems: 1 + maxItems: 32 + + ti,gpio-always-on: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicates if a GPIO bank is always powered and will never lose its logic state. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + description: + Name of the hwmod associated with the GPIO. Needed on some legacy OMAP + SoCs which have not been converted to the ti,sysc interconnect hierarachy. + + ti,no-reset-on-init: + $ref: /schemas/types.yaml#/definitions/flag + deprecated: true + description: + Do not reset on init. Used with ti,hwmods on some legacy OMAP SoCs which + have not been converted to the ti,sysc interconnect hierarachy. + +patternProperties: + "^(.+-hog(-[0-9]+)?)$": + type: object + + required: + - gpio-hog + +required: + - compatible + - reg + - gpio-controller + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + gpio0: gpio@0 { + compatible = "ti,omap4-gpio"; + reg = <0x0 0x1000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + interrupts = <96>; + ti,gpio-always-on; + + ls-buf-en-hog { + gpio-hog; + gpios = <10 GPIO_ACTIVE_HIGH>; + output-high; + line-name = "LS_BUF_EN"; + }; + }; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 894ba217ab32..0f73f436bea7 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -17,6 +17,7 @@ properties: items: - enum: - amlogic,meson-g12a-mali + - mediatek,mt8183-mali - realtek,rtd1619-mali - rockchip,px30-mali - const: arm,mali-bifrost # Mali Bifrost GPU model/revision is fully discoverable @@ -41,10 +42,13 @@ properties: mali-supply: true + sram-supply: true + operating-points-v2: true power-domains: - maxItems: 1 + minItems: 1 + maxItems: 3 resets: maxItems: 2 @@ -89,6 +93,30 @@ allOf: then: required: - resets + - if: + properties: + compatible: + contains: + const: mediatek,mt8183-mali + then: + properties: + power-domains: + minItems: 3 + power-domain-names: + items: + - const: core0 + - const: core1 + - const: core2 + + required: + - sram-supply + - power-domains + - power-domain-names + else: + properties: + power-domains: + maxItems: 1 + sram-supply: false examples: - | diff --git a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml index 9d72264fa90a..e6485f7b046f 100644 --- a/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml +++ b/Documentation/devicetree/bindings/gpu/brcm,bcm-v3d.yaml @@ -34,7 +34,6 @@ properties: - enum: [ bridge, gca ] - enum: [ bridge, gca ] minItems: 2 - maxItems: 4 interrupts: items: diff --git a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml index 3ed172629974..93e7244cdc0e 100644 --- a/Documentation/devicetree/bindings/gpu/vivante,gc.yaml +++ b/Documentation/devicetree/bindings/gpu/vivante,gc.yaml @@ -36,7 +36,6 @@ properties: - description: AHB/slave interface clock (only required if GPU can gate slave interface independently) minItems: 1 - maxItems: 4 clock-names: items: diff --git a/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml new file mode 100644 index 000000000000..10e5a53e447b --- /dev/null +++ b/Documentation/devicetree/bindings/hwlock/allwinner,sun6i-a31-hwspinlock.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwlock/allwinner,sun6i-a31-hwspinlock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SUN6I hardware spinlock driver for Allwinner sun6i compatible SoCs + +maintainers: + - Wilken Gottwalt <wilken.gottwalt@posteo.net> + +description: + The hardware unit provides semaphores between the ARM cores and the embedded + companion core on the SoC. + +properties: + compatible: + const: allwinner,sun6i-a31-hwspinlock + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/sun8i-a23-a33-ccu.h> + #include <dt-bindings/reset/sun8i-a23-a33-ccu.h> + + hwlock@1c18000 { + compatible = "allwinner,sun6i-a31-hwspinlock"; + reg = <0x01c18000 0x1000>; + clocks = <&ccu CLK_BUS_SPINLOCK>; + resets = <&ccu RST_BUS_SPINLOCK>; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml new file mode 100644 index 000000000000..ea643e6c3ef5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/aspeed,i2c.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/aspeed,i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED I2C on the AST24XX, AST25XX, and AST26XX SoCs Device Tree Bindings + +maintainers: + - Rayn Chen <rayn_chen@aspeedtech.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + enum: + - aspeed,ast2400-i2c-bus + - aspeed,ast2500-i2c-bus + - aspeed,ast2600-i2c-bus + + reg: + minItems: 1 + items: + - description: address offset and range of bus + - description: address offset and range of bus buffer + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + description: + root clock of bus, should reference the APB + clock in the second cell + + resets: + maxItems: 1 + + bus-frequency: + minimum: 500 + maximum: 4000000 + default: 100000 + description: frequency of the bus clock in Hz defaults to 100 kHz when not + specified + + multi-master: + type: boolean + description: + states that there is another master active on this bus + +required: + - reg + - compatible + - clocks + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/aspeed-clock.h> + i2c0: i2c-bus@40 { + #address-cells = <1>; + #size-cells = <0>; + #interrupt-cells = <1>; + compatible = "aspeed,ast2500-i2c-bus"; + reg = <0x40 0x40>; + clocks = <&syscon ASPEED_CLK_APB>; + resets = <&syscon ASPEED_RESET_I2C>; + bus-frequency = <100000>; + interrupts = <0>; + interrupt-parent = <&i2c_ic>; + }; diff --git a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml index edbca2476128..7070c04469ed 100644 --- a/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/brcm,brcmstb-i2c.yaml @@ -21,7 +21,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: BSC register range - description: Auto-I2C register range diff --git a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt b/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt deleted file mode 100644 index b47f6ccb196a..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-aspeed.txt +++ /dev/null @@ -1,49 +0,0 @@ -Device tree configuration for the I2C busses on the AST24XX, AST25XX, and AST26XX SoCs. - -Required Properties: -- #address-cells : should be 1 -- #size-cells : should be 0 -- reg : address offset and range of bus -- compatible : should be "aspeed,ast2400-i2c-bus" - or "aspeed,ast2500-i2c-bus" - or "aspeed,ast2600-i2c-bus" -- clocks : root clock of bus, should reference the APB - clock in the second cell -- resets : phandle to reset controller with the reset number in - the second cell -- interrupts : interrupt number - -Optional Properties: -- bus-frequency : frequency of the bus clock in Hz defaults to 100 kHz when not - specified -- multi-master : states that there is another master active on this bus. - -Example: - -i2c { - compatible = "simple-bus"; - #address-cells = <1>; - #size-cells = <1>; - ranges = <0 0x1e78a000 0x1000>; - - i2c_ic: interrupt-controller@0 { - #interrupt-cells = <1>; - compatible = "aspeed,ast2400-i2c-ic"; - reg = <0x0 0x40>; - interrupts = <12>; - interrupt-controller; - }; - - i2c0: i2c-bus@40 { - #address-cells = <1>; - #size-cells = <0>; - #interrupt-cells = <1>; - reg = <0x40 0x40>; - compatible = "aspeed,ast2400-i2c-bus"; - clocks = <&syscon ASPEED_CLK_APB>; - resets = <&syscon ASPEED_RESET_I2C>; - bus-frequency = <100000>; - interrupts = <0>; - interrupt-parent = <&i2c_ic>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt index b745f3706120..6590501c53d4 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-davinci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-davinci.txt @@ -8,7 +8,7 @@ Required properties: - reg : Offset and length of the register set for the device - clocks: I2C functional clock phandle. For 66AK2G this property should be set per binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: @@ -17,7 +17,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains: Should contain a phandle to a PM domain provider node and an args specifier containing the I2C device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Recommended properties : - interrupts : standard interrupt property. diff --git a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt index 81b5d55086fa..86b2e433a969 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.txt @@ -27,7 +27,7 @@ Required properties: - i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C parents. -Furthermore, I2C mux properties and child nodes. See i2c-mux.txt in this +Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this directory. Example: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 7f0194fdd0cc..5ea216ae7084 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -15,6 +15,7 @@ Required properties: "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 "mediatek,mt8192-i2c": for MediaTek MT8192 + "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 - reg: physical base address of the controller and dma base, length of memory mapped region. @@ -32,6 +33,7 @@ Optional properties: - mediatek,have-pmic: platform can control i2c form special pmic side. Only mt6589 and mt8135 support this feature. - mediatek,use-push-pull: IO config use push-pull mode. + - vbus-supply: phandle to the regulator that provides power to SCL/SDA. Example: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt index 21da3ecbb370..d4cf10582a26 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpio.txt @@ -22,8 +22,8 @@ Required properties: - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. - mux-gpios: list of gpios used to control the muxer -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - idle-state: value to set the muxer to when idle. When no value is @@ -62,7 +62,6 @@ Example: reg = <0x3c>; pwms = <&pwm 4 3000>; reset-gpios = <&gpio2 7 1>; - reset-active-low; }; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt deleted file mode 100644 index 8b444b94e92f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.txt +++ /dev/null @@ -1,99 +0,0 @@ -General Purpose I2C Bus Mux - -This binding describes an I2C bus multiplexer that uses a mux controller -from the mux subsystem to route the I2C signals. - - .-----. .-----. - | dev | | dev | - .------------. '-----' '-----' - | SoC | | | - | | .--------+--------' - | .------. | .------+ child bus A, on MUX value set to 0 - | | I2C |-|--| Mux | - | '------' | '--+---+ child bus B, on MUX value set to 1 - | .------. | | '----------+--------+--------. - | | MUX- | | | | | | - | | Ctrl |-|-----+ .-----. .-----. .-----. - | '------' | | dev | | dev | | dev | - '------------' '-----' '-----' '-----' - -Required properties: -- compatible: i2c-mux -- i2c-parent: The phandle of the I2C bus that this multiplexer's master-side - port is connected to. -- mux-controls: The phandle of the mux controller to use for operating the - mux. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. The sub-bus number - is also the mux-controller state described in ../mux/mux-controller.txt - -Optional properties: -- mux-locked: If present, explicitly allow unrelated I2C transactions on the - parent I2C adapter at these times: - + during setup of the multiplexer - + between setup of the multiplexer and the child bus I2C transaction - + between the child bus I2C transaction and releasing of the multiplexer - + during releasing of the multiplexer - However, I2C transactions to devices behind all I2C multiplexers connected - to the same parent adapter that this multiplexer is connected to are blocked - for the full duration of the complete multiplexed I2C transaction (i.e. - including the times covered by the above list). - If mux-locked is not present, the multiplexer is assumed to be parent-locked. - This means that no unrelated I2C transactions are allowed on the parent I2C - adapter for the complete multiplexed I2C transaction. - The properties of mux-locked and parent-locked multiplexers are discussed - in more detail in Documentation/i2c/i2c-topology.rst. - -For each i2c child node, an I2C child bus will be created. They will -be numbered based on their order in the device tree. - -Whenever an access is made to a device on a child bus, the value set -in the relevant node's reg property will be set as the state in the -mux controller. - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - i2c-mux { - compatible = "i2c-mux"; - mux-locked; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@1 { - reg = <1>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - compatible = "solomon,ssd1307fb-i2c"; - reg = <0x3c>; - pwms = <&pwm 4 3000>; - reset-gpios = <&gpio2 7 1>; - reset-active-low; - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - compatible = "nxp,pca9555"; - gpio-controller; - #gpio-cells = <2>; - reg = <0x20>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml new file mode 100644 index 000000000000..9b0603a72f40 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-gpmux.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-gpmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: General Purpose I2C Bus Mux + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + This binding describes an I2C bus multiplexer that uses a mux controller + from the mux subsystem to route the I2C signals. + + .-----. .-----. + | dev | | dev | + .------------. '-----' '-----' + | SoC | | | + | | .--------+--------' + | .------. | .------+ child bus A, on MUX value set to 0 + | | I2C |-|--| Mux | + | '------' | '--+---+ child bus B, on MUX value set to 1 + | .------. | | '----------+--------+--------. + | | MUX- | | | | | | + | | Ctrl |-|-----+ .-----. .-----. .-----. + | '------' | | dev | | dev | | dev | + '------------' '-----' '-----' '-----' + + + +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + +properties: + compatible: + const: i2c-mux + + i2c-parent: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the I2C bus that this multiplexer's master-side port is + connected to. + + mux-controls: + maxItems: 1 + description: + The mux-controller states are the I2C sub-bus numbers. + + mux-locked: + type: boolean + description: | + Explicitly allow unrelated I2C transactions on the parent I2C adapter at + these times: + - during setup of the multiplexer + - between setup of the multiplexer and the child bus I2C transaction + - between the child bus I2C transaction and releasing of the multiplexer + - during releasing of the multiplexer + + However, I2C transactions to devices behind all I2C multiplexers connected + to the same parent adapter that this multiplexer is connected to are blocked + for the full duration of the complete multiplexed I2C transaction (i.e. + including the times covered by the above list). + If mux-locked is not present, the multiplexer is assumed to be parent-locked. + This means that no unrelated I2C transactions are allowed on the parent I2C + adapter for the complete multiplexed I2C transaction. + The properties of mux-locked and parent-locked multiplexers are discussed + in more detail in Documentation/i2c/i2c-topology.rst. + +required: + - compatible + - i2c-parent + - mux-controls + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + i2c-mux { + compatible = "i2c-mux"; + mux-locked; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@1 { + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt index 8b1e49cdce3f..29c4550c9782 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-ltc4306.txt @@ -8,8 +8,8 @@ Required Properties: The following required properties are defined externally: - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. + - Standard I2C mux properties. See i2c-mux.yaml in this directory. + - I2C child bus nodes. See i2c-mux.yaml in this directory. Optional Properties: diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt deleted file mode 100644 index 7abda506b828..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt +++ /dev/null @@ -1,74 +0,0 @@ -* NXP PCA954x I2C bus switch - -The driver supports NXP PCA954x and PCA984x I2C mux/switch devices. - -Required Properties: - - - compatible: Must contain one of the following. - "nxp,pca9540", - "nxp,pca9542", - "nxp,pca9543", - "nxp,pca9544", - "nxp,pca9545", - "nxp,pca9546", "nxp,pca9846", - "nxp,pca9547", "nxp,pca9847", - "nxp,pca9548", "nxp,pca9848", - "nxp,pca9849" - - - reg: The I2C address of the device. - - The following required properties are defined externally: - - - Standard I2C mux properties. See i2c-mux.txt in this directory. - - I2C child bus nodes. See i2c-mux.txt in this directory. - -Optional Properties: - - - reset-gpios: Reference to the GPIO connected to the reset input. - - idle-state: if present, overrides i2c-mux-idle-disconnect, - Please refer to Documentation/devicetree/bindings/mux/mux-controller.txt - - i2c-mux-idle-disconnect: Boolean; if defined, forces mux to disconnect all - children in idle state. This is necessary for example, if there are several - multiplexers on the bus and the devices behind them use same I2C addresses. - - interrupts: Interrupt mapping for IRQ. - - interrupt-controller: Marks the device node as an interrupt controller. - - #interrupt-cells : Should be two. - - first cell is the pin number - - second cell is used to specify flags. - See also Documentation/devicetree/bindings/interrupt-controller/interrupts.txt - -Example: - - i2c-switch@74 { - compatible = "nxp,pca9548"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x74>; - - interrupt-parent = <&ipic>; - interrupts = <17 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #interrupt-cells = <2>; - - i2c@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <2>; - - eeprom@54 { - compatible = "atmel,24c08"; - reg = <0x54>; - }; - }; - - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - rtc@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml new file mode 100644 index 000000000000..9f1726d0356b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.yaml @@ -0,0 +1,110 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux-pca954x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP PCA954x I2C bus switch + +maintainers: + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: + The binding supports NXP PCA954x and PCA984x I2C mux/switch devices. + +allOf: + - $ref: /schemas/i2c/i2c-mux.yaml# + +properties: + compatible: + oneOf: + - enum: + - nxp,pca9540 + - nxp,pca9542 + - nxp,pca9543 + - nxp,pca9544 + - nxp,pca9545 + - nxp,pca9546 + - nxp,pca9547 + - nxp,pca9548 + - nxp,pca9846 + - nxp,pca9847 + - nxp,pca9848 + - nxp,pca9849 + - items: + - const: nxp,pca9646 + - const: nxp,pca9546 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#interrupt-cells": + const: 2 + + interrupt-controller: true + + reset-gpios: + maxItems: 1 + + i2c-mux-idle-disconnect: + type: boolean + description: Forces mux to disconnect all children in idle state. This is + necessary for example, if there are several multiplexers on the bus and + the devices behind them use same I2C addresses. + + idle-state: + description: if present, overrides i2c-mux-idle-disconnect + $ref: /schemas/mux/mux-controller.yaml#/properties/idle-state + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@74 { + compatible = "nxp,pca9548"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x74>; + + interrupt-parent = <&ipic>; + interrupts = <17 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #interrupt-cells = <2>; + + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + eeprom@54 { + compatible = "atmel,24c08"; + reg = <0x54>; + }; + }; + + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt index 33119a98e144..997a287ed3f6 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-pinctrl.txt @@ -28,9 +28,9 @@ Also required are: * Standard pinctrl properties that specify the pin mux state for each child bus. See ../pinctrl/pinctrl-bindings.txt. -* Standard I2C mux properties. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. For each named state defined in the pinctrl-names property, an I2C child bus will be created. I2C child bus numbers are assigned based on the index into diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt index de00d7fc450b..b9d9755e4172 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mux-reg.txt @@ -7,8 +7,8 @@ Required properties: - compatible: i2c-mux-reg - i2c-parent: The phandle of the I2C bus that this multiplexer's master-side port is connected to. -* Standard I2C mux properties. See i2c-mux.txt in this directory. -* I2C child bus nodes. See i2c-mux.txt in this directory. +* Standard I2C mux properties. See i2c-mux.yaml in this directory. +* I2C child bus nodes. See i2c-mux.yaml in this directory. Optional properties: - reg: this pair of <offset size> specifies the register to control the mux. diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.txt b/Documentation/devicetree/bindings/i2c/i2c-mux.txt deleted file mode 100644 index b38f58a1c878..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-mux.txt +++ /dev/null @@ -1,73 +0,0 @@ -Common i2c bus multiplexer/switch properties. - -An i2c bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an i2c bus -multiplexer/switch will have one child node for each child bus. - -Optional properties: -- #address-cells = <1>; - This property is required if the i2c-mux child node does not exist. - -- #size-cells = <0>; - This property is required if the i2c-mux child node does not exist. - -- i2c-mux - For i2c multiplexers/switches that have child nodes that are a mixture - of both i2c child busses and other child nodes, the 'i2c-mux' subnode - can be used for populating the i2c child busses. If an 'i2c-mux' - subnode is present, only subnodes of this will be considered as i2c - child busses. - -Required properties for the i2c-mux child node: -- #address-cells = <1>; -- #size-cells = <0>; - -Required properties for i2c child bus nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - -Optional properties for i2c child bus nodes: -- Other properties specific to the multiplexer/switch hardware. -- Child nodes conforming to i2c bus binding - - -Example : - - /* - An NXP pca9548 8 channel I2C multiplexer at address 0x70 - with two NXP pca8574 GPIO expanders attached, one each to - ports 3 and 4. - */ - - mux@70 { - compatible = "nxp,pca9548"; - reg = <0x70>; - #address-cells = <1>; - #size-cells = <0>; - - i2c@3 { - #address-cells = <1>; - #size-cells = <0>; - reg = <3>; - - gpio1: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - i2c@4 { - #address-cells = <1>; - #size-cells = <0>; - reg = <4>; - - gpio2: gpio@38 { - compatible = "nxp,pca8574"; - reg = <0x38>; - #gpio-cells = <2>; - gpio-controller; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mux.yaml b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml new file mode 100644 index 000000000000..24cac36037f5 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/i2c-mux.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/i2c-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common i2c bus multiplexer/switch properties. + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + An i2c bus multiplexer/switch will have several child busses that are numbered + uniquely in a device dependent manner. The nodes for an i2c bus + multiplexer/switch will have one child node for each child bus. + + For i2c multiplexers/switches that have child nodes that are a mixture of both + i2c child busses and other child nodes, the 'i2c-mux' subnode can be used for + populating the i2c child busses. If an 'i2c-mux' subnode is present, only + subnodes of this will be considered as i2c child busses. + +properties: + $nodename: + pattern: '^(i2c-?)?mux' + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^i2c@[0-9a-f]+$': + $ref: /schemas/i2c/i2c-controller.yaml + unevaluatedProperties: false + + properties: + reg: + description: The mux selector sub-bus number for the child I2C bus. + maxItems: 1 + +additionalProperties: true + +examples: + - | + /* + * An NXP pca9548 8 channel I2C multiplexer at address 0x70 + * with two NXP pca8574 GPIO expanders attached, one each to + * ports 3 and 4. + */ + i2c { + #address-cells = <1>; + #size-cells = <0>; + + i2c-mux@70 { + compatible = "nxp,pca9548"; + reg = <0x70>; + #address-cells = <1>; + #size-cells = <0>; + + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + i2c@4 { + #address-cells = <1>; + #size-cells = <0>; + reg = <4>; + + gpio@20 { + compatible = "nxp,pca9555"; + gpio-controller; + #gpio-cells = <2>; + reg = <0x20>; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/i2c-omap.txt b/Documentation/devicetree/bindings/i2c/i2c-omap.txt deleted file mode 100644 index a425b91af48f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-omap.txt +++ /dev/null @@ -1,37 +0,0 @@ -I2C for OMAP platforms - -Required properties : -- compatible : Must be - "ti,omap2420-i2c" for OMAP2420 SoCs - "ti,omap2430-i2c" for OMAP2430 SoCs - "ti,omap3-i2c" for OMAP3 SoCs - "ti,omap4-i2c" for OMAP4+ SoCs - "ti,am654-i2c", "ti,omap4-i2c" for AM654 SoCs - "ti,j721e-i2c", "ti,omap4-i2c" for J721E SoCs - "ti,am64-i2c", "ti,omap4-i2c" for AM64 SoCs -- ti,hwmods : Must be "i2c<n>", n being the instance number (1-based) -- #address-cells = <1>; -- #size-cells = <0>; - -Recommended properties : -- clock-frequency : Desired I2C bus clock frequency in Hz. Otherwise - the default 100 kHz frequency will be used. - -Optional properties: -- Child nodes conforming to i2c bus binding - -Note: Current implementation will fetch base address, irq and dma -from omap hwmod data base during device registration. -Future plan is to migrate hwmod data base contents into device tree -blob so that, all the required data will be used from device tree dts -file. - -Examples : - -i2c1: i2c@0 { - compatible = "ti,omap3-i2c"; - #address-cells = <1>; - #size-cells = <0>; - ti,hwmods = "i2c1"; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt index 569b16248514..1ff6f8487a2d 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-pxa-pci-ce4100.txt @@ -71,7 +71,7 @@ This is an example which is used on FalconFalls: /* This I2C controller has one gpio controller */ gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; @@ -85,7 +85,7 @@ This is an example which is used on FalconFalls: gpio@26 { #gpio-cells = <2>; - compatible = "ti,pcf8575"; + compatible = "nxp,pcf8575"; reg = <0x26>; gpio-controller; }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt index c6668b7c66e6..7b9fc0c22eaf 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt @@ -9,6 +9,7 @@ PROPERTIES: "qcom,msm8916-cci" "qcom,msm8996-cci" "qcom,sdm845-cci" + "qcom,sm8250-cci" - reg Usage: required @@ -41,8 +42,8 @@ PROPERTIES: SUBNODES: -The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996 and -sdm845), described as subdevices named "i2c-bus@0" and "i2c-bus@1". +The CCI provides I2C masters for one (msm8916) or two i2c busses (msm8996, +sdm845 and sm8250), described as subdevices named "i2c-bus@0" and "i2c-bus@1". PROPERTIES: diff --git a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml index 7f254d79558c..5339dd4fc370 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-rk3x.yaml @@ -36,6 +36,7 @@ properties: - rockchip,px30-i2c - rockchip,rk3308-i2c - rockchip,rk3328-i2c + - rockchip,rk3568-i2c - const: rockchip,rk3399-i2c reg: diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index df41f72afc87..b864916e087f 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -89,8 +89,11 @@ wants to support one of the below features, it should adapt these bindings. - smbus states that additional SMBus restrictions and features apply to this bus. - Examples of features are SMBusHostNotify and SMBusAlert. Examples of - restrictions are more reserved addresses and timeout definitions. + An example of feature is SMBusHostNotify. Examples of restrictions are + more reserved addresses and timeout definitions. + +- smbus-alert + states that the optional SMBus-Alert feature apply to this bus. Required properties (per child device) -------------------------------------- diff --git a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml index eb72dd571def..f771c09aabfc 100644 --- a/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/marvell,mv64xxx-i2c.yaml @@ -43,14 +43,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock for the I2C bus - description: Bus clock (Only for Armada 7K/8K) clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: reg diff --git a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml index d2b401d062b9..93198d5d43a6 100644 --- a/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml +++ b/Documentation/devicetree/bindings/i2c/mellanox,i2c-mlxbf.yaml @@ -20,7 +20,6 @@ properties: reg: minItems: 3 - maxItems: 4 items: - description: Smbus block registers - description: Cause master registers diff --git a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt b/Documentation/devicetree/bindings/i2c/renesas,i2c.txt deleted file mode 100644 index 5762d2d1ab9c..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,i2c.txt +++ /dev/null @@ -1,67 +0,0 @@ -I2C for R-Car platforms - -Required properties: -- compatible: - "renesas,i2c-r8a7742" if the device is a part of a R8A7742 SoC. - "renesas,i2c-r8a7743" if the device is a part of a R8A7743 SoC. - "renesas,i2c-r8a7744" if the device is a part of a R8A7744 SoC. - "renesas,i2c-r8a7745" if the device is a part of a R8A7745 SoC. - "renesas,i2c-r8a77470" if the device is a part of a R8A77470 SoC. - "renesas,i2c-r8a774a1" if the device is a part of a R8A774A1 SoC. - "renesas,i2c-r8a774b1" if the device is a part of a R8A774B1 SoC. - "renesas,i2c-r8a774c0" if the device is a part of a R8A774C0 SoC. - "renesas,i2c-r8a774e1" if the device is a part of a R8A774E1 SoC. - "renesas,i2c-r8a7778" if the device is a part of a R8A7778 SoC. - "renesas,i2c-r8a7779" if the device is a part of a R8A7779 SoC. - "renesas,i2c-r8a7790" if the device is a part of a R8A7790 SoC. - "renesas,i2c-r8a7791" if the device is a part of a R8A7791 SoC. - "renesas,i2c-r8a7792" if the device is a part of a R8A7792 SoC. - "renesas,i2c-r8a7793" if the device is a part of a R8A7793 SoC. - "renesas,i2c-r8a7794" if the device is a part of a R8A7794 SoC. - "renesas,i2c-r8a7795" if the device is a part of a R8A7795 SoC. - "renesas,i2c-r8a7796" if the device is a part of a R8A77960 SoC. - "renesas,i2c-r8a77961" if the device is a part of a R8A77961 SoC. - "renesas,i2c-r8a77965" if the device is a part of a R8A77965 SoC. - "renesas,i2c-r8a77970" if the device is a part of a R8A77970 SoC. - "renesas,i2c-r8a77980" if the device is a part of a R8A77980 SoC. - "renesas,i2c-r8a77990" if the device is a part of a R8A77990 SoC. - "renesas,i2c-r8a77995" if the device is a part of a R8A77995 SoC. - "renesas,i2c-r8a779a0" if the device is a part of a R8A779A0 SoC. - "renesas,rcar-gen1-i2c" for a generic R-Car Gen1 compatible device. - "renesas,rcar-gen2-i2c" for a generic R-Car Gen2 or RZ/G1 compatible - device. - "renesas,rcar-gen3-i2c" for a generic R-Car Gen3 or RZ/G2 compatible - device. - "renesas,i2c-rcar" (deprecated) - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first followed - by the generic version. - -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: interrupt specifier. - -Optional properties: -- clock-frequency: desired I2C bus clock frequency in Hz. The absence of this - property indicates the default frequency 100 kHz. -- clocks: clock specifier. -- dmas: Must contain a list of two references to DMA specifiers, one for - transmission, and one for reception. -- dma-names: Must contain a list of two DMA names, "tx" and "rx". - -- i2c-scl-falling-time-ns: see i2c.txt -- i2c-scl-internal-delay-ns: see i2c.txt -- i2c-scl-rising-time-ns: see i2c.txt - -Examples : - -i2c0: i2c@e6508000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; - reg = <0 0xe6508000 0 0x40>; - interrupts = <0 287 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_I2C0>; - clock-frequency = <400000>; -}; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt deleted file mode 100644 index 5ed1ea1c7e14..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device tree configuration for Renesas EMEV2 IIC controller - -Required properties: -- compatible : "renesas,iic-emev2" -- reg : address start and address range size of device -- interrupts : specifier for the IIC controller interrupt -- clocks : phandle to the IP core SCLK -- clock-names : must be "sclk" -- #address-cells : should be <1> -- #size-cells : should be <0> - -Example: - - iic0: i2c@e0070000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "renesas,iic-emev2"; - reg = <0xe0070000 0x28>; - interrupts = <0 32 IRQ_TYPE_EDGE_RISING>; - clocks = <&iic0_sclk>; - clock-names = "sclk"; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml new file mode 100644 index 000000000000..17c1102562be --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,iic-emev2.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,iic-emev2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas EMMA Mobile EV2 IIC Interface + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + const: renesas,iic-emev2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sclk + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + iic0: i2c@e0070000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,iic-emev2"; + reg = <0xe0070000 0x28>; + interrupts = <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>; + clocks = <&iic0_sclk>; + clock-names = "sclk"; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,iic.txt b/Documentation/devicetree/bindings/i2c/renesas,iic.txt deleted file mode 100644 index 93d412832e66..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,iic.txt +++ /dev/null @@ -1,72 +0,0 @@ -Device tree configuration for Renesas IIC (sh_mobile) driver - -Required properties: -- compatible : - - "renesas,iic-r8a73a4" (R-Mobile APE6) - - "renesas,iic-r8a7740" (R-Mobile A1) - - "renesas,iic-r8a7742" (RZ/G1H) - - "renesas,iic-r8a7743" (RZ/G1M) - - "renesas,iic-r8a7744" (RZ/G1N) - - "renesas,iic-r8a7745" (RZ/G1E) - - "renesas,iic-r8a774a1" (RZ/G2M) - - "renesas,iic-r8a774b1" (RZ/G2N) - - "renesas,iic-r8a774c0" (RZ/G2E) - - "renesas,iic-r8a774e1" (RZ/G2H) - - "renesas,iic-r8a7790" (R-Car H2) - - "renesas,iic-r8a7791" (R-Car M2-W) - - "renesas,iic-r8a7792" (R-Car V2H) - - "renesas,iic-r8a7793" (R-Car M2-N) - - "renesas,iic-r8a7794" (R-Car E2) - - "renesas,iic-r8a7795" (R-Car H3) - - "renesas,iic-r8a7796" (R-Car M3-W) - - "renesas,iic-r8a77961" (R-Car M3-W+) - - "renesas,iic-r8a77965" (R-Car M3-N) - - "renesas,iic-r8a77990" (R-Car E3) - - "renesas,iic-sh73a0" (SH-Mobile AG5) - - "renesas,rcar-gen2-iic" (generic R-Car Gen2 or RZ/G1 - compatible device) - - "renesas,rcar-gen3-iic" (generic R-Car Gen3 or RZ/G2 - compatible device) - - "renesas,rmobile-iic" (generic device) - - When compatible with a generic R-Car version, nodes - must list the SoC-specific version corresponding to - the platform first followed by the generic R-Car - version. - - When compatible with "renesas,rmobile-iic" it should - be the last compatibility string listed. - - The r8a77990 (R-Car E3) and r8a774c0 (RZ/G2E) - controllers are not considered compatible with - "renesas,rcar-gen3-iic" or "renesas,rmobile-iic" - due to the absence of automatic transmission registers. - -- reg : address start and address range size of device -- interrupts : interrupt of device -- clocks : clock for device -- #address-cells : should be <1> -- #size-cells : should be <0> - -Optional properties: -- clock-frequency : frequency of bus clock in Hz. Default 100kHz if unset. -- dmas : Must contain a list of two references to DMA - specifiers, one for transmission, and one for - reception. -- dma-names : Must contain a list of two DMA names, "tx" and "rx". - - -Pinctrl properties might be needed, too. See there. - -Example: - - iic0: i2c@e6500000 { - compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", - "renesas,rmobile-iic"; - reg = <0 0xe6500000 0 0x425>; - interrupts = <0 174 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp3_clks R8A7790_CLK_IIC0>; - clock-frequency = <400000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml new file mode 100644 index 000000000000..052aad44e781 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -0,0 +1,158 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rcar-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car I2C Controller + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,i2c-r8a7778 # R-Car M1A + - renesas,i2c-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-i2c # R-Car Gen1 + + - items: + - enum: + - renesas,i2c-r8a7742 # RZ/G1H + - renesas,i2c-r8a7743 # RZ/G1M + - renesas,i2c-r8a7744 # RZ/G1N + - renesas,i2c-r8a7745 # RZ/G1E + - renesas,i2c-r8a77470 # RZ/G1C + - renesas,i2c-r8a7790 # R-Car H2 + - renesas,i2c-r8a7791 # R-Car M2-W + - renesas,i2c-r8a7792 # R-Car V2H + - renesas,i2c-r8a7793 # R-Car M2-N + - renesas,i2c-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-i2c # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,i2c-r8a774a1 # RZ/G2M + - renesas,i2c-r8a774b1 # RZ/G2N + - renesas,i2c-r8a774c0 # RZ/G2E + - renesas,i2c-r8a774e1 # RZ/G2H + - renesas,i2c-r8a7795 # R-Car H3 + - renesas,i2c-r8a7796 # R-Car M3-W + - renesas,i2c-r8a77961 # R-Car M3-W+ + - renesas,i2c-r8a77965 # R-Car M3-N + - renesas,i2c-r8a77970 # R-Car V3M + - renesas,i2c-r8a77980 # R-Car V3H + - renesas,i2c-r8a77990 # R-Car E3 + - renesas,i2c-r8a77995 # R-Car D3 + - renesas,i2c-r8a779a0 # R-Car V3U + - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + + i2c-scl-falling-time-ns: + default: 35 + description: + Number of nanoseconds the SCL signal takes to fall; t(f) in the I2C + specification. + + i2c-scl-internal-delay-ns: + default: 50 + description: + Number of nanoseconds the IP core additionally needs to setup SCL. + + i2c-scl-rising-time-ns: + default: 200 + description: + Number of nanoseconds the SCL signal takes to rise; t(r) in the I2C + specification. + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen1-i2c + - renesas,rcar-gen2-i2c + then: + properties: + dmas: false + dma-names: false + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-i2c + - renesas,rcar-gen3-i2c + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + i2c0: i2c@e6508000 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "renesas,i2c-r8a7791", "renesas,rcar-gen2-i2c"; + reg = <0xe6508000 0x40>; + interrupts = <GIC_SPI 287 IRQ_TYPE_LEVEL_HIGH>; + clock-frequency = <400000>; + clocks = <&cpg CPG_MOD 931>; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 931>; + i2c-scl-internal-delay-ns = <6>; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.txt b/Documentation/devicetree/bindings/i2c/renesas,riic.txt deleted file mode 100644 index e26fe3ad86a9..000000000000 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.txt +++ /dev/null @@ -1,32 +0,0 @@ -Device tree configuration for Renesas RIIC driver - -Required properties: -- compatible : - "renesas,riic-r7s72100" if the device is a part of a R7S72100 SoC. - "renesas,riic-r7s9210" if the device is a part of a R7S9210 SoC. - "renesas,riic-rz" for a generic RZ/A compatible device. -- reg : address start and address range size of device -- interrupts : 8 interrupts (TEI, RI, TI, SPI, STI, NAKI, ALI, TMOI) -- clock-frequency : frequency of bus clock in Hz -- #address-cells : should be <1> -- #size-cells : should be <0> - -Pinctrl properties might be needed, too. See there. - -Example: - - i2c0: i2c@fcfee000 { - compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; - reg = <0xfcfee000 0x44>; - interrupts = <0 157 IRQ_TYPE_LEVEL_HIGH>, - <0 158 IRQ_TYPE_EDGE_RISING>, - <0 159 IRQ_TYPE_EDGE_RISING>, - <0 160 IRQ_TYPE_LEVEL_HIGH>, - <0 161 IRQ_TYPE_LEVEL_HIGH>, - <0 162 IRQ_TYPE_LEVEL_HIGH>, - <0 163 IRQ_TYPE_LEVEL_HIGH>, - <0 164 IRQ_TYPE_LEVEL_HIGH>; - clock-frequency = <100000>; - #address-cells = <1>; - #size-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml new file mode 100644 index 000000000000..52d92ec7ec0b --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -0,0 +1,93 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,riic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas RZ/A and RZ/G2L I2C Bus Interface (RIIC) + +maintainers: + - Chris Brandt <chris.brandt@renesas.com> + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + items: + - enum: + - renesas,riic-r7s72100 # RZ/A1H + - renesas,riic-r7s9210 # RZ/A2M + - renesas,riic-r9a07g044 # RZ/G2{L,LC} + - const: renesas,riic-rz # RZ/A or RZ/G2L + + reg: + maxItems: 1 + + interrupts: + items: + - description: Transmit End Interrupt (TEI) + - description: Receive Data Full Interrupt (RI) + - description: Transmit Data Empty Interrupt (TI) + - description: Stop Condition Detection Interrupt (SPI) + - description: Start Condition Detection Interrupt (STI) + - description: NACK Reception Interrupt (NAKI) + - description: Arbitration-Lost Interrupt (ALI) + - description: Timeout Interrupt (TMOI) + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-frequency + - power-domains + - '#address-cells' + - '#size-cells' + +if: + properties: + compatible: + contains: + enum: + - renesas,riic-r9a07g044 +then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r7s72100-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c0: i2c@fcfee000 { + compatible = "renesas,riic-r7s72100", "renesas,riic-rz"; + reg = <0xfcfee000 0x44>; + interrupts = <GIC_SPI 157 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 158 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 159 IRQ_TYPE_EDGE_RISING>, + <GIC_SPI 160 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 161 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 162 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 163 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 164 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&mstp9_clks R7S72100_CLK_I2C0>; + clock-frequency = <100000>; + power-domains = <&cpg_clocks>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml new file mode 100644 index 000000000000..04e4ffd80bc0 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/renesas,rmobile-iic.yaml @@ -0,0 +1,149 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/renesas,rmobile-iic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile I2C Bus Interface (IIC) + +maintainers: + - Wolfram Sang <wsa+renesas@sang-engineering.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,iic-r8a73a4 # R-Mobile APE6 + - renesas,iic-r8a7740 # R-Mobile A1 + - renesas,iic-sh73a0 # SH-Mobile AG5 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a7742 # RZ/G1H + - renesas,iic-r8a7743 # RZ/G1M + - renesas,iic-r8a7744 # RZ/G1N + - renesas,iic-r8a7745 # RZ/G1E + - renesas,iic-r8a7790 # R-Car H2 + - renesas,iic-r8a7791 # R-Car M2-W + - renesas,iic-r8a7792 # R-Car V2H + - renesas,iic-r8a7793 # R-Car M2-N + - renesas,iic-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-iic # R-Car Gen2 and RZ/G1 + - const: renesas,rmobile-iic # Generic + + - items: + - enum: + - renesas,iic-r8a774a1 # RZ/G2M + - renesas,iic-r8a774b1 # RZ/G2N + - renesas,iic-r8a774c0 # RZ/G2E + - renesas,iic-r8a774e1 # RZ/G2H + - renesas,iic-r8a7795 # R-Car H3 + - renesas,iic-r8a7796 # R-Car M3-W + - renesas,iic-r8a77961 # R-Car M3-W+ + - renesas,iic-r8a77965 # R-Car M3-N + - renesas,iic-r8a77990 # R-Car E3 + - const: renesas,rcar-gen3-iic # R-Car Gen3 and RZ/G2 + - const: renesas,rmobile-iic # Generic + + reg: + maxItems: 1 + + interrupts: true + + clock-frequency: + description: + Desired I2C bus clock frequency in Hz. The absence of this property + indicates the default frequency 100 kHz. + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + dmas: + minItems: 2 + maxItems: 4 + description: + Must contain a list of pairs of references to DMA specifiers, one for + transmission, and one for reception. + + dma-names: + minItems: 2 + maxItems: 4 + items: + enum: + - tx + - rx + +required: + - compatible + - reg + - interrupts + - clocks + - power-domains + - '#address-cells' + - '#size-cells' + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + + - if: + properties: + compatible: + contains: + enum: + - renesas,iic-r8a7740 + - renesas,iic-sh73a0 + then: + properties: + interrupts: + items: + - description: Arbitration Lost Interrupt (ALI) + - description: Non-acknowledge Detection Interrupt (TACKI) + - description: Wait Interrupt (WAITI) + - description: Data Transmit Enable interrupt (DTEI) + else: + properties: + interrupts: + items: + - description: Single combined interrupt + + - if: + properties: + compatible: + contains: + enum: + - renesas,rcar-gen2-iic + - renesas,rcar-gen3-iic + then: + required: + - resets + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7790-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7790-sysc.h> + + iic0: i2c@e6500000 { + compatible = "renesas,iic-r8a7790", "renesas,rcar-gen2-iic", + "renesas,rmobile-iic"; + reg = <0xe6500000 0x425>; + interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 318>; + clock-frequency = <400000>; + dmas = <&dmac0 0x61>, <&dmac0 0x62>, <&dmac1 0x61>, <&dmac1 0x62>; + dma-names = "tx", "rx", "tx", "rx"; + power-domains = <&sysc R8A7790_PD_ALWAYS_ON>; + resets = <&cpg 318>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml new file mode 100644 index 000000000000..ff165ad1bee8 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/ti,omap4-i2c.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/ti,omap4-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for I2C controllers on TI's OMAP and K3 SoCs + +maintainers: + - Vignesh Raghavendra <vigneshr@ti.com> + +properties: + compatible: + oneOf: + - enum: + - ti,omap2420-i2c + - ti,omap2430-i2c + - ti,omap3-i2c + - ti,omap4-i2c + - items: + - enum: + - ti,am4372-i2c + - ti,am64-i2c + - ti,am654-i2c + - ti,j721e-i2c + - const: ti,omap4-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: fck + + clock-frequency: true + + power-domains: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + ti,hwmods: + description: + Must be "i2c<n>", n being the instance number (1-based). + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + +# subnode's properties +patternProperties: + "@[0-9a-f]+$": + type: object + description: + Flash device uses the below defined properties in the subnode. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2420-i2c + - const: ti,omap2430-i2c + - const: ti,omap3-i2c + - const: ti,omap4-i2c + +then: + properties: + ti,hwmods: + items: + - pattern: "^i2c([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + main_i2c0: i2c@2000000 { + compatible = "ti,j721e-i2c", "ti,omap4-i2c"; + reg = <0x2000000 0x100>; + interrupts = <GIC_SPI 200 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml new file mode 100644 index 000000000000..6f8f8a6258fe --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adis16201.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adis16201.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADIS16201 Dual Axis Inclinometer and similar + +maintainers: + - Jonathan Cameron <Jonathan.Cameron@huawei.com> + +description: | + Two similar parts from external interface point of view. + SPI interface. + https://www.analog.com/en/products/adis16201.html + https://www.analog.com/en/products/adis16209.html + +properties: + compatible: + enum: + - adi,adis16201 + - adi,adis16209 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adis16201"; + reg = <0>; + spi-max-frequency = <2500000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml index 45b3abde298f..a7e84089cc3d 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma180.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/iio/accel/bosch,bma180.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Bosch BMA023 / BMA150/ BMA180 / BMA25x / SMB380 triaxial accelerometers +title: Bosch BMA023 / BMA150/ BMA180 / BMA250 / SMB380 triaxial accelerometers maintainers: - Jonathan Cameron <jic23@kernel.org> @@ -21,7 +21,6 @@ properties: - bosch,bma150 - bosch,bma180 - bosch,bma250 - - bosch,bma254 - bosch,smb380 reg: diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml new file mode 100644 index 000000000000..942b23ad0712 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma220.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/bosch,bma220.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bosch BMA220 Trixial Acceleration Sensor + +maintainers: + - Jonathan Cameron <Jonathan.Cameron@huawei.com> + +properties: + compatible: + enum: + - bosch,bma220 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdda-supply: true + vddd-supply: true + vddio-supply: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "bosch,bma220"; + reg = <0>; + spi-max-frequency = <2500000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml index c2efbb813ca2..e830d5295b92 100644 --- a/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml +++ b/Documentation/devicetree/bindings/iio/accel/bosch,bma255.yaml @@ -18,6 +18,8 @@ properties: enum: - bosch,bmc150_accel - bosch,bmi055_accel + - bosch,bma253 + - bosch,bma254 - bosch,bma255 - bosch,bma250e - bosch,bma222 @@ -31,7 +33,12 @@ properties: vddio-supply: true interrupts: - maxItems: 1 + minItems: 1 + maxItems: 2 + description: | + The first interrupt listed must be the one connected to the INT1 pin, + the second (optional) interrupt listed must be the one connected to the + INT2 pin (if available). mount-matrix: description: an optional 3x3 mounting rotation matrix. diff --git a/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml new file mode 100644 index 000000000000..7c8f8bdc2333 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/fsl,mma7455.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/fsl,mma7455.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale MMA7455 and MMA7456 three axis accelerometers + +maintainers: + - Joachim Eastwood <manabian@gmail.com> + - Jonathan Cameron <jic23@kernel.org> + +description: + Devices support both SPI and I2C interfaces. + +properties: + compatible: + enum: + - fsl,mma7455 + - fsl,mma7456 + reg: + maxItems: 1 + + avdd-supply: true + vddio-supply: true + + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: + description: + Data ready is only available on INT1, but events can use either or + both pins. If not specified, first element assumed to correspond + to INT1 and second (where present) to INT2. + minItems: 1 + maxItems: 2 + items: + enum: + - "INT1" + - "INT2" + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + # include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@18 { + compatible = "fsl,mma7455"; + reg = <0x18>; + vddio-supply = <&iovdd>; + avdd-supply = <&avdd>; + interrupts = <57 IRQ_TYPE_EDGE_FALLING>, <58 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "INT2", "INT1"; + }; + }; + - | + # include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@0 { + compatible = "fsl,mma7456"; + reg = <0>; + spi-max-frequency = <10000000>; + vddio-supply = <&iovdd>; + avdd-supply = <&avdd>; + interrupts = <57 IRQ_TYPE_EDGE_FALLING>; + interrupt-names = "INT1"; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml index fbb714431e3d..52fa0f7c2d0e 100644 --- a/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml +++ b/Documentation/devicetree/bindings/iio/accel/kionix,kxcjk1013.yaml @@ -16,6 +16,7 @@ properties: - kionix,kxcj91008 - kionix,kxtj21009 - kionix,kxtf9 + - kionix,kx023-1025 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml new file mode 100644 index 000000000000..55fd3548e3b6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/murata,sca3300.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/murata,sca3300.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Murata SCA3300 Accelerometer + +description: | + 3-axis industrial accelerometer with digital SPI interface + https://www.murata.com/en-global/products/sensor/accel/sca3300 + +maintainers: + - Tomas Melin <tomas.melin@vaisala.com> + +properties: + compatible: + enum: + - murata,sca3300 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 8000000 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + accelerometer@0 { + compatible = "murata,sca3300"; + reg = <0x0>; + spi-max-frequency = <4000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml new file mode 100644 index 000000000000..ad529ab2c6e2 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/nxp,fxls8962af.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/nxp,fxls8962af.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP FXLS8962AF/FXLS8964AF Accelerometer driver + +maintainers: + - Sean Nyekjaer <sean@geanix.com> + +description: | + NXP FXLS8962AF/FXLS8964AF Accelerometer driver that supports + SPI and I2C interface. + https://www.nxp.com/docs/en/data-sheet/FXLS8962AF.pdf + https://www.nxp.com/docs/en/data-sheet/FXLS8964AF.pdf + +properties: + compatible: + enum: + - nxp,fxls8962af + - nxp,fxls8964af + + reg: + maxItems: 1 + + vdd-supply: + description: phandle to the regulator that provides power to the accelerometer + + spi-max-frequency: true + + interrupts: + maxItems: 1 + + interrupt-names: + enum: + - INT1 + - INT2 + + drive-open-drain: + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a I2C device node */ + accelerometer@62 { + compatible = "nxp,fxls8962af"; + reg = <0x62>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi0 { + #address-cells = <1>; + #size-cells = <0>; + + /* Example for a SPI device node */ + accelerometer@0 { + compatible = "nxp,fxls8962af"; + reg = <0>; + spi-max-frequency = <4000000>; + interrupt-parent = <&gpio0>; + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "INT1"; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adc.yaml b/Documentation/devicetree/bindings/iio/adc/adc.yaml index 912a7635edc4..db348fcbb52c 100644 --- a/Documentation/devicetree/bindings/iio/adc/adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/adc.yaml @@ -39,4 +39,16 @@ properties: The first value specifies the positive input pin, the second specifies the negative input pin. + settling-time-us: + description: + Time between enabling the channel and first stable readings. + + oversampling-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Oversampling is used as replacement of or addition to the low-pass filter. + In some cases, the desired filtering characteristics are a function the + device design and can interact with other characteristics such as + settling time. + additionalProperties: true diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml new file mode 100644 index 000000000000..ca414bb396c5 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7298.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7298.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7298 ADC + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + +description: | + Bindings for the Analog Devices AD7298 ADC device. Datasheet can be + found here: + https://www.analog.com/en/products/ad7298.html + +properties: + compatible: + const: adi,ad7298 + + reg: + maxItems: 1 + + vref-supply: true + vdd-supply: true + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7298"; + reg = <0>; + spi-max-frequency = <5000000>; + vref-supply = <&adc_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml new file mode 100644 index 000000000000..cf711082ad7d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7476.yaml @@ -0,0 +1,174 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright 2019 Analog Devices Inc. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7476.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AD7476 and similar simple SPI ADCs from multiple manufacturers. + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + +description: | + A lot of simple SPI ADCs have very straight forward interfaces. + They typically don't provide a MOSI pin, simply reading out data + on MISO when the clock toggles. + +properties: + compatible: + enum: + - adi,ad7091 + - adi,ad7091r + - adi,ad7273 + - adi,ad7274 + - adi,ad7276 + - adi,ad7277 + - adi,ad7278 + - adi,ad7466 + - adi,ad7467 + - adi,ad7468 + - adi,ad7475 + - adi,ad7476 + - adi,ad7476a + - adi,ad7477 + - adi,ad7477a + - adi,ad7478 + - adi,ad7478a + - adi,ad7495 + - adi,ad7910 + - adi,ad7920 + - adi,ad7940 + - ti,adc081s + - ti,adc101s + - ti,adc121s + - ti,ads7866 + - ti,ads7867 + - ti,ads7868 + - lltc,ltc2314-14 + + reg: + maxItems: 1 + + vcc-supply: + description: + Main powersupply voltage for the chips, sometimes referred to as VDD on + datasheets. If there is no separate vref-supply, then this is needed + to establish channel scaling. + + vdrive-supply: + description: + Some devices have separate supply for their digital control side. + + vref-supply: + description: + Some devices have a specific reference voltage supplied on a different pin + to the other supplies. Needed to be able to establish channel scaling + unless there is also an internal reference available (e.g. ad7091r) + + spi-max-frequency: true + + adi,conversion-start-gpios: + description: A GPIO used to trigger the start of a conversion + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +allOf: + # Devices where reference is vcc + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091 + - adi,ad7276 + - adi,ad7277 + - adi,ad7278 + - adi,ad7466 + - adi,ad7467 + - adi,ad7468 + - adi,ad7940 + - ti,adc081s + - ti,adc101s + - ti,adc121s + - ti,ads7866 + - ti,ads7868 + required: + - vcc-supply + # Devices with a vref + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091r + - adi,ad7273 + - adi,ad7274 + - adi,ad7475 + - lltc,ltc2314-14 + then: + properties: + vref-supply: true + else: + properties: + vref-supply: false + # Devices with a vref where it is not optional + - if: + properties: + compatible: + contains: + enum: + - adi,ad7273 + - adi,ad7274 + - adi,ad7475 + - lltc,ltc2314-14 + then: + required: + - vref-supply + - if: + properties: + compatible: + contains: + enum: + - adi,ad7475 + - adi,ad7495 + then: + properties: + vdrive-supply: true + else: + properties: + vdrive-supply: false + - if: + properties: + compatible: + contains: + enum: + - adi,ad7091 + - adi,ad7091r + then: + properties: + adi,conversion-start-gpios: true + else: + properties: + adi,conversion-start-gpios: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7091r"; + reg = <0>; + spi-max-frequency = <5000000>; + vcc-supply = <&adc_vcc>; + vref-supply = <&adc_vref>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml index 3be8955587e4..7e8328e9ce13 100644 --- a/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/amlogic,meson-saradc.yaml @@ -41,7 +41,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: clkin - const: core diff --git a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml index 1e7894e524f9..733351dee252 100644 --- a/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/st,stm32-dfsdm-adc.yaml @@ -38,14 +38,12 @@ properties: dfsdm clock can also feed CLKOUT, when CLKOUT is used. - description: audio clock can be used as an alternate to feed CLKOUT. minItems: 1 - maxItems: 2 clock-names: items: - const: dfsdm - const: audio minItems: 1 - maxItems: 2 "#address-cells": const: 1 diff --git a/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml new file mode 100644 index 000000000000..601d69971d84 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/ti,tsc2046.yaml @@ -0,0 +1,115 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/ti,tsc2046.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TSC2046 touch screen controller. + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: | + TSC2046 is a touch screen controller with 8 channels ADC. + +properties: + compatible: + enum: + - ti,tsc2046e-adc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + "#io-channel-cells": + const: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +patternProperties: + "^channel@[0-7]$": + $ref: "adc.yaml" + type: object + + properties: + reg: + description: | + The channel number. It can have up to 8 channels + items: + minimum: 0 + maximum: 7 + + settling-time-us: true + oversampling-ratio: true + + required: + - reg + + additionalProperties: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "ti,tsc2046e-adc"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupts-extended = <&gpio3 20 IRQ_TYPE_LEVEL_LOW>; + #io-channel-cells = <1>; + + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0>; + }; + channel@1 { + reg = <1>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@2 { + reg = <2>; + }; + channel@3 { + reg = <3>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@4 { + reg = <4>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@5 { + reg = <5>; + settling-time-us = <700>; + oversampling-ratio = <5>; + }; + channel@6 { + reg = <6>; + }; + channel@7 { + reg = <7>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml index 90439a8dc785..f8a112c9a822 100644 --- a/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml +++ b/Documentation/devicetree/bindings/iio/afe/current-sense-shunt.yaml @@ -24,6 +24,9 @@ properties: description: | Channel node of a voltage io-channel. + "#io-channel-cells": + const: 0 + shunt-resistor-micro-ohms: description: The shunt resistance. @@ -57,6 +60,7 @@ examples: sysi { compatible = "current-sense-shunt"; io-channels = <&tiadc 0>; + #io-channel-cells = <0>; /* Divide the voltage by 3300000/1000000 (or 3.3) for the current. */ shunt-resistor-micro-ohms = <3300000>; diff --git a/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml new file mode 100644 index 000000000000..a02036ef9e8d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/cdc/adi,ad7746.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/cdc/adi,ad7746.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + +description: | + AD7746 24-Bit Capacitance-to-Digital Converter with Temperature Sensor + + Specifications about the part can be found at: + https://www.analog.com/media/en/technical-documentation/data-sheets/ad7291.pdf + +properties: + compatible: + enum: + - adi,ad7745 + - adi,ad7746 + - adi,ad7747 + + reg: + maxItems: 1 + + adi,excitation-vdd-permille: + description: | + Set VDD per mille to be used as the excitation voltage. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [125, 250, 375, 500] + + adi,exca-output-en: + description: Enables the EXCA pin as the excitation output. + type: boolean + + adi,exca-output-invert: + description: | + Inverts the excitation output in the EXCA pin. + Normally only one of the EXCX pins would be inverted, check the following + application notes for more details + https://www.analog.com/media/en/technical-documentation/application-notes/AN-1585.pdf + type: boolean + + adi,excb-output-en: + description: Enables the EXCB pin as the excitation output. + type: boolean + + adi,excb-output-invert: + description: Inverts the excitation output in the EXCB pin. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ad7746: cdc@48 { + compatible = "adi,ad7746"; + reg = <0x48>; + adi,excitation-vdd-permille = <125>; + + adi,exca-output-en; + adi,exca-output-invert; + adi,excb-output-en; + adi,excb-output-invert; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml index a93d1972a5c2..967500b7e773 100644 --- a/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml +++ b/Documentation/devicetree/bindings/iio/chemical/sensirion,sps30.yaml @@ -22,7 +22,6 @@ properties: required: - compatible - - reg additionalProperties: false @@ -37,5 +36,11 @@ examples: reg = <0x69>; }; }; + - | + serial { + air-pollution-sensor { + compatible = "sensirion,sps30"; + }; + }; ... diff --git a/Documentation/devicetree/bindings/iio/dac/ad5755.txt b/Documentation/devicetree/bindings/iio/dac/ad5755.txt deleted file mode 100644 index 502e1e55adbd..000000000000 --- a/Documentation/devicetree/bindings/iio/dac/ad5755.txt +++ /dev/null @@ -1,124 +0,0 @@ -* Analog Devices AD5755 IIO Multi-Channel DAC Linux Driver - -Required properties: - - compatible: Has to contain one of the following: - adi,ad5755 - adi,ad5755-1 - adi,ad5757 - adi,ad5735 - adi,ad5737 - - - reg: spi chip select number for the device - - spi-cpha or spi-cpol: is the only modes that is supported - -Recommended properties: - - spi-max-frequency: Definition as per - Documentation/devicetree/bindings/spi/spi-bus.txt - -Optional properties: -See include/dt-bindings/iio/ad5755.h - - adi,ext-dc-dc-compenstation-resistor: boolean set if the hardware have an - external resistor and thereby bypasses - the internal compensation resistor. - - adi,dc-dc-phase: - Valid values for DC DC Phase control is: - 0: All dc-to-dc converters clock on the same edge. - 1: Channel A and Channel B clock on the same edge, - Channel C and Channel D clock on opposite edges. - 2: Channel A and Channel C clock on the same edge, - Channel B and Channel D clock on opposite edges. - 3: Channel A, Channel B, Channel C, and Channel D - clock 90 degrees out of phase from each other. - - adi,dc-dc-freq-hz: - Valid values for DC DC frequency is [Hz]: - 250000 - 410000 - 650000 - - adi,dc-dc-max-microvolt: - Valid values for the maximum allowed Vboost voltage supplied by - the dc-to-dc converter is: - 23000000 - 24500000 - 27000000 - 29500000 - -Optional for every channel: - - adi,mode: - Valid values for DAC modes is: - 0: 0 V to 5 V voltage range. - 1: 0 V to 10 V voltage range. - 2: Plus minus 5 V voltage range. - 3: Plus minus 10 V voltage range. - 4: 4 mA to 20 mA current range. - 5: 0 mA to 20 mA current range. - 6: 0 mA to 24 mA current range. - - adi,ext-current-sense-resistor: boolean set if the hardware a external - current sense resistor. - - adi,enable-voltage-overrange: boolean enable voltage overrange - - adi,slew: Array of slewrate settings should contain 3 fields: - 1: Should be either 0 or 1 in order to enable or disable slewrate. - 2: Slew rate settings: - Valid values for the slew rate update frequency: - 64000 - 32000 - 16000 - 8000 - 4000 - 2000 - 1000 - 500 - 250 - 125 - 64 - 32 - 16 - 8 - 4 - 0 - 3: Slew step size: - Valid values for the step size LSBs: - 1 - 2 - 4 - 16 - 32 - 64 - 128 - 256 - -Example: -dac@0 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "adi,ad5755"; - reg = <0>; - spi-max-frequency = <1000000>; - spi-cpha; - adi,dc-dc-phase = <0>; - adi,dc-dc-freq-hz = <410000>; - adi,dc-dc-max-microvolt = <23000000>; - channel@0 { - reg = <0>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@1 { - reg = <1>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@2 { - reg = <2>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; - channel@3 { - reg = <3>; - adi,mode = <4>; - adi,ext-current-sense-resistor; - adi,slew = <0 64000 1>; - }; -}; diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml new file mode 100644 index 000000000000..be419ac46caa --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ad5755.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ad5755.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD5755 Multi-Channel DAC + +maintainers: + - Sean Nyekjaer <sean.nyekjaer@prevas.dk> + +properties: + compatible: + enum: + - adi,ad5755 + - adi,ad5755-1 + - adi,ad5757 + - adi,ad5735 + - adi,ad5737 + + reg: + maxItems: 1 + + spi-cpha: + description: Either this or spi-cpol but not both. + spi-cpol: true + + spi-max-frequency: true + + adi,ext-dc-dc-compenstation-resistor: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the hardware have an external resistor and thereby bypasses + the internal compensation resistor. + + adi,dc-dc-phase: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + description: | + Valid values for DC DC Phase control is: + 0: All dc-to-dc converters clock on the same edge. + 1: Channel A and Channel B clock on the same edge, + Channel C and Channel D clock on opposite edges. + 2: Channel A and Channel C clock on the same edge, + Channel B and Channel D clock on opposite edges. + 3: Channel A, Channel B, Channel C, and Channel D + clock 90 degrees out of phase from each other. + + adi,dc-dc-freq-hz: + enum: [250000, 410000, 650000] + + adi,dc-dc-max-microvolt: + description: + Maximum allowed Vboost voltage supplied by the dc-to-dc converter. + enum: [23000000, 24500000, 27000000, 29500000] + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#io-channel-cells": + const: 1 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@[0-7]$": + type: object + description: Child node to describe a channel + properties: + reg: + maxItems: 1 + + adi,mode: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 6 + description: | + Valid values for DAC modes is: + 0: 0 V to 5 V voltage range. + 1: 0 V to 10 V voltage range. + 2: Plus minus 5 V voltage range. + 3: Plus minus 10 V voltage range. + 4: 4 mA to 20 mA current range. + 5: 0 mA to 20 mA current range. + 6: 0 mA to 24 mA current range. + + adi,ext-current-sense-resistor: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the hardware has an external current sense resistor + + adi,enable-voltage-overrange: + $ref: /schemas/types.yaml#/definitions/flag + description: Enable voltage overrange + + adi,slew: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of slewrate settings should contain 3 fields: + 1: Should be either 0 or 1 in order to enable or disable slewrate. + 2: Slew rate update frequency + 3: Slew step size + items: + - enum: [0, 1] + - enum: [64000, 32000, 16000, 8000, 4000, 2000, 1000, 500, 250, 125, 64, 32, 16, 8, 4, 0] + - enum: [1, 2, 4, 16, 32, 64, 128, 256] + + required: + - reg + + additionalProperties: false + +oneOf: + - required: + - spi-cpha + - required: + - spi-cpol + +examples: + - | + #include <dt-bindings/iio/adi,ad5592r.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + #address-cells = <1>; + #size-cells = <0>; + compatible = "adi,ad5755"; + reg = <0>; + spi-max-frequency = <1000000>; + spi-cpha; + adi,dc-dc-phase = <0>; + adi,dc-dc-freq-hz = <410000>; + adi,dc-dc-max-microvolt = <23000000>; + channel@0 { + reg = <0>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@1 { + reg = <1>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@2 { + reg = <2>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + channel@3 { + reg = <3>; + adi,mode = <4>; + adi,ext-current-sense-resistor; + adi,slew = <0 64000 1>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml new file mode 100644 index 000000000000..b0157050f1ee --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/ti,dac082s085.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/ti,dac082s085.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments DAC082s085 and similar DACs + +description: + A family of Texas Instruments 8/10/12-bit 2/4-channel DACs + +maintainers: + - Lukas Wunner <lukas@wunner.de> + +properties: + compatible: + enum: + - ti,dac082s085 + - ti,dac102s085 + - ti,dac122s085 + - ti,dac084s085 + - ti,dac104s085 + - ti,dac124s085 + + reg: + maxItems: 1 + + spi-cpha: true + spi-cpol: + description: + Must be either spi-cpha, or spi-cpol but not both. + + vref-supply: + description: Needed to provide output scaling. + + spi-max-frequency: true + +required: + - compatible + - reg + - vref-supply + +additionalProperties: false + +oneOf: + - required: + - spi-cpha + - required: + - spi-cpol + +examples: + - | + vref_2v5_reg: regulator-vref { + compatible = "regulator-fixed"; + regulator-name = "2v5"; + regulator-min-microvolt = <2500000>; + regulator-max-microvolt = <2500000>; + regulator-always-on; + }; + spi { + #address-cells = <1>; + #size-cells = <0>; + + dac@0 { + compatible = "ti,dac082s085"; + reg = <0>; + spi-max-frequency = <40000000>; + spi-cpol; + vref-supply = <&vref_2v5_reg>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt b/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt deleted file mode 100644 index 9cb0e10df704..000000000000 --- a/Documentation/devicetree/bindings/iio/dac/ti-dac082s085.txt +++ /dev/null @@ -1,34 +0,0 @@ -Texas Instruments 8/10/12-bit 2/4-channel DAC driver - -Required properties: - - compatible: Must be one of: - "ti,dac082s085" - "ti,dac102s085" - "ti,dac122s085" - "ti,dac084s085" - "ti,dac104s085" - "ti,dac124s085" - - reg: Chip select number. - - spi-cpha, spi-cpol: SPI mode (0,1) or (1,0) must be used, so specify - either spi-cpha or spi-cpol (but not both). - - vref-supply: Phandle to the external reference voltage supply. - -For other required and optional properties of SPI slave nodes please refer to -../../spi/spi-bus.txt. - -Example: - vref_2v5_reg: regulator-vref { - compatible = "regulator-fixed"; - regulator-name = "2v5"; - regulator-min-microvolt = <2500000>; - regulator-max-microvolt = <2500000>; - regulator-always-on; - }; - - dac@0 { - compatible = "ti,dac082s085"; - reg = <0>; - spi-max-frequency = <40000000>; - spi-cpol; - vref-supply = <&vref_2v5_reg>; - }; diff --git a/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml new file mode 100644 index 000000000000..83b88c6a243d --- /dev/null +++ b/Documentation/devicetree/bindings/iio/light/amstaos,tsl2591.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/light/amstaos,tsl2591.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AMS/TAOS TSL2591 Ambient Light Sensor (ALS) + +maintainers: + - Joe Sandom <joe.g.sandom@gmail.com> + +description: | + AMS/TAOS TSL2591 is a very-high sensitivity + light-to-digital converter that transforms light intensity into a digital + signal. + +properties: + compatible: + const: amstaos,tsl2591 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + description: + Interrupt (INT:Pin 2) Active low. Should be set to IRQ_TYPE_EDGE_FALLING. + interrupt is used to detect if the light intensity has fallen below + or reached above the configured threshold values. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tsl2591@29 { + compatible = "amstaos,tsl2591"; + reg = <0x29>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt deleted file mode 100644 index 89647d714387..000000000000 --- a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.txt +++ /dev/null @@ -1,39 +0,0 @@ -I/O channel multiplexer bindings - -If a multiplexer is used to select which hardware signal is fed to -e.g. an ADC channel, these bindings describe that situation. - -Required properties: -- compatible : "io-channel-mux" -- io-channels : Channel node of the parent channel that has multiplexed - input. -- io-channel-names : Should be "parent". -- #address-cells = <1>; -- #size-cells = <0>; -- mux-controls : Mux controller node to use for operating the mux -- channels : List of strings, labeling the mux controller states. - -For each non-empty string in the channels property, an io-channel will -be created. The number of this io-channel is the same as the index into -the list of strings in the channels property, and also matches the mux -controller state. The mux controller state is described in -../mux/mux-controller.txt - -Example: - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync", "in", "system-regulator"; - }; diff --git a/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml new file mode 100644 index 000000000000..870b043406d8 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/multiplexer/io-channel-mux.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/multiplexer/io-channel-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I/O channel multiplexer bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + If a multiplexer is used to select which hardware signal is fed to + e.g. an ADC channel, these bindings describe that situation. + + For each non-empty string in the channels property, an io-channel will be + created. The number of this io-channel is the same as the index into the list + of strings in the channels property, and also matches the mux controller + state. The mux controller state is described in + Documentation/devicetree/bindings/mux/mux-controller.yaml + +properties: + + compatible: + const: io-channel-mux + + io-channels: + maxItems: 1 + description: Channel node of the parent channel that has multiplexed input. + + io-channel-names: + const: parent + + mux-controls: true + mux-control-names: true + + channels: + $ref: /schemas/types.yaml#/definitions/string-array + description: + List of strings, labeling the mux controller states. + +required: + - compatible + - io-channels + - io-channel-names + - mux-controls + - channels + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + channels = "sync", "in", "system-regulator"; + }; +... diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 7e98f47987dc..b2a1e42c56fa 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -6,7 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: STMicroelectronics MEMS sensors -description: | +description: The STMicroelectronics sensor devices are pretty straight-forward + I2C or SPI devices, all sharing the same device tree descriptions no matter + what type of sensor it is. Note that whilst this covers many STMicro MEMs sensors, some more complex IMUs need their own bindings. The STMicroelectronics sensor devices are pretty straight-forward I2C or @@ -15,90 +17,181 @@ description: | maintainers: - Denis Ciocca <denis.ciocca@st.com> + - Linus Walleij <linus.walleij@linaro.org> properties: compatible: - description: | - Some values are deprecated. - st,lis3lv02d (deprecated, use st,lis3lv02dl-accel) - st,lis302dl-spi (deprecated, use st,lis3lv02dl-accel) - enum: - # Accelerometers - - st,lis3lv02d - - st,lis302dl-spi - - st,lis3lv02dl-accel - - st,lsm303dlh-accel - - st,lsm303dlhc-accel - - st,lis3dh-accel - - st,lsm330d-accel - - st,lsm330dl-accel - - st,lsm330dlc-accel - - st,lis331dl-accel - - st,lis331dlh-accel - - st,lsm303dl-accel - - st,lsm303dlm-accel - - st,lsm330-accel - - st,lsm303agr-accel - - st,lis2dh12-accel - - st,h3lis331dl-accel - - st,lng2dm-accel - - st,lis3l02dq - - st,lis2dw12 - - st,lis3dhh - - st,lis3de - - st,lis2de12 - - st,lis2hh12 - # Gyroscopes - - st,l3g4200d-gyro - - st,lsm330d-gyro - - st,lsm330dl-gyro - - st,lsm330dlc-gyro - - st,l3gd20-gyro - - st,l3gd20h-gyro - - st,l3g4is-gyro - - st,lsm330-gyro - - st,lsm9ds0-gyro - # Magnetometers - - st,lsm303agr-magn - - st,lsm303dlh-magn - - st,lsm303dlhc-magn - - st,lsm303dlm-magn - - st,lis3mdl-magn - - st,lis2mdl - - st,lsm9ds1-magn - - st,iis2mdc - # Pressure sensors - - st,lps001wp-press - - st,lps25h-press - - st,lps331ap-press - - st,lps22hb-press - - st,lps33hw - - st,lps35hw - - st,lps22hh + oneOf: + - description: STMicroelectronics Accelerometers + enum: + - st,h3lis331dl-accel + - st,lis2de12 + - st,lis2dw12 + - st,lis2hh12 + - st,lis2dh12-accel + - st,lis331dl-accel + - st,lis331dlh-accel + - st,lis3de + - st,lis3dh-accel + - st,lis3dhh + - st,lis3l02dq + - st,lis3lv02dl-accel + - st,lng2dm-accel + - st,lsm303agr-accel + - st,lsm303dl-accel + - st,lsm303dlh-accel + - st,lsm303dlhc-accel + - st,lsm303dlm-accel + - st,lsm330-accel + - st,lsm330d-accel + - st,lsm330dl-accel + - st,lsm330dlc-accel + - description: STMicroelectronics Gyroscopes + enum: + - st,l3g4200d-gyro + - st,l3g4is-gyro + - st,l3gd20-gyro + - st,l3gd20h-gyro + - st,lsm330-gyro + - st,lsm330d-gyro + - st,lsm330dl-gyro + - st,lsm330dlc-gyro + - st,lsm9ds0-gyro + - description: STMicroelectronics Magnetometers + enum: + - st,lis2mdl + - st,lis3mdl-magn + - st,lsm303agr-magn + - st,lsm303dlh-magn + - st,lsm303dlhc-magn + - st,lsm303dlm-magn + - st,lsm9ds1-magn + - description: STMicroelectronics Pressure Sensors + enum: + - st,lps001wp-press + - st,lps22hb-press + - st,lps22hh + - st,lps25h-press + - st,lps331ap-press + - st,lps33hw + - st,lps35hw + - description: IMUs + enum: + - st,lsm9ds0-imu + - description: Deprecated bindings + enum: + - st,lis302dl-spi + - st,lis3lv02d + deprecated: true reg: maxItems: 1 interrupts: + description: interrupt line(s) connected to the DRDY line(s) and/or the + Intertial interrupt lines INT1 and INT2 if these exist. This means up to + three interrupts, and the DRDY must be the first one if it exists on + the package. The trigger edge of the interrupts is sometimes software + configurable in the hardware so the operating system should parse this + flag and set up the trigger edge as indicated in the device tree. minItems: 1 + maxItems: 2 vdd-supply: true vddio-supply: true st,drdy-int-pin: + description: the pin on the package that will be used to signal + "data ready" (valid values 1 or 2). This property is not configurable + on all sensors. $ref: /schemas/types.yaml#/definitions/uint32 - description: - Some sensors have multiple possible pins via which they can provide - a data ready interrupt. This selects which one. - enum: - - 1 - - 2 + enum: [1, 2] drive-open-drain: $ref: /schemas/types.yaml#/definitions/flag - description: | - The interrupt/data ready line will be configured as open drain, which - is useful if several sensors share the same interrupt line. + description: the interrupt/data ready line will be configured + as open drain, which is useful if several sensors share the same + interrupt line. (This binding is taken from pinctrl.) + + mount-matrix: + description: an optional 3x3 mounting rotation matrix. + +allOf: + - if: + properties: + compatible: + enum: + # These have no interrupts + - st,lps001wp + then: + properties: + interrupts: false + st,drdy-int-pin: false + drive-open-drain: false + + - if: + properties: + compatible: + enum: + # These have only DRDY + - st,lis2mdl + - st,lis3l02dq + - st,lis3lv02dl-accel + - st,lps22hb-press + - st,lps22hh + - st,lps25h-press + - st,lps33hw + - st,lps35hw + - st,lsm303agr-magn + - st,lsm303dlh-magn + - st,lsm303dlhc-magn + - st,lsm303dlm-magn + then: + properties: + interrupts: + maxItems: 1 + st,drdy-int-pin: false + + - if: + properties: + compatible: + enum: + # Two intertial interrupts i.e. accelerometer/gyro interrupts + - st,h3lis331dl-accel + - st,l3g4200d-gyro + - st,l3g4is-gyro + - st,l3gd20-gyro + - st,l3gd20h-gyro + - st,lis2de12 + - st,lis2dw12 + - st,lis2hh12 + - st,lis2dh12-accel + - st,lis331dl-accel + - st,lis331dlh-accel + - st,lis3de + - st,lis3dh-accel + - st,lis3dhh + - st,lis3mdl-magn + - st,lng2dm-accel + - st,lps331ap-press + - st,lsm303agr-accel + - st,lsm303dlh-accel + - st,lsm303dlhc-accel + - st,lsm303dlm-accel + - st,lsm330-accel + - st,lsm330-gyro + - st,lsm330d-accel + - st,lsm330d-gyro + - st,lsm330dl-accel + - st,lsm330dl-gyro + - st,lsm330dlc-accel + - st,lsm330dlc-gyro + - st,lsm9ds0-gyro + - st,lsm9ds1-magn + then: + properties: + interrupts: + maxItems: 2 required: - compatible @@ -110,15 +203,30 @@ examples: - | #include <dt-bindings/interrupt-controller/irq.h> i2c { - #address-cells = <1>; - #size-cells = <0>; - accelerometer@1d { - compatible = "st,lis3lv02dl-accel"; - reg = <0x1d>; - interrupt-parent = <&gpio2>; - interrupts = <18 IRQ_TYPE_EDGE_RISING>; - pinctrl-0 = <&lis3lv02dl_nhk_mode>; - pinctrl-names = "default"; - }; + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@1c { + compatible = "st,lis331dl-accel"; + reg = <0x1c>; + st,drdy-int-pin = <1>; + vdd-supply = <&ldo1>; + vddio-supply = <&ldo2>; + interrupt-parent = <&gpio>; + interrupts = <18 IRQ_TYPE_EDGE_RISING>, <19 IRQ_TYPE_EDGE_RISING>; + }; + }; + spi { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <1>; + + l3g4200d: gyroscope@0 { + compatible = "st,l3g4200d-gyro"; + st,drdy-int-pin = <2>; + reg = <0>; + vdd-supply = <&vcc_io>; + vddio-supply = <&vcc_io>; + }; }; ... diff --git a/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml new file mode 100644 index 000000000000..347bc16a4671 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/temperature/ti,tmp117.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/iio/temperature/ti,tmp117.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: "TI TMP117 - Digital temperature sensor with integrated NV memory" + +description: | + TI TMP117 - Digital temperature sensor with integrated NV memory that supports + I2C interface. + https://www.ti.com/lit/gpn/tmp1 + +maintainers: + - Puranjay Mohan <puranjay12@gmail.com> + +properties: + compatible: + enum: + - ti,tmp117 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tmp117@48 { + compatible = "ti,tmp117"; + reg = <0x48>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/fsl-mma8450.txt b/Documentation/devicetree/bindings/input/fsl-mma8450.txt deleted file mode 100644 index 0b96e5737d3a..000000000000 --- a/Documentation/devicetree/bindings/input/fsl-mma8450.txt +++ /dev/null @@ -1,12 +0,0 @@ -* Freescale MMA8450 3-Axis Accelerometer - -Required properties: -- compatible : "fsl,mma8450". -- reg: the I2C address of MMA8450 - -Example: - -accelerometer: mma8450@1c { - compatible = "fsl,mma8450"; - reg = <0x1c>; -}; diff --git a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt index 34ab5763f494..6cd08bca2c66 100644 --- a/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt +++ b/Documentation/devicetree/bindings/input/qcom,pm8941-pwrkey.txt @@ -8,6 +8,8 @@ PROPERTIES Definition: must be one of: "qcom,pm8941-pwrkey" "qcom,pm8941-resin" + "qcom,pmk8350-pwrkey" + "qcom,pmk8350-resin" - reg: Usage: required diff --git a/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml new file mode 100644 index 000000000000..762e56ee90cd --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/cypress,cy8ctma340.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/cypress,cy8ctma340.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cypress CY8CTMA340 series touchscreen controller bindings + +description: The Cypress CY8CTMA340 series (also known as "CYTTSP" after + the marketing name Cypress TrueTouch Standard Product) touchscreens can + be connected to either I2C or SPI buses. + +maintainers: + - Javier Martinez Canillas <javier@dowhile0.org> + - Linus Walleij <linus.walleij@linaro.org> + +allOf: + - $ref: touchscreen.yaml# + +properties: + $nodename: + pattern: "^touchscreen(@.*)?$" + + compatible: + oneOf: + - const: cypress,cy8ctma340 + - const: cypress,cy8ctst341 + - const: cypress,cyttsp-spi + description: Legacy compatible for SPI connected CY8CTMA340 + deprecated: true + - const: cypress,cyttsp-i2c + description: Legacy compatible for I2C connected CY8CTMA340 + deprecated: true + + reg: + description: I2C address when used on the I2C bus, or the SPI chip + select index when used on the SPI bus + + clock-frequency: + description: I2C client clock frequency, defined for host when using + the device on the I2C bus + minimum: 0 + maximum: 400000 + + spi-max-frequency: + description: SPI clock frequency, defined for host, defined when using + the device on the SPI bus. The throughput is maximum 2 Mbps so the + typical value is 2000000, if higher rates are used the total throughput + needs to be restricted to 2 Mbps. + minimum: 0 + maximum: 6000000 + + interrupts: + description: Interrupt to host + maxItems: 1 + + vcpin-supply: + description: Analog power supply regulator on VCPIN pin + + vdd-supply: + description: Digital power supply regulator on VDD pin + + reset-gpios: + description: Reset line for the touchscreen, should be tagged + as GPIO_ACTIVE_LOW + + bootloader-key: + description: the 8-byte bootloader key that is required to switch + the chip from bootloader mode (default mode) to application mode + $ref: /schemas/types.yaml#/definitions/uint8-array + minItems: 8 + maxItems: 8 + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-fuzz-x: true + touchscreen-fuzz-y: true + + active-distance: + description: the distance in pixels beyond which a touch must move + before movement is detected and reported by the device + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + active-interval-ms: + description: the minimum period in ms between consecutive + scanning/processing cycles when the chip is in active mode + minimum: 0 + maximum: 255 + + lowpower-interval-ms: + description: the minimum period in ms between consecutive + scanning/processing cycles when the chip is in low-power mode + minimum: 0 + maximum: 2550 + + touch-timeout-ms: + description: minimum time in ms spent in the active power state while no + touches are detected before entering low-power mode + minimum: 0 + maximum: 2550 + + use-handshake: + description: enable register-based handshake (boolean). This should only + be used if the chip is configured to use 'blocking communication with + timeout' (in this case the device generates an interrupt at the end of + every scanning/processing cycle) + $ref: /schemas/types.yaml#/definitions/flag + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - bootloader-key + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + num-cs = <1>; + cs-gpios = <&gpio 2 GPIO_ACTIVE_HIGH>; + + touchscreen@0 { + compatible = "cypress,cy8ctma340"; + reg = <0>; + interrupt-parent = <&gpio>; + interrupts = <20 IRQ_TYPE_EDGE_FALLING>; + reset-gpios = <&gpio 21 GPIO_ACTIVE_LOW>; + vdd-supply = <&ldo_aux1_reg>; + vcpin-supply = <&ldo_aux2_reg>; + bootloader-key = /bits/ 8 <0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07>; + touchscreen-size-x = <480>; + touchscreen-size-y = <800>; + active-interval-ms = <0>; + touch-timeout-ms = <255>; + lowpower-interval-ms = <10>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt b/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt deleted file mode 100644 index 6ee274aa8b03..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/cyttsp.txt +++ /dev/null @@ -1,93 +0,0 @@ -* Cypress cyttsp touchscreen controller - -Required properties: - - compatible : must be "cypress,cyttsp-i2c" or "cypress,cyttsp-spi" - - reg : Device I2C address or SPI chip select number - - spi-max-frequency : Maximum SPI clocking speed of the device (for cyttsp-spi) - - interrupts : (gpio) interrupt to which the chip is connected - (see interrupt binding[0]). - - bootloader-key : the 8-byte bootloader key that is required to switch - the chip from bootloader mode (default mode) to - application mode. - This property has to be specified as an array of 8 - '/bits/ 8' values. - -Optional properties: - - reset-gpios : the reset gpio the chip is connected to - (see GPIO binding[1] for more details). - - touchscreen-size-x : horizontal resolution of touchscreen (in pixels) - - touchscreen-size-y : vertical resolution of touchscreen (in pixels) - - touchscreen-fuzz-x : horizontal noise value of the absolute input device - (in pixels) - - touchscreen-fuzz-y : vertical noise value of the absolute input device - (in pixels) - - active-distance : the distance in pixels beyond which a touch must move - before movement is detected and reported by the device. - Valid values: 0-15. - - active-interval-ms : the minimum period in ms between consecutive - scanning/processing cycles when the chip is in active mode. - Valid values: 0-255. - - lowpower-interval-ms : the minimum period in ms between consecutive - scanning/processing cycles when the chip is in low-power mode. - Valid values: 0-2550 - - touch-timeout-ms : minimum time in ms spent in the active power state while no - touches are detected before entering low-power mode. - Valid values: 0-2550 - - use-handshake : enable register-based handshake (boolean). This should - only be used if the chip is configured to use 'blocking - communication with timeout' (in this case the device - generates an interrupt at the end of every - scanning/processing cycle). - -[0]: Documentation/devicetree/bindings/interrupt-controller/interrupts.txt -[1]: Documentation/devicetree/bindings/gpio/gpio.txt - -Example: - &i2c1 { - /* ... */ - cyttsp@a { - compatible = "cypress,cyttsp-i2c"; - reg = <0xa>; - interrupt-parent = <&gpio0>; - interrupts = <28 0>; - reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; - - touchscreen-size-x = <800>; - touchscreen-size-y = <480>; - touchscreen-fuzz-x = <4>; - touchscreen-fuzz-y = <7>; - - bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>; - active-distance = <8>; - active-interval-ms = <0>; - lowpower-interval-ms = <200>; - touch-timeout-ms = <100>; - }; - - /* ... */ - }; - - &mcspi1 { - /* ... */ - cyttsp@0 { - compatible = "cypress,cyttsp-spi"; - spi-max-frequency = <6000000>; - reg = <0>; - interrupt-parent = <&gpio0>; - interrupts = <28 0>; - reset-gpios = <&gpio3 4 GPIO_ACTIVE_LOW>; - - touchscreen-size-x = <800>; - touchscreen-size-y = <480>; - touchscreen-fuzz-x = <4>; - touchscreen-fuzz-y = <7>; - - bootloader-key = /bits/ 8 <0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08>; - active-distance = <8>; - active-interval-ms = <0>; - lowpower-interval-ms = <200>; - touch-timeout-ms = <100>; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml index bfc3a8b5e118..2e8da7470513 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/edt-ft5x06.yaml @@ -56,6 +56,7 @@ properties: wakeup-source: true vcc-supply: true + iovcc-supply: true gain: description: Allows setting the sensitivity in the range from 0 to 31. diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt deleted file mode 100644 index af5223bb5bdd..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.txt +++ /dev/null @@ -1,33 +0,0 @@ -Generic resistive touchscreen ADC - -Required properties: - - - compatible: must be "resistive-adc-touch" -The device must be connected to an ADC device that provides channels for -position measurement and optional pressure. -Refer to -https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml -for details - - - iio-channels: must have at least two channels connected to an ADC device. -These should correspond to the channels exposed by the ADC device and should -have the right index as the ADC device registers them. These channels -represent the relative position on the "x" and "y" axes. - - iio-channel-names: must have all the channels' names. Mandatory channels -are "x" and "y". - -Optional properties: - - iio-channels: The third channel named "pressure" is optional and can be -used if the ADC device also measures pressure besides position. -If this channel is missing, pressure will be ignored and the touchscreen -will only report position. - - iio-channel-names: optional channel named "pressure". - -Example: - - resistive_touch: resistive_touch { - compatible = "resistive-adc-touch"; - touchscreen-min-pressure = <50000>; - io-channels = <&adc 24>, <&adc 25>, <&adc 26>; - io-channel-names = "x", "y", "pressure"; - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml new file mode 100644 index 000000000000..7fc22a403d48 --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/resistive-adc-touch.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/resistive-adc-touch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic resistive touchscreen ADC + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +description: | + Generic ADC based resistive touchscreen controller + The device must be connected to an ADC device that provides channels for + position measurement and optional pressure. + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + const: resistive-adc-touch + + io-channels: + minItems: 2 + items: + - description: x + - description: y + - description: pressure (optional) + - description: z1 (optional) + - description: z2 (optional) + + io-channel-names: + oneOf: + - items: + - enum: [x, y] + - enum: [x, y] + - items: + - enum: [x, y, pressure] + - enum: [x, y, pressure] + - enum: [x, y, pressure] + - items: + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + - enum: [x, y, z1, z2] + + touchscreen-size-x: true + touchscreen-size-y: true + touchscreen-fuzz-x: true + touchscreen-fuzz-y: true + touchscreen-inverted-x: true + touchscreen-inverted-y: true + touchscreen-swapped-x-y: true + touchscreen-min-pressure: true + touchscreen-x-plate-ohms: true + +additionalProperties: false + +required: + - compatible + - io-channels + - io-channel-names + +examples: + - | + touchscreen { + compatible = "resistive-adc-touch"; + io-channels = <&adc 24>, <&adc 25>; + io-channel-names = "y", "x"; + }; + - | + touchscreen { + compatible = "resistive-adc-touch"; + touchscreen-min-pressure = <50000>; + io-channels = <&adc 24>, <&adc 25>, <&adc 26>; + io-channel-names = "y", "pressure", "x"; + }; + - | + touchscreen { + compatible = "resistive-adc-touch"; + touchscreen-min-pressure = <50000>; + io-channels = <&adc 1>, <&adc 2>, <&adc 3>, <&adc 4>; + io-channel-names = "x", "z1", "z2", "y"; + touchscreen-x-plate-ohms = <800>; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml new file mode 100644 index 000000000000..1d8ca19fd37a --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/sitronix,st1232.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/sitronix,st1232.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sitronix st1232 or st1633 touchscreen controller + +maintainers: + - Bastian Hecht <hechtb@gmail.com> + +allOf: + - $ref: touchscreen.yaml# + +properties: + compatible: + enum: + - sitronix,st1232 + - sitronix,st1633 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + gpios: + description: A phandle to the reset GPIO + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + touchscreen@55 { + compatible = "sitronix,st1232"; + reg = <0x55>; + interrupts = <2 0>; + gpios = <&gpio1 166 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt b/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt deleted file mode 100644 index 019373253b28..000000000000 --- a/Documentation/devicetree/bindings/input/touchscreen/sitronix-st1232.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Sitronix st1232 or st1633 touchscreen controller - -Required properties: -- compatible: must contain one of - * "sitronix,st1232" - * "sitronix,st1633" -- reg: I2C address of the chip -- interrupts: interrupt to which the chip is connected - -Optional properties: -- gpios: a phandle to the reset GPIO - -For additional optional properties see: touchscreen.txt - -Example: - - i2c@00000000 { - /* ... */ - - touchscreen@55 { - compatible = "sitronix,st1232"; - reg = <0x55>; - interrupts = <2 0>; - gpios = <&gpio1 166 0>; - }; - - /* ... */ - }; diff --git a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml index 046ace461cc9..4b5b212c772c 100644 --- a/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml +++ b/Documentation/devicetree/bindings/input/touchscreen/touchscreen.yaml @@ -74,6 +74,12 @@ properties: touchscreen-y-mm: description: vertical length in mm of the touchscreen + touchscreen-x-plate-ohms: + description: Resistance of the X-plate in Ohms + + touchscreen-y-plate-ohms: + description: Resistance of the Y-plate in Ohms + dependencies: touchscreen-size-x: [ touchscreen-size-y ] touchscreen-size-y: [ touchscreen-size-x ] diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index 36c955965d90..5accc0d113be 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -37,6 +37,18 @@ properties: - qcom,sc7180-npu-noc - qcom,sc7180-qup-virt - qcom,sc7180-system-noc + - qcom,sc7280-aggre1-noc + - qcom,sc7280-aggre2-noc + - qcom,sc7280-clk-virt + - qcom,sc7280-cnoc2 + - qcom,sc7280-cnoc3 + - qcom,sc7280-dc-noc + - qcom,sc7280-gem-noc + - qcom,sc7280-lpass-ag-noc + - qcom,sc7280-mc-virt + - qcom,sc7280-mmss-noc + - qcom,sc7280-nsp-noc + - qcom,sc7280-system-noc - qcom,sdm845-aggre1-noc - qcom,sdm845-aggre2-noc - qcom,sdm845-config-noc diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt deleted file mode 100644 index dd527216c5fb..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.txt +++ /dev/null @@ -1,41 +0,0 @@ -* ARM Vectored Interrupt Controller - -One or more Vectored Interrupt Controllers (VIC's) can be connected in an ARM -system for interrupt routing. For multiple controllers they can either be -nested or have the outputs wire-OR'd together. - -Required properties: - -- compatible : should be one of - "arm,pl190-vic" - "arm,pl192-vic" -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells : The number of cells to define the interrupts. Must be 1 as - the VIC has no configuration options for interrupt sources. The cell is a u32 - and defines the interrupt number. -- reg : The register bank for the VIC. - -Optional properties: - -- interrupts : Interrupt source for parent controllers if the VIC is nested. -- valid-mask : A one cell big bit mask of valid interrupt sources. Each bit - represents single interrupt source, starting from source 0 at LSb and ending - at source 31 at MSb. A bit that is set means that the source is wired and - clear means otherwise. If unspecified, defaults to all valid. -- valid-wakeup-mask : A one cell big bit mask of interrupt sources that can be - configured as wake up source for the system. Order of bits is the same as for - valid-mask property. A set bit means that this interrupt source can be - configured as a wake up source for the system. If unspecied, defaults to all - interrupt sources configurable as wake up sources. - -Example: - - vic0: interrupt-controller@60000 { - compatible = "arm,pl192-vic"; - interrupt-controller; - #interrupt-cells = <1>; - reg = <0x60000 0x1000>; - - valid-mask = <0xffffff7f>; - valid-wakeup-mask = <0x0000ff7f>; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml new file mode 100644 index 000000000000..0075e72fe8c1 --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,vic.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/arm,vic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Vectored Interrupt Controller + +maintainers: + - Rob Herring <robh@kernel.org> + +description: |+ + One or more Vectored Interrupt Controllers (VIC's) can be connected in an + ARM system for interrupt routing. For multiple controllers they can either + be nested or have the outputs wire-OR'd together. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + enum: + - arm,pl190-vic + - arm,pl192-vic + - arm,versatile-vic + + interrupt-controller: true + + "#interrupt-cells": + const: 1 + description: + The number of cells to define the interrupts. It must be 1 as the + VIC has no configuration options for interrupt sources. The single + cell defines the interrupt number. + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + valid-mask: + description: + A one cell big bit mask of valid interrupt sources. Each bit + represents single interrupt source, starting from source 0 at + LSb and ending at source 31 at MSb. A bit that is set means + that the source is wired and clear means otherwise. If unspecified, + defaults to all valid. + $ref: /schemas/types.yaml#/definitions/uint32 + + valid-wakeup-mask: + description: + A one cell big bit mask of interrupt sources that can be configured + as wake up source for the system. Order of bits is the same as for + valid-mask property. A set bit means that this interrupt source + can be configured as a wake up source for the system. If unspecied, + defaults to all interrupt sources configurable as wake up sources. + $ref: /schemas/types.yaml#/definitions/uint32 + +required: + - compatible + - reg + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + // PL192 VIC + vic0: interrupt-controller@60000 { + compatible = "arm,pl192-vic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x60000 0x1000>; + + valid-mask = <0xffffff7f>; + valid-wakeup-mask = <0x0000ff7f>; + }; + +... diff --git a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml index 3b11a1a15398..bcb5e20fa9ca 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/fsl,irqsteer.yaml @@ -35,7 +35,6 @@ properties: - description: output interrupt 6 - description: output interrupt 7 minItems: 1 - maxItems: 8 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml index 067165c4b836..edf26452dc72 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/loongson,liointc.yaml @@ -50,7 +50,6 @@ properties: - const: int2 - const: int3 minItems: 1 - maxItems: 4 '#interrupt-cells': const: 2 diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml index 9731dd4421a1..051beb45d998 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,pruss-intc.yaml @@ -134,7 +134,7 @@ examples: /* AM4376 PRU-ICSS */ #include <dt-bindings/interrupt-controller/arm-gic.h> pruss@0 { - compatible = "ti,am4376-pruss"; + compatible = "ti,am4376-pruss1"; reg = <0x0 0x40000>; #address-cells = <1>; #size-cells = <1>; diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml index 5951c6f98c74..e87bfbcc6913 100644 --- a/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml +++ b/Documentation/devicetree/bindings/iommu/arm,smmu-v3.yaml @@ -38,7 +38,6 @@ properties: If provided, then the combined interrupt will be used in preference to any others. - minItems: 2 - maxItems: 4 items: - const: eventq # Event Queue not empty - const: gerror # Global Error activated diff --git a/Documentation/devicetree/bindings/iommu/iommu.txt b/Documentation/devicetree/bindings/iommu/iommu.txt index 3c36334e4f94..26ba9e530f13 100644 --- a/Documentation/devicetree/bindings/iommu/iommu.txt +++ b/Documentation/devicetree/bindings/iommu/iommu.txt @@ -92,6 +92,24 @@ Optional properties: tagging DMA transactions with an address space identifier. By default, this is 0, which means that the device only has one address space. +- dma-can-stall: When present, the master can wait for a transaction to + complete for an indefinite amount of time. Upon translation fault some + IOMMUs, instead of aborting the translation immediately, may first + notify the driver and keep the transaction in flight. This allows the OS + to inspect the fault and, for example, make physical pages resident + before updating the mappings and completing the transaction. Such IOMMU + accepts a limited number of simultaneous stalled transactions before + having to either put back-pressure on the master, or abort new faulting + transactions. + + Firmware has to opt-in stalling, because most buses and masters don't + support it. In particular it isn't compatible with PCI, where + transactions have to complete before a time limit. More generally it + won't work in systems and masters that haven't been designed for + stalling. For example the OS, in order to handle a stalled transaction, + may attempt to retrieve pages from secondary storage in a stalled + domain, leading to a deadlock. + Notes: ====== diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index dda44976acc1..02c69a95c332 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -49,7 +49,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 description: Specifiers for the MMU fault interrupts. Not required for cache IPMMUs. items: diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt b/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt deleted file mode 100644 index 6ecefea1c6f9..000000000000 --- a/Documentation/devicetree/bindings/iommu/rockchip,iommu.txt +++ /dev/null @@ -1,38 +0,0 @@ -Rockchip IOMMU -============== - -A Rockchip DRM iommu translates io virtual addresses to physical addresses for -its master device. Each slave device is bound to a single master device, and -shares its clocks, power domain and irq. - -Required properties: -- compatible : Should be "rockchip,iommu" -- reg : Address space for the configuration registers -- interrupts : Interrupt specifier for the IOMMU instance -- interrupt-names : Interrupt name for the IOMMU instance -- #iommu-cells : Should be <0>. This indicates the iommu is a - "single-master" device, and needs no additional information - to associate with its master device. See: - Documentation/devicetree/bindings/iommu/iommu.txt -- clocks : A list of clocks required for the IOMMU to be accessible by - the host CPU. -- clock-names : Should contain the following: - "iface" - Main peripheral bus clock (PCLK/HCL) (required) - "aclk" - AXI bus clock (required) - -Optional properties: -- rockchip,disable-mmu-reset : Don't use the mmu reset operation. - Some mmu instances may produce unexpected results - when the reset operation is used. - -Example: - - vopl_mmu: iommu@ff940300 { - compatible = "rockchip,iommu"; - reg = <0xff940300 0x100>; - interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "vopl_mmu"; - clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; - clock-names = "aclk", "iface"; - #iommu-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml new file mode 100644 index 000000000000..d2e28a9e3545 --- /dev/null +++ b/Documentation/devicetree/bindings/iommu/rockchip,iommu.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iommu/rockchip,iommu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip IOMMU + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: |+ + A Rockchip DRM iommu translates io virtual addresses to physical addresses for + its master device. Each slave device is bound to a single master device and + shares its clocks, power domain and irq. + + For information on assigning IOMMU controller to its peripheral devices, + see generic IOMMU bindings. + +properties: + compatible: + enum: + - rockchip,iommu + - rockchip,rk3568-iommu + + reg: + items: + - description: configuration registers for MMU instance 0 + - description: configuration registers for MMU instance 1 + minItems: 1 + maxItems: 2 + + interrupts: + items: + - description: interruption for MMU instance 0 + - description: interruption for MMU instance 1 + minItems: 1 + maxItems: 2 + + clocks: + items: + - description: Core clock + - description: Interface clock + + clock-names: + items: + - const: aclk + - const: iface + + "#iommu-cells": + const: 0 + + power-domains: + maxItems: 1 + + rockchip,disable-mmu-reset: + $ref: /schemas/types.yaml#/definitions/flag + description: | + Do not use the mmu reset operation. + Some mmu instances may produce unexpected results + when the reset operation is used. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - "#iommu-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3399-cru.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + vopl_mmu: iommu@ff940300 { + compatible = "rockchip,iommu"; + reg = <0xff940300 0x100>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cru ACLK_VOP1>, <&cru HCLK_VOP1>; + clock-names = "aclk", "iface"; + #iommu-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml new file mode 100644 index 000000000000..4ff6fabfcb30 --- /dev/null +++ b/Documentation/devicetree/bindings/ipmi/aspeed,ast2400-kcs-bmc.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ipmi/aspeed,ast2400-kcs-bmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ASPEED BMC KCS Devices + +maintainers: + - Andrew Jeffery <andrew@aj.id.au> + +description: | + The Aspeed BMC SoCs typically use the Keyboard-Controller-Style (KCS) + interfaces on the LPC bus for in-band IPMI communication with their host. + +properties: + compatible: + oneOf: + - description: Channel ID derived from reg + items: + enum: + - aspeed,ast2400-kcs-bmc-v2 + - aspeed,ast2500-kcs-bmc-v2 + - aspeed,ast2600-kcs-bmc + + - description: Old-style with explicit channel ID, no reg + deprecated: true + items: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + + interrupts: + maxItems: 1 + + reg: + # maxItems: 3 + items: + - description: IDR register + - description: ODR register + - description: STR register + + aspeed,lpc-io-reg: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + minItems: 1 + maxItems: 2 + description: | + The host CPU LPC IO data and status addresses for the device. For most + channels the status address is derived from the data address, but the + status address may be optionally provided. + + aspeed,lpc-interrupts: + $ref: "/schemas/types.yaml#/definitions/uint32-array" + minItems: 2 + maxItems: 2 + description: | + A 2-cell property expressing the LPC SerIRQ number and the interrupt + level/sense encoding (specified in the standard fashion). + + Note that the generated interrupt is issued from the BMC to the host, and + thus the target interrupt controller is not captured by the BMC's + devicetree. + + kcs_chan: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The LPC channel number in the controller + + kcs_addr: + deprecated: true + $ref: '/schemas/types.yaml#/definitions/uint32' + description: The host CPU IO map address + +required: + - compatible + - interrupts + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - aspeed,ast2400-kcs-bmc + - aspeed,ast2500-kcs-bmc + then: + required: + - kcs_chan + - kcs_addr + else: + required: + - reg + - aspeed,lpc-io-reg + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + kcs3: kcs@24 { + compatible = "aspeed,ast2600-kcs-bmc"; + reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; + aspeed,lpc-io-reg = <0xca2>; + aspeed,lpc-interrupts = <11 IRQ_TYPE_LEVEL_LOW>; + interrupts = <8>; + }; diff --git a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt b/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt deleted file mode 100644 index 193e71ca96b0..000000000000 --- a/Documentation/devicetree/bindings/ipmi/aspeed-kcs-bmc.txt +++ /dev/null @@ -1,33 +0,0 @@ -# Aspeed KCS (Keyboard Controller Style) IPMI interface - -The Aspeed SOCs (AST2400 and AST2500) are commonly used as BMCs -(Baseboard Management Controllers) and the KCS interface can be -used to perform in-band IPMI communication with their host. - -## v1 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc" - "aspeed,ast2500-kcs-bmc" -- interrupts : interrupt generated by the controller -- kcs_chan : The LPC channel number in the controller -- kcs_addr : The host CPU IO map address - -## v2 -Required properties: -- compatible : should be one of - "aspeed,ast2400-kcs-bmc-v2" - "aspeed,ast2500-kcs-bmc-v2" -- reg : The address and size of the IDR, ODR and STR registers -- interrupts : interrupt generated by the controller -- aspeed,lpc-io-reg : The host CPU LPC IO address for the device - -Example: - - kcs3: kcs@24 { - compatible = "aspeed,ast2500-kcs-bmc-v2"; - reg = <0x24 0x1>, <0x30 0x1>, <0x3c 0x1>; - aspeed,lpc-reg = <0xca2>; - interrupts = <8>; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml new file mode 100644 index 000000000000..e0ac68694b63 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/backlight/richtek,rt4831-backlight.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/backlight/richtek,rt4831-backlight.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4831 Backlight + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + RT4831 is a mutifunctional device that can provide power to the LCD display + and LCD backlight. + + For the LCD backlight, it can provide four channel WLED driving capability. + Each channel driving current is up to 30mA + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf + +allOf: + - $ref: common.yaml# + +properties: + compatible: + const: richtek,rt4831-backlight + + default-brightness: + minimum: 0 + maximum: 2048 + + max-brightness: + minimum: 0 + maximum: 2048 + + richtek,pwm-enable: + description: | + Specify the backlight dimming following by PWM duty or by SW control. + type: boolean + + richtek,bled-ovp-sel: + description: | + Backlight OVP level selection, currently support 17V/21V/25V/29V. + $ref: /schemas/types.yaml#/definitions/uint8 + default: 1 + minimum: 0 + maximum: 3 + + richtek,channel-use: + description: | + Backlight LED channel to be used. + BIT 0/1/2/3 is used to indicate led channel 1/2/3/4 enable or disable. + $ref: /schemas/types.yaml#/definitions/uint8 + minimum: 1 + maximum: 15 + +required: + - compatible + - richtek,channel-use + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml index d07eb00b97c8..bd49c201477d 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhu.yaml @@ -101,11 +101,19 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - mhu_client_scb: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; + firmware { + scpi { + compatible = "arm,scpi"; mboxes = <&mhuA 1>; /* HP-NonSecure */ + shmem = <&cpu_scp_hpri>; /* HP-NonSecure */ + + scpi_devpd: power-controller { + compatible = "arm,scpi-power-domains"; + num-domains = <2>; + #power-domain-cells = <1>; + }; }; }; @@ -125,10 +133,36 @@ examples: clocks = <&clock 0 2 1>; clock-names = "apb_pclk"; }; + }; - mhu_client_scpi: scpi@2f000000 { - compatible = "arm,scpi"; - reg = <0 0x2f000000 0 0x200>; - mboxes = <&mhuB 1 4>; /* HP-NonSecure, 5th doorbell */ + firmware { + scmi { + compatible = "arm,scmi"; + mboxes = <&mhuB 0 0>, /* LP-NonSecure, 1st doorbell */ + <&mhuB 0 1>; /* LP-NonSecure, 2nd doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_lpri0>, + <&cpu_scp_lpri1>; + + #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>; + + mboxes = <&mhuB 1 2>, /* HP-NonSecure, 3rd doorbell */ + <&mhuB 1 3>; /* HP-NonSecure, 4th doorbell */ + mbox-names = "tx", "rx"; + shmem = <&cpu_scp_hpri0>, + <&cpu_scp_hpri1>; + }; }; }; + +... diff --git a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml index 6608545ea66f..a4f1fe63659a 100644 --- a/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml +++ b/Documentation/devicetree/bindings/mailbox/arm,mhuv2.yaml @@ -192,18 +192,17 @@ examples: arm,mhuv2-protocols = <1 1>, <1 7>, <0 2>; }; - mhu_client: scb@2e000000 { - compatible = "fujitsu,mb86s70-scb-1.0"; - reg = <0 0x2e000000 0 0x4000>; - - mboxes = - //data-transfer protocol with 5 windows, mhu-tx - <&mhu_tx 2 0>, - //data-transfer protocol with 7 windows, mhu-tx - <&mhu_tx 3 0>, - //doorbell protocol channel 4, doorbell 27, mhu-tx - <&mhu_tx 4 27>, - //data-transfer protocol with 1 window, mhu-rx - <&mhu_rx 0 0>; + mhu_client: dsp@596e8000 { + compatible = "fsl,imx8qxp-dsp"; + reg = <0 0x596e8000 0 0x88000>; + clocks = <&adma_lpcg 0>, <&adma_lpcg 1>, <&adma_lpcg 2>; + clock-names = "ipg", "ocram", "core"; + power-domains = <&pd 0>, <&pd 1>, <&pd 2>, <&pd 3>; + mbox-names = "txdb0", "txdb1", "rxdb0", "rxdb1"; + mboxes = <&mhu_tx 2 0>, //data-transfer protocol with 5 windows, mhu-tx + <&mhu_tx 3 0>, //data-transfer protocol with 7 windows, mhu-tx + <&mhu_rx 2 27>, //doorbell protocol channel 2, doorbell 27, mhu-rx + <&mhu_rx 0 0>; //data-transfer protocol with 1 window, mhu-rx + memory-region = <&dsp_reserved>; }; }; diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index 1a3dff277e2b..675ad9de15bb 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -26,6 +26,7 @@ properties: oneOf: - const: fsl,imx6sx-mu - const: fsl,imx7ulp-mu + - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu - items: - enum: diff --git a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml new file mode 100644 index 000000000000..bbb173ea483c --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml @@ -0,0 +1,47 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mailbox/microchip,polarfire-soc-mailbox.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +properties: + compatible: + const: microchip,polarfire-soc-mailbox + + reg: + items: + - description: mailbox data registers + - description: mailbox interrupt registers + + interrupts: + maxItems: 1 + + "#mbox-cells": + const: 1 + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + mbox: mailbox@37020000 { + compatible = "microchip,polarfire-soc-mailbox"; + reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; + interrupt-parent = <&L1>; + interrupts = <96>; + #mbox-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt b/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt deleted file mode 100644 index 12371f5c6cd9..000000000000 --- a/Documentation/devicetree/bindings/mailbox/omap-mailbox.txt +++ /dev/null @@ -1,184 +0,0 @@ -OMAP2+ and K3 Mailbox -===================== - -The OMAP mailbox hardware facilitates communication between different processors -using a queued mailbox interrupt mechanism. The IP block is external to the -various processor subsystems and is connected on an interconnect bus. The -communication is achieved through a set of registers for message storage and -interrupt configuration registers. - -Each mailbox IP block/cluster has a certain number of h/w fifo queues and output -interrupt lines. An output interrupt line is routed to an interrupt controller -within a processor subsystem, and there can be more than one line going to a -specific processor's interrupt controller. The interrupt line connections are -fixed for an instance and are dictated by the IP integration into the SoC -(excluding the SoCs that have a Interrupt Crossbar IP). Each interrupt line is -programmable through a set of interrupt configuration registers, and have a rx -and tx interrupt source per h/w fifo. Communication between different processors -is achieved through the appropriate programming of the rx and tx interrupt -sources on the appropriate interrupt lines. - -The number of h/w fifo queues and interrupt lines dictate the usable registers. -All the current OMAP SoCs except for the newest DRA7xx SoC has a single IP -instance. DRA7xx has multiple instances with different number of h/w fifo queues -and interrupt lines between different instances. The interrupt lines can also be -routed to different processor sub-systems on DRA7xx as they are routed through -the Crossbar, a kind of interrupt router/multiplexer. The K3 AM65x and J721E -SoCs has each of these instances form a cluster and combine multiple clusters -into a single IP block present within the Main NavSS. The interrupt lines from -all these clusters are multiplexed and routed to different processor subsystems -over a limited number of common interrupt output lines of an Interrupt Router. -The AM64x SoCS also uses a single IP block comprising of multiple clusters, -but the number of clusters are smaller, and the interrupt output lines are -connected directly to various processors. - -Mailbox Device Node: -==================== -A Mailbox device node is used to represent a Mailbox IP instance/cluster within -a SoC. The sub-mailboxes are represented as child nodes of this parent node. - -Required properties: --------------------- -- compatible: Should be one of the following, - "ti,omap2-mailbox" for OMAP2420, OMAP2430 SoCs - "ti,omap3-mailbox" for OMAP3430, OMAP3630 SoCs - "ti,omap4-mailbox" for OMAP44xx, OMAP54xx, AM33xx, - AM43xx and DRA7xx SoCs - "ti,am654-mailbox" for K3 AM65x and J721E SoCs - "ti,am64-mailbox" for K3 AM64x SoCs -- reg: Contains the mailbox register address range (base - address and length) -- interrupts: Contains the interrupt information for the mailbox - device. The format is dependent on which interrupt - controller the Mailbox device uses -- #mbox-cells: Common mailbox binding property to identify the number - of cells required for the mailbox specifier. Should be - 1 -- ti,mbox-num-users: Number of targets (processor devices) that the mailbox - device can interrupt -- ti,mbox-num-fifos: Number of h/w fifo queues within the mailbox IP block - -SoC-specific Required properties: ---------------------------------- -The following are mandatory properties for the OMAP architecture based SoCs -only: -- ti,hwmods: Name of the hwmod associated with the mailbox. This - should be defined in the mailbox node only if the node - is not defined as a child node of a corresponding sysc - interconnect node. - -The following are mandatory properties for the K3 AM65x and J721E SoCs only: -- interrupt-parent: Should contain a phandle to the TI-SCI interrupt - controller node that is used to dynamically program - the interrupt routes between the IP and the main GIC - controllers. See the following binding for additional - details, - Documentation/devicetree/bindings/interrupt-controller/ti,sci-intr.yaml - -Child Nodes: -============ -A child node is used for representing the actual sub-mailbox device that is -used for the communication between the host processor and a remote processor. -Each child node should have a unique node name across all the different -mailbox device nodes. - -Required properties: --------------------- -- ti,mbox-tx: sub-mailbox descriptor property defining a Tx fifo -- ti,mbox-rx: sub-mailbox descriptor property defining a Rx fifo - -Sub-mailbox Descriptor Data ---------------------------- -Each of the above ti,mbox-tx and ti,mbox-rx properties should have 3 cells of -data that represent the following: - Cell #1 (fifo_id) - mailbox fifo id used either for transmitting - (ti,mbox-tx) or for receiving (ti,mbox-rx) - Cell #2 (irq_id) - irq identifier index number to use from the parent's - interrupts data. Should be 0 for most of the cases, a - positive index value is seen only on mailboxes that have - multiple interrupt lines connected to the MPU processor. - Cell #3 (usr_id) - mailbox user id for identifying the interrupt line - associated with generating a tx/rx fifo interrupt. - -Optional Properties: --------------------- -- ti,mbox-send-noirq: Quirk flag to allow the client user of this sub-mailbox - to send messages without triggering a Tx ready interrupt, - and to control the Tx ticker. Should be used only on - sub-mailboxes used to communicate with WkupM3 remote - processor on AM33xx/AM43xx SoCs. - -Mailbox Users: -============== -A device needing to communicate with a target processor device should specify -them using the common mailbox binding properties, "mboxes" and the optional -"mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt -for details). 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. The equivalent -"mbox-names" property value can be used to give a name to the communication channel -to be used by the client user. - - -Example: --------- - -1. /* OMAP4 */ -mailbox: mailbox@4a0f4000 { - compatible = "ti,omap4-mailbox"; - reg = <0x4a0f4000 0x200>; - interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <3>; - ti,mbox-num-fifos = <8>; - mbox_ipu: mbox_ipu { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <1 0 0>; - }; - mbox_dsp: mbox_dsp { - ti,mbox-tx = <3 0 0>; - ti,mbox-rx = <2 0 0>; - }; -}; - -dsp { - ... - mboxes = <&mailbox &mbox_dsp>; - ... -}; - -2. /* AM33xx */ -mailbox: mailbox@480c8000 { - compatible = "ti,omap4-mailbox"; - reg = <0x480C8000 0x200>; - interrupts = <77>; - ti,hwmods = "mailbox"; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <8>; - mbox_wkupm3: wkup_m3 { - ti,mbox-tx = <0 0 0>; - ti,mbox-rx = <0 0 3>; - }; -}; - -3. /* AM65x */ -&cbass_main { - cbass_main_navss: interconnect0 { - mailbox0_cluster0: mailbox@31f80000 { - compatible = "ti,am654-mailbox"; - reg = <0x00 0x31f80000 0x00 0x200>; - #mbox-cells = <1>; - ti,mbox-num-users = <4>; - ti,mbox-num-fifos = <16>; - interrupt-parent = <&intr_main_navss>; - interrupts = <164 0>; - - mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { - ti,mbox-tx = <1 0 0>; - ti,mbox-rx = <0 0 0>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 5dc1173d03fd..8878ec00820e 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -19,6 +19,7 @@ properties: - qcom,ipq6018-apcs-apps-global - qcom,ipq8074-apcs-apps-global - qcom,msm8916-apcs-kpss-global + - qcom,msm8939-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global @@ -27,6 +28,7 @@ properties: - qcom,sc8180x-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared reg: @@ -75,6 +77,7 @@ allOf: - qcom,sc7180-apss-shared - qcom,sdm660-apcs-hmss-global - qcom,sdm845-apss-shared + - qcom,sm6125-apcs-hmss-global - qcom,sm8150-apss-shared then: properties: diff --git a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml index 3b7ab61a144f..b15da9ba90b2 100644 --- a/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml +++ b/Documentation/devicetree/bindings/mailbox/st,stm32-ipcc.yaml @@ -32,7 +32,6 @@ properties: - description: tx channel free - description: wakeup source minItems: 2 - maxItems: 3 interrupt-names: items: @@ -40,7 +39,6 @@ properties: - const: tx - const: wakeup minItems: 2 - maxItems: 3 wakeup-source: true diff --git a/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml new file mode 100644 index 000000000000..e864d798168d --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml @@ -0,0 +1,308 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/ti,omap-mailbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI OMAP2+ and K3 Mailbox devices + +maintainers: + - Suman Anna <s-anna@ti.com> + +description: | + The OMAP Mailbox hardware facilitates communication between different + processors using a queued mailbox interrupt mechanism. The IP block is + external to the various processor subsystems and is connected on an + interconnect bus. The communication is achieved through a set of registers + for message storage and interrupt configuration registers. + + Each mailbox IP block/cluster has a certain number of h/w fifo queues and + output interrupt lines. An output interrupt line is routed to an interrupt + controller within a processor subsystem, and there can be more than one line + going to a specific processor's interrupt controller. The interrupt line + connections are fixed for an instance and are dictated by the IP integration + into the SoC (excluding the SoCs that have an Interrupt Crossbar or an + Interrupt Router IP). Each interrupt line is programmable through a set of + interrupt configuration registers, and have a rx and tx interrupt source per + h/w fifo. Communication between different processors is achieved through the + appropriate programming of the rx and tx interrupt sources on the appropriate + interrupt lines. + + The number of h/w fifo queues and interrupt lines dictate the usable + registers. All the current OMAP SoCs except for the newest DRA7xx SoC has a + single IP instance. DRA7xx has multiple instances with different number of + h/w fifo queues and interrupt lines between different instances. The interrupt + lines can also be routed to different processor sub-systems on DRA7xx as they + are routed through the Crossbar, a kind of interrupt router/multiplexer. The + K3 AM65x, J721E and J7200 SoCs has each of these instances form a cluster and + combine multiple clusters into a single IP block present within the Main + NavSS. The interrupt lines from all these clusters are multiplexed and routed + to different processor subsystems over a limited number of common interrupt + output lines of an Interrupt Router. The AM64x SoCS also uses a single IP + block comprising of multiple clusters, but the number of clusters are + smaller, and the interrupt output lines are connected directly to various + processors. + + Mailbox Controller Nodes + ========================= + A Mailbox device node is used to represent a Mailbox IP instance/cluster + within a SoC. The sub-mailboxes (actual communication channels) are + represented as child nodes of this parent node. + + Mailbox Users + ============== + A device needing to communicate with a target processor device should specify + them using the common mailbox binding properties, "mboxes" and the optional + "mbox-names" (please see Documentation/devicetree/bindings/mailbox/mailbox.txt + for details). 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. + The equivalent "mbox-names" property value can be used to give a name to the + communication channel to be used by the client user. + +$defs: + omap-mbox-descriptor: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: + The omap-mbox-descriptor is made of up of 3 cells and represents a single + uni-directional communication channel. A typical sub-mailbox device uses + two such channels - one for transmitting (Tx) and one for receiving (Rx). + items: + - description: + mailbox fifo id used either for transmitting on ti,mbox-tx channel or + for receiving on ti,mbox-rx channel (fifo_id). This is the hardware + fifo number within a mailbox cluster. + - description: + irq identifier index number to use from the parent's interrupts data. + Should be 0 for most of the cases, a positive index value is seen only + on mailboxes that have multiple interrupt lines connected to the MPU + processor (irq_id). This is an index number in the listed interrupts + property in the DT nodes. + - description: + mailbox user id for identifying the interrupt line associated with + generating a tx/rx fifo interrupt (usr_id). This is the hardware + user id number within a mailbox cluster. + + omap-sub-mailbox: + type: object + description: + The omap-sub-mailbox is a child node within a Mailbox controller device + node and represents the actual communication channel used to send and + receive messages between the host processor and a remote processor. Each + child node should have a unique node name across all the different mailbox + device nodes. + + properties: + ti,mbox-tx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Tx fifo. + + ti,mbox-rx: + $ref: "#/$defs/omap-mbox-descriptor" + description: sub-mailbox descriptor property defining a Rx fifo. + + ti,mbox-send-noirq: + type: boolean + description: + Quirk flag to allow the client user of this sub-mailbox to send + messages without triggering a Tx ready interrupt, and to control + the Tx ticker. Should be used only on sub-mailboxes used to + communicate with WkupM3 remote processor on AM33xx/AM43xx SoCs. + + required: + - ti,mbox-tx + - ti,mbox-rx + +properties: + compatible: + enum: + - ti,omap2-mailbox # for OMAP2420, OMAP2430 SoCs + - ti,omap3-mailbox # for OMAP3430, OMAP3630 SoCs + - ti,omap4-mailbox # for OMAP44xx, OMAP54xx, AM33xx, AM43xx and DRA7xx SoCs + - ti,am654-mailbox # for K3 AM65x, J721E and J7200 SoCs + - ti,am64-mailbox # for K3 AM64x SoCs + + reg: + maxItems: 1 + + interrupts: + description: + Contains the interrupt information for the mailbox device. The format is + dependent on which interrupt controller the Mailbox device uses. The + number of interrupts listed will at most be the value specified in + ti,mbox-num-users property, but is usually limited by the number of + interrupts reaching the main processor. An interrupt-parent property + is required on SoCs where the interrupt lines are connected through a + Interrupt Router before reaching the main processor's GIC. + + "#mbox-cells": + const: 1 + description: + The specifier is a phandle to an omap-sub-mailbox device. + + ti,mbox-num-users: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Number of targets (processor devices) that the mailbox device can + interrupt. + + ti,mbox-num-fifos: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Number of h/w fifo queues within the mailbox IP block. + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + description: + Name of the hwmod associated with the mailbox. This should be defined + in the mailbox node only if the node is not defined as a child node of + a corresponding sysc interconnect node. + + This property is only needed on some legacy OMAP SoCs which have not + yet been converted to the ti,sysc interconnect hierarachy, but is + otherwise considered obsolete. + +patternProperties: + "^mbox-[a-z0-9-]+$": + $ref: "#/$defs/omap-sub-mailbox" + +required: + - compatible + - reg + - interrupts + - "#mbox-cells" + - ti,mbox-num-users + - ti,mbox-num-fifos + +allOf: + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + then: + required: + - interrupt-parent + + - if: + properties: + compatible: + enum: + - ti,am654-mailbox + - ti,am64-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 16 + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap4-mailbox + then: + properties: + ti,mbox-num-users: + enum: [3, 4] + ti,mbox-num-fifos: + enum: [8, 12] + interrupts: + minItems: 1 + maxItems: 4 + + - if: + properties: + compatible: + enum: + - ti,omap3-mailbox + then: + properties: + ti,mbox-num-users: + const: 2 + ti,mbox-num-fifos: + const: 2 + interrupts: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + enum: + - ti,omap2-mailbox + then: + properties: + ti,mbox-num-users: + const: 4 + ti,mbox-num-fifos: + const: 6 + interrupts: + minItems: 1 + maxItems: 2 + +additionalProperties: false + +examples: + - | + /* OMAP4 */ + #include <dt-bindings/interrupt-controller/arm-gic.h> + mailbox: mailbox@4a0f4000 { + compatible = "ti,omap4-mailbox"; + reg = <0x4a0f4000 0x200>; + interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH>; + #mbox-cells = <1>; + ti,mbox-num-users = <3>; + ti,mbox-num-fifos = <8>; + + mbox_ipu: mbox-ipu { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <1 0 0>; + }; + mbox_dsp: mbox-dsp { + ti,mbox-tx = <3 0 0>; + ti,mbox-rx = <2 0 0>; + }; + }; + + dsp { + mboxes = <&mailbox &mbox_dsp>; + }; + + - | + /* AM33xx */ + mailbox1: mailbox@480c8000 { + compatible = "ti,omap4-mailbox"; + reg = <0x480c8000 0x200>; + interrupts = <77>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <8>; + + mbox_wkupm3: mbox-wkup-m3 { + ti,mbox-tx = <0 0 0>; + ti,mbox-rx = <0 0 3>; + ti,mbox-send-noirq; + }; + }; + + - | + /* AM65x */ + mailbox0_cluster0: mailbox@31f80000 { + compatible = "ti,am654-mailbox"; + reg = <0x31f80000 0x200>; + #mbox-cells = <1>; + ti,mbox-num-users = <4>; + ti,mbox-num-fifos = <16>; + interrupt-parent = <&intr_main_navss>; + interrupts = <436>; + + mbox_mcu_r5fss0_core0: mbox-mcu-r5fss0-core0 { + ti,mbox-tx = <1 0 0>; + ti,mbox-rx = <0 0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml index b902495d278b..5044c4bb94e0 100644 --- a/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml +++ b/Documentation/devicetree/bindings/media/amlogic,gx-vdec.yaml @@ -67,7 +67,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dos_parser - const: dos diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml index bcfd93739b4f..3ce4af143a3a 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7180.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.yaml @@ -36,7 +36,13 @@ properties: maxItems: 1 port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false ports: true diff --git a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml index df634b0c1f8c..de15cebe2955 100644 --- a/Documentation/devicetree/bindings/media/i2c/adv7604.yaml +++ b/Documentation/devicetree/bindings/media/i2c/adv7604.yaml @@ -30,7 +30,6 @@ properties: reg-names: minItems: 1 - maxItems: 13 items: - const: main - enum: [ avlink, cec, infoframe, esdp, dpp, afe, rep, edid, hdmi, test, cp, vdp ] diff --git a/Documentation/devicetree/bindings/media/i2c/imx258.yaml b/Documentation/devicetree/bindings/media/i2c/imx258.yaml index 515317eff41a..cde0f7383b2a 100644 --- a/Documentation/devicetree/bindings/media/i2c/imx258.yaml +++ b/Documentation/devicetree/bindings/media/i2c/imx258.yaml @@ -49,7 +49,7 @@ properties: # See ../video-interfaces.txt for more details port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index ee16102fdfe7..02f656e78700 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -111,17 +111,10 @@ properties: i2c-mux: type: object + $ref: /schemas/i2c/i2c-mux.yaml# + unevaluatedProperties: false description: | - Each GMSL link is modelled as a child bus of an i2c bus - multiplexer/switch, in accordance with bindings described in - Documentation/devicetree/bindings/i2c/i2c-mux.txt. - - properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 + Each GMSL link is modelled as a child bus of an i2c bus multiplexer/switch. patternProperties: "^i2c@[0-3]$": @@ -133,12 +126,6 @@ properties: channels. properties: - '#address-cells': - const: 1 - - '#size-cells': - const: 0 - reg: description: The index of the GMSL channel. maxItems: 1 @@ -173,10 +160,6 @@ properties: additionalProperties: false - additionalProperties: false - - additionalProperties: false - required: - compatible - reg diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml index 9149f5685688..246dc5fec716 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov5648.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml index 0699c7e4fdeb..b962863e4f65 100644 --- a/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml +++ b/Documentation/devicetree/bindings/media/i2c/ovti,ov8865.yaml @@ -45,7 +45,7 @@ properties: port: description: MIPI CSI-2 transmitter port - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base additionalProperties: false properties: diff --git a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml index 27cc5b7ff613..f5055b9db693 100644 --- a/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml +++ b/Documentation/devicetree/bindings/media/i2c/sony,imx334.yaml @@ -37,7 +37,7 @@ properties: port: additionalProperties: false - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base properties: endpoint: diff --git a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml index c14c7d827b00..b39b84c5f012 100644 --- a/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml +++ b/Documentation/devicetree/bindings/media/marvell,mmp2-ccic.yaml @@ -43,7 +43,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: AXI bus interface clock - description: Peripheral clock diff --git a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml index 04013e5dd044..90b4af2c9724 100644 --- a/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sc7180-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml index 04b9af4db191..177bf81544b1 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-venus-v2.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 3 - maxItems: 4 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml index 7b81bd7f2399..ebf8f3d866a5 100644 --- a/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-venus.yaml @@ -30,7 +30,6 @@ properties: power-domain-names: minItems: 2 - maxItems: 3 items: - const: venus - const: vcodec0 diff --git a/Documentation/devicetree/bindings/media/renesas,drif.yaml b/Documentation/devicetree/bindings/media/renesas,drif.yaml index 9cd56ff2c316..817a6d566738 100644 --- a/Documentation/devicetree/bindings/media/renesas,drif.yaml +++ b/Documentation/devicetree/bindings/media/renesas,drif.yaml @@ -78,7 +78,6 @@ properties: dma-names: minItems: 1 - maxItems: 2 items: - const: rx - const: rx diff --git a/Documentation/devicetree/bindings/media/renesas,vin.yaml b/Documentation/devicetree/bindings/media/renesas,vin.yaml index 39bb6db2fb32..c0442e79cbb4 100644 --- a/Documentation/devicetree/bindings/media/renesas,vin.yaml +++ b/Documentation/devicetree/bindings/media/renesas,vin.yaml @@ -120,7 +120,8 @@ properties: properties: port@0: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false description: Input port node, single endpoint describing a parallel input source. diff --git a/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml new file mode 100644 index 000000000000..7a63c85ef8c5 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/arm,pl353-smc.yaml @@ -0,0 +1,131 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/arm,pl353-smc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM PL353 Static Memory Controller (SMC) device-tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> + +description: + The PL353 Static Memory Controller is a bus where you can connect two kinds + of memory interfaces, which are NAND and memory mapped interfaces (such as + SRAM or NOR). + +# We need a select here so we don't match all nodes with 'arm,primecell' +select: + properties: + compatible: + contains: + const: arm,pl353-smc-r2p1 + required: + - compatible + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + items: + - const: arm,pl353-smc-r2p1 + - const: arm,primecell + + "#address-cells": + const: 2 + + "#size-cells": + const: 1 + + reg: + items: + - description: + Configuration registers for the host and sub-controllers. + The three chip select regions are defined in 'ranges'. + + clocks: + items: + - description: clock for the memory device bus + - description: main clock of the SMC + + clock-names: + items: + - const: memclk + - const: apb_pclk + + ranges: + minItems: 1 + maxItems: 3 + description: | + Memory bus areas for interacting with the devices. Reflects + the memory layout with four integer values following: + <cs-number> 0 <offset> <size> + items: + - description: NAND bank 0 + - description: NOR/SRAM bank 0 + - description: NOR/SRAM bank 1 + + interrupts: true + +patternProperties: + "@[0-3],[a-f0-9]+$": + type: object + description: | + The child device node represents the controller connected to the SMC + bus. The controller can be a NAND controller or a pair of any memory + mapped controllers such as NOR and SRAM controllers. + + properties: + compatible: + description: + Compatible of memory controller. + + reg: + items: + - items: + - description: | + Chip-select ID, as in the parent range property. + minimum: 0 + maximum: 2 + - description: | + Offset of the memory region requested by the device. + - description: | + Length of the memory region requested by the device. + + required: + - compatible + - reg + +required: + - compatible + - reg + - clock-names + - clocks + - "#address-cells" + - "#size-cells" + - ranges + +additionalProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index a08a32340987..e87e4382807c 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -53,14 +53,12 @@ properties: apb and smi are mandatory. the async is only for generation 1 smi HW. gals(global async local sync) also is optional, see below. minItems: 2 - maxItems: 4 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. - description: smi is the clock for transfer data and command. - - description: async is asynchronous clock, it help transform the smi - clock into the emi clock domain. - - description: gals0 is the path0 clock of gals. + - description: Either asynchronous clock to help transform the smi clock + into the emi clock domain on Gen1 h/w, or the path0 clock of gals. - description: gals1 is the path1 clock of gals. clock-names: diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index 7ed7839ff0a7..2353f6cf3c80 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -37,7 +37,6 @@ properties: description: | apb and smi are mandatory. gals(global async local sync) is optional. minItems: 2 - maxItems: 3 items: - description: apb is Advanced Peripheral Bus clock, It's the clock for setting the register. diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt deleted file mode 100644 index d2250498c36d..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.txt +++ /dev/null @@ -1,130 +0,0 @@ -Embedded Memory Controller - -Properties: -- name : Should be emc -- #address-cells : Should be 1 -- #size-cells : Should be 0 -- compatible : Should contain "nvidia,tegra20-emc". -- reg : Offset and length of the register set for the device -- nvidia,use-ram-code : If present, the sub-nodes will be addressed - and chosen using the ramcode board selector. If omitted, only one - set of tables can be present and said tables will be used - irrespective of ram-code configuration. -- interrupts : Should contain EMC General interrupt. -- clocks : Should contain EMC clock. -- nvidia,memory-controller : Phandle of the Memory Controller node. -- #interconnect-cells : Should be 0. -- operating-points-v2: See ../bindings/opp/opp.txt for details. - -For each opp entry in 'operating-points-v2' table: -- opp-supported-hw: One bitfield indicating SoC process ID mask - - A bitwise AND is performed against this value and if any bit - matches, the OPP gets enabled. - -Optional properties: -- power-domains: Phandle of the SoC "core" power domain. - -Child device nodes describe the memory settings for different configurations and clock rates. - -Example: - - opp_table: opp-table { - compatible = "operating-points-v2"; - - opp@36000000 { - opp-microvolt = <950000 950000 1300000>; - opp-hz = /bits/ 64 <36000000>; - }; - ... - }; - - memory-controller@7000f400 { - #address-cells = < 1 >; - #size-cells = < 0 >; - #interconnect-cells = <0>; - compatible = "nvidia,tegra20-emc"; - reg = <0x7000f400 0x400>; - interrupts = <0 78 0x04>; - clocks = <&tegra_car TEGRA20_CLK_EMC>; - nvidia,memory-controller = <&mc>; - power-domains = <&domain>; - operating-points-v2 = <&opp_table>; - } - - -Embedded Memory Controller ram-code table - -If the emc node has the nvidia,use-ram-code property present, then the -next level of nodes below the emc table are used to specify which settings -apply for which ram-code settings. - -If the emc node lacks the nvidia,use-ram-code property, this level is omitted -and the tables are stored directly under the emc node (see below). - -Properties: - -- name : Should be emc-tables -- nvidia,ram-code : the binary representation of the ram-code board strappings - for which this node (and children) are valid. - - - -Embedded Memory Controller configuration table - -This is a table containing the EMC register settings for the various -operating speeds of the memory controller. They are always located as -subnodes of the emc controller node. - -There are two ways of specifying which tables to use: - -* The simplest is if there is just one set of tables in the device tree, - and they will always be used (based on which frequency is used). - This is the preferred method, especially when firmware can fill in - this information based on the specific system information and just - pass it on to the kernel. - -* The slightly more complex one is when more than one memory configuration - might exist on the system. The Tegra20 platform handles this during - early boot by selecting one out of possible 4 memory settings based - on a 2-pin "ram code" bootstrap setting on the board. The values of - these strappings can be read through a register in the SoC, and thus - used to select which tables to use. - -Properties: -- name : Should be emc-table -- compatible : Should contain "nvidia,tegra20-emc-table". -- reg : either an opaque enumerator to tell different tables apart, or - the valid frequency for which the table should be used (in kHz). -- clock-frequency : the clock frequency for the EMC at which this - table should be used (in kHz). -- nvidia,emc-registers : a 46 word array of EMC registers to be programmed - for operation at the 'clock-frequency' setting. - The order and contents of the registers are: - RC, RFC, RAS, RP, R2W, W2R, R2P, W2P, RD_RCD, WR_RCD, RRD, REXT, - WDV, QUSE, QRST, QSAFE, RDV, REFRESH, BURST_REFRESH_NUM, PDEX2WR, - PDEX2RD, PCHG2PDEN, ACT2PDEN, AR2PDEN, RW2PDEN, TXSR, TCKE, TFAW, - TRPAB, TCLKSTABLE, TCLKSTOP, TREFBW, QUSE_EXTRA, FBIO_CFG6, ODT_WRITE, - ODT_READ, FBIO_CFG5, CFG_DIG_DLL, DLL_XFORM_DQS, DLL_XFORM_QUSE, - ZCAL_REF_CNT, ZCAL_WAIT_CNT, AUTO_CAL_INTERVAL, CFG_CLKTRIM_0, - CFG_CLKTRIM_1, CFG_CLKTRIM_2 - - emc-table@166000 { - reg = <166000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 166000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; - - emc-table@333000 { - reg = <333000>; - compatible = "nvidia,tegra20-emc-table"; - clock-frequency = < 333000 >; - nvidia,emc-registers = < 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 >; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml new file mode 100644 index 000000000000..cac6842dc8f1 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/nvidia,tegra20-emc.yaml @@ -0,0 +1,230 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/nvidia,tegra20-emc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NVIDIA Tegra20 SoC External Memory Controller + +maintainers: + - Dmitry Osipenko <digetx@gmail.com> + - Jon Hunter <jonathanh@nvidia.com> + - Thierry Reding <thierry.reding@gmail.com> + +description: | + The External Memory Controller (EMC) interfaces with the off-chip SDRAM to + service the request stream sent from Memory Controller. The EMC also has + various performance-affecting settings beyond the obvious SDRAM configuration + parameters and initialization settings. Tegra20 EMC supports multiple JEDEC + standard protocols: DDR1, LPDDR2 and DDR2. + +properties: + compatible: + const: nvidia,tegra20-emc + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + "#interconnect-cells": + const: 0 + + nvidia,memory-controller: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle of the Memory Controller node. + + power-domains: + maxItems: 1 + description: + Phandle of the SoC "core" power domain. + + operating-points-v2: + description: + Should contain freqs and voltages and opp-supported-hw property, which + is a bitfield indicating SoC process ID mask. + + nvidia,use-ram-code: + type: boolean + description: + If present, the emc-tables@ sub-nodes will be addressed. + +$defs: + emc-table: + type: object + properties: + compatible: + const: nvidia,tegra20-emc-table + + clock-frequency: + description: + Memory clock rate in kHz. + minimum: 1000 + maximum: 900000 + + reg: + maxItems: 1 + description: + Either an opaque enumerator to tell different tables apart, or + the valid frequency for which the table should be used (in kHz). + + nvidia,emc-registers: + description: + EMC timing characterization data. These are the registers + (see section "15.4.1 EMC Registers" in the TRM) whose values + need to be specified, according to the board documentation. + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: EMC_RC + - description: EMC_RFC + - description: EMC_RAS + - description: EMC_RP + - description: EMC_R2W + - description: EMC_W2R + - description: EMC_R2P + - description: EMC_W2P + - description: EMC_RD_RCD + - description: EMC_WR_RCD + - description: EMC_RRD + - description: EMC_REXT + - description: EMC_WDV + - description: EMC_QUSE + - description: EMC_QRST + - description: EMC_QSAFE + - description: EMC_RDV + - description: EMC_REFRESH + - description: EMC_BURST_REFRESH_NUM + - description: EMC_PDEX2WR + - description: EMC_PDEX2RD + - description: EMC_PCHG2PDEN + - description: EMC_ACT2PDEN + - description: EMC_AR2PDEN + - description: EMC_RW2PDEN + - description: EMC_TXSR + - description: EMC_TCKE + - description: EMC_TFAW + - description: EMC_TRPAB + - description: EMC_TCLKSTABLE + - description: EMC_TCLKSTOP + - description: EMC_TREFBW + - description: EMC_QUSE_EXTRA + - description: EMC_FBIO_CFG6 + - description: EMC_ODT_WRITE + - description: EMC_ODT_READ + - description: EMC_FBIO_CFG5 + - description: EMC_CFG_DIG_DLL + - description: EMC_DLL_XFORM_DQS + - description: EMC_DLL_XFORM_QUSE + - description: EMC_ZCAL_REF_CNT + - description: EMC_ZCAL_WAIT_CNT + - description: EMC_AUTO_CAL_INTERVAL + - description: EMC_CFG_CLKTRIM_0 + - description: EMC_CFG_CLKTRIM_1 + - description: EMC_CFG_CLKTRIM_2 + + required: + - clock-frequency + - compatible + - reg + - nvidia,emc-registers + + additionalProperties: false + +patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + "^emc-tables@[a-z0-9-]+$": + type: object + properties: + reg: + maxItems: 1 + description: + An opaque enumerator to tell different tables apart. + + nvidia,ram-code: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Value of RAM_CODE this timing set is used for. + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + patternProperties: + "^emc-table@[0-9]+$": + $ref: "#/$defs/emc-table" + + required: + - nvidia,ram-code + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - clocks + - nvidia,memory-controller + - "#interconnect-cells" + - operating-points-v2 + +additionalProperties: false + +examples: + - | + external-memory-controller@7000f400 { + compatible = "nvidia,tegra20-emc"; + reg = <0x7000f400 0x400>; + interrupts = <0 78 4>; + clocks = <&clock_controller 57>; + + nvidia,memory-controller = <&mc>; + operating-points-v2 = <&dvfs_opp_table>; + power-domains = <&domain>; + + #interconnect-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; + + nvidia,use-ram-code; + + emc-tables@0 { + nvidia,ram-code = <0>; + reg = <0>; + + #address-cells = <1>; + #size-cells = <0>; + + emc-table@333000 { + reg = <333000>; + compatible = "nvidia,tegra20-emc-table"; + clock-frequency = <333000>; + nvidia,emc-registers = <0x00000018 0x00000033 + 0x00000012 0x00000004 0x00000004 0x00000005 + 0x00000003 0x0000000c 0x00000006 0x00000006 + 0x00000003 0x00000001 0x00000004 0x00000005 + 0x00000004 0x00000009 0x0000000d 0x00000bff + 0x00000000 0x00000003 0x00000003 0x00000006 + 0x00000006 0x00000001 0x00000011 0x000000c8 + 0x00000003 0x0000000e 0x00000007 0x00000008 + 0x00000002 0x00000000 0x00000000 0x00000002 + 0x00000000 0x00000000 0x00000083 0xf0440303 + 0x007fe010 0x00001414 0x00000000 0x00000000 + 0x00000000 0x00000000 0x00000000 0x00000000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt b/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt deleted file mode 100644 index d56615fd343a..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/pl353-smc.txt +++ /dev/null @@ -1,47 +0,0 @@ -Device tree bindings for ARM PL353 static memory controller - -PL353 static memory controller supports two kinds of memory -interfaces.i.e NAND and SRAM/NOR interfaces. -The actual devices are instantiated from the child nodes of pl353 smc node. - -Required properties: -- compatible : Should be "arm,pl353-smc-r2p1", "arm,primecell". -- reg : Controller registers map and length. -- clock-names : List of input clock names - "memclk", "apb_pclk" - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). -- address-cells : Must be 2. -- size-cells : Must be 1. - -Child nodes: - For NAND the "arm,pl353-nand-r2p1" and for NOR the "cfi-flash" drivers are -supported as child nodes. - -for NAND partition information please refer the below file -Documentation/devicetree/bindings/mtd/partition.txt - -Example: - smcc: memory-controller@e000e000 - compatible = "arm,pl353-smc-r2p1", "arm,primecell"; - clock-names = "memclk", "apb_pclk"; - clocks = <&clkc 11>, <&clkc 44>; - reg = <0xe000e000 0x1000>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0xe1000000 0x1000000 //Nand CS Region - 0x1 0x0 0xe2000000 0x2000000 //SRAM/NOR CS Region - 0x2 0x0 0xe4000000 0x2000000>; //SRAM/NOR CS Region - nand_0: flash@e1000000 { - compatible = "arm,pl353-nand-r2p1" - reg = <0 0 0x1000000>; - (...) - }; - nor0: flash@e2000000 { - compatible = "cfi-flash"; - reg = <1 0 0x2000000>; - }; - nor1: flash@e4000000 { - compatible = "cfi-flash"; - reg = <2 0 0x2000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index 4dfa70a013ae..d793dd0316b7 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -117,6 +117,22 @@ properties: - "#address-cells" - "#size-cells" + cbas: + type: object + + description: + This device is used to signal when a detachable base is attached + to a Chrome OS tablet. This device cannot be detected at runtime. + + properties: + compatible: + const: google,cros-cbas + + required: + - compatible + + additionalProperties: false + patternProperties: "^i2c-tunnel[0-9]*$": type: object @@ -187,6 +203,10 @@ examples: proximity { compatible = "google,cros-ec-mkbp-proximity"; }; + + cbas { + compatible = "google,cros-cbas"; + }; }; }; diff --git a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt index b52e7a33f0f9..190230216de8 100644 --- a/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt +++ b/Documentation/devicetree/bindings/mfd/motorola-cpcap.txt @@ -16,8 +16,8 @@ Optional subnodes: The sub-functions of CPCAP get their own node with their own compatible values, which are described in the following files: -- Documentation/devicetree/bindings/power/supply/cpcap-battery.txt -- Documentation/devicetree/bindings/power/supply/cpcap-charger.txt +- Documentation/devicetree/bindings/power/supply/cpcap-battery.yaml +- Documentation/devicetree/bindings/power/supply/cpcap-charger.yaml - Documentation/devicetree/bindings/regulator/cpcap-regulator.txt - Documentation/devicetree/bindings/phy/phy-cpcap-usb.txt - Documentation/devicetree/bindings/input/cpcap-pwrbutton.txt diff --git a/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml new file mode 100644 index 000000000000..779936850ee0 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/qcom,pm8008.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/qcom,pm8008.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. PM8008 PMIC bindings + +maintainers: + - Guru Das Srinagesh <gurus@codeaurora.org> + +description: | + Qualcomm Technologies, Inc. PM8008 is a dedicated camera PMIC that integrates + all the necessary power management, housekeeping, and interface support + functions into a single IC. + +properties: + compatible: + const: qcom,pm8008 + + reg: + description: + I2C slave address. + + maxItems: 1 + + interrupts: + maxItems: 1 + + description: Parent interrupt. + + "#interrupt-cells": + const: 2 + + description: | + The first cell is the IRQ number, the second cell is the IRQ trigger + flag. All interrupts are listed in include/dt-bindings/mfd/qcom-pm8008.h. + + interrupt-controller: true + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^gpio@[0-9a-f]+$": + type: object + + description: | + The GPIO peripheral. This node may be specified twice, one for each GPIO. + + properties: + compatible: + const: qcom,pm8008-gpio + + reg: + description: Peripheral address of one of the two GPIO peripherals. + maxItems: 1 + + gpio-controller: true + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + "#gpio-cells": + const: 2 + + required: + - compatible + - reg + - gpio-controller + - interrupt-controller + - "#gpio-cells" + - "#interrupt-cells" + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/mfd/qcom-pm8008.h> + #include <dt-bindings/interrupt-controller/irq.h> + qupv3_se13_i2c { + #address-cells = <1>; + #size-cells = <0>; + pm8008i@8 { + compatible = "qcom,pm8008"; + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + interrupt-controller; + #interrupt-cells = <2>; + + interrupt-parent = <&tlmm>; + interrupts = <32 IRQ_TYPE_EDGE_RISING>; + + gpio@c000 { + compatible = "qcom,pm8008-gpio"; + reg = <0xc000>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 79367a43b27d..5ef79bf3d035 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -34,6 +34,10 @@ Required properties: "qcom,pm8998", "qcom,pmi8998", "qcom,pm8005", + "qcom,pm8350c", + "qcom,pmk8350", + "qcom,pm7325", + "qcom,pmr735a", or generalized "qcom,spmi-pmic". - reg: Specifies the SPMI USID slave address for this device. For more information see: diff --git a/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml new file mode 100644 index 000000000000..4762eb1439ce --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/richtek,rt4831.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/richtek,rt4831.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT4831 DSV and Backlight Integrated IC + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + RT4831 is a multifunctional device that can provide power to the LCD display + and LCD backlight. + + For Display Bias Voltage DSVP and DSVN, the output range is about 4V to 6.5V. + It's sufficient to meet the current LCD power requirement. + + For the LCD backlight, it can provide four channel WLED driving capability. + Each channel driving current is up to 30mA + + Datasheet is available at + https://www.richtek.com/assets/product_file/RT4831A/DS4831A-05.pdf + +properties: + compatible: + const: richtek,rt4831 + + reg: + description: I2C device address. + maxItems: 1 + + enable-gpios: + description: | + GPIO to enable/disable the chip. It is optional. + Some usage directly tied this pin to follow VIO 1.8V power on sequence. + maxItems: 1 + + regulators: + $ref: ../regulator/richtek,rt4831-regulator.yaml + + backlight: + $ref: ../leds/backlight/richtek,rt4831-backlight.yaml + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/leds/rt4831-backlight.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rt4831@11 { + compatible = "richtek,rt4831"; + reg = <0x11>; + + regulators { + DSVLCM { + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <7150000>; + regulator-allow-bypass; + }; + DSVP { + regulator-name = "rt4831-dsvp"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + regulator-boot-on; + }; + DSVN { + regulator-name = "rt4831-dsvn"; + regulator-min-microvolt = <4000000>; + regulator-max-microvolt = <6500000>; + regulator-boot-on; + }; + }; + + backlight { + compatible = "richtek,rt4831-backlight"; + default-brightness = <1024>; + max-brightness = <2048>; + richtek,bled-ovp-sel = /bits/ 8 <RT4831_BLOVPLVL_21V>; + richtek,channel-use = /bits/ 8 <RT4831_BLED_ALLCHEN>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/rk808.txt b/Documentation/devicetree/bindings/mfd/rk808.txt index 04df07f6f793..23a17a6663ec 100644 --- a/Documentation/devicetree/bindings/mfd/rk808.txt +++ b/Documentation/devicetree/bindings/mfd/rk808.txt @@ -23,6 +23,7 @@ Optional properties: default output clock name - rockchip,system-power-controller: Telling whether or not this pmic is controlling the system power. +- wakeup-source: Device can be used as a wakeup source. Optional RK805 properties: - vcc1-supply: The input supply for DCDC_REG1 @@ -63,8 +64,18 @@ Optional RK809 properties: - vcc9-supply: The input supply for DCDC_REG5, SWITCH_REG2 Optional RK817 properties: +- clocks: The input clock for the audio codec +- clock-names: The clock name for the codec clock. Should be "mclk". +- #sound-dai-cells: Needed for the interpretation of sound dais. Should be 0. + - vcc8-supply: The input supply for BOOST - vcc9-supply: The input supply for OTG_SWITCH +- codec: The child node for the codec to hold additional properties. + If no additional properties are required for the codec, this + node can be omitted. + +- rockchip,mic-in-differential: Telling if the microphone uses differential + mode. Should be under the codec child node. Optional RK818 properties: - vcc1-supply: The input supply for DCDC_REG1 @@ -275,3 +286,180 @@ Example: }; }; }; + + rk817: pmic@20 { + compatible = "rockchip,rk817"; + reg = <0x20>; + interrupt-parent = <&gpio0>; + interrupts = <RK_PB2 IRQ_TYPE_LEVEL_LOW>; + clock-output-names = "rk808-clkout1", "xin32k"; + clock-names = "mclk"; + clocks = <&cru SCLK_I2S1_OUT>; + pinctrl-names = "default"; + pinctrl-0 = <&pmic_int>, <&i2s1_2ch_mclk>; + wakeup-source; + #clock-cells = <1>; + #sound-dai-cells = <0>; + + vcc1-supply = <&vccsys>; + vcc2-supply = <&vccsys>; + vcc3-supply = <&vccsys>; + vcc4-supply = <&vccsys>; + vcc5-supply = <&vccsys>; + vcc6-supply = <&vccsys>; + vcc7-supply = <&vccsys>; + + regulators { + vdd_logic: DCDC_REG1 { + regulator-name = "vdd_logic"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1150000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vdd_arm: DCDC_REG2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <950000>; + regulator-max-microvolt = <1350000>; + regulator-ramp-delay = <6001>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <950000>; + }; + }; + + vcc_ddr: DCDC_REG3 { + regulator-name = "vcc_ddr"; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + vcc_3v3: DCDC_REG4 { + regulator-name = "vcc_3v3"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_1v8: LDO_REG2 { + regulator-name = "vcc_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1800000>; + }; + }; + + vdd_1v0: LDO_REG3 { + regulator-name = "vdd_1v0"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <1000000>; + }; + }; + + vcc3v3_pmu: LDO_REG4 { + regulator-name = "vcc3v3_pmu"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vccio_sd: LDO_REG5 { + regulator-name = "vccio_sd"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <3300000>; + regulator-always-on; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_sd: LDO_REG6 { + regulator-name = "vcc_sd"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + regulator-boot-on; + + regulator-state-mem { + regulator-on-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_bl: LDO_REG7 { + regulator-name = "vcc_bl"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <3300000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3300000>; + }; + }; + + vcc_lcd: LDO_REG8 { + regulator-name = "vcc_lcd"; + regulator-min-microvolt = <2800000>; + regulator-max-microvolt = <2800000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <2800000>; + }; + }; + + vcc_cam: LDO_REG9 { + regulator-name = "vcc_cam"; + regulator-min-microvolt = <3000000>; + regulator-max-microvolt = <3000000>; + + regulator-state-mem { + regulator-off-in-suspend; + regulator-suspend-microvolt = <3000000>; + }; + }; + }; + + rk817_codec: codec { + rockchip,mic-in-differential; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml index 0f16c8864a87..dace35362a7a 100644 --- a/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml +++ b/Documentation/devicetree/bindings/mfd/st,stm32-timers.yaml @@ -119,8 +119,6 @@ patternProperties: - compatible required: - - "#address-cells" - - "#size-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml new file mode 100644 index 000000000000..a0d4bad5dc81 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml @@ -0,0 +1,278 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/stericsson,db8500-prcmu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson DB8500 PRCMU - Power Reset and Control Management Unit + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: + The DB8500 Power Reset and Control Management Unit is an XP70 8-bit + microprocessor that is embedded in the always-on power domain of the + DB8500 SoCs to manage the low power states, powering up and down parts + of the silicon, and controlling reset of different IP blocks. + +properties: + $nodename: + pattern: '^prcmu@[0-9a-f]+$' + + compatible: + description: The device is compatible both to the device-specific + compatible "stericsson,db8500-prcmu" and "syscon". The latter + compatible is needed for the device to be exposed as a system + controller so that arbitrary registers can be access by + different operating system components. + items: + - const: stericsson,db8500-prcmu + - const: syscon + + reg: + items: + - description: Main PRCMU register area + - description: PRCMU TCPM register area + - description: PRCMU TCDM register area + + reg-names: + items: + - const: prcmu + - const: prcmu-tcpm + - const: prcmu-tcdm + + interrupts: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + ranges: true + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + db8500-prcmu-regulators: + description: Node describing the DB8500 regulators. These are mainly + power rails inside the silicon but some of those are also routed + out to external pins. + type: object + + properties: + compatible: + const: stericsson,db8500-prcmu-regulator + + db8500_vape: + description: The voltage for the application processor, the + main voltage domain for the chip. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_varm: + description: The voltage for the ARM Cortex A-9 CPU. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vmodem: + description: The voltage for the modem subsystem. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vpll: + description: The voltage for the phase locked loop clocks. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps1: + description: Also known as VIO12, is a step-down voltage regulator + for 1.2V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps2: + description: Also known as VIO18, is a step-down voltage regulator + for 1.8V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vsmps3: + description: This is a step-down voltage regulator + for 0.87 thru 1.875V I/O. SMPS means System Management Power Source. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_vrf1: + description: RF transciever voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_mmdsp: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator. This is the voltage for the accelerator DSP + for video encoding and decoding. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_mmdsp_ret: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator for retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sva_pipe: + description: Smart Video Accelerator (SVA) multimedia DSP (MMDSP) + voltage regulator for the data pipe. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_mmdsp: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator. This is the voltage for the accelerator DSP + for image encoding and decoding. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_mmdsp_ret: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator for retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sia_pipe: + description: Smart Image Accelerator (SIA) multimedia DSP (MMDSP) + voltage regulator for the data pipe. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_sga: + description: Smart Graphics Accelerator (SGA) voltage regulator. + This is in effect controlling the power to the MALI400 3D + accelerator block. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_b2r2_mcde: + description: Blit Blend Rotate and Rescale (B2R2), and Multi-Channel + Display Engine (MCDE) voltage regulator. These are two graphics + blocks. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram12: + description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram12_ret: + description: Embedded Static RAM (ESRAM) 1 and 2 voltage regulator for + retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram34: + description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator. + type: object + $ref: ../regulator/regulator.yaml# + + db8500_esram34_ret: + description: Embedded Static RAM (ESRAM) 3 and 4 voltage regulator for + retention mode. + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + - db8500_vape + - db8500_varm + - db8500_vmodem + - db8500_vpll + - db8500_vsmps1 + - db8500_vsmps2 + - db8500_vsmps3 + - db8500_vrf1 + - db8500_sva_mmdsp + - db8500_sva_mmdsp_ret + - db8500_sva_pipe + - db8500_sia_mmdsp + - db8500_sia_mmdsp_ret + - db8500_sia_pipe + - db8500_sga + - db8500_b2r2_mcde + - db8500_esram12 + - db8500_esram12_ret + - db8500_esram34 + - db8500_esram34_ret + + additionalProperties: false + +patternProperties: + "^thermal@[0-9a-f]+$": + description: Node describing the DB8500 thermal control functions. + This binds to an operating system driver that monitors the + temperature of the SoC. + type: object + + properties: + compatible: + const: stericsson,db8500-thermal + + reg: + maxItems: 1 + + interrupts: + items: + - description: Hotmon low interrupt (falling temperature) + - description: Hotmon high interrupt (rising temperature) + + interrupt-names: + items: + - const: IRQ_HOTMON_LOW + - const: IRQ_HOTMON_HIGH + + '#thermal-sensor-cells': + const: 0 + + additionalProperties: false + + "^prcmu-timer-4@[0-9a-f]+$": + description: Node describing the externally visible timer 4 in the + PRCMU block. This timer is interesting to the operating system + since even thought it has a very low resolution (32768 Hz) it is + always on, and thus provides a consistent monotonic timeline for + the system. + type: object + + properties: + compatible: + const: stericsson,db8500-prcmu-timer-4 + + reg: + maxItems: 1 + + additionalProperties: false + + "^ab850[05]$": + description: Node describing the Analog Baseband 8500 mixed-signals + ASIC AB8500 and subcomponents. The AB8500 is accessed through the + PRCMU and hence it appears here. This component has a separate + set of devicetree bindings. The AB8505 is a newer version of the + same ASIC. + type: object + +required: + - compatible + - reg + - '#address-cells' + - '#size-cells' + - ranges + - interrupts + - interrupt-controller + - '#interrupt-cells' + - db8500-prcmu-regulators + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 19fcf59fd2fe..272832e9f8f2 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -43,12 +43,10 @@ properties: patternProperties: # Optional children - "^serdes-ln-ctrl@[0-9a-f]+$": + "^mux-controller@[0-9a-f]+$": type: object - description: | - This is the SERDES lane control mux. It should follow the bindings - specified in - Documentation/devicetree/bindings/mux/reg-mux.txt + description: + This is the SERDES lane control mux. required: - compatible @@ -68,9 +66,18 @@ examples: #size-cells = <1>; ranges; - serdes_ln_ctrl: serdes-ln-ctrl@4080 { + serdes_ln_ctrl: mux-controller@4080 { compatible = "mmio-mux"; reg = <0x00004080 0x50>; + + #mux-control-cells = <1>; + mux-reg-masks = + <0x4080 0x3>, <0x4084 0x3>, /* SERDES0 lane0/1 select */ + <0x4090 0x3>, <0x4094 0x3>, /* SERDES1 lane0/1 select */ + <0x40a0 0x3>, <0x40a4 0x3>, /* SERDES2 lane0/1 select */ + <0x40b0 0x3>, <0x40b4 0x3>, /* SERDES3 lane0/1 select */ + <0x40c0 0x3>, <0x40c4 0x3>, <0x40c8 0x3>, <0x40cc 0x3>; + /* SERDES4 lane0/1/2/3 select */ }; }; ... diff --git a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt index 7b636b7a8311..72ea0af368d4 100644 --- a/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt +++ b/Documentation/devicetree/bindings/misc/eeprom-93xx46.txt @@ -2,7 +2,10 @@ EEPROMs (SPI) compatible with Microchip Technology 93xx46 family. Required properties: - compatible : shall be one of: + "atmel,at93c46" "atmel,at93c46d" + "atmel,at93c56" + "atmel,at93c66" "eeprom-93xx46" "microchip,93lc46b" - data-size : number of data bits per word (either 8 or 16) diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index e75b3a8ba816..4f62ad6ce50c 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -64,7 +64,6 @@ properties: clocks: minItems: 2 - maxItems: 4 items: - description: Bus Clock - description: Module Clock @@ -73,7 +72,6 @@ properties: clock-names: minItems: 2 - maxItems: 4 items: - const: ahb - const: mmc diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 369471814496..b5baf439fbac 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -116,7 +116,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 4 items: - const: default - const: state_100mhz diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index 8648d48dbbfd..e866e985549e 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -31,6 +31,8 @@ properties: - const: mediatek,mt2701-mmc - items: - const: mediatek,mt8192-mmc + - const: mediatek,mt8183-mmc + - items: - const: mediatek,mt8195-mmc - const: mediatek,mt8183-mmc @@ -38,7 +40,6 @@ properties: description: Should contain phandle for the clock feeding the MMC controller. minItems: 2 - maxItems: 8 items: - description: source clock (required). - description: HCLK which used for host (required). @@ -51,7 +52,6 @@ properties: clock-names: minItems: 2 - maxItems: 8 items: - const: source - const: hclk diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 1118b6fa93c9..677989bc5924 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -75,7 +75,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: core - const: cd @@ -107,7 +106,6 @@ properties: pinctrl-names: minItems: 1 - maxItems: 2 items: - const: default - const: state_uhs diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 29399e88ac53..224303f5b913 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -44,7 +44,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: clk_ahb - const: clk_xin diff --git a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml index aa12480648a5..1c87f4218e18 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-pxa.yaml @@ -57,7 +57,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: io - const: core diff --git a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt index 4a9145ef15d6..57d077c0b7c1 100644 --- a/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt +++ b/Documentation/devicetree/bindings/mmc/ti-omap-hsmmc.txt @@ -25,10 +25,10 @@ The following are mandatory properties for 66AK2G SoCs only: - power-domains:Should contain a phandle to a PM domain provider node and an args specifier containing the MMC device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks: Must contain an entry for each entry in clock-names. Should be defined as per the he appropriate clock bindings consumer - usage in Documentation/devicetree/bindings/clock/ti,sci-clk.txt + usage in Documentation/devicetree/bindings/clock/ti,sci-clk.yaml - clock-names: Shall be "fck" for the functional clock, and "mmchsdb_fck" for the debounce clock. diff --git a/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml new file mode 100644 index 000000000000..5f126bb9b202 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/arm,pl353-nand-r2p1.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/arm,pl353-nand-r2p1.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: PL353 NAND Controller device tree bindings + +allOf: + - $ref: "nand-controller.yaml" + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Naga Sureshkumar Relli <naga.sureshkumar.relli@xilinx.com> + +properties: + compatible: + items: + - const: arm,pl353-nand-r2p1 + + reg: + items: + - items: + - description: CS with regard to the parent ranges property + - description: Offset of the memory region requested by the device + - description: Length of the memory region requested by the device + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + smcc: memory-controller@e000e000 { + compatible = "arm,pl353-smc-r2p1", "arm,primecell"; + reg = <0xe000e000 0x0001000>; + clock-names = "memclk", "apb_pclk"; + clocks = <&clkc 11>, <&clkc 44>; + ranges = <0x0 0x0 0xe1000000 0x1000000 /* Nand CS region */ + 0x1 0x0 0xe2000000 0x2000000 /* SRAM/NOR CS0 region */ + 0x2 0x0 0xe4000000 0x2000000>; /* SRAM/NOR CS1 region */ + #address-cells = <2>; + #size-cells = <1>; + + nfc0: nand-controller@0,0 { + compatible = "arm,pl353-nand-r2p1"; + reg = <0 0 0x1000000>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/arm-versatile.txt b/Documentation/devicetree/bindings/mtd/arm-versatile.txt deleted file mode 100644 index 4ec28796a3c0..000000000000 --- a/Documentation/devicetree/bindings/mtd/arm-versatile.txt +++ /dev/null @@ -1,26 +0,0 @@ -Flash device on ARM Versatile board - -These flash chips are found in the ARM reference designs like Integrator, -Versatile, RealView, Versatile Express etc. - -They are regular CFI compatible (Intel or AMD extended) flash chips with -some special write protect/VPP bits that can be controlled by the machine's -system controller. - -Required properties: -- compatible : must be "arm,versatile-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface. - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@34000000 { - compatible = "arm,versatile-flash", "cfi-flash"; - reg = <0x34000000 0x4000000>; - bank-width = <4>; -}; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt deleted file mode 100644 index 44335a4f8bfb..000000000000 --- a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.txt +++ /dev/null @@ -1,186 +0,0 @@ -* Broadcom STB NAND Controller - -The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND -flash chips. It has a memory-mapped register interface for both control -registers and for its data input/output buffer. On some SoCs, this controller is -paired with a custom DMA engine (inventively named "Flash DMA") which supports -basic PROGRAM and READ functions, among other features. - -This controller was originally designed for STB SoCs (BCM7xxx) but is now -available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and -iProc/Cygnus. Its history includes several similar (but not fully register -compatible) versions. - -Required properties: -- compatible : May contain an SoC-specific compatibility string (see below) - to account for any SoC-specific hardware bits that may be - added on top of the base core controller. - In addition, must contain compatibility information about - the core NAND controller, of the following form: - "brcm,brcmnand" and an appropriate version compatibility - string, like "brcm,brcmnand-v7.0" - Possible values: - brcm,brcmnand-v2.1 - brcm,brcmnand-v2.2 - brcm,brcmnand-v4.0 - brcm,brcmnand-v5.0 - brcm,brcmnand-v6.0 - brcm,brcmnand-v6.1 - brcm,brcmnand-v6.2 - brcm,brcmnand-v7.0 - brcm,brcmnand-v7.1 - brcm,brcmnand-v7.2 - brcm,brcmnand-v7.3 - brcm,brcmnand -- reg : the register start and length for NAND register region. - (optional) Flash DMA register range (if present) - (optional) NAND flash cache range (if at non-standard offset) -- reg-names : a list of the names corresponding to the previous register - ranges. Should contain "nand" and (optionally) - "flash-dma" or "flash-edu" and/or "nand-cache". -- interrupts : The NAND CTLRDY interrupt, (if Flash DMA is available) - FLASH_DMA_DONE and if EDU is avaialble and used FLASH_EDU_DONE -- interrupt-names : May be "nand_ctlrdy" or "flash_dma_done" or "flash_edu_done", - if broken out as individual interrupts. - May be "nand", if the SoC has the individual NAND - interrupts multiplexed behind another custom piece of - hardware -- #address-cells : <1> - subnodes give the chip-select number -- #size-cells : <0> - -Optional properties: -- clock : reference to the clock for the NAND controller -- clock-names : "nand" (required for the above clock) -- brcm,nand-has-wp : Some versions of this IP include a write-protect - (WP) control bit. It is always available on >= - v7.0. Use this property to describe the rare - earlier versions of this core that include WP - - -- Additional SoC-specific NAND controller properties -- - -The NAND controller is integrated differently on the variety of SoCs on which it -is found. Part of this integration involves providing status and enable bits -with which to control the 8 exposed NAND interrupts, as well as hardware for -configuring the endianness of the data bus. On some SoCs, these features are -handled via standard, modular components (e.g., their interrupts look like a -normal IRQ chip), but on others, they are controlled in unique and interesting -ways, sometimes with registers that lump multiple NAND-related functions -together. The former case can be described simply by the standard interrupts -properties in the main controller node. But for the latter exceptional cases, -we define additional 'compatible' properties and associated register resources within the NAND controller node above. - - - compatible: Can be one of several SoC-specific strings. Each SoC may have - different requirements for its additional properties, as described below each - bullet point below. - - * "brcm,nand-bcm63138" - - reg: (required) the 'NAND_INT_BASE' register range, with separate status - and enable registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-bcm6368" - - compatible: should contain "brcm,nand-bcm<soc>", "brcm,nand-bcm6368" - - reg: (required) the 'NAND_INTR_BASE' register range, with combined status - and enable registers, and boot address registers - - reg-names: (required) "nand-int-base" - - * "brcm,nand-iproc" - - reg: (required) the "IDM" register range, for interrupt enable and APB - bus access endianness configuration, and the "EXT" register range, - for interrupt status/ack. - - reg-names: (required) a list of the names corresponding to the previous - register ranges. Should contain "iproc-idm" and "iproc-ext". - - -* NAND chip-select - -Each controller (compatible: "brcm,brcmnand") may contain one or more subnodes -to represent enabled chip-selects which (may) contain NAND flash chips. Their -properties are as follows. - -Required properties: -- compatible : should contain "brcm,nandcs" -- reg : a single integer representing the chip-select - number (e.g., 0, 1, 2, etc.) -- #address-cells : see partition.txt -- #size-cells : see partition.txt - -Optional properties: -- nand-ecc-strength : see nand-controller.yaml -- nand-ecc-step-size : must be 512 or 1024. See nand-controller.yaml -- nand-on-flash-bbt : boolean, to enable the on-flash BBT for this - chip-select. See nand-controller.yaml -- brcm,nand-oob-sector-size : integer, to denote the spare area sector size - expected for the ECC layout in use. This size, in - addition to the strength and step-size, - determines how the hardware BCH engine will lay - out the parity bytes it stores on the flash. - This property can be automatically determined by - the flash geometry (particularly the NAND page - and OOB size) in many cases, but when booting - from NAND, the boot controller has only a limited - number of available options for its default ECC - layout. - -Each nandcs device node may optionally contain sub-nodes describing the flash -partition mapping. See partition.txt for more detail. - - -Example: - -nand@f0442800 { - compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; - reg = <0xF0442800 0x600>, - <0xF0443000 0x100>; - reg-names = "nand", "flash-dma"; - interrupt-parent = <&hif_intr2_intc>; - interrupts = <24>, <4>; - - #address-cells = <1>; - #size-cells = <0>; - - nandcs@1 { - compatible = "brcm,nandcs"; - reg = <1>; // Chip select 1 - nand-on-flash-bbt; - nand-ecc-strength = <12>; - nand-ecc-step-size = <512>; - - // Partitions - #address-cells = <1>; // <2>, for 64-bit offset - #size-cells = <1>; // <2>, for 64-bit length - flash0.rootfs@0 { - reg = <0 0x10000000>; - }; - flash0@0 { - reg = <0 0>; // MTDPART_SIZ_FULL - }; - flash0.kernel@10000000 { - reg = <0x10000000 0x400000>; - }; - }; -}; - -nand@10000200 { - compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", - "brcm,brcmnand-v4.0", "brcm,brcmnand"; - reg = <0x10000200 0x180>, - <0x10000600 0x200>, - <0x100000b0 0x10>; - reg-names = "nand", "nand-cache", "nand-int-base"; - interrupt-parent = <&periph_intc>; - interrupts = <50>; - clocks = <&periph_clk 20>; - clock-names = "nand"; - - #address-cells = <1>; - #size-cells = <0>; - - nand0: nandcs@0 { - compatible = "brcm,nandcs"; - reg = <0>; - nand-on-flash-bbt; - nand-ecc-strength = <1>; - nand-ecc-step-size = <512>; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml new file mode 100644 index 000000000000..e5f1a33332a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/brcm,brcmnand.yaml @@ -0,0 +1,242 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/brcm,brcmnand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom STB NAND Controller + +maintainers: + - Brian Norris <computersforpeace@gmail.com> + - Kamal Dasu <kdasu.kdev@gmail.com> + +description: | + The Broadcom Set-Top Box NAND controller supports low-level access to raw NAND + flash chips. It has a memory-mapped register interface for both control + registers and for its data input/output buffer. On some SoCs, this controller + is paired with a custom DMA engine (inventively named "Flash DMA") which + supports basic PROGRAM and READ functions, among other features. + + This controller was originally designed for STB SoCs (BCM7xxx) but is now + available on a variety of Broadcom SoCs, including some BCM3xxx, BCM63xx, and + iProc/Cygnus. Its history includes several similar (but not fully register + compatible) versions. + + -- Additional SoC-specific NAND controller properties -- + + The NAND controller is integrated differently on the variety of SoCs on which + it is found. Part of this integration involves providing status and enable + bits with which to control the 8 exposed NAND interrupts, as well as hardware + for configuring the endianness of the data bus. On some SoCs, these features + are handled via standard, modular components (e.g., their interrupts look like + a normal IRQ chip), but on others, they are controlled in unique and + interesting ways, sometimes with registers that lump multiple NAND-related + functions together. The former case can be described simply by the standard + interrupts properties in the main controller node. But for the latter + exceptional cases, we define additional 'compatible' properties and associated + register resources within the NAND controller node above. + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,brcmnand-v2.1 + - brcm,brcmnand-v2.2 + - brcm,brcmnand-v4.0 + - brcm,brcmnand-v5.0 + - brcm,brcmnand-v6.0 + - brcm,brcmnand-v6.1 + - brcm,brcmnand-v6.2 + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - brcm,brcmnand-v7.2 + - brcm,brcmnand-v7.3 + - const: brcm,brcmnand + - description: BCM63138 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63138 + - enum: + - brcm,brcmnand-v7.0 + - brcm,brcmnand-v7.1 + - const: brcm,brcmnand + - description: iProc SoC-specific NAND controller + items: + - const: brcm,nand-iproc + - const: brcm,brcmnand-v6.1 + - const: brcm,brcmnand + - description: BCM63168 SoC-specific NAND controller + items: + - const: brcm,nand-bcm63168 + - const: brcm,nand-bcm6368 + - const: brcm,brcmnand-v4.0 + - const: brcm,brcmnand + + reg: + minItems: 1 + maxItems: 6 + + reg-names: + minItems: 1 + maxItems: 6 + items: + enum: [ nand, flash-dma, flash-edu, nand-cache, nand-int-base, iproc-idm, iproc-ext ] + + interrupts: + minItems: 1 + maxItems: 3 + items: + - description: NAND CTLRDY interrupt + - description: FLASH_DMA_DONE if flash DMA is available + - description: FLASH_EDU_DONE if EDU is available + + interrupt-names: + minItems: 1 + maxItems: 3 + items: + - const: nand_ctlrdy + - const: flash_dma_done + - const: flash_edu_done + + clocks: + maxItems: 1 + description: reference to the clock for the NAND controller + + clock-names: + const: nand + + brcm,nand-has-wp: + description: > + Some versions of this IP include a write-protect + (WP) control bit. It is always available on >= + v7.0. Use this property to describe the rare + earlier versions of this core that include WP + type: boolean + +patternProperties: + "^nand@[a-f0-9]$": + type: object + properties: + compatible: + const: brcm,nandcs + + nand-ecc-step-size: + enum: [ 512, 1024 ] + + brcm,nand-oob-sector-size: + description: | + integer, to denote the spare area sector size + expected for the ECC layout in use. This size, in + addition to the strength and step-size, + determines how the hardware BCH engine will lay + out the parity bytes it stores on the flash. + This property can be automatically determined by + the flash geometry (particularly the NAND page + and OOB size) in many cases, but when booting + from NAND, the boot controller has only a limited + number of available options for its default ECC + layout. + $ref: /schemas/types.yaml#/definitions/uint32 + +allOf: + - $ref: nand-controller.yaml# + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm63138 + then: + properties: + reg-names: + minItems: 2 + maxItems: 2 + items: + - const: nand + - const: nand-int-base + - if: + properties: + compatible: + contains: + const: brcm,nand-bcm6368 + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: nand-int-base + - const: nand-cache + - if: + properties: + compatible: + contains: + const: brcm,nand-iproc + then: + properties: + reg-names: + minItems: 3 + maxItems: 3 + items: + - const: nand + - const: iproc-idm + - const: iproc-ext + +unevaluatedProperties: false + +required: + - reg + - reg-names + - interrupts + +examples: + - | + nand-controller@f0442800 { + compatible = "brcm,brcmnand-v7.0", "brcm,brcmnand"; + reg = <0xf0442800 0x600>, + <0xf0443000 0x100>; + reg-names = "nand", "flash-dma"; + interrupt-parent = <&hif_intr2_intc>; + interrupts = <24>, <4>; + + #address-cells = <1>; + #size-cells = <0>; + + nand@1 { + compatible = "brcm,nandcs"; + reg = <1>; // Chip select 1 + nand-on-flash-bbt; + nand-ecc-strength = <12>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; + - | + nand-controller@10000200 { + compatible = "brcm,nand-bcm63168", "brcm,nand-bcm6368", + "brcm,brcmnand-v4.0", "brcm,brcmnand"; + reg = <0x10000200 0x180>, + <0x100000b0 0x10>, + <0x10000600 0x200>; + reg-names = "nand", "nand-int-base", "nand-cache"; + interrupt-parent = <&periph_intc>; + interrupts = <50>; + clocks = <&periph_clk 20>; + clock-names = "nand"; + + #address-cells = <1>; + #size-cells = <0>; + + nand@0 { + compatible = "brcm,nandcs"; + reg = <0>; + nand-on-flash-bbt; + nand-ecc-strength = <1>; + nand-ecc-step-size = <512>; + + #address-cells = <1>; + #size-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/mtd/common.txt b/Documentation/devicetree/bindings/mtd/common.txt index fc068b923d7a..ae16f9ea8606 100644 --- a/Documentation/devicetree/bindings/mtd/common.txt +++ b/Documentation/devicetree/bindings/mtd/common.txt @@ -1,15 +1 @@ -* Common properties of all MTD devices - -Optional properties: -- label: user-defined MTD device name. Can be used to assign user - friendly names to MTD devices (instead of the flash model or flash - controller based name) in order to ease flash device identification - and/or describe what they are used for. - -Example: - - flash@0 { - label = "System-firmware"; - - /* flash type specific properties */ - }; +This file has been moved to mtd.yaml. diff --git a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt index 3fa1b34d69ad..efa5b2aba829 100644 --- a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt +++ b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt @@ -9,7 +9,7 @@ Required properties: - syscon : must be a phandle to the system controller - bank-width : width in bytes of flash interface, should be <2> -For the rest of the properties, see mtd-physmap.txt. +For the rest of the properties, see mtd-physmap.yaml. The device tree may optionally contain sub-nodes describing partitions of the address space. See partition.txt for more detail. diff --git a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt b/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt deleted file mode 100644 index ad42f4db32f1..000000000000 --- a/Documentation/devicetree/bindings/mtd/cypress,hyperflash.txt +++ /dev/null @@ -1,13 +0,0 @@ -Bindings for HyperFlash NOR flash chips compliant with Cypress HyperBus -specification and supports Cypress CFI specification 1.5 command set. - -Required properties: -- compatible : "cypress,hyperflash", "cfi-flash" for HyperFlash NOR chips -- reg : Address of flash's memory map - -Example: - - flash@0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x4000000>; - }; diff --git a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt b/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt deleted file mode 100644 index 4bdcb92ae381..000000000000 --- a/Documentation/devicetree/bindings/mtd/intel,ixp4xx-flash.txt +++ /dev/null @@ -1,22 +0,0 @@ -Flash device on Intel IXP4xx SoC - -This flash is regular CFI compatible (Intel or AMD extended) flash chips with -specific big-endian or mixed-endian memory access pattern. - -Required properties: -- compatible : must be "intel,ixp4xx-flash", "cfi-flash"; -- reg : memory address for the flash chip -- bank-width : width in bytes of flash interface, should be <2> - -For the rest of the properties, see mtd-physmap.txt. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@50000000 { - compatible = "intel,ixp4xx-flash", "cfi-flash"; - reg = <0x50000000 0x01000000>; - bank-width = <2>; -}; diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 5e7e5349f9a1..ed590d7c6e37 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -9,6 +9,9 @@ title: SPI NOR flash ST M25Pxx (and similar) serial flash chips maintainers: - Rob Herring <robh@kernel.org> +allOf: + - $ref: "mtd.yaml#" + properties: compatible: oneOf: @@ -82,6 +85,9 @@ patternProperties: '^partition@': type: object + "^otp(-[0-9]+)?$": + type: object + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml new file mode 100644 index 000000000000..2cdf6bf3dc4a --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/microchip,mchp48l640.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/mtd/microchip,mchp48l640.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip 48l640 (and similar) serial EERAM bindings + +maintainers: + - Heiko Schocher <hs@denx.de> + +description: | + The Microchip 48l640 is a 8KByte EERAM connected via SPI. + + datasheet: http://ww1.microchip.com/downloads/en/DeviceDoc/20006055B.pdf + +properties: + compatible: + items: + - const: microchip,48l640 + + reg: + maxItems: 1 + + spi-max-frequency: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + eeram@0 { + compatible = "microchip,48l640"; + reg = <0>; + spi-max-frequency = <20000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt b/Documentation/devicetree/bindings/mtd/mtd-physmap.txt deleted file mode 100644 index c69f4f065d23..000000000000 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.txt +++ /dev/null @@ -1,114 +0,0 @@ -CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) - -Flash chips (Memory Technology Devices) are often used for solid state -file systems on embedded devices. - - - compatible : should contain the specific model of mtd chip(s) - used, if known, followed by either "cfi-flash", "jedec-flash", - "mtd-ram" or "mtd-rom". - - reg : Address range(s) of the mtd chip(s) - It's possible to (optionally) define multiple "reg" tuples so that - non-identical chips can be described in one node. - - bank-width : Width (in bytes) of the bank. Equal to the - device width times the number of interleaved chips. - - device-width : (optional) Width of a single mtd chip. If - omitted, assumed to be equal to 'bank-width'. - - #address-cells, #size-cells : Must be present if the device has - sub-nodes representing partitions (see below). In this case - both #address-cells and #size-cells must be equal to 1. - - no-unaligned-direct-access: boolean to disable the default direct - mapping of the flash. - On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause - problems with JFFS2 usage, as the local bus (LPB) doesn't support - unaligned accesses as implemented in the JFFS2 code via memcpy(). - By defining "no-unaligned-direct-access", the flash will not be - exposed directly to the MTD users (e.g. JFFS2) any more. - - linux,mtd-name: allow to specify the mtd name for retro capability with - physmap-flash drivers as boot loader pass the mtd partition via the old - device name physmap-flash. - - use-advanced-sector-protection: boolean to enable support for the - advanced sector protection (Spansion: PPB - Persistent Protection - Bits) locking. - - addr-gpios : (optional) List of GPIO descriptors that will be used to - address the MSBs address lines. The order goes from LSB to MSB. - -For JEDEC compatible devices, the following additional properties -are defined: - - - vendor-id : Contains the flash chip's vendor id (1 byte). - - device-id : Contains the flash chip's device id (1 byte). - -For ROM compatible devices (and ROM fallback from cfi-flash), the following -additional (optional) property is defined: - - - erase-size : The chip's physical erase block size in bytes. - - The device tree may optionally contain endianness property. - little-endian or big-endian : It Represents the endianness that should be used - by the controller to properly read/write data - from/to the flash. If this property is missing, - the endianness is chosen by the system - (potentially based on extra configuration options). - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - - flash@ff000000 { - compatible = "amd,am29lv128ml", "cfi-flash"; - reg = <ff000000 01000000>; - bank-width = <4>; - device-width = <1>; - #address-cells = <1>; - #size-cells = <1>; - fs@0 { - label = "fs"; - reg = <0 f80000>; - }; - firmware@f80000 { - label ="firmware"; - reg = <f80000 80000>; - read-only; - }; - }; - -Here an example with multiple "reg" tuples: - - flash@f0000000,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "intel,PC48F4400P0VB", "cfi-flash"; - reg = <0 0x00000000 0x02000000 - 0 0x02000000 0x02000000>; - bank-width = <2>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; - -An example using SRAM: - - sram@2,0 { - compatible = "samsung,k6f1616u6a", "mtd-ram"; - reg = <2 0 0x00200000>; - bank-width = <2>; - }; - -An example using gpio-addrs - - flash@20000000 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash", "jedec-flash"; - reg = <0x20000000 0x02000000>; - ranges = <0 0x00000000 0x02000000 - 1 0x02000000 0x02000000>; - bank-width = <2>; - addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; - partition@0 { - label = "test-part1"; - reg = <0 0x04000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml new file mode 100644 index 000000000000..13c29cc91b59 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -0,0 +1,208 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd-physmap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: CFI or JEDEC memory-mapped NOR flash, MTD-RAM (NVRAM...) + +maintainers: + - Rob Herring <robh@kernel.org> + +description: | + Flash chips (Memory Technology Devices) are often used for solid state + file systems on embedded devices. + +properties: + compatible: + oneOf: + - items: + - enum: + - amd,s29gl01gp + - amd,s29gl032a + - amd,s29gl256n + - amd,s29gl512n + - arm,versatile-flash + - cortina,gemini-flash + - cypress,hyperflash + - ge,imp3a-firmware-mirror + - ge,imp3a-paged-flash + - gef,ppc9a-firmware-mirror + - gef,ppc9a-paged-flash + - gef,sbc310-firmware-mirror + - gef,sbc310-paged-flash + - gef,sbc610-firmware-mirror + - gef,sbc610-paged-flash + - intel,28f128j3 + - intel,dt28f160 + - intel,ixp4xx-flash + - intel,JS28F128 + - intel,JS28F640 + - intel,PC28F640P30T85 + - numonyx,js28f00a + - numonyx,js28f128 + - sst,sst39vf320 + - xlnx,xps-mch-emc-2.00.a + - const: cfi-flash + - items: + - enum: + - cypress,cy7c1019dv33-10zsxi + - arm,vexpress-psram + - const: mtd-ram + - enum: + - cfi-flash + - jedec-flash + - mtd-ram + - mtd-rom + + reg: + description: | + It's possible to (optionally) define multiple "reg" tuples so that + non-identical chips can be described in one node. + minItems: 1 + maxItems: 8 + + bank-width: + description: Width (in bytes) of the bank. Equal to the device width times + the number of interleaved chips. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2, 4 ] + + device-width: + description: + Width of a single mtd chip. If omitted, assumed to be equal to 'bank-width'. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 1, 2 ] + + no-unaligned-direct-access: + type: boolean + description: | + Disables the default direct mapping of the flash. + + On some platforms (e.g. MPC5200) a direct 1:1 mapping may cause problems + with JFFS2 usage, as the local bus (LPB) doesn't support unaligned + accesses as implemented in the JFFS2 code via memcpy(). By defining + "no-unaligned-direct-access", the flash will not be exposed directly to + the MTD users (e.g. JFFS2) any more. + + linux,mtd-name: + description: + Allows specifying the mtd name for retro capability with physmap-flash + drivers as boot loader pass the mtd partition via the old device name + physmap-flash. + $ref: /schemas/types.yaml#/definitions/string + + use-advanced-sector-protection: + type: boolean + description: | + Enables support for the advanced sector protection (Spansion: PPB - + Persistent Protection Bits) locking. + + erase-size: + description: The chip's physical erase block size in bytes. + $ref: /schemas/types.yaml#/definitions/uint32 + + addr-gpios: + description: + List of GPIO descriptors that will be used to address the MSBs address + lines. The order goes from LSB to MSB. + minItems: 1 + maxItems: 8 + + '#address-cells': + const: 1 + + '#size-cells': + const: 1 + + big-endian: true + little-endian: true + +patternProperties: + '@[0-9a-f]+$': + $ref: partitions/partition.yaml + +required: + - compatible + - reg + +# FIXME: A parent bus may define timing properties +additionalProperties: true + +examples: + - | + + flash@ff000000 { + compatible = "cfi-flash"; + reg = <0xff000000 0x01000000>; + bank-width = <4>; + device-width = <1>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0xff000000 0x01000000>; + + fs@0 { + label = "fs"; + reg = <0 0xf80000>; + }; + firmware@f80000 { + label ="firmware"; + reg = <0xf80000 0x80000>; + read-only; + }; + }; + + - | + /* An example with multiple "reg" tuples */ + + flash@0 { + compatible = "intel,PC28F640P30T85", "cfi-flash"; + reg = <0x00000000 0x02000000>, + <0x02000000 0x02000000>; + bank-width = <2>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0 0x04000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; + + - | + /* An example using SRAM */ + bus { + #address-cells = <2>; + #size-cells = <1>; + + sram@2,0 { + compatible = "mtd-ram"; + reg = <2 0 0x00200000>; + bank-width = <2>; + }; + }; + + - | + /* An example using addr-gpios */ + #include <dt-bindings/gpio/gpio.h> + + flash@20000000 { + compatible = "cfi-flash"; + reg = <0x20000000 0x02000000>; + bank-width = <2>; + addr-gpios = <&gpio1 2 GPIO_ACTIVE_HIGH>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x00000000 0x02000000>, + <1 0x02000000 0x02000000>; + + partition@0 { + label = "test-part1"; + reg = <0 0x04000000>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mtd/mtd.yaml b/Documentation/devicetree/bindings/mtd/mtd.yaml new file mode 100644 index 000000000000..376b679cfc70 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mtd.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mtd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MTD (Memory Technology Device) Device Tree Bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + - Richard Weinberger <richard@nod.at> + +properties: + $nodename: + pattern: "^flash(@.*)?$" + + label: + description: + User-defined MTD device name. Can be used to assign user friendly + names to MTD devices (instead of the flash model or flash controller + based name) in order to ease flash device identification and/or + describe what they are used for. + +patternProperties: + "^otp(-[0-9]+)?$": + type: object + $ref: ../nvmem/nvmem.yaml# + + description: | + An OTP memory region. Some flashes provide a one-time-programmable + memory whose content can either be programmed by a user or is already + pre-programmed by the factory. Some flashes might provide both. + + properties: + compatible: + enum: + - user-otp + - factory-otp + + required: + - compatible + +additionalProperties: true + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + label = "System-firmware"; + }; + }; + + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + reg = <0>; + compatible = "jedec,spi-nor"; + + otp-1 { + compatible = "factory-otp"; + #address-cells = <1>; + #size-cells = <1>; + + electronic-serial-number@0 { + reg = <0 8>; + }; + }; + + otp-2 { + compatible = "user-otp"; + #address-cells = <1>; + #size-cells = <1>; + + mac-address@0 { + reg = <0 6>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index 678b39952502..bd217e6f5018 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -38,6 +38,17 @@ properties: ranges: true + cs-gpios: + minItems: 1 + maxItems: 8 + description: + Array of chip-select available to the controller. The first + entries are a 1:1 mapping of the available chip-select on the + NAND controller (even if they are not used). As many additional + chip-select as needed may follow and should be phandles of GPIO + lines. 'reg' entries of the NAND chip subnodes become indexes of + this array when this property is present. + patternProperties: "^nand@[a-f0-9]$": type: object @@ -164,14 +175,19 @@ examples: nand-controller { #address-cells = <1>; #size-cells = <0>; + cs-gpios = <0>, <&gpioA 1>; /* A single native CS is available */ /* controller specific properties */ nand@0 { - reg = <0>; + reg = <0>; /* Native CS */ nand-use-soft-ecc-engine; nand-ecc-algo = "bch"; /* controller specific properties */ }; + + nand@1 { + reg = <1>; /* GPIO CS */ + }; }; diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt index b677147ca4e1..c2175d3c82ec 100644 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,trx.txt @@ -28,6 +28,11 @@ detected by a software parsing TRX header. Required properties: - compatible : (required) must be "brcm,trx" +Optional properties: + +- brcm,trx-magic: TRX magic, if it is different from the default magic + 0x30524448 as a u32. + Example: flash@0 { diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt deleted file mode 100644 index faa81c2e5da6..000000000000 --- a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.txt +++ /dev/null @@ -1,51 +0,0 @@ -Bindings for HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs - -Required properties: -- compatible : "ti,am654-hbmc" for AM654 SoC -- reg : Two entries: - First entry pointed to the register space of HBMC controller - Second entry pointing to the memory map region dedicated for - MMIO access to attached flash devices -- ranges : Address translation from offset within CS to allocated MMIO - space in SoC - -Optional properties: -- mux-controls : phandle to the multiplexer that controls selection of - HBMC vs OSPI inside Flash SubSystem (FSS). Default is OSPI, - if property is absent. - See Documentation/devicetree/bindings/mux/reg-mux.txt - for mmio-mux binding details - -Example: - - system-controller@47000000 { - compatible = "syscon", "simple-mfd"; - reg = <0x0 0x47000000 0x0 0x100>; - #address-cells = <2>; - #size-cells = <2>; - ranges; - - hbmc_mux: multiplexer { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x4 0x2>; /* 0: reg 0x4, bit 1 */ - }; - }; - - hbmc: hyperbus@47034000 { - compatible = "ti,am654-hbmc"; - reg = <0x0 0x47034000 0x0 0x100>, - <0x5 0x00000000 0x1 0x0000000>; - power-domains = <&k3_pds 55>; - #address-cells = <2>; - #size-cells = <1>; - ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ - <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ - mux-controls = <&hbmc_mux 0>; - - /* Slave flash node */ - flash@0,0 { - compatible = "cypress,hyperflash", "cfi-flash"; - reg = <0x0 0x0 0x4000000>; - }; - }; diff --git a/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml new file mode 100644 index 000000000000..30b458c41cac --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/ti,am654-hbmc.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/ti,am654-hbmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HyperBus Memory Controller (HBMC) on TI's K3 family of SoCs + +maintainers: + - Vignesh Raghavendra <vigneshr@ti.com> + +properties: + compatible: + const: ti,am654-hbmc + + reg: + maxItems: 2 + + power-domains: true + '#address-cells': true + '#size-cells': true + ranges: true + + mux-controls: + description: MMIO mux controller node to select b/w OSPI and HBMC. + + clocks: + maxItems: 1 + +patternProperties: + "^flash@[0-1],[0-9a-f]+$": + type: object + +required: + - compatible + - reg + - ranges + - clocks + - '#address-cells' + - '#size-cells' + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + hbmc: memory-controller@47034000 { + compatible = "ti,am654-hbmc"; + reg = <0x0 0x47034000 0x0 0x100>, + <0x5 0x00000000 0x1 0x0000000>; + ranges = <0x0 0x0 0x5 0x00000000 0x4000000>, /* CS0 - 64MB */ + <0x1 0x0 0x5 0x04000000 0x4000000>; /* CS1 - 64MB */ + clocks = <&k3_clks 102 0>; + #address-cells = <2>; + #size-cells = <1>; + power-domains = <&k3_pds 55>; + mux-controls = <&hbmc_mux 0>; + + flash@0,0 { + compatible = "cypress,hyperflash", "cfi-flash"; + reg = <0x0 0x0 0x4000000>; + #address-cells = <1>; + #size-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mux/adi,adg792a.txt b/Documentation/devicetree/bindings/mux/adi,adg792a.txt index 96b787a69f50..b0e5bf6903d8 100644 --- a/Documentation/devicetree/bindings/mux/adi,adg792a.txt +++ b/Documentation/devicetree/bindings/mux/adi,adg792a.txt @@ -5,7 +5,7 @@ Required properties: - #mux-control-cells : <0> if parallel (the three muxes are bound together with a single mux controller controlling all three muxes), or <1> if not (one mux controller for each mux). -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADG792G: - gpio-controller : if present, #gpio-cells below is required. diff --git a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt index be6947f4d86b..453a38961c13 100644 --- a/Documentation/devicetree/bindings/mux/adi,adgs1408.txt +++ b/Documentation/devicetree/bindings/mux/adi,adgs1408.txt @@ -4,7 +4,7 @@ Required properties: - compatible : Should be one of * "adi,adgs1408" * "adi,adgs1409" -* Standard mux-controller bindings as described in mux-controller.txt +* Standard mux-controller bindings as described in mux-controller.yaml Optional properties for ADGS1408/1409: - gpio-controller : if present, #gpio-cells is required. diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.txt b/Documentation/devicetree/bindings/mux/gpio-mux.txt deleted file mode 100644 index b8f746344d80..000000000000 --- a/Documentation/devicetree/bindings/mux/gpio-mux.txt +++ /dev/null @@ -1,69 +0,0 @@ -GPIO-based multiplexer controller bindings - -Define what GPIO pins are used to control a multiplexer. Or several -multiplexers, if the same pins control more than one multiplexer. - -Required properties: -- compatible : "gpio-mux" -- mux-gpios : list of gpios used to control the multiplexer, least - significant bit first. -- #mux-control-cells : <0> -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-state : if present, the state the mux will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state is defined as the number represented by the -multiplexer GPIO pins, where the first pin is the least significant -bit. An active pin is a binary 1, an inactive pin is a binary 0. - -Example: - - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mux/gpio-mux.yaml b/Documentation/devicetree/bindings/mux/gpio-mux.yaml new file mode 100644 index 000000000000..0a7c8d64981a --- /dev/null +++ b/Documentation/devicetree/bindings/mux/gpio-mux.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/gpio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: GPIO-based multiplexer controller bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + Define what GPIO pins are used to control a multiplexer. Or several + multiplexers, if the same pins control more than one multiplexer. + + The multiplexer state is defined as the number represented by the + multiplexer GPIO pins, where the first pin is the least significant + bit. An active pin is a binary 1, an inactive pin is a binary 0. + +properties: + compatible: + const: gpio-mux + + mux-gpios: + description: + List of gpios used to control the multiplexer, least significant bit first. + + '#mux-control-cells': + const: 0 + + idle-state: + default: -1 + +required: + - compatible + - mux-gpios + - "#mux-control-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/mux-consumer.yaml b/Documentation/devicetree/bindings/mux/mux-consumer.yaml new file mode 100644 index 000000000000..7af93298ab5c --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-consumer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-consumer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller consumer bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + Mux controller consumers should specify a list of mux controllers that they + want to use with a property containing a 'mux-ctrl-list': + + mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list] + single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier] + mux-ctrl-phandle : phandle to mux controller node + mux-ctrl-specifier : array of #mux-control-cells specifying the + given mux controller (controller specific) + + Mux controller properties should be named "mux-controls". The exact meaning of + each mux controller property must be documented in the device tree binding for + each consumer. An optional property "mux-control-names" may contain a list of + strings to label each of the mux controllers listed in the "mux-controls" + property. + + mux-ctrl-specifier typically encodes the chip-relative mux controller number. + If the mux controller chip only provides a single mux controller, the + mux-ctrl-specifier can typically be left out. + +select: true + +properties: + mux-controls: + $ref: /schemas/types.yaml#/definitions/phandle-array + + mux-control-names: + description: + Devices that use more than a single mux controller can use the + "mux-control-names" property to map the name of the requested mux + controller to an index into the list given by the "mux-controls" property. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/mux/mux-controller.txt b/Documentation/devicetree/bindings/mux/mux-controller.txt deleted file mode 100644 index 4f47e4bd2fa0..000000000000 --- a/Documentation/devicetree/bindings/mux/mux-controller.txt +++ /dev/null @@ -1,157 +0,0 @@ -Common multiplexer controller bindings -====================================== - -A multiplexer (or mux) controller will have one, or several, consumer devices -that uses the mux controller. Thus, a mux controller can possibly control -several parallel multiplexers. Presumably there will be at least one -multiplexer needed by each consumer, but a single mux controller can of course -control several multiplexers for a single consumer. - -A mux controller provides a number of states to its consumers, and the state -space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, -0-7 for an 8-way multiplexer, etc. - - -Consumers ---------- - -Mux controller consumers should specify a list of mux controllers that they -want to use with a property containing a 'mux-ctrl-list': - - mux-ctrl-list ::= <single-mux-ctrl> [mux-ctrl-list] - single-mux-ctrl ::= <mux-ctrl-phandle> [mux-ctrl-specifier] - mux-ctrl-phandle : phandle to mux controller node - mux-ctrl-specifier : array of #mux-control-cells specifying the - given mux controller (controller specific) - -Mux controller properties should be named "mux-controls". The exact meaning of -each mux controller property must be documented in the device tree binding for -each consumer. An optional property "mux-control-names" may contain a list of -strings to label each of the mux controllers listed in the "mux-controls" -property. - -Drivers for devices that use more than a single mux controller can use the -"mux-control-names" property to map the name of the requested mux controller -to an index into the list given by the "mux-controls" property. - -mux-ctrl-specifier typically encodes the chip-relative mux controller number. -If the mux controller chip only provides a single mux controller, the -mux-ctrl-specifier can typically be left out. - -Example: - - /* One consumer of a 2-way mux controller (one GPIO-line) */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - mux-control-names = "adc"; - - channels = "sync", "in"; - }; - -Note that in the example above, specifying the "mux-control-names" is redundant -because there is only one mux controller in the list. However, if the driver -for the consumer node in fact asks for a named mux controller, that name is of -course still required. - - /* - * Two consumers (one for an ADC line and one for an i2c bus) of - * parallel 4-way multiplexers controlled by the same two GPIO-lines. - */ - mux: mux-controller { - compatible = "gpio-mux"; - #mux-control-cells = <0>; - - mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, - <&pioA 1 GPIO_ACTIVE_HIGH>; - }; - - adc-mux { - compatible = "io-channel-mux"; - io-channels = <&adc 0>; - io-channel-names = "parent"; - - mux-controls = <&mux>; - - channels = "sync-1", "in", "out", "sync-2"; - }; - - i2c-mux { - compatible = "i2c-mux"; - i2c-parent = <&i2c1>; - - mux-controls = <&mux>; - - #address-cells = <1>; - #size-cells = <0>; - - i2c@0 { - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - ssd1307: oled@3c { - /* ... */ - }; - }; - - i2c@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - pca9555: pca9555@20 { - /* ... */ - }; - }; - }; - - -Mux controller nodes --------------------- - -Mux controller nodes must specify the number of cells used for the -specifier using the '#mux-control-cells' property. - -Optionally, mux controller nodes can also specify the state the mux should -have when it is idle. The idle-state property is used for this. If the -idle-state is not present, the mux controller is typically left as is when -it is idle. For multiplexer chips that expose several mux controllers, the -idle-state property is an array with one idle state for each mux controller. - -The special value (-1) may be used to indicate that the mux should be left -as is when it is idle. This is the default, but can still be useful for -mux controller chips with more than one mux controller, particularly when -there is a need to "step past" a mux controller and set some other idle -state for a mux controller with a higher index. - -Some mux controllers have the ability to disconnect the input/output of the -multiplexer. Using this disconnected high-impedance state as the idle state -is indicated with idle state (-2). - -These constants are available in - - #include <dt-bindings/mux/mux.h> - -as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). - -An example mux controller node look like this (the adg972a chip is a triple -4-way multiplexer): - - mux: mux-controller@50 { - compatible = "adi,adg792a"; - reg = <0x50>; - #mux-control-cells = <1>; - - idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>; - }; diff --git a/Documentation/devicetree/bindings/mux/mux-controller.yaml b/Documentation/devicetree/bindings/mux/mux-controller.yaml new file mode 100644 index 000000000000..736a84c3b6a5 --- /dev/null +++ b/Documentation/devicetree/bindings/mux/mux-controller.yaml @@ -0,0 +1,182 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/mux-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common multiplexer controller provider bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: | + A multiplexer (or mux) controller will have one, or several, consumer devices + that uses the mux controller. Thus, a mux controller can possibly control + several parallel multiplexers. Presumably there will be at least one + multiplexer needed by each consumer, but a single mux controller can of course + control several multiplexers for a single consumer. + + A mux controller provides a number of states to its consumers, and the state + space is a simple zero-based enumeration. I.e. 0-1 for a 2-way multiplexer, + 0-7 for an 8-way multiplexer, etc. + + + Mux controller nodes + -------------------- + + Mux controller nodes must specify the number of cells used for the + specifier using the '#mux-control-cells' property. + + Optionally, mux controller nodes can also specify the state the mux should + have when it is idle. The idle-state property is used for this. If the + idle-state is not present, the mux controller is typically left as is when + it is idle. For multiplexer chips that expose several mux controllers, the + idle-state property is an array with one idle state for each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + + These constants are available in + + #include <dt-bindings/mux/mux.h> + + as MUX_IDLE_AS_IS (-1) and MUX_IDLE_DISCONNECT (-2). + + An example mux controller node look like this (the adg972a chip is a triple + 4-way multiplexer): + + mux: mux-controller@50 { + compatible = "adi,adg792a"; + reg = <0x50>; + #mux-control-cells = <1>; + + idle-state = <MUX_IDLE_DISCONNECT MUX_IDLE_AS_IS 2>; + }; + +select: + anyOf: + - properties: + $nodename: + pattern: '^mux-controller' + - required: + - '#mux-control-cells' + +properties: + $nodename: + pattern: '^mux-controller(@.*|-[0-9a-f]+)?$' + + '#mux-control-cells': + enum: [ 0, 1 ] + + idle-state: + $ref: /schemas/types.yaml#/definitions/int32 + minimum: -2 + + idle-states: + description: | + Mux controller nodes can specify the state the mux should have when it is + idle. If the idle-state is not present, the mux controller is typically + left as is when it is idle. For multiplexer chips that expose several mux + controllers, the idle-state property is an array with one idle state for + each mux controller. + + The special value (-1) may be used to indicate that the mux should be left + as is when it is idle. This is the default, but can still be useful for + mux controller chips with more than one mux controller, particularly when + there is a need to "step past" a mux controller and set some other idle + state for a mux controller with a higher index. + + Some mux controllers have the ability to disconnect the input/output of the + multiplexer. Using this disconnected high-impedance state as the idle state + is indicated with idle state (-2). + $ref: /schemas/types.yaml#/definitions/int32-array + items: + minimum: -2 + +additionalProperties: true + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + /* One consumer of a 2-way mux controller (one GPIO-line) */ + mux: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux>; + mux-control-names = "adc"; + + channels = "sync", "in"; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + + /* + * Two consumers (one for an ADC line and one for an i2c bus) of + * parallel 4-way multiplexers controlled by the same two GPIO-lines. + */ + mux2: mux-controller { + compatible = "gpio-mux"; + #mux-control-cells = <0>; + + mux-gpios = <&pioA 0 GPIO_ACTIVE_HIGH>, + <&pioA 1 GPIO_ACTIVE_HIGH>; + }; + + adc-mux { + compatible = "io-channel-mux"; + io-channels = <&adc 0>; + io-channel-names = "parent"; + + mux-controls = <&mux2>; + + channels = "sync-1", "in", "out", "sync-2"; + }; + + i2c-mux { + compatible = "i2c-mux"; + i2c-parent = <&i2c1>; + + mux-controls = <&mux2>; + + #address-cells = <1>; + #size-cells = <0>; + + i2c@0 { + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + ssd1307: oled@3c { + reg = <0x3c>; + }; + }; + + i2c@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + pca9555: pca9555@20 { + reg = <0x20>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mux/reg-mux.txt b/Documentation/devicetree/bindings/mux/reg-mux.txt deleted file mode 100644 index 4afd7ba73d60..000000000000 --- a/Documentation/devicetree/bindings/mux/reg-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Generic register bitfield-based multiplexer controller bindings - -Define register bitfields to be used to control multiplexers. The parent -device tree node must be a device node to provide register r/w access. - -Required properties: -- compatible : should be one of - "reg-mux" : if parent device of mux controller is not syscon device - "mmio-mux" : if parent device of mux controller is syscon device -- #mux-control-cells : <1> -- mux-reg-masks : an array of register offset and pre-shifted bitfield mask - pairs, each describing a single mux control. -* Standard mux-controller bindings as decribed in mux-controller.txt - -Optional properties: -- idle-states : if present, the state the muxes will have when idle. The - special state MUX_IDLE_AS_IS is the default. - -The multiplexer state of each multiplexer is defined as the value of the -bitfield described by the corresponding register offset and bitfield mask -pair in the mux-reg-masks array. - -Example 1: -The parent device of mux controller is not a syscon device. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -Example 2: -The parent device of mux controller is syscon device. - -syscon { - compatible = "syscon"; - - mux: mux-controller { - compatible = "mmio-mux"; - #mux-control-cells = <1>; - - mux-reg-masks = <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ - <0x3 0x40>, /* 1: reg 0x3, bit 6 */ - idle-states = <MUX_IDLE_AS_IS>, <0>; - }; -}; - -video-mux { - compatible = "video-mux"; - mux-controls = <&mux 0>; - #address-cells = <1>; - #size-cells = <0>; - - ports { - /* inputs 0..3 */ - port@0 { - reg = <0>; - }; - port@1 { - reg = <1>; - }; - port@2 { - reg = <2>; - }; - port@3 { - reg = <3>; - }; - - /* output */ - port@4 { - reg = <4>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mux/reg-mux.yaml b/Documentation/devicetree/bindings/mux/reg-mux.yaml new file mode 100644 index 000000000000..60d5746eb39d --- /dev/null +++ b/Documentation/devicetree/bindings/mux/reg-mux.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mux/reg-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic register bitfield-based multiplexer controller bindings + +maintainers: + - Peter Rosin <peda@axentia.se> + +description: |+ + Define register bitfields to be used to control multiplexers. The parent + device tree node must be a device node to provide register r/w access. + +properties: + compatible: + enum: + - reg-mux # parent device of mux controller is not syscon device + - mmio-mux # parent device of mux controller is syscon device + + reg: true + + '#mux-control-cells': + const: 1 + + mux-reg-masks: + description: an array of register offset and pre-shifted bitfield mask + pairs, each describing a single mux control. + + idle-states: true + +required: + - compatible + - mux-reg-masks + - '#mux-control-cells' + +additionalProperties: false + +examples: + - | + /* The parent device of mux controller is not a syscon device. */ + + #include <dt-bindings/mux/mux.h> + + mux-controller { + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = + <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux1 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + - | + /* The parent device of mux controller is syscon device. */ + + #include <dt-bindings/mux/mux.h> + syscon@1000 { + compatible = "fsl,imx7d-iomuxc-gpr", "fsl,imx6q-iomuxc-gpr", "syscon", "simple-mfd"; + reg = <0x1000 0x100>; + + mux2: mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + + mux-reg-masks = + <0x3 0x30>, /* 0: reg 0x3, bits 5:4 */ + <0x3 0x40>; /* 1: reg 0x3, bit 6 */ + idle-states = <MUX_IDLE_AS_IS>, <0>; + }; + }; + + video-mux { + compatible = "video-mux"; + mux-controls = <&mux2 0>; + #address-cells = <1>; + #size-cells = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + /* inputs 0..3 */ + port@0 { + reg = <0>; + }; + port@1 { + reg = <1>; + }; + port@2 { + reg = <2>; + }; + port@3 { + reg = <3>; + }; + + /* output */ + port@4 { + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml index 0467441d7037..608e1d62bed5 100644 --- a/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/amlogic,meson-dwmac.yaml @@ -43,7 +43,6 @@ allOf: properties: clocks: minItems: 3 - maxItems: 4 items: - description: GMAC main clock - description: First parent clock of the internal mux @@ -52,7 +51,6 @@ allOf: clock-names: minItems: 3 - maxItems: 4 items: - const: stmmaceth - const: clkin0 diff --git a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml index 2f46e45dcd60..a93d2f165899 100644 --- a/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml +++ b/Documentation/devicetree/bindings/net/brcm,bcm4908-enet.yaml @@ -23,14 +23,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RX interrupt - description: TX interrupt interrupt-names: minItems: 1 - maxItems: 2 items: - const: rx - const: tx diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt deleted file mode 100644 index 8ba9ed11d716..000000000000 --- a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.txt +++ /dev/null @@ -1,23 +0,0 @@ -* Broadcom iProc MDIO bus controller - -Required properties: -- compatible: should be "brcm,iproc-mdio" -- reg: address and length of the register set for the MDIO interface -- #size-cells: must be 1 -- #address-cells: must be 0 - -Child nodes of this MDIO bus controller node are standard Ethernet PHY device -nodes as described in Documentation/devicetree/bindings/net/phy.txt - -Example: - -mdio@18002000 { - compatible = "brcm,iproc-mdio"; - reg = <0x18002000 0x8>; - #size-cells = <1>; - #address-cells = <0>; - - enet-gphy@0 { - reg = <0>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml new file mode 100644 index 000000000000..3031395f7e6e --- /dev/null +++ b/Documentation/devicetree/bindings/net/brcm,iproc-mdio.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/brcm,iproc-mdio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc MDIO bus controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +allOf: + - $ref: mdio.yaml# + +properties: + compatible: + const: brcm,iproc-mdio + + reg: + maxItems: 1 + +unevaluatedProperties: false + +required: + - reg + +examples: + - | + mdio@18002000 { + compatible = "brcm,iproc-mdio"; + reg = <0x18002000 0x8>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@0 { + reg = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt index b58843f29591..deb9e852ea27 100644 --- a/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt +++ b/Documentation/devicetree/bindings/net/brcm,mdio-mux-iproc.txt @@ -17,7 +17,7 @@ Optional properties: - clocks: phandle of the core clock which drives the mdio block. Additional information regarding generic multiplexer properties can be found -at- Documentation/devicetree/bindings/net/mdio-mux.txt +at- Documentation/devicetree/bindings/net/mdio-mux.yaml for example: diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 798fa5fb7bb2..f84e31348d80 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -30,14 +30,12 @@ properties: - description: interrupt line0 - description: interrupt line1 minItems: 1 - maxItems: 2 interrupt-names: items: - const: int0 - const: int1 minItems: 1 - maxItems: 2 clocks: items: diff --git a/Documentation/devicetree/bindings/net/can/c_can.txt b/Documentation/devicetree/bindings/net/can/c_can.txt index 2d504256b0d8..366479806acb 100644 --- a/Documentation/devicetree/bindings/net/can/c_can.txt +++ b/Documentation/devicetree/bindings/net/can/c_can.txt @@ -19,10 +19,10 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains : Should contain a phandle to a PM domain provider node and an args specifier containing the DCAN device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml - clocks : CAN functional clock phandle. This property is as per the binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml Optional properties: - syscon-raminit : Handle to system control region that contains the diff --git a/Documentation/devicetree/bindings/net/can/rcar_can.txt b/Documentation/devicetree/bindings/net/can/rcar_can.txt deleted file mode 100644 index 90ac4fef23f5..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_can.txt +++ /dev/null @@ -1,80 +0,0 @@ -Renesas R-Car CAN controller Device Tree Bindings -------------------------------------------------- - -Required properties: -- compatible: "renesas,can-r8a7742" if CAN controller is a part of R8A7742 SoC. - "renesas,can-r8a7743" if CAN controller is a part of R8A7743 SoC. - "renesas,can-r8a7744" if CAN controller is a part of R8A7744 SoC. - "renesas,can-r8a7745" if CAN controller is a part of R8A7745 SoC. - "renesas,can-r8a77470" if CAN controller is a part of R8A77470 SoC. - "renesas,can-r8a774a1" if CAN controller is a part of R8A774A1 SoC. - "renesas,can-r8a774b1" if CAN controller is a part of R8A774B1 SoC. - "renesas,can-r8a774c0" if CAN controller is a part of R8A774C0 SoC. - "renesas,can-r8a774e1" if CAN controller is a part of R8A774E1 SoC. - "renesas,can-r8a7778" if CAN controller is a part of R8A7778 SoC. - "renesas,can-r8a7779" if CAN controller is a part of R8A7779 SoC. - "renesas,can-r8a7790" if CAN controller is a part of R8A7790 SoC. - "renesas,can-r8a7791" if CAN controller is a part of R8A7791 SoC. - "renesas,can-r8a7792" if CAN controller is a part of R8A7792 SoC. - "renesas,can-r8a7793" if CAN controller is a part of R8A7793 SoC. - "renesas,can-r8a7794" if CAN controller is a part of R8A7794 SoC. - "renesas,can-r8a7795" if CAN controller is a part of R8A7795 SoC. - "renesas,can-r8a7796" if CAN controller is a part of R8A77960 SoC. - "renesas,can-r8a77961" if CAN controller is a part of R8A77961 SoC. - "renesas,can-r8a77965" if CAN controller is a part of R8A77965 SoC. - "renesas,can-r8a77990" if CAN controller is a part of R8A77990 SoC. - "renesas,can-r8a77995" if CAN controller is a part of R8A77995 SoC. - "renesas,rcar-gen1-can" for a generic R-Car Gen1 compatible device. - "renesas,rcar-gen2-can" for a generic R-Car Gen2 or RZ/G1 - compatible device. - "renesas,rcar-gen3-can" for a generic R-Car Gen3 or RZ/G2 - compatible device. - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first - followed by the generic version. - -- reg: physical base address and size of the R-Car CAN register map. -- interrupts: interrupt specifier for the sole interrupt. -- clocks: phandles and clock specifiers for 3 CAN clock inputs. -- clock-names: 3 clock input name strings: "clkp1", "clkp2", and "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A77960, R8A77961, R8A77965, R8A77990, and R8A77995: -For the denoted SoCs, "clkp2" can be CANFD clock. This is a div6 clock and can -be used by both CAN and CAN FD controller at the same time. It needs to be -scaled to maximum frequency if any of these controllers use it. This is done -using the below properties: - -- assigned-clocks: phandle of clkp2(CANFD) clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional properties: -- renesas,can-clock-select: R-Car CAN Clock Source Select. Valid values are: - <0x0> (default) : Peripheral clock (clkp1) - <0x1> : Peripheral clock (clkp2) - <0x3> : External input clock - -Example -------- - -SoC common .dtsi file: - - can0: can@e6e80000 { - compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; - reg = <0 0xe6e80000 0 0x1000>; - interrupts = <0 186 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&mstp9_clks R8A7791_CLK_RCAN0>, - <&cpg_clocks R8A7791_CLK_RCAN>, <&can_clk>; - clock-names = "clkp1", "clkp2", "can_clk"; - status = "disabled"; - }; - -Board specific .dts file: - -&can0 { - pinctrl-0 = <&can0_pins>; - pinctrl-names = "default"; - status = "okay"; -}; diff --git a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt b/Documentation/devicetree/bindings/net/can/rcar_canfd.txt deleted file mode 100644 index 248c4ed97a0a..000000000000 --- a/Documentation/devicetree/bindings/net/can/rcar_canfd.txt +++ /dev/null @@ -1,107 +0,0 @@ -Renesas R-Car CAN FD controller Device Tree Bindings ----------------------------------------------------- - -Required properties: -- compatible: Must contain one or more of the following: - - "renesas,rcar-gen3-canfd" for R-Car Gen3 and RZ/G2 compatible controllers. - - "renesas,r8a774a1-canfd" for R8A774A1 (RZ/G2M) compatible controller. - - "renesas,r8a774b1-canfd" for R8A774B1 (RZ/G2N) compatible controller. - - "renesas,r8a774c0-canfd" for R8A774C0 (RZ/G2E) compatible controller. - - "renesas,r8a774e1-canfd" for R8A774E1 (RZ/G2H) compatible controller. - - "renesas,r8a7795-canfd" for R8A7795 (R-Car H3) compatible controller. - - "renesas,r8a7796-canfd" for R8A7796 (R-Car M3-W) compatible controller. - - "renesas,r8a77965-canfd" for R8A77965 (R-Car M3-N) compatible controller. - - "renesas,r8a77970-canfd" for R8A77970 (R-Car V3M) compatible controller. - - "renesas,r8a77980-canfd" for R8A77980 (R-Car V3H) compatible controller. - - "renesas,r8a77990-canfd" for R8A77990 (R-Car E3) compatible controller. - - "renesas,r8a77995-canfd" for R8A77995 (R-Car D3) compatible controller. - - When compatible with the generic version, nodes must list the - SoC-specific version corresponding to the platform first, followed by the - family-specific and/or generic versions. - -- reg: physical base address and size of the R-Car CAN FD register map. -- interrupts: interrupt specifiers for the Channel & Global interrupts -- clocks: phandles and clock specifiers for 3 clock inputs. -- clock-names: 3 clock input name strings: "fck", "canfd", "can_clk". -- pinctrl-0: pin control group to be used for this controller. -- pinctrl-names: must be "default". - -Required child nodes: -The controller supports two channels and each is represented as a child node. -The name of the child nodes are "channel0" and "channel1" respectively. Each -child node supports the "status" property only, which is used to -enable/disable the respective channel. - -Required properties for R8A774A1, R8A774B1, R8A774C0, R8A774E1, R8A7795, -R8A7796, R8A77965, R8A77990, and R8A77995: -In the denoted SoCs, canfd clock is a div6 clock and can be used by both CAN -and CAN FD controller at the same time. It needs to be scaled to maximum -frequency if any of these controllers use it. This is done using the below -properties: - -- assigned-clocks: phandle of canfd clock. -- assigned-clock-rates: maximum frequency of this clock. - -Optional property: -The controller can operate in either CAN FD only mode (default) or -Classical CAN only mode. The mode is global to both the channels. In order to -enable the later, define the following optional property. - - renesas,no-can-fd: puts the controller in Classical CAN only mode. - -Example -------- - -SoC common .dtsi file: - - canfd: can@e66c0000 { - compatible = "renesas,r8a7795-canfd", - "renesas,rcar-gen3-canfd"; - reg = <0 0xe66c0000 0 0x8000>; - interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&cpg CPG_MOD 914>, - <&cpg CPG_CORE R8A7795_CLK_CANFD>, - <&can_clk>; - clock-names = "fck", "canfd", "can_clk"; - assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; - assigned-clock-rates = <40000000>; - power-domains = <&cpg>; - status = "disabled"; - - channel0 { - status = "disabled"; - }; - - channel1 { - status = "disabled"; - }; - }; - -Board specific .dts file: - -E.g. below enables Channel 1 alone in the board in Classical CAN only mode. - -&canfd { - pinctrl-0 = <&canfd1_pins>; - pinctrl-names = "default"; - renesas,no-can-fd; - status = "okay"; - - channel1 { - status = "okay"; - }; -}; - -E.g. below enables Channel 0 alone in the board using External clock -as fCAN clock. - -&canfd { - pinctrl-0 = <&canfd0_pins>, <&can_clk_pins>; - pinctrl-names = "default"; - status = "okay"; - - channel0 { - status = "okay"; - }; -}; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml new file mode 100644 index 000000000000..fadc871fd6b0 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-can.yaml @@ -0,0 +1,139 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN Controller + +maintainers: + - Sergei Shtylyov <sergei.shtylyov@gmail.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,can-r8a7778 # R-Car M1-A + - renesas,can-r8a7779 # R-Car H1 + - const: renesas,rcar-gen1-can # R-Car Gen1 + + - items: + - enum: + - renesas,can-r8a7742 # RZ/G1H + - renesas,can-r8a7743 # RZ/G1M + - renesas,can-r8a7744 # RZ/G1N + - renesas,can-r8a7745 # RZ/G1E + - renesas,can-r8a77470 # RZ/G1C + - renesas,can-r8a7790 # R-Car H2 + - renesas,can-r8a7791 # R-Car M2-W + - renesas,can-r8a7792 # R-Car V2H + - renesas,can-r8a7793 # R-Car M2-N + - renesas,can-r8a7794 # R-Car E2 + - const: renesas,rcar-gen2-can # R-Car Gen2 and RZ/G1 + + - items: + - enum: + - renesas,can-r8a774a1 # RZ/G2M + - renesas,can-r8a774b1 # RZ/G2N + - renesas,can-r8a774c0 # RZ/G2E + - renesas,can-r8a774e1 # RZ/G2H + - renesas,can-r8a7795 # R-Car H3 + - renesas,can-r8a7796 # R-Car M3-W + - renesas,can-r8a77961 # R-Car M3-W+ + - renesas,can-r8a77965 # R-Car M3-N + - renesas,can-r8a77990 # R-Car E3 + - renesas,can-r8a77995 # R-Car D3 + - const: renesas,rcar-gen3-can # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 3 + + clock-names: + items: + - const: clkp1 + - const: clkp2 + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,can-clock-select: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 0, 1, 3 ] + default: 0 + description: | + R-Car CAN Clock Source Select. Valid values are: + <0x0> (default) : Peripheral clock (clkp1) + <0x1> : Peripheral clock (clkp2) + <0x3> : External input clock + + assigned-clocks: + description: + Reference to the clkp2 (CANFD) clock. + On R-Car Gen3 and RZ/G2 SoCs, "clkp2" is the CANFD clock. This is a div6 + clock and can be used by both CAN and CAN FD controllers at the same + time. It needs to be scaled to maximum frequency if any of these + controllers use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + +allOf: + - $ref: can-controller.yaml# + + - if: + not: + properties: + compatible: + contains: + const: renesas,rcar-gen1-can + then: + required: + - resets + + - if: + properties: + compatible: + contains: + const: renesas,rcar-gen3-can + then: + required: + - assigned-clocks + - assigned-clock-rates + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7791-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7791-sysc.h> + + can0: can@e6e80000 { + compatible = "renesas,can-r8a7791", "renesas,rcar-gen2-can"; + reg = <0xe6e80000 0x1000>; + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 916>, + <&cpg CPG_CORE R8A7791_CLK_RCAN>, <&can_clk>; + clock-names = "clkp1", "clkp2", "can_clk"; + power-domains = <&sysc R8A7791_PD_ALWAYS_ON>; + resets = <&cpg 916>; + }; diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml new file mode 100644 index 000000000000..0b33ba9ccb47 --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/renesas,rcar-canfd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car CAN FD Controller + +maintainers: + - Fabrizio Castro <fabrizio.castro.jz@renesas.com> + +allOf: + - $ref: can-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - enum: + - renesas,r8a774a1-canfd # RZ/G2M + - renesas,r8a774b1-canfd # RZ/G2N + - renesas,r8a774c0-canfd # RZ/G2E + - renesas,r8a774e1-canfd # RZ/G2H + - renesas,r8a7795-canfd # R-Car H3 + - renesas,r8a7796-canfd # R-Car M3-W + - renesas,r8a77965-canfd # R-Car M3-N + - renesas,r8a77970-canfd # R-Car V3M + - renesas,r8a77980-canfd # R-Car V3H + - renesas,r8a77990-canfd # R-Car E3 + - renesas,r8a77995-canfd # R-Car D3 + - const: renesas,rcar-gen3-canfd # R-Car Gen3 and RZ/G2 + + reg: + maxItems: 1 + + interrupts: + items: + - description: Channel interrupt + - description: Global interrupt + + clocks: + maxItems: 3 + + clock-names: + items: + - const: fck + - const: canfd + - const: can_clk + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + renesas,no-can-fd: + $ref: /schemas/types.yaml#/definitions/flag + description: + The controller can operate in either CAN FD only mode (default) or + Classical CAN only mode. The mode is global to both the channels. + Specify this property to put the controller in Classical CAN only mode. + + assigned-clocks: + description: + Reference to the CANFD clock. The CANFD clock is a div6 clock and can be + used by both CAN (if present) and CAN FD controllers at the same time. + It needs to be scaled to maximum frequency if any of these controllers + use it. + + assigned-clock-rates: + description: Maximum frequency of the CANFD clock. + +patternProperties: + "^channel[01]$": + type: object + description: + The controller supports two channels and each is represented as a child + node. Each child node supports the "status" property only, which + is used to enable/disable the respective channel. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - resets + - assigned-clocks + - assigned-clock-rates + - channel0 + - channel1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a7795-cpg-mssr.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/r8a7795-sysc.h> + + canfd: can@e66c0000 { + compatible = "renesas,r8a7795-canfd", + "renesas,rcar-gen3-canfd"; + reg = <0xe66c0000 0x8000>; + interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cpg CPG_MOD 914>, + <&cpg CPG_CORE R8A7795_CLK_CANFD>, + <&can_clk>; + clock-names = "fck", "canfd", "can_clk"; + assigned-clocks = <&cpg CPG_CORE R8A7795_CLK_CANFD>; + assigned-clock-rates = <40000000>; + power-domains = <&sysc R8A7795_PD_ALWAYS_ON>; + resets = <&cpg 914>; + + channel0 { + }; + + channel1 { + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml index d730fe5a4355..d159ac78cec1 100644 --- a/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml +++ b/Documentation/devicetree/bindings/net/dsa/brcm,sf2.yaml @@ -48,14 +48,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: switch's main clock - description: dividing of the switch core clock clock-names: minItems: 1 - maxItems: 2 items: - const: sw_switch - const: sw_switch_mdiv diff --git a/Documentation/devicetree/bindings/net/dsa/mt7530.txt b/Documentation/devicetree/bindings/net/dsa/mt7530.txt index de04626a8e9d..18247ebfc487 100644 --- a/Documentation/devicetree/bindings/net/dsa/mt7530.txt +++ b/Documentation/devicetree/bindings/net/dsa/mt7530.txt @@ -81,6 +81,12 @@ Optional properties: - gpio-controller: Boolean; if defined, MT7530's LED controller will run on GPIO mode. - #gpio-cells: Must be 2 if gpio-controller is defined. +- interrupt-controller: Boolean; Enables the internal interrupt controller. + +If interrupt-controller is defined, the following properties are required. + +- #interrupt-cells: Must be 1. +- interrupts: Parent interrupt for the interrupt controller. See Documentation/devicetree/bindings/net/dsa/dsa.txt for a list of additional required, optional properties and how the integrated switch subnodes must diff --git a/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml new file mode 100644 index 000000000000..0b8a05dd52e6 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/nxp,sja1105.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/nxp,sja1105.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP SJA1105 Automotive Ethernet Switch Family Device Tree Bindings + +description: + The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944.pdf) of at + least one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum + cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed + depends on the SPI bus master driver. + +allOf: + - $ref: "dsa.yaml#" + +maintainers: + - Vladimir Oltean <vladimir.oltean@nxp.com> + +properties: + compatible: + enum: + - nxp,sja1105e + - nxp,sja1105t + - nxp,sja1105p + - nxp,sja1105q + - nxp,sja1105r + - nxp,sja1105s + - nxp,sja1110a + - nxp,sja1110b + - nxp,sja1110c + - nxp,sja1110d + + reg: + maxItems: 1 + + # Optional container node for the 2 internal MDIO buses of the SJA1110 + # (one for the internal 100base-T1 PHYs and the other for the single + # 100base-TX PHY). The "reg" property does not have physical significance. + # The PHY addresses to port correspondence is as follows: for 100base-T1, + # port 5 has PHY 1, port 6 has PHY 2 etc, while for 100base-TX, port 1 has + # PHY 1. + mdios: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + patternProperties: + "^mdio@[0-1]$": + type: object + + allOf: + - $ref: "http://devicetree.org/schemas/net/mdio.yaml#" + + properties: + compatible: + oneOf: + - enum: + - nxp,sja1110-base-t1-mdio + - nxp,sja1110-base-tx-mdio + + reg: + oneOf: + - enum: + - 0 + - 1 + + required: + - compatible + - reg + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet-switch@1 { + reg = <0x1>; + compatible = "nxp,sja1105t"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + phy-handle = <&rgmii_phy6>; + phy-mode = "rgmii-id"; + reg = <0>; + }; + + port@1 { + phy-handle = <&rgmii_phy3>; + phy-mode = "rgmii-id"; + reg = <1>; + }; + + port@2 { + phy-handle = <&rgmii_phy4>; + phy-mode = "rgmii-id"; + reg = <2>; + }; + + port@3 { + phy-mode = "rgmii-id"; + reg = <3>; + }; + + port@4 { + ethernet = <&enet2>; + phy-mode = "rgmii"; + reg = <4>; + + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/qca8k.txt b/Documentation/devicetree/bindings/net/dsa/qca8k.txt index ccbc6d89325d..8c73f67c43ca 100644 --- a/Documentation/devicetree/bindings/net/dsa/qca8k.txt +++ b/Documentation/devicetree/bindings/net/dsa/qca8k.txt @@ -3,6 +3,7 @@ Required properties: - compatible: should be one of: + "qca,qca8327" "qca,qca8334" "qca,qca8337" @@ -20,6 +21,10 @@ described in dsa/dsa.txt. If the QCA8K switch is connect to a SoC's external mdio-bus each subnode describing a port needs to have a valid phandle referencing the internal PHY it is connected to. This is because there's no N:N mapping of port and PHY id. +To declare the internal mdio-bus configuration, declare a mdio node in the +switch node and declare the phandle for the port referencing the internal +PHY is connected to. In this config a internal mdio-bus is registered and +the mdio MASTER is used as communication. Don't use mixed external and internal mdio-bus configurations, as this is not supported by the hardware. @@ -149,26 +154,61 @@ for the internal master mdio-bus configuration: port@1 { reg = <1>; label = "lan1"; + phy-mode = "internal"; + phy-handle = <&phy_port1>; }; port@2 { reg = <2>; label = "lan2"; + phy-mode = "internal"; + phy-handle = <&phy_port2>; }; port@3 { reg = <3>; label = "lan3"; + phy-mode = "internal"; + phy-handle = <&phy_port3>; }; port@4 { reg = <4>; label = "lan4"; + phy-mode = "internal"; + phy-handle = <&phy_port4>; }; port@5 { reg = <5>; label = "wan"; + phy-mode = "internal"; + phy-handle = <&phy_port5>; + }; + }; + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + phy_port1: phy@0 { + reg = <0>; + }; + + phy_port2: phy@1 { + reg = <1>; + }; + + phy_port3: phy@2 { + reg = <2>; + }; + + phy_port4: phy@3 { + reg = <3>; + }; + + phy_port5: phy@4 { + reg = <4>; }; }; }; diff --git a/Documentation/devicetree/bindings/net/dsa/sja1105.txt b/Documentation/devicetree/bindings/net/dsa/sja1105.txt deleted file mode 100644 index 13fd21074d48..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/sja1105.txt +++ /dev/null @@ -1,156 +0,0 @@ -NXP SJA1105 switch driver -========================= - -Required properties: - -- compatible: - Must be one of: - - "nxp,sja1105e" - - "nxp,sja1105t" - - "nxp,sja1105p" - - "nxp,sja1105q" - - "nxp,sja1105r" - - "nxp,sja1105s" - - Although the device ID could be detected at runtime, explicit bindings - are required in order to be able to statically check their validity. - For example, SGMII can only be specified on port 4 of R and S devices, - and the non-SGMII devices, while pin-compatible, are not equal in terms - of support for RGMII internal delays (supported on P/Q/R/S, but not on - E/T). - -Optional properties: - -- sja1105,role-mac: -- sja1105,role-phy: - Boolean properties that can be assigned under each port node. By - default (unless otherwise specified) a port is configured as MAC if it - is driving a PHY (phy-handle is present) or as PHY if it is PHY-less - (fixed-link specified, presumably because it is connected to a MAC). - The effect of this property (in either its implicit or explicit form) - is: - - In the case of MII or RMII it specifies whether the SJA1105 port is a - clock source or sink for this interface (not applicable for RGMII - where there is a Tx and an Rx clock). - - In the case of RGMII it affects the behavior regarding internal - delays: - 1. If sja1105,role-mac is specified, and the phy-mode property is one - of "rgmii-id", "rgmii-txid" or "rgmii-rxid", then the entity - designated to apply the delay/clock skew necessary for RGMII - is the PHY. The SJA1105 MAC does not apply any internal delays. - 2. If sja1105,role-phy is specified, and the phy-mode property is one - of the above, the designated entity to apply the internal delays - is the SJA1105 MAC (if hardware-supported). This is only supported - by the second-generation (P/Q/R/S) hardware. On a first-generation - E or T device, it is an error to specify an RGMII phy-mode other - than "rgmii" for a port that is in fixed-link mode. In that case, - the clock skew must either be added by the MAC at the other end of - the fixed-link, or by PCB serpentine traces on the board. - These properties are required, for example, in the case where SJA1105 - ports are at both ends of a MII/RMII PHY-less setup. One end would need - to have sja1105,role-mac, while the other sja1105,role-phy. - -See Documentation/devicetree/bindings/net/dsa/dsa.txt for the list of standard -DSA required and optional properties. - -Other observations ------------------- - -The SJA1105 SPI interface requires a CS-to-CLK time (t2 in UM10944) of at least -one half of t_CLK. At an SPI frequency of 1MHz, this means a minimum -cs_sck_delay of 500ns. Ensuring that this SPI timing requirement is observed -depends on the SPI bus master driver. - -Example -------- - -Ethernet switch connected via SPI to the host, CPU port wired to enet2: - -arch/arm/boot/dts/ls1021a-tsn.dts: - -/* SPI controller of the LS1021 */ -&dspi0 { - sja1105@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - compatible = "nxp,sja1105t"; - spi-max-frequency = <4000000>; - fsl,spi-cs-sck-delay = <1000>; - fsl,spi-sck-cs-delay = <1000>; - ports { - #address-cells = <1>; - #size-cells = <0>; - port@0 { - /* ETH5 written on chassis */ - label = "swp5"; - phy-handle = <&rgmii_phy6>; - phy-mode = "rgmii-id"; - reg = <0>; - /* Implicit "sja1105,role-mac;" */ - }; - port@1 { - /* ETH2 written on chassis */ - label = "swp2"; - phy-handle = <&rgmii_phy3>; - phy-mode = "rgmii-id"; - reg = <1>; - /* Implicit "sja1105,role-mac;" */ - }; - port@2 { - /* ETH3 written on chassis */ - label = "swp3"; - phy-handle = <&rgmii_phy4>; - phy-mode = "rgmii-id"; - reg = <2>; - /* Implicit "sja1105,role-mac;" */ - }; - port@3 { - /* ETH4 written on chassis */ - phy-handle = <&rgmii_phy5>; - label = "swp4"; - phy-mode = "rgmii-id"; - reg = <3>; - /* Implicit "sja1105,role-mac;" */ - }; - port@4 { - /* Internal port connected to eth2 */ - ethernet = <&enet2>; - phy-mode = "rgmii"; - reg = <4>; - /* Implicit "sja1105,role-phy;" */ - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - }; -}; - -/* MDIO controller of the LS1021 */ -&mdio0 { - /* BCM5464 */ - rgmii_phy3: ethernet-phy@3 { - reg = <0x3>; - }; - rgmii_phy4: ethernet-phy@4 { - reg = <0x4>; - }; - rgmii_phy5: ethernet-phy@5 { - reg = <0x5>; - }; - rgmii_phy6: ethernet-phy@6 { - reg = <0x6>; - }; -}; - -/* Ethernet master port of the LS1021 */ -&enet2 { - phy-connection-type = "rgmii"; - status = "ok"; - fixed-link { - speed = <1000>; - full-duplex; - }; -}; diff --git a/Documentation/devicetree/bindings/net/ethernet-controller.yaml b/Documentation/devicetree/bindings/net/ethernet-controller.yaml index e8f04687a3e0..b0933a8c295a 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -68,6 +68,7 @@ properties: - tbi - rev-mii - rmii + - rev-rmii # RX and TX delays are added by the MAC when required - rgmii @@ -97,6 +98,7 @@ properties: - 10gbase-kr - usxgmii - 10gbase-r + - 25gbase-r phy-mode: $ref: "#/properties/phy-connection-type" diff --git a/Documentation/devicetree/bindings/net/ingenic,mac.yaml b/Documentation/devicetree/bindings/net/ingenic,mac.yaml new file mode 100644 index 000000000000..d08a88125a5c --- /dev/null +++ b/Documentation/devicetree/bindings/net/ingenic,mac.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/ingenic,mac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for MAC in Ingenic SoCs + +maintainers: + - 周琰杰 (Zhou Yanjie) <zhouyanjie@wanyeetech.com> + +description: + The Ethernet Media Access Controller in Ingenic SoCs. + +properties: + compatible: + enum: + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-names: + const: macirq + + clocks: + maxItems: 1 + + clock-names: + const: stmmaceth + + mode-reg: + description: An extra syscon register that control ethernet interface and timing delay + + rx-clk-delay-ps: + description: RGMII receive clock delay defined in pico seconds + + tx-clk-delay-ps: + description: RGMII transmit clock delay defined in pico seconds + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - mode-reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/x1000-cgu.h> + + mac: ethernet@134b0000 { + compatible = "ingenic,x1000-mac"; + reg = <0x134b0000 0x2000>; + + interrupt-parent = <&intc>; + interrupts = <55>; + interrupt-names = "macirq"; + + clocks = <&cgu X1000_CLK_MAC>; + clock-names = "stmmaceth"; + + mode-reg = <&mac_phy_ctrl>; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.txt b/Documentation/devicetree/bindings/net/mdio-gpio.txt deleted file mode 100644 index 4d91a36c5cf5..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-gpio.txt +++ /dev/null @@ -1,27 +0,0 @@ -MDIO on GPIOs - -Currently defined compatibles: -- virtual,gpio-mdio -- microchip,mdio-smi0 - -MDC and MDIO lines connected to GPIO controllers are listed in the -gpios property as described in section VIII.1 in the following order: - -MDC, MDIO. - -Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" -node. - -Example: - -aliases { - mdio-gpio0 = &mdio0; -}; - -mdio0: mdio { - compatible = "virtual,mdio-gpio"; - #address-cells = <1>; - #size-cells = <0>; - gpios = <&qe_pio_a 11 - &qe_pio_c 6>; -}; diff --git a/Documentation/devicetree/bindings/net/mdio-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-gpio.yaml new file mode 100644 index 000000000000..1d83b8dcce2c --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-gpio.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MDIO on GPIOs + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Heiner Kallweit <hkallweit1@gmail.com> + - Russell King <linux@armlinux.org.uk> + +allOf: + - $ref: "mdio.yaml#" + +properties: + compatible: + enum: + - virtual,mdio-gpio + - microchip,mdio-smi0 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + gpios: + minItems: 2 + items: + - description: MDC + - description: MDIO + - description: MDO + +#Note: Each gpio-mdio bus should have an alias correctly numbered in "aliases" +#node. +additionalProperties: + type: object + +examples: + - | + aliases { + mdio-gpio0 = &mdio0; + }; + + mdio0: mdio { + compatible = "virtual,mdio-gpio"; + #address-cells = <1>; + #size-cells = <0>; + gpios = <&qe_pio_a 11>, + <&qe_pio_c 6>; + ethphy0: ethernet-phy@0 { + reg = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt b/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt deleted file mode 100644 index 694987d3c17a..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-gpio.txt +++ /dev/null @@ -1,119 +0,0 @@ -Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. - -This is a special case of a MDIO bus multiplexer. One or more GPIO -lines are used to control which child bus is connected. - -Required properties in addition to the generic multiplexer properties: - -- compatible : mdio-mux-gpio. -- gpios : GPIO specifiers for each GPIO line. One or more must be specified. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml new file mode 100644 index 000000000000..71c25c4580ea --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-gpio.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer/switch controlled by GPIO pins. + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: + This is a special case of a MDIO bus multiplexer. One or more GPIO + lines are used to control which child bus is connected. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-gpio + + gpios: + description: + List of GPIOs used to control the multiplexer, least significant bit first. + minItems: 1 + maxItems: 32 + +required: + - compatible + - gpios + +unevaluatedProperties: false + +examples: + - | + /* + An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a + pair of GPIO lines. Child busses 2 and 3 populated with 4 + PHYs each. + */ + mdio-mux { + compatible = "mdio-mux-gpio"; + gpios = <&gpio1 3 0>, <&gpio1 4 0>; + mdio-parent-bus = <&smi1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@2 { + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <10 8>; /* Pin 10, active low */ + }; + }; + + mdio@3 { + reg = <3>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@1 { + reg = <1>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@2 { + reg = <2>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@3 { + reg = <3>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + ethernet-phy@4 { + reg = <4>; + marvell,reg-init = <3 0x10 0 0x5777>, + <3 0x11 0 0x00aa>, + <3 0x12 0 0x4105>, + <3 0x13 0 0x0a60>; + interrupt-parent = <&gpio>; + interrupts = <12 8>; /* Pin 12, active low */ + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt deleted file mode 100644 index 065e8bdb957d..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.txt +++ /dev/null @@ -1,75 +0,0 @@ -Properties for an MDIO bus multiplexer controlled by a memory-mapped device - -This is a special case of a MDIO bus multiplexer. A memory-mapped device, -like an FPGA, is used to control which child bus is connected. The mdio-mux -node must be a child of the memory-mapped device. The driver currently only -supports devices with 8, 16 or 32-bit registers. - -Required properties in addition to the generic multiplexer properties: - -- compatible : string, must contain "mdio-mux-mmioreg" - -- reg : integer, contains the offset of the register that controls the bus - multiplexer. The size field in the 'reg' property is the size of - register, and must therefore be 1, 2, or 4. - -- mux-mask : integer, contains an eight-bit mask that specifies which - bits in the register control the actual bus multiplexer. The - 'reg' property of each child mdio-mux node must be constrained by - this mask. - -Example: - -The FPGA node defines a memory-mapped FPGA with a register space of 0x30 bytes. -For the "EMI2" MDIO bus, register 9 (BRDCFG1) controls the mux on that bus. -A bitmask of 0x6 means that bits 1 and 2 (bit 0 is lsb) are the bits on -BRDCFG1 that control the actual mux. - - /* The FPGA node */ - fpga: board-control@3,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,p5020ds-fpga", "fsl,fpga-ngpixis"; - reg = <3 0 0x30>; - ranges = <0 3 0 0x30>; - - mdio-mux-emi2 { - compatible = "mdio-mux-mmioreg", "mdio-mux"; - mdio-parent-bus = <&xmdio0>; - #address-cells = <1>; - #size-cells = <0>; - reg = <9 1>; // BRDCFG1 - mux-mask = <0x6>; // EMI2 - - emi2_slot1: mdio@0 { // Slot 1 XAUI (FM2) - reg = <0>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot1: ethernet-phy@0 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <4>; - }; - }; - - emi2_slot2: mdio@2 { // Slot 2 XAUI (FM1) - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy_xgmii_slot2: ethernet-phy@4 { - compatible = "ethernet-phy-ieee802.3-c45"; - reg = <0>; - }; - }; - }; - }; - - /* The parent MDIO bus. */ - xmdio0: mdio@f1000 { - #address-cells = <1>; - #size-cells = <0>; - compatible = "fsl,fman-xmdio"; - reg = <0xf1000 0x1000>; - interrupts = <100 1 0 0>; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml new file mode 100644 index 000000000000..cf86bb0b0b62 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-mmioreg.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-mmioreg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer controlled by a memory-mapped device + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + This is a special case of a MDIO bus multiplexer. A memory-mapped device, + like an FPGA, is used to control which child bus is connected. The mdio-mux + node must be a child of the memory-mapped device. The driver currently only + supports devices with 8, 16 or 32-bit registers. + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + items: + - const: mdio-mux-mmioreg + - const: mdio-mux + + reg: + description: Contains the offset of the register that controls the bus + multiplexer. The size field in the 'reg' property is the size of register, + and must therefore be 1, 2, or 4. + maxItems: 1 + + mux-mask: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Contains an eight-bit mask that specifies which bits in the + register control the actual bus multiplexer. The 'reg' property of each + child mdio-mux node must be constrained by this mask. + +required: + - compatible + - reg + - mux-mask + +unevaluatedProperties: false + +examples: + - | + mdio-mux@9 { + compatible = "mdio-mux-mmioreg", "mdio-mux"; + mdio-parent-bus = <&xmdio0>; + #address-cells = <1>; + #size-cells = <0>; + reg = <9 1>; // BRDCFG1 + mux-mask = <0x6>; // EMI2 + + mdio@0 { // Slot 1 XAUI (FM2) + reg = <0>; + #address-cells = <1>; + #size-cells = <0>; + + phy_xgmii_slot1: ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + + mdio@2 { // Slot 2 XAUI (FM1) + reg = <2>; + #address-cells = <1>; + #size-cells = <0>; + + ethernet-phy@4 { + compatible = "ethernet-phy-ieee802.3-c45"; + reg = <4>; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt deleted file mode 100644 index 534e38058fe0..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.txt +++ /dev/null @@ -1,82 +0,0 @@ -Properties for an MDIO bus multiplexer consumer device - -This is a special case of MDIO mux when MDIO mux is defined as a consumer -of a mux producer device. The mux producer can be of any type like mmio mux -producer, gpio mux producer or generic register based mux producer. - -Required properties in addition to the MDIO Bus multiplexer properties: - -- compatible : should be "mmio-mux-multiplexer" -- mux-controls : mux controller node to use for operating the mux -- mdio-parent-bus : phandle to the parent MDIO bus. - -each child node of mdio bus multiplexer consumer device represent a mdio -bus. - -for more information please refer -Documentation/devicetree/bindings/mux/mux-controller.txt -and Documentation/devicetree/bindings/net/mdio-mux.txt - -Example: -In below example the Mux producer and consumer are separate nodes. - -&i2c0 { - fpga@66 { // fpga connected to i2c - compatible = "fsl,lx2160aqds-fpga", "fsl,fpga-qixis-i2c", - "simple-mfd"; - reg = <0x66>; - - mux: mux-controller { // Mux Producer - compatible = "reg-mux"; - #mux-control-cells = <1>; - mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ - <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ - }; - }; -}; - -mdio-mux-1 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 0>; - mdio-parent-bus = <&emdio1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@8 { - reg = <0x8>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; - -mdio-mux-2 { // Mux consumer - compatible = "mdio-mux-multiplexer"; - mux-controls = <&mux 1>; - mdio-parent-bus = <&emdio2>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@0 { - reg = <0x0>; - #address-cells = <1>; - #size-cells = <0>; - }; - - mdio@1 { - reg = <0x1>; - #address-cells = <1>; - #size-cells = <0>; - }; - - .. - .. -}; diff --git a/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml new file mode 100644 index 000000000000..282987074ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux-multiplexer.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux-multiplexer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Properties for an MDIO bus multiplexer consumer device + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + This is a special case of MDIO mux when MDIO mux is defined as a consumer + of a mux producer device. The mux producer can be of any type like mmio mux + producer, gpio mux producer or generic register based mux producer. + + +allOf: + - $ref: /schemas/net/mdio-mux.yaml# + +properties: + compatible: + const: mdio-mux-multiplexer + + mux-controls: + maxItems: 1 + +required: + - compatible + - mux-controls + +unevaluatedProperties: false + +examples: + - | + mux: mux-controller { // Mux Producer + compatible = "reg-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x54 0xf8>, /* 0: reg 0x54, bits 7:3 */ + <0x54 0x07>; /* 1: reg 0x54, bits 2:0 */ + }; + + mdio-mux-1 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 0>; + mdio-parent-bus = <&emdio1>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@8 { + reg = <0x8>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; + + mdio-mux-2 { // Mux consumer + compatible = "mdio-mux-multiplexer"; + mux-controls = <&mux 1>; + mdio-parent-bus = <&emdio2>; + #address-cells = <1>; + #size-cells = <0>; + + mdio@0 { + reg = <0x0>; + #address-cells = <1>; + #size-cells = <0>; + }; + + mdio@1 { + reg = <0x1>; + #address-cells = <1>; + #size-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/net/mdio-mux.txt b/Documentation/devicetree/bindings/net/mdio-mux.txt deleted file mode 100644 index f58571f36570..000000000000 --- a/Documentation/devicetree/bindings/net/mdio-mux.txt +++ /dev/null @@ -1,129 +0,0 @@ -Common MDIO bus multiplexer/switch properties. - -An MDIO bus multiplexer/switch will have several child busses that are -numbered uniquely in a device dependent manner. The nodes for an MDIO -bus multiplexer/switch will have one child node for each child bus. - -Required properties: -- #address-cells = <1>; -- #size-cells = <0>; - -Optional properties: -- mdio-parent-bus : phandle to the parent MDIO bus. - -- Other properties specific to the multiplexer/switch hardware. - -Required properties for child nodes: -- #address-cells = <1>; -- #size-cells = <0>; -- reg : The sub-bus number. - - -Example : - - /* The parent MDIO bus. */ - smi1: mdio@1180000001900 { - compatible = "cavium,octeon-3860-mdio"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0x11800 0x00001900 0x0 0x40>; - }; - - /* - An NXP sn74cbtlv3253 dual 1-of-4 switch controlled by a - pair of GPIO lines. Child busses 2 and 3 populated with 4 - PHYs each. - */ - mdio-mux { - compatible = "mdio-mux-gpio"; - gpios = <&gpio1 3 0>, <&gpio1 4 0>; - mdio-parent-bus = <&smi1>; - #address-cells = <1>; - #size-cells = <0>; - - mdio@2 { - reg = <2>; - #address-cells = <1>; - #size-cells = <0>; - - phy11: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy12: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy13: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - phy14: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <10 8>; /* Pin 10, active low */ - }; - }; - - mdio@3 { - reg = <3>; - #address-cells = <1>; - #size-cells = <0>; - - phy21: ethernet-phy@1 { - reg = <1>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy22: ethernet-phy@2 { - reg = <2>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy23: ethernet-phy@3 { - reg = <3>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - phy24: ethernet-phy@4 { - reg = <4>; - marvell,reg-init = <3 0x10 0 0x5777>, - <3 0x11 0 0x00aa>, - <3 0x12 0 0x4105>, - <3 0x13 0 0x0a60>; - interrupt-parent = <&gpio>; - interrupts = <12 8>; /* Pin 12, active low */ - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/mdio-mux.yaml b/Documentation/devicetree/bindings/net/mdio-mux.yaml new file mode 100644 index 000000000000..d169adf5d9f4 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mdio-mux.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mdio-mux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common MDIO bus multiplexer/switch properties. + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + +description: |+ + An MDIO bus multiplexer/switch will have several child busses that are + numbered uniquely in a device dependent manner. The nodes for an MDIO + bus multiplexer/switch will have one child node for each child bus. + +properties: + $nodename: + pattern: '^mdio-mux[\-@]?' + + mdio-parent-bus: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle of the MDIO bus that this multiplexer's master-side port is + connected to. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + '^mdio@[0-9a-f]+$': + type: object + + properties: + reg: + maxItems: 1 + description: The sub-bus number. + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml new file mode 100644 index 000000000000..347b912a46bb --- /dev/null +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -0,0 +1,226 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/microchip,sparx5-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Sparx5 Ethernet switch controller + +maintainers: + - Steen Hegelund <steen.hegelund@microchip.com> + - Lars Povlsen <lars.povlsen@microchip.com> + +description: | + The SparX-5 Enterprise Ethernet switch family provides a rich set of + Enterprise switching features such as advanced TCAM-based VLAN and + QoS processing enabling delivery of differentiated services, and + security through TCAM-based frame processing using versatile content + aware processor (VCAP). + + IPv4/IPv6 Layer 3 (L3) unicast and multicast routing is supported + with up to 18K IPv4/9K IPv6 unicast LPM entries and up to 9K IPv4/3K + IPv6 (S,G) multicast groups. + + L3 security features include source guard and reverse path + forwarding (uRPF) tasks. Additional L3 features include VRF-Lite and + IP tunnels (IP over GRE/IP). + + The SparX-5 switch family targets managed Layer 2 and Layer 3 + equipment in SMB, SME, and Enterprise where high port count + 1G/2.5G/5G/10G switching with 10G/25G aggregation links is required. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: microchip,sparx5-switch + + reg: + items: + - description: cpu target + - description: devices target + - description: general control block target + + reg-names: + items: + - const: cpu + - const: devices + - const: gcb + + interrupts: + minItems: 1 + items: + - description: register based extraction + - description: frame dma based extraction + + interrupt-names: + minItems: 1 + items: + - const: xtr + - const: fdma + + resets: + items: + - description: Reset controller used for switch core reset (soft reset) + + reset-names: + items: + - const: switch + + mac-address: true + + ethernet-ports: + type: object + patternProperties: + "^port@[0-9a-f]+$": + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + reg: + description: Switch port number + + phys: + maxItems: 1 + description: + phandle of a Ethernet SerDes PHY. This defines which SerDes + instance will handle the Ethernet traffic. + + phy-mode: + description: + This specifies the interface used by the Ethernet SerDes towards + the PHY or SFP. + + microchip,bandwidth: + description: Specifies bandwidth in Mbit/s allocated to the port. + $ref: "/schemas/types.yaml#/definitions/uint32" + maximum: 25000 + + phy-handle: + description: + phandle of a Ethernet PHY. This is optional and if provided it + points to the cuPHY used by the Ethernet SerDes. + + sfp: + description: + phandle of an SFP. This is optional and used when not specifying + a cuPHY. It points to the SFP node that describes the SFP used by + the Ethernet SerDes. + + managed: true + + microchip,sd-sgpio: + description: + Index of the ports Signal Detect SGPIO in the set of 384 SGPIOs + This is optional, and only needed if the default used index is + is not correct. + $ref: "/schemas/types.yaml#/definitions/uint32" + minimum: 0 + maximum: 383 + + required: + - reg + - phys + - phy-mode + - microchip,bandwidth + + oneOf: + - required: + - phy-handle + - required: + - sfp + - managed + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - resets + - reset-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + switch: switch@600000000 { + compatible = "microchip,sparx5-switch"; + reg = <0 0x401000>, + <0x10004000 0x7fc000>, + <0x11010000 0xaf0000>; + reg-names = "cpu", "devices", "gcb"; + interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "xtr"; + resets = <&reset 0>; + reset-names = "switch"; + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + microchip,bandwidth = <1000>; + phys = <&serdes 13>; + phy-handle = <&phy0>; + phy-mode = "qsgmii"; + }; + /* ... */ + /* Then the 25G interfaces */ + port60: port@60 { + reg = <60>; + microchip,bandwidth = <25000>; + phys = <&serdes 29>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth60>; + managed = "in-band-status"; + microchip,sd-sgpio = <365>; + }; + port61: port@61 { + reg = <61>; + microchip,bandwidth = <25000>; + phys = <&serdes 30>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth61>; + managed = "in-band-status"; + microchip,sd-sgpio = <369>; + }; + port62: port@62 { + reg = <62>; + microchip,bandwidth = <25000>; + phys = <&serdes 31>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth62>; + managed = "in-band-status"; + microchip,sd-sgpio = <373>; + }; + port63: port@63 { + reg = <63>; + microchip,bandwidth = <25000>; + phys = <&serdes 32>; + phy-mode = "10gbase-r"; + sfp = <&sfp_eth63>; + managed = "in-band-status"; + microchip,sd-sgpio = <377>; + }; + /* Finally the Management interface */ + port64: port@64 { + reg = <64>; + microchip,bandwidth = <1000>; + phys = <&serdes 0>; + phy-handle = <&phy64>; + phy-mode = "sgmii"; + mac-address = [ 00 00 00 01 02 03 ]; + }; + }; + }; + +... +# vim: set ts=2 sw=2 sts=2 tw=80 et cc=80 ft=yaml : diff --git a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml index 477066e2b821..081742c2b726 100644 --- a/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml +++ b/Documentation/devicetree/bindings/net/nfc/samsung,s3fwrn5.yaml @@ -27,6 +27,9 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + wake-gpios: maxItems: 1 description: @@ -80,6 +83,8 @@ examples: en-gpios = <&gpf1 4 GPIO_ACTIVE_HIGH>; wake-gpios = <&gpj0 2 GPIO_ACTIVE_HIGH>; + + clocks = <&rpmcc 20>; }; }; # UART example on Raspberry Pi diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index 5fe6d3dceb08..ed88ba4b94df 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -44,6 +44,7 @@ description: properties: compatible: enum: + - qcom,msm8998-ipa - qcom,sc7180-ipa - qcom,sc7280-ipa - qcom,sdm845-ipa diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt deleted file mode 100644 index 709ca6d51650..000000000000 --- a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.txt +++ /dev/null @@ -1,69 +0,0 @@ -Qualcomm Bluetooth Chips ---------------------- - -This documents the binding structure and common properties for serial -attached Qualcomm devices. - -Serial attached Qualcomm devices shall be a child node of the host UART -device the slave device is attached to. - -Required properties: - - compatible: should contain one of the following: - * "qcom,qca6174-bt" - * "qcom,qca9377-bt" - * "qcom,wcn3990-bt" - * "qcom,wcn3991-bt" - * "qcom,wcn3998-bt" - * "qcom,qca6390-bt" - -Optional properties for compatible string qcom,qca6174-bt: - - - enable-gpios: gpio specifier used to enable chip - - clocks: clock provided to the controller (SUSCLK_32KHZ) - - firmware-name: specify the name of nvm firmware to load - -Optional properties for compatible string qcom,qca9377-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - -Required properties for compatible string qcom,wcn399x-bt: - - - vddio-supply: VDD_IO supply regulator handle. - - vddxo-supply: VDD_XO supply regulator handle. - - vddrf-supply: VDD_RF supply regulator handle. - - vddch0-supply: VDD_CH0 supply regulator handle. - -Optional properties for compatible string qcom,wcn399x-bt: - - - max-speed: see Documentation/devicetree/bindings/serial/serial.yaml - - firmware-name: specify the name of nvm firmware to load - - clocks: clock provided to the controller - -Examples: - -serial@7570000 { - label = "BT-UART"; - status = "okay"; - - bluetooth { - compatible = "qcom,qca6174-bt"; - - enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; - clocks = <&divclk4>; - firmware-name = "nvm_00440302.bin"; - }; -}; - -serial@898000 { - bluetooth { - compatible = "qcom,wcn3990-bt"; - - vddio-supply = <&vreg_s4a_1p8>; - vddxo-supply = <&vreg_l7a_1p8>; - vddrf-supply = <&vreg_l17a_1p3>; - vddch0-supply = <&vreg_l25a_3p3>; - max-speed = <3200000>; - firmware-name = "crnv21.bin"; - clocks = <&rpmhcc RPMH_RF_CLK2>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml new file mode 100644 index 000000000000..f93c6e7a1b59 --- /dev/null +++ b/Documentation/devicetree/bindings/net/qualcomm-bluetooth.yaml @@ -0,0 +1,183 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/qualcomm-bluetooth.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Bluetooth Chips + +maintainers: + - Balakrishna Godavarthi <bgodavar@codeaurora.org> + - Rocky Liao <rjliao@codeaurora.org> + +description: + This binding describes Qualcomm UART-attached bluetooth chips. + +properties: + compatible: + enum: + - qcom,qca6174-bt + - qcom,qca9377-bt + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + - qcom,qca6390-bt + - qcom,wcn6750-bt + + enable-gpios: + maxItems: 1 + description: gpio specifier used to enable chip + + swctrl-gpios: + maxItems: 1 + description: gpio specifier is used to find status + of clock supply to SoC + + clocks: + maxItems: 1 + description: clock provided to the controller (SUSCLK_32KHZ) + + vddio-supply: + description: VDD_IO supply regulator handle + + vddxo-supply: + description: VDD_XO supply regulator handle + + vddrf-supply: + description: VDD_RF supply regulator handle + + vddch0-supply: + description: VDD_CH0 supply regulator handle + + vddaon-supply: + description: VDD_AON supply regulator handle + + vddbtcxmx-supply: + description: VDD_BT_CXMX supply regulator handle + + vddrfacmn-supply: + description: VDD_RFA_CMN supply regulator handle + + vddrfa0p8-supply: + description: VDD_RFA_0P8 suppply regulator handle + + vddrfa1p7-supply: + description: VDD_RFA_1P7 supply regulator handle + + vddrfa1p2-supply: + description: VDD_RFA_1P2 supply regulator handle + + vddrfa2p2-supply: + description: VDD_RFA_2P2 supply regulator handle + + vddasd-supply: + description: VDD_ASD supply regulator handle + + max-speed: + description: see Documentation/devicetree/bindings/serial/serial.yaml + + firmware-name: + description: specify the name of nvm firmware to load + + local-bd-address: + description: see Documentation/devicetree/bindings/net/bluetooth.txt + + +required: + - compatible + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,qca6174-bt + then: + required: + - enable-gpios + - clocks + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn3990-bt + - qcom,wcn3991-bt + - qcom,wcn3998-bt + then: + required: + - vddio-supply + - vddxo-supply + - vddrf-supply + - vddch0-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,wcn6750-bt + then: + required: + - enable-gpios + - swctrl-gpios + - vddio-supply + - vddaon-supply + - vddbtcxmx-supply + - vddrfacmn-supply + - vddrfa0p8-supply + - vddrfa1p7-supply + - vddrfa1p2-supply + - vddasd-supply + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + serial { + + bluetooth { + compatible = "qcom,qca6174-bt"; + enable-gpios = <&pm8994_gpios 19 GPIO_ACTIVE_HIGH>; + clocks = <&divclk4>; + firmware-name = "nvm_00440302.bin"; + }; + }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn3990-bt"; + vddio-supply = <&vreg_s4a_1p8>; + vddxo-supply = <&vreg_l7a_1p8>; + vddrf-supply = <&vreg_l17a_1p3>; + vddch0-supply = <&vreg_l25a_3p3>; + max-speed = <3200000>; + firmware-name = "crnv21.bin"; + }; + }; + - | + serial { + + bluetooth { + compatible = "qcom,wcn6750-bt"; + pinctrl-names = "default"; + pinctrl-0 = <&bt_en_default>; + enable-gpios = <&tlmm 85 GPIO_ACTIVE_HIGH>; + swctrl-gpios = <&tlmm 86 GPIO_ACTIVE_HIGH>; + vddio-supply = <&vreg_l19b_1p8>; + vddaon-supply = <&vreg_s7b_0p9>; + vddbtcxmx-supply = <&vreg_s7b_0p9>; + vddrfacmn-supply = <&vreg_s7b_0p9>; + vddrfa0p8-supply = <&vreg_s7b_0p9>; + vddrfa1p7-supply = <&vreg_s1b_1p8>; + vddrfa1p2-supply = <&vreg_s8b_1p2>; + vddrfa2p2-supply = <&vreg_s1c_2p2>; + vddasd-supply = <&vreg_l11c_2p8>; + max-speed = <3200000>; + firmware-name = "msnv11.bin"; + }; + }; diff --git a/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml new file mode 100644 index 000000000000..bb94a2388520 --- /dev/null +++ b/Documentation/devicetree/bindings/net/realtek,rtl82xx.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0+ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/realtek,rtl82xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek RTL82xx PHY + +maintainers: + - Andrew Lunn <andrew@lunn.ch> + - Florian Fainelli <f.fainelli@gmail.com> + - Heiner Kallweit <hkallweit1@gmail.com> + +description: + Bindings for Realtek RTL82xx PHYs + +allOf: + - $ref: ethernet-phy.yaml# + +properties: + realtek,clkout-disable: + type: boolean + description: + Disable CLKOUT clock, CLKOUT clock default is enabled after hardware reset. + + + realtek,aldps-enable: + type: boolean + description: + Enable ALDPS mode, ALDPS mode default is disabled after hardware reset. + +unevaluatedProperties: false + +examples: + - | + mdio { + #address-cells = <1>; + #size-cells = <0>; + + ethphy1: ethernet-phy@1 { + reg = <1>; + realtek,clkout-disable; + realtek,aldps-enable; + }; + }; diff --git a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml index 5acddb6171bf..083623c8d718 100644 --- a/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/rockchip-dwmac.yaml @@ -19,10 +19,12 @@ select: - rockchip,rk3128-gmac - rockchip,rk3228-gmac - rockchip,rk3288-gmac + - rockchip,rk3308-gmac - rockchip,rk3328-gmac - rockchip,rk3366-gmac - rockchip,rk3368-gmac - rockchip,rk3399-gmac + - rockchip,rk3568-gmac - rockchip,rv1108-gmac required: - compatible @@ -32,17 +34,23 @@ allOf: properties: compatible: - items: - - enum: - - rockchip,px30-gmac - - rockchip,rk3128-gmac - - rockchip,rk3228-gmac - - rockchip,rk3288-gmac - - rockchip,rk3328-gmac - - rockchip,rk3366-gmac - - rockchip,rk3368-gmac - - rockchip,rk3399-gmac - - rockchip,rv1108-gmac + oneOf: + - items: + - enum: + - rockchip,px30-gmac + - rockchip,rk3128-gmac + - rockchip,rk3228-gmac + - rockchip,rk3288-gmac + - rockchip,rk3308-gmac + - rockchip,rk3328-gmac + - rockchip,rk3366-gmac + - rockchip,rk3368-gmac + - rockchip,rk3399-gmac + - rockchip,rv1108-gmac + - items: + - enum: + - rockchip,rk3568-gmac + - const: snps,dwmac-4.20a clocks: minItems: 5 diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 2edd8bea993e..d7652596a09b 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -51,11 +51,20 @@ properties: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac - amlogic,meson6-dwmac - amlogic,meson8b-dwmac - amlogic,meson8m2-dwmac - amlogic,meson-gxbb-dwmac - amlogic,meson-axg-dwmac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - rockchip,px30-gmac - rockchip,rk3128-gmac - rockchip,rk3228-gmac @@ -82,7 +91,6 @@ properties: interrupts: minItems: 1 - maxItems: 3 items: - description: Combined signal for various interrupt events - description: The interrupt to manage the remote wake-up packet detection @@ -90,7 +98,6 @@ properties: interrupt-names: minItems: 1 - maxItems: 3 items: - const: macirq - const: eth_wake_irq @@ -310,6 +317,11 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwxgmac - snps,dwxgmac-2.10 - st,spear600-gmac @@ -353,6 +365,13 @@ allOf: - allwinner,sun8i-r40-emac - allwinner,sun8i-v3s-emac - allwinner,sun50i-a64-emac + - loongson,ls2k-dwmac + - loongson,ls7a-dwmac + - ingenic,jz4775-mac + - ingenic,x1000-mac + - ingenic,x1600-mac + - ingenic,x1830-mac + - ingenic,x2000-mac - snps,dwmac-4.00 - snps,dwmac-4.10a - snps,dwmac-4.20a diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 27eb6066793f..19c7bd482a51 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -46,7 +46,6 @@ properties: clocks: minItems: 3 - maxItems: 5 items: - description: GMAC main clock - description: MAC TX clock diff --git a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml index f90557f6deb8..b9589a0daa5c 100644 --- a/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/brcm,stb-pcie.yaml @@ -25,14 +25,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/pci/loongson.yaml b/Documentation/devicetree/bindings/pci/loongson.yaml index 81bae060cbde..82bc6c486ca3 100644 --- a/Documentation/devicetree/bindings/pci/loongson.yaml +++ b/Documentation/devicetree/bindings/pci/loongson.yaml @@ -24,7 +24,6 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: CFG0 standard config space register - description: CFG1 extended config space register diff --git a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml index e7b1f9892da4..742206dbd965 100644 --- a/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml +++ b/Documentation/devicetree/bindings/pci/mediatek-pcie-gen3.yaml @@ -70,7 +70,6 @@ properties: reset-names: minItems: 1 - maxItems: 2 items: - const: phy - const: mac diff --git a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml index 04251d71f56b..fb95c276a986 100644 --- a/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml +++ b/Documentation/devicetree/bindings/pci/microchip,pcie-host.yaml @@ -26,14 +26,12 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: PCIe host controller - description: builtin MSI controller interrupt-names: minItems: 1 - maxItems: 2 items: - const: pcie - const: msi diff --git a/Documentation/devicetree/bindings/pci/pci-keystone.txt b/Documentation/devicetree/bindings/pci/pci-keystone.txt deleted file mode 100644 index 47202a2938f2..000000000000 --- a/Documentation/devicetree/bindings/pci/pci-keystone.txt +++ /dev/null @@ -1,115 +0,0 @@ -TI Keystone PCIe interface - -Keystone PCI host Controller is based on the Synopsys DesignWare PCI -hardware version 3.65. It shares common functions with the PCIe DesignWare -core driver and inherits common properties defined in -Documentation/devicetree/bindings/pci/designware-pcie.txt - -Please refer to Documentation/devicetree/bindings/pci/designware-pcie.txt -for the details of DesignWare DT bindings. Additional properties are -described here as well as properties that are not applicable. - -Required Properties:- - -compatibility: Should be "ti,keystone-pcie" for RC on Keystone2 SoC - Should be "ti,am654-pcie-rc" for RC on AM654x SoC -reg: Three register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "config" for the - configuration space address - -pcie_msi_intc : Interrupt controller device node for MSI IRQ chip - interrupt-cells: should be set to 1 - interrupts: GIC interrupt lines connected to PCI MSI interrupt lines - (required if the compatible is "ti,keystone-pcie") -msi-map: As specified in Documentation/devicetree/bindings/pci/pci-msi.txt - (required if the compatible is "ti,am654-pcie-rc". - -ti,syscon-pcie-id : phandle to the device control module required to set device - id and vendor id. -ti,syscon-pcie-mode : phandle to the device control module required to configure - PCI in either RC mode or EP mode. - - Example: - pcie_msi_intc: msi-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 32 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 33 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 34 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 35 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 36 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 37 IRQ_TYPE_EDGE_RISING>; - }; - -pcie_intc: Interrupt controller device node for Legacy IRQ chip - interrupt-cells: should be set to 1 - - Example: - pcie_intc: legacy-interrupt-controller { - interrupt-controller; - #interrupt-cells = <1>; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 26 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 27 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 28 IRQ_TYPE_EDGE_RISING>, - <GIC_SPI 29 IRQ_TYPE_EDGE_RISING>; - }; - -Optional properties:- - phys: phandle to generic Keystone SerDes PHY for PCI - phy-names: name of the generic Keystone SerDes PHY for PCI - - If boot loader already does PCI link establishment, then phys and - phy-names shouldn't be present. - interrupts: platform interrupt for error interrupts. - -DesignWare DT Properties not applicable for Keystone PCI - -1. pcie_bus clock-names not used. Instead, a phandle to phys is used. - -AM654 PCIe Endpoint -=================== - -Required Properties:- - -compatibility: Should be "ti,am654-pcie-ep" for EP on AM654x SoC -reg: Four register ranges as listed in the reg-names property -reg-names: "dbics" for the DesignWare PCIe registers, "app" for the - TI specific application registers, "atu" for the - Address Translation Unit configuration registers and - "addr_space" used to map remote RC address space -num-ib-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-ob-windows: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -num-lanes: As specified in - Documentation/devicetree/bindings/pci/designware-pcie.txt -power-domains: As documented by the generic PM domain bindings in - Documentation/devicetree/bindings/power/power_domain.txt. -ti,syscon-pcie-mode: phandle to the device control module required to configure - PCI in either RC mode or EP mode. - -Optional properties:- - -phys: list of PHY specifiers (used by generic PHY framework) -phy-names: must be "pcie-phy0", "pcie-phy1", "pcie-phyN".. based on the - number of lanes as specified in *num-lanes* property. -("phys" and "phy-names" DT bindings are specified in -Documentation/devicetree/bindings/phy/phy-bindings.txt) -interrupts: platform interrupt for error interrupts. - -pcie-ep { - compatible = "ti,am654-pcie-ep"; - reg = <0x5500000 0x1000>, <0x5501000 0x1000>, - <0x10000000 0x8000000>, <0x5506000 0x1000>; - reg-names = "app", "dbics", "addr_space", "atu"; - power-domains = <&k3_pds 120>; - ti,syscon-pcie-mode = <&pcie0_mode>; - num-lanes = <1>; - num-ib-windows = <16>; - num-ob-windows = <16>; - interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; -}; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index 0da458a051b6..25f4def468bf 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -14,6 +14,7 @@ - "qcom,pcie-qcs404" for qcs404 - "qcom,pcie-sdm845" for sdm845 - "qcom,pcie-sm8250" for sm8250 + - "qcom,pcie-ipq6018" for ipq6018 - reg: Usage: required @@ -124,6 +125,16 @@ - "aux" Auxiliary clock - clock-names: + Usage: required for ipq6018 + Value type: <stringlist> + Definition: Should contain the following entries + - "iface" PCIe to SysNOC BIU clock + - "axi_m" AXI Master clock + - "axi_s" AXI Slave clock + - "axi_bridge" AXI bridge clock + - "rchng" + +- clock-names: Usage: required for qcs404 Value type: <stringlist> Definition: Should contain the following entries @@ -210,6 +221,19 @@ - "axi_m_sticky" AXI Master Sticky reset - reset-names: + Usage: required for ipq6018 + Value type: <stringlist> + Definition: Should contain the following entries + - "pipe" PIPE reset + - "sleep" Sleep reset + - "sticky" Core Sticky reset + - "axi_m" AXI Master reset + - "axi_s" AXI Slave reset + - "ahb" AHB Reset + - "axi_m_sticky" AXI Master Sticky reset + - "axi_s_sticky" AXI Slave Sticky reset + +- reset-names: Usage: required for qcs404 Value type: <stringlist> Definition: Should contain the following entries diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml new file mode 100644 index 000000000000..78c217d362a7 --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-ep.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-ep.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Endpoint + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: pci-ep.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-ep + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: addr_space + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + interrupts: + minItems: 1 + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - power-domains + - ti,syscon-pcie-mode + - dma-coherent + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + pcie0_ep: pcie-ep@5500000 { + compatible = "ti,am654-pcie-ep"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x8000000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "addr_space", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + ti,syscon-pcie-mode = <&pcie0_mode>; + num-ib-windows = <16>; + num-ob-windows = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; + }; diff --git a/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml new file mode 100644 index 000000000000..834dc1c1743c --- /dev/null +++ b/Documentation/devicetree/bindings/pci/ti,am65-pci-host.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2021 Texas Instruments Incorporated - http://www.ti.com/ +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pci/ti,am65-pci-host.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI AM65 PCI Host + +maintainers: + - Kishon Vijay Abraham I <kishon@ti.com> + +allOf: + - $ref: /schemas/pci/pci-bus.yaml# + +properties: + compatible: + enum: + - ti,am654-pcie-rc + - ti,keystone-pcie + + reg: + maxItems: 4 + + reg-names: + items: + - const: app + - const: dbics + - const: config + - const: atu + + power-domains: + maxItems: 1 + + ti,syscon-pcie-id: + description: Phandle to the SYSCON entry required for getting PCIe device/vendor ID + $ref: /schemas/types.yaml#/definitions/phandle + + ti,syscon-pcie-mode: + description: Phandle to the SYSCON entry required for configuring PCIe in RC or EP mode. + $ref: /schemas/types.yaml#/definitions/phandle + + msi-map: true + + dma-coherent: true + +required: + - compatible + - reg + - reg-names + - max-link-speed + - ti,syscon-pcie-id + - ti,syscon-pcie-mode + - ranges + +if: + properties: + compatible: + enum: + - ti,am654-pcie-rc +then: + required: + - dma-coherent + - power-domains + - msi-map + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + pcie0_rc: pcie@5500000 { + compatible = "ti,am654-pcie-rc"; + reg = <0x5500000 0x1000>, + <0x5501000 0x1000>, + <0x10000000 0x2000>, + <0x5506000 0x1000>; + reg-names = "app", "dbics", "config", "atu"; + power-domains = <&k3_pds 120 TI_SCI_PD_EXCLUSIVE>; + #address-cells = <3>; + #size-cells = <2>; + ranges = <0x81000000 0 0 0x10020000 0 0x00010000>, + <0x82000000 0 0x10030000 0x10030000 0 0x07FD0000>; + ti,syscon-pcie-id = <&pcie_devid>; + ti,syscon-pcie-mode = <&pcie0_mode>; + bus-range = <0x0 0xff>; + num-viewport = <16>; + max-link-speed = <2>; + dma-coherent; + interrupts = <GIC_SPI 340 IRQ_TYPE_EDGE_RISING>; + msi-map = <0x0 &gic_its 0x0 0x10000>; + device_type = "pci"; + }; diff --git a/Documentation/devicetree/bindings/perf/arm,cmn.yaml b/Documentation/devicetree/bindings/perf/arm,cmn.yaml index e4fcc0de25e2..42424ccbdd0c 100644 --- a/Documentation/devicetree/bindings/perf/arm,cmn.yaml +++ b/Documentation/devicetree/bindings/perf/arm,cmn.yaml @@ -21,7 +21,6 @@ properties: interrupts: minItems: 1 - maxItems: 4 items: - description: Overflow interrupt for DTC0 - description: Overflow interrupt for DTC1 diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml index f80431060803..e288450e0844 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun8i-h3-usb-phy.yaml @@ -15,7 +15,9 @@ properties: const: 1 compatible: - const: allwinner,sun8i-h3-usb-phy + enum: + - allwinner,sun8i-h3-usb-phy + - allwinner,sun50i-h616-usb-phy reg: items: diff --git a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml index 9a2e779e6d38..0f0bcde9eb88 100644 --- a/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,bcm63xx-usbh-phy.yaml @@ -28,7 +28,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: usbh - const: usb_ref diff --git a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml index 5f9e91bfb5ff..43a4b880534c 100644 --- a/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,brcmstb-usb-phy.yaml @@ -22,7 +22,6 @@ properties: reg: minItems: 1 - maxItems: 6 items: - description: the base CTRL register - description: XHCI EC register @@ -33,7 +32,6 @@ properties: reg-names: minItems: 1 - maxItems: 6 items: - const: ctrl - const: xhci_ec @@ -51,7 +49,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: sw_usb - const: sw_usb3 diff --git a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml index 04edda504ab6..cb1aa325336f 100644 --- a/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml +++ b/Documentation/devicetree/bindings/phy/brcm,sata-phy.yaml @@ -35,7 +35,6 @@ properties: reg-names: minItems: 1 - maxItems: 2 items: - const: phy - const: phy-ctrl diff --git a/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml new file mode 100644 index 000000000000..ebd78acfe2de --- /dev/null +++ b/Documentation/devicetree/bindings/phy/hisilicon,hi3670-usb3.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/hisilicon,hi3670-usb3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Hisilicon Kirin970 USB PHY + +maintainers: + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org> + +description: |+ + Bindings for USB3 PHY on HiSilicon Kirin 970. + +properties: + compatible: + const: hisilicon,hi3670-usb-phy + + "#phy-cells": + const: 0 + + hisilicon,pericrg-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control iso refclk. + + hisilicon,pctrl-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control usb tcxo. + + hisilicon,sctrl-syscon: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: phandle of syscon used to control phy deep sleep. + + hisilicon,eye-diagram-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: Eye diagram for phy. + + hisilicon,tx-vboost-lvl: + $ref: /schemas/types.yaml#/definitions/uint32 + description: TX level vboost for phy. + +required: + - compatible + - hisilicon,pericrg-syscon + - hisilicon,pctrl-syscon + - hisilicon,sctrl-syscon + - hisilicon,eye-diagram-param + - hisilicon,tx-vboost-lvl + - "#phy-cells" + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + usb3_otg_bc: usb3_otg_bc@ff200000 { + compatible = "syscon", "simple-mfd"; + reg = <0x0 0xff200000 0x0 0x1000>; + + usb_phy { + compatible = "hisilicon,hi3670-usb-phy"; + #phy-cells = <0>; + hisilicon,pericrg-syscon = <&crg_ctrl>; + hisilicon,pctrl-syscon = <&pctrl>; + hisilicon,sctrl-syscon = <&sctrl>; + hisilicon,eye-diagram-param = <0xfdfee4>; + hisilicon,tx-vboost-lvl = <0x5>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml index 0ccaded3f245..29d4123323c2 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,mt7621-pci-phy.yaml @@ -16,6 +16,9 @@ properties: reg: maxItems: 1 + clocks: + maxItems: 1 + "#phy-cells": const: 1 description: selects if the phy is dual-ported @@ -23,6 +26,7 @@ properties: required: - compatible - reg + - clocks - "#phy-cells" additionalProperties: false @@ -32,5 +36,6 @@ examples: pcie0_phy: pcie-phy@1e149000 { compatible = "mediatek,mt7621-pci-phy"; reg = <0x1e149000 0x0700>; + clocks = <&sysc 0>; #phy-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index b8a7651a3d9a..ef9d9d4e6875 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -131,7 +131,6 @@ patternProperties: clocks: minItems: 1 - maxItems: 2 items: - description: Reference clock, (HS is 48Mhz, SS/P is 24~27Mhz) - description: Reference clock of analog phy @@ -141,7 +140,6 @@ patternProperties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: da_ref diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml index 84383e2e0b34..e71b32c9c0d1 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-sierra.yaml @@ -31,14 +31,12 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: Sierra PHY reset. - description: Sierra APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: sierra_reset - const: sierra_apb diff --git a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml index 320a232c7208..bd9ae11c9994 100644 --- a/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml +++ b/Documentation/devicetree/bindings/phy/phy-cadence-torrent.yaml @@ -52,28 +52,24 @@ properties: reg: minItems: 1 - maxItems: 2 items: - description: Offset of the Torrent PHY configuration registers. - description: Offset of the DPTX PHY configuration registers. reg-names: minItems: 1 - maxItems: 2 items: - const: torrent_phy - const: dptx_phy resets: minItems: 1 - maxItems: 2 items: - description: Torrent PHY reset. - description: Torrent APB reset. This is optional. reset-names: minItems: 1 - maxItems: 2 items: - const: torrent_reset - const: torrent_apb diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml index fb29ad807b68..a5b027a6e70f 100644 --- a/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-inno-usb2.yaml @@ -14,6 +14,7 @@ properties: enum: - rockchip,px30-usb2phy - rockchip,rk3228-usb2phy + - rockchip,rk3308-usb2phy - rockchip,rk3328-usb2phy - rockchip,rk3366-usb2phy - rockchip,rk3399-usb2phy diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 018cc1246ee1..3329f1d33a4f 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -74,6 +74,13 @@ patternProperties: "#phy-cells": enum: [ 0x0, 0x1 ] + connector: + type: object + allOf: + - $ref: ../connector/usb-connector.yaml + properties: + vbus-supply: true + allOf: - if: properties: @@ -130,6 +137,10 @@ examples: reg = <0>; phy-supply = <&vdd_usb>; #phy-cells = <0>; + connector { + compatible = "usb-a-connector"; + vbus-supply = <&vbus_sw>; + }; }; usbphyc_port1: usb-phy@1 { diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml index 17f132ce5516..35296c588e78 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-hs.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml index 17fd7f6b83bb..6cf5c6c06072 100644 --- a/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,ipq806x-usb-phy-ss.yaml @@ -30,7 +30,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: ref - const: xo diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index 7808ec8bc712..f0497b8623ad 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -17,6 +17,7 @@ description: properties: compatible: enum: + - qcom,ipq6018-qmp-pcie-phy - qcom,ipq8074-qmp-pcie-phy - qcom,ipq8074-qmp-usb3-phy - qcom,msm8996-qmp-pcie-phy @@ -45,11 +46,11 @@ properties: - qcom,sm8350-qmp-ufs-phy - qcom,sm8350-qmp-usb3-phy - qcom,sm8350-qmp-usb3-uni-phy + - qcom,sdx55-qmp-pcie-phy - qcom,sdx55-qmp-usb3-uni-phy reg: minItems: 1 - maxItems: 2 items: - description: Address and length of PHY's common serdes block. - description: Address and length of PHY's DP_COM control block. @@ -301,8 +302,33 @@ allOf: compatible: contains: enum: + - qcom,ipq6018-qmp-pcie-phy + then: + properties: + clocks: + items: + - description: Phy aux clock. + - description: Phy config clock. + clock-names: + items: + - const: aux + - const: cfg_ahb + resets: + items: + - description: reset of phy block. + - description: phy common block reset. + reset-names: + items: + - const: phy + - const: common + - if: + properties: + compatible: + contains: + enum: - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy + - qcom,sdx55-qmp-pcie-phy - qcom,sm8250-qmp-gen3x1-pcie-phy - qcom,sm8250-qmp-gen3x2-pcie-phy - qcom,sm8250-qmp-modem-pcie-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index 9f9cf07b7d45..ec9ccaaba098 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -23,6 +23,8 @@ properties: - qcom,msm8998-qusb2-phy - qcom,sdm660-qusb2-phy - qcom,ipq6018-qusb2-phy + - qcom,sm4250-qusb2-phy + - qcom,sm6115-qusb2-phy - items: - enum: - qcom,sc7180-qusb2-phy @@ -36,7 +38,6 @@ properties: clocks: minItems: 2 - maxItems: 3 items: - description: phy config clock - description: 19.2 MHz ref clk @@ -44,7 +45,6 @@ properties: clock-names: minItems: 2 - maxItems: 3 items: - const: cfg_ahb - const: ref diff --git a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt b/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt deleted file mode 100644 index 63853b35e083..000000000000 --- a/Documentation/devicetree/bindings/phy/rcar-gen3-phy-pcie.txt +++ /dev/null @@ -1,24 +0,0 @@ -* Renesas R-Car generation 3 PCIe PHY - -This file provides information on what the device node for the R-Car -generation 3 PCIe PHY contains. - -Required properties: -- compatible: "renesas,r8a77980-pcie-phy" if the device is a part of the - R8A77980 SoC. -- reg: offset and length of the register block. -- clocks: clock phandle and specifier pair. -- power-domains: power domain phandle and specifier pair. -- resets: reset phandle and specifier pair. -- #phy-cells: see phy-bindings.txt in the same directory, must be <0>. - -Example (R-Car V3H): - - pcie-phy@e65d0000 { - compatible = "renesas,r8a77980-pcie-phy"; - reg = <0 0xe65d0000 0 0x8000>; - #phy-cells = <0>; - clocks = <&cpg CPG_MOD 319>; - power-domains = <&sysc 32>; - resets = <&cpg 319>; - }; diff --git a/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml new file mode 100644 index 000000000000..247ef7c47cf5 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/renesas,rcar-gen3-pcie-phy.yaml @@ -0,0 +1,53 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/renesas,rcar-gen3-pcie-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Car Generation 3 PCIe PHY + +maintainers: + - Sergei Shtylyov <sergei.shtylyov@gmail.com> + +properties: + compatible: + const: renesas,r8a77980-pcie-phy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + '#phy-cells': + const: 0 + +required: + - compatible + - reg + - clocks + - power-domains + - resets + - '#phy-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/r8a77980-cpg-mssr.h> + #include <dt-bindings/power/r8a77980-sysc.h> + + pcie-phy@e65d0000 { + compatible = "renesas,r8a77980-pcie-phy"; + reg = <0xe65d0000 0x8000>; + #phy-cells = <0>; + clocks = <&cpg CPG_MOD 319>; + power-domains = <&sysc R8A77980_PD_ALWAYS_ON>; + resets = <&cpg 319>; + }; diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 0f358d5b84ef..d5dc5a3cdceb 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -39,7 +39,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: fck - const: usb_x1 @@ -61,7 +60,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: reset of USB 2.0 host side - description: reset of USB 2.0 peripheral side diff --git a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml index f3ef738a3ff6..b8483f9edbfc 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb3-phy.yaml @@ -33,7 +33,6 @@ properties: # If you want to use the ssc, the clock-frequency of usb_extal # must not be 0. minItems: 2 - maxItems: 3 items: - const: usb3-if # The funcional clock - const: usb3s_clk # The usb3's external clock diff --git a/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml new file mode 100644 index 000000000000..bb4a2e4b8ab0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rockchip-inno-csi-dphy.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/rockchip-inno-csi-dphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC MIPI RX0 D-PHY Device Tree Bindings + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +description: | + The Rockchip SoC has a MIPI CSI D-PHY based on an Innosilicon IP wich + connects to the ISP1 (Image Signal Processing unit v1.0) for CSI cameras. + +properties: + compatible: + enum: + - rockchip,px30-csi-dphy + - rockchip,rk1808-csi-dphy + - rockchip,rk3326-csi-dphy + - rockchip,rk3368-csi-dphy + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: pclk + + '#phy-cells': + const: 0 + + power-domains: + description: Video in/out power domain. + maxItems: 1 + + resets: + items: + - description: exclusive PHY reset line + + reset-names: + items: + - const: apb + + rockchip,grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional phy settings are access through GRF regs. + +required: + - compatible + - reg + - clocks + - clock-names + - '#phy-cells' + - power-domains + - resets + - reset-names + - rockchip,grf + +additionalProperties: false + +examples: + - | + + csi_dphy: phy@ff2f0000 { + compatible = "rockchip,px30-csi-dphy"; + reg = <0xff2f0000 0x4000>; + clocks = <&cru 1>; + clock-names = "pclk"; + #phy-cells = <0>; + power-domains = <&power 1>; + resets = <&cru 1>; + reset-names = "apb"; + rockchip,grf = <&grf>; + }; diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt deleted file mode 100644 index 4ed569046daf..000000000000 --- a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.txt +++ /dev/null @@ -1,52 +0,0 @@ -ROCKCHIP USB2 PHY - -Required properties: - - compatible: matching the soc type, one of - "rockchip,rk3066a-usb-phy" - "rockchip,rk3188-usb-phy" - "rockchip,rk3288-usb-phy" - - #address-cells: should be 1 - - #size-cells: should be 0 - -Deprecated properties: - - rockchip,grf : phandle to the syscon managing the "general - register files" - phy should be a child of the GRF instead - -Sub-nodes: -Each PHY should be represented as a sub-node. - -Sub-nodes -required properties: -- #phy-cells: should be 0 -- reg: PHY configure reg address offset in GRF - "0x320" - for PHY attach to OTG controller - "0x334" - for PHY attach to HOST0 controller - "0x348" - for PHY attach to HOST1 controller - -Optional Properties: -- clocks : phandle + clock specifier for the phy clocks -- clock-names: string, clock name, must be "phyclk" -- #clock-cells: for users of the phy-pll, should be 0 -- reset-names: Only allow the following entries: - - phy-reset -- resets: Must contain an entry for each entry in reset-names. -- vbus-supply: power-supply phandle for vbus power source - -Example: - -grf: syscon@ff770000 { - compatible = "rockchip,rk3288-grf", "syscon", "simple-mfd"; - -... - - usbphy: phy { - compatible = "rockchip,rk3288-usb-phy"; - #address-cells = <1>; - #size-cells = <0>; - - usbphy0: usb-phy0 { - #phy-cells = <0>; - reg = <0x320>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml new file mode 100644 index 000000000000..f0fc8275dcd0 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/rockchip-usb-phy.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/rockchip-usb-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip USB2.0 phy + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + oneOf: + - const: rockchip,rk3288-usb-phy + - items: + - enum: + - rockchip,rk3066a-usb-phy + - rockchip,rk3188-usb-phy + - const: rockchip,rk3288-usb-phy + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +patternProperties: + "usb-phy@[0-9a-f]+$": + type: object + + properties: + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-names: + const: phyclk + + "#clock-cells": + const: 0 + + resets: + maxItems: 1 + + reset-names: + const: phy-reset + + vbus-supply: + description: phandle for vbus power source + + required: + - reg + - "#phy-cells" + + additionalProperties: false + +examples: + - | + usbphy: usbphy { + compatible = "rockchip,rk3288-usb-phy"; + #address-cells = <1>; + #size-cells = <0>; + + usbphy0: usb-phy@320 { + reg = <0x320>; + #phy-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml new file mode 100644 index 000000000000..6107880e5246 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/phy/ti,tcan104x-can.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: TCAN104x CAN TRANSCEIVER PHY + +maintainers: + - Aswath Govindraju <a-govindraju@ti.com> + +properties: + $nodename: + pattern: "^can-phy" + + compatible: + enum: + - ti,tcan1042 + - ti,tcan1043 + + '#phy-cells': + const: 0 + + standby-gpios: + description: + gpio node to toggle standby signal on transceiver + maxItems: 1 + + enable-gpios: + description: + gpio node to toggle enable signal on transceiver + maxItems: 1 + + max-bitrate: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + max bit rate supported in bps + minimum: 1 + +required: + - compatible + - '#phy-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + transceiver1: can-phy { + compatible = "ti,tcan1043"; + #phy-cells = <0>; + max-bitrate = <5000000>; + standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>; + enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml index ccdd9e3820d7..3f94f6944740 100644 --- a/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/actions,s500-pinctrl.yaml @@ -26,7 +26,6 @@ properties: - description: PAD Pull Control + PAD Schmitt Trigger Enable + PAD Control - description: PAD Drive Capacity Select minItems: 1 - maxItems: 4 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml new file mode 100644 index 000000000000..d50571affd1f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/apple,pinctrl.yaml @@ -0,0 +1,106 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/apple,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple GPIO controller + +maintainers: + - Mark Kettenis <kettenis@openbsd.org> + +description: | + The Apple GPIO controller is a simple combined pin and GPIO + controller present on Apple ARM SoC platforms, including various + iPhone and iPad devices and the "Apple Silicon" Macs. + +properties: + compatible: + items: + - const: apple,t8103-pinctrl + - const: apple,pinctrl + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + gpio-controller: true + + '#gpio-cells': + const: 2 + + gpio-ranges: + maxItems: 1 + + interrupts: + description: One interrupt for each of the (up to 7) interrupt + groups supported by the controller sorted by interrupt group + number in ascending order. + minItems: 1 + maxItems: 7 + + interrupt-controller: true + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + pinmux: + description: + Values are constructed from pin number and alternate function + configuration number using the APPLE_PINMUX() helper macro + defined in include/dt-bindings/pinctrl/apple.h. + + required: + - pinmux + + additionalProperties: false + +required: + - compatible + - reg + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/apple-aic.h> + #include <dt-bindings/pinctrl/apple.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + pinctrl: pinctrl@23c100000 { + compatible = "apple,t8103-pinctrl", "apple,pinctrl"; + reg = <0x2 0x3c100000 0x0 0x100000>; + clocks = <&gpio_clk>; + + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pinctrl 0 0 212>; + + interrupt-controller; + interrupt-parent = <&aic>; + interrupts = <AIC_IRQ 16 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 17 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 18 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 19 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 20 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 21 IRQ_TYPE_LEVEL_HIGH>, + <AIC_IRQ 22 IRQ_TYPE_LEVEL_HIGH>; + + pcie_pins: pcie-pins { + pinmux = <APPLE_PINMUX(150, 1)>, + <APPLE_PINMUX(151, 1)>, + <APPLE_PINMUX(32, 1)>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml index ad91c0bc54da..ad2866c99738 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2600-pinctrl.yaml @@ -46,8 +46,8 @@ patternProperties: PWM9, RGMII1, RGMII2, RGMII3, RGMII4, RMII1, RMII2, RMII3, RMII4, RXD1, RXD2, RXD3, RXD4, SALT1, SALT10, SALT11, SALT12, SALT13, SALT14, SALT15, SALT16, SALT2, SALT3, SALT4, SALT5, SALT6, SALT7, SALT8, - SALT9, SD1, SD2, SGPM1, SGPS1, SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, - SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, + SALT9, SD1, SD2, SGPM1, SGPM2, SGPS1, SGPS2, SIOONCTRL, SIOPBI, SIOPBO, + SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12, @@ -74,9 +74,9 @@ patternProperties: RXD1, RXD2, RXD3, RXD4, SALT1, SALT10G0, SALT10G1, SALT11G0, SALT11G1, SALT12G0, SALT12G1, SALT13G0, SALT13G1, SALT14G0, SALT14G1, SALT15G0, SALT15G1, SALT16G0, SALT16G1, SALT2, SALT3, SALT4, SALT5, SALT6, - SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPS1, SIOONCTRL, - SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, SPI1ABR, - SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, + SALT7, SALT8, SALT9G0, SALT9G1, SD1, SD2, SD3, SGPM1, SGPM2, SGPS1, SGPS2, + SIOONCTRL, SIOPBI, SIOPBO, SIOPWREQ, SIOPWRGD, SIOS3, SIOS5, SIOSCI, SPI1, + SPI1ABR, SPI1CS1, SPI1WP, SPI2, SPI2CS1, SPI2CS2, TACH0, TACH1, TACH10, TACH11, TACH12, TACH13, TACH14, TACH15, TACH2, TACH3, TACH4, TACH5, TACH6, TACH7, TACH8, TACH9, THRU0, THRU1, THRU2, THRU3, TXD1, TXD2, TXD3, TXD4, UART10, UART11, UART12G0, UART12G1, UART13G0, UART13G1, UART6, diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt deleted file mode 100644 index 8ab2d468dbdb..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4708-pinmux.txt +++ /dev/null @@ -1,55 +0,0 @@ -Broadcom Northstar pins mux controller - -Some of Northstar SoCs's pins can be used for various purposes thanks to the mux -controller. This binding allows describing mux controller and listing available -functions. They can be referenced later by other bindings to let system -configure controller correctly. - -A list of pins varies across chipsets so few bindings are available. - -Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" -noce. - -Required properties: -- compatible: must be one of: - "brcm,bcm4708-pinmux" - "brcm,bcm4709-pinmux" - "brcm,bcm53012-pinmux" -- offset: offset of pin registers in the CRU block - -Functions and their groups available for all chipsets: -- "spi": "spi_grp" -- "i2c": "i2c_grp" -- "pwm": "pwm0_grp", "pwm1_grp", "pwm2_grp", "pwm3_grp" -- "uart1": "uart1_grp" - -Additionally available on BCM4709 and BCM53012: -- "mdio": "mdio_grp" -- "uart2": "uart2_grp" -- "sdio": "sdio_pwr_grp", "sdio_1p8v_grp" - -For documentation of subnodes see: -Documentation/devicetree/bindings/pinctrl/pinctrl-bindings.txt - -Example: - dmu@1800c000 { - compatible = "simple-bus"; - ranges = <0 0x1800c000 0x1000>; - #address-cells = <1>; - #size-cells = <1>; - - cru@100 { - compatible = "syscon", "simple-mfd"; - reg = <0x100 0x1a4>; - - pinctrl { - compatible = "brcm,bcm4708-pinmux"; - offset = <0xc0>; - - spi-pins { - function = "spi"; - groups = "spi_grp"; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml new file mode 100644 index 000000000000..470aff599c27 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,ns-pinmux.yaml @@ -0,0 +1,94 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,ns-pinmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom Northstar pins mux controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: + Some of Northstar SoCs's pins can be used for various purposes thanks to the + mux controller. This binding allows describing mux controller and listing + available functions. They can be referenced later by other bindings to let + system configure controller correctly. + + A list of pins varies across chipsets so few bindings are available. + + Node of the pinmux must be nested in the CRU (Central Resource Unit) "syscon" + node. + +properties: + compatible: + enum: + - brcm,bcm4708-pinmux + - brcm,bcm4709-pinmux + - brcm,bcm53012-pinmux + + offset: + description: offset of pin registers in the CRU block + maxItems: 1 + $ref: /schemas/types.yaml#/definitions/uint32-array + +patternProperties: + '-pins$': + type: object + description: pin node + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ spi, i2c, pwm, uart1, mdio, uart2, sdio ] + groups: + minItems: 1 + maxItems: 4 + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp, mdio_grp, uart2_grp, sdio_pwr_grp, sdio_1p8v_grp ] + + required: + - function + - groups + + additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + const: brcm,bcm4708-pinmux + then: + patternProperties: + '-pins$': + properties: + function: + enum: [ spi, i2c, pwm, uart1 ] + groups: + items: + enum: [ spi_grp, i2c_grp, pwm0_grp, pwm1_grp, pwm2_grp, pwm3_grp, + uart1_grp ] + +required: + - offset + +additionalProperties: false + +examples: + - | + cru@1800c100 { + compatible = "syscon", "simple-mfd"; + reg = <0x1800c100 0x1a4>; + + pinctrl { + compatible = "brcm,bcm4708-pinmux"; + offset = <0xc0>; + + spi-pins { + function = "spi"; + groups = "spi_grp"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt index 6ec3c8d79f49..2fa5edac7a35 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mcp23s08.txt @@ -49,6 +49,7 @@ Optional properties: - interrupt-controller: Marks the device node as a interrupt controller. - drive-open-drain: Sets the ODR flag in the IOCON register. This configures the IRQ output as open drain active low. +- reset-gpios: Corresponds to the active-low RESET# pin for the chip Optional device specific properties: - microchip,irq-mirror: Sets the mirror flag in the IOCON register. Devices @@ -135,6 +136,7 @@ gpio21: gpio@21 { microchip,irq-mirror; pinctrl-names = "default"; pinctrl-0 = <&i2cgpio0irq>, <&gpio21pullups>; + reset-gpios = <&gpio6 15 GPIO_ACTIVE_LOW>; gpio21pullups: pinmux { pins = "gpio0", "gpio1", "gpio2", "gpio3", diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt index 360e59c9301a..5fe2c26c28bf 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt65xx.txt @@ -12,6 +12,7 @@ Required properties: "mediatek,mt8135-pinctrl", compatible with mt8135 pinctrl. "mediatek,mt8167-pinctrl", compatible with mt8167 pinctrl. "mediatek,mt8173-pinctrl", compatible with mt8173 pinctrl. + "mediatek,mt8365-pinctrl", compatible with mt8365 pinctrl. "mediatek,mt8516-pinctrl", compatible with mt8516 pinctrl. - pins-are-numbered: Specify the subnodes are using numbered pinmux to specify pins. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt index f6a9760558a6..161216daf463 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.txt @@ -31,6 +31,7 @@ PMIC's from Qualcomm. "qcom,pm8350b-gpio" "qcom,pm8350c-gpio" "qcom,pmk8350-gpio" + "qcom,pm7325-gpio" "qcom,pmr735a-gpio" "qcom,pmr735b-gpio" "qcom,pm6150-gpio" @@ -120,6 +121,7 @@ to specify in a pin configuration subnode: gpio1-gpio8 for pm8350b gpio1-gpio9 for pm8350c gpio1-gpio4 for pmk8350 + gpio1-gpio10 for pm7325 gpio1-gpio4 for pmr735a gpio1-gpio4 for pmr735b gpio1-gpio10 for pm6150 diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt index 0ba07bc96c55..5363d44cbb74 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.txt @@ -21,6 +21,7 @@ of PMIC's from Qualcomm. "qcom,pmi8950-mpp", "qcom,pm8994-mpp", "qcom,pma8084-mpp", + "qcom,pmi8994-mpp", And must contain either "qcom,spmi-mpp" or "qcom,ssbi-mpp" if the device is on an spmi bus or an ssbi bus respectively. diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml new file mode 100644 index 000000000000..5f7adaa81f83 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sm6125-pinctrl.yaml @@ -0,0 +1,132 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sm6125-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: Qualcomm Technologies, Inc. SM6125 TLMM block + +maintainers: + - Martin Botka <martin.botka@somainline.org> + +description: | + This binding describes the Top Level Mode Multiplexer (TLMM) block found + in the SM6125 platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sm6125-tlmm + + reg: + minItems: 3 + maxItems: 3 + + reg-names: + items: + - const: "west" + - const: "south" + - const: "east" + + interrupts: true + interrupt-controller: true + '#interrupt-cells': true + gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': true + gpio-ranges: true + wakeup-parent: true + +required: + - compatible + - reg + - reg-names + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sm6125-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sm6125-tlmm-state" + +$defs: + qcom-sm6125-tlmm-state: + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + $ref: "qcom,tlmm-common.yaml#/$defs/qcom-tlmm-state" + + properties: + pins: + description: + List of gpio pins affected by the properties specified in this + subnode. + items: + oneOf: + - pattern: "^gpio[0-9]|[1-9][0-9]|1[0-2][0-9]|13[0-2]$" + - enum: [ sdc1_clk, sdc1_cmd, sdc1_data, sdc2_clk, sdc2_cmd, sdc2_data ] + minItems: 1 + maxItems: 36 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ adsp_ext, agera_pll, atest_char, atest_char0, atest_char1, + atest_char2, atest_char3, atest_tsens, atest_tsens2, atest_usb1, + atest_usb10, atest_usb11, atest_usb12, atest_usb13, atest_usb2, + atest_usb20, atest_usb21, atest_usb22, atest_usb23, aud_sb, + audio_ref, cam_mclk, cci_async, cci_i2c, cci_timer0, cci_timer1, + cci_timer2, cci_timer3, cci_timer4, copy_gp, copy_phase, cri_trng, + cri_trng0, cri_trng1, dbg_out, ddr_bist, ddr_pxi0, ddr_pxi1, + ddr_pxi2, ddr_pxi3, debug_hot, dmic0_clk, dmic0_data, dmic1_clk, + dmic1_data, dp_hot, edp_hot, edp_lcd, gcc_gp1, gcc_gp2, gcc_gp3, + gp_pdm0, gp_pdm1, gp_pdm2, gpio, gps_tx, jitter_bist, ldo_en, + ldo_update, m_voc, mclk1, mclk2, mdp_vsync, mdp_vsync0, mdp_vsync1, + mdp_vsync2, mdp_vsync3, mdp_vsync4, mdp_vsync5, mpm_pwr, mss_lte, + nav_pps, pa_indicator, phase_flag, pll_bist, pll_bypassnl, pll_reset, + pri_mi2s, pri_mi2s_ws, prng_rosc, qca_sb, qdss_cti, qdss, qlink_enable, + qlink_request, qua_mi2s, qui_mi2s, qup00, qup01, qup02, qup03, qup04, + qup10, qup11, qup12, qup13, qup14, sd_write, sec_mi2s, sp_cmu, swr_rx, + swr_tx, ter_mi2s, tgu_ch0, tgu_ch1, tgu_ch2, tgu_ch3, tsense_pwm, + uim1_clk, uim1_data, uim1_present, uim1_reset, uim2_clk, uim2_data, + uim2_present, uim2_reset, unused1, unused2, usb_phy, vfr_1, vsense_trigger, + wlan1_adc0, wlan1_adc1, wlan2_adc0, wlan2_adc1, wsa_clk, wsa_data ] + + + bias-disable: true + bias-pull-down: true + bias-pull-up: true + drive-strength: true + input-enable: true + output-high: true + output-low: true + + required: + - pins + - function + + additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + pinctrl@500000 { + compatible = "qcom,sm6125-tlmm"; + reg = <0x00500000 0x400000>, + <0x00900000 0x400000>, + <0x00d00000 0x400000>; + reg-names = "west", "south", "east"; + interrupts = <GIC_SPI 227 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + gpio-ranges = <&tlmm 0 0 134>; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml index d30f85cc395e..f005abac7079 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-ee-pwrc.yaml @@ -37,7 +37,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: vpu - const: vapb diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt deleted file mode 100644 index 49aba15dff8b..000000000000 --- a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.txt +++ /dev/null @@ -1,100 +0,0 @@ -DT bindings for the Renesas R-Mobile System Controller - -== System Controller Node == - -The R-Mobile System Controller provides the following functions: - - Boot mode management, - - Reset generation, - - Power management. - -Required properties: -- compatible: Should be "renesas,sysc-<soctype>", "renesas,sysc-rmobile" as - fallback. - Examples with soctypes are: - - "renesas,sysc-r8a73a4" (R-Mobile APE6) - - "renesas,sysc-r8a7740" (R-Mobile A1) - - "renesas,sysc-sh73a0" (SH-Mobile AG5) -- reg: Two address start and address range blocks for the device: - - The first block refers to the normally accessible registers, - - the second block refers to the registers protected by the HPB - semaphore. - -Optional nodes: -- pm-domains: This node contains a hierarchy of PM domain nodes, which should - match the Power Area Hierarchy in the Power Domain Specifications section of - the device's datasheet. - - -== PM Domain Nodes == - -Each of the PM domain nodes represents a PM domain, as documented by the -generic PM domain bindings in -Documentation/devicetree/bindings/power/power-domain.yaml. - -The nodes should be named by the real power area names, and thus their names -should be unique. - -Required properties: - - #power-domain-cells: Must be 0. - -Optional properties: -- reg: If the PM domain is not always-on, this property must contain the bit - index number for the corresponding power area in the various Power - Control and Status Registers. The parent's node must contain the - following two properties: - - #address-cells: Must be 1, - - #size-cells: Must be 0. - If the PM domain is always-on, this property must be omitted. - - -Example: - -This shows a subset of the r8a7740 PM domain hierarchy, containing the -C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP domain, -which is a subdomain of A4S. - - sysc: system-controller@e6180000 { - compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; - reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; - - pm-domains { - pd_c5: c5 { - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a4s: a4s@10 { - reg = <10>; - #address-cells = <1>; - #size-cells = <0>; - #power-domain-cells = <0>; - - pd_a3sp: a3sp@11 { - reg = <11>; - #power-domain-cells = <0>; - }; - }; - - pd_a4su: a4su@20 { - reg = <20>; - #power-domain-cells = <0>; - }; - }; - }; - }; - - -== PM Domain Consumers == - -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node. - -Example: - - tpu: pwm@e6600000 { - compatible = "renesas,tpu-r8a7740", "renesas,tpu"; - reg = <0xe6600000 0x100>; - clocks = <&mstp3_clks R8A7740_CLK_TPU0>; - power-domains = <&pd_a3sp>; - #pwm-cells = <3>; - }; diff --git a/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml new file mode 100644 index 000000000000..559718997de7 --- /dev/null +++ b/Documentation/devicetree/bindings/power/renesas,sysc-rmobile.yaml @@ -0,0 +1,121 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/renesas,sysc-rmobile.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas R-Mobile System Controller + +maintainers: + - Geert Uytterhoeven <geert+renesas@glider.be> + - Magnus Damm <magnus.damm@gmail.com> + +description: | + The R-Mobile System Controller provides the following functions: + - Boot mode management, + - Reset generation, + - Power management. + +properties: + compatible: + items: + - enum: + - renesas,sysc-r8a73a4 # R-Mobile APE6 + - renesas,sysc-r8a7740 # R-Mobile A1 + - renesas,sysc-sh73a0 # SH-Mobile AG5 + - const: renesas,sysc-rmobile # Generic SH/R-Mobile + + reg: + items: + - description: Normally accessible register block + - description: Register block protected by the HPB semaphore + + pm-domains: + type: object + description: | + This node contains a hierarchy of PM domain nodes, which should match the + Power Area Hierarchy in the Power Domain Specifications section of the + device's datasheet. + + properties: + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + additionalProperties: + $ref: "#/$defs/pd-node" + +required: + - compatible + - reg + - pm-domains + +additionalProperties: false + +$defs: + pd-node: + type: object + description: + PM domain node representing a PM domain. This node hould be named by + the real power area name, and thus its name should be unique. + + properties: + reg: + maxItems: 1 + description: + If the PM domain is not always-on, this property must contain the + bit index number for the corresponding power area in the various + Power Control and Status Registers. + If the PM domain is always-on, this property must be omitted. + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#power-domain-cells': + const: 0 + + required: + - '#power-domain-cells' + + additionalProperties: + $ref: "#/$defs/pd-node" + +examples: + - | + // This shows a subset of the r8a7740 PM domain hierarchy, containing the + // C5 "always-on" domain, 2 of its subdomains (A4S and A4SU), and the A3SP + // domain, which is a subdomain of A4S. + sysc: system-controller@e6180000 { + compatible = "renesas,sysc-r8a7740", "renesas,sysc-rmobile"; + reg = <0xe6180000 0x8000>, <0xe6188000 0x8000>; + + pm-domains { + pd_c5: c5 { + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a4s: a4s@10 { + reg = <10>; + #address-cells = <1>; + #size-cells = <0>; + #power-domain-cells = <0>; + + pd_a3sp: a3sp@11 { + reg = <11>; + #power-domain-cells = <0>; + }; + }; + + pd_a4su: a4su@20 { + reg = <20>; + #power-domain-cells = <0>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/charger-manager.txt b/Documentation/devicetree/bindings/power/supply/charger-manager.txt deleted file mode 100644 index b5ae9061b7a0..000000000000 --- a/Documentation/devicetree/bindings/power/supply/charger-manager.txt +++ /dev/null @@ -1,91 +0,0 @@ -charger-manager bindings -~~~~~~~~~~~~~~~~~~~~~~~~ - -Required properties : - - compatible : "charger-manager" - - <>-supply : for regulator consumer, named according to cm-regulator-name - - cm-chargers : name of chargers - - cm-fuel-gauge : name of battery fuel gauge - - subnode <regulator> : - - cm-regulator-name : name of charger regulator - - subnode <cable> : - - cm-cable-name : name of charger cable - one of USB, USB-HOST, - SDP, DCP, CDP, ACA, FAST-CHARGER, SLOW-CHARGER, WPT, - PD, DOCK, JIG, or MECHANICAL - - cm-cable-extcon : name of extcon dev -(optional) - cm-cable-min : minimum current of cable -(optional) - cm-cable-max : maximum current of cable - -Optional properties : - - cm-name : charger manager's name (default : "battery") - - cm-poll-mode : polling mode - 0 for disabled, 1 for always, 2 for when - external power is connected, or 3 for when charging. If not present, - then polling is disabled - - cm-poll-interval : polling interval (in ms) - - cm-battery-stat : battery status - 0 for battery always present, 1 for no - battery, 2 to check presence via fuel gauge, or 3 to check presence - via charger - - cm-fullbatt-vchkdrop-volt : voltage drop (in uV) before restarting charging - - cm-fullbatt-voltage : voltage (in uV) of full battery - - cm-fullbatt-soc : state of charge to consider as full battery - - cm-fullbatt-capacity : capcity (in uAh) to consider as full battery - - cm-thermal-zone : name of external thermometer's thermal zone - - cm-battery-* : threshold battery temperature for charging - -cold : critical cold temperature of battery for charging - -cold-in-minus : flag that cold temperature is in minus degrees - -hot : critical hot temperature of battery for charging - -temp-diff : temperature difference to allow recharging - - cm-dis/charging-max = limits of charging duration - -Deprecated properties: - - cm-num-chargers - - cm-fullbatt-vchkdrop-ms - -Example : - charger-manager@0 { - compatible = "charger-manager"; - chg-reg-supply = <&charger_regulator>; - - cm-name = "battery"; - /* Always polling ON : 30s */ - cm-poll-mode = <1>; - cm-poll-interval = <30000>; - - cm-fullbatt-vchkdrop-volt = <150000>; - cm-fullbatt-soc = <100>; - - cm-battery-stat = <3>; - - cm-chargers = "charger0", "charger1", "charger2"; - - cm-fuel-gauge = "fuelgauge0"; - - cm-thermal-zone = "thermal_zone.1" - /* in deci centigrade */ - cm-battery-cold = <50>; - cm-battery-cold-in-minus; - cm-battery-hot = <800>; - cm-battery-temp-diff = <100>; - - /* Allow charging for 5hr */ - cm-charging-max = <18000000>; - /* Allow discharging for 2hr */ - cm-discharging-max = <7200000>; - - regulator@0 { - cm-regulator-name = "chg-reg"; - cable@0 { - cm-cable-name = "USB"; - cm-cable-extcon = "extcon-dev.0"; - cm-cable-min = <475000>; - cm-cable-max = <500000>; - }; - cable@1 { - cm-cable-name = "SDP"; - cm-cable-extcon = "extcon-dev.0"; - cm-cable-min = <650000>; - cm-cable-max = <675000>; - }; - }; - - }; diff --git a/Documentation/devicetree/bindings/power/supply/charger-manager.yaml b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml new file mode 100644 index 000000000000..c863cfa67865 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/charger-manager.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/charger-manager.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Charger Manager + +maintainers: + - Sebastian Reichel <sre@kernel.org> + +description: | + Binding for the legacy charger manager driver. + Please do not use for new products. + +properties: + compatible: + const: charger-manager + + cm-chargers: + description: name of chargers + $ref: /schemas/types.yaml#/definitions/string-array + + cm-num-chargers: + $ref: /schemas/types.yaml#/definitions/uint32 + deprecated: true + + cm-fuel-gauge: + description: name of battery fuel gauge + $ref: /schemas/types.yaml#/definitions/string + + cm-name: + description: name of the charger manager + default: battery + $ref: /schemas/types.yaml#/definitions/string + + cm-poll-mode: + description: polling mode + default: 0 + enum: + - 0 # disabled + - 1 # always + - 2 # when external power is connected + - 3 # when charging + + cm-poll-interval: + description: polling interval (in ms) + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-stat: + description: battery status + enum: + - 0 # battery always present + - 1 # no battery + - 2 # check presence via fuel gauge + - 3 # check presence via charger + + cm-fullbatt-vchkdrop-volt: + description: voltage drop before restarting charging in uV + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-vchkdrop-ms: + deprecated: true + + cm-fullbatt-voltage: + description: voltage of full battery in uV + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-soc: + description: state of charge to consider as full battery in % + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-fullbatt-capacity: + description: capcity to consider as full battery in uAh + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-thermal-zone: + description: name of external thermometer's thermal zone + $ref: /schemas/types.yaml#/definitions/string + + cm-discharging-max: + description: limits of discharging duration in ms + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-charging-max: + description: limits of charging duration in ms + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-cold: + description: critical cold temperature of battery for charging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-cold-in-minus: + description: if set cm-battery-cold temperature is in minus degrees + type: boolean + + cm-battery-hot: + description: critical hot temperature of battery for charging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-battery-temp-diff: + description: temperature difference to allow recharging in deci-degree celsius + $ref: /schemas/types.yaml#/definitions/uint32 + +patternProperties: + "-supply$": + description: regulator consumer, named according to cm-regulator-name + $ref: /schemas/types.yaml#/definitions/phandle + + "^regulator[@-][0-9]$": + type: object + properties: + cm-regulator-name: + description: name of charger regulator + $ref: /schemas/types.yaml#/definitions/string + + required: + - cm-regulator-name + + additionalProperties: false + + patternProperties: + "^cable[@-][0-9]$": + type: object + properties: + cm-cable-name: + description: name of charger cable + enum: + - USB + - USB-HOST + - SDP + - DCP + - CDP + - ACA + - FAST-CHARGER + - SLOW-CHARGER + - WPT + - PD + - DOCK + - JIG + - MECHANICAL + + cm-cable-extcon: + description: name of extcon dev + $ref: /schemas/types.yaml#/definitions/string + + cm-cable-min: + description: minimum current of cable in uA + $ref: /schemas/types.yaml#/definitions/uint32 + + cm-cable-max: + description: maximum current of cable in uA + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - cm-cable-name + - cm-cable-extcon + + additionalProperties: false + +required: + - compatible + - cm-chargers + - cm-fuel-gauge + +additionalProperties: false + +examples: + - | + charger-manager { + compatible = "charger-manager"; + chg-reg-supply = <&charger_regulator>; + + cm-name = "battery"; + /* Always polling ON : 30s */ + cm-poll-mode = <1>; + cm-poll-interval = <30000>; + + cm-fullbatt-vchkdrop-volt = <150000>; + cm-fullbatt-soc = <100>; + + cm-battery-stat = <3>; + + cm-chargers = "charger0", "charger1", "charger2"; + + cm-fuel-gauge = "fuelgauge0"; + + cm-thermal-zone = "thermal_zone.1"; + /* in deci centigrade */ + cm-battery-cold = <50>; + cm-battery-cold-in-minus; + cm-battery-hot = <800>; + cm-battery-temp-diff = <100>; + + /* Allow charging for 5hr */ + cm-charging-max = <18000000>; + /* Allow discharging for 2hr */ + cm-discharging-max = <7200000>; + + regulator-0 { + cm-regulator-name = "chg-reg"; + cable-0 { + cm-cable-name = "USB"; + cm-cable-extcon = "extcon-dev.0"; + cm-cable-min = <475000>; + cm-cable-max = <500000>; + }; + cable-1 { + cm-cable-name = "SDP"; + cm-cable-extcon = "extcon-dev.0"; + cm-cable-min = <650000>; + cm-cable-max = <675000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml index de91cf3f058c..f792d06db413 100644 --- a/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml +++ b/Documentation/devicetree/bindings/power/supply/maxim,max17040.yaml @@ -89,7 +89,7 @@ examples: reg = <0x36>; maxim,alert-low-soc-level = <10>; interrupt-parent = <&gpio7>; - interrupts = <2 IRQ_TYPE_EDGE_FALLING>; + interrupts = <2 IRQ_TYPE_LEVEL_LOW>; wakeup-source; }; }; diff --git a/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml new file mode 100644 index 000000000000..ae647d3355a2 --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/richtek,rt5033-battery.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/power/supply/richtek,rt5033-battery.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Richtek RT5033 PMIC Fuel Gauge + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +allOf: + - $ref: power-supply.yaml# + +properties: + compatible: + const: richtek,rt5033-battery + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@35 { + compatible = "richtek,rt5033-battery"; + reg = <0x35>; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + battery@35 { + compatible = "richtek,rt5033-battery"; + reg = <0x35>; + interrupt-parent = <&msmgpio>; + interrupts = <121 IRQ_TYPE_EDGE_FALLING>; + }; + }; diff --git a/Documentation/devicetree/bindings/property-units.txt b/Documentation/devicetree/bindings/property-units.txt deleted file mode 100644 index 218f99fa311f..000000000000 --- a/Documentation/devicetree/bindings/property-units.txt +++ /dev/null @@ -1,48 +0,0 @@ -Standard Unit Suffixes for Property names - -Properties which have a unit of measure are recommended to have a unit -suffix appended to the property name. The list below contains the -recommended suffixes. Other variations exist in bindings, but should not -be used in new bindings or added here. The inconsistency in the unit -prefixes is due to selecting the most commonly used variants. - -It is also recommended to use the units listed here and not add additional -unit prefixes. - -Time/Frequency ----------------------------------------- --mhz : megahertz --hz : hertz (preferred) --sec : second --ms : millisecond --us : microsecond --ns : nanosecond --ps : picosecond - -Distance ----------------------------------------- --mm : millimeter - -Electricity ----------------------------------------- --microamp : microampere --microamp-hours : microampere hour --ohms : ohm --micro-ohms : microohm --microwatt-hours: microwatt hour --microvolt : microvolt --picofarads : picofarad --femtofarads : femtofarad - -Temperature ----------------------------------------- --celsius : degree Celsius --millicelsius : millidegree Celsius - -Pressure ----------------------------------------- --kpascal : kilopascal - -Throughput ----------------------------------------- --kBps : kilobytes per second diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 7dcab2bf8128..54a7700df08f 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -37,7 +37,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Module Clock - description: Bus Clock diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt deleted file mode 100644 index 655f6cd4ef46..000000000000 --- a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.txt +++ /dev/null @@ -1,21 +0,0 @@ -Broadcom iProc PWM controller device tree bindings - -This controller has 4 channels. - -Required Properties : -- compatible: must be "brcm,iproc-pwm" -- reg: physical base address and length of the controller's registers -- clocks: phandle + clock specifier pair for the external clock -- #pwm-cells: Should be 3. See pwm.yaml in this directory for a - description of the cells format. - -Refer to clocks/clock-bindings.txt for generic clock consumer properties. - -Example: - -pwm: pwm@18031000 { - compatible = "brcm,iproc-pwm"; - reg = <0x18031000 0x28>; - clocks = <&osc>; - #pwm-cells = <3>; -}; diff --git a/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml new file mode 100644 index 000000000000..218ab06c34d1 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/brcm,iproc-pwm.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/brcm,iproc-pwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom iProc PWM controller + +maintainers: + - Rafał Miłecki <rafal@milecki.pl> + +description: + This controller has 4 channels. + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + const: brcm,iproc-pwm + + reg: + maxItems: 1 + + clocks: + description: external clock + maxItems: 1 + + "#pwm-cells": + const: 3 + +unevaluatedProperties: false + +required: + - reg + - clocks + +examples: + - | + pwm@18031000 { + compatible = "brcm,iproc-pwm"; + reg = <0x18031000 0x28>; + clocks = <&osc>; + #pwm-cells = <3>; + }; diff --git a/Documentation/devicetree/bindings/pwm/pwm.yaml b/Documentation/devicetree/bindings/pwm/pwm.yaml index 7d1f687cee9c..2effe6c0de6b 100644 --- a/Documentation/devicetree/bindings/pwm/pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm.yaml @@ -24,8 +24,9 @@ additionalProperties: true examples: - | - pwm: pwm@7000a000 { - compatible = "nvidia,tegra20-pwm"; - reg = <0x7000a000 0x100>; - #pwm-cells = <2>; + pwm: pwm@1c20e00 { + compatible = "allwinner,sun7i-a20-pwm"; + reg = <0x01c20e00 0xc>; + clocks = <&osc24M>; + #pwm-cells = <3>; }; diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 3c2fa2e93d1b..7ea1070b4b3a 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -61,6 +61,19 @@ required: - reg - '#pwm-cells' - clocks + - power-domains + +if: + not: + properties: + compatible: + contains: + enum: + - renesas,pwm-r8a7778 + - renesas,pwm-r8a7779 +then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml index aa9a4570c906..81ccb2110162 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -9,6 +9,15 @@ title: Renesas R-Car Timer Pulse Unit PWM Controller maintainers: - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> +select: + properties: + compatible: + contains: + const: renesas,tpu + required: + - compatible + - '#pwm-cells' + properties: compatible: items: @@ -58,6 +67,23 @@ required: - compatible - reg - '#pwm-cells' + - clocks + - power-domains + +allOf: + - $ref: pwm.yaml# + + - if: + not: + properties: + compatible: + contains: + enum: + - renesas,tpu-r8a73a4 + - renesas,tpu-r8a7740 + then: + required: + - resets additionalProperties: false diff --git a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml index 208a628f8d6c..fc16d903353e 100644 --- a/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/fsl,imx-rproc.yaml @@ -17,7 +17,11 @@ properties: enum: - fsl,imx8mq-cm4 - fsl,imx8mm-cm4 + - fsl,imx8mn-cm7 + - fsl,imx8mp-cm7 + - fsl,imx8ulp-cm33 - fsl,imx7d-cm4 + - fsl,imx7ulp-cm4 - fsl,imx6sx-cm4 clocks: @@ -49,10 +53,14 @@ properties: minItems: 1 maxItems: 32 + fsl,auto-boot: + $ref: /schemas/types.yaml#/definitions/flag + description: + Indicate whether need to load the default firmware and start the remote + processor automatically. + required: - compatible - - clocks - - syscon additionalProperties: false diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt deleted file mode 100644 index 229f908fd831..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.txt +++ /dev/null @@ -1,228 +0,0 @@ -Qualcomm ADSP Peripheral Image Loader - -This document defines the binding for a component that loads and boots firmware -on the Qualcomm ADSP Hexagon core. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,msm8974-adsp-pil" - "qcom,msm8996-adsp-pil" - "qcom,msm8996-slpi-pil" - "qcom,msm8998-adsp-pas" - "qcom,msm8998-slpi-pas" - "qcom,qcs404-adsp-pas" - "qcom,qcs404-cdsp-pas" - "qcom,qcs404-wcss-pas" - "qcom,sc7180-mpss-pas" - "qcom,sdm845-adsp-pas" - "qcom,sdm845-cdsp-pas" - "qcom,sdx55-mpss-pas" - "qcom,sm8150-adsp-pas" - "qcom,sm8150-cdsp-pas" - "qcom,sm8150-mpss-pas" - "qcom,sm8150-slpi-pas" - "qcom,sm8250-adsp-pas" - "qcom,sm8250-cdsp-pas" - "qcom,sm8250-slpi-pas" - "qcom,sm8350-adsp-pas" - "qcom,sm8350-cdsp-pas" - "qcom,sm8350-slpi-pas" - "qcom,sm8350-mpss-pas" - -- interrupts-extended: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the interrupts that match interrupt-names - -- interrupt-names: - Usage: required - Value type: <stringlist> - Definition: The interrupts needed depends on the compatible - string: - qcom,msm8974-adsp-pil: - qcom,msm8996-adsp-pil: - qcom,msm8996-slpi-pil: - qcom,msm8998-adsp-pas: - qcom,msm8998-slpi-pas: - qcom,qcs404-adsp-pas: - qcom,qcs404-cdsp-pas: - qcom,sdm845-adsp-pas: - qcom,sdm845-cdsp-pas: - qcom,sm8150-adsp-pas: - qcom,sm8150-cdsp-pas: - qcom,sm8150-slpi-pas: - qcom,sm8250-adsp-pas: - qcom,sm8250-cdsp-pas: - qcom,sm8250-slpi-pas: - qcom,sm8350-adsp-pas: - qcom,sm8350-cdsp-pas: - qcom,sm8350-slpi-pas: - must be "wdog", "fatal", "ready", "handover", "stop-ack" - qcom,qcs404-wcss-pas: - qcom,sc7180-mpss-pas: - qcom,sdx55-mpss-pas: - qcom,sm8150-mpss-pas: - qcom,sm8350-mpss-pas: - must be "wdog", "fatal", "ready", "handover", "stop-ack", - "shutdown-ack" - -- firmware-name: - Usage: optional - Value type: <string> - Definition: must list the relative firmware image path for the - Hexagon Core. - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: reference to the xo clock and optionally aggre2 clock to be - held on behalf of the booting Hexagon core - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: must be "xo" and optionally include "aggre2" - -- cx-supply: - Usage: required - Value type: <phandle> - Definition: reference to the regulator to be held on behalf of the - booting Hexagon core - -- px-supply: - Usage: required - Value type: <phandle> - Definition: reference to the px regulator to be held on behalf of the - booting Hexagon core - -- power-domains: - Usage: required - Value type: <phandle> - Definition: reference to power-domains that match the power-domain-names - -- power-domain-names: - Usage: required - Value type: <stringlist> - Definition: The power-domains needed depend on the compatible string: - qcom,msm8974-adsp-pil: - qcom,msm8996-adsp-pil: - qcom,msm8998-adsp-pas: - must be "cx" - qcom,msm8996-slpi-pil: - must be "ss_cx" - qcom,msm8998-slpi-pas: - must be "ssc_cx" - qcom,qcs404-adsp-pas: - must be "lpi_cx" - qcom,qcs404-cdsp-pas: - qcom,qcs404-wcss-pas: - must be "mx" - qcom,sdm845-adsp-pas: - qcom,sdm845-cdsp-pas: - qcom,sm8150-adsp-pas: - qcom,sm8150-cdsp-pas: - qcom,sm8250-cdsp-pas: - qcom,sm8350-cdsp-pas: - must be "cx", "load_state" - qcom,sc7180-mpss-pas: - qcom,sm8150-mpss-pas: - qcom,sm8350-mpss-pas: - must be "cx", "load_state", "mss" - qcom,sdx55-mpss-pas: - must be "cx", "mss" - qcom,sm8250-adsp-pas: - qcom,sm8350-adsp-pas: - qcom,sm8150-slpi-pas: - qcom,sm8250-slpi-pas: - qcom,sm8350-slpi-pas: - must be "lcx", "lmx", "load_state" - -- memory-region: - Usage: required - Value type: <phandle> - Definition: reference to the reserved-memory for the ADSP - -- qcom,smem-states: - Usage: required - Value type: <phandle> - Definition: reference to the smem state for requesting the ADSP to - shut down - -- qcom,smem-state-names: - Usage: required - Value type: <stringlist> - Definition: must be "stop" - - -= SUBNODES -The adsp node may have an subnode named either "smd-edge" or "glink-edge" that -describes the communication edge, channels and devices related to the ADSP. -See ../soc/qcom/qcom,smd.txt and ../soc/qcom/qcom,glink.txt for details on how -to describe these. - - -= EXAMPLE -The following example describes the resources needed to boot control the -ADSP, as it is found on MSM8974 boards. - - adsp { - compatible = "qcom,msm8974-adsp-pil"; - - interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; - - clocks = <&rpmcc RPM_CXO_CLK>; - clock-names = "xo"; - - cx-supply = <&pm8841_s2>; - - memory-region = <&adsp_region>; - - qcom,smem-states = <&adsp_smp2p_out 0>; - qcom,smem-state-names = "stop"; - - smd-edge { - interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; - - qcom,ipc = <&apcs 8 8>; - qcom,smd-edge = <1>; - }; - }; - -The following example describes the resources needed to boot control the -SLPI, as it is found on MSM8996 boards. - - slpi { - compatible = "qcom,msm8996-slpi-pil"; - interrupts-extended = <&intc 0 390 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, - <&slpi_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; - interrupt-names = "wdog", - "fatal", - "ready", - "handover", - "stop-ack"; - - clocks = <&rpmcc MSM8996_RPM_SMD_XO_CLK_SRC>, - <&rpmcc MSM8996_RPM_SMD_AGGR2_NOC_CLK>; - clock-names = "xo", "aggre2"; - - cx-supply = <&pm8994_l26>; - px-supply = <&pm8994_lvs2>; - - memory-region = <&slpi_region>; - qcom,smem-states = <&slpi_smp2p_out 0>; - qcom,smem-state-names = "stop"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml new file mode 100644 index 000000000000..c597ccced623 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -0,0 +1,547 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,adsp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm ADSP Peripheral Image Loader binding + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +description: + This document defines the binding for a component that loads and boots + firmware on the Qualcomm ADSP Hexagon core. + +properties: + compatible: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,msm8998-slpi-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-cdsp-pas + - qcom,qcs404-wcss-pas + - qcom,sc7180-mpss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-mpss-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sdx55-mpss-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-mpss-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + + reg: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 8 + + clock-names: + minItems: 1 + maxItems: 8 + + interrupts: + minItems: 5 + maxItems: 6 + + interrupt-names: + minItems: 5 + maxItems: 6 + + resets: + minItems: 1 + maxItems: 3 + + reset-names: + minItems: 1 + maxItems: 3 + + cx-supply: + description: Phandle to the CX regulator + + px-supply: + description: Phandle to the PX regulator + + power-domains: + minItems: 1 + maxItems: 3 + + power-domain-names: + minItems: 1 + maxItems: 3 + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: Firmware name for the Hexagon core + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + qcom,smem-states: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: States used by the AP to signal the Hexagon core + items: + - description: Stop the modem + + qcom,smem-state-names: + $ref: /schemas/types.yaml#/definitions/string-array + description: The names of the state bits used for SMP2P output + items: + - const: stop + + qcom,halt-regs: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Phandle reference to a syscon representing TCSR followed by the + three offsets within syscon for q6, modem and nc halt registers. + + smd-edge: + type: object + description: + Qualcomm Shared Memory subnode which represents communication edge, + channels and devices related to the ADSP. + + glink-edge: + type: object + description: + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the ADSP. + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +allOf: + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-wcss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sc8180x-mpss-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-mpss-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + - qcom,sm8350-mpss-pas + then: + properties: + clocks: + items: + - description: XO clock + clock-names: + items: + - const: xo + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-slpi-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: AGGRE2 clock + clock-names: + items: + - const: xo + - const: aggre2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcs404-cdsp-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: SWAY clock + - description: TBU clock + - description: BIMC clock + - description: AHB AON clock + - description: Q6SS SLAVE clock + - description: Q6SS MASTER clock + - description: Q6 AXIM clock + clock-names: + items: + - const: xo + - const: sway + - const: tbu + - const: bimc + - const: ahb_aon + - const: q6ss_slave + - const: q6ss_master + - const: q6_axim + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + clocks: + items: + - description: XO clock + - description: IFACE clock + - description: BUS clock + - description: NAC clock + - description: SNOC AXI clock + - description: MNOC AXI clock + clock-names: + items: + - const: xo + - const: iface + - const: bus + - const: nav + - const: snoc_axi + - const: mnoc_axi + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + - qcom,msm8996-adsp-pil + - qcom,msm8996-slpi-pil + - qcom,msm8998-adsp-pas + - qcom,msm8998-slpi-pas + - qcom,qcs404-adsp-pas + - qcom,qcs404-cdsp-pas + - qcom,qcs404-wcss-pas + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sdm845-adsp-pas + - qcom,sdm845-cdsp-pas + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-cdsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-cdsp-pas + - qcom,sm8350-slpi-pas + then: + properties: + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + - qcom,sc8180x-mpss-pas + - qcom,sdx55-mpss-pas + - qcom,sm8150-mpss-pas + - qcom,sm8350-mpss-pas + then: + properties: + interrupts: + items: + - description: Watchdog interrupt + - description: Fatal interrupt + - description: Ready interrupt + - description: Handover interrupt + - description: Stop acknowledge interrupt + - description: Shutdown acknowledge interrupt + interrupt-names: + items: + - const: wdog + - const: fatal + - const: ready + - const: handover + - const: stop-ack + - const: shutdown-ack + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8974-adsp-pil + then: + required: + - cx-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-adsp-pil + - qcom,msm8998-adsp-pas + then: + properties: + power-domains: + items: + - description: CX power domain + power-domain-names: + items: + - const: cx + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-slpi-pil + - qcom,msm8998-slpi-pas + then: + properties: + power-domains: + items: + - description: SSC-CX power domain + power-domain-names: + items: + - const: ssc_cx + required: + - px-supply + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MX power domain + - description: MSS power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-adsp-pas + - qcom,sm8150-cdsp-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + power-domain-names: + items: + - const: load_state + - const: cx + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8150-mpss-pas + - qcom,sm8350-mpss-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MSS power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdx55-mpss-pas + then: + properties: + power-domains: + items: + - description: CX power domain + - description: MSS power domain + power-domain-names: + items: + - const: cx + - const: mss + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc8180x-adsp-pas + - qcom,sc8180x-cdsp-pas + - qcom,sm8150-slpi-pas + - qcom,sm8250-adsp-pas + - qcom,sm8250-slpi-pas + - qcom,sm8350-adsp-pas + - qcom,sm8350-slpi-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: LCX power domain + - description: LMX power domain + power-domain-names: + items: + - const: load_state + - const: lcx + - const: lmx + + - if: + properties: + compatible: + contains: + enum: + - qcom,sm8350-cdsp-pas + then: + properties: + power-domains: + items: + - description: Load State power domain + - description: CX power domain + - description: MXC power domain + power-domain-names: + items: + - const: load_state + - const: cx + - const: mxc + + - if: + properties: + compatible: + contains: + enum: + - qcom,qcs404-cdsp-pas + then: + properties: + resets: + items: + - description: CDSP restart + reset-names: + items: + - const: restart + + - if: + properties: + compatible: + contains: + enum: + - qcom,sc7180-mpss-pas + then: + properties: + resets: + items: + - description: MSS restart + - description: PDC reset + reset-names: + items: + - const: mss_restart + - const: pdc_reset + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/interrupt-controller/irq.h> + adsp { + compatible = "qcom,msm8974-adsp-pil"; + + interrupts-extended = <&intc 0 162 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&adsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", + "fatal", + "ready", + "handover", + "stop-ack"; + + clocks = <&rpmcc RPM_CXO_CLK>; + clock-names = "xo"; + + cx-supply = <&pm8841_s2>; + + memory-region = <&adsp_region>; + + qcom,smem-states = <&adsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + smd-edge { + interrupts = <0 156 IRQ_TYPE_EDGE_RISING>; + + qcom,ipc = <&apcs 8 8>; + qcom,smd-edge = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index 64afdcfb613d..1e6225677e00 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -72,7 +72,6 @@ properties: - from local to remote, where ACK from the remote means that communnication as been stopped on the remote side. minItems: 1 - maxItems: 4 mbox-names: items: @@ -81,7 +80,6 @@ properties: - const: shutdown - const: detach minItems: 1 - maxItems: 4 memory-region: description: diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index d905d614502b..130fbaacc4b1 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -14,8 +14,12 @@ description: | processor subsystems/clusters (R5FSS). The dual core cluster can be used either in a LockStep mode providing safety/fault tolerance features or in a Split mode providing two individual compute cores for doubling the compute - capacity. These are used together with other processors present on the SoC - to achieve various system level goals. + capacity on most SoCs. These are used together with other processors present + on the SoC to achieve various system level goals. + + AM64x SoCs do not support LockStep mode, but rather a new non-safety mode + called "Single-CPU" mode, where only Core0 is used, but with ability to use + Core1's TCMs as well. Each Dual-Core R5F sub-system is represented as a single DTS node representing the cluster, with a pair of child DT nodes representing @@ -33,6 +37,7 @@ properties: - ti,am654-r5fss - ti,j721e-r5fss - ti,j7200-r5fss + - ti,am64-r5fss power-domains: description: | @@ -56,11 +61,12 @@ properties: ti,cluster-mode: $ref: /schemas/types.yaml#/definitions/uint32 - enum: [0, 1] description: | Configuration Mode for the Dual R5F cores within the R5F cluster. - Should be either a value of 1 (LockStep mode) or 0 (Split mode), - default is LockStep mode if omitted. + Should be either a value of 1 (LockStep mode) or 0 (Split mode) on + most SoCs (AM65x, J721E, J7200), default is LockStep mode if omitted; + and should be either a value of 0 (Split mode) or 2 (Single-CPU mode) + on AM64x SoCs, default is Split mode if omitted. # R5F Processor Child Nodes: # ========================== @@ -97,6 +103,7 @@ patternProperties: - ti,am654-r5f - ti,j721e-r5f - ti,j7200-r5f + - ti,am64-r5f reg: items: @@ -198,6 +205,20 @@ patternProperties: unevaluatedProperties: false +if: + properties: + compatible: + enum: + - ti,am64-r5fss +then: + properties: + ti,cluster-mode: + enum: [0, 2] +else: + properties: + ti,cluster-mode: + enum: [0, 1] + required: - compatible - power-domains diff --git a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt index 461dc1d8d570..463a97c11eff 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt +++ b/Documentation/devicetree/bindings/remoteproc/ti,keystone-rproc.txt @@ -48,7 +48,7 @@ The following are the mandatory properties: bindings for the reset argument specifier as per SoC, Documentation/devicetree/bindings/reset/ti-syscon-reset.txt for 66AK2HK/66AK2L/66AK2E SoCs or, - Documentation/devicetree/bindings/reset/ti,sci-reset.txt + Documentation/devicetree/bindings/reset/ti,sci-reset.yaml for 66AK2G SoCs - interrupts: Should contain an entry for each value in 'interrupt-names'. @@ -82,7 +82,7 @@ The following are mandatory properties for Keystone 2 66AK2G SoCs only: - power-domains: Should contain a phandle to a PM domain provider node and an args specifier containing the DSP device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml Optional properties: -------------------- diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index 73400bc6e91d..c6c12129d6b7 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -65,7 +65,7 @@ properties: OMAP Mailbox specifier denoting the sub-mailbox, to be used for communication with the remote processor. The specifier format is as per the bindings, - Documentation/devicetree/bindings/mailbox/omap-mailbox.txt + Documentation/devicetree/bindings/mailbox/ti,omap-mailbox.yaml This property should match with the sub-mailbox node used in the firmware image. @@ -116,7 +116,6 @@ properties: list, in the specified order, each representing the corresponding internal RAM memory region. minItems: 1 - maxItems: 3 items: - const: l2ram - const: l1pram diff --git a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml index 63071eef1632..d7c3a78e37e6 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,pru-rproc.yaml @@ -36,6 +36,9 @@ properties: enum: - ti,am3356-pru # for AM335x SoC family (AM3356+ SoCs only) - ti,am4376-pru # for AM437x SoC family (AM4376+ SoCs only) + - ti,am642-pru # for PRUs in K3 AM64x SoC family + - ti,am642-rtu # for RTUs in K3 AM64x SoC family + - ti,am642-tx-pru # for Tx_PRUs in K3 AM64x SoC family - ti,am5728-pru # for AM57xx SoC family - ti,k2g-pru # for 66AK2G SoC family - ti,am654-pru # for PRUs in K3 AM65x SoC family @@ -68,6 +71,7 @@ if: enum: - ti,am654-rtu - ti,j721e-rtu + - ti,am642-rtu then: properties: $nodename: @@ -79,6 +83,7 @@ else: enum: - ti,am654-tx-pru - ti,j721e-tx-pru + - ti,am642-tx-pru then: properties: $nodename: diff --git a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml index 27c5e34a3ac6..b11ac533f914 100644 --- a/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml +++ b/Documentation/devicetree/bindings/reset/fsl,imx-src.yaml @@ -59,7 +59,6 @@ properties: - description: SRC interrupt - description: CPU WDOG interrupts out of SRC minItems: 1 - maxItems: 2 '#reset-cells': const: 1 diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt b/Documentation/devicetree/bindings/reset/ti,sci-reset.txt deleted file mode 100644 index 8b1cf022f18a..000000000000 --- a/Documentation/devicetree/bindings/reset/ti,sci-reset.txt +++ /dev/null @@ -1,62 +0,0 @@ -Texas Instruments System Control Interface (TI-SCI) Reset Controller -===================================================================== - -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). -For TI SCI details, please refer to the document, -Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -TI-SCI Reset Controller Node -============================ -This reset controller node uses the TI SCI protocol to perform the reset -management of various hardware modules present on the SoC. Must be a child -node of the associated TI-SCI system controller node. - -Required properties: --------------------- - - compatible : Should be "ti,sci-reset" - - #reset-cells : Should be 2. Please see the reset consumer node below for - usage details. - -TI-SCI Reset Consumer Nodes -=========================== -Each of the reset consumer nodes should have the following properties, -in addition to their own properties. - -Required properties: --------------------- - - resets : A phandle and reset specifier pair, one pair for each reset - signal that affects the device, or that the device manages. - The phandle should point to the TI-SCI reset controller node, - and the reset specifier should have 2 cell-values. The first - cell should contain the device ID. The second cell should - contain the reset mask value used by system controller. - Please refer to the protocol documentation for these values - to be used for different devices, - http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data - -Please also refer to Documentation/devicetree/bindings/reset/reset.txt for -common reset controller usage by consumers. - -Example: --------- -The following example demonstrates both a TI-SCI reset controller node and a -consumer (a DSP device) on the 66AK2G SoC. - -pmmc: pmmc { - compatible = "ti,k2g-sci"; - - k2g_reset: reset-controller { - compatible = "ti,sci-reset"; - #reset-cells = <2>; - }; -}; - -dsp0: dsp@10800000 { - ... - resets = <&k2g_reset 0x0046 0x1>; - ... -}; diff --git a/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml new file mode 100644 index 000000000000..4639d2cec557 --- /dev/null +++ b/Documentation/devicetree/bindings/reset/ti,sci-reset.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/ti,sci-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI reset 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 reset controller node uses the TI SCI protocol to perform the reset + management of various hardware modules present on the SoC. Must be a child + node of the associated TI-SCI system controller node. + +properties: + $nodename: + pattern: "^reset-controller$" + + compatible: + const: ti,sci-reset + + "#reset-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 reset mask corresponding to the device + used by system controller. + + 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_reset: reset-controller { + compatible = "ti,sci-reset"; + #reset-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index 23b227614366..1d38ff76d18f 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -56,7 +56,6 @@ properties: interrupts: minItems: 3 - maxItems: 4 items: - description: DirError interrupt - description: DataError interrupt diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.txt b/Documentation/devicetree/bindings/rng/mtk-rng.txt deleted file mode 100644 index dfdcb5cd2ea8..000000000000 --- a/Documentation/devicetree/bindings/rng/mtk-rng.txt +++ /dev/null @@ -1,22 +0,0 @@ -Device-Tree bindings for Mediatek random number generator -found in MediaTek SoC family - -Required properties: -- compatible : Should be - "mediatek,mt7622-rng", "mediatek,mt7623-rng" : for MT7622 - "mediatek,mt7629-rng", "mediatek,mt7623-rng" : for MT7629 - "mediatek,mt7623-rng" : for MT7623 - "mediatek,mt8516-rng", "mediatek,mt7623-rng" : for MT8516 -- clocks : list of clock specifiers, corresponding to - entries in clock-names property; -- clock-names : Should contain "rng" entries; -- reg : Specifies base physical address and size of the registers - -Example: - -rng: rng@1020f000 { - compatible = "mediatek,mt7623-rng"; - reg = <0 0x1020f000 0 0x1000>; - clocks = <&infracfg CLK_INFRA_TRNG>; - clock-names = "rng"; -}; diff --git a/Documentation/devicetree/bindings/rng/mtk-rng.yaml b/Documentation/devicetree/bindings/rng/mtk-rng.yaml new file mode 100644 index 000000000000..61888e07bda0 --- /dev/null +++ b/Documentation/devicetree/bindings/rng/mtk-rng.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/rng/mtk-rng.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: MediaTek Random number generator + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + +properties: + $nodename: + pattern: "^rng@[0-9a-f]+$" + + compatible: + oneOf: + - enum: + - mediatek,mt7623-rng + - items: + - enum: + - mediatek,mt7622-rng + - mediatek,mt7629-rng + - mediatek,mt8365-rng + - mediatek,mt8516-rng + - const: mediatek,mt7623-rng + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rng + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2701-clk.h> + rng: rng@1020f000 { + compatible = "mediatek,mt7623-rng"; + reg = <0x1020f000 0x1000>; + clocks = <&infracfg CLK_INFRA_TRNG>; + clock-names = "rng"; + }; diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index b1b0ee769b71..beeb90e55727 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -32,7 +32,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: RTC Alarm 0 - description: RTC Alarm 1 diff --git a/Documentation/devicetree/bindings/rtc/arm,pl031.yaml b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml new file mode 100644 index 000000000000..fa5f2eda372e --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/arm,pl031.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/arm,pl031.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Arm Primecell PL031 Real Time Clock + +select: + properties: + compatible: + contains: + const: arm,pl031 + required: + - compatible + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + compatible: + items: + - const: arm,pl031 + - const: arm,primecell + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + maxItems: 1 + + start-year: true + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rtc@10017000 { + compatible = "arm,pl031", "arm,primecell"; + reg = <0x10017000 0x1000>; + clocks = <&pclk>; + clock-names = "apb_pclk"; + }; diff --git a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml index 06bd737821c1..4807c95a663c 100644 --- a/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/imxdi-rtc.yaml @@ -21,7 +21,6 @@ properties: - description: rtc alarm interrupt - description: dryice security violation interrupt minItems: 1 - maxItems: 2 clocks: maxItems: 1 diff --git a/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml new file mode 100644 index 000000000000..a98b72752349 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/nxp,pcf8563.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/nxp,pcf8563.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Philips PCF8563/Epson RTC8564 Real Time Clock + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + enum: + - epson,rtc8564 + - microcrystal,rv8564 + - nxp,pca8565 + - nxp,pcf8563 + - nxp,pcf85263 + - nxp,pcf85363 + + reg: + maxItems: 1 + + "#clock-cells": + const: 0 + + clock-output-names: + maxItems: 1 + + interrupts: + maxItems: 1 + + start-year: true + wakeup-source: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + rtc@51 { + compatible = "nxp,pcf8563"; + reg = <0x51>; + #clock-cells = <0>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/rtc/pcf85363.txt b/Documentation/devicetree/bindings/rtc/pcf85363.txt deleted file mode 100644 index 94adc1cf93d9..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf85363.txt +++ /dev/null @@ -1,17 +0,0 @@ -NXP PCF85263/PCF85363 Real Time Clock -============================ - -Required properties: -- compatible: Should contain "nxp,pcf85263" or "nxp,pcf85363". -- reg: I2C address for chip. - -Optional properties: -- interrupts: IRQ line for the RTC (not implemented). - -Example: - -pcf85363: pcf85363@51 { - compatible = "nxp,pcf85363"; - reg = <0x51>; -}; - diff --git a/Documentation/devicetree/bindings/rtc/pcf8563.txt b/Documentation/devicetree/bindings/rtc/pcf8563.txt deleted file mode 100644 index 0a900f7c8977..000000000000 --- a/Documentation/devicetree/bindings/rtc/pcf8563.txt +++ /dev/null @@ -1,29 +0,0 @@ -* Philips PCF8563/Epson RTC8564 Real Time Clock - -Philips PCF8563/Epson RTC8564 Real Time Clock - -Required properties: -- compatible: Should contain "nxp,pcf8563", - "epson,rtc8564" or - "microcrystal,rv8564" or - "nxp,pca8565" -- reg: I2C address for chip. - -Optional property: -- #clock-cells: Should be 0. -- clock-output-names: - overwrite the default clock name "pcf8563-clkout" - -Example: - -pcf8563: pcf8563@51 { - compatible = "nxp,pcf8563"; - reg = <0x51>; - #clock-cells = <0>; -}; - -device { -... - clocks = <&pcf8563>; -... -}; diff --git a/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml new file mode 100644 index 000000000000..bdb72d3ddf2a --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/xlnx,zynqmp-rtc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/xlnx,zynqmp-rtc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx Zynq Ultrascale+ MPSoC Real Time Clock + +description: + RTC controller for the Xilinx Zynq MPSoC Real Time Clock. + The RTC controller has separate IRQ lines for seconds and alarm. + +maintainers: + - Michal Simek <michal.simek@xilinx.com> + +allOf: + - $ref: rtc.yaml# + +properties: + compatible: + const: xlnx,zynqmp-rtc + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + + interrupt-names: + items: + - const: alarm + - const: sec + + calibration: + description: | + calibration value for 1 sec period which will + be programmed directly to calibration register. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0x1 + maximum: 0x1FFFFF + default: 0x198233 + +required: + - compatible + - reg + - interrupts + - interrupt-names + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + rtc: rtc@ffa60000 { + compatible = "xlnx,zynqmp-rtc"; + reg = <0x0 0xffa60000 0x0 0x100>; + interrupt-parent = <&gic>; + interrupts = <0 26 4>, <0 27 4>; + interrupt-names = "alarm", "sec"; + calibration = <0x198233>; + }; + }; diff --git a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt b/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt deleted file mode 100644 index 0df6f016b1b7..000000000000 --- a/Documentation/devicetree/bindings/rtc/xlnx-rtc.txt +++ /dev/null @@ -1,25 +0,0 @@ -* Xilinx Zynq Ultrascale+ MPSoC Real Time Clock - -RTC controller for the Xilinx Zynq MPSoC Real Time Clock -Separate IRQ lines for seconds and alarm - -Required properties: -- compatible: Should be "xlnx,zynqmp-rtc" -- reg: Physical base address of the controller and length - of memory mapped region. -- interrupts: IRQ lines for the RTC. -- interrupt-names: interrupt line names eg. "sec" "alarm" - -Optional: -- calibration: calibration value for 1 sec period which will - be programmed directly to calibration register - -Example: -rtc: rtc@ffa60000 { - compatible = "xlnx,zynqmp-rtc"; - reg = <0x0 0xffa60000 0x100>; - interrupt-parent = <&gic>; - interrupts = <0 26 4>, <0 27 4>; - interrupt-names = "alarm", "sec"; - calibration = <0x198233>; -}; diff --git a/Documentation/devicetree/bindings/serial/8250.yaml b/Documentation/devicetree/bindings/serial/8250.yaml index 41f57c448621..a0bf061b80fe 100644 --- a/Documentation/devicetree/bindings/serial/8250.yaml +++ b/Documentation/devicetree/bindings/serial/8250.yaml @@ -10,7 +10,7 @@ maintainers: - devicetree@vger.kernel.org allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# - if: anyOf: - required: diff --git a/Documentation/devicetree/bindings/serial/8250_omap.yaml b/Documentation/devicetree/bindings/serial/8250_omap.yaml new file mode 100644 index 000000000000..1c826fcf5828 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/8250_omap.yaml @@ -0,0 +1,118 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/8250_omap.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for 8250 compliant UARTs on TI's OMAP2+ and K3 SoCs + +maintainers: + - Vignesh Raghavendra <vigneshr@ti.com> + +allOf: + - $ref: /schemas/serial/serial.yaml# + - $ref: /schemas/serial/rs485.yaml# + +properties: + compatible: + oneOf: + - enum: + - ti,am3352-uart + - ti,am4372-uart + - ti,am654-uart + - ti,dra742-uart + - ti,omap2-uart + - ti,omap3-uart + - ti,omap4-uart + - items: + - enum: + - ti,am64-uart + - ti,j721e-uart + - const: ti,am654-uart + + ti,hwmods: + description: + Must be "uart<n>", n being the instance number (1-based) + This property is applicable only on legacy platforms mainly omap2/3 + and ti81xx and should not be used on other platforms. + $ref: /schemas/types.yaml#/definitions/string + deprecated: true + + dmas: + minItems: 1 + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + description: + First entry is module IRQ required for normal IO operation. + Second entry is optional and corresponds to system wakeup IRQ + where supported. + + clocks: + maxItems: 1 + + clock-names: + const: fclk + + rts-gpios: true + cts-gpios: true + dtr-gpios: true + dsr-gpios: true + rng-gpios: true + dcd-gpios: true + rs485-rts-delay: true + rs485-rts-active-low: true + rs485-rx-during-tx: true + rs485-rts-active-high: true + linux,rs485-enabled-at-boot-time: true + rts-gpio: true + power-domains: true + clock-frequency: true + current-speed: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + properties: + compatible: + oneOf: + - const: ti,omap2-uart + - const: ti,omap3-uart + - const: ti,omap4-uart + +then: + properties: + ti,hwmods: + items: + - pattern: "^uart([1-9])$" + +else: + properties: + ti,hwmods: false + +examples: + - | + serial@49042000 { + compatible = "ti,omap3-uart"; + reg = <0x49042000 0x400>; + interrupts = <80>; + dmas = <&sdma 81 &sdma 82>; + dma-names = "tx", "rx"; + ti,hwmods = "uart4"; + clock-frequency = <48000000>; + }; diff --git a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml index 75ebc9952a99..7487aa6ef849 100644 --- a/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml +++ b/Documentation/devicetree/bindings/serial/amlogic,meson-uart.yaml @@ -55,6 +55,11 @@ properties: - const: pclk - const: baud + fifo-size: + description: The fifo size supported by the UART channel. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [64, 128] + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml index 46c62745f901..6d176588df47 100644 --- a/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml +++ b/Documentation/devicetree/bindings/serial/brcm,bcm7271-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Al Cooper <alcooperx@gmail.com> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# description: |+ The Broadcom UART is based on the basic 8250 UART but with diff --git a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml index 2b06c6ce4a75..9d949296a142 100644 --- a/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-imx-uart.yaml @@ -71,6 +71,18 @@ properties: received, and that the peripheral should invert its input using the INVR registers. + fsl,dma-info: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + description: | + First cell contains the size of DMA buffer chunks, second cell contains + the amount of chunks used for the device. Multiplying both numbers is + the total size of memory used for receiving data. + When not being configured the system will use default settings, which + are sensible for most use cases. If you need low latency processing on + slow connections this needs to be configured appropriately. + uart-has-rtscts: true rs485-rts-delay: true diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index bd21060d26e0..a90c971b4f1f 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -36,14 +36,12 @@ properties: - description: ipg clock - description: baud clock minItems: 1 - maxItems: 2 clock-names: items: - const: ipg - const: baud minItems: 1 - maxItems: 2 dmas: items: diff --git a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml index 7748d8c3bab8..b432d4dff730 100644 --- a/Documentation/devicetree/bindings/serial/ingenic,uart.yaml +++ b/Documentation/devicetree/bindings/serial/ingenic,uart.yaml @@ -10,7 +10,7 @@ maintainers: - Paul Cercueil <paul@crapouillou.net> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: $nodename: diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt index b7e0e32b9ac6..2d0dbdf32d1d 100644 --- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt +++ b/Documentation/devicetree/bindings/serial/mvebu-uart.txt @@ -5,10 +5,10 @@ Required properties: - compatible: - "marvell,armada-3700-uart" for the standard variant of the UART (32 bytes FIFO, no DMA, level interrupts, 8-bit access to the - FIFO, baudrate limited to 230400). + FIFO), called also UART1. - "marvell,armada-3700-uart-ext" for the extended variant of the UART (128 bytes FIFO, DMA, front interrupts, 8-bit or 32-bit - accesses to the FIFO, baudrate unlimited by the dividers). + accesses to the FIFO), called also UART2. - reg: offset and length of the register set for the device. - clocks: UART reference clock used to derive the baudrate. If no clock is provided (possible only with the "marvell,armada-3700-uart" @@ -33,7 +33,7 @@ Required properties: Example: uart0: serial@12000 { compatible = "marvell,armada-3700-uart"; - reg = <0x12000 0x200>; + reg = <0x12000 0x18>; clocks = <&xtalclk>; interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, diff --git a/Documentation/devicetree/bindings/serial/omap_serial.txt b/Documentation/devicetree/bindings/serial/omap_serial.txt deleted file mode 100644 index c2db8cabf2ab..000000000000 --- a/Documentation/devicetree/bindings/serial/omap_serial.txt +++ /dev/null @@ -1,40 +0,0 @@ -OMAP UART controller - -Required properties: -- compatible : should be "ti,am64-uart", "ti,am654-uart" for AM64 controllers -- compatible : should be "ti,j721e-uart", "ti,am654-uart" for J721E controllers -- compatible : should be "ti,am654-uart" for AM654 controllers -- compatible : should be "ti,omap2-uart" for OMAP2 controllers -- compatible : should be "ti,omap3-uart" for OMAP3 controllers -- compatible : should be "ti,omap4-uart" for OMAP4 controllers -- compatible : should be "ti,am4372-uart" for AM437x controllers -- compatible : should be "ti,am3352-uart" for AM335x controllers -- compatible : should be "ti,dra742-uart" for DRA7x controllers -- reg : address and length of the register space -- interrupts or interrupts-extended : Should contain the uart interrupt - specifier or both the interrupt - controller phandle and interrupt - specifier. -- ti,hwmods : Must be "uart<n>", n being the instance number (1-based) - -Optional properties: -- clock-frequency : frequency of the clock input to the UART -- dmas : DMA specifier, consisting of a phandle to the DMA controller - node and a DMA channel number. -- dma-names : "rx" for receive channel, "tx" for transmit channel. -- rs485-rts-delay, rs485-rx-during-tx, linux,rs485-enabled-at-boot-time: see rs485.txt -- rs485-rts-active-high: drive RTS high when sending (default is low). -- clocks: phandle to the functional clock as per - Documentation/devicetree/bindings/clock/clock-bindings.txt - -Example: - - uart4: serial@49042000 { - compatible = "ti,omap3-uart"; - reg = <0x49042000 0x400>; - interrupts = <80>; - dmas = <&sdma 81 &sdma 82>; - dma-names = "tx", "rx"; - ti,hwmods = "uart4"; - clock-frequency = <48000000>; - }; diff --git a/Documentation/devicetree/bindings/serial/pl011.yaml b/Documentation/devicetree/bindings/serial/pl011.yaml index 1f8e9f2644b6..5ea00f8a283d 100644 --- a/Documentation/devicetree/bindings/serial/pl011.yaml +++ b/Documentation/devicetree/bindings/serial/pl011.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring <robh@kernel.org> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# # Need a custom select here or 'arm,primecell' will match on lots of nodes select: @@ -24,12 +24,9 @@ select: properties: compatible: - oneOf: - - items: - - const: arm,pl011 - - const: arm,primecell - - items: - - const: arm,primecell + items: + - const: arm,pl011 + - const: arm,primecell reg: maxItems: 1 @@ -103,7 +100,7 @@ dependencies: poll-rate-ms: [ auto-poll ] poll-timeout-ms: [ auto-poll ] -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml index a344369285b6..a644e5af12b2 100644 --- a/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml +++ b/Documentation/devicetree/bindings/serial/qca,ar9330-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Oleksij Rempel <o.rempel@pengutronix.de> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: @@ -35,7 +35,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml index 82aefdb0d45e..e98ec48fee46 100644 --- a/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,em-uart.yaml @@ -35,7 +35,7 @@ required: - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index 22d76829f7ae..6b8731f7f2fb 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -64,6 +64,10 @@ properties: - const: renesas,rcar-gen3-scif # R-Car Gen3 and RZ/G2 - const: renesas,scif # generic SCIF compatible UART + - items: + - enum: + - renesas,scif-r9a07g044 # RZ/G2{L,LC} + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 97ec8a093bf3..f064e5b76cf1 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -44,7 +44,6 @@ properties: clock-names: description: N = 0 is allowed for SoCs without internal baud clock mux. minItems: 2 - maxItems: 5 items: - const: uart - pattern: '^clk_uart_baud[0-3]$' @@ -82,7 +81,7 @@ required: unevaluatedProperties: false allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# - if: properties: diff --git a/Documentation/devicetree/bindings/serial/serial.yaml b/Documentation/devicetree/bindings/serial/serial.yaml index 2fdf4ed198da..c75ba3fb6465 100644 --- a/Documentation/devicetree/bindings/serial/serial.yaml +++ b/Documentation/devicetree/bindings/serial/serial.yaml @@ -23,6 +23,8 @@ properties: $nodename: pattern: "^serial(@.*)?$" + label: true + cts-gpios: maxItems: 1 description: diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml index 5fa94dacbba9..09aae43f65a7 100644 --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml @@ -12,7 +12,7 @@ maintainers: - Palmer Dabbelt <palmer@sifive.com> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: @@ -49,7 +49,7 @@ required: - interrupts - clocks -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml index 87ef1e218152..b49fda5e608f 100644 --- a/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml +++ b/Documentation/devicetree/bindings/serial/snps-dw-apb-uart.yaml @@ -10,7 +10,7 @@ maintainers: - Rob Herring <robh@kernel.org> allOf: - - $ref: /schemas/serial.yaml# + - $ref: serial.yaml# properties: compatible: @@ -23,6 +23,7 @@ properties: - items: - enum: - rockchip,px30-uart + - rockchip,rk1808-uart - rockchip,rk3036-uart - rockchip,rk3066-uart - rockchip,rk3188-uart @@ -31,6 +32,7 @@ properties: - rockchip,rk3328-uart - rockchip,rk3368-uart - rockchip,rk3399-uart + - rockchip,rk3568-uart - rockchip,rv1108-uart - const: snps,dw-apb-uart - items: diff --git a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml index 71a6426bc558..f50f4ca893a0 100644 --- a/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml +++ b/Documentation/devicetree/bindings/serial/st,stm32-uart.yaml @@ -112,8 +112,7 @@ required: - interrupts - clocks -additionalProperties: - type: object +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml new file mode 100644 index 000000000000..2cd3bc6bd8d6 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/microchip,polarfire-soc-sys-controller.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) system controller + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +description: | + The PolarFire SoC system controller is communicated with via a mailbox. + This document describes the bindings for the client portion of that mailbox. + + +properties: + mboxes: + maxItems: 1 + + compatible: + const: microchip,polarfire-soc-sys-controller + +required: + - compatible + - mboxes + +additionalProperties: false + +examples: + - | + syscontroller: syscontroller { + compatible = "microchip,polarfire-soc-sys-controller"; + mboxes = <&mbox 0>; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index 84671950ca0d..4663c2bcad50 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -164,7 +164,6 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: UART core irq - description: Wakeup irq (RX GPIO) diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt deleted file mode 100644 index 6217e64309de..000000000000 --- a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt +++ /dev/null @@ -1,65 +0,0 @@ -Texas Instruments TI-SCI Generic Power Domain ---------------------------------------------- - -Some TI SoCs contain a system controller (like the PMMC, etc...) that is -responsible for controlling the state of the IPs that are present. -Communication between the host processor running an OS and the system -controller happens through a protocol known as TI-SCI [1]. - -[1] Documentation/devicetree/bindings/arm/keystone/ti,sci.txt - -PM Domain Node -============== -The PM domain node represents the global PM domain managed by the PMMC, which -in this case is the implementation as documented by the generic PM domain -bindings in Documentation/devicetree/bindings/power/power-domain.yaml. Because -this relies on the TI SCI protocol to communicate with the PMMC it must be a -child of the pmmc node. - -Required Properties: --------------------- -- compatible: should be "ti,sci-pm-domain" -- #power-domain-cells: Can be one of the following: - 1: Containing the device id of each node - 2: First entry should be device id - Second entry should be one of the floowing: - TI_SCI_PD_EXCLUSIVE: To allow device to be - exclusively controlled by - the requesting hosts. - TI_SCI_PD_SHARED: To allow device to be shared - by multiple hosts. - -Example (K2G): -------------- - pmmc: pmmc { - compatible = "ti,k2g-sci"; - ... - - k2g_pds: power-controller { - compatible = "ti,sci-pm-domain"; - #power-domain-cells = <1>; - }; - }; - -PM Domain Consumers -=================== -Hardware blocks belonging to a PM domain should contain a "power-domains" -property that is a phandle pointing to the corresponding PM domain node -along with an index representing the device id to be passed to the PMMC -for device control. - -Required Properties: --------------------- -- power-domains: phandle pointing to the corresponding PM domain node - and an ID representing the device. - -See http://processors.wiki.ti.com/index.php/TISCI#66AK2G02_Data for the list -of valid identifiers for k2g. - -Example (K2G): --------------------- - uart0: serial@2530c00 { - compatible = "ns16550a"; - ... - power-domains = <&k2g_pds 0x002c>; - }; diff --git a/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml new file mode 100644 index 000000000000..9e6cb4ee9755 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/ti/sci-pm-domain.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI-SCI generic power domain node bindings + +maintainers: + - Nishanth Menon <nm@ti.com> + +allOf: + - $ref: /schemas/power/power-domain.yaml# + +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 PM domain node represents the global PM domain managed by the TI-SCI + controller. Since this relies on the TI SCI protocol to communicate with + the TI-SCI controller, it must be a child of the TI-SCI controller node. + +properties: + compatible: + const: ti,sci-pm-domain + + "#power-domain-cells": + enum: [1, 2] + description: + The two cells represent values that the TI-SCI controller defines. + + The first cell should contain the device ID. + + The second cell, if cell-value is 2, should be one of the following + TI_SCI_PD_EXCLUSIVE - Allows the device to be exclusively controlled + or + TI_SCI_PD_SHARED - Allows the device to be shared by multiple hosts. + Please refer to dt-bindings/soc/ti,sci_pm_domain.h for the definitions. + + 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: + - | + k2g_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <1>; + }; + + - | + k3_pds: power-controller { + compatible = "ti,sci-pm-domain"; + #power-domain-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index dbc62821c60b..9790617af1bc 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -100,7 +100,6 @@ patternProperties: properties: reg: minItems: 2 # On AM437x one of two PRUSS units don't contain Shared RAM. - maxItems: 3 items: - description: Address and size of the Data RAM0. - description: Address and size of the Data RAM1. @@ -111,7 +110,6 @@ patternProperties: reg-names: minItems: 2 - maxItems: 3 items: - const: dram0 - const: dram1 diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml index 67405e6d8168..19f111f40225 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun8i-a33-codec.yaml @@ -12,7 +12,11 @@ maintainers: properties: "#sound-dai-cells": - const: 0 + minimum: 0 + maximum: 1 + description: + A value of 0 is deprecated. When used, it only allows access to + the ADC/DAC and AIF1 (the CPU DAI), not the other two AIFs/DAIs. compatible: oneOf: @@ -50,7 +54,7 @@ additionalProperties: false examples: - | audio-codec@1c22e00 { - #sound-dai-cells = <0>; + #sound-dai-cells = <1>; compatible = "allwinner,sun8i-a33-codec"; reg = <0x01c22e00 0x400>; interrupts = <0 29 4>; diff --git a/Documentation/devicetree/bindings/sound/cs42l42.txt b/Documentation/devicetree/bindings/sound/cs42l42.txt index 7dfaa2ab906f..5d416fdaf023 100644 --- a/Documentation/devicetree/bindings/sound/cs42l42.txt +++ b/Documentation/devicetree/bindings/sound/cs42l42.txt @@ -81,6 +81,13 @@ Optional properties: < x1 x2 x3 x4 > Default = < 15 8 4 1> + - cirrus,hs-bias-sense-disable: This is boolean property. If present the + HSBIAS sense is disabled. Configures HSBIAS output current sense through + the external 2.21-k resistor. HSBIAS_SENSE is hardware feature to reduce + the potential pop noise during the headset plug out slowly. But on some + platforms ESD voltage will affect it causing test to fail, especially + with CTIA headset type. For different hardware setups, a designer might + want to tweak default behavior. Example: diff --git a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml index 4454aca34d56..f226ec13167a 100644 --- a/Documentation/devicetree/bindings/sound/fsl,spdif.yaml +++ b/Documentation/devicetree/bindings/sound/fsl,spdif.yaml @@ -25,6 +25,7 @@ properties: - fsl,imx8mq-spdif - fsl,imx8mm-spdif - fsl,imx8mn-spdif + - fsl,imx8ulp-spdif reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/fsl-sai.txt b/Documentation/devicetree/bindings/sound/fsl-sai.txt index 0dc83cc4a236..c71c5861d787 100644 --- a/Documentation/devicetree/bindings/sound/fsl-sai.txt +++ b/Documentation/devicetree/bindings/sound/fsl-sai.txt @@ -9,8 +9,10 @@ Required properties: - compatible : Compatible list, contains "fsl,vf610-sai", "fsl,imx6sx-sai", "fsl,imx6ul-sai", - "fsl,imx7ulp-sai", "fsl,imx8mq-sai" or - "fsl,imx8qm-sai". + "fsl,imx7ulp-sai", "fsl,imx8mq-sai", + "fsl,imx8qm-sai", "fsl,imx8mm-sai", + "fsl,imx8mn-sai", "fsl,imx8mp-sai", or + "fsl,imx8ulp-sai". - reg : Offset and length of the register set for the device. diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml new file mode 100644 index 000000000000..d1816dd061cf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audio-card.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX audio sound card. + +maintainers: + - Shengjiu Wang <shengjiu.wang@nxp.com> + +properties: + compatible: + enum: + - fsl,imx-audio-card + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + audio-routing: + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + description: + A list of the connections between audio components. Each entry is a + pair of strings, the first being the connection's sink, the second + being the connection's source. Valid names could be power supplies, + MicBias of codec and the jacks on the board. + +patternProperties: + ".*-dai-link$": + description: + Each subnode represents a dai link. Subnodes of each dai links would be + cpu/codec dais. + + type: object + + properties: + link-name: + description: Indicates dai-link name and PCM stream name. + $ref: /schemas/types.yaml#/definitions/string + maxItems: 1 + + format: + description: audio format. + items: + enum: + - i2s + - dsp_b + + dai-tdm-slot-num: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + dai-tdm-slot-width: + description: see tdm-slot.txt. + $ref: /schemas/types.yaml#/definitions/uint32 + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + fsl,mclk-equal-bclk: + description: Indicates mclk can be equal to bclk, especially for sai interface + $ref: /schemas/types.yaml#/definitions/flag + + required: + - link-name + - cpu + + additionalProperties: false + +required: + - compatible + - model + +additionalProperties: false + +examples: + - | + sound-ak4458 { + compatible = "fsl,imx-audio-card"; + model = "ak4458-audio"; + pri-dai-link { + link-name = "akcodec"; + format = "i2s"; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + fe-dai-link { + link-name = "HiFi-ASRC-FE"; + format = "i2s"; + cpu { + sound-dai = <&easrc>; + }; + }; + be-dai-link { + link-name = "HiFi-ASRC-BE"; + format = "dsp_b"; + dai-tdm-slot-num = <8>; + dai-tdm-slot-width = <32>; + fsl,mclk-equal-bclk; + cpu { + sound-dai = <&sai1>; + }; + codec { + sound-dai = <&ak4458_1>, <&ak4458_2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.txt b/Documentation/devicetree/bindings/sound/imx-audmux.txt deleted file mode 100644 index 2db4dcbee1b9..000000000000 --- a/Documentation/devicetree/bindings/sound/imx-audmux.txt +++ /dev/null @@ -1,28 +0,0 @@ -Freescale Digital Audio Mux (AUDMUX) device - -Required properties: - - - compatible : "fsl,imx21-audmux" for AUDMUX version firstly used - on i.MX21, or "fsl,imx31-audmux" for the version - firstly used on i.MX31. - - - reg : Should contain AUDMUX registers location and length. - -An initial configuration can be setup using child nodes. - -Required properties of optional child nodes: - - - fsl,audmux-port : Integer of the audmux port that is configured by this - child node. - - - fsl,port-config : List of configuration options for the specific port. - For imx31-audmux and above, it is a list of tuples - <ptcr pdcr>. For imx21-audmux it is a list of pcr - values. - -Example: - -audmux@21d8000 { - compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; - reg = <0x021d8000 0x4000>; -}; diff --git a/Documentation/devicetree/bindings/sound/imx-audmux.yaml b/Documentation/devicetree/bindings/sound/imx-audmux.yaml new file mode 100644 index 000000000000..dab45c310670 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/imx-audmux.yaml @@ -0,0 +1,119 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/imx-audmux.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Digital Audio Mux device + +maintainers: + - Oleksij Rempel <o.rempel@pengutronix.de> + +properties: + compatible: + oneOf: + - items: + - enum: + - fsl,imx27-audmux + - const: fsl,imx21-audmux + - items: + - enum: + - fsl,imx25-audmux + - fsl,imx35-audmux + - fsl,imx50-audmux + - fsl,imx51-audmux + - fsl,imx53-audmux + - fsl,imx6q-audmux + - fsl,imx6sl-audmux + - fsl,imx6sll-audmux + - fsl,imx6sx-audmux + - const: fsl,imx31-audmux + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: audmux + +patternProperties: + "^mux-[0-9a-z]*$": + type: object + properties: + fsl,audmux-port: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Integer of the audmux port that is configured by this child node + + fsl,port-config: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + List of configuration options for the specific port. + For imx31-audmux and above, it is a list of tuples ptcr pdcr. + For imx21-audmux it is a list of pcr values. + + required: + - fsl,audmux-port + - fsl,port-config + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + }; + - | + audmux@10016000 { + compatible = "fsl,imx27-audmux", "fsl,imx21-audmux"; + reg = <0x10016000 0x1000>; + clocks = <&clks 1>; + clock-names = "audmux"; + + mux-ssi0 { + fsl,audmux-port = <0>; + fsl,port-config = <0xcb205000>; + }; + + mux-pins4 { + fsl,audmux-port = <2>; + fsl,port-config = <0x00001000>; + }; + }; + - | + #include <dt-bindings/sound/fsl-imx-audmux.h> + audmux@21d8000 { + compatible = "fsl,imx6q-audmux", "fsl,imx31-audmux"; + reg = <0x021d8000 0x4000>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_audmux>; + + mux-ssi1 { + fsl,audmux-port = <0>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN 0 + IMX_AUDMUX_V2_PTCR_TFSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TCSEL(2) 0 + IMX_AUDMUX_V2_PTCR_TFSDIR 0 + IMX_AUDMUX_V2_PTCR_TCLKDIR IMX_AUDMUX_V2_PDCR_RXDSEL(2) + >; + }; + + mux-pins3 { + fsl,audmux-port = <2>; + fsl,port-config = < + IMX_AUDMUX_V2_PTCR_SYN IMX_AUDMUX_V2_PDCR_RXDSEL(0) + 0 IMX_AUDMUX_V2_PDCR_TXRXEN + >; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml index 249970952202..5bdd30a8a404 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra-audio-graph-card.yaml @@ -28,7 +28,6 @@ properties: minItems: 2 clock-names: - minItems: 2 items: - const: pll_a - const: plla_out0 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index 38e52e7dbb40..63370709c768 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -34,7 +34,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: I2S bit clock - description: @@ -48,7 +47,6 @@ properties: clock-names: minItems: 1 - maxItems: 2 items: - const: i2s - const: sync_input diff --git a/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml new file mode 100644 index 000000000000..ffb8fcfeb629 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/nxp,tfa989x.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/nxp,tfa989x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP/Goodix TFA989X (TFA1) Audio Amplifiers + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +properties: + compatible: + enum: + - nxp,tfa9895 + - nxp,tfa9897 + + reg: + maxItems: 1 + + '#sound-dai-cells': + const: 0 + + sound-name-prefix: + $ref: /schemas/types.yaml#/definitions/string + description: + Used as prefix for sink/source names of the component. Must be a + unique string among multiple instances of the same component. + + vddd-supply: + description: regulator phandle for the VDDD power supply. + +required: + - compatible + - reg + - '#sound-dai-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + audio-codec@34 { + compatible = "nxp,tfa9895"; + reg = <0x34>; + sound-name-prefix = "Speaker Left"; + #sound-dai-cells = <0>; + }; + audio-codec@36 { + compatible = "nxp,tfa9895"; + reg = <0x36>; + sound-name-prefix = "Speaker Right"; + #sound-dai-cells = <0>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml index e8f716b5f875..9b225dbf8b79 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd934x.yaml @@ -77,6 +77,31 @@ properties: minimum: 1800000 maximum: 2850000 + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + clock-output-names: const: mclk @@ -159,6 +184,11 @@ examples: qcom,micbias2-microvolt = <1800000>; qcom,micbias3-microvolt = <1800000>; qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headset-vthreshold-microvolt = <1700000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; clock-names = "extclk"; clocks = <&rpmhcc 2>; diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml new file mode 100644 index 000000000000..49a267b306f6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x-sdw.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x-sdw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm SoundWire Slave devices on WCD9380/WCD9385 + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. This bindings is for the + slave devices. + +properties: + compatible: + const: sdw20217010d00 + + reg: + maxItems: 1 + + qcom,tx-port-mapping: + description: | + Specifies static port mapping between slave and master tx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 4 + maxItems: 4 + + qcom,rx-port-mapping: + description: | + Specifies static port mapping between slave and master rx ports. + In the order of slave port index. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 5 + maxItems: 5 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml new file mode 100644 index 000000000000..cb74ce40c2e6 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/qcom,wcd938x.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Qualcomm WCD9380/WCD9385 Audio Codec + +maintainers: + - Srinivas Kandagatla <srinivas.kandagatla@linaro.org> + +description: | + Qualcomm WCD9380/WCD9385 Codec is a standalone Hi-Fi audio codec IC. + It has RX and TX Soundwire slave devices. + +properties: + compatible: + enum: + - qcom,wcd9380-codec + - qcom,wcd9385-codec + + reset-gpios: + description: GPIO spec for reset line to use + maxItems: 1 + + vdd-buck-supply: + description: A reference to the 1.8V buck supply + + vdd-rxtx-supply: + description: A reference to the 1.8V rx supply + + vdd-io-supply: + description: A reference to the 1.8V I/O supply + + qcom,tx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire tx device phandle + + qcom,rx-device: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A reference to Soundwire rx device phandle + + qcom,micbias1-microvolt: + description: micbias1 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias2-microvolt: + description: micbias2 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias3-microvolt: + description: micbias3 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,micbias4-microvolt: + description: micbias4 voltage + minimum: 1800000 + maximum: 2850000 + + qcom,hphl-jack-type-normally-closed: + description: Indicates that HPHL jack switch type is normally closed + type: boolean + + qcom,ground-jack-type-normally-closed: + description: Indicates that Headset Ground switch type is normally closed + type: boolean + + qcom,mbhc-headset-vthreshold-microvolt: + description: Voltage threshold value for headset detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-headphone-vthreshold-microvolt: + description: Voltage threshold value for headphone detection + minimum: 0 + maximum: 2850000 + + qcom,mbhc-buttons-vthreshold-microvolt: + description: + Array of 8 Voltage threshold values corresponding to headset + button0 - button7 + minItems: 8 + maxItems: 8 + + '#sound-dai-cells': + const: 1 + +required: + - compatible + - reset-gpios + - qcom,tx-device + - qcom,rx-device + - qcom,micbias1-microvolt + - qcom,micbias2-microvolt + - qcom,micbias3-microvolt + - qcom,micbias4-microvolt + - "#sound-dai-cells" + +additionalProperties: false + +examples: + - | + codec { + compatible = "qcom,wcd9380-codec"; + reset-gpios = <&tlmm 32 0>; + #sound-dai-cells = <1>; + qcom,tx-device = <&wcd938x_tx>; + qcom,rx-device = <&wcd938x_rx>; + qcom,micbias1-microvolt = <1800000>; + qcom,micbias2-microvolt = <1800000>; + qcom,micbias3-microvolt = <1800000>; + qcom,micbias4-microvolt = <1800000>; + qcom,hphl-jack-type-normally-closed; + qcom,ground-jack-type-normally-closed; + qcom,mbhc-buttons-vthreshold-microvolt = <75000 150000 237000 500000 500000 500000 500000 500000>; + qcom,mbhc-headphone-vthreshold-microvolt = <50000>; + }; + + /* ... */ + + soundwire@3210000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03210000 0x2000>; + wcd938x_rx: codec@0,4 { + compatible = "sdw20217010d00"; + reg = <0 4>; + qcom,rx-port-mapping = <1 2 3 4 5>; + }; + }; + + soundwire@3230000 { + #address-cells = <2>; + #size-cells = <0>; + reg = <0x03230000 0x2000>; + wcd938x_tx: codec@0,3 { + compatible = "sdw20217010d00"; + reg = <0 3>; + qcom,tx-port-mapping = <2 3 4 5>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index 605de3a5847f..ee936d1aa724 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -86,9 +86,11 @@ properties: power-domains: true resets: + minItems: 1 maxItems: 11 reset-names: + minItems: 1 maxItems: 11 clocks: @@ -110,6 +112,13 @@ properties: - pattern: '^dvc\.[0-1]$' - pattern: '^clk_(a|b|c|i)$' + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port(@[0-9a-f]+)?: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + port: $ref: audio-graph-port.yaml# unevaluatedProperties: false @@ -257,7 +266,6 @@ required: - "#sound-dai-cells" allOf: - - $ref: audio-graph.yaml# - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/sound/sgtl5000.yaml b/Documentation/devicetree/bindings/sound/sgtl5000.yaml index 70b4a8831073..e762c320b574 100644 --- a/Documentation/devicetree/bindings/sound/sgtl5000.yaml +++ b/Documentation/devicetree/bindings/sound/sgtl5000.yaml @@ -75,6 +75,10 @@ properties: $ref: "/schemas/types.yaml#/definitions/uint32" enum: [ 0, 1, 2, 3 ] + port: + $ref: audio-graph-port.yaml# + unevaluatedProperties: false + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index f2443b651282..06e83461705c 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -26,7 +26,6 @@ properties: - description: Base address and size of SAI common register set. - description: Base address and size of SAI identification register set. minItems: 1 - maxItems: 2 ranges: maxItems: 1 @@ -81,14 +80,12 @@ patternProperties: - description: sai_ck clock feeding the internal clock generator. - description: MCLK clock from a SAI set as master clock provider. minItems: 1 - maxItems: 2 clock-names: items: - const: sai_ck - const: MCLK minItems: 1 - maxItems: 2 dmas: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt index ca75890f0d07..f59125bc79d1 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic32x4.txt @@ -6,6 +6,7 @@ Required properties: - compatible - "string" - One of: "ti,tlv320aic32x4" TLV320AIC3204 "ti,tlv320aic32x6" TLV320AIC3206, TLV320AIC3256 + "ti,tas2505" TAS2505, TAS2521 - reg: I2C slave address - supply-*: Required supply regulators are: "iov" - digital IO power supply diff --git a/Documentation/devicetree/bindings/sound/wm8750.txt b/Documentation/devicetree/bindings/sound/wm8750.txt deleted file mode 100644 index 682f221f6f38..000000000000 --- a/Documentation/devicetree/bindings/sound/wm8750.txt +++ /dev/null @@ -1,18 +0,0 @@ -WM8750 and WM8987 audio CODECs - -These devices support both I2C and SPI (configured with pin strapping -on the board). - -Required properties: - - - compatible : "wlf,wm8750" or "wlf,wm8987" - - - reg : the I2C address of the device for I2C, the chip select - number for SPI. - -Example: - -wm8750: codec@1a { - compatible = "wlf,wm8750"; - reg = <0x1a>; -}; diff --git a/Documentation/devicetree/bindings/sound/wm8750.yaml b/Documentation/devicetree/bindings/sound/wm8750.yaml new file mode 100644 index 000000000000..24246ac7bbdf --- /dev/null +++ b/Documentation/devicetree/bindings/sound/wm8750.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/wm8750.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WM8750 and WM8987 audio CODECs + +description: | + These devices support both I2C and SPI (configured with pin strapping + on the board). + +maintainers: + - Mark Brown <broonie@kernel.org> + +properties: + compatible: + enum: + - wlf,wm8750 + - wlf,wm8987 + + reg: + description: + The I2C address of the device for I2C, the chip select number for SPI + maxItems: 1 + +additionalProperties: false + +required: + - reg + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + codec@1a { + compatible = "wlf,wm8750"; + reg = <0x1a>; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml index e3fb553d9180..4d46c49ec32b 100644 --- a/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml +++ b/Documentation/devicetree/bindings/spi/amlogic,meson-gx-spicc.yaml @@ -35,7 +35,6 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: controller register bus clock - description: baud rate generator and delay control clock diff --git a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml index 6ee19d49fd3c..ec5873919170 100644 --- a/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/brcm,spi-bcm-qspi.yaml @@ -56,7 +56,6 @@ properties: reg-names: minItems: 1 - maxItems: 5 items: - const: mspi - const: bspi @@ -71,7 +70,6 @@ properties: interrupt-names: oneOf: - minItems: 1 - maxItems: 7 items: - const: mspi_done - const: mspi_halted diff --git a/Documentation/devicetree/bindings/spi/spi-davinci.txt b/Documentation/devicetree/bindings/spi/spi-davinci.txt index e2198a389484..200c7fc7b089 100644 --- a/Documentation/devicetree/bindings/spi/spi-davinci.txt +++ b/Documentation/devicetree/bindings/spi/spi-davinci.txt @@ -25,7 +25,7 @@ Required properties: - interrupts: interrupt number mapped to CPU. - clocks: spi clk phandle For 66AK2G this property should be set per binding, - Documentation/devicetree/bindings/clock/ti,sci-clk.txt + Documentation/devicetree/bindings/clock/ti,sci-clk.yaml SoC-specific Required Properties: diff --git a/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml new file mode 100644 index 000000000000..f882903769f9 --- /dev/null +++ b/Documentation/devicetree/bindings/spmi/hisilicon,hisi-spmi-controller.yaml @@ -0,0 +1,73 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spmi/hisilicon,hisi-spmi-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon SPMI controller + +maintainers: + - Mauro Carvalho Chehab <mchehab+huawei@kernel.org> + +description: | + The HiSilicon SPMI BUS controller is found on some Kirin-based designs. + It is a MIPI System Power Management (SPMI) controller. + + The PMIC part is provided by + ./Documentation/devicetree/bindings/mfd/hisilicon,hi6421-spmi-pmic.yaml. + +allOf: + - $ref: spmi.yaml# + +properties: + + $nodename: + pattern: "spmi@[0-9a-f]" + + compatible: + const: hisilicon,kirin970-spmi-controller + + reg: + maxItems: 1 + + hisilicon,spmi-channel: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + number of the Kirin 970 SPMI channel where the SPMI devices are connected. + +required: + - compatible + - reg + - hisilicon,spmi-channel + +patternProperties: + "@[0-9a-f]$": + type: object + + description: | + PMIC properties, which are specific to the used SPMI PMIC device(s). + When used in combination with HiSilicon 6421v600, the properties + are documented at + drivers/staging/hikey9xx/hisilicon,hi6421-spmi-pmic.yaml. + +unevaluatedProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + spmi: spmi@fff24000 { + compatible = "hisilicon,kirin970-spmi-controller"; + #address-cells = <2>; + #size-cells = <0>; + reg = <0x0 0xfff24000 0x0 0x1000>; + hisilicon,spmi-channel = <2>; + + pmic@0 { + reg = <0 0>; + /* pmic properties */ + }; + }; + }; diff --git a/Documentation/devicetree/bindings/spmi/spmi.yaml b/Documentation/devicetree/bindings/spmi/spmi.yaml index 173940930719..1d243faef2f8 100644 --- a/Documentation/devicetree/bindings/spmi/spmi.yaml +++ b/Documentation/devicetree/bindings/spmi/spmi.yaml @@ -40,14 +40,15 @@ patternProperties: properties: reg: - minItems: 1 - maxItems: 2 items: - - minimum: 0 - maximum: 0xf - - enum: [ 0 ] - description: | - 0 means user ID address. 1 is reserved for group ID address. + - minItems: 1 + items: + - minimum: 0 + maximum: 0xf + - enum: [ 0 ] + description: + 0 means user ID address. 1 is reserved for group ID + address. required: - reg diff --git a/Documentation/devicetree/bindings/sram/sram.yaml b/Documentation/devicetree/bindings/sram/sram.yaml index c1a5afa73cfe..3eda5049d183 100644 --- a/Documentation/devicetree/bindings/sram/sram.yaml +++ b/Documentation/devicetree/bindings/sram/sram.yaml @@ -28,6 +28,8 @@ properties: contains: enum: - mmio-sram + - amlogic,meson-gxbb-sram + - arm,juno-sram-ns - atmel,sama5d2-securam - rockchip,rk3288-pmu-sram @@ -80,6 +82,9 @@ patternProperties: - amlogic,meson8b-smp-sram - amlogic,meson-gxbb-scp-shmem - amlogic,meson-axg-scp-shmem + - arm,juno-scp-shmem + - arm,scmi-shmem + - arm,scp-shmem - renesas,smp-sram - rockchip,rk3066-smp-sram - samsung,exynos4210-sysram diff --git a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml index bf97d1fb33e7..6e0b110153b0 100644 --- a/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml +++ b/Documentation/devicetree/bindings/thermal/allwinner,sun8i-a83t-ths.yaml @@ -23,14 +23,12 @@ properties: clocks: minItems: 1 - maxItems: 2 items: - description: Bus Clock - description: Module Clock clock-names: minItems: 1 - maxItems: 2 items: - const: bus - const: mod diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index 0242fd91b622..0b3b6af7bd5b 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -77,7 +77,6 @@ properties: nvmem-cell-names: minItems: 1 - maxItems: 2 items: - const: calib - enum: diff --git a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml index b6a6d03a08b2..2ecac754e1cd 100644 --- a/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml +++ b/Documentation/devicetree/bindings/timer/allwinner,sun5i-a13-hstimer.yaml @@ -24,7 +24,6 @@ properties: interrupts: minItems: 2 - maxItems: 4 items: - description: Timer 0 Interrupt - description: Timer 1 Interrupt diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml index 7f5e3af58255..df8ce87fd54b 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer.yaml @@ -35,7 +35,6 @@ properties: interrupts: minItems: 1 - maxItems: 5 items: - description: secure timer irq - description: non-secure timer irq diff --git a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml index d83a1f97f911..cd2176cad53a 100644 --- a/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml +++ b/Documentation/devicetree/bindings/timer/arm,arch_timer_mmio.yaml @@ -71,14 +71,12 @@ patternProperties: interrupts: minItems: 1 - maxItems: 2 items: - description: physical timer irq - description: virtual timer irq reg: minItems: 1 - maxItems: 2 items: - description: 1st view base address - description: 2nd optional view base address diff --git a/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml new file mode 100644 index 000000000000..5684df6448ef --- /dev/null +++ b/Documentation/devicetree/bindings/timer/arm,twd-timer.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/arm,twd-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Timer + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-timer + - arm,cortex-a5-twd-timer + - arm,arm11mp-twd-timer + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + always-on: + description: + If present, the timer is powered through an always-on power domain, + therefore it never loses context. + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + timer@2c000600 { + compatible = "arm,arm11mp-twd-timer"; + reg = <0x2c000600 0x20>; + interrupts = <GIC_PPI 13 0xf01>; + }; diff --git a/Documentation/devicetree/bindings/timer/arm,twd.txt b/Documentation/devicetree/bindings/timer/arm,twd.txt deleted file mode 100644 index 383ea19c2bf0..000000000000 --- a/Documentation/devicetree/bindings/timer/arm,twd.txt +++ /dev/null @@ -1,53 +0,0 @@ -* ARM Timer Watchdog - -ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core -Timer-Watchdog (aka TWD), which provides both a per-cpu local timer -and watchdog. - -The TWD is usually attached to a GIC to deliver its two per-processor -interrupts. - -** Timer node required properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-timer" - "arm,cortex-a5-twd-timer" - "arm,arm11mp-twd-timer" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD timer - register window. - -Optional - -- always-on : a boolean property. If present, the timer is powered through - an always-on power domain, therefore it never loses context. - -Example: - - twd-timer@2c000600 { - compatible = "arm,arm11mp-twd-timer""; - reg = <0x2c000600 0x20>; - interrupts = <1 13 0xf01>; - }; - -** Watchdog node properties: - -- compatible : Should be one of: - "arm,cortex-a9-twd-wdt" - "arm,cortex-a5-twd-wdt" - "arm,arm11mp-twd-wdt" - -- interrupts : One interrupt to each core - -- reg : Specify the base address and the size of the TWD watchdog - register window. - -Example: - - twd-watchdog@2c000620 { - compatible = "arm,arm11mp-twd-wdt"; - reg = <0x2c000620 0x20>; - interrupts = <1 14 0xf01>; - }; diff --git a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml index a8de99b0c0f9..f32575d4b5aa 100644 --- a/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml +++ b/Documentation/devicetree/bindings/timer/intel,ixp4xx-timer.yaml @@ -22,7 +22,6 @@ properties: interrupts: minItems: 1 - maxItems: 2 items: - description: Timer 1 interrupt - description: Timer 2 interrupt diff --git a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml index f0f0f121c355..c57169118b68 100644 --- a/Documentation/devicetree/bindings/timer/renesas,tmu.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,tmu.yaml @@ -36,6 +36,7 @@ properties: - renesas,tmu-r8a77980 # R-Car V3H - renesas,tmu-r8a77990 # R-Car E3 - renesas,tmu-r8a77995 # R-Car D3 + - renesas,tmu-r8a779a0 # R-Car V3U - const: renesas,tmu reg: diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.txt b/Documentation/devicetree/bindings/timer/renesas,tpu.txt deleted file mode 100644 index 1d46f9de4feb..000000000000 --- a/Documentation/devicetree/bindings/timer/renesas,tpu.txt +++ /dev/null @@ -1,21 +0,0 @@ -* Renesas H8/300 Timer Pulse Unit - -The TPU is a 16bit timer/counter with configurable clock inputs and -programmable compare match. -This implementation support only cascade mode. - -Required Properties: - - - compatible: must contain "renesas,tpu" - - reg: base address and length of the registers block in 2 channel. - - clocks: a list of phandle, one for each entry in clock-names. - - clock-names: must contain "peripheral_clk" for the functional clock. - - -Example: - tpu: tpu@ffffe0 { - compatible = "renesas,tpu"; - reg = <0xffffe0 16>, <0xfffff0 12>; - clocks = <&pclk>; - clock-names = "peripheral_clk"; - }; diff --git a/Documentation/devicetree/bindings/timer/renesas,tpu.yaml b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml new file mode 100644 index 000000000000..01554dff23d8 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/renesas,tpu.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/renesas,tpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Renesas H8/300 Timer Pulse Unit + +maintainers: + - Yoshinori Sato <ysato@users.sourceforge.jp> + +description: + The TPU is a 16bit timer/counter with configurable clock inputs and + programmable compare match. + This implementation supports only cascade mode. + +select: + properties: + compatible: + contains: + const: renesas,tpu + '#pwm-cells': false + required: + - compatible + +properties: + compatible: + const: renesas,tpu + + reg: + items: + - description: First channel + - description: Second channel + + clocks: + maxItems: 1 + + clock-names: + const: fck + +required: + - compatible + - reg + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + tpu: tpu@ffffe0 { + compatible = "renesas,tpu"; + reg = <0xffffe0 16>, <0xfffff0 12>; + clocks = <&pclk>; + clock-names = "fck"; + }; diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 37ac0a3ae3b4..919a4bf03a5a 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -177,8 +177,14 @@ properties: - meas,tsys01 # MEMSIC magnetometer - memsic,mmc35240 + # MEMSIC 3-axis accelerometer + - memsic,mx4005 # MEMSIC 2-axis 8-bit digital accelerometer - memsic,mxc6225 + # MEMSIC 2-axis 8-bit digital accelerometer + - memsic,mxc6255 + # MEMSIC 3-axis accelerometer + - memsic,mxc6655 # Microchip differential I2C ADC, 1 Channel, 18 bit - microchip,mcp3421 # Microchip differential I2C ADC, 2 Channel, 18 bit @@ -263,6 +269,10 @@ properties: - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface - sensirion,sgp30 + # Sensortek 3 axis accelerometer + - sensortek,stk8312 + # Sensortek 3 axis accelerometer + - sensortek,stk8ba50 # SGX Sensortech VZ89X Sensors - sgx,vz89x # Relative Humidity and Temperature Sensors @@ -272,6 +282,8 @@ properties: # Socionext SynQuacer TPM MMIO module - socionext,synquacer-tpm-mmio # i2c serial eeprom (24cxx) + - sparkfun,qwiic-joystick + # SparkFun Qwiic Joystick (COM-15168) with i2c interface - st,24c256 # Ambient Light Sensor with SMBUS/Two Wire Serial Interface - taos,tsl2550 diff --git a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml index 0f520f17735e..933fa356d2ce 100644 --- a/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml +++ b/Documentation/devicetree/bindings/usb/allwinner,sun4i-a10-musb.yaml @@ -22,6 +22,9 @@ properties: - allwinner,sun8i-a83t-musb - allwinner,sun50i-h6-musb - const: allwinner,sun8i-a33-musb + - items: + - const: allwinner,sun50i-h616-musb + - const: allwinner,sun8i-h3-musb reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml index a407e1143cf4..dc9d6ed0781d 100644 --- a/Documentation/devicetree/bindings/usb/cdns,usb3.yaml +++ b/Documentation/devicetree/bindings/usb/cdns,usb3.yaml @@ -28,9 +28,9 @@ properties: interrupts: minItems: 3 items: - - description: OTG/DRD controller interrupt - description: XHCI host controller interrupt - description: Device controller interrupt + - description: OTG/DRD controller interrupt - description: interrupt used to wake up core, e.g when usbcmd.rs is cleared by xhci core, this interrupt is optional @@ -75,6 +75,7 @@ required: - reg - reg-names - interrupts + - interrupt-names additionalProperties: false diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index e5ee51b7b470..10c7d9b6cc53 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -24,6 +24,7 @@ properties: - rockchip,rk3188-usb - rockchip,rk3228-usb - rockchip,rk3288-usb + - rockchip,rk3308-usb - rockchip,rk3328-usb - rockchip,rk3368-usb - rockchip,rv1108-usb diff --git a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml index 4241d38d5864..1d893d3d3432 100644 --- a/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml +++ b/Documentation/devicetree/bindings/usb/maxim,max3420-udc.yaml @@ -30,14 +30,12 @@ properties: - description: usb irq from max3420 - description: vbus detection irq minItems: 1 - maxItems: 2 interrupt-names: items: - const: udc - const: vbus minItems: 1 - maxItems: 2 spi-max-frequency: maximum: 26000000 diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index e60e590dbe12..8428415896ce 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -25,7 +25,6 @@ properties: reg: minItems: 2 - maxItems: 3 items: - description: XUSB device controller registers - description: XUSB device PCI Config registers @@ -33,7 +32,6 @@ properties: reg-names: minItems: 2 - maxItems: 3 items: - const: base - const: fpci @@ -45,7 +43,6 @@ properties: clocks: minItems: 4 - maxItems: 5 items: - description: Clock to enable core XUSB dev clock. - description: Clock to enable XUSB super speed clock. @@ -55,7 +52,6 @@ properties: clock-names: minItems: 4 - maxItems: 5 items: - const: dev - const: ss diff --git a/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml new file mode 100644 index 000000000000..a88f99adfe8e --- /dev/null +++ b/Documentation/devicetree/bindings/usb/nxp,isp1760.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/nxp,isp1760.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP ISP1760 family controller bindings + +maintainers: + - Sebastian Siewior <bigeasy@linutronix.de> + - Laurent Pinchart <laurent.pinchart@ideasonboard.com> + +description: | + NXP ISP1760 family, which includes ISP1760/1761/1763 devicetree controller + bindings + +properties: + compatible: + enum: + - nxp,usb-isp1760 + - nxp,usb-isp1761 + - nxp,usb-isp1763 + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + items: + - description: Host controller interrupt + - description: Device controller interrupt in isp1761 + + interrupt-names: + minItems: 1 + maxItems: 2 + items: + - const: host + - const: peripheral + + bus-width: + description: + Number of data lines. + enum: [8, 16, 32] + default: 32 + + dr_mode: + enum: + - host + - peripheral + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + usb@40200000 { + compatible = "nxp,usb-isp1763"; + reg = <0x40200000 0x100000>; + interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH>; + bus-width = <16>; + dr_mode = "host"; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 413299b5fe2b..4e6451789806 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -19,6 +19,8 @@ properties: - qcom,sc7280-dwc3 - qcom,sdm845-dwc3 - qcom,sdx55-dwc3 + - qcom,sm4250-dwc3 + - qcom,sm6115-dwc3 - qcom,sm8150-dwc3 - qcom,sm8250-dwc3 - qcom,sm8350-dwc3 diff --git a/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml new file mode 100644 index 000000000000..04ee255eb4f0 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/realtek,rts5411.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/realtek,rts5411.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for the Realtek RTS5411 USB 3.0 hub controller + +maintainers: + - Matthias Kaehlcke <mka@chromium.org> + +allOf: + - $ref: usb-device.yaml# + +properties: + compatible: + items: + - enum: + - usbbda,5411 + - usbbda,411 + + reg: true + + vdd-supply: + description: + phandle to the regulator that provides power to the hub. + + companion-hub: + $ref: '/schemas/types.yaml#/definitions/phandle' + description: + phandle to the companion hub on the controller. + +required: + - companion-hub + - compatible + - reg + +additionalProperties: false + +examples: + - | + usb { + dr_mode = "host"; + #address-cells = <1>; + #size-cells = <0>; + + /* 2.0 hub on port 1 */ + hub_2_0: hub@1 { + compatible = "usbbda,5411"; + reg = <1>; + vdd-supply = <&pp3300_hub>; + companion-hub = <&hub_3_0>; + }; + + /* 3.0 hub on port 2 */ + hub_3_0: hub@2 { + compatible = "usbbda,411"; + reg = <2>; + vdd-supply = <&pp3300_hub>; + companion-hub = <&hub_2_0>; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index e67223d90bb7..ad73339ffe1d 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -53,7 +53,6 @@ properties: clocks: minItems: 1 - maxItems: 3 items: - description: USB 2.0 host - description: USB 2.0 peripheral @@ -86,7 +85,6 @@ properties: dma-names: minItems: 2 - maxItems: 4 items: - const: ch0 - const: ch1 @@ -100,7 +98,6 @@ properties: resets: minItems: 1 - maxItems: 2 items: - description: USB 2.0 host - description: USB 2.0 peripheral diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index 7ec87a783c5c..a634774c537c 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -27,7 +27,7 @@ properties: description: PM domain provider node and an args specifier containing the USB device id value. See, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml maxItems: 1 clocks: diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index 9a068d3bc73b..f6e91a5fd8fe 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -47,7 +47,7 @@ properties: description: Should contain a phandle to a PM domain provider node and an args specifier containing the USB device id value. This property is as per the binding, - Documentation/devicetree/bindings/soc/ti/sci-pm-domain.txt + Documentation/devicetree/bindings/soc/ti/sci-pm-domain.yaml phys: maxItems: 1 diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index b868cefc7c55..2bbc27aae977 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -472,7 +472,7 @@ patternProperties: "^hirschmann,.*": description: Hirschmann Automation and Control GmbH "^hisilicon,.*": - description: Hisilicon Limited. + description: HiSilicon Limited. "^hit,.*": description: Hitachi Ltd. "^hitex,.*": @@ -533,6 +533,8 @@ patternProperties: description: Innolux Corporation "^inside-secure,.*": description: INSIDE Secure + "^insignal,.*": + description: Insignal Ltd. "^inspur,.*": description: Inspur Corporation "^intel,.*": @@ -830,6 +832,8 @@ patternProperties: description: Opal Kelly Incorporated "^opencores,.*": description: OpenCores.org + "^openembed,.*": + description: OpenEmbed "^openrisc,.*": description: OpenRISC.io "^option,.*": @@ -1076,6 +1080,8 @@ patternProperties: description: Sony Corporation "^spansion,.*": description: Spansion Inc. + "^sparkfun,.*": + description: SparkFun Electronics "^sprd,.*": description: Spreadtrum Communications Inc. "^sst,.*": @@ -1085,6 +1091,8 @@ patternProperties: (formerly part of MStar Semiconductor, Inc.) "^st,.*": description: STMicroelectronics + "^starfive,.*": + description: StarFive Technology Co. Ltd. "^starry,.*": description: Starry Electronic Technology (ShenZhen) Co., LTD "^startek,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt b/Documentation/devicetree/bindings/virtio/mmio.txt deleted file mode 100644 index 0a575f329f6e..000000000000 --- a/Documentation/devicetree/bindings/virtio/mmio.txt +++ /dev/null @@ -1,47 +0,0 @@ -* virtio memory mapped device - -See https://ozlabs.org/~rusty/virtio-spec/ for more details. - -Required properties: - -- compatible: "virtio,mmio" compatibility string -- reg: control registers base address and size including configuration space -- interrupts: interrupt generated by the device - -Required properties for virtio-iommu: - -- #iommu-cells: When the node corresponds to a virtio-iommu device, it is - linked to DMA masters using the "iommus" or "iommu-map" - properties [1][2]. #iommu-cells specifies the size of the - "iommus" property. For virtio-iommu #iommu-cells must be - 1, each cell describing a single endpoint ID. - -Optional properties: - -- iommus: If the device accesses memory through an IOMMU, it should - have an "iommus" property [1]. Since virtio-iommu itself - does not access memory through an IOMMU, the "virtio,mmio" - node cannot have both an "#iommu-cells" and an "iommus" - property. - -Example: - - virtio_block@3000 { - compatible = "virtio,mmio"; - reg = <0x3000 0x100>; - interrupts = <41>; - - /* Device has endpoint ID 23 */ - iommus = <&viommu 23> - } - - viommu: iommu@3100 { - compatible = "virtio,mmio"; - reg = <0x3100 0x100>; - interrupts = <42>; - - #iommu-cells = <1> - } - -[1] Documentation/devicetree/bindings/iommu/iommu.txt -[2] Documentation/devicetree/bindings/pci/pci-iommu.txt diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml new file mode 100644 index 000000000000..d46597028cf1 --- /dev/null +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/virtio/mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: virtio memory mapped devices + +maintainers: + - Jean-Philippe Brucker <jean-philippe@linaro.org> + +description: + See https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=virtio for + more details. + +properties: + compatible: + const: virtio,mmio + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + '#iommu-cells': + description: Required when the node corresponds to a virtio-iommu device. + const: 1 + + iommus: + description: Required for devices making accesses thru an IOMMU. + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + virtio@3000 { + compatible = "virtio,mmio"; + reg = <0x3000 0x100>; + interrupts = <41>; + + /* Device has endpoint ID 23 */ + iommus = <&viommu 23>; + }; + + viommu: iommu@3100 { + compatible = "virtio,mmio"; + reg = <0x3100 0x100>; + interrupts = <42>; + + #iommu-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml new file mode 100644 index 000000000000..6bfa46353c4e --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,sbsa-gwdt.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,sbsa-gwdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SBSA (Server Base System Architecture) Generic Watchdog + +maintainers: + - Fu Wei <fu.wei@linaro.org> + +description: | + The SBSA Generic Watchdog Timer is used to force a reset of the system after + two stages of timeout have elapsed. A detailed definition of the watchdog + timer can be found in the ARM document: ARM-DEN-0029 - Server Base System + Architecture (SBSA) + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + const: arm,sbsa-gwdt + + reg: + items: + - description: Watchdog control frame + - description: Refresh frame + + interrupts: + description: The Watchdog Signal 0 (WS0) SPI (Shared Peripheral Interrupt) + maxItems: 1 + +required: + - compatible + - reg + - interrupts + +unevaluatedProperties: false + +examples: + - | + + watchdog@2a440000 { + compatible = "arm,sbsa-gwdt"; + reg = <0x2a440000 0x1000>, + <0x2a450000 0x1000>; + interrupts = <0 27 4>; + timeout-sec = <30>; + }; +... diff --git a/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml new file mode 100644 index 000000000000..bb8901854222 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/arm,twd-wdt.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/arm,twd-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARM Timer-Watchdog Watchdog + +maintainers: + - Rob Herring <robh@kernel.org> + +description: + ARM 11MP, Cortex-A5 and Cortex-A9 are often associated with a per-core + Timer-Watchdog (aka TWD), which provides both a per-cpu local timer + and watchdog. + + The TWD is usually attached to a GIC to deliver its two per-processor + interrupts. + +properties: + compatible: + enum: + - arm,cortex-a9-twd-wdt + - arm,cortex-a5-twd-wdt + - arm,arm11mp-twd-wdt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + watchdog@2c000620 { + compatible = "arm,arm11mp-twd-wdt"; + reg = <0x2c000620 0x20>; + interrupts = <GIC_PPI 14 0xf01>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml new file mode 100644 index 000000000000..9856cd76c28d --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/atmel,sama5d4-wdt.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/atmel,sama5d4-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel SAMA5D4 Watchdog Timer (WDT) Controller + +maintainers: + - Eugen Hristev <eugen.hristev@microchip.com> + +allOf: + - $ref: "watchdog.yaml#" + +properties: + compatible: + enum: + - atmel,sama5d4-wdt + - microchip,sam9x60-wdt + - microchip,sama7g5-wdt + + reg: + maxItems: 1 + + atmel,watchdog-type: + $ref: /schemas/types.yaml#/definitions/string + description: should be hardware or software. + oneOf: + - description: + Enable watchdog fault reset. A watchdog fault triggers + watchdog reset. + const: hardware + - description: + Enable watchdog fault interrupt. A watchdog fault asserts + watchdog interrupt. + const: software + default: hardware + + atmel,idle-halt: + $ref: /schemas/types.yaml#/definitions/flag + description: | + present if you want to stop the watchdog when the CPU is in idle state. + CAUTION: This property should be used with care, it actually makes the + watchdog not counting when the CPU is in idle state, therefore the + watchdog reset time depends on mean CPU usage and will not reset at all + if the CPU stop working while it is in idle state, which is probably + not what you want. + + atmel,dbg-halt: + $ref: /schemas/types.yaml#/definitions/flag + description: | + present if you want to stop the watchdog when the CPU is in debug state. + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + watchdog@fc068640 { + compatible = "atmel,sama5d4-wdt"; + reg = <0xfc068640 0x10>; + interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>; + timeout-sec = <10>; + atmel,watchdog-type = "hardware"; + atmel,dbg-halt; + atmel,idle-halt; + }; + +... diff --git a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt b/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt deleted file mode 100644 index 44727fcc2729..000000000000 --- a/Documentation/devicetree/bindings/watchdog/atmel-sama5d4-wdt.txt +++ /dev/null @@ -1,34 +0,0 @@ -* Atmel SAMA5D4 Watchdog Timer (WDT) Controller - -Required properties: -- compatible: "atmel,sama5d4-wdt" or "microchip,sam9x60-wdt" -- reg: base physical address and length of memory mapped region. - -Optional properties: -- timeout-sec: watchdog timeout value (in seconds). -- interrupts: interrupt number to the CPU. -- atmel,watchdog-type: should be "hardware" or "software". - "hardware": enable watchdog fault reset. A watchdog fault triggers - watchdog reset. - "software": enable watchdog fault interrupt. A watchdog fault asserts - watchdog interrupt. -- atmel,idle-halt: present if you want to stop the watchdog when the CPU is - in idle state. - CAUTION: This property should be used with care, it actually makes the - watchdog not counting when the CPU is in idle state, therefore the - watchdog reset time depends on mean CPU usage and will not reset at all - if the CPU stop working while it is in idle state, which is probably - not what you want. -- atmel,dbg-halt: present if you want to stop the watchdog when the CPU is - in debug state. - -Example: - watchdog@fc068640 { - compatible = "atmel,sama5d4-wdt"; - reg = <0xfc068640 0x10>; - interrupts = <4 IRQ_TYPE_LEVEL_HIGH 5>; - timeout-sec = <10>; - atmel,watchdog-type = "hardware"; - atmel,dbg-halt; - atmel,idle-halt; - }; diff --git a/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml new file mode 100644 index 000000000000..e3e8b86dbf63 --- /dev/null +++ b/Documentation/devicetree/bindings/watchdog/mstar,msc313e-wdt.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/watchdog/mstar,msc313e-wdt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar Watchdog Device Tree Bindings + +maintainers: + - Daniel Palmer <daniel@0x0f.com> + - Romain Perier <romain.perier@gmail.com> + +allOf: + - $ref: watchdog.yaml# + +properties: + compatible: + enum: + - mstar,msc313e-wdt + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - clocks + - reg + +unevaluatedProperties: false + +examples: + - | + watchdog@6000 { + compatible = "mstar,msc313e-wdt"; + reg = <0x6000 0x1f>; + clocks = <&xtal_div2>; + }; diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index e36ba60de829..416d716403f6 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -1,5 +1,8 @@ Mediatek SoCs Watchdog timer +The watchdog supports a pre-timeout interrupt that fires timeout-sec/2 +before the expiry. + Required properties: - compatible should contain: @@ -13,10 +16,12 @@ Required properties: "mediatek,mt8183-wdt": for MT8183 "mediatek,mt8516-wdt", "mediatek,mt6589-wdt": for MT8516 "mediatek,mt8192-wdt": for MT8192 + "mediatek,mt8195-wdt", "mediatek,mt6589-wdt": for MT8195 - reg : Specifies base physical address and size of the registers. Optional properties: +- interrupts: Watchdog pre-timeout (bark) interrupt. - timeout-sec: contains the watchdog timeout in seconds. - #reset-cells: Should be 1. @@ -26,6 +31,7 @@ watchdog: watchdog@10007000 { compatible = "mediatek,mt8183-wdt", "mediatek,mt6589-wdt"; reg = <0 0x10007000 0 0x100>; + interrupts = <GIC_SPI 139 IRQ_TYPE_NONE>; timeout-sec = <10>; #reset-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml index b8e4118945a0..ba60bdf1fecc 100644 --- a/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/qcom-wdt.yaml @@ -17,6 +17,7 @@ properties: enum: - qcom,apss-wdt-qcs404 - qcom,apss-wdt-sc7180 + - qcom,apss-wdt-sc7280 - qcom,apss-wdt-sdm845 - qcom,apss-wdt-sdx55 - qcom,apss-wdt-sm8150 diff --git a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt b/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt deleted file mode 100644 index 6f2d5f91964d..000000000000 --- a/Documentation/devicetree/bindings/watchdog/sbsa-gwdt.txt +++ /dev/null @@ -1,31 +0,0 @@ -* SBSA (Server Base System Architecture) Generic Watchdog - -The SBSA Generic Watchdog Timer is used to force a reset of the system -after two stages of timeout have elapsed. A detailed definition of the -watchdog timer can be found in the ARM document: ARM-DEN-0029 - Server -Base System Architecture (SBSA) - -Required properties: -- compatible: Should at least contain "arm,sbsa-gwdt". - -- reg: Each entry specifies the base physical address of a register frame - and the length of that frame; currently, two frames must be defined, - in this order: - 1: Watchdog control frame; - 2: Refresh frame. - -- interrupts: Should contain the Watchdog Signal 0 (WS0) SPI (Shared - Peripheral Interrupt) number of SBSA Generic Watchdog. - -Optional properties -- timeout-sec: Watchdog timeout values (in seconds). - -Example for FVP Foundation Model v8: - -watchdog@2a440000 { - compatible = "arm,sbsa-gwdt"; - reg = <0x0 0x2a440000 0 0x1000>, - <0x0 0x2a450000 0 0x1000>; - interrupts = <0 27 4>; - timeout-sec = <30>; -}; diff --git a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml index b58596b1831d..6461eb4f4a27 100644 --- a/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/snps,dw-wdt.yaml @@ -27,6 +27,7 @@ properties: - rockchip,rk3328-wdt - rockchip,rk3368-wdt - rockchip,rk3399-wdt + - rockchip,rk3568-wdt - rockchip,rv1108-wdt - const: snps,dw-wdt diff --git a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml index 3f1ba1d6c6b5..481bf91f988a 100644 --- a/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml +++ b/Documentation/devicetree/bindings/watchdog/st,stm32-iwdg.yaml @@ -27,7 +27,6 @@ properties: - description: Low speed clock - description: Optional peripheral clock minItems: 1 - maxItems: 2 clock-names: items: diff --git a/Documentation/devicetree/bindings/writing-bindings.rst b/Documentation/devicetree/bindings/writing-bindings.rst index 45ff426d0019..f7dfb98c156e 100644 --- a/Documentation/devicetree/bindings/writing-bindings.rst +++ b/Documentation/devicetree/bindings/writing-bindings.rst @@ -52,7 +52,8 @@ Properties constraints specific to the device. - DO use common property unit suffixes for properties with scientific units. - See property-units.txt. + Recommended suffixes are listed at + https://github.com/devicetree-org/dt-schema/blob/master/schemas/property-units.yaml - DO define properties in terms of constraints. How many entries? What are possible values? What is the order? diff --git a/Documentation/driver-api/auxiliary_bus.rst b/Documentation/driver-api/auxiliary_bus.rst index fff96c7ba7a8..ef902daf0d68 100644 --- a/Documentation/driver-api/auxiliary_bus.rst +++ b/Documentation/driver-api/auxiliary_bus.rst @@ -11,7 +11,7 @@ too complex for a single device to be managed by a monolithic driver (e.g. Sound Open Firmware), multiple devices might implement a common intersection of functionality (e.g. NICs + RDMA), or a driver may want to export an interface for another subsystem to drive (e.g. SIOV Physical Function -export Virtual Function management). A split of the functinoality into child- +export Virtual Function management). A split of the functionality into child- devices representing sub-domains of functionality makes it possible to compartmentalize, layer, and distribute domain-specific concerns via a Linux device-driver model. diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 1bad466f9167..487ce4f41d77 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -22,16 +22,22 @@ This section covers the driver infrastructure for a CXL memory device. CXL Memory Device ----------------- -.. kernel-doc:: drivers/cxl/mem.c - :doc: cxl mem +.. kernel-doc:: drivers/cxl/pci.c + :doc: cxl pci -.. kernel-doc:: drivers/cxl/mem.c +.. kernel-doc:: drivers/cxl/pci.c :internal: -CXL Bus -------- -.. kernel-doc:: drivers/cxl/bus.c - :doc: cxl bus +CXL Core +-------- +.. kernel-doc:: drivers/cxl/cxl.h + :doc: cxl objects + +.. kernel-doc:: drivers/cxl/cxl.h + :internal: + +.. kernel-doc:: drivers/cxl/core.c + :doc: cxl core External Interfaces =================== diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 7f37ec30d9fd..7f21425d9435 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -178,6 +178,15 @@ DMA Fence Array .. kernel-doc:: include/linux/dma-fence-array.h :internal: +DMA Fence Chain +~~~~~~~~~~~~~~~ + +.. kernel-doc:: drivers/dma-buf/dma-fence-chain.c + :export: + +.. kernel-doc:: include/linux/dma-fence-chain.h + :internal: + DMA Fence uABI/Sync File ~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index e0814d214048..0fe1fffa295e 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -314,7 +314,6 @@ IOMAP devm_ioremap_resource() : checks resource, requests memory region, ioremaps devm_ioremap_resource_wc() devm_platform_ioremap_resource() : calls devm_ioremap_resource() for platform device - devm_platform_ioremap_resource_wc() devm_platform_ioremap_resource_byname() devm_platform_get_and_ioremap_resource() devm_iounmap() diff --git a/Documentation/driver-api/generic-counter.rst b/Documentation/driver-api/generic-counter.rst index b02c52cd69d6..64fe7db080e5 100644 --- a/Documentation/driver-api/generic-counter.rst +++ b/Documentation/driver-api/generic-counter.rst @@ -307,7 +307,7 @@ Determining the type of extension to create is a matter of scope. * Device extensions are attributes that expose information/control non-specific to a particular Count or Signal. This is where you would - put your global features or other miscellanous functionality. + put your global features or other miscellaneous functionality. For example, if your device has an overtemp sensor, you can report the chip overheated via a device extension called "error_overtemp": diff --git a/Documentation/driver-api/pin-control.rst b/Documentation/driver-api/pin-control.rst index e2474425fb0c..71eefe5a023f 100644 --- a/Documentation/driver-api/pin-control.rst +++ b/Documentation/driver-api/pin-control.rst @@ -95,7 +95,7 @@ this in our driver:: To enable the pinctrl subsystem and the subgroups for PINMUX and PINCONF and selected drivers, you need to select them from your machine's Kconfig entry, since these are so tightly integrated with the machines they are used on. -See for example arch/arm/mach-u300/Kconfig for an example. +See for example arch/arm/mach-ux500/Kconfig for an example. Pins usually have fancier names than this. You can find these in the datasheet for your chip. Notice that the core pinctrl.h file provides a fancy macro diff --git a/Documentation/driver-api/serial/moxa-smartio.rst b/Documentation/driver-api/serial/moxa-smartio.rst index 156100f17c3f..af25bc5cc3e6 100644 --- a/Documentation/driver-api/serial/moxa-smartio.rst +++ b/Documentation/driver-api/serial/moxa-smartio.rst @@ -2,14 +2,8 @@ MOXA Smartio/Industio Family Device Driver Installation Guide ============================================================= -.. note:: - - This file is outdated. It needs some care in order to make it - updated to Kernel 5.0 and upper - Copyright (C) 2008, Moxa Inc. - -Date: 01/21/2008 +Copyright (C) 2021, Jiri Slaby .. Content @@ -17,12 +11,7 @@ Date: 01/21/2008 2. System Requirement 3. Installation 3.1 Hardware installation - 3.2 Driver files - 3.3 Device naming convention - 3.4 Module driver configuration - 3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x. - 3.6 Custom configuration - 3.7 Verify driver installation + 3.2 Device naming convention 4. Utilities 5. Setserial 6. Troubleshooting @@ -31,14 +20,13 @@ Date: 01/21/2008 ^^^^^^^^^^^^^^^ The Smartio/Industio/UPCI family Linux driver supports following multiport - boards. + boards: - 2 ports multiport board CP-102U, CP-102UL, CP-102UF CP-132U-I, CP-132UL, CP-132, CP-132I, CP132S, CP-132IS, - CI-132, CI-132I, CI-132IS, - (C102H, C102HI, C102HIS, C102P, CP-102, CP-102S) + (CP-102, CP-102S) - 4 ports multiport board CP-104EL, @@ -46,10 +34,7 @@ Date: 01/21/2008 CP-134U, CP-134U-I, C104H/PCI, C104HS/PCI, CP-114, CP-114I, CP-114S, CP-114IS, CP-114UL, - C104H, C104HS, - CI-104J, CI-104JS, - CI-134, CI-134I, CI-134IS, - (C114HI, CT-114I, C104P), + (C114HI, CT-114I), POS-104UL, CB-114, CB-134I @@ -58,15 +43,10 @@ Date: 01/21/2008 CP-118EL, CP-168EL, CP-118U, CP-168U, C168H/PCI, - C168H, C168HS, - (C168P), CB-108 - This driver and installation procedure have been developed upon Linux Kernel - 2.4.x and 2.6.x. This driver supports Intel x86 hardware platform. In order - to maintain compatibility, this version has also been properly tested with - RedHat, Mandrake, Fedora and S.u.S.E Linux. However, if compatibility problem - occurs, please contact Moxa at support@moxa.com.tw. + If a compatibility problem occurs, please contact Moxa at + support@moxa.com.tw. In addition to device driver, useful utilities are also provided in this version. They are: @@ -78,22 +58,19 @@ Date: 01/21/2008 Monitor program to observe data count and line status signals. - msterm A simple terminal program which is useful in testing serial ports. - - io-irq.exe - Configuration program to setup ISA boards. Please note that - this program can only be executed under DOS. All the drivers and utilities are published in form of source code under GNU General Public License in this version. Please refer to GNU General Public License announcement in each source code file for more detail. - In Moxa's Web sites, you may always find latest driver at http://www.moxa.com/. + In Moxa's Web sites, you may always find the latest driver at + https://www.moxa.com/. - This version of driver can be installed as Loadable Module (Module driver) - or built-in into kernel (Static driver). You may refer to following - installation procedure for suitable one. Before you install the driver, + This version of driver can be installed as a Loadable Module (Module driver) + or built-in into kernel (Static driver). Before you install the driver, please refer to hardware installation procedure in the User's Manual. - We assume the user should be familiar with following documents. + We assume the user should be familiar with following documents: - Serial-HOWTO - Kernel-HOWTO @@ -101,9 +78,6 @@ Date: 01/21/2008 2. System Requirement ^^^^^^^^^^^^^^^^^^^^^ - - Hardware platform: Intel x86 machine - - Kernel version: 2.4.x or 2.6.x - - gcc version 2.72 or later - Maximum 4 boards can be installed in combination 3. Installation @@ -112,23 +86,12 @@ Date: 01/21/2008 3.1 Hardware installation ========================= - There are two types of buses, ISA and PCI, for Smartio/Industio - family multiport board. - -ISA board ---------- - - You'll have to configure CAP address, I/O address, Interrupt Vector - as well as IRQ before installing this driver. Please refer to hardware - installation procedure in User's Manual before proceed any further. - Please make sure the JP1 is open after the ISA board is set properly. - PCI/UPCI board -------------- - You may need to adjust IRQ usage in BIOS to avoid from IRQ conflict - with other ISA devices. Please refer to hardware installation - procedure in User's Manual in advance. + You may need to adjust IRQ usage in BIOS to avoid IRQ conflict with other + ISA devices. Please refer to hardware installation procedure in User's + Manual in advance. PCI IRQ Sharing --------------- @@ -138,42 +101,11 @@ PCI IRQ Sharing together on one system and they can share the same IRQ. -3.2 Driver files -================ - - The driver file may be obtained from ftp, CD-ROM or floppy disk. The - first step, anyway, is to copy driver file "mxser.tgz" into specified - directory. e.g. /moxa. The execute commands as below:: - - # cd / - # mkdir moxa - # cd /moxa - # tar xvf /dev/fd0 - -or:: - # cd / - # mkdir moxa - # cd /moxa - # cp /mnt/cdrom/<driver directory>/mxser.tgz . - # tar xvfz mxser.tgz - - -3.3 Device naming convention +3.2 Device naming convention ============================ - You may find all the driver and utilities files in /moxa/mxser. - Following installation procedure depends on the model you'd like to - run the driver. If you prefer module driver, please refer to 3.4. - If static driver is required, please refer to 3.5. - -Dialin and callout port ------------------------ - - This driver remains traditional serial device properties. There are - two special file name for each serial port. One is dial-in port - which is named "ttyMxx". For callout port, the naming convention - is "cumxx". + The device node is named "ttyMxx". Device naming when more than 2 boards installed ----------------------------------------------- @@ -181,322 +113,13 @@ Device naming when more than 2 boards installed Naming convention for each Smartio/Industio multiport board is pre-defined as below. - ============ =============== ============== - Board Num. Dial-in Port Callout port - 1st board ttyM0 - ttyM7 cum0 - cum7 - 2nd board ttyM8 - ttyM15 cum8 - cum15 - 3rd board ttyM16 - ttyM23 cum16 - cum23 - 4th board ttyM24 - ttym31 cum24 - cum31 - ============ =============== ============== - -.. note:: - - Under Kernel 2.6 and upper, the cum Device is Obsolete. So use ttyM* - device instead. - -Board sequence --------------- - - This driver will activate ISA boards according to the parameter set - in the driver. After all specified ISA board activated, PCI board - will be installed in the system automatically driven. - Therefore the board number is sorted by the CAP address of ISA boards. - For PCI boards, their sequence will be after ISA boards and C168H/PCI - has higher priority than C104H/PCI boards. - -3.4 Module driver configuration -=============================== - - Module driver is easiest way to install. If you prefer static driver - installation, please skip this paragraph. - - - ------------- Prepare to use the MOXA driver -------------------- - -3.4.1 Create tty device with correct major number -------------------------------------------------- - - Before using MOXA driver, your system must have the tty devices - which are created with driver's major number. We offer one shell - script "msmknod" to simplify the procedure. - This step is only needed to be executed once. But you still - need to do this procedure when: - - a. You change the driver's major number. Please refer the "3.7" - section. - b. Your total installed MOXA boards number is changed. Maybe you - add/delete one MOXA board. - c. You want to change the tty name. This needs to modify the - shell script "msmknod" - - The procedure is:: - - # cd /moxa/mxser/driver - # ./msmknod - - This shell script will require the major number for dial-in - device and callout device to create tty device. You also need - to specify the total installed MOXA board number. Default major - numbers for dial-in device and callout device are 30, 35. If - you need to change to other number, please refer section "3.7" - for more detailed procedure. - Msmknod will delete any special files occupying the same device - naming. - -3.4.2 Build the MOXA driver and utilities ------------------------------------------ - - Before using the MOXA driver and utilities, you need compile the - all the source code. This step is only need to be executed once. - But you still re-compile the source code if you modify the source - code. For example, if you change the driver's major number (see - "3.7" section), then you need to do this step again. - - Find "Makefile" in /moxa/mxser, then run - - # make clean; make install - - ..note:: - - For Red Hat 9, Red Hat Enterprise Linux AS3/ES3/WS3 & Fedora Core1: - # make clean; make installsp1 - - For Red Hat Enterprise Linux AS4/ES4/WS4: - # make clean; make installsp2 - - The driver files "mxser.o" and utilities will be properly compiled - and copied to system directories respectively. - -------------- Load MOXA driver-------------------- - -3.4.3 Load the MOXA driver --------------------------- - - :: - - # modprobe mxser <argument> - - will activate the module driver. You may run "lsmod" to check - if "mxser" is activated. If the MOXA board is ISA board, the - <argument> is needed. Please refer to section "3.4.5" for more - information. - -------------- Load MOXA driver on boot -------------------- - -3.4.4 Load the mxser driver ---------------------------- - - - For the above description, you may manually execute - "modprobe mxser" to activate this driver and run - "rmmod mxser" to remove it. - - However, it's better to have a boot time configuration to - eliminate manual operation. Boot time configuration can be - achieved by rc file. We offer one "rc.mxser" file to simplify - the procedure under "moxa/mxser/driver". - - But if you use ISA board, please modify the "modprobe ..." command - to add the argument (see "3.4.5" section). After modifying the - rc.mxser, please try to execute "/moxa/mxser/driver/rc.mxser" - manually to make sure the modification is ok. If any error - encountered, please try to modify again. If the modification is - completed, follow the below step. - - Run following command for setting rc files:: - - # cd /moxa/mxser/driver - # cp ./rc.mxser /etc/rc.d - # cd /etc/rc.d - - Check "rc.serial" is existed or not. If "rc.serial" doesn't exist, - create it by vi, run "chmod 755 rc.serial" to change the permission. - - Add "/etc/rc.d/rc.mxser" in last line. - - Reboot and check if moxa.o activated by "lsmod" command. - -3.4.5. specify CAP address --------------------------- - - If you'd like to drive Smartio/Industio ISA boards in the system, - you'll have to add parameter to specify CAP address of given - board while activating "mxser.o". The format for parameters are - as follows.:: - - modprobe mxser ioaddr=0x???,0x???,0x???,0x??? - | | | | - | | | +- 4th ISA board - | | +------ 3rd ISA board - | +------------ 2nd ISA board - +-------------------1st ISA board - -3.5 Static driver configuration for Linux kernel 2.4.x and 2.6.x -================================================================ - - Note: - To use static driver, you must install the linux kernel - source package. - -3.5.1 Backup the built-in driver in the kernel ----------------------------------------------- - - :: - - # cd /usr/src/linux/drivers/char - # mv mxser.c mxser.c.old - - For Red Hat 7.x user, you need to create link: - # cd /usr/src - # ln -s linux-2.4 linux - -3.5.2 Create link ------------------ - :: - - # cd /usr/src/linux/drivers/char - # ln -s /moxa/mxser/driver/mxser.c mxser.c - -3.5.3 Add CAP address list for ISA boards. ------------------------------------------- - - For PCI boards user, please skip this step. - - In module mode, the CAP address for ISA board is given by - parameter. In static driver configuration, you'll have to - assign it within driver's source code. If you will not - install any ISA boards, you may skip to next portion. - The instructions to modify driver source code are as - below. - - a. run:: - - # cd /moxa/mxser/driver - # vi mxser.c - - b. Find the array mxserBoardCAP[] as below:: - - static int mxserBoardCAP[] = {0x00, 0x00, 0x00, 0x00}; - - c. Change the address within this array using vi. For - example, to driver 2 ISA boards with CAP address - 0x280 and 0x180 as 1st and 2nd board. Just to change - the source code as follows:: - - static int mxserBoardCAP[] = {0x280, 0x180, 0x00, 0x00}; - -3.5.4 Setup kernel configuration --------------------------------- - - Configure the kernel:: - - # cd /usr/src/linux - # make menuconfig - - You will go into a menu-driven system. Please select [Character - devices][Non-standard serial port support], enable the [Moxa - SmartIO support] driver with "[*]" for built-in (not "[M]"), then - select [Exit] to exit this program. - -3.5.5 Rebuild kernel --------------------- - - The following are for Linux kernel rebuilding, for your - reference only. - - For appropriate details, please refer to the Linux document: - - a. Run the following commands:: - - cd /usr/src/linux - make clean # take a few minutes - make dep # take a few minutes - make bzImage # take probably 10-20 minutes - make install # copy boot image to correct position - - f. Please make sure the boot kernel (vmlinuz) is in the - correct position. - g. If you use 'lilo' utility, you should check /etc/lilo.conf - 'image' item specified the path which is the 'vmlinuz' path, - or you will load wrong (or old) boot kernel image (vmlinuz). - After checking /etc/lilo.conf, please run "lilo". - - Note that if the result of "make bzImage" is ERROR, then you have to - go back to Linux configuration Setup. Type "make menuconfig" in - directory /usr/src/linux. - - -3.5.6 Make tty device and special file --------------------------------------- - - :: - # cd /moxa/mxser/driver - # ./msmknod - -3.5.7 Make utility ------------------- - - :: - - # cd /moxa/mxser/utility - # make clean; make install - -3.5.8 Reboot ------------- - - - -3.6 Custom configuration -======================== - - Although this driver already provides you default configuration, you - still can change the device name and major number. The instruction to - change these parameters are shown as below. - -a. Change Device name - - If you'd like to use other device names instead of default naming - convention, all you have to do is to modify the internal code - within the shell script "msmknod". First, you have to open "msmknod" - by vi. Locate each line contains "ttyM" and "cum" and change them - to the device name you desired. "msmknod" creates the device names - you need next time executed. - -b. Change Major number - - If major number 30 and 35 had been occupied, you may have to select - 2 free major numbers for this driver. There are 3 steps to change - major numbers. - -3.6.1 Find free major numbers ------------------------------ - - In /proc/devices, you may find all the major numbers occupied - in the system. Please select 2 major numbers that are available. - e.g. 40, 45. - -3.6.2 Create special files --------------------------- - - Run /moxa/mxser/driver/msmknod to create special files with - specified major numbers. - -3.6.3 Modify driver with new major number ------------------------------------------ - - Run vi to open /moxa/mxser/driver/mxser.c. Locate the line - contains "MXSERMAJOR". Change the content as below:: - - #define MXSERMAJOR 40 - #define MXSERCUMAJOR 45 - - 3.6.4 Run "make clean; make install" in /moxa/mxser/driver. - -3.7 Verify driver installation -============================== - - You may refer to /var/log/messages to check the latest status - log reported by this driver whenever it's activated. + ============ =============== + Board Num. Device node + 1st board ttyM0 - ttyM7 + 2nd board ttyM8 - ttyM15 + 3rd board ttyM16 - ttyM23 + 4th board ttyM24 - ttyM31 + ============ =============== 4. Utilities ^^^^^^^^^^^^ @@ -505,14 +128,11 @@ b. Change Major number msterm. These 3 utilities are released in form of source code. They should be compiled into executable file and copied into /usr/bin. - Before using these utilities, please load driver (refer 3.4 & 3.5) and - make sure you had run the "msmknod" utility. - msdiag - Diagnostic =================== This utility provides the function to display what Moxa Smartio/Industio - board found by driver in the system. + board was found by the driver in the system. msmon - Port Monitoring ======================= @@ -542,23 +162,23 @@ msterm - Terminal Emulation Supported Setserial parameters are listed as below. - ============== ========================================================= - uart set UART type(16450-->disable FIFO, 16550A-->enable FIFO) - close_delay set the amount of time(in 1/100 of a second) that DTR + ============== ============================================================= + uart set UART type(16450 --> disable FIFO, 16550A --> enable FIFO) + close_delay set the amount of time (in 1/100 of a second) that DTR should be kept low while being closed. - closing_wait set the amount of time(in 1/100 of a second) that the + closing_wait set the amount of time (in 1/100 of a second) that the serial port should wait for data to be drained while - being closed, before the receiver is disable. - spd_hi Use 57.6kb when the application requests 38.4kb. - spd_vhi Use 115.2kb when the application requests 38.4kb. - spd_shi Use 230.4kb when the application requests 38.4kb. - spd_warp Use 460.8kb when the application requests 38.4kb. - spd_normal Use 38.4kb when the application requests 38.4kb. - spd_cust Use the custom divisor to set the speed when the + being closed, before the receiver is disabled. + spd_hi Use 57.6kb when the application requests 38.4kb. + spd_vhi Use 115.2kb when the application requests 38.4kb. + spd_shi Use 230.4kb when the application requests 38.4kb. + spd_warp Use 460.8kb when the application requests 38.4kb. + spd_normal Use 38.4kb when the application requests 38.4kb. + spd_cust Use the custom divisor to set the speed when the application requests 38.4kb. - divisor This option set the custom division. - baud_base This option set the base baud rate. - ============== ========================================================= + divisor This option sets the custom division. + baud_base This option sets the base baud rate. + ============== ============================================================= 6. Troubleshooting ^^^^^^^^^^^^^^^^^^ @@ -575,41 +195,3 @@ msterm - Terminal Emulation Solution: To avoid this problem, please unplug fifth and after board, because Moxa driver supports up to 4 boards. - - Error msg: - Request_irq fail, IRQ(?) may be conflict with another device. - - Solution: - Other PCI or ISA devices occupy the assigned IRQ. If you are not sure - which device causes the situation, please check /proc/interrupts to find - free IRQ and simply change another free IRQ for Moxa board. - - Error msg: - Board #: C1xx Series(CAP=xxx) interrupt number invalid. - - Solution: - Each port within the same multiport board shares the same IRQ. Please set - one IRQ (IRQ doesn't equal to zero) for one Moxa board. - - Error msg: - No interrupt vector be set for Moxa ISA board(CAP=xxx). - - Solution: - Moxa ISA board needs an interrupt vector.Please refer to user's manual - "Hardware Installation" chapter to set interrupt vector. - - Error msg: - Couldn't install MOXA Smartio/Industio family driver! - - Solution: - Load Moxa driver fail, the major number may conflict with other devices. - Please refer to previous section 3.7 to change a free major number for - Moxa driver. - - Error msg: - Couldn't install MOXA Smartio/Industio family callout driver! - - Solution: - Load Moxa callout driver fail, the callout device major number may - conflict with other devices. Please refer to previous section 3.7 to - change a free callout device major number for Moxa driver. diff --git a/Documentation/driver-api/surface_aggregator/clients/cdev.rst b/Documentation/driver-api/surface_aggregator/clients/cdev.rst index 248c1372d879..0134a841a079 100644 --- a/Documentation/driver-api/surface_aggregator/clients/cdev.rst +++ b/Documentation/driver-api/surface_aggregator/clients/cdev.rst @@ -1,9 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0+ -.. |u8| replace:: :c:type:`u8 <u8>` -.. |u16| replace:: :c:type:`u16 <u16>` .. |ssam_cdev_request| replace:: :c:type:`struct ssam_cdev_request <ssam_cdev_request>` .. |ssam_cdev_request_flags| replace:: :c:type:`enum ssam_cdev_request_flags <ssam_cdev_request_flags>` +.. |ssam_cdev_event| replace:: :c:type:`struct ssam_cdev_event <ssam_cdev_event>` ============================== User-Space EC Interface (cdev) @@ -23,6 +22,40 @@ These IOCTLs and their respective input/output parameter structs are defined in A small python library and scripts for accessing this interface can be found at https://github.com/linux-surface/surface-aggregator-module/tree/master/scripts/ssam. +.. contents:: + + +Receiving Events +================ + +Events can be received by reading from the device-file. The are represented by +the |ssam_cdev_event| datatype. + +Before events are available to be read, however, the desired notifiers must be +registered via the ``SSAM_CDEV_NOTIF_REGISTER`` IOCTL. Notifiers are, in +essence, callbacks, called when the EC sends an event. They are, in this +interface, associated with a specific target category and device-file-instance. +They forward any event of this category to the buffer of the corresponding +instance, from which it can then be read. + +Notifiers themselves do not enable events on the EC. Thus, it may additionally +be necessary to enable events via the ``SSAM_CDEV_EVENT_ENABLE`` IOCTL. While +notifiers work per-client (i.e. per-device-file-instance), events are enabled +globally, for the EC and all of its clients (regardless of userspace or +non-userspace). The ``SSAM_CDEV_EVENT_ENABLE`` and ``SSAM_CDEV_EVENT_DISABLE`` +IOCTLs take care of reference counting the events, such that an event is +enabled as long as there is a client that has requested it. + +Note that enabled events are not automatically disabled once the client +instance is closed. Therefore any client process (or group of processes) should +balance their event enable calls with the corresponding event disable calls. It +is, however, perfectly valid to enable and disable events on different client +instances. For example, it is valid to set up notifiers and read events on +client instance ``A``, enable those events on instance ``B`` (note that these +will also be received by A since events are enabled/disabled globally), and +after no more events are desired, disable the previously enabled events via +instance ``C``. + Controller IOCTLs ================= @@ -45,9 +78,33 @@ The following IOCTLs are provided: - ``REQUEST`` - Perform synchronous SAM request. + * - ``0xA5`` + - ``2`` + - ``W`` + - ``NOTIF_REGISTER`` + - Register event notifier. -``REQUEST`` ------------ + * - ``0xA5`` + - ``3`` + - ``W`` + - ``NOTIF_UNREGISTER`` + - Unregister event notifier. + + * - ``0xA5`` + - ``4`` + - ``W`` + - ``EVENT_ENABLE`` + - Enable event source. + + * - ``0xA5`` + - ``5`` + - ``W`` + - ``EVENT_DISABLE`` + - Disable event source. + + +``SSAM_CDEV_REQUEST`` +--------------------- Defined as ``_IOWR(0xA5, 1, struct ssam_cdev_request)``. @@ -82,6 +139,66 @@ submitted, and completed (i.e. handed back to user-space) successfully from inside the IOCTL, but the request ``status`` member may still be negative in case the actual execution of the request failed after it has been submitted. -A full definition of the argument struct is provided below: +A full definition of the argument struct is provided below. + +``SSAM_CDEV_NOTIF_REGISTER`` +---------------------------- + +Defined as ``_IOW(0xA5, 2, struct ssam_cdev_notifier_desc)``. + +Register a notifier for the event target category specified in the given +notifier description with the specified priority. Notifiers registration is +required to receive events, but does not enable events themselves. After a +notifier for a specific target category has been registered, all events of that +category will be forwarded to the userspace client and can then be read from +the device file instance. Note that events may have to be enabled, e.g. via the +``SSAM_CDEV_EVENT_ENABLE`` IOCTL, before the EC will send them. + +Only one notifier can be registered per target category and client instance. If +a notifier has already been registered, this IOCTL will fail with ``-EEXIST``. + +Notifiers will automatically be removed when the device file instance is +closed. + +``SSAM_CDEV_NOTIF_UNREGISTER`` +------------------------------ + +Defined as ``_IOW(0xA5, 3, struct ssam_cdev_notifier_desc)``. + +Unregisters the notifier associated with the specified target category. The +priority field will be ignored by this IOCTL. If no notifier has been +registered for this client instance and the given category, this IOCTL will +fail with ``-ENOENT``. + +``SSAM_CDEV_EVENT_ENABLE`` +-------------------------- + +Defined as ``_IOW(0xA5, 4, struct ssam_cdev_event_desc)``. + +Enable the event associated with the given event descriptor. + +Note that this call will not register a notifier itself, it will only enable +events on the controller. If you want to receive events by reading from the +device file, you will need to register the corresponding notifier(s) on that +instance. + +Events are not automatically disabled when the device file is closed. This must +be done manually, via a call to the ``SSAM_CDEV_EVENT_DISABLE`` IOCTL. + +``SSAM_CDEV_EVENT_DISABLE`` +--------------------------- + +Defined as ``_IOW(0xA5, 5, struct ssam_cdev_event_desc)``. + +Disable the event associated with the given event descriptor. + +Note that this will not unregister any notifiers. Events may still be received +and forwarded to user-space after this call. The only safe way of stopping +events from being received is unregistering all previously registered +notifiers. + + +Structures and Enums +==================== .. kernel-doc:: include/uapi/linux/surface_aggregator/cdev.h diff --git a/Documentation/driver-api/usb/error-codes.rst b/Documentation/driver-api/usb/error-codes.rst index a3e84bfac776..8f9790c2d6f8 100644 --- a/Documentation/driver-api/usb/error-codes.rst +++ b/Documentation/driver-api/usb/error-codes.rst @@ -61,6 +61,9 @@ USB-specific: (c) requested data transfer length is invalid: negative or too large for the host controller. +``-EBADR`` The wLength value in a control URB's setup packet does + not match the URB's transfer_buffer_length. + ``-ENOSPC`` This request would overcommit the usb bandwidth reserved for periodic transfers (interrupt, isochronous). diff --git a/Documentation/driver-api/vfio-mediated-device.rst b/Documentation/driver-api/vfio-mediated-device.rst index 1779b85f014e..9f26079cacae 100644 --- a/Documentation/driver-api/vfio-mediated-device.rst +++ b/Documentation/driver-api/vfio-mediated-device.rst @@ -93,7 +93,7 @@ interfaces: Registration Interface for a Mediated Bus Driver ------------------------------------------------ -The registration interface for a mediated bus driver provides the following +The registration interface for a mediated device driver provides the following structure to represent a mediated device's driver:: /* @@ -136,37 +136,26 @@ The structures in the mdev_parent_ops structure are as follows: * dev_attr_groups: attributes of the parent device * mdev_attr_groups: attributes of the mediated device * supported_config: attributes to define supported configurations +* device_driver: device driver to bind for mediated device instances -The functions in the mdev_parent_ops structure are as follows: +The mdev_parent_ops also still has various functions pointers. Theses exist +for historical reasons only and shall not be used for new drivers. -* create: allocate basic resources in a driver for a mediated device -* remove: free resources in a driver when a mediated device is destroyed - -(Note that mdev-core provides no implicit serialization of create/remove -callbacks per mdev parent device, per mdev type, or any other categorization. -Vendor drivers are expected to be fully asynchronous in this respect or -provide their own internal resource protection.) - -The callbacks in the mdev_parent_ops structure are as follows: - -* open: open callback of mediated device -* close: close callback of mediated device -* ioctl: ioctl callback of mediated device -* read : read emulation callback -* write: write emulation callback -* mmap: mmap emulation callback - -A driver should use the mdev_parent_ops structure in the function call to -register itself with the mdev core driver:: +When a driver wants to add the GUID creation sysfs to an existing device it has +probe'd to then it should call:: extern int mdev_register_device(struct device *dev, const struct mdev_parent_ops *ops); -However, the mdev_parent_ops structure is not required in the function call -that a driver should use to unregister itself with the mdev core driver:: +This will provide the 'mdev_supported_types/XX/create' files which can then be +used to trigger the creation of a mdev_device. The created mdev_device will be +attached to the specified driver. + +When the driver needs to remove itself it calls:: extern void mdev_unregister_device(struct device *dev); +Which will unbind and destroy all the created mdevs and remove the sysfs files. Mediated Device Management Interface Through sysfs ================================================== diff --git a/Documentation/filesystems/debugfs.rst b/Documentation/filesystems/debugfs.rst index 0f2292e367e6..71b1fee56d2a 100644 --- a/Documentation/filesystems/debugfs.rst +++ b/Documentation/filesystems/debugfs.rst @@ -120,8 +120,8 @@ and hexadecimal:: Boolean values can be placed in debugfs with:: - struct dentry *debugfs_create_bool(const char *name, umode_t mode, - struct dentry *parent, bool *value); + void debugfs_create_bool(const char *name, umode_t mode, + struct dentry *parent, bool *value); A read on the resulting file will yield either Y (for non-zero values) or N, followed by a newline. If written to, it will accept either upper- or diff --git a/Documentation/filesystems/ext4/journal.rst b/Documentation/filesystems/ext4/journal.rst index cdbfec473167..5fad38860f17 100644 --- a/Documentation/filesystems/ext4/journal.rst +++ b/Documentation/filesystems/ext4/journal.rst @@ -4,14 +4,14 @@ Journal (jbd2) -------------- Introduced in ext3, the ext4 filesystem employs a journal to protect the -filesystem against corruption in the case of a system crash. A small -continuous region of disk (default 128MiB) is reserved inside the -filesystem as a place to land “important” data writes on-disk as quickly -as possible. Once the important data transaction is fully written to the -disk and flushed from the disk write cache, a record of the data being -committed is also written to the journal. At some later point in time, -the journal code writes the transactions to their final locations on -disk (this could involve a lot of seeking or a lot of small +filesystem against metadata inconsistencies in the case of a system crash. Up +to 10,240,000 file system blocks (see man mke2fs(8) for more details on journal +size limits) can be reserved inside the filesystem as a place to land +“important” data writes on-disk as quickly as possible. Once the important +data transaction is fully written to the disk and flushed from the disk write +cache, a record of the data being committed is also written to the journal. At +some later point in time, the journal code writes the transactions to their +final locations on disk (this could involve a lot of seeking or a lot of small read-write-erases) before erasing the commit record. Should the system crash during the second slow write, the journal can be replayed all the way to the latest commit record, guaranteeing the atomicity of whatever @@ -731,3 +731,26 @@ point, the refcount for inode 11 is not reliable, but that gets fixed by the replay of last inode 11 tag. Thus, by converting a non-idempotent procedure into a series of idempotent outcomes, fast commits ensured idempotence during the replay. + +Journal Checkpoint +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Checkpointing the journal ensures all transactions and their associated buffers +are submitted to the disk. In-progress transactions are waited upon and included +in the checkpoint. Checkpointing is used internally during critical updates to +the filesystem including journal recovery, filesystem resizing, and freeing of +the journal_t structure. + +A journal checkpoint can be triggered from userspace via the ioctl +EXT4_IOC_CHECKPOINT. This ioctl takes a single, u64 argument for flags. +Currently, three flags are supported. First, EXT4_IOC_CHECKPOINT_FLAG_DRY_RUN +can be used to verify input to the ioctl. It returns error if there is any +invalid input, otherwise it returns success without performing +any checkpointing. This can be used to check whether the ioctl exists on a +system and to verify there are no issues with arguments or flags. The +other two flags are EXT4_IOC_CHECKPOINT_FLAG_DISCARD and +EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT. These flags cause the journal blocks to be +discarded or zero-filled, respectively, after the journal checkpoint is +complete. EXT4_IOC_CHECKPOINT_FLAG_DISCARD and EXT4_IOC_CHECKPOINT_FLAG_ZEROOUT +cannot both be set. The ioctl may be useful when snapshotting a system or for +complying with content deletion SLOs. diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 1e894480115b..2183fd8cc350 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -480,7 +480,7 @@ prototypes:: locking rules: ======================= =================== -ops bd_mutex +ops open_mutex ======================= =================== open: yes release: yes diff --git a/Documentation/filesystems/path-lookup.rst b/Documentation/filesystems/path-lookup.rst index a6fa7619b69e..2b2df6aa5432 100644 --- a/Documentation/filesystems/path-lookup.rst +++ b/Documentation/filesystems/path-lookup.rst @@ -1297,18 +1297,18 @@ to lookup: RCU-walk, REF-walk, and REF-walk with forced revalidation. yet. This is primarily used to tell the audit subsystem the full context of a particular access being audited. -``LOOKUP_ROOT`` indicates that the ``root`` field in the ``nameidata`` was +``ND_ROOT_PRESET`` indicates that the ``root`` field in the ``nameidata`` was provided by the caller, so it shouldn't be released when it is no longer needed. -``LOOKUP_JUMPED`` means that the current dentry was chosen not because +``ND_JUMPED`` means that the current dentry was chosen not because it had the right name but for some other reason. This happens when following "``..``", following a symlink to ``/``, crossing a mount point or accessing a "``/proc/$PID/fd/$FD``" symlink (also known as a "magic link"). In this case the filesystem has not been asked to revalidate the name (with ``d_revalidate()``). In such cases the inode may still need to be revalidated, so ``d_op->d_weak_revalidate()`` is called if -``LOOKUP_JUMPED`` is set when the look completes - which may be at the +``ND_JUMPED`` is set when the look completes - which may be at the final component or, when creating, unlinking, or renaming, at the penultimate component. Resolution-restriction flags diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index 0302035781be..bf19fd6b86e7 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -890,3 +890,21 @@ been called or returned with non -EIOCBQUEUED code. mnt_want_write_file() can now only be paired with mnt_drop_write_file(), whereas previously it could be paired with mnt_drop_write() as well. + +--- + +**mandatory** + +iov_iter_copy_from_user_atomic() is gone; use copy_page_from_iter_atomic(). +The difference is copy_page_from_iter_atomic() advances the iterator and +you don't need iov_iter_advance() after it. However, if you decide to use +only a part of obtained data, you should do iov_iter_revert(). + +--- + +**mandatory** + +Calling conventions for file_open_root() changed; now it takes struct path * +instead of passing mount and dentry separately. For callers that used to +pass <mnt, mnt->mnt_root> pair (i.e. the root of given mount), a new helper +is provided - file_open_root_mnt(). In-tree users adjusted. diff --git a/Documentation/filesystems/proc.rst b/Documentation/filesystems/proc.rst index 81bfe3c800cc..042c418f4090 100644 --- a/Documentation/filesystems/proc.rst +++ b/Documentation/filesystems/proc.rst @@ -933,8 +933,15 @@ meminfo ~~~~~~~ Provides information about distribution and utilization of memory. This -varies by architecture and compile options. The following is from a -16GB PIII, which has highmem enabled. You may not have all of these fields. +varies by architecture and compile options. Some of the counters reported +here overlap. The memory reported by the non overlapping counters may not +add up to the overall memory usage and the difference for some workloads +can be substantial. In many cases there are other means to find out +additional memory using subsystem specific interfaces, for instance +/proc/net/sockstat for TCP memory allocations. + +The following is from a 16GB PIII, which has highmem enabled. +You may not have all of these fields. :: @@ -1913,18 +1920,20 @@ if precise results are needed. 3.8 /proc/<pid>/fdinfo/<fd> - Information about opened file --------------------------------------------------------------- This file provides information associated with an opened file. The regular -files have at least three fields -- 'pos', 'flags' and 'mnt_id'. The 'pos' -represents the current offset of the opened file in decimal form [see lseek(2) -for details], 'flags' denotes the octal O_xxx mask the file has been -created with [see open(2) for details] and 'mnt_id' represents mount ID of -the file system containing the opened file [see 3.5 /proc/<pid>/mountinfo -for details]. +files have at least four fields -- 'pos', 'flags', 'mnt_id' and 'ino'. +The 'pos' represents the current offset of the opened file in decimal +form [see lseek(2) for details], 'flags' denotes the octal O_xxx mask the +file has been created with [see open(2) for details] and 'mnt_id' represents +mount ID of the file system containing the opened file [see 3.5 +/proc/<pid>/mountinfo for details]. 'ino' represents the inode number of +the file. A typical output is:: pos: 0 flags: 0100002 mnt_id: 19 + ino: 63107 All locks associated with a file descriptor are shown in its fdinfo too:: @@ -1941,6 +1950,7 @@ Eventfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 eventfd-count: 5a where 'eventfd-count' is hex value of a counter. @@ -1953,6 +1963,7 @@ Signalfd files pos: 0 flags: 04002 mnt_id: 9 + ino: 63107 sigmask: 0000000000000200 where 'sigmask' is hex value of the signal mask associated @@ -1966,6 +1977,7 @@ Epoll files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 tfd: 5 events: 1d data: ffffffffffffffff pos:0 ino:61af sdev:7 where 'tfd' is a target file descriptor number in decimal form, @@ -1982,6 +1994,8 @@ For inotify files the format is the following:: pos: 0 flags: 02000000 + mnt_id: 9 + ino: 63107 inotify wd:3 ino:9e7e sdev:800013 mask:800afce ignored_mask:0 fhandle-bytes:8 fhandle-type:1 f_handle:7e9e0000640d1b6d where 'wd' is a watch descriptor in decimal form, i.e. a target file @@ -2004,6 +2018,7 @@ For fanotify files the format is:: pos: 0 flags: 02 mnt_id: 9 + ino: 63107 fanotify flags:10 event-flags:0 fanotify mnt_id:12 mflags:40 mask:38 ignored_mask:40000003 fanotify ino:4f969 sdev:800013 mflags:0 mask:3b ignored_mask:40000000 fhandle-bytes:8 fhandle-type:1 f_handle:69f90400c275b5b4 @@ -2028,6 +2043,7 @@ Timerfd files pos: 0 flags: 02 mnt_id: 9 + ino: 63107 clockid: 0 ticks: 0 settime flags: 01 @@ -2042,6 +2058,22 @@ details]. 'it_value' is remaining time until the timer expiration. with TIMER_ABSTIME option which will be shown in 'settime flags', but 'it_value' still exhibits timer's remaining time. +DMA Buffer files +~~~~~~~~~~~~~~~~ + +:: + + pos: 0 + flags: 04002 + mnt_id: 9 + ino: 63107 + size: 32768 + count: 2 + exp_name: system-heap + +where 'size' is the size of the DMA buffer in bytes. 'count' is the file count of +the DMA buffer file. 'exp_name' is the name of the DMA buffer exporter. + 3.9 /proc/<pid>/map_files - Information about memory mapped files --------------------------------------------------------------------- This directory contains symbolic links which represent memory mapped files diff --git a/Documentation/firmware-guide/acpi/dsd/phy.rst b/Documentation/firmware-guide/acpi/dsd/phy.rst new file mode 100644 index 000000000000..680ad179e5f9 --- /dev/null +++ b/Documentation/firmware-guide/acpi/dsd/phy.rst @@ -0,0 +1,199 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========================= +MDIO bus and PHYs in ACPI +========================= + +The PHYs on an MDIO bus [1] are probed and registered using +fwnode_mdiobus_register_phy(). + +Later, for connecting these PHYs to their respective MACs, the PHYs registered +on the MDIO bus have to be referenced. + +This document introduces two _DSD properties that are to be used +for connecting PHYs on the MDIO bus [3] to the MAC layer. + +These properties are defined in accordance with the "Device +Properties UUID For _DSD" [2] document and the +daffd814-6eba-4d8c-8a91-bc9bbf4aa301 UUID must be used in the Device +Data Descriptors containing them. + +phy-handle +---------- +For each MAC node, a device property "phy-handle" is used to reference +the PHY that is registered on an MDIO bus. This is mandatory for +network interfaces that have PHYs connected to MAC via MDIO bus. + +During the MDIO bus driver initialization, PHYs on this bus are probed +using the _ADR object as shown below and are registered on the MDIO bus. + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +Later, during the MAC driver initialization, the registered PHY devices +have to be retrieved from the MDIO bus. For this, the MAC driver needs +references to the previously registered PHYs which are provided +as device object references (e.g. \_SB.MDI0.PHY1). + +phy-mode +-------- +The "phy-mode" _DSD property is used to describe the connection to +the PHY. The valid values for "phy-mode" are defined in [4]. + +managed +------- +Optional property, which specifies the PHY management type. +The valid values for "managed" are defined in [4]. + +fixed-link +---------- +The "fixed-link" is described by a data-only subnode of the +MAC port, which is linked in the _DSD package via +hierarchical data extension (UUID dbb8e3e6-5886-4ba6-8795-1319f52a966b +in accordance with [5] "_DSD Implementation Guide" document). +The subnode should comprise a required property ("speed") and +possibly the optional ones - complete list of parameters and +their values are specified in [4]. + +The following ASL example illustrates the usage of these properties. + +DSDT entry for MDIO node +------------------------ + +The MDIO bus has an SoC component (MDIO controller) and a platform +component (PHYs on the MDIO bus). + +a) Silicon Component +This node describes the MDIO controller, MDI0 +--------------------------------------------- + +.. code-block:: none + + Scope(_SB) + { + Device(MDI0) { + Name(_HID, "NXP0006") + Name(_CCA, 1) + Name(_UID, 0) + Name(_CRS, ResourceTemplate() { + Memory32Fixed(ReadWrite, MDI0_BASE, MDI_LEN) + Interrupt(ResourceConsumer, Level, ActiveHigh, Shared) + { + MDI0_IT + } + }) // end of _CRS for MDI0 + } // end of MDI0 + } + +b) Platform Component +The PHY1 and PHY2 nodes represent the PHYs connected to MDIO bus MDI0 +--------------------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.MDI0) + { + Device(PHY1) { + Name (_ADR, 0x1) + } // end of PHY1 + + Device(PHY2) { + Name (_ADR, 0x2) + } // end of PHY2 + } + +DSDT entries representing MAC nodes +----------------------------------- + +Below are the MAC nodes where PHY nodes are referenced. +phy-mode and phy-handle are used as explained earlier. +------------------------------------------------------ + +.. code-block:: none + + Scope(\_SB.MCE0.PR17) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY1} + } + }) + } + + Scope(\_SB.MCE0.PR18) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package (2) {"phy-mode", "rgmii-id"}, + Package (2) {"phy-handle", \_SB.MDI0.PHY2}} + } + }) + } + +MAC node example where "managed" property is specified. +------------------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH0) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + Package () {"managed", "in-band-status"} + } + }) + } + +MAC node example with a "fixed-link" subnode. +--------------------------------------------- + +.. code-block:: none + + Scope(\_SB.PP21.ETH1) + { + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"phy-mode", "sgmii"}, + }, + ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), + Package () { + Package () {"fixed-link", "LNK0"} + } + }) + Name (LNK0, Package(){ // Data-only subnode of port + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"speed", 1000}, + Package () {"full-duplex", 1} + } + }) + } + +References +========== + +[1] Documentation/networking/phy.rst + +[2] https://www.uefi.org/sites/default/files/resources/_DSD-device-properties-UUID.pdf + +[3] Documentation/firmware-guide/acpi/DSD-properties-rules.rst + +[4] Documentation/devicetree/bindings/net/ethernet-controller.yaml + +[5] https://github.com/UEFI/DSD-Guide/blob/main/dsd-guide.pdf diff --git a/Documentation/firmware-guide/acpi/index.rst b/Documentation/firmware-guide/acpi/index.rst index f72b5f1769fb..a99ee402b212 100644 --- a/Documentation/firmware-guide/acpi/index.rst +++ b/Documentation/firmware-guide/acpi/index.rst @@ -11,6 +11,7 @@ ACPI Support dsd/graph dsd/data-node-references dsd/leds + dsd/phy enumeration osi method-customizing diff --git a/Documentation/fpga/dfl.rst b/Documentation/fpga/dfl.rst index f3a1223f2517..75df90d1e54c 100644 --- a/Documentation/fpga/dfl.rst +++ b/Documentation/fpga/dfl.rst @@ -57,7 +57,7 @@ FPGA Interface Unit (FIU) represents a standalone functional unit for the interface to FPGA, e.g. the FPGA Management Engine (FME) and Port (more descriptions on FME and Port in later sections). -Accelerated Function Unit (AFU) represents a FPGA programmable region and +Accelerated Function Unit (AFU) represents an FPGA programmable region and always connects to a FIU (e.g. a Port) as its child as illustrated above. Private Features represent sub features of the FIU and AFU. They could be @@ -311,7 +311,7 @@ The driver organization in virtualization case is illustrated below: | PCI PF Device | | | PCI VF Device | +---------------+ | +---------------+ -FPGA PCIe device driver is always loaded first once a FPGA PCIe PF or VF device +FPGA PCIe device driver is always loaded first once an FPGA PCIe PF or VF device is detected. It: * Finishes enumeration on both FPGA PCIe PF and VF device using common diff --git a/Documentation/gpu/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc.rst index cc89b0fc11df..f7ff7e1309de 100644 --- a/Documentation/gpu/amdgpu-dc.rst +++ b/Documentation/gpu/amdgpu-dc.rst @@ -66,3 +66,9 @@ Display Core ============ **WIP** + +FreeSync Video +-------------- + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: FreeSync Video diff --git a/Documentation/gpu/amdgpu.rst b/Documentation/gpu/amdgpu.rst index 2062a6023678..364680cdad2e 100644 --- a/Documentation/gpu/amdgpu.rst +++ b/Documentation/gpu/amdgpu.rst @@ -300,4 +300,25 @@ pcie_replay_count .. kernel-doc:: drivers/gpu/drm/amd/amdgpu/amdgpu_device.c :doc: pcie_replay_count ++GPU SmartShift Information +============================ + +GPU SmartShift information via sysfs + +smartshift_apu_power +-------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_apu_power +smartshift_dgpu_power +--------------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_dgpu_power + +smartshift_bias +--------------- + +.. kernel-doc:: drivers/gpu/drm/amd/pm/amdgpu_pm.c + :doc: smartshift_bias diff --git a/Documentation/gpu/driver-uapi.rst b/Documentation/gpu/driver-uapi.rst new file mode 100644 index 000000000000..4411e6919a3d --- /dev/null +++ b/Documentation/gpu/driver-uapi.rst @@ -0,0 +1,8 @@ +=============== +DRM Driver uAPI +=============== + +drm/i915 uAPI +============= + +.. kernel-doc:: include/uapi/drm/i915_drm.h diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 12272b168580..06af044c882f 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,18 @@ update it, its value is mostly useless. The DRM core prints it to the kernel log at initialization time and passes it to userspace through the DRM_IOCTL_VERSION ioctl. +Managing Ownership of the Framebuffer Aperture +---------------------------------------------- + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :doc: overview + +.. kernel-doc:: include/drm/drm_aperture.h + :internal: + +.. kernel-doc:: drivers/gpu/drm/drm_aperture.c + :export: + Device Instance and Driver Handling ----------------------------------- diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index 21be6deadc12..d5a73fa2c9ef 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -469,8 +469,8 @@ DRM MM Range Allocator Function References .. kernel-doc:: drivers/gpu/drm/drm_mm.c :export: -DRM Cache Handling -================== +DRM Cache Handling and Fast WC memcpy() +======================================= .. kernel-doc:: drivers/gpu/drm/drm_cache.c :export: diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 486c720f3890..42ce0196930a 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -210,13 +210,13 @@ DPIO .. kernel-doc:: drivers/gpu/drm/i915/display/intel_dpio_phy.c :doc: DPIO -CSR firmware support for DMC ----------------------------- +DMC Firmware Support +-------------------- -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c - :doc: csr support for dmc +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c + :doc: DMC Firmware Support -.. kernel-doc:: drivers/gpu/drm/i915/display/intel_csr.c +.. kernel-doc:: drivers/gpu/drm/i915/display/intel_dmc.c :internal: Video BIOS Table (VBT) @@ -537,7 +537,7 @@ The HuC FW layout is the same as the GuC one, see `GuC Firmware Layout`_ DMC --- -See `CSR firmware support for DMC`_ +See `DMC Firmware Support`_ Tracing ======= diff --git a/Documentation/gpu/index.rst b/Documentation/gpu/index.rst index ec4bc72438e4..b9c1214d8f23 100644 --- a/Documentation/gpu/index.rst +++ b/Documentation/gpu/index.rst @@ -10,6 +10,7 @@ Linux GPU Driver Developer's Guide drm-kms drm-kms-helpers drm-uapi + driver-uapi drm-client drivers backlight diff --git a/Documentation/gpu/rfc/i915_gem_lmem.rst b/Documentation/gpu/rfc/i915_gem_lmem.rst new file mode 100644 index 000000000000..675ba8620d66 --- /dev/null +++ b/Documentation/gpu/rfc/i915_gem_lmem.rst @@ -0,0 +1,131 @@ +========================= +I915 DG1/LMEM RFC Section +========================= + +Upstream plan +============= +For upstream the overall plan for landing all the DG1 stuff and turning it for +real, with all the uAPI bits is: + +* Merge basic HW enabling of DG1(still without pciid) +* Merge the uAPI bits behind special CONFIG_BROKEN(or so) flag + * At this point we can still make changes, but importantly this lets us + start running IGTs which can utilize local-memory in CI +* Convert over to TTM, make sure it all keeps working. Some of the work items: + * TTM shrinker for discrete + * dma_resv_lockitem for full dma_resv_lock, i.e not just trylock + * Use TTM CPU pagefault handler + * Route shmem backend over to TTM SYSTEM for discrete + * TTM purgeable object support + * Move i915 buddy allocator over to TTM + * MMAP ioctl mode(see `I915 MMAP`_) + * SET/GET ioctl caching(see `I915 SET/GET CACHING`_) +* Send RFC(with mesa-dev on cc) for final sign off on the uAPI +* Add pciid for DG1 and turn on uAPI for real + +New object placement and region query uAPI +========================================== +Starting from DG1 we need to give userspace the ability to allocate buffers from +device local-memory. Currently the driver supports gem_create, which can place +buffers in system memory via shmem, and the usual assortment of other +interfaces, like dumb buffers and userptr. + +To support this new capability, while also providing a uAPI which will work +beyond just DG1, we propose to offer three new bits of uAPI: + +DRM_I915_QUERY_MEMORY_REGIONS +----------------------------- +New query ID which allows userspace to discover the list of supported memory +regions(like system-memory and local-memory) for a given device. We identify +each region with a class and instance pair, which should be unique. The class +here would be DEVICE or SYSTEM, and the instance would be zero, on platforms +like DG1. + +Side note: The class/instance design is borrowed from our existing engine uAPI, +where we describe every physical engine in terms of its class, and the +particular instance, since we can have more than one per class. + +In the future we also want to expose more information which can further +describe the capabilities of a region. + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_memory_class drm_i915_gem_memory_class_instance drm_i915_memory_region_info drm_i915_query_memory_regions + +GEM_CREATE_EXT +-------------- +New ioctl which is basically just gem_create but now allows userspace to provide +a chain of possible extensions. Note that if we don't provide any extensions and +set flags=0 then we get the exact same behaviour as gem_create. + +Side note: We also need to support PXP[1] in the near future, which is also +applicable to integrated platforms, and adds its own gem_create_ext extension, +which basically lets userspace mark a buffer as "protected". + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_create_ext + +I915_GEM_CREATE_EXT_MEMORY_REGIONS +---------------------------------- +Implemented as an extension for gem_create_ext, we would now allow userspace to +optionally provide an immutable list of preferred placements at creation time, +in priority order, for a given buffer object. For the placements we expect +them each to use the class/instance encoding, as per the output of the regions +query. Having the list in priority order will be useful in the future when +placing an object, say during eviction. + +.. kernel-doc:: include/uapi/drm/i915_drm.h + :functions: drm_i915_gem_create_ext_memory_regions + +One fair criticism here is that this seems a little over-engineered[2]. If we +just consider DG1 then yes, a simple gem_create.flags or something is totally +all that's needed to tell the kernel to allocate the buffer in local-memory or +whatever. However looking to the future we need uAPI which can also support +upcoming Xe HP multi-tile architecture in a sane way, where there can be +multiple local-memory instances for a given device, and so using both class and +instance in our uAPI to describe regions is desirable, although specifically +for DG1 it's uninteresting, since we only have a single local-memory instance. + +Existing uAPI issues +==================== +Some potential issues we still need to resolve. + +I915 MMAP +--------- +In i915 there are multiple ways to MMAP GEM object, including mapping the same +object using different mapping types(WC vs WB), i.e multiple active mmaps per +object. TTM expects one MMAP at most for the lifetime of the object. If it +turns out that we have to backpedal here, there might be some potential +userspace fallout. + +I915 SET/GET CACHING +-------------------- +In i915 we have set/get_caching ioctl. TTM doesn't let us to change this, but +DG1 doesn't support non-snooped pcie transactions, so we can just always +allocate as WB for smem-only buffers. If/when our hw gains support for +non-snooped pcie transactions then we must fix this mode at allocation time as +a new GEM extension. + +This is related to the mmap problem, because in general (meaning, when we're +not running on intel cpus) the cpu mmap must not, ever, be inconsistent with +allocation mode. + +Possible idea is to let the kernel picks the mmap mode for userspace from the +following table: + +smem-only: WB. Userspace does not need to call clflush. + +smem+lmem: We only ever allow a single mode, so simply allocate this as uncached +memory, and always give userspace a WC mapping. GPU still does snooped access +here(assuming we can't turn it off like on DG1), which is a bit inefficient. + +lmem only: always WC + +This means on discrete you only get a single mmap mode, all others must be +rejected. That's probably going to be a new default mode or something like +that. + +Links +===== +[1] https://patchwork.freedesktop.org/series/86798/ + +[2] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/5599#note_553791 diff --git a/Documentation/gpu/rfc/index.rst b/Documentation/gpu/rfc/index.rst index a8621f7dab8b..05670442ca1b 100644 --- a/Documentation/gpu/rfc/index.rst +++ b/Documentation/gpu/rfc/index.rst @@ -15,3 +15,7 @@ host such documentation: * Once the code has landed move all the documentation to the right places in the main core, helper or driver sections. + +.. toctree:: + + i915_gem_lmem.rst diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 7ff9fac10d8b..12e61869939e 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -546,6 +546,8 @@ There's a bunch of issues with it: this (together with the drm_minor->drm_device move) would allow us to remove debugfs_init. +Previous RFC that hasn't landed yet: https://lore.kernel.org/dri-devel/20200513114130.28641-2-wambui.karugax@gmail.com/ + Contact: Daniel Vetter Level: Intermediate diff --git a/Documentation/i2c/i2c-sysfs.rst b/Documentation/i2c/i2c-sysfs.rst new file mode 100644 index 000000000000..6b68b95cd427 --- /dev/null +++ b/Documentation/i2c/i2c-sysfs.rst @@ -0,0 +1,395 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============== +Linux I2C Sysfs +=============== + +Overview +======== + +I2C topology can be complex because of the existence of I2C MUX +(I2C Multiplexer). The Linux +kernel abstracts the MUX channels into logical I2C bus numbers. However, there +is a gap of knowledge to map from the I2C bus physical number and MUX topology +to logical I2C bus number. This doc is aimed to fill in this gap, so the +audience (hardware engineers and new software developers for example) can learn +the concept of logical I2C buses in the kernel, by knowing the physical I2C +topology and navigating through the I2C sysfs in Linux shell. This knowledge is +useful and essential to use ``i2c-tools`` for the purpose of development and +debugging. + +Target audience +--------------- + +People who need to use Linux shell to interact with I2C subsystem on a system +which the Linux is running on. + +Prerequisites +------------- + +1. Knowledge of general Linux shell file system commands and operations. + +2. General knowledge of I2C, I2C MUX and I2C topology. + +Location of I2C Sysfs +===================== + +Typically, the Linux Sysfs filesystem is mounted at the ``/sys`` directory, +so you can find the I2C Sysfs under ``/sys/bus/i2c/devices`` +where you can directly ``cd`` to it. +There is a list of symbolic links under that directory. The links that +start with ``i2c-`` are I2C buses, which may be either physical or logical. The +other links that begin with numbers and end with numbers are I2C devices, where +the first number is I2C bus number, and the second number is I2C address. + +Google Pixel 3 phone for example:: + + blueline:/sys/bus/i2c/devices $ ls + 0-0008 0-0061 1-0028 3-0043 4-0036 4-0041 i2c-1 i2c-3 + 0-000c 0-0066 2-0049 4-000b 4-0040 i2c-0 i2c-2 i2c-4 + +``i2c-2`` is an I2C bus whose number is 2, and ``2-0049`` is an I2C device +on bus 2 address 0x49 bound with a kernel driver. + +Terminologies +============= + +First, let us define a couple of terminologies to avoid confusions in the later +sections. + +(Physical) I2C Bus Controller +----------------------------- + +The hardware system that the Linux kernel is running on may have multiple +physical I2C bus controllers. The controllers are hardware and physical, and the +system may define multiple registers in the memory space to manipulate the +controllers. Linux kernel has I2C bus drivers under source directory +``drivers/i2c/busses`` to translate kernel I2C API into register +operations for different systems. This terminology is not limited to Linux +kernel only. + +I2C Bus Physical Number +----------------------- + +For each physical I2C bus controller, the system vendor may assign a physical +number to each controller. For example, the first I2C bus controller which has +the lowest register addresses may be called ``I2C-0``. + +Logical I2C Bus +--------------- + +Every I2C bus number you see in Linux I2C Sysfs is a logical I2C bus with a +number assigned. This is similar to the fact that software code is usually +written upon virtual memory space, instead of physical memory space. + +Each logical I2C bus may be an abstraction of a physical I2C bus controller, or +an abstraction of a channel behind an I2C MUX. In case it is an abstraction of a +MUX channel, whenever we access an I2C device via a such logical bus, the kernel +will switch the I2C MUX for you to the proper channel as part of the +abstraction. + +Physical I2C Bus +---------------- + +If the logical I2C bus is a direct abstraction of a physical I2C bus controller, +let us call it a physical I2C bus. + +Caveat +------ + +This may be a confusing part for people who only know about the physical I2C +design of a board. It is actually possible to rename the I2C bus physical number +to a different number in logical I2C bus level in Device Tree Source (DTS) under +section ``aliases``. See +`arch/arm/boot/dts/nuvoton-npcm730-gsj.dts +<../../arch/arm/boot/dts/nuvoton-npcm730-gsj.dts>`_ +for an example of DTS file. + +Best Practice: **(To kernel software developers)** It is better to keep the I2C +bus physical number the same as their corresponding logical I2C bus number, +instead of renaming or mapping them, so that it may be less confusing to other +users. These physical I2C buses can be served as good starting points for I2C +MUX fanouts. For the following examples, we will assume that the physical I2C +bus has a number same as their I2C bus physical number. + +Walk through Logical I2C Bus +============================ + +For the following content, we will use a more complex I2C topology as an +example. Here is a brief graph for the I2C topology. If you do not understand +this graph at the first glance, do not be afraid to continue reading this doc +and review it when you finish reading. + +:: + + i2c-7 (physical I2C bus controller 7) + `-- 7-0071 (4-channel I2C MUX at 0x71) + |-- i2c-60 (channel-0) + |-- i2c-73 (channel-1) + | |-- 73-0040 (I2C sensor device with hwmon directory) + | |-- 73-0070 (I2C MUX at 0x70, exists in DTS, but failed to probe) + | `-- 73-0072 (8-channel I2C MUX at 0x72) + | |-- i2c-78 (channel-0) + | |-- ... (channel-1...6, i2c-79...i2c-84) + | `-- i2c-85 (channel-7) + |-- i2c-86 (channel-2) + `-- i2c-203 (channel-3) + +Distinguish Physical and Logical I2C Bus +---------------------------------------- + +One simple way to distinguish between a physical I2C bus and a logical I2C bus, +is to read the symbolic link ``device`` under the I2C bus directory by using +command ``ls -l`` or ``readlink``. + +An alternative symbolic link to check is ``mux_device``. This link only exists +in logical I2C bus directory which is fanned out from another I2C bus. +Reading this link will also tell you which I2C MUX device created +this logical I2C bus. + +If the symbolic link points to a directory ending with ``.i2c``, it should be a +physical I2C bus, directly abstracting a physical I2C bus controller. For +example:: + + $ readlink /sys/bus/i2c/devices/i2c-7/device + ../../f0087000.i2c + $ ls /sys/bus/i2c/devices/i2c-7/mux_device + ls: /sys/bus/i2c/devices/i2c-7/mux_device: No such file or directory + +In this case, ``i2c-7`` is a physical I2C bus, so it does not have the symbolic +link ``mux_device`` under its directory. And if the kernel software developer +follows the common practice by not renaming physical I2C buses, this should also +mean the physical I2C bus controller 7 of the system. + +On the other hand, if the symbolic link points to another I2C bus, the I2C bus +presented by the current directory has to be a logical bus. The I2C bus pointed +by the link is the parent bus which may be either a physical I2C bus or a +logical one. In this case, the I2C bus presented by the current directory +abstracts an I2C MUX channel under the parent bus. + +For example:: + + $ readlink /sys/bus/i2c/devices/i2c-73/device + ../../i2c-7 + $ readlink /sys/bus/i2c/devices/i2c-73/mux_device + ../7-0071 + +``i2c-73`` is a logical bus fanout by an I2C MUX under ``i2c-7`` +whose I2C address is 0x71. +Whenever we access an I2C device with bus 73, the kernel will always +switch the I2C MUX addressed 0x71 to the proper channel for you as part of the +abstraction. + +Finding out Logical I2C Bus Number +---------------------------------- + +In this section, we will describe how to find out the logical I2C bus number +representing certain I2C MUX channels based on the knowledge of physical +hardware I2C topology. + +In this example, we have a system which has a physical I2C bus 7 and not renamed +in DTS. There is a 4-channel MUX at address 0x71 on that bus. There is another +8-channel MUX at address 0x72 behind the channel 1 of the 0x71 MUX. Let us +navigate through Sysfs and find out the logical I2C bus number of the channel 3 +of the 0x72 MUX. + +First of all, let us go to the directory of ``i2c-7``:: + + ~$ cd /sys/bus/i2c/devices/i2c-7 + /sys/bus/i2c/devices/i2c-7$ ls + 7-0071 i2c-60 name subsystem + delete_device i2c-73 new_device uevent + device i2c-86 of_node + i2c-203 i2c-dev power + +There, we see the 0x71 MUX as ``7-0071``. Go inside it:: + + /sys/bus/i2c/devices/i2c-7$ cd 7-0071/ + /sys/bus/i2c/devices/i2c-7/7-0071$ ls -l + channel-0 channel-3 modalias power + channel-1 driver name subsystem + channel-2 idle_state of_node uevent + +Read the link ``channel-1`` using ``readlink`` or ``ls -l``:: + + /sys/bus/i2c/devices/i2c-7/7-0071$ readlink channel-1 + ../i2c-73 + +We find out that the channel 1 of 0x71 MUX on ``i2c-7`` is assigned +with a logical I2C bus number of 73. +Let us continue the journey to directory ``i2c-73`` in either ways:: + + # cd to i2c-73 under I2C Sysfs root + /sys/bus/i2c/devices/i2c-7/7-0071$ cd /sys/bus/i2c/devices/i2c-73 + /sys/bus/i2c/devices/i2c-73$ + + # cd the channel symbolic link + /sys/bus/i2c/devices/i2c-7/7-0071$ cd channel-1 + /sys/bus/i2c/devices/i2c-7/7-0071/channel-1$ + + # cd the link content + /sys/bus/i2c/devices/i2c-7/7-0071$ cd ../i2c-73 + /sys/bus/i2c/devices/i2c-7/i2c-73$ + +Either ways, you will end up in the directory of ``i2c-73``. Similar to above, +we can now find the 0x72 MUX and what logical I2C bus numbers +that its channels are assigned:: + + /sys/bus/i2c/devices/i2c-73$ ls + 73-0040 device i2c-83 new_device + 73-004e i2c-78 i2c-84 of_node + 73-0050 i2c-79 i2c-85 power + 73-0070 i2c-80 i2c-dev subsystem + 73-0072 i2c-81 mux_device uevent + delete_device i2c-82 name + /sys/bus/i2c/devices/i2c-73$ cd 73-0072 + /sys/bus/i2c/devices/i2c-73/73-0072$ ls + channel-0 channel-4 driver of_node + channel-1 channel-5 idle_state power + channel-2 channel-6 modalias subsystem + channel-3 channel-7 name uevent + /sys/bus/i2c/devices/i2c-73/73-0072$ readlink channel-3 + ../i2c-81 + +There, we find out the logical I2C bus number of the channel 3 of the 0x72 MUX +is 81. We can later use this number to switch to its own I2C Sysfs directory or +issue ``i2c-tools`` commands. + +Tip: Once you understand the I2C topology with MUX, command +`i2cdetect -l +<https://manpages.debian.org/unstable/i2c-tools/i2cdetect.8.en.html>`_ +in +`I2C Tools +<https://i2c.wiki.kernel.org/index.php/I2C_Tools>`_ +can give you +an overview of the I2C topology easily, if it is available on your system. For +example:: + + $ i2cdetect -l | grep -e '\-73' -e _7 | sort -V + i2c-7 i2c npcm_i2c_7 I2C adapter + i2c-73 i2c i2c-7-mux (chan_id 1) I2C adapter + i2c-78 i2c i2c-73-mux (chan_id 0) I2C adapter + i2c-79 i2c i2c-73-mux (chan_id 1) I2C adapter + i2c-80 i2c i2c-73-mux (chan_id 2) I2C adapter + i2c-81 i2c i2c-73-mux (chan_id 3) I2C adapter + i2c-82 i2c i2c-73-mux (chan_id 4) I2C adapter + i2c-83 i2c i2c-73-mux (chan_id 5) I2C adapter + i2c-84 i2c i2c-73-mux (chan_id 6) I2C adapter + i2c-85 i2c i2c-73-mux (chan_id 7) I2C adapter + +Pinned Logical I2C Bus Number +----------------------------- + +If not specified in DTS, when an I2C MUX driver is applied and the MUX device is +successfully probed, the kernel will assign the MUX channels with a logical bus +number based on the current biggest logical bus number incrementally. For +example, if the system has ``i2c-15`` as the highest logical bus number, and a +4-channel MUX is applied successfully, we will have ``i2c-16`` for the +MUX channel 0, and all the way to ``i2c-19`` for the MUX channel 3. + +The kernel software developer is able to pin the fanout MUX channels to a static +logical I2C bus number in the DTS. This doc will not go through the details on +how to implement this in DTS, but we can see an example in: +`arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts +<../../arch/arm/boot/dts/aspeed-bmc-facebook-wedge400.dts>`_ + +In the above example, there is an 8-channel I2C MUX at address 0x70 on physical +I2C bus 2. The channel 2 of the MUX is defined as ``imux18`` in DTS, +and pinned to logical I2C bus number 18 with the line of ``i2c18 = &imux18;`` +in section ``aliases``. + +Take it further, it is possible to design a logical I2C bus number schema that +can be easily remembered by humans or calculated arithmetically. For example, we +can pin the fanout channels of a MUX on bus 3 to start at 30. So 30 will be the +logical bus number of the channel 0 of the MUX on bus 3, and 37 will be the +logical bus number of the channel 7 of the MUX on bus 3. + +I2C Devices +=========== + +In previous sections, we mostly covered the I2C bus. In this section, let us see +what we can learn from the I2C device directory whose link name is in the format +of ``${bus}-${addr}``. The ``${bus}`` part in the name is a logical I2C bus +decimal number, while the ``${addr}`` part is a hex number of the I2C address +of each device. + +I2C Device Directory Content +---------------------------- + +Inside each I2C device directory, there is a file named ``name``. +This file tells what device name it was used for the kernel driver to +probe this device. Use command ``cat`` to read its content. For example:: + + /sys/bus/i2c/devices/i2c-73$ cat 73-0040/name + ina230 + /sys/bus/i2c/devices/i2c-73$ cat 73-0070/name + pca9546 + /sys/bus/i2c/devices/i2c-73$ cat 73-0072/name + pca9547 + +There is a symbolic link named ``driver`` to tell what Linux kernel driver was +used to probe this device:: + + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0040/driver + /sys/bus/i2c/drivers/ina2xx + /sys/bus/i2c/devices/i2c-73$ readlink -f 73-0072/driver + /sys/bus/i2c/drivers/pca954x + +But if the link ``driver`` does not exist at the first place, +it may mean that the kernel driver failed to probe this device due to +some errors. The error may be found in ``dmesg``:: + + /sys/bus/i2c/devices/i2c-73$ ls 73-0070/driver + ls: 73-0070/driver: No such file or directory + /sys/bus/i2c/devices/i2c-73$ dmesg | grep 73-0070 + pca954x 73-0070: probe failed + pca954x 73-0070: probe failed + +Depending on what the I2C device is and what kernel driver was used to probe the +device, we may have different content in the device directory. + +I2C MUX Device +-------------- + +While you may be already aware of this in previous sections, an I2C MUX device +will have symbolic link ``channel-*`` inside its device directory. +These symbolic links point to their logical I2C bus directories:: + + /sys/bus/i2c/devices/i2c-73$ ls -l 73-0072/channel-* + lrwxrwxrwx ... 73-0072/channel-0 -> ../i2c-78 + lrwxrwxrwx ... 73-0072/channel-1 -> ../i2c-79 + lrwxrwxrwx ... 73-0072/channel-2 -> ../i2c-80 + lrwxrwxrwx ... 73-0072/channel-3 -> ../i2c-81 + lrwxrwxrwx ... 73-0072/channel-4 -> ../i2c-82 + lrwxrwxrwx ... 73-0072/channel-5 -> ../i2c-83 + lrwxrwxrwx ... 73-0072/channel-6 -> ../i2c-84 + lrwxrwxrwx ... 73-0072/channel-7 -> ../i2c-85 + +I2C Sensor Device / Hwmon +------------------------- + +I2C sensor device is also common to see. If they are bound by a kernel hwmon +(Hardware Monitoring) driver successfully, you will see a ``hwmon`` directory +inside the I2C device directory. Keep digging into it, you will find the Hwmon +Sysfs for the I2C sensor device:: + + /sys/bus/i2c/devices/i2c-73/73-0040/hwmon/hwmon17$ ls + curr1_input in0_lcrit_alarm name subsystem + device in1_crit power uevent + in0_crit in1_crit_alarm power1_crit update_interval + in0_crit_alarm in1_input power1_crit_alarm + in0_input in1_lcrit power1_input + in0_lcrit in1_lcrit_alarm shunt_resistor + +For more info on the Hwmon Sysfs, refer to the doc: + +`Naming and data format standards for sysfs files +<../hwmon/sysfs-interface.rst>`_ + +Instantiate I2C Devices in I2C Sysfs +------------------------------------ + +Refer to the doc: + +`How to instantiate I2C devices, Method 4: Instantiate from user-space +<instantiating-devices.rst#method-4-instantiate-from-user-space>`_ diff --git a/Documentation/networking/af_xdp.rst b/Documentation/networking/af_xdp.rst index 2ccc5644cc98..42576880aa4a 100644 --- a/Documentation/networking/af_xdp.rst +++ b/Documentation/networking/af_xdp.rst @@ -290,19 +290,19 @@ round-robin example of distributing packets is shown below: #define MAX_SOCKS 16 struct { - __uint(type, BPF_MAP_TYPE_XSKMAP); - __uint(max_entries, MAX_SOCKS); - __uint(key_size, sizeof(int)); - __uint(value_size, sizeof(int)); + __uint(type, BPF_MAP_TYPE_XSKMAP); + __uint(max_entries, MAX_SOCKS); + __uint(key_size, sizeof(int)); + __uint(value_size, sizeof(int)); } xsks_map SEC(".maps"); static unsigned int rr; SEC("xdp_sock") int xdp_sock_prog(struct xdp_md *ctx) { - rr = (rr + 1) & (MAX_SOCKS - 1); + rr = (rr + 1) & (MAX_SOCKS - 1); - return bpf_redirect_map(&xsks_map, rr, XDP_DROP); + return bpf_redirect_map(&xsks_map, rr, XDP_DROP); } Note, that since there is only a single set of FILL and COMPLETION @@ -379,7 +379,7 @@ would look like this for the TX path: .. code-block:: c if (xsk_ring_prod__needs_wakeup(&my_tx_ring)) - sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); + sendto(xsk_socket__fd(xsk_handle), NULL, 0, MSG_DONTWAIT, NULL, 0); I.e., only use the syscall if the flag is set. @@ -442,9 +442,9 @@ purposes. The supported statistics are shown below: .. code-block:: c struct xdp_statistics { - __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ - __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ - __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 rx_dropped; /* Dropped for reasons other than invalid desc */ + __u64 rx_invalid_descs; /* Dropped due to invalid descriptor */ + __u64 tx_invalid_descs; /* Dropped due to invalid descriptor */ }; XDP_OPTIONS getsockopt @@ -483,15 +483,15 @@ like this: .. code-block:: c // struct xdp_rxtx_ring { - // __u32 *producer; - // __u32 *consumer; - // struct xdp_desc *desc; + // __u32 *producer; + // __u32 *consumer; + // struct xdp_desc *desc; // }; // struct xdp_umem_ring { - // __u32 *producer; - // __u32 *consumer; - // __u64 *desc; + // __u32 *producer; + // __u32 *consumer; + // __u64 *desc; // }; // typedef struct xdp_rxtx_ring RING; diff --git a/Documentation/networking/caif/caif.rst b/Documentation/networking/caif/caif.rst index 81a14373d780..d922d419c513 100644 --- a/Documentation/networking/caif/caif.rst +++ b/Documentation/networking/caif/caif.rst @@ -69,9 +69,9 @@ There are debugfs parameters provided for serial communication. - 0x01 - tty->warned is on. - 0x04 - tty->packed is on. - - 0x08 - tty->flow_stopped is on. + - 0x08 - tty->flow.tco_stopped is on. - 0x10 - tty->hw_stopped is on. - - 0x20 - tty->stopped is on. + - 0x20 - tty->flow.stopped is on. * last_tx_msg: Binary blob Prints the last transmitted frame. diff --git a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst index 70643b58de05..4118384cf8eb 100644 --- a/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst +++ b/Documentation/networking/device_drivers/cellular/qualcomm/rmnet.rst @@ -27,34 +27,136 @@ these MAP frames and send them to appropriate PDN's. 2. Packet format ================ -a. MAP packet (data / control) +a. MAP packet v1 (data / control) -MAP header has the same endianness of the IP packet. +MAP header fields are in big endian format. Packet format:: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8-15 16-31 Function Command / Data Reserved Pad Multiplexer ID Payload length - Bit 32 - x - Function Raw Bytes + + Bit 32-x + Function Raw bytes Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command -or data packet. Control packet is used for transport level flow control. Data +or data packet. Command packet is used for transport level flow control. Data packets are standard IP packets. -Reserved bits are usually zeroed out and to be ignored by receiver. +Reserved bits must be zero when sent and ignored when received. -Padding is number of bytes to be added for 4 byte alignment if required by -hardware. +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. Multiplexer ID is to indicate the PDN on which data has to be sent. Payload length includes the padding length but does not include MAP header length. -b. MAP packet (command specific):: +b. Map packet v4 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Reserved Pad Multiplexer ID Payload length + + Bit 32-(x-33) (x-32)-x + Function Raw bytes Checksum offload header + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Reserved bits must be zero when sent and ignored when received. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +Checksum offload header, has the information about the checksum processing done +by the hardware.Checksum offload header fields are in big endian format. + +Packet format:: + + Bit 0-14 15 16-31 + Function Reserved Valid Checksum start offset + + Bit 31-47 48-64 + Function Checksum length Checksum value + +Reserved bits must be zero when sent and ignored when received. + +Valid bit indicates whether the partial checksum is calculated and is valid. +Set to 1, if its is valid. Set to 0 otherwise. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Checksum start offset, Indicates the offset in bytes from the beginning of the +IP header, from which modem computed checksum. + +Checksum length is the Length in bytes starting from CKSUM_START_OFFSET, +over which checksum is computed. + +Checksum value, indicates the checksum computed. + +c. MAP packet v5 (data / control) + +MAP header fields are in big endian format. + +Packet format:: + + Bit 0 1 2-7 8-15 16-31 + Function Command / Data Next header Pad Multiplexer ID Payload length + + Bit 32-x + Function Raw bytes + +Command (1)/ Data (0) bit value is to indicate if the packet is a MAP command +or data packet. Command packet is used for transport level flow control. Data +packets are standard IP packets. + +Next header is used to indicate the presence of another header, currently is +limited to checksum header. + +Padding is the number of bytes to be appended to the payload to +ensure 4 byte alignment. + +Multiplexer ID is to indicate the PDN on which data has to be sent. + +Payload length includes the padding length but does not include MAP header +length. + +d. Checksum offload header v5 + +Checksum offload header fields are in big endian format. + + Bit 0 - 6 7 8-15 16-31 + Function Header Type Next Header Checksum Valid Reserved + +Header Type is to indicate the type of header, this usually is set to CHECKSUM + +Header types += ========================================== +0 Reserved +1 Reserved +2 checksum header + +Checksum Valid is to indicate whether the header checksum is valid. Value of 1 +implies that checksum is calculated on this packet and is valid, value of 0 +indicates that the calculated packet checksum is invalid. + +Reserved bits must be zero when sent and ignored when received. + +e. MAP packet v1/v5 (command specific):: - Bit 0 1 2-7 8 - 15 16 - 31 + Bit 0 1 2-7 8 - 15 16 - 31 Function Command Reserved Pad Multiplexer ID Payload length Bit 32 - 39 40 - 45 46 - 47 48 - 63 Function Command name Reserved Command Type Reserved @@ -74,7 +176,7 @@ Command types 3 is for error during processing of commands = ========================================== -c. Aggregation +f. Aggregation Aggregation is multiple MAP packets (can be data or command) delivered to rmnet in a single linear skb. rmnet will process the individual diff --git a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst index f8c6469f2bd2..01b2a69b0cb0 100644 --- a/Documentation/networking/device_drivers/ethernet/amazon/ena.rst +++ b/Documentation/networking/device_drivers/ethernet/amazon/ena.rst @@ -11,12 +11,12 @@ ENA is a networking interface designed to make good use of modern CPU features and system architectures. The ENA device exposes a lightweight management interface with a -minimal set of memory mapped registers and extendable command set +minimal set of memory mapped registers and extendible command set through an Admin Queue. The driver supports a range of ENA devices, is link-speed independent -(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc.), and has -a negotiated and extendable feature set. +(i.e., the same driver is used for 10GbE, 25GbE, 40GbE, etc), and has +a negotiated and extendible feature set. Some ENA devices support SR-IOV. This driver is used for both the SR-IOV Physical Function (PF) and Virtual Function (VF) devices. @@ -27,9 +27,9 @@ is advertised by the device via the Admin Queue), a dedicated MSI-X interrupt vector per Tx/Rx queue pair, adaptive interrupt moderation, and CPU cacheline optimized data placement. -The ENA driver supports industry standard TCP/IP offload features such -as checksum offload and TCP transmit segmentation offload (TSO). -Receive-side scaling (RSS) is supported for multi-core scaling. +The ENA driver supports industry standard TCP/IP offload features such as +checksum offload. Receive-side scaling (RSS) is supported for multi-core +scaling. The ENA driver and its corresponding devices implement health monitoring mechanisms such as watchdog, enabling the device and driver @@ -38,22 +38,20 @@ debug logs. Some of the ENA devices support a working mode called Low-latency Queue (LLQ), which saves several more microseconds. - ENA Source Code Directory Structure =================================== ================= ====================================================== ena_com.[ch] Management communication layer. This layer is - responsible for the handling all the management - (admin) communication between the device and the - driver. + responsible for the handling all the management + (admin) communication between the device and the + driver. ena_eth_com.[ch] Tx/Rx data path. ena_admin_defs.h Definition of ENA management interface. ena_eth_io_defs.h Definition of ENA data path interface. ena_common_defs.h Common definitions for ena_com layer. ena_regs_defs.h Definition of ENA PCI memory-mapped (MMIO) registers. ena_netdev.[ch] Main Linux kernel driver. -ena_syfsfs.[ch] Sysfs files. ena_ethtool.c ethtool callbacks. ena_pci_id_tbl.h Supported device IDs. ================= ====================================================== @@ -69,7 +67,7 @@ ENA management interface is exposed by means of: - Asynchronous Event Notification Queue (AENQ) ENA device MMIO Registers are accessed only during driver -initialization and are not involved in further normal device +initialization and are not used during further normal device operation. AQ is used for submitting management commands, and the @@ -100,28 +98,27 @@ group may have multiple syndromes, as shown below The events are: - ==================== =============== - Group Syndrome - ==================== =============== - Link state change **X** - Fatal error **X** - Notification Suspend traffic - Notification Resume traffic - Keep-Alive **X** - ==================== =============== +==================== =============== +Group Syndrome +==================== =============== +Link state change **X** +Fatal error **X** +Notification Suspend traffic +Notification Resume traffic +Keep-Alive **X** +==================== =============== ACQ and AENQ share the same MSI-X vector. -Keep-Alive is a special mechanism that allows monitoring of the -device's health. The driver maintains a watchdog (WD) handler which, -if fired, logs the current state and statistics then resets and -restarts the ENA device and driver. A Keep-Alive event is delivered by -the device every second. The driver re-arms the WD upon reception of a -Keep-Alive event. A missed Keep-Alive event causes the WD handler to -fire. +Keep-Alive is a special mechanism that allows monitoring the device's health. +A Keep-Alive event is delivered by the device every second. +The driver maintains a watchdog (WD) handler which logs the current state and +statistics. If the keep-alive events aren't delivered as expected the WD resets +the device and the driver. Data Path Interface =================== + I/O operations are based on Tx and Rx Submission Queues (Tx SQ and Rx SQ correspondingly). Each SQ has a completion queue (CQ) associated with it. @@ -131,26 +128,24 @@ physical memory. The ENA driver supports two Queue Operation modes for Tx SQs: -- Regular mode +- **Regular mode:** + In this mode the Tx SQs reside in the host's memory. The ENA + device fetches the ENA Tx descriptors and packet data from host + memory. - * In this mode the Tx SQs reside in the host's memory. The ENA - device fetches the ENA Tx descriptors and packet data from host - memory. +- **Low Latency Queue (LLQ) mode or "push-mode":** + In this mode the driver pushes the transmit descriptors and the + first 128 bytes of the packet directly to the ENA device memory + space. The rest of the packet payload is fetched by the + device. For this operation mode, the driver uses a dedicated PCI + device memory BAR, which is mapped with write-combine capability. -- Low Latency Queue (LLQ) mode or "push-mode". - - * In this mode the driver pushes the transmit descriptors and the - first 128 bytes of the packet directly to the ENA device memory - space. The rest of the packet payload is fetched by the - device. For this operation mode, the driver uses a dedicated PCI - device memory BAR, which is mapped with write-combine capability. + **Note that** not all ENA devices support LLQ, and this feature is negotiated + with the device upon initialization. If the ENA device does not + support LLQ mode, the driver falls back to the regular mode. The Rx SQs support only the regular mode. -Note: Not all ENA devices support LLQ, and this feature is negotiated - with the device upon initialization. If the ENA device does not - support LLQ mode, the driver falls back to the regular mode. - The driver supports multi-queue for both Tx and Rx. This has various benefits: @@ -165,6 +160,7 @@ benefits: Interrupt Modes =============== + The driver assigns a single MSI-X vector per queue pair (for both Tx and Rx directions). The driver assigns an additional dedicated MSI-X vector for management (for ACQ and AENQ). @@ -190,20 +186,21 @@ unmasked by the driver after NAPI processing is complete. Interrupt Moderation ==================== + ENA driver and device can operate in conventional or adaptive interrupt moderation mode. -In conventional mode the driver instructs device to postpone interrupt +**In conventional mode** the driver instructs device to postpone interrupt posting according to static interrupt delay value. The interrupt delay -value can be configured through ethtool(8). The following ethtool -parameters are supported by the driver: tx-usecs, rx-usecs +value can be configured through `ethtool(8)`. The following `ethtool` +parameters are supported by the driver: ``tx-usecs``, ``rx-usecs`` -In adaptive interrupt moderation mode the interrupt delay value is +**In adaptive interrupt** moderation mode the interrupt delay value is updated by the driver dynamically and adjusted every NAPI cycle according to the traffic nature. -Adaptive coalescing can be switched on/off through ethtool(8) -adaptive_rx on|off parameter. +Adaptive coalescing can be switched on/off through `ethtool(8)`'s +:code:`adaptive_rx on|off` parameter. More information about Adaptive Interrupt Moderation (DIM) can be found in Documentation/networking/net_dim.rst @@ -214,17 +211,10 @@ The rx_copybreak is initialized by default to ENA_DEFAULT_RX_COPYBREAK and can be configured by the ETHTOOL_STUNABLE command of the SIOCETHTOOL ioctl. -SKB -=== -The driver-allocated SKB for frames received from Rx handling using -NAPI context. The allocation method depends on the size of the packet. -If the frame length is larger than rx_copybreak, napi_get_frags() -is used, otherwise netdev_alloc_skb_ip_align() is used, the buffer -content is copied (by CPU) to the SKB, and the buffer is recycled. - Statistics ========== -The user can obtain ENA device and driver statistics using ethtool. + +The user can obtain ENA device and driver statistics using `ethtool`. The driver can collect regular or extended statistics (including per-queue stats) from the device. @@ -232,22 +222,23 @@ In addition the driver logs the stats to syslog upon device reset. MTU === + The driver supports an arbitrarily large MTU with a maximum that is negotiated with the device. The driver configures MTU using the SetFeature command (ENA_ADMIN_MTU property). The user can change MTU -via ip(8) and similar legacy tools. +via `ip(8)` and similar legacy tools. Stateless Offloads ================== + The ENA driver supports: -- TSO over IPv4/IPv6 -- TSO with ECN - IPv4 header checksum offload - TCP/UDP over IPv4/IPv6 checksum offloads RSS === + - The ENA device supports RSS that allows flexible Rx traffic steering. - Toeplitz and CRC32 hash functions are supported. @@ -260,41 +251,42 @@ RSS function delivered in the Rx CQ descriptor is set in the received SKB. - The user can provide a hash key, hash function, and configure the - indirection table through ethtool(8). + indirection table through `ethtool(8)`. DATA PATH ========= + Tx -- -ena_start_xmit() is called by the stack. This function does the following: +:code:`ena_start_xmit()` is called by the stack. This function does the following: -- Maps data buffers (skb->data and frags). -- Populates ena_buf for the push buffer (if the driver and device are - in push mode.) +- Maps data buffers (``skb->data`` and frags). +- Populates ``ena_buf`` for the push buffer (if the driver and device are + in push mode). - Prepares ENA bufs for the remaining frags. -- Allocates a new request ID from the empty req_id ring. The request +- Allocates a new request ID from the empty ``req_id`` ring. The request ID is the index of the packet in the Tx info. This is used for - out-of-order TX completions. + out-of-order Tx completions. - Adds the packet to the proper place in the Tx ring. -- Calls ena_com_prepare_tx(), an ENA communication layer that converts - the ena_bufs to ENA descriptors (and adds meta ENA descriptors as - needed.) +- Calls :code:`ena_com_prepare_tx()`, an ENA communication layer that converts + the ``ena_bufs`` to ENA descriptors (and adds meta ENA descriptors as + needed). * This function also copies the ENA descriptors and the push buffer - to the Device memory space (if in push mode.) + to the Device memory space (if in push mode). -- Writes doorbell to the ENA device. +- Writes a doorbell to the ENA device. - When the ENA device finishes sending the packet, a completion interrupt is raised. - The interrupt handler schedules NAPI. -- The ena_clean_tx_irq() function is called. This function handles the +- The :code:`ena_clean_tx_irq()` function is called. This function handles the completion descriptors generated by the ENA, with a single completion descriptor per completed packet. - * req_id is retrieved from the completion descriptor. The tx_info of - the packet is retrieved via the req_id. The data buffers are - unmapped and req_id is returned to the empty req_id ring. + * ``req_id`` is retrieved from the completion descriptor. The ``tx_info`` of + the packet is retrieved via the ``req_id``. The data buffers are + unmapped and ``req_id`` is returned to the empty ``req_id`` ring. * The function stops when the completion descriptors are completed or the budget is reached. @@ -303,12 +295,11 @@ Rx - When a packet is received from the ENA device. - The interrupt handler schedules NAPI. -- The ena_clean_rx_irq() function is called. This function calls - ena_rx_pkt(), an ENA communication layer function, which returns the - number of descriptors used for a new unhandled packet, and zero if +- The :code:`ena_clean_rx_irq()` function is called. This function calls + :code:`ena_com_rx_pkt()`, an ENA communication layer function, which returns the + number of descriptors used for a new packet, and zero if no new packet is found. -- Then it calls the ena_clean_rx_irq() function. -- ena_eth_rx_skb() checks packet length: +- :code:`ena_rx_skb()` checks packet length: * If the packet is small (len < rx_copybreak), the driver allocates a SKB for the new packet, and copies the packet payload into the @@ -317,9 +308,10 @@ Rx - In this way the original data buffer is not passed to the stack and is reused for future Rx packets. - * Otherwise the function unmaps the Rx buffer, then allocates the - new SKB structure and hooks the Rx buffer to the SKB frags. + * Otherwise the function unmaps the Rx buffer, sets the first + descriptor as `skb`'s linear part and the other descriptors as the + `skb`'s frags. - The new SKB is updated with the necessary information (protocol, - checksum hw verify result, etc.), and then passed to the network - stack, using the NAPI interface function napi_gro_receive(). + checksum hw verify result, etc), and then passed to the network + stack, using the NAPI interface function :code:`napi_gro_receive()`. diff --git a/Documentation/networking/device_drivers/ethernet/google/gve.rst b/Documentation/networking/device_drivers/ethernet/google/gve.rst index 793693cef6e3..6d73ee78f3d7 100644 --- a/Documentation/networking/device_drivers/ethernet/google/gve.rst +++ b/Documentation/networking/device_drivers/ethernet/google/gve.rst @@ -47,13 +47,24 @@ The driver interacts with the device in the following ways: - Transmit and Receive Queues - See description below +Descriptor Formats +------------------ +GVE supports two descriptor formats: GQI and DQO. These two formats have +entirely different descriptors, which will be described below. + Registers --------- -All registers are MMIO and big endian. +All registers are MMIO. The registers are used for initializing and configuring the device as well as querying device status in response to management interrupts. +Endianness +---------- +- Admin Queue messages and registers are all Big Endian. +- GQI descriptors and datapath registers are Big Endian. +- DQO descriptors and datapath registers are Little Endian. + Admin Queue (AQ) ---------------- The Admin Queue is a PAGE_SIZE memory block, treated as an array of AQ @@ -97,10 +108,10 @@ the queues associated with that interrupt. The handler for these irqs schedule the napi for that block to run and poll the queues. -Traffic Queues --------------- -gVNIC's queues are composed of a descriptor ring and a buffer and are -assigned to a notification block. +GQI Traffic Queues +------------------ +GQI queues are composed of a descriptor ring and a buffer and are assigned to a +notification block. The descriptor rings are power-of-two-sized ring buffers consisting of fixed-size descriptors. They advance their head pointer using a __be32 @@ -121,3 +132,35 @@ Receive The buffers for receive rings are put into a data ring that is the same length as the descriptor ring and the head and tail pointers advance over the rings together. + +DQO Traffic Queues +------------------ +- Every TX and RX queue is assigned a notification block. + +- TX and RX buffers queues, which send descriptors to the device, use MMIO + doorbells to notify the device of new descriptors. + +- RX and TX completion queues, which receive descriptors from the device, use a + "generation bit" to know when a descriptor was populated by the device. The + driver initializes all bits with the "current generation". The device will + populate received descriptors with the "next generation" which is inverted + from the current generation. When the ring wraps, the current/next generation + are swapped. + +- It's the driver's responsibility to ensure that the RX and TX completion + queues are not overrun. This can be accomplished by limiting the number of + descriptors posted to HW. + +- TX packets have a 16 bit completion_tag and RX buffers have a 16 bit + buffer_id. These will be returned on the TX completion and RX queues + respectively to let the driver know which packet/buffer was completed. + +Transmit +~~~~~~~~ +A packet's buffers are DMA mapped for the device to access before transmission. +After the packet was successfully transmitted, the buffers are unmapped. + +Receive +~~~~~~~ +The driver posts fixed sized buffers to HW on the RX buffer queue. The packet +received on the associated RX queue may span multiple descriptors. diff --git a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst index 936a10f1942c..ef8cb62e82a1 100644 --- a/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst +++ b/Documentation/networking/device_drivers/ethernet/mellanox/mlx5.rst @@ -12,6 +12,7 @@ Contents - `Enabling the driver and kconfig options`_ - `Devlink info`_ - `Devlink parameters`_ +- `Bridge offload`_ - `mlx5 subfunction`_ - `mlx5 function attributes`_ - `Devlink health reporters`_ @@ -217,6 +218,37 @@ users try to enable them. $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev +Bridge offload +============== +The mlx5 driver implements support for offloading bridge rules when in switchdev +mode. Linux bridge FDBs are automatically offloaded when mlx5 switchdev +representor is attached to bridge. + +- Change device to switchdev mode:: + + $ devlink dev eswitch set pci/0000:06:00.0 mode switchdev + +- Attach mlx5 switchdev representor 'enp8s0f0' to bridge netdev 'bridge1':: + + $ ip link set enp8s0f0 master bridge1 + +VLANs +----- +Following bridge VLAN functions are supported by mlx5: + +- VLAN filtering (including multiple VLANs per port):: + + $ ip link set bridge1 type bridge vlan_filtering 1 + $ bridge vlan add dev enp8s0f0 vid 2-3 + +- VLAN push on bridge ingress:: + + $ bridge vlan add dev enp8s0f0 vid 3 pvid + +- VLAN pop on bridge egress:: + + $ bridge vlan add dev enp8s0f0 vid 3 untagged + mlx5 subfunction ================ mlx5 supports subfunction management using devlink port (see :ref:`Documentation/networking/devlink/devlink-port.rst <devlink_port>`) interface. @@ -568,3 +600,59 @@ tc and eswitch offloads tracepoints: $ cat /sys/kernel/debug/tracing/trace ... kworker/u48:7-2221 [009] ...1 1475.387435: mlx5e_rep_neigh_update: netdev: ens1f0 MAC: 24:8a:07:9a:17:9a IPv4: 1.1.1.10 IPv6: ::ffff:1.1.1.10 neigh_connected=1 + +Bridge offloads tracepoints: + +- mlx5_esw_bridge_fdb_entry_init: trace bridge FDB entry offloaded to mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:9-2217 [003] ...1 318.582243: mlx5_esw_bridge_fdb_entry_init: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=0 flags=0 used=0 + +- mlx5_esw_bridge_fdb_entry_cleanup: trace bridge FDB entry deleted from mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2581 [005] ...1 318.629871: mlx5_esw_bridge_fdb_entry_cleanup: net_device=enp8s0f0_1 addr=e4:fd:05:08:00:03 vid=0 flags=0 used=16 + +- mlx5_esw_bridge_fdb_entry_refresh: trace bridge FDB entry offload refreshed in + mlx5:: + + $ echo mlx5:mlx5_esw_bridge_fdb_entry_refresh >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + kworker/u20:8-3849 [003] ...1 466716: mlx5_esw_bridge_fdb_entry_refresh: net_device=enp8s0f0_0 addr=e4:fd:05:08:00:02 vid=3 flags=0 used=0 + +- mlx5_esw_bridge_vlan_create: trace bridge VLAN object add on mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_create >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.460258: mlx5_esw_bridge_vlan_create: vid=1 flags=6 + +- mlx5_esw_bridge_vlan_cleanup: trace bridge VLAN object delete from mlx5 + representor:: + + $ echo mlx5:mlx5_esw_bridge_vlan_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + bridge-2582 [007] ...1 318.653496: mlx5_esw_bridge_vlan_cleanup: vid=2 flags=8 + +- mlx5_esw_bridge_vport_init: trace mlx5 vport assigned with bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_init >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-2560 [007] ...1 318.458915: mlx5_esw_bridge_vport_init: vport_num=1 + +- mlx5_esw_bridge_vport_cleanup: trace mlx5 vport removed from bridge upper + device:: + + $ echo mlx5:mlx5_esw_bridge_vport_cleanup >> set_event + $ cat /sys/kernel/debug/tracing/trace + ... + ip-5387 [000] ...1 573713: mlx5_esw_bridge_vport_cleanup: vport_num=1 diff --git a/Documentation/networking/device_drivers/index.rst b/Documentation/networking/device_drivers/index.rst index d8279de7bf25..3a5a1d46e77e 100644 --- a/Documentation/networking/device_drivers/index.rst +++ b/Documentation/networking/device_drivers/index.rst @@ -18,6 +18,7 @@ Contents: qlogic/index wan/index wifi/index + wwan/index .. only:: subproject and html diff --git a/Documentation/networking/device_drivers/wwan/index.rst b/Documentation/networking/device_drivers/wwan/index.rst new file mode 100644 index 000000000000..1cb8c7371401 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/index.rst @@ -0,0 +1,18 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +WWAN Device Drivers +=================== + +Contents: + +.. toctree:: + :maxdepth: 2 + + iosm + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/networking/device_drivers/wwan/iosm.rst b/Documentation/networking/device_drivers/wwan/iosm.rst new file mode 100644 index 000000000000..aceb0223eb46 --- /dev/null +++ b/Documentation/networking/device_drivers/wwan/iosm.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +.. Copyright (C) 2020-21 Intel Corporation + +.. _iosm_driver_doc: + +=========================================== +IOSM Driver for Intel M.2 PCIe based Modems +=========================================== +The IOSM (IPC over Shared Memory) driver is a WWAN PCIe host driver developed +for linux or chrome platform for data exchange over PCIe interface between +Host platform & Intel M.2 Modem. The driver exposes interface conforming to the +MBIM protocol [1]. Any front end application ( eg: Modem Manager) could easily +manage the MBIM interface to enable data communication towards WWAN. + +Basic usage +=========== +MBIM functions are inactive when unmanaged. The IOSM driver only provides a +userspace interface MBIM "WWAN PORT" representing MBIM control channel and does +not play any role in managing the functionality. It is the job of a userspace +application to detect port enumeration and enable MBIM functionality. + +Examples of few such userspace application are: +- mbimcli (included with the libmbim [2] library), and +- Modem Manager [3] + +Management Applications to carry out below required actions for establishing +MBIM IP session: +- open the MBIM control channel +- configure network connection settings +- connect to network +- configure IP network interface + +Management application development +================================== +The driver and userspace interfaces are described below. The MBIM protocol is +described in [1] Mobile Broadband Interface Model v1.0 Errata-1. + +MBIM control channel userspace ABI +---------------------------------- + +/dev/wwan0mbim0 character device +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The driver exposes an MBIM interface to the MBIM function by implementing +MBIM WWAN Port. The userspace end of the control channel pipe is a +/dev/wwan0mbim0 character device. Application shall use this interface for +MBIM protocol communication. + +Fragmentation +~~~~~~~~~~~~~ +The userspace application is responsible for all control message fragmentation +and defragmentation as per MBIM specification. + +/dev/wwan0mbim0 write() +~~~~~~~~~~~~~~~~~~~~~~~ +The MBIM control messages from the management application must not exceed the +negotiated control message size. + +/dev/wwan0mbim0 read() +~~~~~~~~~~~~~~~~~~~~~~ +The management application must accept control messages of up the negotiated +control message size. + +MBIM data channel userspace ABI +------------------------------- + +wwan0-X network device +~~~~~~~~~~~~~~~~~~~~~~ +The IOSM driver exposes IP link interface "wwan0-X" of type "wwan" for IP +traffic. Iproute network utility is used for creating "wwan0-X" network +interface and for associating it with MBIM IP session. The Driver supports +upto 8 IP sessions for simultaneous IP communication. + +The userspace management application is responsible for creating new IP link +prior to establishing MBIM IP session where the SessionId is greater than 0. + +For example, creating new IP link for a MBIM IP session with SessionId 1: + + ip link add dev wwan0-1 parentdev-name wwan0 type wwan linkid 1 + +The driver will automatically map the "wwan0-1" network device to MBIM IP +session 1. + +References +========== +[1] "MBIM (Mobile Broadband Interface Model) Errata-1" + - https://www.usb.org/document-library/ + +[2] libmbim - "a glib-based library for talking to WWAN modems and + devices which speak the Mobile Interface Broadband Model (MBIM) + protocol" + - http://www.freedesktop.org/wiki/Software/libmbim/ + +[3] Modem Manager - "a DBus-activated daemon which controls mobile + broadband (2G/3G/4G) devices and connections" + - http://www.freedesktop.org/wiki/Software/ModemManager/ diff --git a/Documentation/networking/devlink/devlink-port.rst b/Documentation/networking/devlink/devlink-port.rst index ab790e7980b8..7627b1da01f2 100644 --- a/Documentation/networking/devlink/devlink-port.rst +++ b/Documentation/networking/devlink/devlink-port.rst @@ -164,6 +164,41 @@ device to instantiate the subfunction device on particular PCI function. A subfunction device is created on the :ref:`Documentation/driver-api/auxiliary_bus.rst <auxiliary_bus>`. At this point a matching subfunction driver binds to the subfunction's auxiliary device. +Rate object management +====================== + +Devlink provides API to manage tx rates of single devlink port or a group. +This is done through rate objects, which can be one of the two types: + +``leaf`` + Represents a single devlink port; created/destroyed by the driver. Since leaf + have 1to1 mapping to its devlink port, in user space it is referred as + ``pci/<bus_addr>/<port_index>``; + +``node`` + Represents a group of rate objects (leafs and/or nodes); created/deleted by + request from the userspace; initially empty (no rate objects added). In + userspace it is referred as ``pci/<bus_addr>/<node_name>``, where + ``node_name`` can be any identifier, except decimal number, to avoid + collisions with leafs. + +API allows to configure following rate object's parameters: + +``tx_share`` + Minimum TX rate value shared among all other rate objects, or rate objects + that parts of the parent group, if it is a part of the same group. + +``tx_max`` + Maximum TX rate value. + +``parent`` + Parent node name. Parent node rate limits are considered as additional limits + to all node children limits. ``tx_max`` is an upper limit for children. + ``tx_share`` is a total bandwidth distributed among children. + +Driver implementations are allowed to support both or either rate object types +and setting methods of their parameters. + Terms and Definitions ===================== diff --git a/Documentation/networking/devlink/devlink-trap.rst b/Documentation/networking/devlink/devlink-trap.rst index efa5f7f42c88..90d1381b88de 100644 --- a/Documentation/networking/devlink/devlink-trap.rst +++ b/Documentation/networking/devlink/devlink-trap.rst @@ -497,6 +497,7 @@ drivers: * Documentation/networking/devlink/netdevsim.rst * Documentation/networking/devlink/mlxsw.rst + * Documentation/networking/devlink/prestera.rst .. _Generic-Packet-Trap-Groups: diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 8428a1220723..b3b9e0692088 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -46,3 +46,4 @@ parameters, info versions, and other features it supports. qed ti-cpsw-switch am65-nuss-cpsw-switch + prestera diff --git a/Documentation/networking/devlink/netdevsim.rst b/Documentation/networking/devlink/netdevsim.rst index 02c2d20dc673..8a292fb5aaea 100644 --- a/Documentation/networking/devlink/netdevsim.rst +++ b/Documentation/networking/devlink/netdevsim.rst @@ -57,6 +57,32 @@ entries, FIB rule entries and nexthops that the driver will allow. $ devlink resource set netdevsim/netdevsim0 path /nexthops size 16 $ devlink dev reload netdevsim/netdevsim0 +Rate objects +============ + +The ``netdevsim`` driver supports rate objects management, which includes: + +- registerging/unregistering leaf rate objects per VF devlink port; +- creation/deletion node rate objects; +- setting tx_share and tx_max rate values for any rate object type; +- setting parent node for any rate object type. + +Rate nodes and it's parameters are exposed in ``netdevsim`` debugfs in RO mode. +For example created rate node with name ``some_group``: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/rate_groups/some_group + rate_parent tx_max tx_share + +Same parameters are exposed for leaf objects in corresponding ports directories. +For ex.: + +.. code:: shell + + $ ls /sys/kernel/debug/netdevsim/netdevsim0/ports/1 + dev ethtool rate_parent tx_max tx_share + Driver-specific Traps ===================== diff --git a/Documentation/networking/devlink/prestera.rst b/Documentation/networking/devlink/prestera.rst new file mode 100644 index 000000000000..49409d1d3081 --- /dev/null +++ b/Documentation/networking/devlink/prestera.rst @@ -0,0 +1,141 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================== +prestera devlink support +======================== + +This document describes the devlink features implemented by the ``prestera`` +device driver. + +Driver-specific Traps +===================== + +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description +.. list-table:: List of Driver-specific Traps Registered by ``prestera`` + :widths: 5 5 90 + + * - Name + - Type + - Description + * - ``arp_bc`` + - ``trap`` + - Traps ARP broadcast packets (both requests/responses) + * - ``is_is`` + - ``trap`` + - Traps IS-IS packets + * - ``ospf`` + - ``trap`` + - Traps OSPF packets + * - ``ip_bc_mac`` + - ``trap`` + - Traps IPv4 packets with broadcast DA Mac address + * - ``stp`` + - ``trap`` + - Traps STP BPDU + * - ``lacp`` + - ``trap`` + - Traps LACP packets + * - ``lldp`` + - ``trap`` + - Traps LLDP packets + * - ``router_mc`` + - ``trap`` + - Traps multicast packets + * - ``vrrp`` + - ``trap`` + - Traps VRRP packets + * - ``dhcp`` + - ``trap`` + - Traps DHCP packets + * - ``mtu_error`` + - ``trap`` + - Traps (exception) packets that exceeded port's MTU + * - ``mac_to_me`` + - ``trap`` + - Traps packets with switch-port's DA Mac address + * - ``ttl_error`` + - ``trap`` + - Traps (exception) IPv4 packets whose TTL exceeded + * - ``ipv4_options`` + - ``trap`` + - Traps (exception) packets due to the malformed IPV4 header options + * - ``ip_default_route`` + - ``trap`` + - Traps packets that have no specific IP interface (IP to me) and no forwarding prefix + * - ``local_route`` + - ``trap`` + - Traps packets that have been send to one of switch IP interfaces addresses + * - ``ipv4_icmp_redirect`` + - ``trap`` + - Traps (exception) IPV4 ICMP redirect packets + * - ``arp_response`` + - ``trap`` + - Traps ARP replies packets that have switch-port's DA Mac address + * - ``acl_code_0`` + - ``trap`` + - Traps packets that have ACL priority set to 0 (tc pref 0) + * - ``acl_code_1`` + - ``trap`` + - Traps packets that have ACL priority set to 1 (tc pref 1) + * - ``acl_code_2`` + - ``trap`` + - Traps packets that have ACL priority set to 2 (tc pref 2) + * - ``acl_code_3`` + - ``trap`` + - Traps packets that have ACL priority set to 3 (tc pref 3) + * - ``acl_code_4`` + - ``trap`` + - Traps packets that have ACL priority set to 4 (tc pref 4) + * - ``acl_code_5`` + - ``trap`` + - Traps packets that have ACL priority set to 5 (tc pref 5) + * - ``acl_code_6`` + - ``trap`` + - Traps packets that have ACL priority set to 6 (tc pref 6) + * - ``acl_code_7`` + - ``trap`` + - Traps packets that have ACL priority set to 7 (tc pref 7) + * - ``ipv4_bgp`` + - ``trap`` + - Traps IPv4 BGP packets + * - ``ssh`` + - ``trap`` + - Traps SSH packets + * - ``telnet`` + - ``trap`` + - Traps Telnet packets + * - ``icmp`` + - ``trap`` + - Traps ICMP packets + * - ``rxdma_drop`` + - ``drop`` + - Drops packets (RxDMA) due to the lack of ingress buffers etc. + * - ``port_no_vlan`` + - ``drop`` + - Drops packets due to faulty-configured network or due to internal bug (config issue). + * - ``local_port`` + - ``drop`` + - Drops packets whose decision (FDB entry) is to bridge packet back to the incoming port/trunk. + * - ``invalid_sa`` + - ``drop`` + - Drops packets with multicast source MAC address. + * - ``illegal_ip_addr`` + - ``drop`` + - Drops packets with illegal SIP/DIP multicast/unicast addresses. + * - ``illegal_ipv4_hdr`` + - ``drop`` + - Drops packets with illegal IPV4 header. + * - ``ip_uc_dip_da_mismatch`` + - ``drop`` + - Drops packets with destination MAC being unicast, but destination IP address being multicast. + * - ``ip_sip_is_zero`` + - ``drop`` + - Drops packets with zero (0) IPV4 source address. + * - ``met_red`` + - ``drop`` + - Drops non-conforming packets (dropped by Ingress policer, metering drop), e.g. packet rate exceeded configured bandwith. diff --git a/Documentation/networking/dsa/configuration.rst b/Documentation/networking/dsa/configuration.rst index 774f0e76c746..2b08f1a772d3 100644 --- a/Documentation/networking/dsa/configuration.rst +++ b/Documentation/networking/dsa/configuration.rst @@ -292,3 +292,71 @@ configuration. # bring up the bridge devices ip link set br0 up + +Forwarding database (FDB) management +------------------------------------ + +The existing DSA switches do not have the necessary hardware support to keep +the software FDB of the bridge in sync with the hardware tables, so the two +tables are managed separately (``bridge fdb show`` queries both, and depending +on whether the ``self`` or ``master`` flags are being used, a ``bridge fdb +add`` or ``bridge fdb del`` command acts upon entries from one or both tables). + +Up until kernel v4.14, DSA only supported user space management of bridge FDB +entries using the bridge bypass operations (which do not update the software +FDB, just the hardware one) using the ``self`` flag (which is optional and can +be omitted). + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 self static + # or shorthand + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Due to a bug, the bridge bypass FDB implementation provided by DSA did not +distinguish between ``static`` and ``local`` FDB entries (``static`` are meant +to be forwarded, while ``local`` are meant to be locally terminated, i.e. sent +to the host port). Instead, all FDB entries with the ``self`` flag (implicit or +explicit) are treated by DSA as ``static`` even if they are ``local``. + + .. code-block:: sh + + # This command: + bridge fdb add dev swp0 00:01:02:03:04:05 static + # behaves the same for DSA as this command: + bridge fdb add dev swp0 00:01:02:03:04:05 local + # or shorthand, because the 'local' flag is implicit if 'static' is not + # specified, it also behaves the same as: + bridge fdb add dev swp0 00:01:02:03:04:05 + +The last command is an incorrect way of adding a static bridge FDB entry to a +DSA switch using the bridge bypass operations, and works by mistake. Other +drivers will treat an FDB entry added by the same command as ``local`` and as +such, will not forward it, as opposed to DSA. + +Between kernel v4.14 and v5.14, DSA has supported in parallel two modes of +adding a bridge FDB entry to the switch: the bridge bypass discussed above, as +well as a new mode using the ``master`` flag which installs FDB entries in the +software bridge too. + + .. code-block:: sh + + bridge fdb add dev swp0 00:01:02:03:04:05 master static + +Since kernel v5.14, DSA has gained stronger integration with the bridge's +software FDB, and the support for its bridge bypass FDB implementation (using +the ``self`` flag) has been removed. This results in the following changes: + + .. code-block:: sh + + # This is the only valid way of adding an FDB entry that is supported, + # compatible with v4.14 kernels and later: + bridge fdb add dev swp0 00:01:02:03:04:05 master static + # This command is no longer buggy and the entry is properly treated as + # 'local' instead of being forwarded: + bridge fdb add dev swp0 00:01:02:03:04:05 + # This command no longer installs a static FDB entry to hardware: + bridge fdb add dev swp0 00:01:02:03:04:05 static + +Script writers are therefore encouraged to use the ``master static`` set of +flags when working with bridge FDB entries on DSA switch interfaces. diff --git a/Documentation/networking/dsa/dsa.rst b/Documentation/networking/dsa/dsa.rst index 8688009514cc..20baacf2bc5c 100644 --- a/Documentation/networking/dsa/dsa.rst +++ b/Documentation/networking/dsa/dsa.rst @@ -93,14 +93,15 @@ A tagging protocol may tag all packets with switch tags of the same length, or the tag length might vary (for example packets with PTP timestamps might require an extended switch tag, or there might be one tag length on TX and a different one on RX). Either way, the tagging protocol driver must populate the -``struct dsa_device_ops::overhead`` with the length in octets of the longest -switch frame header. The DSA framework will automatically adjust the MTU of the -master interface to accomodate for this extra size in order for DSA user ports -to support the standard MTU (L2 payload length) of 1500 octets. The ``overhead`` -is also used to request from the network stack, on a best-effort basis, the -allocation of packets with a ``needed_headroom`` or ``needed_tailroom`` -sufficient such that the act of pushing the switch tag on transmission of a -packet does not cause it to reallocate due to lack of memory. +``struct dsa_device_ops::needed_headroom`` and/or ``struct dsa_device_ops::needed_tailroom`` +with the length in octets of the longest switch frame header/trailer. The DSA +framework will automatically adjust the MTU of the master interface to +accommodate for this extra size in order for DSA user ports to support the +standard MTU (L2 payload length) of 1500 octets. The ``needed_headroom`` and +``needed_tailroom`` properties are also used to request from the network stack, +on a best-effort basis, the allocation of packets with enough extra space such +that the act of pushing the switch tag on transmission of a packet does not +cause it to reallocate due to lack of memory. Even though applications are not expected to parse DSA-specific frame headers, the format on the wire of the tagging protocol represents an Application Binary @@ -169,8 +170,8 @@ The job of this method is to prepare the skb in a way that the switch will understand what egress port the packet is for (and not deliver it towards other ports). Typically this is fulfilled by pushing a frame header. Checking for insufficient size in the skb headroom or tailroom is unnecessary provided that -the ``overhead`` and ``tail_tag`` properties were filled out properly, because -DSA ensures there is enough space before calling this method. +the ``needed_headroom`` and ``needed_tailroom`` properties were filled out +properly, because DSA ensures there is enough space before calling this method. The reception of a packet goes through the tagger's ``rcv`` function. The passed ``struct sk_buff *skb`` has ``skb->data`` pointing at diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 7395a33baaf9..da4057ba37f1 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -5,7 +5,7 @@ NXP SJA1105 switch driver Overview ======== -The NXP SJA1105 is a family of 6 devices: +The NXP SJA1105 is a family of 10 SPI-managed automotive switches: - SJA1105E: First generation, no TTEthernet - SJA1105T: First generation, TTEthernet @@ -13,9 +13,11 @@ The NXP SJA1105 is a family of 6 devices: - SJA1105Q: Second generation, TTEthernet, no SGMII - SJA1105R: Second generation, no TTEthernet, SGMII - SJA1105S: Second generation, TTEthernet, SGMII - -These are SPI-managed automotive switches, with all ports being gigabit -capable, and supporting MII/RMII/RGMII and optionally SGMII on one port. +- SJA1110A: Third generation, TTEthernet, SGMII, integrated 100base-T1 and + 100base-TX PHYs +- SJA1110B: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110C: Third generation, TTEthernet, SGMII, 100base-T1, 100base-TX +- SJA1110D: Third generation, TTEthernet, SGMII, 100base-T1 Being automotive parts, their configuration interface is geared towards set-and-forget use, with minimal dynamic interaction at runtime. They @@ -579,3 +581,54 @@ A board would need to hook up the PHYs connected to the switch to any other MDIO bus available to Linux within the system (e.g. to the DSA master's MDIO bus). Link state management then works by the driver manually keeping in sync (over SPI commands) the MAC link speed with the settings negotiated by the PHY. + +By comparison, the SJA1110 supports an MDIO slave access point over which its +internal 100base-T1 PHYs can be accessed from the host. This is, however, not +used by the driver, instead the internal 100base-T1 and 100base-TX PHYs are +accessed through SPI commands, modeled in Linux as virtual MDIO buses. + +The microcontroller attached to the SJA1110 port 0 also has an MDIO controller +operating in master mode, however the driver does not support this either, +since the microcontroller gets disabled when the Linux driver operates. +Discrete PHYs connected to the switch ports should have their MDIO interface +attached to an MDIO controller from the host system and not to the switch, +similar to SJA1105. + +Port compatibility matrix +------------------------- + +The SJA1105 port compatibility matrix is: + +===== ============== ============== ============== +Port SJA1105E/T SJA1105P/Q SJA1105R/S +===== ============== ============== ============== +0 xMII xMII xMII +1 xMII xMII xMII +2 xMII xMII xMII +3 xMII xMII xMII +4 xMII xMII SGMII +===== ============== ============== ============== + + +The SJA1110 port compatibility matrix is: + +===== ============== ============== ============== ============== +Port SJA1110A SJA1110B SJA1110C SJA1110D +===== ============== ============== ============== ============== +0 RevMII (uC) RevMII (uC) RevMII (uC) RevMII (uC) +1 100base-TX 100base-TX 100base-TX + or SGMII SGMII +2 xMII xMII xMII xMII + or SGMII or SGMII +3 xMII xMII xMII + or SGMII or SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X +4 SGMII SGMII SGMII SGMII + or 2500base-X or 2500base-X or 2500base-X or 2500base-X +5 100base-T1 100base-T1 100base-T1 100base-T1 +6 100base-T1 100base-T1 100base-T1 100base-T1 +7 100base-T1 100base-T1 100base-T1 100base-T1 +8 100base-T1 100base-T1 n/a n/a +9 100base-T1 100base-T1 n/a n/a +10 100base-T1 n/a n/a n/a +===== ============== ============== ============== ============== diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 25131df3c2bd..6ea91e41593f 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -1363,8 +1363,8 @@ in an implementation specific way. ``ETHTOOL_A_FEC_AUTO`` requests the driver to choose FEC mode based on SFP module parameters. This does not mean autonegotiation. -MODULE_EEPROM -============= +MODULE_EEPROM_GET +================= Fetch module EEPROM data dump. This interface is designed to allow dumps of at most 1/2 page at once. This @@ -1383,12 +1383,14 @@ Request contents: ``ETHTOOL_A_MODULE_EEPROM_I2C_ADDRESS`` u8 page I2C address ======================================= ====== ========================== +If ``ETHTOOL_A_MODULE_EEPROM_BANK`` is not specified, bank 0 is assumed. + Kernel response contents: +---------------------------------------------+--------+---------------------+ | ``ETHTOOL_A_MODULE_EEPROM_HEADER`` | nested | reply header | +---------------------------------------------+--------+---------------------+ - | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | nested | array of bytes from | + | ``ETHTOOL_A_MODULE_EEPROM_DATA`` | binary | array of bytes from | | | | module EEPROM | +---------------------------------------------+--------+---------------------+ diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index c2ecc9894fd0..b3fa522e4cd9 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -99,6 +99,35 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 - 1 - Layer 4 - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl + +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Unused (Flow Label) + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) fib_sync_mem - UNSIGNED INTEGER Amount of dirty memory from fib entries that can be backlogged before @@ -732,6 +761,31 @@ tcp_syncookies - INTEGER network connections you can set this knob to 2 to enable unconditionally generation of syncookies. +tcp_migrate_req - BOOLEAN + The incoming connection is tied to a specific listening socket when + the initial SYN packet is received during the three-way handshake. + When a listener is closed, in-flight request sockets during the + handshake and established sockets in the accept queue are aborted. + + If the listener has SO_REUSEPORT enabled, other listeners on the + same port should have been able to accept such connections. This + option makes it possible to migrate such child sockets to another + listener after close() or shutdown(). + + The BPF_SK_REUSEPORT_SELECT_OR_MIGRATE type of eBPF program should + usually be used to define the policy to pick an alive listener. + Otherwise, the kernel will randomly pick an alive listener only if + this option is enabled. + + Note that migration between listeners with different settings may + crash applications. Let's say migration happens from listener A to + B, and only B has TCP_SAVE_SYN enabled. B cannot read SYN data from + the requests migrated from A. To avoid such a situation, cancel + migration by returning SK_DROP in the type of eBPF program, or + disable this option. + + Default: 0 + tcp_fastopen - INTEGER Enable TCP Fast Open (RFC7413) to send and accept data in the opening SYN packet. @@ -1743,6 +1797,35 @@ fib_multipath_hash_policy - INTEGER - 0 - Layer 3 (source and destination addresses plus flow label) - 1 - Layer 4 (standard 5-tuple) - 2 - Layer 3 or inner Layer 3 if present + - 3 - Custom multipath hash. Fields used for multipath hash calculation + are determined by fib_multipath_hash_fields sysctl + +fib_multipath_hash_fields - UNSIGNED INTEGER + When fib_multipath_hash_policy is set to 3 (custom multipath hash), the + fields used for multipath hash calculation are determined by this + sysctl. + + This value is a bitmask which enables various fields for multipath hash + calculation. + + Possible fields are: + + ====== ============================ + 0x0001 Source IP address + 0x0002 Destination IP address + 0x0004 IP protocol + 0x0008 Flow Label + 0x0010 Source port + 0x0020 Destination port + 0x0040 Inner source IP address + 0x0080 Inner destination IP address + 0x0100 Inner IP protocol + 0x0200 Inner Flow Label + 0x0400 Inner source port + 0x0800 Inner destination port + ====== ============================ + + Default: 0x0007 (source IP, destination IP and IP protocol) anycast_src_echo_reply - BOOLEAN Controls the use of anycast addresses as source addresses for ICMPv6 @@ -2751,6 +2834,18 @@ encap_port - INTEGER Default: 0 +plpmtud_probe_interval - INTEGER + The time interval (in milliseconds) for the PLPMTUD probe timer, + which is configured to expire after this period to receive an + acknowledgment to a probe packet. This is also the time interval + between the probes for the current pmtu when the probe search + is done. + + PLPMTUD will be disabled when 0 is set, and other values for it + must be >= 5000. + + Default: 0 + ``/proc/sys/net/core/*`` ======================== diff --git a/Documentation/networking/mptcp-sysctl.rst b/Documentation/networking/mptcp-sysctl.rst index 6af0196c4297..76d939e688b8 100644 --- a/Documentation/networking/mptcp-sysctl.rst +++ b/Documentation/networking/mptcp-sysctl.rst @@ -7,13 +7,13 @@ MPTCP Sysfs variables /proc/sys/net/mptcp/* Variables =============================== -enabled - INTEGER +enabled - BOOLEAN Control whether MPTCP sockets can be created. - MPTCP sockets can be created if the value is nonzero. This is - a per-namespace sysctl. + MPTCP sockets can be created if the value is 1. This is a + per-namespace sysctl. - Default: 1 + Default: 1 (enabled) add_addr_timeout - INTEGER (seconds) Set the timeout after which an ADD_ADDR control message will be @@ -24,3 +24,24 @@ add_addr_timeout - INTEGER (seconds) sysctl. Default: 120 + +checksum_enabled - BOOLEAN + Control whether DSS checksum can be enabled. + + DSS checksum can be enabled if the value is nonzero. This is a + per-namespace sysctl. + + Default: 0 + +allow_join_initial_addr_port - BOOLEAN + Allow peers to send join requests to the IP address and port number used + by the initial subflow if the value is 1. This controls a flag that is + sent to the peer at connection time, and whether such join requests are + accepted or denied. + + Joins to addresses advertised with ADD_ADDR are not affected by this + value. + + This is a per-namespace sysctl. + + Default: 1 diff --git a/Documentation/networking/nf_conntrack-sysctl.rst b/Documentation/networking/nf_conntrack-sysctl.rst index 11a9b76786cb..0467b30e4abe 100644 --- a/Documentation/networking/nf_conntrack-sysctl.rst +++ b/Documentation/networking/nf_conntrack-sysctl.rst @@ -177,3 +177,27 @@ nf_conntrack_gre_timeout_stream - INTEGER (seconds) This extended timeout will be used in case there is an GRE stream detected. + +nf_flowtable_tcp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for tcp connections. + TCP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with tcp pickup timeout. + +nf_flowtable_tcp_pickup - INTEGER (seconds) + default 120 + + TCP connection timeout after being aged from nf flow table offload. + +nf_flowtable_udp_timeout - INTEGER (seconds) + default 30 + + Control offload timeout for udp connections. + UDP connections may be offloaded from nf conntrack to nf flow table. + Once aged, the connection is returned to nf conntrack with udp pickup timeout. + +nf_flowtable_udp_pickup - INTEGER (seconds) + default 30 + + UDP connection timeout after being aged from nf flow table offload. diff --git a/Documentation/networking/phy.rst b/Documentation/networking/phy.rst index 3f05d50ecd6e..571ba08386e7 100644 --- a/Documentation/networking/phy.rst +++ b/Documentation/networking/phy.rst @@ -292,6 +292,12 @@ Some of the interface modes are described below: Note: due to legacy usage, some 10GBASE-R usage incorrectly makes use of this definition. +``PHY_INTERFACE_MODE_25GBASER`` + This is the IEEE 802.3 PCS Clause 107 defined 25GBASE-R protocol. + The PCS is identical to 10GBASE-R, i.e. 64B/66B encoded + running 2.5 as fast, giving a fixed bit rate of 25.78125 Gbaud. + Please refer to the IEEE standard for further information. + ``PHY_INTERFACE_MODE_100BASEX`` This defines IEEE 802.3 Clause 24. The link operates at a fixed data rate of 125Mpbs using a 4B/5B encoding scheme, resulting in an underlying diff --git a/Documentation/s390/vfio-ap.rst b/Documentation/s390/vfio-ap.rst index e15436599086..f57ae621f33e 100644 --- a/Documentation/s390/vfio-ap.rst +++ b/Documentation/s390/vfio-ap.rst @@ -514,7 +514,6 @@ These are the steps: * S390_AP_IOMMU * VFIO * VFIO_MDEV - * VFIO_MDEV_DEVICE * KVM If using make menuconfig select the following to build the vfio_ap module:: diff --git a/Documentation/scsi/scsi_mid_low_api.rst b/Documentation/scsi/scsi_mid_low_api.rst index 096ffe9cae0e..63ddea2b9640 100644 --- a/Documentation/scsi/scsi_mid_low_api.rst +++ b/Documentation/scsi/scsi_mid_low_api.rst @@ -1172,10 +1172,9 @@ Members of interest: of 0 implies a successfully completed command (and all data (if any) has been transferred to or from the SCSI target device). 'result' is a 32 bit unsigned integer that - can be viewed as 4 related bytes. The SCSI status value is - in the LSB. See include/scsi/scsi.h status_byte(), - msg_byte(), host_byte() and driver_byte() macros and - related constants. + can be viewed as 2 related bytes. The SCSI status value is + in the LSB. See include/scsi/scsi.h status_byte() and + host_byte() macros and related constants. sense_buffer - an array (maximum size: SCSI_SENSE_BUFFERSIZE bytes) that should be written when the SCSI status (LSB of 'result') diff --git a/Documentation/sound/hd-audio/controls.rst b/Documentation/sound/hd-audio/controls.rst index f2ebc4f79b44..dbe6483f4ff4 100644 --- a/Documentation/sound/hd-audio/controls.rst +++ b/Documentation/sound/hd-audio/controls.rst @@ -102,7 +102,7 @@ Conexant codecs --------------- Auto-Mute Mode - See Reatek codecs. + See Realtek codecs. Analog codecs diff --git a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst index e6365836fa8b..01d59b8aea92 100644 --- a/Documentation/sound/kernel-api/writing-an-alsa-driver.rst +++ b/Documentation/sound/kernel-api/writing-an-alsa-driver.rst @@ -3508,14 +3508,15 @@ field must be set, though). “IEC958 Playback Con Mask” is used to return the bit-mask for the IEC958 status bits of consumer mode. Similarly, “IEC958 Playback Pro Mask” -returns the bitmask for professional mode. They are read-only controls, -and are defined as MIXER controls (iface = -``SNDRV_CTL_ELEM_IFACE_MIXER``). +returns the bitmask for professional mode. They are read-only controls. Meanwhile, “IEC958 Playback Default” control is defined for getting and -setting the current default IEC958 bits. Note that this one is usually -defined as a PCM control (iface = ``SNDRV_CTL_ELEM_IFACE_PCM``), -although in some places it's defined as a MIXER control. +setting the current default IEC958 bits. + +Due to historical reasons, both variants of the Playback Mask and the +Playback Default controls can be implemented on either a +``SNDRV_CTL_ELEM_IFACE_PCM`` or a ``SNDRV_CTL_ELEM_IFACE_MIXER`` iface. +Drivers should expose the mask and default on the same iface though. In addition, you can define the control switches to enable/disable or to set the raw bit mode. The implementation will depend on the chip, but diff --git a/Documentation/trace/boottime-trace.rst b/Documentation/trace/boottime-trace.rst index 89b64334929b..8053898cfeb4 100644 --- a/Documentation/trace/boottime-trace.rst +++ b/Documentation/trace/boottime-trace.rst @@ -99,6 +99,12 @@ These options are setting per-event options. ftrace.[instance.INSTANCE.]event.GROUP.EVENT.enable Enable GROUP:EVENT tracing. +ftrace.[instance.INSTANCE.]event.GROUP.enable + Enable all event tracing within GROUP. + +ftrace.[instance.INSTANCE.]event.enable + Enable all event tracing. + ftrace.[instance.INSTANCE.]event.GROUP.EVENT.filter = FILTER Set FILTER rule to the GROUP:EVENT. diff --git a/Documentation/trace/hwlat_detector.rst b/Documentation/trace/hwlat_detector.rst index 5739349649c8..de94b499b0bc 100644 --- a/Documentation/trace/hwlat_detector.rst +++ b/Documentation/trace/hwlat_detector.rst @@ -76,8 +76,13 @@ in /sys/kernel/tracing: - tracing_cpumask - the CPUs to move the hwlat thread across - hwlat_detector/width - specified amount of time to spin within window (usecs) - hwlat_detector/window - amount of time between (width) runs (usecs) + - hwlat_detector/mode - the thread mode -The hwlat detector's kernel thread will migrate across each CPU specified in -tracing_cpumask between each window. To limit the migration, either modify -tracing_cpumask, or modify the hwlat kernel thread (named [hwlatd]) CPU -affinity directly, and the migration will stop. +By default, one hwlat detector's kernel thread will migrate across each CPU +specified in cpumask at the beginning of a new window, in a round-robin +fashion. This behavior can be changed by changing the thread mode, +the available options are: + + - none: do not force migration + - round-robin: migrate across each CPU specified in cpumask [default] + - per-cpu: create one thread for each cpu in tracing_cpumask diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index f634b36fd3aa..3769b9b7aed8 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -23,6 +23,8 @@ Linux Tracing Technologies histogram-design boottime-trace hwlat_detector + osnoise-tracer + timerlat-tracer intel_th ring-buffer-design stm diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst new file mode 100644 index 000000000000..b648cb9bf1f0 --- /dev/null +++ b/Documentation/trace/osnoise-tracer.rst @@ -0,0 +1,152 @@ +============== +OSNOISE Tracer +============== + +In the context of high-performance computing (HPC), the Operating System +Noise (*osnoise*) refers to the interference experienced by an application +due to activities inside the operating system. In the context of Linux, +NMIs, IRQs, SoftIRQs, and any other system thread can cause noise to the +system. Moreover, hardware-related jobs can also cause noise, for example, +via SMIs. + +hwlat_detector is one of the tools used to identify the most complex +source of noise: *hardware noise*. + +In a nutshell, the hwlat_detector creates a thread that runs +periodically for a given period. At the beginning of a period, the thread +disables interrupt and starts sampling. While running, the hwlatd +thread reads the time in a loop. As interrupts are disabled, threads, +IRQs, and SoftIRQs cannot interfere with the hwlatd thread. Hence, the +cause of any gap between two different reads of the time roots either on +NMI or in the hardware itself. At the end of the period, hwlatd enables +interrupts and reports the max observed gap between the reads. It also +prints a NMI occurrence counter. If the output does not report NMI +executions, the user can conclude that the hardware is the culprit for +the latency. The hwlat detects the NMI execution by observing +the entry and exit of a NMI. + +The osnoise tracer leverages the hwlat_detector by running a +similar loop with preemption, SoftIRQs and IRQs enabled, thus allowing +all the sources of *osnoise* during its execution. Using the same approach +of hwlat, osnoise takes note of the entry and exit point of any +source of interferences, increasing a per-cpu interference counter. The +osnoise tracer also saves an interference counter for each source of +interference. The interference counter for NMI, IRQs, SoftIRQs, and +threads is increased anytime the tool observes these interferences' entry +events. When a noise happens without any interference from the operating +system level, the hardware noise counter increases, pointing to a +hardware-related noise. In this way, osnoise can account for any +source of interference. At the end of the period, the osnoise tracer +prints the sum of all noise, the max single noise, the percentage of CPU +available for the thread, and the counters for the noise sources. + +Usage +----- + +Write the ASCII text "osnoise" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo osnoise > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: osnoise + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth MAX + # || / SINGLE Interference counters: + # |||| RUNTIME NOISE % OF CPU NOISE +-----------------------------+ + # TASK-PID CPU# |||| TIMESTAMP IN US IN US AVAILABLE IN US HW NMI IRQ SIRQ THREAD + # | | | |||| | | | | | | | | | | + <...>-859 [000] .... 81.637220: 1000000 190 99.98100 9 18 0 1007 18 1 + <...>-860 [001] .... 81.638154: 1000000 656 99.93440 74 23 0 1006 16 3 + <...>-861 [002] .... 81.638193: 1000000 5675 99.43250 202 6 0 1013 25 21 + <...>-862 [003] .... 81.638242: 1000000 125 99.98750 45 1 0 1011 23 0 + <...>-863 [004] .... 81.638260: 1000000 1721 99.82790 168 7 0 1002 49 41 + <...>-864 [005] .... 81.638286: 1000000 263 99.97370 57 6 0 1006 26 2 + <...>-865 [006] .... 81.638302: 1000000 109 99.98910 21 3 0 1006 18 1 + <...>-866 [007] .... 81.638326: 1000000 7816 99.21840 107 8 0 1016 39 19 + +In addition to the regular trace fields (from TASK-PID to TIMESTAMP), the +tracer prints a message at the end of each period for each CPU that is +running an osnoise/ thread. The osnoise specific fields report: + + - The RUNTIME IN US reports the amount of time in microseconds that + the osnoise thread kept looping reading the time. + - The NOISE IN US reports the sum of noise in microseconds observed + by the osnoise tracer during the associated runtime. + - The % OF CPU AVAILABLE reports the percentage of CPU available for + the osnoise thread during the runtime window. + - The MAX SINGLE NOISE IN US reports the maximum single noise observed + during the runtime window. + - The Interference counters display how many each of the respective + interference happened during the runtime window. + +Note that the example above shows a high number of HW noise samples. +The reason being is that this sample was taken on a virtual machine, +and the host interference is detected as a hardware interference. + +Tracer options +--------------------- + +The tracer has a set of options inside the osnoise directory, they are: + + - osnoise/cpus: CPUs at which a osnoise thread will execute. + - osnoise/period_us: the period of the osnoise thread. + - osnoise/runtime_us: how long an osnoise thread will look for noise. + - osnoise/stop_tracing_us: stop the system tracing if a single noise + higher than the configured value happens. Writing 0 disables this + option. + - osnoise/stop_tracing_total_us: stop the system tracing if total noise + higher than the configured value happens. Writing 0 disables this + option. + - tracing_threshold: the minimum delta between two time() reads to be + considered as noise, in us. When set to 0, the default value will + will be used, which is currently 5 us. + +Additional Tracing +------------------ + +In addition to the tracer, a set of tracepoints were added to +facilitate the identification of the osnoise source. + + - osnoise:sample_threshold: printed anytime a noise is higher than + the configurable tolerance_ns. + - osnoise:nmi_noise: noise from NMI, including the duration. + - osnoise:irq_noise: noise from an IRQ, including the duration. + - osnoise:softirq_noise: noise from a SoftIRQ, including the + duration. + - osnoise:thread_noise: noise from a thread, including the duration. + +Note that all the values are *net values*. For example, if while osnoise +is running, another thread preempts the osnoise thread, it will start a +thread_noise duration at the start. Then, an IRQ takes place, preempting +the thread_noise, starting a irq_noise. When the IRQ ends its execution, +it will compute its duration, and this duration will be subtracted from +the thread_noise, in such a way as to avoid the double accounting of the +IRQ execution. This logic is valid for all sources of noise. + +Here is one example of the usage of these tracepoints:: + + osnoise/8-961 [008] d.h. 5789.857532: irq_noise: local_timer:236 start 5789.857529929 duration 1845 ns + osnoise/8-961 [008] dNh. 5789.858408: irq_noise: local_timer:236 start 5789.858404871 duration 2848 ns + migration/8-54 [008] d... 5789.858413: thread_noise: migration/8:54 start 5789.858409300 duration 3068 ns + osnoise/8-961 [008] .... 5789.858413: sample_threshold: start 5789.858404555 duration 8812 ns interferences 2 + +In this example, a noise sample of 8 microseconds was reported in the last +line, pointing to two interferences. Looking backward in the trace, the +two previous entries were about the migration thread running after a +timer IRQ execution. The first event is not part of the noise because +it took place one millisecond before. + +It is worth noticing that the sum of the duration reported in the +tracepoints is smaller than eight us reported in the sample_threshold. +The reason roots in the overhead of the entry and exit code that happens +before and after any interference execution. This justifies the dual +approach: measuring thread and tracing. diff --git a/Documentation/trace/timerlat-tracer.rst b/Documentation/trace/timerlat-tracer.rst new file mode 100644 index 000000000000..c7cbb557aee7 --- /dev/null +++ b/Documentation/trace/timerlat-tracer.rst @@ -0,0 +1,181 @@ +############### +Timerlat tracer +############### + +The timerlat tracer aims to help the preemptive kernel developers to +find souces of wakeup latencies of real-time threads. Like cyclictest, +the tracer sets a periodic timer that wakes up a thread. The thread then +computes a *wakeup latency* value as the difference between the *current +time* and the *absolute time* that the timer was set to expire. The main +goal of timerlat is tracing in such a way to help kernel developers. + +Usage +----- + +Write the ASCII text "timerlat" into the current_tracer file of the +tracing system (generally mounted at /sys/kernel/tracing). + +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + +It is possible to follow the trace by reading the trace trace file:: + + [root@f32 tracing]# cat trace + # tracer: timerlat + # + # _-----=> irqs-off + # / _----=> need-resched + # | / _---=> hardirq/softirq + # || / _--=> preempt-depth + # || / + # |||| ACTIVATION + # TASK-PID CPU# |||| TIMESTAMP ID CONTEXT LATENCY + # | | | |||| | | | | + <idle>-0 [000] d.h1 54.029328: #1 context irq timer_latency 932 ns + <...>-867 [000] .... 54.029339: #1 context thread timer_latency 11700 ns + <idle>-0 [001] dNh1 54.029346: #1 context irq timer_latency 2833 ns + <...>-868 [001] .... 54.029353: #1 context thread timer_latency 9820 ns + <idle>-0 [000] d.h1 54.030328: #2 context irq timer_latency 769 ns + <...>-867 [000] .... 54.030330: #2 context thread timer_latency 3070 ns + <idle>-0 [001] d.h1 54.030344: #2 context irq timer_latency 935 ns + <...>-868 [001] .... 54.030347: #2 context thread timer_latency 4351 ns + + +The tracer creates a per-cpu kernel thread with real-time priority that +prints two lines at every activation. The first is the *timer latency* +observed at the *hardirq* context before the activation of the thread. +The second is the *timer latency* observed by the thread. The ACTIVATION +ID field serves to relate the *irq* execution to its respective *thread* +execution. + +The *irq*/*thread* splitting is important to clarify at which context +the unexpected high value is coming from. The *irq* context can be +delayed by hardware related actions, such as SMIs, NMIs, IRQs +or by a thread masking interrupts. Once the timer happens, the delay +can also be influenced by blocking caused by threads. For example, by +postponing the scheduler execution via preempt_disable(), by the +scheduler execution, or by masking interrupts. Threads can +also be delayed by the interference from other threads and IRQs. + +Tracer options +--------------------- + +The timerlat tracer is built on top of osnoise tracer. +So its configuration is also done in the osnoise/ config +directory. The timerlat configs are: + + - cpus: CPUs at which a timerlat thread will execute. + - timerlat_period_us: the period of the timerlat thread. + - osnoise/stop_tracing_us: stop the system tracing if a + timer latency at the *irq* context higher than the configured + value happens. Writing 0 disables this option. + - stop_tracing_total_us: stop the system tracing if a + timer latency at the *thread* context higher than the configured + value happens. Writing 0 disables this option. + - print_stack: save the stack of the IRQ ocurrence, and print + it afte the *thread context* event". + +timerlat and osnoise +---------------------------- + +The timerlat can also take advantage of the osnoise: traceevents. +For example:: + + [root@f32 ~]# cd /sys/kernel/tracing/ + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# echo 1 > events/osnoise/enable + [root@f32 tracing]# echo 25 > osnoise/stop_tracing_total_us + [root@f32 tracing]# tail -10 trace + cc1-87882 [005] d..h... 548.771078: #402268 context irq timer_latency 13585 ns + cc1-87882 [005] dNLh1.. 548.771082: irq_noise: local_timer:236 start 548.771077442 duration 7597 ns + cc1-87882 [005] dNLh2.. 548.771099: irq_noise: qxl:21 start 548.771085017 duration 7139 ns + cc1-87882 [005] d...3.. 548.771102: thread_noise: cc1:87882 start 548.771078243 duration 9909 ns + timerlat/5-1035 [005] ....... 548.771104: #402268 context thread timer_latency 39960 ns + +In this case, the root cause of the timer latency does not point to a +single cause, but to multiple ones. Firstly, the timer IRQ was delayed +for 13 us, which may point to a long IRQ disabled section (see IRQ +stacktrace section). Then the timer interrupt that wakes up the timerlat +thread took 7597 ns, and the qxl:21 device IRQ took 7139 ns. Finally, +the cc1 thread noise took 9909 ns of time before the context switch. +Such pieces of evidence are useful for the developer to use other +tracing methods to figure out how to debug and optimize the system. + +It is worth mentioning that the *duration* values reported +by the osnoise: events are *net* values. For example, the +thread_noise does not include the duration of the overhead caused +by the IRQ execution (which indeed accounted for 12736 ns). But +the values reported by the timerlat tracer (timerlat_latency) +are *gross* values. + +The art below illustrates a CPU timeline and how the timerlat tracer +observes it at the top and the osnoise: events at the bottom. Each "-" +in the timelines means circa 1 us, and the time moves ==>:: + + External timer irq thread + clock latency latency + event 13585 ns 39960 ns + | ^ ^ + v | | + |-------------| | + |-------------+-------------------------| + ^ ^ + ======================================================================== + [tmr irq] [dev irq] + [another thread...^ v..^ v.......][timerlat/ thread] <-- CPU timeline + ========================================================================= + |-------| |-------| + |--^ v-------| + | | | + | | + thread_noise: 9909 ns + | +-> irq_noise: 6139 ns + +-> irq_noise: 7597 ns + +IRQ stacktrace +--------------------------- + +The osnoise/print_stack option is helpful for the cases in which a thread +noise causes the major factor for the timer latency, because of preempt or +irq disabled. For example:: + + [root@f32 tracing]# echo 500 > osnoise/stop_tracing_total_us + [root@f32 tracing]# echo 500 > osnoise/print_stack + [root@f32 tracing]# echo timerlat > current_tracer + [root@f32 tracing]# tail -21 per_cpu/cpu7/trace + insmod-1026 [007] dN.h1.. 200.201948: irq_noise: local_timer:236 start 200.201939376 duration 7872 ns + insmod-1026 [007] d..h1.. 200.202587: #29800 context irq timer_latency 1616 ns + insmod-1026 [007] dN.h2.. 200.202598: irq_noise: local_timer:236 start 200.202586162 duration 11855 ns + insmod-1026 [007] dN.h3.. 200.202947: irq_noise: local_timer:236 start 200.202939174 duration 7318 ns + insmod-1026 [007] d...3.. 200.203444: thread_noise: insmod:1026 start 200.202586933 duration 838681 ns + timerlat/7-1001 [007] ....... 200.203445: #29800 context thread timer_latency 859978 ns + timerlat/7-1001 [007] ....1.. 200.203446: <stack trace> + => timerlat_irq + => __hrtimer_run_queues + => hrtimer_interrupt + => __sysvec_apic_timer_interrupt + => asm_call_irq_on_stack + => sysvec_apic_timer_interrupt + => asm_sysvec_apic_timer_interrupt + => delay_tsc + => dummy_load_1ms_pd_init + => do_one_initcall + => do_init_module + => __do_sys_finit_module + => do_syscall_64 + => entry_SYSCALL_64_after_hwframe + +In this case, it is possible to see that the thread added the highest +contribution to the *timer latency* and the stack trace, saved during +the timerlat IRQ handler, points to a function named +dummy_load_1ms_pd_init, which had the following code (on purpose):: + + static int __init dummy_load_1ms_pd_init(void) + { + preempt_disable(); + mdelay(1); + preempt_enable(); + return 0; + + } diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index 2085e7b24eeb..9d6276f82774 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -728,6 +728,8 @@ The uac2 function provides these attributes in its function directory: 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) diff --git a/Documentation/userspace-api/accelerators/ocxl.rst b/Documentation/userspace-api/accelerators/ocxl.rst index 14cefc020e2d..db7570d5e50d 100644 --- a/Documentation/userspace-api/accelerators/ocxl.rst +++ b/Documentation/userspace-api/accelerators/ocxl.rst @@ -6,7 +6,7 @@ OpenCAPI is an interface between processors and accelerators. It aims at being low-latency and high-bandwidth. The specification is developed by the `OpenCAPI Consortium <http://opencapi.org/>`_. -It allows an accelerator (which could be a FPGA, ASICs, ...) to access +It allows an accelerator (which could be an FPGA, ASICs, ...) to access the host memory coherently, using virtual addresses. An OpenCAPI device can also host its own memory, that can be accessed from the host. diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 9bfc2b510c64..1409e40e6345 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -325,7 +325,7 @@ Code Seq# Include File Comments 0xA3 90-9F linux/dtlk.h 0xA4 00-1F uapi/linux/tee.h Generic TEE subsystem 0xA4 00-1F uapi/asm/sgx.h <mailto:linux-sgx@vger.kernel.org> -0xA5 01 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator +0xA5 01-05 linux/surface_aggregator/cdev.h Microsoft Surface Platform System Aggregator <mailto:luzmaximilian@gmail.com> 0xA5 20-2F linux/surface_aggregator/dtx.h Microsoft Surface DTX driver <mailto:luzmaximilian@gmail.com> diff --git a/Documentation/vm/hmm.rst b/Documentation/vm/hmm.rst index 09e28507f5b2..a14c2938e7af 100644 --- a/Documentation/vm/hmm.rst +++ b/Documentation/vm/hmm.rst @@ -332,7 +332,7 @@ between device driver specific code and shared common code: walks to fill in the ``args->src`` array with PFNs to be migrated. The ``invalidate_range_start()`` callback is passed a ``struct mmu_notifier_range`` with the ``event`` field set to - ``MMU_NOTIFY_MIGRATE`` and the ``migrate_pgmap_owner`` field set to + ``MMU_NOTIFY_MIGRATE`` and the ``owner`` field set to the ``args->pgmap_owner`` field passed to migrate_vma_setup(). This is allows the device driver to skip the invalidation callback and only invalidate device private MMU mappings that are actually migrating. @@ -405,6 +405,23 @@ between device driver specific code and shared common code: The lock can now be released. +Exclusive access memory +======================= + +Some devices have features such as atomic PTE bits that can be used to implement +atomic access to system memory. To support atomic operations to a shared virtual +memory page such a device needs access to that page which is exclusive of any +userspace access from the CPU. The ``make_device_exclusive_range()`` function +can be used to make a memory range inaccessible from userspace. + +This replaces all mappings for pages in the given range with special swap +entries. Any attempt to access the swap entry results in a fault which is +resovled by replacing the entry with the original mapping. A driver gets +notified that the mapping has been changed by MMU notifiers, after which point +it will no longer have exclusive access to the page. Exclusive access is +guranteed to last until the driver drops the page lock and page reference, at +which point any CPU faults on the page may proceed as described. + Memory cgroup (memcg) and rss accounting ======================================== diff --git a/Documentation/vm/memory-model.rst b/Documentation/vm/memory-model.rst index ce398a7dc6cd..30e8fbed6914 100644 --- a/Documentation/vm/memory-model.rst +++ b/Documentation/vm/memory-model.rst @@ -14,15 +14,11 @@ for the CPU. Then there could be several contiguous ranges at completely distinct addresses. And, don't forget about NUMA, where different memory banks are attached to different CPUs. -Linux abstracts this diversity using one of the three memory models: -FLATMEM, DISCONTIGMEM and SPARSEMEM. Each architecture defines what +Linux abstracts this diversity using one of the two memory models: +FLATMEM and SPARSEMEM. Each architecture defines what memory models it supports, what the default memory model is and whether it is possible to manually override that default. -.. note:: - At time of this writing, DISCONTIGMEM is considered deprecated, - although it is still in use by several architectures. - All the memory models track the status of physical page frames using struct page arranged in one or more arrays. @@ -63,43 +59,6 @@ straightforward: `PFN - ARCH_PFN_OFFSET` is an index to the The `ARCH_PFN_OFFSET` defines the first page frame number for systems with physical memory starting at address different from 0. -DISCONTIGMEM -============ - -The DISCONTIGMEM model treats the physical memory as a collection of -`nodes` similarly to how Linux NUMA support does. For each node Linux -constructs an independent memory management subsystem represented by -`struct pglist_data` (or `pg_data_t` for short). Among other -things, `pg_data_t` holds the `node_mem_map` array that maps -physical pages belonging to that node. The `node_start_pfn` field of -`pg_data_t` is the number of the first page frame belonging to that -node. - -The architecture setup code should call :c:func:`free_area_init_node` for -each node in the system to initialize the `pg_data_t` object and its -`node_mem_map`. - -Every `node_mem_map` behaves exactly as FLATMEM's `mem_map` - -every physical page frame in a node has a `struct page` entry in the -`node_mem_map` array. When DISCONTIGMEM is enabled, a portion of the -`flags` field of the `struct page` encodes the node number of the -node hosting that page. - -The conversion between a PFN and the `struct page` in the -DISCONTIGMEM model became slightly more complex as it has to determine -which node hosts the physical page and which `pg_data_t` object -holds the `struct page`. - -Architectures that support DISCONTIGMEM provide :c:func:`pfn_to_nid` -to convert PFN to the node number. The opposite conversion helper -:c:func:`page_to_nid` is generic as it uses the node number encoded in -page->flags. - -Once the node number is known, the PFN can be used to index -appropriate `node_mem_map` array to access the `struct page` and -the offset of the `struct page` from the `node_mem_map` plus -`node_start_pfn` is the PFN of that page. - SPARSEMEM ========= diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index 0e1490524f53..eae3af17f2d9 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -389,14 +389,14 @@ mlocked, munlock_vma_page() updates that zone statistics for the number of mlocked pages. Note, however, that at this point we haven't checked whether the page is mapped by other VM_LOCKED VMAs. -We can't call try_to_munlock(), the function that walks the reverse map to +We can't call page_mlock(), the function that walks the reverse map to check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -try_to_munlock() is a variant of try_to_unmap() and thus requires that the page +page_mlock() is a variant of try_to_unmap() and thus requires that the page not be on an LRU list [more on these below]. However, the call to -isolate_lru_page() could fail, in which case we couldn't try_to_munlock(). So, +isolate_lru_page() could fail, in which case we can't call page_mlock(). So, we go ahead and clear PG_mlocked up front, as this might be the only chance we -have. If we can successfully isolate the page, we go ahead and -try_to_munlock(), which will restore the PG_mlocked flag and update the zone +have. If we can successfully isolate the page, we go ahead and call +page_mlock(), which will restore the PG_mlocked flag and update the zone page statistics if it finds another VMA holding the page mlocked. If we fail to isolate the page, we'll have left a potentially mlocked page on the LRU. This is fine, because we'll catch it later if and if vmscan tries to reclaim @@ -545,31 +545,24 @@ munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, holepunching, and truncation of file pages and their anonymous COWed pages. -try_to_munlock() Reverse Map Scan +page_mlock() Reverse Map Scan --------------------------------- -.. warning:: - [!] TODO/FIXME: a better name might be page_mlocked() - analogous to the - page_referenced() reverse map walker. - When munlock_vma_page() [see section :ref:`munlock()/munlockall() System Call Handling <munlock_munlockall_handling>` above] tries to munlock a page, it needs to determine whether or not the page is mapped by any VM_LOCKED VMA without actually attempting to unmap all PTEs from the page. For this purpose, the unevictable/mlock infrastructure -introduced a variant of try_to_unmap() called try_to_munlock(). +introduced a variant of try_to_unmap() called page_mlock(). -try_to_munlock() calls the same functions as try_to_unmap() for anonymous and -mapped file and KSM pages with a flag argument specifying unlock versus unmap -processing. Again, these functions walk the respective reverse maps looking -for VM_LOCKED VMAs. When such a VMA is found, as in the try_to_unmap() case, -the functions mlock the page via mlock_vma_page() and return SWAP_MLOCK. This -undoes the pre-clearing of the page's PG_mlocked done by munlock_vma_page. +page_mlock() walks the respective reverse maps looking for VM_LOCKED VMAs. When +such a VMA is found the page is mlocked via mlock_vma_page(). This undoes the +pre-clearing of the page's PG_mlocked done by munlock_vma_page. -Note that try_to_munlock()'s reverse map walk must visit every VMA in a page's +Note that page_mlock()'s reverse map walk must visit every VMA in a page's reverse map to determine that a page is NOT mapped into any VM_LOCKED VMA. However, the scan can terminate when it encounters a VM_LOCKED VMA. -Although try_to_munlock() might be called a great many times when munlocking a +Although page_mlock() might be called a great many times when munlocking a large region or tearing down a large address space that has been mlocked via mlockall(), overall this is a fairly rare event. @@ -602,7 +595,7 @@ inactive lists to the appropriate node's unevictable list. shrink_inactive_list() should only see SHM_LOCK'd pages that became SHM_LOCK'd after shrink_active_list() had moved them to the inactive list, or pages mapped into VM_LOCKED VMAs that munlock_vma_page() couldn't isolate from the LRU to -recheck via try_to_munlock(). shrink_inactive_list() won't notice the latter, +recheck via page_mlock(). shrink_inactive_list() won't notice the latter, but will pass on to shrink_page_list(). shrink_page_list() again culls obviously unevictable pages that it could diff --git a/Documentation/w1/slaves/w1_ds2438.rst b/Documentation/w1/slaves/w1_ds2438.rst index a29309a3f8e5..4fa671fbc93f 100644 --- a/Documentation/w1/slaves/w1_ds2438.rst +++ b/Documentation/w1/slaves/w1_ds2438.rst @@ -22,7 +22,7 @@ is also often used in weather stations and applications such as: rain gauge, wind speed/direction measuring, humidity sensing, etc. Current support is provided through the following sysfs files (all files -except "iad" are readonly): +except "iad" and "offset" are readonly): "iad" ----- @@ -44,6 +44,23 @@ Internally when this file is read, the additional CRC byte is also obtained from the slave device. If it is correct, the 8 bytes page data are passed to userspace, otherwise an I/O error is returned. +"page1" +------- +This file provides full 8 bytes of the chip Page 1 (01h). +This page contains the ICA, elapsed time meter and current offset data of the DS2438. +Internally when this file is read, the additional CRC byte is also obtained +from the slave device. If it is correct, the 8 bytes page data are passed +to userspace, otherwise an I/O error is returned. + +"offset" +-------- +This file controls the 2-byte Offset Register of the chip. +Writing a 2-byte value will change the Offset Register, which changes the +current measurement done by the chip. Changing this register to the two's complement +of the current register while forcing zero current through the load will calibrate +the chip, canceling offset errors in the current ADC. + + "temperature" ------------- Opening and reading this file initiates the CONVERT_T (temperature conversion) diff --git a/Documentation/x86/elf_auxvec.rst b/Documentation/x86/elf_auxvec.rst new file mode 100644 index 000000000000..18e4744717f9 --- /dev/null +++ b/Documentation/x86/elf_auxvec.rst @@ -0,0 +1,53 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +x86-specific ELF Auxiliary Vectors +================================== + +This document describes the semantics of the x86 auxiliary vectors. + +Introduction +============ + +ELF Auxiliary vectors enable the kernel to efficiently provide +configuration-specific parameters to userspace. In this example, a program +allocates an alternate stack based on the kernel-provided size:: + + #include <sys/auxv.h> + #include <elf.h> + #include <signal.h> + #include <stdlib.h> + #include <assert.h> + #include <err.h> + + #ifndef AT_MINSIGSTKSZ + #define AT_MINSIGSTKSZ 51 + #endif + + .... + stack_t ss; + + ss.ss_sp = malloc(ss.ss_size); + assert(ss.ss_sp); + + ss.ss_size = getauxval(AT_MINSIGSTKSZ) + SIGSTKSZ; + ss.ss_flags = 0; + + if (sigaltstack(&ss, NULL)) + err(1, "sigaltstack"); + + +The exposed auxiliary vectors +============================= + +AT_SYSINFO is used for locating the vsyscall entry point. It is not +exported on 64-bit mode. + +AT_SYSINFO_EHDR is the start address of the page containing the vDSO. + +AT_MINSIGSTKSZ denotes the minimum stack size required by the kernel to +deliver a signal to user-space. AT_MINSIGSTKSZ comprehends the space +consumed by the kernel to accommodate the user context for the current +hardware configuration. It does not comprehend subsequent user-space stack +consumption, which must be added by the user. (e.g. Above, user-space adds +SIGSTKSZ to AT_MINSIGSTKSZ.) diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index 0004f5d2283e..383048396336 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -36,3 +36,4 @@ x86-specific Documentation sva sgx features + elf_auxvec |