diff options
Diffstat (limited to 'Documentation')
1037 files changed, 37924 insertions, 11875 deletions
diff --git a/Documentation/ABI/obsolete/procfs-i8k b/Documentation/ABI/obsolete/procfs-i8k new file mode 100644 index 000000000000..32df4d5bdd15 --- /dev/null +++ b/Documentation/ABI/obsolete/procfs-i8k @@ -0,0 +1,10 @@ +What: /proc/i8k +Date: November 2001 +KernelVersion: 2.4.14 +Contact: Pali Rohár <pali@kernel.org> +Description: Legacy interface for getting/setting sensor information like + fan speed, temperature, serial number, hotkey status etc + on Dell Laptops. + Since the driver is now using the standard hwmon sysfs interface, + the procfs interface is deprecated. +Users: https://github.com/vitorafsr/i8kutils diff --git a/Documentation/ABI/removed/sysfs-mce b/Documentation/ABI/removed/sysfs-mce new file mode 100644 index 000000000000..ef5dd2a80918 --- /dev/null +++ b/Documentation/ABI/removed/sysfs-mce @@ -0,0 +1,37 @@ +What: /sys/devices/system/machinecheck/machinecheckX/tolerant +Contact: Borislav Petkov <bp@suse.de> +Date: Dec, 2021 +Description: + Unused and obsolete after the advent of recoverable machine + checks (see last sentence below) and those are present since + 2010 (Nehalem). + + Original description: + + The entries appear for each CPU, but they are truly shared + between all CPUs. + + Tolerance level. When a machine check exception occurs for a + non corrected machine check the kernel can take different + actions. + + Since machine check exceptions can happen any time it is + sometimes risky for the kernel to kill a process because it + defies normal kernel locking rules. The tolerance level + configures how hard the kernel tries to recover even at some + risk of deadlock. Higher tolerant values trade potentially + better uptime with the risk of a crash or even corruption + (for tolerant >= 3). + + == =========================================================== + 0 always panic on uncorrected errors, log corrected errors + 1 panic or SIGBUS on uncorrected errors, log corrected errors + 2 SIGBUS or log uncorrected errors, log corrected errors + 3 never panic or SIGBUS, log all errors (for testing only) + == =========================================================== + + Default: 1 + + Note this only makes a difference if the CPU allows recovery + from a machine check exception. Current x86 CPUs generally + do not. diff --git a/Documentation/ABI/stable/sysfs-block b/Documentation/ABI/stable/sysfs-block index 8dd3e84a8aad..e8797cd09aff 100644 --- a/Documentation/ABI/stable/sysfs-block +++ b/Documentation/ABI/stable/sysfs-block @@ -155,6 +155,55 @@ Description: last zone of the device which may be smaller. +What: /sys/block/<disk>/queue/crypto/ +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + The presence of this subdirectory of /sys/block/<disk>/queue/ + indicates that the device supports inline encryption. This + subdirectory contains files which describe the inline encryption + capabilities of the device. For more information about inline + encryption, refer to Documentation/block/inline-encryption.rst. + + +What: /sys/block/<disk>/queue/crypto/max_dun_bits +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] This file shows the maximum length, in bits, of data unit + numbers accepted by the device in inline encryption requests. + + +What: /sys/block/<disk>/queue/crypto/modes/<mode> +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] For each crypto mode (i.e., encryption/decryption + algorithm) the device supports with inline encryption, a file + will exist at this location. It will contain a hexadecimal + number that is a bitmask of the supported data unit sizes, in + bytes, for that crypto mode. + + Currently, the crypto modes that may be supported are: + + * AES-256-XTS + * AES-128-CBC-ESSIV + * Adiantum + + For example, if a device supports AES-256-XTS inline encryption + with data unit sizes of 512 and 4096 bytes, the file + /sys/block/<disk>/queue/crypto/modes/AES-256-XTS will exist and + will contain "0x1200". + + +What: /sys/block/<disk>/queue/crypto/num_keyslots +Date: February 2022 +Contact: linux-block@vger.kernel.org +Description: + [RO] This file shows the number of keyslots the device has for + use with inline encryption. + + What: /sys/block/<disk>/queue/dax Date: June 2016 Contact: linux-block@vger.kernel.org diff --git a/Documentation/ABI/stable/sysfs-devices-system-cpu b/Documentation/ABI/stable/sysfs-devices-system-cpu index 3965ce504484..902392d7eddf 100644 --- a/Documentation/ABI/stable/sysfs-devices-system-cpu +++ b/Documentation/ABI/stable/sysfs-devices-system-cpu @@ -86,6 +86,10 @@ What: /sys/devices/system/cpu/cpuX/topology/die_cpus Description: internal kernel map of CPUs within the same die. Values: hexadecimal bitmask. +What: /sys/devices/system/cpu/cpuX/topology/ppin +Description: per-socket protected processor inventory number +Values: hexadecimal. + What: /sys/devices/system/cpu/cpuX/topology/die_cpus_list Description: human-readable list of CPUs within the same die. The format is like 0-3, 8-11, 14,17. diff --git a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp index f5724bb5b462..c3fec3c835af 100644 --- a/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp +++ b/Documentation/ABI/stable/sysfs-driver-firmware-zynqmp @@ -113,3 +113,144 @@ Description: # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/health_status Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "Ronak Jain" <ronak.jain@xilinx.com> +Description: + This sysfs interface allows user to configure features at + runtime. The user can enable or disable features running at + firmware as well as the user can configure the parameters of + the features at runtime. The supported features are over + temperature and external watchdog. Here, the external watchdog + is completely different than the /dev/watchdog as the external + watchdog is running on the firmware and it is used to monitor + the health of firmware not APU(Linux). Also, the external + watchdog is interfaced outside of the zynqmp soc. + + The supported config ids are for the feature configuration is, + 1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or + disable the over temperature feature. + 2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the + over temperature limit in Degree Celsius. + 3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable + the external watchdog feature. + 4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the + external watchdog feature. + + Usage: + + Select over temperature config ID to enable/disable feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check over temperature config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 1. + + Select over temperature config ID to configure OT limit + # echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check over temperature config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 2. + + Select external watchdog config ID to enable/disable feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check external watchdog config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 3. + + Select external watchdog config ID to configure time interval + # echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + + Check external watchdog config ID is selected or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + The expected result is 4. + +Users: Xilinx + +What: /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "Ronak Jain" <ronak.jain@xilinx.com> +Description: + This sysfs interface allows to configure features at runtime. + The user can enable or disable features running at firmware. + Also, the user can configure the parameters of the features + at runtime. The supported features are over temperature and + external watchdog. Here, the external watchdog is completely + different than the /dev/watchdog as the external watchdog is + running on the firmware and it is used to monitor the health + of firmware not APU(Linux). Also, the external watchdog is + interfaced outside of the zynqmp soc. + + By default the features are disabled in the firmware. The user + can enable features by querying appropriate config id of the + features. + + The default limit for the over temperature is 90 Degree Celsius. + The default timer interval for the external watchdog is 570ms. + + The supported config ids are for the feature configuration is, + 1. PM_FEATURE_OVERTEMP_STATUS = 1, the user can enable or + disable the over temperature feature. + 2. PM_FEATURE_OVERTEMP_VALUE = 2, the user can configure the + over temperature limit in Degree Celsius. + 3. PM_FEATURE_EXTWDT_STATUS = 3, the user can enable or disable + the external watchdog feature. + 4. PM_FEATURE_EXTWDT_VALUE = 4, the user can configure the + external watchdog feature. + + Usage: + + Enable over temperature feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature feature is enabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 1. + + Disable over temperature feature + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature feature is disabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 0. + + Configure over temperature limit to 50 Degree Celsius + # echo 2 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 50 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the over temperature limit is configured or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 50. + + Enable external watchdog feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 1 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog feature is enabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 1. + + Disable external watchdog feature + # echo 3 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 0 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog feature is disabled or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 0. + + Configure external watchdog timer interval to 500ms + # echo 4 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_id + # echo 500 > /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + + Check whether the external watchdog timer interval is configured or not + # cat /sys/devices/platform/firmware\:zynqmp-firmware/feature_config_value + The expected result is 500. + +Users: Xilinx diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac1 b/Documentation/ABI/testing/configfs-usb-gadget-uac1 index d4b8cf40a9e4..c4ba92f004c3 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac1 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac1 @@ -6,7 +6,7 @@ Description: ===================== ======================================= c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_mute_present capture mute control enable c_volume_present capture volume control enable @@ -17,7 +17,7 @@ Description: c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable @@ -29,4 +29,5 @@ Description: (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ===================== ======================================= diff --git a/Documentation/ABI/testing/configfs-usb-gadget-uac2 b/Documentation/ABI/testing/configfs-usb-gadget-uac2 index 7fb3dbe26857..3371c39f651d 100644 --- a/Documentation/ABI/testing/configfs-usb-gadget-uac2 +++ b/Documentation/ABI/testing/configfs-usb-gadget-uac2 @@ -6,8 +6,9 @@ Description: ===================== ======================================= c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) + c_hs_bint capture bInterval for HS/SS (1-4: fixed, 0: auto) c_sync capture synchronization type (async/adaptive) c_mute_present capture mute control enable @@ -20,8 +21,9 @@ Description: (in 1/256 dB) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) + p_hs_bint playback bInterval for HS/SS (1-4: fixed, 0: auto) p_mute_present playback mute control enable p_volume_present playback volume control enable p_volume_min playback volume control min value @@ -32,4 +34,5 @@ Description: (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ===================== ======================================= diff --git a/Documentation/ABI/testing/debugfs-driver-habanalabs b/Documentation/ABI/testing/debugfs-driver-habanalabs index 2667cbf940f3..bcf6915987e4 100644 --- a/Documentation/ABI/testing/debugfs-driver-habanalabs +++ b/Documentation/ABI/testing/debugfs-driver-habanalabs @@ -12,24 +12,7 @@ What: /sys/kernel/debug/habanalabs/hl<n>/clk_gate Date: May 2020 KernelVersion: 5.8 Contact: ogabbay@kernel.org -Description: Allow the root user to disable/enable in runtime the clock - gating mechanism in Gaudi. Due to how Gaudi is built, the - clock gating needs to be disabled in order to access the - registers of the TPC and MME engines. This is sometimes needed - during debug by the user and hence the user needs this option. - The user can supply a bitmask value, each bit represents - a different engine to disable/enable its clock gating feature. - The bitmask is composed of 20 bits: - - ======= ============ - 0 - 7 DMA channels - 8 - 11 MME engines - 12 - 19 TPC engines - ======= ============ - - The bit's location of a specific engine can be determined - using (1 << GAUDI_ENGINE_ID_*). GAUDI_ENGINE_ID_* values - are defined in uapi habanalabs.h file in enum gaudi_engine_id +Description: This setting is now deprecated as clock gating is handled solely by the f/w What: /sys/kernel/debug/habanalabs/hl<n>/command_buffers Date: Jan 2019 @@ -239,6 +222,7 @@ KernelVersion: 5.6 Contact: ogabbay@kernel.org Description: Sets the stop-on_error option for the device engines. Value of "0" is for disable, otherwise enable. + Relevant only for GOYA and GAUDI. What: /sys/kernel/debug/habanalabs/hl<n>/timeout_locked Date: Sep 2021 diff --git a/Documentation/ABI/testing/debugfs-hisi-hpre b/Documentation/ABI/testing/debugfs-hisi-hpre index b4be5f1db4b7..396de7bc735d 100644 --- a/Documentation/ABI/testing/debugfs-hisi-hpre +++ b/Documentation/ABI/testing/debugfs-hisi-hpre @@ -1,140 +1,150 @@ -What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the HPRE cluster. +What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the HPRE cluster. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/cluster_ctrl -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Write the HPRE core selection in the cluster into this file, +What: /sys/kernel/debug/hisi_hpre/<bdf>/cluster[0-3]/cluster_ctrl +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Write the HPRE core selection in the cluster into this file, and then we can read the debug information of the core. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/rdclr_en -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: HPRE cores debug registers read clear control. 1 means enable +What: /sys/kernel/debug/hisi_hpre/<bdf>/rdclr_en +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: HPRE cores debug registers read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/current_qm -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: One HPRE controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_hpre/<bdf>/current_qm +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: One HPRE controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the HPRE. +What: /sys/kernel/debug/hisi_hpre/<bdf>/alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The <bdf> is related the function for PF and VF. + HPRE driver supports to configure each function's QoS, the driver + supports to write <bdf> value to alg_qos in the host. Such as + "echo <bdf> value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + +What: /sys/kernel/debug/hisi_hpre/<bdf>/regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the HPRE. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump debug registers from the QM. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/regs +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump debug registers from the QM. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/current_q -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: One QM may contain multiple queues. Select specific queue to +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/current_q +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: One QM may contain multiple queues. Select specific queue to show its debug registers in above regs. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable -Date: Sep 2019 -Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(regs) read clear control. 1 means enable +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/clear_enable +Date: Sep 2019 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_hpre/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests sent +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent with returning busy. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of completed but error requests. +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/send_fail_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but error requests. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of invalid requests being received. +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Set the threshold time for counting the request which is +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/overtime_thrhld +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Set the threshold time for counting the request which is processed longer than the threshold. 0: disable(default), 1: 1 microsecond. Available for both PF and VF, and take no other effect on HPRE. -What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of time out requests. +What: /sys/kernel/debug/hisi_hpre/<bdf>/hpre_dfx/over_thrhld_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of time out requests. Available for both PF and VF, and take no other effect on HPRE. diff --git a/Documentation/ABI/testing/debugfs-hisi-sec b/Documentation/ABI/testing/debugfs-hisi-sec index 85feb4408e0f..2bf84ced484b 100644 --- a/Documentation/ABI/testing/debugfs-hisi-sec +++ b/Documentation/ABI/testing/debugfs-hisi-sec @@ -1,113 +1,123 @@ -What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Enabling/disabling of clear action after reading +What: /sys/kernel/debug/hisi_sec2/<bdf>/clear_enable +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Enabling/disabling of clear action after reading the SEC debug registers. 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: One SEC controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_sec2/<bdf>/current_qm +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: One SEC controller has one PF and multiple VFs, each function has a QM. This file can be used to select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Dump of QM related debug registers. +What: /sys/kernel/debug/hisi_sec2/<bdf>/alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The <bdf> is related the function for PF and VF. + SEC driver supports to configure each function's QoS, the driver + supports to write <bdf> value to alg_qos in the host. Such as + "echo <bdf> value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/qm_regs +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Dump of QM related debug registers. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: One QM of SEC may contain multiple queues. Select specific +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/current_q +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: One QM of SEC may contain multiple queues. Select specific queue to show its debug registers in above 'regs'. Only available for PF. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable -Date: Oct 2019 -Contact: linux-crypto@vger.kernel.org -Description: Enabling/disabling of clear action after reading +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/clear_enable +Date: Oct 2019 +Contact: linux-crypto@vger.kernel.org +Description: Enabling/disabling of clear action after reading the SEC's QM debug registers. 0: disable, 1: enable. Only available for PF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_sec2/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests sent with returning busy. +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests sent with returning busy. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of BD type error requests +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests to be received. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of invalid requests being received. +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/invalid_req_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of invalid requests being received. Available for both PF and VF, and take no other effect on SEC. -What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of completed but marked error requests +What: /sys/kernel/debug/hisi_sec2/<bdf>/sec_dfx/done_flag_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of completed but marked error requests to be received. Available for both PF and VF, and take no other effect on SEC. diff --git a/Documentation/ABI/testing/debugfs-hisi-zip b/Documentation/ABI/testing/debugfs-hisi-zip index 3034a2bf99ca..bf1258bc6495 100644 --- a/Documentation/ABI/testing/debugfs-hisi-zip +++ b/Documentation/ABI/testing/debugfs-hisi-zip @@ -1,114 +1,124 @@ -What: /sys/kernel/debug/hisi_zip/<bdf>/comp_core[01]/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of compression cores related debug registers. +What: /sys/kernel/debug/hisi_zip/<bdf>/comp_core[01]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of compression cores related debug registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/decomp_core[0-5]/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of decompression cores related debug registers. +What: /sys/kernel/debug/hisi_zip/<bdf>/decomp_core[0-5]/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of decompression cores related debug registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/clear_enable -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Compression/decompression core debug registers read clear +What: /sys/kernel/debug/hisi_zip/<bdf>/clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Compression/decompression core debug registers read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/current_qm -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: One ZIP controller has one PF and multiple VFs, each function +What: /sys/kernel/debug/hisi_zip/<bdf>/current_qm +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One ZIP controller has one PF and multiple VFs, each function has a QM. Select the QM which below qm refers to. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: Dump of QM related debug registers. +What: /sys/kernel/debug/hisi_zip/<bdf>/alg_qos +Date: Jun 2021 +Contact: linux-crypto@vger.kernel.org +Description: The <bdf> is related the function for PF and VF. + ZIP driver supports to configure each function's QoS, the driver + supports to write <bdf> value to alg_qos in the host. Such as + "echo <bdf> value > alg_qos". The qos value is 1~1000, means + 1/1000~1000/1000 of total QoS. The driver reading alg_qos to + get related QoS in the host and VM, Such as "cat alg_qos". + +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/regs +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: Dump of QM related debug registers. Available for PF and VF in host. VF in guest currently only has one debug register. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/current_q -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: One QM may contain multiple queues. Select specific queue to +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/current_q +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: One QM may contain multiple queues. Select specific queue to show its debug registers in above regs. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable -Date: Nov 2018 -Contact: linux-crypto@vger.kernel.org -Description: QM debug registers(regs) read clear control. 1 means enable +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/clear_enable +Date: Nov 2018 +Contact: linux-crypto@vger.kernel.org +Description: QM debug registers(regs) read clear control. 1 means enable register read clear, otherwise 0. Writing to this file has no functional effect, only enable or disable counters clear after reading of these registers. Only available for PF. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of invalid interrupts for +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/err_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of invalid interrupts for QM task completion. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of QM async event queue interrupts. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/aeq_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of QM async event queue interrupts. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of interrupts for QM abnormal event. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/abnormal_irq +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of interrupts for QM abnormal event. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of queue allocation errors. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/create_qp_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of queue allocation errors. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the number of failed QM mailbox commands. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/mb_err +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the number of failed QM mailbox commands. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the status of the QM. +What: /sys/kernel/debug/hisi_zip/<bdf>/qm/status +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the status of the QM. Four states: initiated, started, stopped and closed. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of sent requests. +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of sent requests. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of received requests. +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/recv_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of received requests. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of requests received +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/send_busy_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of requests received with returning busy. Available for both PF and VF, and take no other effect on ZIP. -What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt -Date: Apr 2020 -Contact: linux-crypto@vger.kernel.org -Description: Dump the total number of BD type error requests +What: /sys/kernel/debug/hisi_zip/<bdf>/zip_dfx/err_bd_cnt +Date: Apr 2020 +Contact: linux-crypto@vger.kernel.org +Description: Dump the total number of BD type error requests to be received. Available for both PF and VF, and take no other effect on ZIP. diff --git a/Documentation/ABI/testing/sysfs-bus-cxl b/Documentation/ABI/testing/sysfs-bus-cxl index 0b6a2e6e8fbb..7c2b846521f3 100644 --- a/Documentation/ABI/testing/sysfs-bus-cxl +++ b/Documentation/ABI/testing/sysfs-bus-cxl @@ -1,3 +1,12 @@ +What: /sys/bus/cxl/flush +Date: Januarry, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (WO) If userspace manually unbinds a port the kernel schedules + all descendant memdevs for unbind. Writing '1' to this attribute + flushes that work. + What: /sys/bus/cxl/devices/memX/firmware_version Date: December, 2020 KernelVersion: v5.12 @@ -25,6 +34,24 @@ Description: identically named field in the Identify Memory Device Output Payload in the CXL-2.0 specification. +What: /sys/bus/cxl/devices/memX/serial +Date: January, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) 64-bit serial number per the PCIe Device Serial Number + capability. Mandatory for CXL devices, see CXL 2.0 8.1.12.2 + Memory Device PCIe Capabilities and Extended Capabilities. + +What: /sys/bus/cxl/devices/memX/numa_node +Date: January, 2022 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + (RO) If NUMA is enabled and the platform has affinitized the + host PCI device for this memory device, emit the CPU node + affinity for this device. + What: /sys/bus/cxl/devices/*/devtype Date: June, 2021 KernelVersion: v5.14 @@ -34,6 +61,15 @@ Description: the same value communicated in the DEVTYPE environment variable for uevents for devices on the "cxl" bus. +What: /sys/bus/cxl/devices/*/modalias +Date: December, 2021 +KernelVersion: v5.18 +Contact: linux-cxl@vger.kernel.org +Description: + CXL device objects export the modalias attribute which mirrors + the same value communicated in the MODALIAS environment variable + for uevents for devices on the "cxl" bus. + What: /sys/bus/cxl/devices/portX/uport Date: June, 2021 KernelVersion: v5.14 diff --git a/Documentation/ABI/testing/sysfs-bus-iio b/Documentation/ABI/testing/sysfs-bus-iio index c551301b33f1..d4ccc68fdcf0 100644 --- a/Documentation/ABI/testing/sysfs-bus-iio +++ b/Documentation/ABI/testing/sysfs-bus-iio @@ -476,6 +476,7 @@ What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_i_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltageY_q_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_i_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_q_calibscale +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_voltage_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_x_calibscale What: /sys/bus/iio/devices/iio:deviceX/in_accel_y_calibscale @@ -1213,6 +1214,32 @@ Description: number or direction is not specified, applies to all channels of this type. +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_en +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_en +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_rising_en +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_falling_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Similar to in_accel_mag[_y][_rising|_falling]_en, but the event + value is relative to a reference magnitude. The reference magnitude + includes the graviational acceleration. + +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_value +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_rising_value +What: /sys/.../iio:deviceX/events/in_accel_mag_referenced_falling_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_rising_value +What: /sys/.../iio:deviceX/events/in_accel_y_mag_referenced_falling_value +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + The value to which the reference magnitude of the channel is + compared. If the axis is not specified, it applies to all channels + of this type. + What: /sys/.../events/in_steps_change_en KernelVersion: 4.0 Contact: linux-iio@vger.kernel.org @@ -1252,6 +1279,10 @@ Description: Actually start the buffer capture up. Will start trigger if first device and appropriate. + Note that it might be impossible to configure other attributes, + (e.g.: events, scale, sampling rate) if they impact the currently + active buffer capture session. + What: /sys/bus/iio/devices/iio:deviceX/bufferY KernelVersion: 5.11 Contact: linux-iio@vger.kernel.org diff --git a/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a new file mode 100644 index 000000000000..83b7efe6aa07 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-adc-ad7280a @@ -0,0 +1,13 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_balance_switch_en +KernelVersion: 5.14 +Contact: linux-iio@vger.kernel.org +Description: + Used to enable an output for balancing cells for time + controlled via in_voltage_Y-voltageZ_balance_switch_timer. + +What: /sys/bus/iio/devices/iio:deviceX/in_voltageY-voltageZ_balance_switch_timer +KernelVersion: 5.14 +Contact: linux-iio@vger.kernel.org +Description: + Time in seconds for which balance switch will be turned on. + Multiple of 71.5 seconds. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 new file mode 100644 index 000000000000..1c35971277ba --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-dac-ltc2688 @@ -0,0 +1,86 @@ +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Dither enable. Write 1 to enable dither or 0 to disable it. This is useful + for changing the dither parameters. They way it should be done is: + + - disable dither operation; + - change dither parameters (eg: frequency, phase...); + - enabled dither operation + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_raw +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + This raw, unscaled value refers to the dither signal amplitude. + The same scale as in out_voltageY_raw applies. However, the + offset might be different as it's always 0 for this attribute. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_raw_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Available range for dither raw amplitude values. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_offset +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Offset applied to out_voltageY_dither_raw. Read only attribute + always set to 0. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_frequency +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Sets the dither signal frequency. Units are in Hz. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_frequency_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Returns the available values for the dither frequency. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_phase +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Sets the dither signal phase. Units are in Radians. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_dither_phase_available +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Returns the available values for the dither phase. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_toggle_en +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Toggle enable. Write 1 to enable toggle or 0 to disable it. This is + useful when one wants to change the DAC output codes. The way it should + be done is: + + - disable toggle operation; + - change out_voltageY_raw0 and out_voltageY_raw1; + - enable toggle operation. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw0 +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_raw1 +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + It has the same meaning as out_voltageY_raw. This attribute is + specific to toggle enabled channels and refers to the DAC output + code in INPUT_A (_raw0) and INPUT_B (_raw1). The same scale and offset + as in out_voltageY_raw applies. + +What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_symbol +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Performs a SW toggle. This attribute is specific to toggle + enabled channels and allows to toggle between out_voltageY_raw0 + and out_voltageY_raw1 through software. Writing 0 will select + out_voltageY_raw0 while 1 selects out_voltageY_raw1. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 new file mode 100644 index 000000000000..395010a0ef8b --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-frequency-admv1014 @@ -0,0 +1,23 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_coarse +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_I) with coarse steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_coarse +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_Q) with coarse steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_i_calibscale_fine +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_I) with fine steps. + +What: /sys/bus/iio/devices/iio:deviceX/in_altvoltage0_q_calibscale_fine +KernelVersion: 5.18 +Contact: linux-iio@vger.kernel.org +Description: + Read/write value for the digital attenuator gain (IF_Q) with fine steps. diff --git a/Documentation/ABI/testing/sysfs-bus-iio-sx9324 b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 new file mode 100644 index 000000000000..632e3321f5a3 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-iio-sx9324 @@ -0,0 +1,28 @@ +What: /sys/bus/iio/devices/iio:deviceX/in_proximity<id>_setup +Date: November 2021 +KernelVersion: 5.17 +Contact: Gwendal Grignou <gwendal@chromium.org> +Description: + SX9324 has 3 inputs, CS0, CS1 and CS2. Hardware layout + defines if the input is + + not connected (HZ), + + grounded (GD), + + connected to an antenna where it can act as a base + (DS - data shield), or measured input (MI). + + The sensor rotates measurement across 4 phases + (PH0, PH1, PH2, PH3), where the inputs are configured + and then measured. + + By default, during the first phase, [PH0], CS0 is measured, + while CS1 and CS2 are used as shields. + `cat in_proximity0_setup` returns "MI,DS,DS". + [PH1], CS1 is measured, CS0 and CS2 are shield: + `cat in_proximity1_setup` returns "DS,MI,DS". + [PH2], CS2 is measured, CS0 and CS1 are shield: + `cat in_proximity1_setup` returns "DS,DS,MI". + [PH3], CS1 and CS2 are measured (combo mode): + `cat in_proximity1_setup` returns "DS,MI,MI". + + Note, these are the chip default. Hardware layout will most + likely dictate different output. The entry is read-only. diff --git a/Documentation/ABI/testing/sysfs-bus-nvdimm b/Documentation/ABI/testing/sysfs-bus-nvdimm index bff84a16812a..1c1f5acbf53d 100644 --- a/Documentation/ABI/testing/sysfs-bus-nvdimm +++ b/Documentation/ABI/testing/sysfs-bus-nvdimm @@ -6,3 +6,38 @@ Description: The libnvdimm sub-system implements a common sysfs interface for platform nvdimm resources. See Documentation/driver-api/nvdimm/. + +What: /sys/bus/event_source/devices/nmemX/format +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain <kjain@linux.ibm.com> +Description: (RO) Attribute group to describe the magic bits + that go into perf_event_attr.config for a particular pmu. + (See ABI/testing/sysfs-bus-event_source-devices-format). + + Each attribute under this group defines a bit range of the + perf_event_attr.config. Supported attribute is listed + below:: + event = "config:0-4" - event ID + + For example:: + ctl_res_cnt = "event=0x1" + +What: /sys/bus/event_source/devices/nmemX/events +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain <kjain@linux.ibm.com> +Description: (RO) Attribute group to describe performance monitoring events + for the nvdimm memory device. Each attribute in this group + describes a single performance monitoring event supported by + this nvdimm pmu. The name of the file is the name of the event. + (See ABI/testing/sysfs-bus-event_source-devices-events). A + listing of the events supported by a given nvdimm provider type + can be found in Documentation/driver-api/nvdimm/$provider. + +What: /sys/bus/event_source/devices/nmemX/cpumask +Date: February 2022 +KernelVersion: 5.18 +Contact: Kajol Jain <kjain@linux.ibm.com> +Description: (RO) This sysfs file exposes the cpumask which is designated to + to retrieve nvdimm pmu event counter data. diff --git a/Documentation/ABI/testing/sysfs-bus-papr-pmem b/Documentation/ABI/testing/sysfs-bus-papr-pmem index 95254cec92bf..4ac0673901e7 100644 --- a/Documentation/ABI/testing/sysfs-bus-papr-pmem +++ b/Documentation/ABI/testing/sysfs-bus-papr-pmem @@ -61,3 +61,15 @@ Description: * "CchRHCnt" : Cache Read Hit Count * "CchWHCnt" : Cache Write Hit Count * "FastWCnt" : Fast Write Count + +What: /sys/bus/nd/devices/nmemX/papr/health_bitmap_inject +Date: Jan, 2022 +KernelVersion: v5.17 +Contact: linuxppc-dev <linuxppc-dev@lists.ozlabs.org>, nvdimm@lists.linux.dev, +Description: + (RO) Reports the health bitmap inject bitmap that is applied to + bitmap received from PowerVM via the H_SCM_HEALTH. This is used + to forcibly set specific bits returned from Hcall. These is then + used to simulate various health or shutdown states for an nvdimm + and are set by user-space tools like ndctl by issuing a PAPR DSM. + diff --git a/Documentation/ABI/testing/sysfs-bus-peci b/Documentation/ABI/testing/sysfs-bus-peci new file mode 100644 index 000000000000..87454ec5d981 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-bus-peci @@ -0,0 +1,16 @@ +What: /sys/bus/peci/rescan +Date: July 2021 +KernelVersion: 5.18 +Contact: Iwona Winiarska <iwona.winiarska@intel.com> +Description: + Writing a non-zero value to this attribute will + initiate scan for PECI devices on all PECI controllers + in the system. + +What: /sys/bus/peci/devices/<controller_id>-<device_addr>/remove +Date: July 2021 +KernelVersion: 5.18 +Contact: Iwona Winiarska <iwona.winiarska@intel.com> +Description: + Writing a non-zero value to this attribute will + remove the PECI device and any of its children. diff --git a/Documentation/ABI/testing/sysfs-class-firmware-attributes b/Documentation/ABI/testing/sysfs-class-firmware-attributes index 13e31c6a0e9c..05820365f1ec 100644 --- a/Documentation/ABI/testing/sysfs-class-firmware-attributes +++ b/Documentation/ABI/testing/sysfs-class-firmware-attributes @@ -246,6 +246,51 @@ Description: that is being referenced (e.g hdd0, hdd1 etc) This attribute defaults to device 0. + certificate: + signature: + save_signature: + These attributes are used for certificate based authentication. This is + used in conjunction with a signing server as an alternative to password + based authentication. + The user writes to the attribute(s) with a BASE64 encoded string obtained + from the signing server. + The attributes can be displayed to check the stored value. + + Some usage examples: + Installing a certificate to enable feature: + echo <supervisor password > authentication/Admin/current_password + echo <signed certificate> > authentication/Admin/certificate + + Updating the installed certificate: + echo <signature> > authentication/Admin/signature + echo <signed certificate> > authentication/Admin/certificate + + Removing the installed certificate: + echo <signature> > authentication/Admin/signature + echo '' > authentication/Admin/certificate + + Changing a BIOS setting: + echo <signature> > authentication/Admin/signature + echo <save signature> > authentication/Admin/save_signature + echo Enable > attribute/PasswordBeep/current_value + + You cannot enable certificate authentication if a supervisor password + has not been set. + Clearing the certificate results in no bios-admin authentication method + being configured allowing anyone to make changes. + After any of these operations the system must reboot for the changes to + take effect. + + certificate_thumbprint: + Read only attribute used to display the MD5, SHA1 and SHA256 thumbprints + for the certificate installed in the BIOS. + + certificate_to_password: + Write only attribute used to switch from certificate based authentication + back to password based. + Usage: + echo <signature> > authentication/Admin/signature + echo <password> > authentication/Admin/certificate_to_password What: /sys/class/firmware-attributes/*/attributes/pending_reboot diff --git a/Documentation/ABI/testing/sysfs-class-hwmon b/Documentation/ABI/testing/sysfs-class-hwmon index 1f20687def44..653d4c75eddb 100644 --- a/Documentation/ABI/testing/sysfs-class-hwmon +++ b/Documentation/ABI/testing/sysfs-class-hwmon @@ -9,6 +9,14 @@ Description: RO +What: /sys/class/hwmon/hwmonX/label +Description: + A descriptive label that allows to uniquely identify a + device within the system. + The contents of the label are free-form. + + RO + What: /sys/class/hwmon/hwmonX/update_interval Description: The interval at which the chip will update readings. diff --git a/Documentation/ABI/testing/sysfs-class-power b/Documentation/ABI/testing/sysfs-class-power index fde21d900420..a9ce63cfbe87 100644 --- a/Documentation/ABI/testing/sysfs-class-power +++ b/Documentation/ABI/testing/sysfs-class-power @@ -380,13 +380,17 @@ Description: algorithm to adjust the charge rate dynamically, without any user configuration required. "Custom" means that the charger uses the charge_control_* properties as configuration for some - different algorithm. + different algorithm. "Long Life" means the charger reduces its + charging rate in order to prolong the battery health. "Bypass" + means the charger bypasses the charging path around the + integrated converter allowing for a "smart" wall adaptor to + perform the power conversion externally. Access: Read, Write Valid values: "Unknown", "N/A", "Trickle", "Fast", "Standard", - "Adaptive", "Custom" + "Adaptive", "Custom", "Long Life", "Bypass" What: /sys/class/power_supply/<supply_name>/charge_term_current Date: July 2014 @@ -468,6 +472,7 @@ Description: auto: Charge normally, respect thresholds inhibit-charge: Do not charge while AC is attached force-discharge: Force discharge while AC is attached + ================ ==================================== What: /sys/class/power_supply/<supply_name>/technology Date: May 2007 diff --git a/Documentation/ABI/testing/sysfs-class-thermal b/Documentation/ABI/testing/sysfs-class-thermal index 2c52bb1f864c..8eee37982b2a 100644 --- a/Documentation/ABI/testing/sysfs-class-thermal +++ b/Documentation/ABI/testing/sysfs-class-thermal @@ -203,7 +203,7 @@ Description: - for generic ACPI: should be "Fan", "Processor" or "LCD" - for memory controller device on intel_menlow platform: - should be "Memory controller". + should be "Memory controller". RO, Required diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu index 61f5676a7429..2ad01cad7f1c 100644 --- a/Documentation/ABI/testing/sysfs-devices-system-cpu +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu @@ -73,6 +73,7 @@ What: /sys/devices/system/cpu/cpuX/topology/core_id /sys/devices/system/cpu/cpuX/topology/physical_package_id /sys/devices/system/cpu/cpuX/topology/thread_siblings /sys/devices/system/cpu/cpuX/topology/thread_siblings_list + /sys/devices/system/cpu/cpuX/topology/ppin Date: December 2008 Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org> Description: CPU topology files that describe a logical CPU's relationship @@ -103,6 +104,11 @@ Description: CPU topology files that describe a logical CPU's relationship thread_siblings_list: human-readable list of cpuX's hardware threads within the same core as cpuX + ppin: human-readable Protected Processor Identification + Number of the socket the cpu# belongs to. There should be + one per physical_package_id. File is readable only to + admin. + See Documentation/admin-guide/cputopology.rst for more information. @@ -662,6 +668,7 @@ Description: Preferred MTE tag checking mode ================ ============================================== "sync" Prefer synchronous mode + "asymm" Prefer asymmetric mode "async" Prefer asynchronous mode ================ ============================================== diff --git a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing index b363827da437..910df0e5815a 100644 --- a/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing +++ b/Documentation/ABI/testing/sysfs-driver-aspeed-uart-routing @@ -1,4 +1,4 @@ -What: /sys/bus/platform/drivers/aspeed-uart-routing/*/uart* +What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/uart\* Date: September 2021 Contact: Oskar Senft <osk@google.com> Chia-Wei Wang <chiawei_wang@aspeedtech.com> @@ -9,7 +9,7 @@ Description: Selects the RX source of the UARTx device. depends on the selected file. e.g. - cat /sys/bus/platform/drivers/aspeed-uart-routing/*.uart_routing/uart1 + cat /sys/bus/platform/drivers/aspeed-uart-routing/\*.uart_routing/uart1 [io1] io2 io3 io4 uart2 uart3 uart4 io6 In this case, UART1 gets its input from IO1 (physical serial port 1). @@ -17,7 +17,7 @@ Description: Selects the RX source of the UARTx device. Users: OpenBMC. Proposed changes should be mailed to openbmc@lists.ozlabs.org -What: /sys/bus/platform/drivers/aspeed-uart-routing/*/io* +What: /sys/bus/platform/drivers/aspeed-uart-routing/\*/io\* Date: September 2021 Contact: Oskar Senft <osk@google.com> Chia-Wei Wang <chiawei_wang@aspeedtech.com> diff --git a/Documentation/ABI/testing/sysfs-driver-eud b/Documentation/ABI/testing/sysfs-driver-eud new file mode 100644 index 000000000000..83f3872182a4 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-eud @@ -0,0 +1,9 @@ +What: /sys/bus/platform/drivers/eud/.../enable +Date: February 2022 +Contact: Souradeep Chowdhury <quic_schowdhu@quicinc.com> +Description: + The Enable/Disable sysfs interface for Embedded + USB Debugger(EUD). This enables and disables the + EUD based on a 1 or a 0 value. By enabling EUD, + the user is able to activate the mini-usb hub of + EUD for debug and trace capabilities. diff --git a/Documentation/ABI/testing/sysfs-driver-habanalabs b/Documentation/ABI/testing/sysfs-driver-habanalabs index 1f127f71d2b4..96646fb2e7a1 100644 --- a/Documentation/ABI/testing/sysfs-driver-habanalabs +++ b/Documentation/ABI/testing/sysfs-driver-habanalabs @@ -69,6 +69,12 @@ KernelVersion: 5.1 Contact: ogabbay@kernel.org Description: Displays the device's version from the eFuse +What: /sys/class/habanalabs/hl<n>/fw_os_ver +Date: Dec 2021 +KernelVersion: 5.18 +Contact: ogabbay@kernel.org +Description: Version of the firmware OS running on the device's CPU + What: /sys/class/habanalabs/hl<n>/hard_reset Date: Jan 2019 KernelVersion: 5.1 @@ -115,7 +121,7 @@ What: /sys/class/habanalabs/hl<n>/infineon_ver Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Version of the Device's power supply F/W code +Description: Version of the Device's power supply F/W code. Relevant only to GOYA and GAUDI What: /sys/class/habanalabs/hl<n>/max_power Date: Jan 2019 @@ -220,4 +226,10 @@ What: /sys/class/habanalabs/hl<n>/uboot_ver Date: Jan 2019 KernelVersion: 5.1 Contact: ogabbay@kernel.org -Description: Version of the u-boot running on the device's CPU
\ No newline at end of file +Description: Version of the u-boot running on the device's CPU + +What: /sys/class/habanalabs/hl<n>/vrm_ver +Date: Jan 2022 +KernelVersion: not yet upstreamed +Contact: ogabbay@kernel.org +Description: Version of the Device's Voltage Regulator Monitor F/W code. N/A to GOYA and GAUDI diff --git a/Documentation/ABI/testing/sysfs-driver-intel_sdsi b/Documentation/ABI/testing/sysfs-driver-intel_sdsi new file mode 100644 index 000000000000..ab122125ff9a --- /dev/null +++ b/Documentation/ABI/testing/sysfs-driver-intel_sdsi @@ -0,0 +1,77 @@ +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + This directory contains interface files for accessing Intel + Software Defined Silicon (SDSi) features on a CPU. X + represents the socket instance (though not the socket ID). + The socket ID is determined by reading the registers file + and decoding it per the specification. + + Some files communicate with SDSi hardware through a mailbox. + Should the operation fail, one of the following error codes + may be returned: + + Error Code Cause + ---------- ----- + EIO General mailbox failure. Log may indicate cause. + EBUSY Mailbox is owned by another agent. + EPERM SDSI capability is not enabled in hardware. + EPROTO Failure in mailbox protocol detected by driver. + See log for details. + EOVERFLOW For provision commands, the size of the data + exceeds what may be written. + ESPIPE Seeking is not allowed. + ETIMEDOUT Failure to complete mailbox transaction in time. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/guid +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (RO) The GUID for the registers file. The GUID identifies + the layout of the registers file in this directory. + Information about the register layouts for a particular GUID + is available at http://github.com/intel/intel-sdsi + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/registers +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (RO) Contains information needed by applications to provision + a CPU and monitor status information. The layout of this file + is determined by the GUID in this directory. Information about + the layout for a particular GUID is available at + http://github.com/intel/intel-sdsi + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_akc +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (WO) Used to write an Authentication Key Certificate (AKC) to + the SDSi NVRAM for the CPU. The AKC is used to authenticate a + Capability Activation Payload. Mailbox command. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/provision_cap +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (WO) Used to write a Capability Activation Payload (CAP) to the + SDSi NVRAM for the CPU. CAPs are used to activate a given CPU + feature. A CAP is validated by SDSi hardware using a previously + provisioned AKC file. Upon successful authentication, the CPU + configuration is updated. A cold reboot is required to fully + activate the feature. Mailbox command. + +What: /sys/bus/auxiliary/devices/intel_vsec.sdsi.X/state_certificate +Date: Feb 2022 +KernelVersion: 5.18 +Contact: "David E. Box" <david.e.box@linux.intel.com> +Description: + (RO) Used to read back the current State Certificate for the CPU + from SDSi hardware. The State Certificate contains information + about the current licenses on the CPU. Mailbox command. diff --git a/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info new file mode 100644 index 000000000000..141a6b371469 --- /dev/null +++ b/Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info @@ -0,0 +1,29 @@ +What: /sys/firmware/papr/energy_scale_info +Date: February 2022 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: Directory hosting a set of platform attributes like + energy/frequency on Linux running as a PAPR guest. + + Each file in a directory contains a platform + attribute hierarchy pertaining to performance/ + energy-savings mode and processor frequency. + +What: /sys/firmware/papr/energy_scale_info/<id> +Date: February 2022 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: Energy, frequency attributes directory for POWERVM servers + +What: /sys/firmware/papr/energy_scale_info/<id>/desc +Date: February 2022 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: String description of the energy attribute of <id> + +What: /sys/firmware/papr/energy_scale_info/<id>/value +Date: February 2022 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: Numeric value of the energy attribute of <id> + +What: /sys/firmware/papr/energy_scale_info/<id>/value_desc +Date: February 2022 +Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org> +Description: String value of the energy attribute of <id> diff --git a/Documentation/ABI/testing/sysfs-fs-f2fs b/Documentation/ABI/testing/sysfs-fs-f2fs index 2416b03ff283..9b583dd0298b 100644 --- a/Documentation/ABI/testing/sysfs-fs-f2fs +++ b/Documentation/ABI/testing/sysfs-fs-f2fs @@ -55,8 +55,9 @@ Description: Controls the in-place-update policy. 0x04 F2FS_IPU_UTIL 0x08 F2FS_IPU_SSR_UTIL 0x10 F2FS_IPU_FSYNC - 0x20 F2FS_IPU_ASYNC, + 0x20 F2FS_IPU_ASYNC 0x40 F2FS_IPU_NOCACHE + 0x80 F2FS_IPU_HONOR_OPU_WRITE ==== ================= Refer segment.h for details. @@ -98,6 +99,33 @@ Description: Controls the issue rate of discard commands that consist of small checkpoint is triggered, and issued during the checkpoint. By default, it is disabled with 0. +What: /sys/fs/f2fs/<disk>/max_discard_request +Date: December 2021 +Contact: "Konstantin Vyshetsky" <vkon@google.com> +Description: Controls the number of discards a thread will issue at a time. + Higher number will allow the discard thread to finish its work + faster, at the cost of higher latency for incomming I/O. + +What: /sys/fs/f2fs/<disk>/min_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" <vkon@google.com> +Description: Controls the interval the discard thread will wait between + issuing discard requests when there are discards to be issued and + no I/O aware interruptions occur. + +What: /sys/fs/f2fs/<disk>/mid_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" <vkon@google.com> +Description: Controls the interval the discard thread will wait between + issuing discard requests when there are discards to be issued and + an I/O aware interruption occurs. + +What: /sys/fs/f2fs/<disk>/max_discard_issue_time +Date: December 2021 +Contact: "Konstantin Vyshetsky" <vkon@google.com> +Description: Controls the interval the discard thread will wait when there are + no discard operations to be issued. + What: /sys/fs/f2fs/<disk>/discard_granularity Date: July 2017 Contact: "Chao Yu" <yuchao0@huawei.com> @@ -269,11 +297,16 @@ Description: Shows current reserved blocks in system, it may be temporarily What: /sys/fs/f2fs/<disk>/gc_urgent Date: August 2017 Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> -Description: Do background GC aggressively when set. When gc_urgent = 1, - background thread starts to do GC by given gc_urgent_sleep_time - interval. When gc_urgent = 2, F2FS will lower the bar of - checking idle in order to process outstanding discard commands - and GC a little bit aggressively. It is set to 0 by default. +Description: Do background GC aggressively when set. Set to 0 by default. + gc urgent high(1): does GC forcibly in a period of given + gc_urgent_sleep_time and ignores I/O idling check. uses greedy + GC approach and turns SSR mode on. + gc urgent low(2): lowers the bar of checking I/O idling in + order to process outstanding discard commands and GC a + little bit aggressively. uses cost benefit GC approach. + gc urgent mid(3): does GC forcibly in a period of given + gc_urgent_sleep_time and executes a mid level of I/O idling check. + uses cost benefit GC approach. What: /sys/fs/f2fs/<disk>/gc_urgent_sleep_time Date: August 2017 @@ -430,6 +463,7 @@ Description: Show status of f2fs superblock in real time. 0x800 SBI_QUOTA_SKIP_FLUSH skip flushing quota in current CP 0x1000 SBI_QUOTA_NEED_REPAIR quota file may be corrupted 0x2000 SBI_IS_RESIZEFS resizefs is in process + 0x4000 SBI_IS_FREEZING freefs is in process ====== ===================== ================================= What: /sys/fs/f2fs/<disk>/ckpt_thread_ioprio @@ -503,7 +537,7 @@ Date: July 2021 Contact: "Daeho Jeong" <daehojeong@google.com> Description: Show how many segments have been reclaimed by GC during a specific GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy, - 3: GC idle AT, 4: GC urgent high, 5: GC urgent low) + 3: GC idle AT, 4: GC urgent high, 5: GC urgent low 6: GC urgent mid) You can re-initialize this value to "0". What: /sys/fs/f2fs/<disk>/gc_segment_mode @@ -540,3 +574,9 @@ Contact: "Daeho Jeong" <daehojeong@google.com> Description: You can set the trial count limit for GC urgent high mode with this value. If GC thread gets to the limit, the mode will turn back to GC normal mode. By default, the value is zero, which means there is no limit like before. + +What: /sys/fs/f2fs/<disk>/max_roll_forward_node_blocks +Date: January 2022 +Contact: "Jaegeuk Kim" <jaegeuk@kernel.org> +Description: Controls max # of node block writes to be used for roll forward + recovery. This can limit the roll forward recovery time. diff --git a/Documentation/ABI/testing/sysfs-kernel-mm-damon b/Documentation/ABI/testing/sysfs-kernel-mm-damon new file mode 100644 index 000000000000..9e282065cbcf --- /dev/null +++ b/Documentation/ABI/testing/sysfs-kernel-mm-damon @@ -0,0 +1,274 @@ +what: /sys/kernel/mm/damon/ +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Interface for Data Access MONitoring (DAMON). Contains files + for controlling DAMON. For more details on DAMON itself, + please refer to Documentation/admin-guide/mm/damon/index.rst. + +What: /sys/kernel/mm/damon/admin/ +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Interface for privileged users of DAMON. Contains files for + controlling DAMON that aimed to be used by privileged users. + +What: /sys/kernel/mm/damon/admin/kdamonds/nr_kdamonds +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON worker thread (kdamond) + named '0' to 'N-1' under the kdamonds/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/state +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing 'on' or 'off' to this file makes the kdamond starts or + stops, respectively. Reading the file returns the keywords + based on the current status. Writing 'update_schemes_stats' to + the file updates contents of schemes stats files of the + kdamond. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/pid +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the pid of the kdamond if it is + running. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/nr_contexts +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON context named '0' to + 'N-1' under the contexts/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/operations +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a keyword for a monitoring operations set ('vaddr' for + virtual address spaces monitoring, and 'paddr' for the physical + address space monitoring) to this file makes the context to use + the operations set. Reading the file returns the keyword for + the operations set the context is set to use. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/sample_us +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a value to this file sets the sampling interval of the + DAMON context in microseconds as the value. Reading this file + returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/aggr_us +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a value to this file sets the aggregation interval of + the DAMON context in microseconds as the value. Reading this + file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/intervals/update_us +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a value to this file sets the update interval of the + DAMON context in microseconds as the value. Reading this file + returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/nr_regions/min + +WDate: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a value to this file sets the minimum number of + monitoring regions of the DAMON context as the value. Reading + this file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/monitoring_attrs/nr_regions/max +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a value to this file sets the maximum number of + monitoring regions of the DAMON context as the value. Reading + this file returns the value. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/nr_targets +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON target of the context + named '0' to 'N-1' under the contexts/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/pid_target +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the pid of + the target process if the context is for virtual address spaces + monitoring, respectively. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/nr_regions +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a number 'N' to this file creates the number of + directories for setting each DAMON target memory region of the + context named '0' to 'N-1' under the regions/ directory. In + case of the virtual address space monitoring, DAMON + automatically sets the target memory region based on the target + processes' mappings. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/<R>/start +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the start + address of the monitoring region. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/targets/<T>/regions/<R>/end +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the end + address of the monitoring region. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/nr_schemes +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing a number 'N' to this file creates the number of + directories for controlling each DAMON-based operation scheme + of the context named '0' to 'N-1' under the schemes/ directory. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/action +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the action + of the scheme. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the mimimum + size of the scheme's target regions in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/max +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the maximum + size of the scheme's target regions in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/nr_accesses/min +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the manimum + 'nr_accesses' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/nr_accesses/max +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the maximum + 'nr_accesses' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/age/min +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the minimum + 'age' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/age/max +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the maximum + 'age' of the scheme's target regions. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/ms +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the time + quota of the scheme in milliseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/bytes +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the size + quota of the scheme in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/reset_interval_ms +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the quotas + charge reset interval of the scheme in milliseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/sz_permil +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for 'size' in + permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/nr_accesses_permil +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for + 'nr_accesses' in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/quotas/weights/age_permil +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the + under-quota limit regions prioritization weight for 'age' in + permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/metric +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the metric + of the watermarks for the scheme. The writable/readable + keywords for this file are 'none' for disabling the watermarks + feature, or 'free_mem_rate' for the system's global free memory + rate in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/interval_us +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the metric + check interval of the watermarks for the scheme in + microseconds. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/high +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the high + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/mid +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the mid + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/watermarks/low +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Writing to and reading from this file sets and gets the low + watermark of the scheme in permil. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_tried +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the number of regions that the action + of the scheme has tried to be applied. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_tried +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the total size of regions that the + action of the scheme has tried to be applied in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/nr_applied +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the number of regions that the action + of the scheme has successfully applied. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/sz_applied +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the total size of regions that the + action of the scheme has successfully applied in bytes. + +What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/stats/qt_exceeds +Date: Mar 2022 +Contact: SeongJae Park <sj@kernel.org> +Description: Reading this file returns the number of the exceed events of + the scheme's quotas. diff --git a/Documentation/ABI/testing/sysfs-mce b/Documentation/ABI/testing/sysfs-mce index c8cd989034b4..83172f50e27c 100644 --- a/Documentation/ABI/testing/sysfs-mce +++ b/Documentation/ABI/testing/sysfs-mce @@ -53,38 +53,6 @@ Description: (but some corrected errors might be still reported in other ways) -What: /sys/devices/system/machinecheck/machinecheckX/tolerant -Contact: Andi Kleen <ak@linux.intel.com> -Date: Feb, 2007 -Description: - The entries appear for each CPU, but they are truly shared - between all CPUs. - - Tolerance level. When a machine check exception occurs for a - non corrected machine check the kernel can take different - actions. - - Since machine check exceptions can happen any time it is - sometimes risky for the kernel to kill a process because it - defies normal kernel locking rules. The tolerance level - configures how hard the kernel tries to recover even at some - risk of deadlock. Higher tolerant values trade potentially - better uptime with the risk of a crash or even corruption - (for tolerant >= 3). - - == =========================================================== - 0 always panic on uncorrected errors, log corrected errors - 1 panic or SIGBUS on uncorrected errors, log corrected errors - 2 SIGBUS or log uncorrected errors, log corrected errors - 3 never panic or SIGBUS, log all errors (for testing only) - == =========================================================== - - Default: 1 - - Note this only makes a difference if the CPU allows recovery - from a machine check exception. Current x86 CPUs generally - do not. - What: /sys/devices/system/machinecheck/machinecheckX/trigger Contact: Andi Kleen <ak@linux.intel.com> Date: Feb, 2007 diff --git a/Documentation/ABI/testing/sysfs-platform-lg-laptop b/Documentation/ABI/testing/sysfs-platform-lg-laptop index cf47749b19df..0570cd524d0e 100644 --- a/Documentation/ABI/testing/sysfs-platform-lg-laptop +++ b/Documentation/ABI/testing/sysfs-platform-lg-laptop @@ -17,6 +17,7 @@ Date: October 2018 KernelVersion: 4.20 Contact: "Matan Ziv-Av <matan@svgalib.org> Description: + Deprecated use /sys/class/power_supply/CMB0/charge_control_end_threshold Maximal battery charge level. Accepted values are 80 or 100. What: /sys/devices/platform/lg-laptop/fan_mode diff --git a/Documentation/ABI/testing/sysfs-timecard b/Documentation/ABI/testing/sysfs-timecard index 97f6773794a5..220478156297 100644 --- a/Documentation/ABI/testing/sysfs-timecard +++ b/Documentation/ABI/testing/sysfs-timecard @@ -37,8 +37,15 @@ Description: (RO) Set of available destinations (sinks) for a SMA PPS2 signal is sent to the PPS2 selector TS1 signal is sent to timestamper 1 TS2 signal is sent to timestamper 2 + TS3 signal is sent to timestamper 3 + TS4 signal is sent to timestamper 4 IRIG signal is sent to the IRIG-B module DCF signal is sent to the DCF module + FREQ1 signal is sent to frequency counter 1 + FREQ2 signal is sent to frequency counter 2 + FREQ3 signal is sent to frequency counter 3 + FREQ4 signal is sent to frequency counter 4 + None signal input is disabled ===== ================================================ What: /sys/class/timecard/ocpN/available_sma_outputs @@ -50,10 +57,16 @@ Description: (RO) Set of available sources for a SMA output signal. 10Mhz output is from the 10Mhz reference clock PHC output PPS is from the PHC clock MAC output PPS is from the Miniature Atomic Clock - GNSS output PPS is from the GNSS module + GNSS1 output PPS is from the first GNSS module GNSS2 output PPS is from the second GNSS module IRIG output is from the PHC, in IRIG-B format DCF output is from the PHC, in DCF format + GEN1 output is from frequency generator 1 + GEN2 output is from frequency generator 2 + GEN3 output is from frequency generator 3 + GEN4 output is from frequency generator 4 + GND output is GND + VCC output is VCC ===== ================================================ What: /sys/class/timecard/ocpN/clock_source @@ -63,6 +76,97 @@ Description: (RW) Contains the current synchronization source used by the PHC. May be changed by writing one of the listed values from the available_clock_sources attribute set. +What: /sys/class/timecard/ocpN/clock_status_drift +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Contains the current drift value used by the firmware + for internal disciplining of the atomic clock. + +What: /sys/class/timecard/ocpN/clock_status_offset +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Contains the current offset value used by the firmware + for internal disciplining of the atomic clock. + +What: /sys/class/timecard/ocpN/freqX +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Optional directory containing the sysfs nodes for + frequency counter <X>. + +What: /sys/class/timecard/ocpN/freqX/frequency +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Contains the measured frequency over the specified + measurement period. + +What: /sys/class/timecard/ocpN/freqX/seconds +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) Specifies the number of seconds from 0-255 that the + frequency should be measured over. Write 0 to disable. + +What: /sys/class/timecard/ocpN/genX +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Optional directory containing the sysfs nodes for + frequency generator <X>. + +What: /sys/class/timecard/ocpN/genX/duty +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Specifies the signal duty cycle as a percentage from 1-99. + +What: /sys/class/timecard/ocpN/genX/period +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Specifies the signal period in nanoseconds. + +What: /sys/class/timecard/ocpN/genX/phase +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Specifies the signal phase offset in nanoseconds. + +What: /sys/class/timecard/ocpN/genX/polarity +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Specifies the signal polarity, either 1 or 0. + +What: /sys/class/timecard/ocpN/genX/running +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Either 0 or 1, showing if the signal generator is running. + +What: /sys/class/timecard/ocpN/genX/start +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RO) Shows the time in <sec>.<nsec> that the signal generator + started running. + +What: /sys/class/timecard/ocpN/genX/signal +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) Used to start the signal generator, and summarize + the current status. + + The signal generator may be started by writing the signal + period, followed by the optional signal values. If the + optional values are not provided, they default to the current + settings, which may be obtained from the other sysfs nodes. + + period [duty [phase [polarity]]] + + echo 500000000 > signal # 1/2 second period + echo 1000000 40 100 > signal + echo 0 > signal # turn off generator + + Period and phase are specified in nanoseconds. Duty cycle is + a percentage from 1-99. Polarity is 1 or 0. + + Reading this node will return: + + period duty phase polarity start_time + What: /sys/class/timecard/ocpN/gnss_sync Date: September 2021 Contact: Jonathan Lemon <jonathan.lemon@gmail.com> @@ -126,6 +230,16 @@ Description: (RW) These attributes specify the direction of the signal The 10Mhz reference clock input is currently only valid on SMA1 and may not be combined with other destination sinks. +What: /sys/class/timecard/ocpN/tod_correction +Date: March 2022 +Contact: Jonathan Lemon <jonathan.lemon@gmail.com> +Description: (RW) The incoming GNSS signal is in UTC time, and the NMEA + format messages do not provide a TAI offset. This sets the + correction value for the incoming time. + + If UBX_LS is enabled, this should be 0, and the offset is + taken from the UBX-NAV-TIMELS message. + What: /sys/class/timecard/ocpN/ts_window_adjust Date: September 2021 Contact: Jonathan Lemon <jonathan.lemon@gmail.com> diff --git a/Documentation/Makefile b/Documentation/Makefile index 9f4bd42cef18..64d44c1ecad3 100644 --- a/Documentation/Makefile +++ b/Documentation/Makefile @@ -26,7 +26,7 @@ SPHINX_CONF = conf.py PAPER = BUILDDIR = $(obj)/output PDFLATEX = xelatex -LATEXOPTS = -interaction=batchmode +LATEXOPTS = -interaction=batchmode -no-shell-escape ifeq ($(KBUILD_VERBOSE),0) SPHINXOPTS += "-q" diff --git a/Documentation/accounting/psi.rst b/Documentation/accounting/psi.rst index f2b3439edcc2..860fe651d645 100644 --- a/Documentation/accounting/psi.rst +++ b/Documentation/accounting/psi.rst @@ -92,7 +92,8 @@ Triggers can be set on more than one psi metric and more than one trigger for the same psi metric can be specified. However for each trigger a separate file descriptor is required to be able to poll it separately from others, therefore for each trigger a separate open() syscall should be made even -when opening the same psi interface file. +when opening the same psi interface file. Write operations to a file descriptor +with an already existing psi trigger will fail with EBUSY. Monitors activate only when system enters stall state for the monitored psi metric and deactivates upon exit from the stall state. While system is diff --git a/Documentation/admin-guide/acpi/fan_performance_states.rst b/Documentation/admin-guide/acpi/fan_performance_states.rst index 98fe5c333121..b9e4b4d146c1 100644 --- a/Documentation/admin-guide/acpi/fan_performance_states.rst +++ b/Documentation/admin-guide/acpi/fan_performance_states.rst @@ -60,3 +60,31 @@ For example:: When a given field is not populated or its value provided by the platform firmware is invalid, the "not-defined" string is shown instead of the value. + +ACPI Fan Fine Grain Control +============================= + +When _FIF object specifies support for fine grain control, then fan speed +can be set from 0 to 100% with the recommended minimum "step size" via +_FSL object. User can adjust fan speed using thermal sysfs cooling device. + +Here use can look at fan performance states for a reference speed (speed_rpm) +and set it by changing cooling device cur_state. If the fine grain control +is supported then user can also adjust to some other speeds which are +not defined in the performance states. + +The support of fine grain control is presented via sysfs attribute +"fine_grain_control". If fine grain control is present, this attribute +will show "1" otherwise "0". + +This sysfs attribute is presented in the same directory as performance states. + +ACPI Fan Performance Feedback +============================= + +The optional _FST object provides status information for the fan device. +This includes field to provide current fan speed in revolutions per minute +at which the fan is rotating. + +This speed is presented in the sysfs using the attribute "fan_speed_rpm", +in the same directory as performance states. diff --git a/Documentation/admin-guide/blockdev/zram.rst b/Documentation/admin-guide/blockdev/zram.rst index 3e11926a4df9..54fe63745ed8 100644 --- a/Documentation/admin-guide/blockdev/zram.rst +++ b/Documentation/admin-guide/blockdev/zram.rst @@ -315,8 +315,8 @@ To use the feature, admin should set up backing device via:: echo /dev/sda5 > /sys/block/zramX/backing_dev -before disksize setting. It supports only partition at this moment. -If admin wants to use incompressible page writeback, they could do via:: +before disksize setting. It supports only partitions at this moment. +If admin wants to use incompressible page writeback, they could do it via:: echo huge > /sys/block/zramX/writeback @@ -341,9 +341,9 @@ Admin can request writeback of those idle pages at right timing via:: echo idle > /sys/block/zramX/writeback -With the command, zram writeback idle pages from memory to the storage. +With the command, zram will writeback idle pages from memory to the storage. -If admin want to write a specific page in zram device to backing device, +If an admin wants to write a specific page in zram device to the backing device, they could write a page index into the interface. echo "page_index=1251" > /sys/block/zramX/writeback @@ -354,7 +354,7 @@ to guarantee storage health for entire product life. To overcome the concern, zram supports "writeback_limit" feature. The "writeback_limit_enable"'s default value is 0 so that it doesn't limit -any writeback. IOW, if admin wants to apply writeback budget, he should +any writeback. IOW, if admin wants to apply writeback budget, they should enable writeback_limit_enable via:: $ echo 1 > /sys/block/zramX/writeback_limit_enable @@ -365,7 +365,7 @@ until admin sets the budget via /sys/block/zramX/writeback_limit. (If admin doesn't enable writeback_limit_enable, writeback_limit's value assigned via /sys/block/zramX/writeback_limit is meaningless.) -If admin want to limit writeback as per-day 400M, he could do it +If admin wants to limit writeback as per-day 400M, they could do it like below:: $ MB_SHIFT=20 @@ -375,16 +375,16 @@ like below:: $ echo 1 > /sys/block/zram0/writeback_limit_enable If admins want to allow further write again once the budget is exhausted, -he could do it like below:: +they could do it like below:: $ echo $((400<<MB_SHIFT>>4K_SHIFT)) > \ /sys/block/zram0/writeback_limit -If admin wants to see remaining writeback budget since last set:: +If an admin wants to see the remaining writeback budget since last set:: $ cat /sys/block/zramX/writeback_limit -If admin want to disable writeback limit, he could do:: +If an admin wants to disable writeback limit, they could do:: $ echo 0 > /sys/block/zramX/writeback_limit_enable @@ -393,7 +393,7 @@ system reboot, echo 1 > /sys/block/zramX/reset) so keeping how many of writeback happened until you reset the zram to allocate extra writeback budget in next setting is user's job. -If admin wants to measure writeback count in a certain period, he could +If admin wants to measure writeback count in a certain period, they could know it via /sys/block/zram0/bd_stat's 3rd column. memory tracking diff --git a/Documentation/admin-guide/cgroup-v1/memory.rst b/Documentation/admin-guide/cgroup-v1/memory.rst index faac50149a22..2cc502a75ef6 100644 --- a/Documentation/admin-guide/cgroup-v1/memory.rst +++ b/Documentation/admin-guide/cgroup-v1/memory.rst @@ -64,6 +64,7 @@ Brief summary of control files. threads cgroup.procs show list of processes cgroup.event_control an interface for event_fd() + This knob is not available on CONFIG_PREEMPT_RT systems. memory.usage_in_bytes show current usage for memory (See 5.5 for details) memory.memsw.usage_in_bytes show current usage for memory+Swap @@ -75,6 +76,7 @@ Brief summary of control files. memory.max_usage_in_bytes show max memory usage recorded memory.memsw.max_usage_in_bytes show max memory+Swap usage recorded memory.soft_limit_in_bytes set/show soft limit of memory usage + This knob is not available on CONFIG_PREEMPT_RT systems. memory.stat show various statistics memory.use_hierarchy set/show hierarchical account enabled This knob is deprecated and shouldn't be diff --git a/Documentation/admin-guide/cgroup-v2.rst b/Documentation/admin-guide/cgroup-v2.rst index 5aa368d165da..69d7a6983f78 100644 --- a/Documentation/admin-guide/cgroup-v2.rst +++ b/Documentation/admin-guide/cgroup-v2.rst @@ -1301,6 +1301,11 @@ PAGE_SIZE multiple when read back. Amount of memory used to cache filesystem data, including tmpfs and shared memory. + kernel (npn) + Amount of total kernel memory, including + (kernel_stack, pagetables, percpu, vmalloc, slab) in + addition to other kernel memory use cases. + kernel_stack Amount of memory allocated to kernel stacks. diff --git a/Documentation/admin-guide/gpio/index.rst b/Documentation/admin-guide/gpio/index.rst index 7db367572f30..f6861ca16ffe 100644 --- a/Documentation/admin-guide/gpio/index.rst +++ b/Documentation/admin-guide/gpio/index.rst @@ -10,6 +10,7 @@ gpio gpio-aggregator sysfs gpio-mockup + gpio-sim .. only:: subproject and html diff --git a/Documentation/admin-guide/hw-vuln/spectre.rst b/Documentation/admin-guide/hw-vuln/spectre.rst index a2b22d5640ec..9e9556826450 100644 --- a/Documentation/admin-guide/hw-vuln/spectre.rst +++ b/Documentation/admin-guide/hw-vuln/spectre.rst @@ -60,8 +60,8 @@ privileged data touched during the speculative execution. Spectre variant 1 attacks take advantage of speculative execution of conditional branches, while Spectre variant 2 attacks use speculative execution of indirect branches to leak privileged memory. -See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[7] <spec_ref7>` -:ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`. +See :ref:`[1] <spec_ref1>` :ref:`[5] <spec_ref5>` :ref:`[6] <spec_ref6>` +:ref:`[7] <spec_ref7>` :ref:`[10] <spec_ref10>` :ref:`[11] <spec_ref11>`. Spectre variant 1 (Bounds Check Bypass) --------------------------------------- @@ -131,6 +131,19 @@ steer its indirect branch speculations to gadget code, and measure the speculative execution's side effects left in level 1 cache to infer the victim's data. +Yet another variant 2 attack vector is for the attacker to poison the +Branch History Buffer (BHB) to speculatively steer an indirect branch +to a specific Branch Target Buffer (BTB) entry, even if the entry isn't +associated with the source address of the indirect branch. Specifically, +the BHB might be shared across privilege levels even in the presence of +Enhanced IBRS. + +Currently the only known real-world BHB attack vector is via +unprivileged eBPF. Therefore, it's highly recommended to not enable +unprivileged eBPF, especially when eIBRS is used (without retpolines). +For a full mitigation against BHB attacks, it's recommended to use +retpolines (or eIBRS combined with retpolines). + Attack scenarios ---------------- @@ -364,13 +377,15 @@ The possible values in this file are: - Kernel status: - ==================================== ================================= - 'Not affected' The processor is not vulnerable - 'Vulnerable' Vulnerable, no mitigation - 'Mitigation: Full generic retpoline' Software-focused mitigation - 'Mitigation: Full AMD retpoline' AMD-specific software mitigation - 'Mitigation: Enhanced IBRS' Hardware-focused mitigation - ==================================== ================================= + ======================================== ================================= + 'Not affected' The processor is not vulnerable + 'Mitigation: None' Vulnerable, no mitigation + 'Mitigation: Retpolines' Use Retpoline thunks + 'Mitigation: LFENCE' Use LFENCE instructions + 'Mitigation: Enhanced IBRS' Hardware-focused mitigation + 'Mitigation: Enhanced IBRS + Retpolines' Hardware-focused + Retpolines + 'Mitigation: Enhanced IBRS + LFENCE' Hardware-focused + LFENCE + ======================================== ================================= - Firmware status: Show if Indirect Branch Restricted Speculation (IBRS) is used to protect against Spectre variant 2 attacks when calling firmware (x86 only). @@ -583,12 +598,13 @@ kernel command line. Specific mitigations can also be selected manually: - retpoline - replace indirect branches - retpoline,generic - google's original retpoline - retpoline,amd - AMD-specific minimal thunk + retpoline auto pick between generic,lfence + retpoline,generic Retpolines + retpoline,lfence LFENCE; indirect branch + retpoline,amd alias for retpoline,lfence + eibrs enhanced IBRS + eibrs,retpoline enhanced IBRS + Retpolines + eibrs,lfence enhanced IBRS + LFENCE Not specifying this option is equivalent to spectre_v2=auto. @@ -599,7 +615,7 @@ kernel command line. spectre_v2=off. Spectre variant 1 mitigations cannot be disabled. -For spectre_v2_user see :doc:`/admin-guide/kernel-parameters`. +For spectre_v2_user see Documentation/admin-guide/kernel-parameters.txt Mitigation selection guide -------------------------- @@ -681,7 +697,7 @@ AMD white papers: .. _spec_ref6: -[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/90343-B_SoftwareTechniquesforManagingSpeculation_WP_7-18Update_FNL.pdf>`_. +[6] `Software techniques for managing speculation on AMD processors <https://developer.amd.com/wp-content/resources/Managing-Speculation-on-AMD-Processors.pdf>`_. ARM white papers: diff --git a/Documentation/admin-guide/index.rst b/Documentation/admin-guide/index.rst index 1bedab498104..5bfafcbb9562 100644 --- a/Documentation/admin-guide/index.rst +++ b/Documentation/admin-guide/index.rst @@ -35,6 +35,7 @@ problems and bugs in particular. :maxdepth: 1 reporting-issues + reporting-regressions security-bugs bug-hunting bug-bisect diff --git a/Documentation/admin-guide/iostats.rst b/Documentation/admin-guide/iostats.rst index 9b14b0c2c9c4..609a3201fd4e 100644 --- a/Documentation/admin-guide/iostats.rst +++ b/Documentation/admin-guide/iostats.rst @@ -76,7 +76,7 @@ Field 3 -- # of sectors read (unsigned long) Field 4 -- # of milliseconds spent reading (unsigned int) This is the total number of milliseconds spent by all reads (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 5 -- # of writes completed (unsigned long) This is the total number of writes completed successfully. @@ -89,7 +89,7 @@ Field 7 -- # of sectors written (unsigned long) Field 8 -- # of milliseconds spent writing (unsigned int) This is the total number of milliseconds spent by all writes (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 9 -- # of I/Os currently in progress (unsigned int) The only field that should go to zero. Incremented as requests are @@ -120,7 +120,7 @@ Field 14 -- # of sectors discarded (unsigned long) Field 15 -- # of milliseconds spent discarding (unsigned int) This is the total number of milliseconds spent by all discards (as - measured from __make_request() to end_that_request_last()). + measured from blk_mq_alloc_request() to __blk_mq_end_request()). Field 16 -- # of flush requests completed This is the total number of flush requests completed successfully. diff --git a/Documentation/admin-guide/kdump/kdump.rst b/Documentation/admin-guide/kdump/kdump.rst index cb30ca3df27c..a748e7eb4429 100644 --- a/Documentation/admin-guide/kdump/kdump.rst +++ b/Documentation/admin-guide/kdump/kdump.rst @@ -146,9 +146,9 @@ System kernel config options CONFIG_SYSFS=y Note that "sysfs file system support" might not appear in the "Pseudo - filesystems" menu if "Configure standard kernel features (for small - systems)" is not enabled in "General Setup." In this case, check the - .config file itself to ensure that sysfs is turned on, as follows:: + filesystems" menu if "Configure standard kernel features (expert users)" + is not enabled in "General Setup." In this case, check the .config file + itself to ensure that sysfs is turned on, as follows:: grep 'CONFIG_SYSFS' .config @@ -533,6 +533,10 @@ the following command:: cp /proc/vmcore <dump-file> +or use scp to write out the dump file between hosts on a network, e.g:: + + scp /proc/vmcore remote_username@remote_ip:<dump-file> + You can also use makedumpfile utility to write out the dump file with specified options to filter out unwanted contents, e.g:: diff --git a/Documentation/admin-guide/kdump/vmcoreinfo.rst b/Documentation/admin-guide/kdump/vmcoreinfo.rst index 3861a25faae1..8419019b6a88 100644 --- a/Documentation/admin-guide/kdump/vmcoreinfo.rst +++ b/Documentation/admin-guide/kdump/vmcoreinfo.rst @@ -494,6 +494,14 @@ architecture which is used to lookup the page-tables for the Virtual addresses in the higher VA range (refer to ARMv8 ARM document for more details). +MODULES_VADDR|MODULES_END|VMALLOC_START|VMALLOC_END|VMEMMAP_START|VMEMMAP_END +----------------------------------------------------------------------------- + +Used to get the correct ranges: + MODULES_VADDR ~ MODULES_END-1 : Kernel module space. + VMALLOC_START ~ VMALLOC_END-1 : vmalloc() / ioremap() space. + VMEMMAP_START ~ VMEMMAP_END-1 : vmemmap region, used for struct page array. + arm === diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt index f5a27f067db9..3f1cc5e317ed 100644 --- a/Documentation/admin-guide/kernel-parameters.txt +++ b/Documentation/admin-guide/kernel-parameters.txt @@ -724,6 +724,12 @@ hvc<n> Use the hypervisor console device <n>. This is for both Xen and PowerPC hypervisors. + { null | "" } + Use to disable console output, i.e., to have kernel + console messages discarded. + This must be the only console= parameter used on the + kernel command line. + If the device connected to the port is not a TTY but a braille device, prepend "brl," before the device type, for instance console=brl,ttyS0 @@ -944,6 +950,30 @@ dump out devices still on the deferred probe list after retrying. + dell_smm_hwmon.ignore_dmi= + [HW] Continue probing hardware even if DMI data + indicates that the driver is running on unsupported + hardware. + + dell_smm_hwmon.force= + [HW] Activate driver even if SMM BIOS signature does + not match list of supported models and enable otherwise + blacklisted features. + + dell_smm_hwmon.power_status= + [HW] Report power status in /proc/i8k + (disabled by default). + + dell_smm_hwmon.restricted= + [HW] Allow controlling fans only if SYS_ADMIN + capability is set. + + dell_smm_hwmon.fan_mult= + [HW] Factor to multiply fan speed with. + + dell_smm_hwmon.fan_max= + [HW] Maximum configurable fan speed. + dfltcc= [HW,S390] Format: { on | off | def_only | inf_only | always } on: s390 zlib hardware support for compression on @@ -1435,6 +1465,14 @@ as early as possible in order to facilitate early boot debugging. + ftrace_boot_snapshot + [FTRACE] On boot up, a snapshot will be taken of the + ftrace ring buffer that can be read at: + /sys/kernel/tracing/snapshot. + This is useful if you need tracing information from kernel + boot up that is likely to be overridden by user space + start up functionality. + ftrace_dump_on_oops[=orig_cpu] [FTRACE] will dump the trace buffers on oops. If no parameter is passed, ftrace will dump @@ -1625,7 +1663,7 @@ [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). + memory (7 * PAGE_SIZE for each 2MB hugetlb page). Format: { on | off (default) } on: enable the feature @@ -1703,17 +1741,6 @@ i810= [HW,DRM] - i8k.ignore_dmi [HW] Continue probing hardware even if DMI data - indicates that the driver is running on unsupported - hardware. - i8k.force [HW] Activate i8k driver even if SMM BIOS signature - does not match list of supported models. - i8k.power_status - [HW] Report power status in /proc/i8k - (disabled by default) - i8k.restricted [HW] Allow controlling fans only if SYS_ADMIN - capability is set. - i915.invert_brightness= [DRM] Invert the sense of the variable that is used to set the brightness of the panel backlight. Normally a @@ -2339,13 +2366,35 @@ kvm.ignore_msrs=[KVM] Ignore guest accesses to unhandled MSRs. Default is 0 (don't ignore, but inject #GP) + kvm.eager_page_split= + [KVM,X86] Controls whether or not KVM will try to + proactively split all huge pages during dirty logging. + Eager page splitting reduces interruptions to vCPU + execution by eliminating the write-protection faults + and MMU lock contention that would otherwise be + required to split huge pages lazily. + + VM workloads that rarely perform writes or that write + only to a small region of VM memory may benefit from + disabling eager page splitting to allow huge pages to + still be used for reads. + + The behavior of eager page splitting depends on whether + KVM_DIRTY_LOG_INITIALLY_SET is enabled or disabled. If + disabled, all huge pages in a memslot will be eagerly + split when dirty logging is enabled on that memslot. If + enabled, eager page splitting will be performed during + the KVM_CLEAR_DIRTY ioctl, and only for the pages being + cleared. + + Eager page splitting currently only supports splitting + huge pages mapped by the TDP MMU. + + Default is Y (on). + kvm.enable_vmware_backdoor=[KVM] Support VMware backdoor PV interface. Default is false (don't support). - kvm.mmu_audit= [KVM] This is a R/W parameter which allows audit - KVM MMU at runtime. - Default is 0 (off) - kvm.nx_huge_pages= [KVM] Controls the software workaround for the X86_BUG_ITLB_MULTIHIT bug. @@ -2827,6 +2876,9 @@ For details see: Documentation/admin-guide/hw-vuln/mds.rst + mem=nn[KMG] [HEXAGON] Set the memory size. + Must be specified, otherwise memory size will be 0. + mem=nn[KMG] [KNL,BOOT] Force usage of a specific amount of memory Amount of memory to be used in cases as follows: @@ -2834,6 +2886,13 @@ 2 when the kernel is not able to see the whole system memory; 3 memory that lies after 'mem=' boundary is excluded from the hypervisor, then assigned to KVM guests. + 4 to limit the memory available for kdump kernel. + + [ARC,MICROBLAZE] - the limit applies only to low memory, + high memory is not affected. + + [ARM64] - only limits memory covered by the linear + mapping. The NOMAP regions are not affected. [X86] Work as limiting max address. Use together with memmap= to avoid physical address space collisions. @@ -2844,6 +2903,14 @@ in above case 3, memory may need be hot added after boot if system memory of hypervisor is not sufficient. + mem=nn[KMG]@ss[KMG] + [ARM,MIPS] - override the memory layout reported by + firmware. + Define a memory region of size nn[KMG] starting at + ss[KMG]. + Multiple different regions can be specified with + multiple mem= parameters on the command line. + mem=nopentium [BUGS=X86-32] Disable usage of 4MB pages for kernel memory. @@ -3485,8 +3552,7 @@ difficult since unequal pointers can no longer be compared. However, if this command-line option is specified, then all normal pointers will have their true - value printed. Pointers printed via %pK may still be - hashed. This option should only be specified when + value printed. This option should only be specified when debugging the kernel. Please do not use on production kernels. @@ -3726,6 +3792,11 @@ bit 3: print locks info if CONFIG_LOCKDEP is on bit 4: print ftrace buffer bit 5: print all printk messages in buffer + bit 6: print all CPUs backtrace (if available in the arch) + *Be aware* that this option may print a _lot_ of lines, + so there are risks of losing older messages in the log. + Use this option carefully, maybe worth to setup a + bigger log buffer with "log_buf_len" along with this. panic_on_taint= Bitmask for conditionally calling panic() in add_taint() Format: <hex>[,nousertaint] @@ -4356,6 +4427,12 @@ fully seed the kernel's CRNG. Default is controlled by CONFIG_RANDOM_TRUST_CPU. + random.trust_bootloader={on,off} + [KNL] Enable or disable trusting the use of a + seed passed by the bootloader (if available) to + fully seed the kernel's CRNG. Default is controlled + by CONFIG_RANDOM_TRUST_BOOTLOADER. + randomize_kstack_offset= [KNL] Enable or disable kernel stack offset randomization, which provides roughly 5 bits of @@ -4504,6 +4581,8 @@ (the least-favored priority). Otherwise, when RCU_BOOST is not set, valid values are 0-99 and the default is zero (non-realtime operation). + When RCU_NOCB_CPU is set, also adjust the + priority of NOCB callback kthreads. rcutree.rcu_nocb_gp_stride= [KNL] Set the number of NOCB callback kthreads in @@ -5361,8 +5440,12 @@ Specific mitigations can also be selected manually: retpoline - replace indirect branches - retpoline,generic - google's original retpoline - retpoline,amd - AMD-specific minimal thunk + retpoline,generic - Retpolines + retpoline,lfence - LFENCE; indirect branch + retpoline,amd - alias for retpoline,lfence + eibrs - enhanced IBRS + eibrs,retpoline - enhanced IBRS + Retpolines + eibrs,lfence - enhanced IBRS + LFENCE Not specifying this option is equivalent to spectre_v2=auto. diff --git a/Documentation/admin-guide/laptops/lg-laptop.rst b/Documentation/admin-guide/laptops/lg-laptop.rst index 6fbe165dcd27..67fd6932cef4 100644 --- a/Documentation/admin-guide/laptops/lg-laptop.rst +++ b/Documentation/admin-guide/laptops/lg-laptop.rst @@ -38,7 +38,7 @@ FN lock. Battery care limit ------------------ -Writing 80/100 to /sys/devices/platform/lg-laptop/battery_care_limit +Writing 80/100 to /sys/class/power_supply/CMB0/charge_control_end_threshold sets the maximum capacity to charge the battery. Limiting the charge reduces battery capacity loss over time. diff --git a/Documentation/admin-guide/media/fimc.rst b/Documentation/admin-guide/media/fimc.rst index 56b149d9a527..267ef52fe387 100644 --- a/Documentation/admin-guide/media/fimc.rst +++ b/Documentation/admin-guide/media/fimc.rst @@ -14,7 +14,7 @@ data from LCD controller (FIMD) through the SoC internal writeback data path. There are multiple FIMC instances in the SoCs (up to 4), having slightly different capabilities, like pixel alignment constraints, rotator availability, LCD writeback support, etc. The driver is located at -drivers/media/platform/exynos4-is directory. +drivers/media/platform/samsung/exynos4-is directory. Supported SoCs -------------- diff --git a/Documentation/admin-guide/media/i2c-cardlist.rst b/Documentation/admin-guide/media/i2c-cardlist.rst index db17f39b56cf..ef3b5fff3b01 100644 --- a/Documentation/admin-guide/media/i2c-cardlist.rst +++ b/Documentation/admin-guide/media/i2c-cardlist.rst @@ -284,7 +284,7 @@ tda9887 TDA 9885/6/7 analog IF demodulator tea5761 TEA 5761 radio tuner tea5767 TEA 5767 radio tuner tua9001 Infineon TUA9001 silicon tuner -tuner-xc2028 XCeive xc2028/xc3028 tuners +xc2028 XCeive xc2028/xc3028 tuners xc4000 Xceive XC4000 silicon tuner xc5000 Xceive XC5000 silicon tuner ============ ================================================== diff --git a/Documentation/admin-guide/media/imx7.rst b/Documentation/admin-guide/media/imx7.rst index 4785ae8ac978..2fa27718f52a 100644 --- a/Documentation/admin-guide/media/imx7.rst +++ b/Documentation/admin-guide/media/imx7.rst @@ -33,7 +33,7 @@ reference manual [#f1]_. Entities -------- -imx7-mipi-csi2 +imx-mipi-csi2 -------------- This is the MIPI CSI-2 receiver entity. It has one sink pad to receive the pixel diff --git a/Documentation/admin-guide/media/omap3isp.rst b/Documentation/admin-guide/media/omap3isp.rst index bc447bbec7ce..f32e7375a1a2 100644 --- a/Documentation/admin-guide/media/omap3isp.rst +++ b/Documentation/admin-guide/media/omap3isp.rst @@ -17,7 +17,7 @@ Introduction ------------ This file documents the Texas Instruments OMAP 3 Image Signal Processor (ISP) -driver located under drivers/media/platform/omap3isp. The original driver was +driver located under drivers/media/platform/ti/omap3isp. The original driver was written by Texas Instruments but since that it has been rewritten (twice) at Nokia. diff --git a/Documentation/admin-guide/media/omap4_camera.rst b/Documentation/admin-guide/media/omap4_camera.rst index 24db4222d36d..2ada9b1e6897 100644 --- a/Documentation/admin-guide/media/omap4_camera.rst +++ b/Documentation/admin-guide/media/omap4_camera.rst @@ -25,7 +25,7 @@ As of Revision AB, the ISS is described in detail in section 8. This driver is supporting **only** the CSI2-A/B interfaces for now. It makes use of the Media Controller framework [#f2]_, and inherited most of the -code from OMAP3 ISP driver (found under drivers/media/platform/omap3isp/\*), +code from OMAP3 ISP driver (found under drivers/media/platform/ti/omap3isp/\*), except that it doesn't need an IOMMU now for ISS buffers memory mapping. Supports usage of MMAP buffers only (for now). diff --git a/Documentation/admin-guide/media/vimc.rst b/Documentation/admin-guide/media/vimc.rst index 180507d455f2..0b07f05dde25 100644 --- a/Documentation/admin-guide/media/vimc.rst +++ b/Documentation/admin-guide/media/vimc.rst @@ -76,3 +76,16 @@ vimc-capture: * 1 Pad sink * 1 Pad source + +Module options +-------------- + +Vimc has a module parameter to configure the driver. + +* ``allocator=<unsigned int>`` + + memory allocator selection, default is 0. It specifies the way buffers + will be allocated. + + - 0: vmalloc + - 1: dma-contig diff --git a/Documentation/admin-guide/mm/damon/usage.rst b/Documentation/admin-guide/mm/damon/usage.rst index 59b84904a854..592ea9a50881 100644 --- a/Documentation/admin-guide/mm/damon/usage.rst +++ b/Documentation/admin-guide/mm/damon/usage.rst @@ -4,7 +4,7 @@ Detailed Usages =============== -DAMON provides below three interfaces for different users. +DAMON provides below interfaces for different users. - *DAMON user space tool.* `This <https://github.com/awslabs/damo>`_ is for privileged people such as @@ -14,17 +14,21 @@ DAMON provides below three interfaces for different users. virtual and physical address spaces monitoring. For more detail, please refer to its `usage document <https://github.com/awslabs/damo/blob/next/USAGE.md>`_. -- *debugfs interface.* - :ref:`This <debugfs_interface>` is for privileged user space programmers who +- *sysfs interface.* + :ref:`This <sysfs_interface>` is for privileged user space programmers who want more optimized use of DAMON. Using this, users can use DAMON’s major - features by reading from and writing to special debugfs files. Therefore, - you can write and use your personalized DAMON debugfs wrapper programs that - reads/writes the debugfs files instead of you. The `DAMON user space tool + features by reading from and writing to special sysfs files. Therefore, + you can write and use your personalized DAMON sysfs wrapper programs that + reads/writes the sysfs files instead of you. The `DAMON user space tool <https://github.com/awslabs/damo>`_ is one example of such programs. It supports both virtual and physical address spaces monitoring. Note that this interface provides only simple :ref:`statistics <damos_stats>` for the monitoring results. For detailed monitoring results, DAMON provides a :ref:`tracepoint <tracepoint>`. +- *debugfs interface.* + :ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface + <sysfs_interface>`. This will be removed after next LTS kernel is released, + so users should move to the :ref:`sysfs interface <sysfs_interface>`. - *Kernel Space Programming Interface.* :doc:`This </vm/damon/api>` is for kernel space programmers. Using this, users can utilize every feature of DAMON most flexibly and efficiently by @@ -32,6 +36,340 @@ DAMON provides below three interfaces for different users. DAMON for various address spaces. For detail, please refer to the interface :doc:`document </vm/damon/api>`. +.. _sysfs_interface: + +sysfs Interface +=============== + +DAMON sysfs interface is built when ``CONFIG_DAMON_SYSFS`` is defined. It +creates multiple directories and files under its sysfs directory, +``<sysfs>/kernel/mm/damon/``. You can control DAMON by writing to and reading +from the files under the directory. + +For a short example, users can monitor the virtual address space of a given +workload as below. :: + + # cd /sys/kernel/mm/damon/admin/ + # echo 1 > kdamonds/nr && echo 1 > kdamonds/0/contexts/nr + # echo vaddr > kdamonds/0/contexts/0/operations + # echo 1 > kdamonds/0/contexts/0/targets/nr + # echo $(pidof <workload>) > kdamonds/0/contexts/0/targets/0/pid + # echo on > kdamonds/0/state + +Files Hierarchy +--------------- + +The files hierarchy of DAMON sysfs interface is shown below. In the below +figure, parents-children relations are represented with indentations, each +directory is having ``/`` suffix, and files in each directory are separated by +comma (","). :: + + /sys/kernel/mm/damon/admin + │ kdamonds/nr_kdamonds + │ │ 0/state,pid + │ │ │ contexts/nr_contexts + │ │ │ │ 0/operations + │ │ │ │ │ monitoring_attrs/ + │ │ │ │ │ │ intervals/sample_us,aggr_us,update_us + │ │ │ │ │ │ nr_regions/min,max + │ │ │ │ │ targets/nr_targets + │ │ │ │ │ │ 0/pid_target + │ │ │ │ │ │ │ regions/nr_regions + │ │ │ │ │ │ │ │ 0/start,end + │ │ │ │ │ │ │ │ ... + │ │ │ │ │ │ ... + │ │ │ │ │ schemes/nr_schemes + │ │ │ │ │ │ 0/action + │ │ │ │ │ │ │ access_pattern/ + │ │ │ │ │ │ │ │ sz/min,max + │ │ │ │ │ │ │ │ nr_accesses/min,max + │ │ │ │ │ │ │ │ age/min,max + │ │ │ │ │ │ │ quotas/ms,bytes,reset_interval_ms + │ │ │ │ │ │ │ │ weights/sz_permil,nr_accesses_permil,age_permil + │ │ │ │ │ │ │ watermarks/metric,interval_us,high,mid,low + │ │ │ │ │ │ │ stats/nr_tried,sz_tried,nr_applied,sz_applied,qt_exceeds + │ │ │ │ │ │ ... + │ │ │ │ ... + │ │ ... + +Root +---- + +The root of the DAMON sysfs interface is ``<sysfs>/kernel/mm/damon/``, and it +has one directory named ``admin``. The directory contains the files for +privileged user space programs' control of DAMON. User space tools or deamons +having the root permission could use this directory. + +kdamonds/ +--------- + +The monitoring-related information including request specifications and results +are called DAMON context. DAMON executes each context with a kernel thread +called kdamond, and multiple kdamonds could run in parallel. + +Under the ``admin`` directory, one directory, ``kdamonds``, which has files for +controlling the kdamonds exist. In the beginning, this directory has only one +file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number +of child directories named ``0`` to ``N-1``. Each directory represents each +kdamond. + +kdamonds/<N>/ +------------- + +In each kdamond directory, two files (``state`` and ``pid``) and one directory +(``contexts``) exist. + +Reading ``state`` returns ``on`` if the kdamond is currently running, or +``off`` if it is not running. Writing ``on`` or ``off`` makes the kdamond be +in the state. Writing ``update_schemes_stats`` to ``state`` file updates the +contents of stats files for each DAMON-based operation scheme of the kdamond. +For details of the stats, please refer to :ref:`stats section +<sysfs_schemes_stats>`. + +If the state is ``on``, reading ``pid`` shows the pid of the kdamond thread. + +``contexts`` directory contains files for controlling the monitoring contexts +that this kdamond will execute. + +kdamonds/<N>/contexts/ +---------------------- + +In the beginning, this directory has only one file, ``nr_contexts``. Writing a +number (``N``) to the file creates the number of child directories named as +``0`` to ``N-1``. Each directory represents each monitoring context. At the +moment, only one context per kdamond is supported, so only ``0`` or ``1`` can +be written to the file. + +contexts/<N>/ +------------- + +In each context directory, one file (``operations``) and three directories +(``monitoring_attrs``, ``targets``, and ``schemes``) exist. + +DAMON supports multiple types of monitoring operations, including those for +virtual address space and the physical address space. You can set and get what +type of monitoring operations DAMON will use for the context by writing one of +below keywords to, and reading from the file. + + - vaddr: Monitor virtual address spaces of specific processes + - paddr: Monitor the physical address space of the system + +contexts/<N>/monitoring_attrs/ +------------------------------ + +Files for specifying attributes of the monitoring including required quality +and efficiency of the monitoring are in ``monitoring_attrs`` directory. +Specifically, two directories, ``intervals`` and ``nr_regions`` exist in this +directory. + +Under ``intervals`` directory, three files for DAMON's sampling interval +(``sample_us``), aggregation interval (``aggr_us``), and update interval +(``update_us``) exist. You can set and get the values in micro-seconds by +writing to and reading from the files. + +Under ``nr_regions`` directory, two files for the lower-bound and upper-bound +of DAMON's monitoring regions (``min`` and ``max``, respectively), which +controls the monitoring overhead, exist. You can set and get the values by +writing to and rading from the files. + +For more details about the intervals and monitoring regions range, please refer +to the Design document (:doc:`/vm/damon/design`). + +contexts/<N>/targets/ +--------------------- + +In the beginning, this directory has only one file, ``nr_targets``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each monitoring target. + +targets/<N>/ +------------ + +In each target directory, one file (``pid_target``) and one directory +(``regions``) exist. + +If you wrote ``vaddr`` to the ``contexts/<N>/operations``, each target should +be a process. You can specify the process to DAMON by writing the pid of the +process to the ``pid_target`` file. + +targets/<N>/regions +------------------- + +When ``vaddr`` monitoring operations set is being used (``vaddr`` is written to +the ``contexts/<N>/operations`` file), DAMON automatically sets and updates the +monitoring target regions so that entire memory mappings of target processes +can be covered. However, users could want to set the initial monitoring region +to specific address ranges. + +In contrast, DAMON do not automatically sets and updates the monitoring target +regions when ``paddr`` monitoring operations set is being used (``paddr`` is +written to the ``contexts/<N>/operations``). Therefore, users should set the +monitoring target regions by themselves in the case. + +For such cases, users can explicitly set the initial monitoring target regions +as they want, by writing proper values to the files under this directory. + +In the beginning, this directory has only one file, ``nr_regions``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each initial monitoring target region. + +regions/<N>/ +------------ + +In each region directory, you will find two files (``start`` and ``end``). You +can set and get the start and end addresses of the initial monitoring target +region by writing to and reading from the files, respectively. + +contexts/<N>/schemes/ +--------------------- + +For usual DAMON-based data access aware memory management optimizations, users +would normally want the system to apply a memory management action to a memory +region of a specific access pattern. DAMON receives such formalized operation +schemes from the user and applies those to the target memory regions. Users +can get and set the schemes by reading from and writing to files under this +directory. + +In the beginning, this directory has only one file, ``nr_schemes``. Writing a +number (``N``) to the file creates the number of child directories named ``0`` +to ``N-1``. Each directory represents each DAMON-based operation scheme. + +schemes/<N>/ +------------ + +In each scheme directory, four directories (``access_pattern``, ``quotas``, +``watermarks``, and ``stats``) and one file (``action``) exist. + +The ``action`` file is for setting and getting what action you want to apply to +memory regions having specific access pattern of the interest. The keywords +that can be written to and read from the file and their meaning are as below. + + - ``willneed``: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - ``cold``: Call ``madvise()`` for the region with ``MADV_COLD`` + - ``pageout``: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - ``hugepage``: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - ``nohugepage``: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - ``stat``: Do nothing but count the statistics + +schemes/<N>/access_pattern/ +--------------------------- + +The target access pattern of each DAMON-based operation scheme is constructed +with three ranges including the size of the region in bytes, number of +monitored accesses per aggregate interval, and number of aggregated intervals +for the age of the region. + +Under the ``access_pattern`` directory, three directories (``sz``, +``nr_accesses``, and ``age``) each having two files (``min`` and ``max``) +exist. You can set and get the access pattern for the given scheme by writing +to and reading from the ``min`` and ``max`` files under ``sz``, +``nr_accesses``, and ``age`` directories, respectively. + +schemes/<N>/quotas/ +------------------- + +Optimal ``target access pattern`` for each ``action`` is workload dependent, so +not easy to find. Worse yet, setting a scheme of some action too aggressive +can cause severe overhead. To avoid such overhead, users can limit time and +size quota for each scheme. In detail, users can ask DAMON to try to use only +up to specific time (``time quota``) for applying the action, and to apply the +action to only up to specific amount (``size quota``) of memory regions having +the target access pattern within a given time interval (``reset interval``). + +When the quota limit is expected to be exceeded, DAMON prioritizes found memory +regions of the ``target access pattern`` based on their size, access frequency, +and age. For personalized prioritization, users can set the weights for the +three properties. + +Under ``quotas`` directory, three files (``ms``, ``bytes``, +``reset_interval_ms``) and one directory (``weights``) having three files +(``sz_permil``, ``nr_accesses_permil``, and ``age_permil``) in it exist. + +You can set the ``time quota`` in milliseconds, ``size quota`` in bytes, and +``reset interval`` in milliseconds by writing the values to the three files, +respectively. You can also set the prioritization weights for size, access +frequency, and age in per-thousand unit by writing the values to the three +files under the ``weights`` directory. + +schemes/<N>/watermarks/ +----------------------- + +To allow easy activation and deactivation of each scheme based on system +status, DAMON provides a feature called watermarks. The feature receives five +values called ``metric``, ``interval``, ``high``, ``mid``, and ``low``. The +``metric`` is the system metric such as free memory ratio that can be measured. +If the metric value of the system is higher than the value in ``high`` or lower +than ``low`` at the memoent, the scheme is deactivated. If the value is lower +than ``mid``, the scheme is activated. + +Under the watermarks directory, five files (``metric``, ``interval_us``, +``high``, ``mid``, and ``low``) for setting each value exist. You can set and +get the five values by writing to the files, respectively. + +Keywords and meanings of those that can be written to the ``metric`` file are +as below. + + - none: Ignore the watermarks + - free_mem_rate: System's free memory rate (per thousand) + +The ``interval`` should written in microseconds unit. + +.. _sysfs_schemes_stats: + +schemes/<N>/stats/ +------------------ + +DAMON counts the total number and bytes of regions that each scheme is tried to +be applied, the two numbers for the regions that each scheme is successfully +applied, and the total number of the quota limit exceeds. This statistics can +be used for online analysis or tuning of the schemes. + +The statistics can be retrieved by reading the files under ``stats`` directory +(``nr_tried``, ``sz_tried``, ``nr_applied``, ``sz_applied``, and +``qt_exceeds``), respectively. The files are not updated in real time, so you +should ask DAMON sysfs interface to updte the content of the files for the +stats by writing a special keyword, ``update_schemes_stats`` to the relevant +``kdamonds/<N>/state`` file. + +Example +~~~~~~~ + +Below commands applies a scheme saying "If a memory region of size in [4KiB, +8KiB] is showing accesses per aggregate interval in [0, 5] for aggregate +interval in [10, 20], page out the region. For the paging out, use only up to +10ms per second, and also don't page out more than 1GiB per second. Under the +limitation, page out memory regions having longer age first. Also, check the +free memory rate of the system every 5 seconds, start the monitoring and paging +out when the free memory rate becomes lower than 50%, but stop it if the free +memory rate becomes larger than 60%, or lower than 30%". :: + + # cd <sysfs>/kernel/mm/damon/admin + # # populate directories + # echo 1 > kdamonds/nr_kdamonds; echo 1 > kdamonds/0/contexts/nr_contexts; + # echo 1 > kdamonds/0/contexts/0/schemes/nr_schemes + # cd kdamonds/0/contexts/0/schemes/0 + # # set the basic access pattern and the action + # echo 4096 > access_patterns/sz/min + # echo 8192 > access_patterns/sz/max + # echo 0 > access_patterns/nr_accesses/min + # echo 5 > access_patterns/nr_accesses/max + # echo 10 > access_patterns/age/min + # echo 20 > access_patterns/age/max + # echo pageout > action + # # set quotas + # echo 10 > quotas/ms + # echo $((1024*1024*1024)) > quotas/bytes + # echo 1000 > quotas/reset_interval_ms + # # set watermark + # echo free_mem_rate > watermarks/metric + # echo 5000000 > watermarks/interval_us + # echo 600 > watermarks/high + # echo 500 > watermarks/mid + # echo 300 > watermarks/low + +Please note that it's highly recommended to use user space tools like `damo +<https://github.com/awslabs/damo>`_ rather than manually reading and writing +the files as above. Above is only for an example. .. _debugfs_interface: @@ -47,7 +385,7 @@ Attributes ---------- Users can get and set the ``sampling interval``, ``aggregation interval``, -``regions update interval``, and min/max number of monitoring target regions by +``update interval``, and min/max number of monitoring target regions by reading from and writing to the ``attrs`` file. To know about the monitoring attributes in detail, please refer to the :doc:`/vm/damon/design`. For example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and @@ -108,24 +446,28 @@ In such cases, users can explicitly set the initial monitoring target regions as they want, by writing proper values to the ``init_regions`` file. Each line of the input should represent one region in below form.:: - <target id> <start address> <end address> + <target idx> <start address> <end address> -The ``target id`` should already in ``target_ids`` file, and the regions should -be passed in address order. For example, below commands will set a couple of -address ranges, ``1-100`` and ``100-200`` as the initial monitoring target -region of process 42, and another couple of address ranges, ``20-40`` and -``50-100`` as that of process 4242.:: +The ``target idx`` should be the index of the target in ``target_ids`` file, +starting from ``0``, and the regions should be passed in address order. For +example, below commands will set a couple of address ranges, ``1-100`` and +``100-200`` as the initial monitoring target region of pid 42, which is the +first one (index ``0``) in ``target_ids``, and another couple of address +ranges, ``20-40`` and ``50-100`` as that of pid 4242, which is the second one +(index ``1``) in ``target_ids``.:: # cd <debugfs>/damon - # echo "42 1 100 - 42 100 200 - 4242 20 40 - 4242 50 100" > init_regions + # cat target_ids + 42 4242 + # echo "0 1 100 + 0 100 200 + 1 20 40 + 1 50 100" > init_regions Note that this sets the initial monitoring target regions only. In case of virtual memory monitoring, DAMON will automatically updates the boundary of the -regions after one ``regions update interval``. Therefore, users should set the -``regions update interval`` large enough in this case, if they don't want the +regions after one ``update interval``. Therefore, users should set the +``update interval`` large enough in this case, if they don't want the update. diff --git a/Documentation/admin-guide/mm/pagemap.rst b/Documentation/admin-guide/mm/pagemap.rst index bfc28704856c..6e2e416af783 100644 --- a/Documentation/admin-guide/mm/pagemap.rst +++ b/Documentation/admin-guide/mm/pagemap.rst @@ -23,7 +23,7 @@ There are four components to pagemap: * 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 + * Bits 58-60 zero * Bit 61 page is file-page or shared-anon (since 3.5) * Bit 62 page swapped * Bit 63 page present diff --git a/Documentation/admin-guide/mm/zswap.rst b/Documentation/admin-guide/mm/zswap.rst index 8edb8d578caf..6e6f7b0d6562 100644 --- a/Documentation/admin-guide/mm/zswap.rst +++ b/Documentation/admin-guide/mm/zswap.rst @@ -130,9 +130,25 @@ attribute, e.g.:: echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled When zswap same-filled page identification is disabled at runtime, it will stop -checking for the same-value filled pages during store operation. However, the -existing pages which are marked as same-value filled pages remain stored -unchanged in zswap until they are either loaded or invalidated. +checking for the same-value filled pages during store operation. +In other words, every page will be then considered non-same-value filled. +However, the existing pages which are marked as same-value filled pages remain +stored unchanged in zswap until they are either loaded or invalidated. + +In some circumstances it might be advantageous to make use of just the zswap +ability to efficiently store same-filled pages without enabling the whole +compressed page storage. +In this case the handling of non-same-value pages by zswap (enabled by default) +can be disabled by setting the ``non_same_filled_pages_enabled`` attribute +to 0, e.g. ``zswap.non_same_filled_pages_enabled=0``. +It can also be enabled and disabled at runtime using the sysfs +``non_same_filled_pages_enabled`` attribute, e.g.:: + + echo 1 > /sys/module/zswap/parameters/non_same_filled_pages_enabled + +Disabling both ``zswap.same_filled_pages_enabled`` and +``zswap.non_same_filled_pages_enabled`` effectively disables accepting any new +pages by zswap. To prevent zswap from shrinking pool when zswap is full and there's a high pressure on swap (this will result in flipping pages in and out zswap pool diff --git a/Documentation/admin-guide/perf/index.rst b/Documentation/admin-guide/perf/index.rst index 5a8f2529a033..69b23f087c05 100644 --- a/Documentation/admin-guide/perf/index.rst +++ b/Documentation/admin-guide/perf/index.rst @@ -8,6 +8,7 @@ Performance monitor support :maxdepth: 1 hisi-pmu + hisi-pcie-pmu imx-ddr qcom_l2_pmu qcom_l3_pmu diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst index 2f066df4ee9c..83b58eb4ab4d 100644 --- a/Documentation/admin-guide/pm/amd-pstate.rst +++ b/Documentation/admin-guide/pm/amd-pstate.rst @@ -19,7 +19,7 @@ Linux kernel. The new mechanism is based on Collaborative Processor Performance Control (CPPC) which provides finer grain frequency management than legacy ACPI hardware P-States. Current AMD CPU/APU platforms are using the ACPI P-states driver to manage CPU frequency and clocks with switching -only in 3 P-states. CPPC replaces the ACPI P-states controls, allows a +only in 3 P-states. CPPC replaces the ACPI P-states controls and allows a flexible, low-latency interface for the Linux kernel to directly communicate the performance hints to hardware. @@ -27,7 +27,7 @@ communicate the performance hints to hardware. ``ondemand``, etc. to manage the performance hints which are provided by CPPC hardware functionality that internally follows the hardware specification (for details refer to AMD64 Architecture Programmer's Manual -Volume 2: System Programming [1]_). Currently ``amd-pstate`` supports basic +Volume 2: System Programming [1]_). Currently, ``amd-pstate`` supports basic frequency control function according to kernel governors on some of the Zen2 and Zen3 processors, and we will implement more AMD specific functions in future after we verify them on the hardware and SBIOS. @@ -41,9 +41,9 @@ continuous, abstract, and unit-less performance value in a scale that is not tied to a specific performance state / frequency. This is an ACPI standard [2]_ which software can specify application performance goals and hints as a relative target to the infrastructure limits. AMD processors -provides the low latency register model (MSR) instead of AML code +provide the low latency register model (MSR) instead of an AML code interpreter for performance adjustments. ``amd-pstate`` will initialize a -``struct cpufreq_driver`` instance ``amd_pstate_driver`` with the callbacks +``struct cpufreq_driver`` instance, ``amd_pstate_driver``, with the callbacks to manage each performance update behavior. :: Highest Perf ------>+-----------------------+ +-----------------------+ @@ -91,26 +91,26 @@ AMD CPPC Performance Capability Highest Performance (RO) ......................... -It is the absolute maximum performance an individual processor may reach, +This is the absolute maximum performance an individual processor may reach, assuming ideal conditions. This performance level may not be sustainable for long durations and may only be achievable if other platform components -are in a specific state; for example, it may require other processors be in +are in a specific state; for example, it may require other processors to be in an idle state. This would be equivalent to the highest frequencies supported by the processor. Nominal (Guaranteed) Performance (RO) ...................................... -It is the maximum sustained performance level of the processor, assuming -ideal operating conditions. In absence of an external constraint (power, -thermal, etc.) this is the performance level the processor is expected to +This is the maximum sustained performance level of the processor, assuming +ideal operating conditions. In the absence of an external constraint (power, +thermal, etc.), this is the performance level the processor is expected to be able to maintain continuously. All cores/processors are expected to be able to sustain their nominal performance state simultaneously. Lowest non-linear Performance (RO) ................................... -It is the lowest performance level at which nonlinear power savings are +This is the lowest performance level at which nonlinear power savings are achieved, for example, due to the combined effects of voltage and frequency scaling. Above this threshold, lower performance levels should be generally more energy efficient than higher performance levels. This register @@ -119,7 +119,7 @@ effectively conveys the most efficient performance level to ``amd-pstate``. Lowest Performance (RO) ........................ -It is the absolute lowest performance level of the processor. Selecting a +This is the absolute lowest performance level of the processor. Selecting a performance level lower than the lowest nonlinear performance level may cause an efficiency penalty but should reduce the instantaneous power consumption of the processor. @@ -149,14 +149,14 @@ a relative number. This can be expressed as percentage of nominal performance (infrastructure max). Below the nominal sustained performance level, desired performance expresses the average performance level of the processor subject to hardware. Above the nominal performance level, -processor must provide at least nominal performance requested and go higher +the processor must provide at least nominal performance requested and go higher if current operating conditions allow. Energy Performance Preference (EPP) (RW) ......................................... -Provides a hint to the hardware if software wants to bias toward performance -(0x0) or energy efficiency (0xff). +This attribute provides a hint to the hardware if software wants to bias +toward performance (0x0) or energy efficiency (0xff). Key Governors Support @@ -173,35 +173,34 @@ operating frequencies supported by the hardware. Users can check the ``amd-pstate`` mainly supports ``schedutil`` and ``ondemand`` for dynamic frequency control. It is to fine tune the processor configuration on ``amd-pstate`` to the ``schedutil`` with CPU CFS scheduler. ``amd-pstate`` -registers adjust_perf callback to implement the CPPC similar performance -update behavior. It is initialized by ``sugov_start`` and then populate the -CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as -the utilization update callback function in CPU scheduler. CPU scheduler -will call ``cpufreq_update_util`` and assign the target performance -according to the ``struct sugov_cpu`` that utilization update belongs to. -Then ``amd-pstate`` updates the desired performance according to the CPU +registers the adjust_perf callback to implement performance update behavior +similar to CPPC. It is initialized by ``sugov_start`` and then populates the +CPU's update_util_data pointer to assign ``sugov_update_single_perf`` as the +utilization update callback function in the CPU scheduler. The CPU scheduler +will call ``cpufreq_update_util`` and assigns the target performance according +to the ``struct sugov_cpu`` that the utilization update belongs to. +Then, ``amd-pstate`` updates the desired performance according to the CPU scheduler assigned. Processor Support ======================= -The ``amd-pstate`` initialization will fail if the _CPC in ACPI SBIOS is -not existed at the detected processor, and it uses ``acpi_cpc_valid`` to -check the _CPC existence. All Zen based processors support legacy ACPI -hardware P-States function, so while the ``amd-pstate`` fails to be -initialized, the kernel will fall back to initialize ``acpi-cpufreq`` -driver. +The ``amd-pstate`` initialization will fail if the ``_CPC`` entry in the ACPI +SBIOS does not exist in the detected processor. It uses ``acpi_cpc_valid`` +to check the existence of ``_CPC``. All Zen based processors support the legacy +ACPI hardware P-States function, so when ``amd-pstate`` fails initialization, +the kernel will fall back to initialize the ``acpi-cpufreq`` driver. There are two types of hardware implementations for ``amd-pstate``: one is `Full MSR Support <perf_cap_>`_ and another is `Shared Memory Support -<perf_cap_>`_. It can use :c:macro:`X86_FEATURE_CPPC` feature flag (for -details refer to Processor Programming Reference (PPR) for AMD Family -19h Model 51h, Revision A1 Processors [3]_) to indicate the different -types. ``amd-pstate`` is to register different ``static_call`` instances -for different hardware implementations. +<perf_cap_>`_. It can use the :c:macro:`X86_FEATURE_CPPC` feature flag to +indicate the different types. (For details, refer to the Processor Programming +Reference (PPR) for AMD Family 19h Model 51h, Revision A1 Processors [3]_.) +``amd-pstate`` is to register different ``static_call`` instances for different +hardware implementations. -Currently, some of Zen2 and Zen3 processors support ``amd-pstate``. In the +Currently, some of the Zen2 and Zen3 processors support ``amd-pstate``. In the future, it will be supported on more and more AMD processors. Full MSR Support @@ -210,18 +209,18 @@ Full MSR Support Some new Zen3 processors such as Cezanne provide the MSR registers directly while the :c:macro:`X86_FEATURE_CPPC` CPU feature flag is set. ``amd-pstate`` can handle the MSR register to implement the fast switch -function in ``CPUFreq`` that can shrink latency of frequency control on the -interrupt context. The functions with ``pstate_xxx`` prefix represent the -operations of MSR registers. +function in ``CPUFreq`` that can reduce the latency of frequency control in +interrupt context. The functions with a ``pstate_xxx`` prefix represent the +operations on MSR registers. Shared Memory Support ---------------------- -If :c:macro:`X86_FEATURE_CPPC` CPU feature flag is not set, that means the -processor supports shared memory solution. In this case, ``amd-pstate`` +If the :c:macro:`X86_FEATURE_CPPC` CPU feature flag is not set, the +processor supports the shared memory solution. In this case, ``amd-pstate`` uses the ``cppc_acpi`` helper methods to implement the callback functions -that defined on ``static_call``. The functions with ``cppc_xxx`` prefix -represent the operations of acpi cppc helpers for shared memory solution. +that are defined on ``static_call``. The functions with the ``cppc_xxx`` prefix +represent the operations of ACPI CPPC helpers for the shared memory solution. AMD P-States and ACPI hardware P-States always can be supported in one @@ -234,7 +233,7 @@ User Space Interface in ``sysfs`` ================================== ``amd-pstate`` exposes several global attributes (files) in ``sysfs`` to -control its functionality at the system level. They located in the +control its functionality at the system level. They are located in the ``/sys/devices/system/cpu/cpufreq/policyX/`` directory and affect all CPUs. :: root@hr-test1:/home/ray# ls /sys/devices/system/cpu/cpufreq/policy0/*amd* @@ -246,38 +245,38 @@ control its functionality at the system level. They located in the ``amd_pstate_highest_perf / amd_pstate_max_freq`` Maximum CPPC performance and CPU frequency that the driver is allowed to -set in percent of the maximum supported CPPC performance level (the highest +set, in percent of the maximum supported CPPC performance level (the highest performance supported in `AMD CPPC Performance Capability <perf_cap_>`_). -In some of ASICs, the highest CPPC performance is not the one in the _CPC -table, so we need to expose it to sysfs. If boost is not active but -supported, this maximum frequency will be larger than the one in +In some ASICs, the highest CPPC performance is not the one in the ``_CPC`` +table, so we need to expose it to sysfs. If boost is not active, but +still supported, this maximum frequency will be larger than the one in ``cpuinfo``. This attribute is read-only. ``amd_pstate_lowest_nonlinear_freq`` -The lowest non-linear CPPC CPU frequency that the driver is allowed to set -in percent of the maximum supported CPPC performance level (Please see the +The lowest non-linear CPPC CPU frequency that the driver is allowed to set, +in percent of the maximum supported CPPC performance level. (Please see the lowest non-linear performance in `AMD CPPC Performance Capability -<perf_cap_>`_). +<perf_cap_>`_.) This attribute is read-only. -For other performance and frequency values, we can read them back from +Other performance and frequency values can be read back from ``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`. ``amd-pstate`` vs ``acpi-cpufreq`` ====================================== -On majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables -provided by the platform firmware used for CPU performance scaling, but -only provides 3 P-states on AMD processors. -However, on modern AMD APU and CPU series, it provides the collaborative -processor performance control according to ACPI protocol and customize this -for AMD platforms. That is fine-grain and continuous frequency range +On the majority of AMD platforms supported by ``acpi-cpufreq``, the ACPI tables +provided by the platform firmware are used for CPU performance scaling, but +only provide 3 P-states on AMD processors. +However, on modern AMD APU and CPU series, hardware provides the Collaborative +Processor Performance Control according to the ACPI protocol and customizes this +for AMD platforms. That is, fine-grained and continuous frequency ranges instead of the legacy hardware P-states. ``amd-pstate`` is the kernel -module which supports the new AMD P-States mechanism on most of future AMD -platforms. The AMD P-States mechanism will be the more performance and energy +module which supports the new AMD P-States mechanism on most of the future AMD +platforms. The AMD P-States mechanism is the more performance and energy efficiency frequency management method on AMD processors. Kernel Module Options for ``amd-pstate`` @@ -287,25 +286,25 @@ Kernel Module Options for ``amd-pstate`` Use a module param (shared_mem) to enable related processors manually with **amd_pstate.shared_mem=1**. Due to the performance issue on the processors with `Shared Memory Support -<perf_cap_>`_, so we disable it for the moment and will enable this by default -once we address performance issue on this solution. +<perf_cap_>`_, we disable it presently and will re-enable this by default +once we address performance issue with this solution. -The way to check whether current processor is `Full MSR Support <perf_cap_>`_ +To check whether the current processor is using `Full MSR Support <perf_cap_>`_ or `Shared Memory Support <perf_cap_>`_ : :: ray@hr-test1:~$ lscpu | grep cppc Flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid aperfmperf rapl pni pclmulqdq monitor ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx f16c rdrand lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt tce topoext perfctr_core perfctr_nb bpext perfctr_llc mwaitx cpb cat_l3 cdp_l3 hw_pstate ssbd mba ibrs ibpb stibp vmmcall fsgsbase bmi1 avx2 smep bmi2 erms invpcid cqm rdt_a rdseed adx smap clflushopt clwb sha_ni xsaveopt xsavec xgetbv1 xsaves cqm_llc cqm_occup_llc cqm_mbm_total cqm_mbm_local clzero irperf xsaveerptr rdpru wbnoinvd cppc arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold avic v_vmsave_vmload vgif v_spec_ctrl umip pku ospke vaes vpclmulqdq rdpid overflow_recov succor smca fsrm -If CPU Flags have cppc, then this processor supports `Full MSR Support -<perf_cap_>`_. Otherwise it supports `Shared Memory Support <perf_cap_>`_. +If the CPU flags have ``cppc``, then this processor supports `Full MSR Support +<perf_cap_>`_. Otherwise, it supports `Shared Memory Support <perf_cap_>`_. ``cpupower`` tool support for ``amd-pstate`` =============================================== -``amd-pstate`` is supported on ``cpupower`` tool that can be used to dump the frequency -information. And it is in progress to support more and more operations for new -``amd-pstate`` module with this tool. :: +``amd-pstate`` is supported by the ``cpupower`` tool, which can be used to dump +frequency information. Development is in progress to support more and more +operations for the new ``amd-pstate`` module with this tool. :: root@hr-test1:/home/ray# cpupower frequency-info analyzing CPU 0: @@ -336,10 +335,10 @@ Trace Events -------------- There are two static trace events that can be used for ``amd-pstate`` -diagnostics. One of them is the cpu_frequency trace event generally used +diagnostics. One of them is the ``cpu_frequency`` trace event generally used by ``CPUFreq``, and the other one is the ``amd_pstate_perf`` trace event specific to ``amd-pstate``. The following sequence of shell commands can -be used to enable them and see their output (if the kernel is generally +be used to enable them and see their output (if the kernel is configured to support event tracing). :: root@hr-test1:/home/ray# cd /sys/kernel/tracing/ @@ -364,11 +363,37 @@ configured to support event tracing). :: <idle>-0 [003] d.s.. 4995.980971: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=3 changed=false fast_switch=true <idle>-0 [011] d.s.. 4995.980996: amd_pstate_perf: amd_min_perf=85 amd_des_perf=85 amd_max_perf=166 cpu_id=11 changed=false fast_switch=true -The cpu_frequency trace event will be triggered either by the ``schedutil`` scaling +The ``cpu_frequency`` trace event will be triggered either by the ``schedutil`` scaling governor (for the policies it is attached to), or by the ``CPUFreq`` core (for the policies with other scaling governors). +Tracer Tool +------------- + +``amd_pstate_tracer.py`` can record and parse ``amd-pstate`` trace log, then +generate performance plots. This utility can be used to debug and tune the +performance of ``amd-pstate`` driver. The tracer tool needs to import intel +pstate tracer. + +Tracer tool located in ``linux/tools/power/x86/amd_pstate_tracer``. It can be +used in two ways. If trace file is available, then directly parse the file +with command :: + + ./amd_pstate_trace.py [-c cpus] -t <trace_file> -n <test_name> + +Or generate trace file with root privilege, then parse and plot with command :: + + sudo ./amd_pstate_trace.py [-c cpus] -n <test_name> -i <interval> [-m kbytes] + +The test result can be found in ``results/test_name``. Following is the example +about part of the output. :: + + common_cpu common_secs common_usecs min_perf des_perf max_perf freq mperf apef tsc load duration_ms sample_num elapsed_time common_comm + CPU_005 712 116384 39 49 166 0.7565 9645075 2214891 38431470 25.1 11.646 469 2.496 kworker/5:0-40 + CPU_006 712 116408 39 49 166 0.6769 8950227 1839034 37192089 24.06 11.272 470 2.496 kworker/6:0-1264 + + Reference =========== diff --git a/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst new file mode 100644 index 000000000000..09169d935835 --- /dev/null +++ b/Documentation/admin-guide/pm/intel_uncore_frequency_scaling.rst @@ -0,0 +1,60 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: <isonum.txt> + +============================== +Intel Uncore Frequency Scaling +============================== + +:Copyright: |copy| 2022 Intel Corporation + +:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> + +Introduction +------------ + +The uncore can consume significant amount of power in Intel's Xeon servers based +on the workload characteristics. To optimize the total power and improve overall +performance, SoCs have internal algorithms for scaling uncore frequency. These +algorithms monitor workload usage of uncore and set a desirable frequency. + +It is possible that users have different expectations of uncore performance and +want to have control over it. The objective is similar to allowing users to set +the scaling min/max frequencies via cpufreq sysfs to improve CPU performance. +Users may have some latency sensitive workloads where they do not want any +change to uncore frequency. Also, users may have workloads which require +different core and uncore performance at distinct phases and they may want to +use both cpufreq and the uncore scaling interface to distribute power and +improve overall performance. + +Sysfs Interface +--------------- + +To control uncore frequency, a sysfs interface is provided in the directory: +`/sys/devices/system/cpu/intel_uncore_frequency/`. + +There is one directory for each package and die combination as the scope of +uncore scaling control is per die in multiple die/package SoCs or per +package for single die per package SoCs. The name represents the +scope of control. For example: 'package_00_die_00' is for package id 0 and +die 0. + +Each package_*_die_* contains the following attributes: + +``initial_max_freq_khz`` + Out of reset, this attribute represent the maximum possible frequency. + This is a read-only attribute. If users adjust max_freq_khz, + they can always go back to maximum using the value from this attribute. + +``initial_min_freq_khz`` + Out of reset, this attribute represent the minimum possible frequency. + This is a read-only attribute. If users adjust min_freq_khz, + they can always go back to minimum using the value from this attribute. + +``max_freq_khz`` + This attribute is used to set the maximum uncore frequency. + +``min_freq_khz`` + This attribute is used to set the minimum uncore frequency. + +``current_freq_khz`` + This attribute is used to get the current uncore frequency. diff --git a/Documentation/admin-guide/pm/working-state.rst b/Documentation/admin-guide/pm/working-state.rst index 5d2757e2de65..ee45887811ff 100644 --- a/Documentation/admin-guide/pm/working-state.rst +++ b/Documentation/admin-guide/pm/working-state.rst @@ -15,3 +15,4 @@ Working-State Power Management cpufreq_drivers intel_epb intel-speed-select + intel_uncore_frequency_scaling diff --git a/Documentation/admin-guide/reporting-issues.rst b/Documentation/admin-guide/reporting-issues.rst index d7ac13f789cc..ec62151fe672 100644 --- a/Documentation/admin-guide/reporting-issues.rst +++ b/Documentation/admin-guide/reporting-issues.rst @@ -1,14 +1,5 @@ .. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) -.. - If you want to distribute this text under CC-BY-4.0 only, please use 'The - Linux kernel developers' for author attribution and link this as source: - https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst -.. - Note: Only the content of this RST file as found in the Linux kernel sources - is available under CC-BY-4.0, as versions of this text that were processed - (for example by the kernel's build system) might contain content taken from - files which use a more restrictive license. - +.. See the bottom of this file for additional redistribution information. Reporting issues ++++++++++++++++ @@ -395,22 +386,16 @@ fixed as soon as possible, hence there are 'issues of high priority' that get handled slightly differently in the reporting process. Three type of cases qualify: regressions, security issues, and really severe problems. -You deal with a 'regression' if something that worked with an older version of -the Linux kernel does not work with a newer one or somehow works worse with it. -It thus is a regression when a WiFi driver that did a fine job with Linux 5.7 -somehow misbehaves with 5.8 or doesn't work at all. It's also a regression if -an application shows erratic behavior with a newer kernel, which might happen -due to incompatible changes in the interface between the kernel and the -userland (like procfs and sysfs). Significantly reduced performance or -increased power consumption also qualify as regression. But keep in mind: the -new kernel needs to be built with a configuration that is similar to the one -from the old kernel (see below how to achieve that). That's because the kernel -developers sometimes can not avoid incompatibilities when implementing new -features; but to avoid regressions such features have to be enabled explicitly -during build time configuration. +You deal with a regression if some application or practical use case running +fine with one Linux kernel works worse or not at all with a newer version +compiled using a similar configuration. The document +Documentation/admin-guide/reporting-regressions.rst explains this in more +detail. It also provides a good deal of other information about regressions you +might want to be aware of; it for example explains how to add your issue to the +list of tracked regressions, to ensure it won't fall through the cracks. What qualifies as security issue is left to your judgment. Consider reading -'Documentation/admin-guide/security-bugs.rst' before proceeding, as it +Documentation/admin-guide/security-bugs.rst before proceeding, as it provides additional details how to best handle security issues. An issue is a 'really severe problem' when something totally unacceptably bad @@ -517,7 +502,7 @@ line starting with 'CPU:'. It should end with 'Not tainted' if the kernel was not tainted when it noticed the problem; it was tainted if you see 'Tainted:' followed by a few spaces and some letters. -If your kernel is tainted, study 'Documentation/admin-guide/tainted-kernels.rst' +If your kernel is tainted, study Documentation/admin-guide/tainted-kernels.rst to find out why. Try to eliminate the reason. Often it's caused by one these three things: @@ -1043,7 +1028,7 @@ down the culprit, as maintainers often won't have the time or setup at hand to reproduce it themselves. To find the change there is a process called 'bisection' which the document -'Documentation/admin-guide/bug-bisect.rst' describes in detail. That process +Documentation/admin-guide/bug-bisect.rst describes in detail. That process will often require you to build about ten to twenty kernel images, trying to reproduce the issue with each of them before building the next. Yes, that takes some time, but don't worry, it works a lot quicker than most people assume. @@ -1073,10 +1058,11 @@ When dealing with regressions make sure the issue you face is really caused by the kernel and not by something else, as outlined above already. In the whole process keep in mind: an issue only qualifies as regression if the -older and the newer kernel got built with a similar configuration. The best way -to archive this: copy the configuration file (``.config``) from the old working -kernel freshly to each newer kernel version you try. Afterwards run ``make -olddefconfig`` to adjust it for the needs of the new version. +older and the newer kernel got built with a similar configuration. This can be +achieved by using ``make olddefconfig``, as explained in more detail by +Documentation/admin-guide/reporting-regressions.rst; that document also +provides a good deal of other information about regressions you might want to be +aware of. Write and send the report @@ -1283,7 +1269,7 @@ them when sending the report by mail. If you filed it in a bug tracker, forward the report's text to these addresses; but on top of it put a small note where you mention that you filed it with a link to the ticket. -See 'Documentation/admin-guide/security-bugs.rst' for more information. +See Documentation/admin-guide/security-bugs.rst for more information. Duties after the report went out @@ -1571,7 +1557,7 @@ Once your report is out your might get asked to do a proper one, as it allows to pinpoint the exact change that causes the issue (which then can easily get reverted to fix the issue quickly). Hence consider to do a proper bisection right away if time permits. See the section 'Special care for regressions' and -the document 'Documentation/admin-guide/bug-bisect.rst' for details how to +the document Documentation/admin-guide/bug-bisect.rst for details how to perform one. In case of a successful bisection add the author of the culprit to the recipients; also CC everyone in the signed-off-by chain, which you find at the end of its commit message. @@ -1594,7 +1580,7 @@ Some fixes are too complex Even small and seemingly obvious code-changes sometimes introduce new and totally unexpected problems. The maintainers of the stable and longterm kernels are very aware of that and thus only apply changes to these kernels that are -within rules outlined in 'Documentation/process/stable-kernel-rules.rst'. +within rules outlined in Documentation/process/stable-kernel-rules.rst. Complex or risky changes for example do not qualify and thus only get applied to mainline. Other fixes are easy to get backported to the newest stable and @@ -1756,10 +1742,23 @@ art will lay some groundwork to improve the situation over time. .. - This text is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If you - spot a typo or small mistake, feel free to let him know directly and he'll - fix it. You are free to do the same in a mostly informal way if you want - to contribute changes to the text, but for copyright reasons please CC + end-of-content +.. + This document is maintained by Thorsten Leemhuis <linux@leemhuis.info>. If + you spot a typo or small mistake, feel free to let him know directly and + he'll fix it. You are free to do the same in a mostly informal way if you + want to contribute changes to the text, but for copyright reasons please CC linux-doc@vger.kernel.org and "sign-off" your contribution as Documentation/process/submitting-patches.rst outlines in the section "Sign your work - the Developer's Certificate of Origin". +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-issues.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/admin-guide/reporting-regressions.rst b/Documentation/admin-guide/reporting-regressions.rst new file mode 100644 index 000000000000..d8adccdae23f --- /dev/null +++ b/Documentation/admin-guide/reporting-regressions.rst @@ -0,0 +1,451 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. [see the bottom of this file for redistribution information] + +Reporting regressions ++++++++++++++++++++++ + +"*We don't cause regressions*" is the first rule of Linux kernel development; +Linux founder and lead developer Linus Torvalds established it himself and +ensures it's obeyed. + +This document describes what the rule means for users and how the Linux kernel's +development model ensures to address all reported regressions; aspects relevant +for kernel developers are left to Documentation/process/handling-regressions.rst. + + +The important bits (aka "TL;DR") +================================ + +#. It's a regression if something running fine with one Linux kernel works worse + or not at all with a newer version. Note, the newer kernel has to be compiled + using a similar configuration; the detailed explanations below describes this + and other fine print in more detail. + +#. Report your issue as outlined in Documentation/admin-guide/reporting-issues.rst, + it already covers all aspects important for regressions and repeated + below for convenience. Two of them are important: start your report's subject + with "[REGRESSION]" and CC or forward it to `the regression mailing list + <https://lore.kernel.org/regressions/>`_ (regressions@lists.linux.dev). + +#. Optional, but recommended: when sending or forwarding your report, make the + Linux kernel regression tracking bot "regzbot" track the issue by specifying + when the regression started like this:: + + #regzbot introduced v5.13..v5.14-rc1 + + +All the details on Linux kernel regressions relevant for users +============================================================== + + +The important basics +-------------------- + + +What is a "regression" and what is the "no regressions rule"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's a regression if some application or practical use case running fine with +one Linux kernel works worse or not at all with a newer version compiled using a +similar configuration. The "no regressions rule" forbids this to take place; if +it happens by accident, developers that caused it are expected to quickly fix +the issue. + +It thus is a regression when a WiFi driver from Linux 5.13 works fine, but with +5.14 doesn't work at all, works significantly slower, or misbehaves somehow. +It's also a regression if a perfectly working application suddenly shows erratic +behavior with a newer kernel version; such issues can be caused by changes in +procfs, sysfs, or one of the many other interfaces Linux provides to userland +software. But keep in mind, as mentioned earlier: 5.14 in this example needs to +be built from a configuration similar to the one from 5.13. This can be achieved +using ``make olddefconfig``, as explained in more detail below. + +Note the "practical use case" in the first sentence of this section: developers +despite the "no regressions" rule are free to change any aspect of the kernel +and even APIs or ABIs to userland, as long as no existing application or use +case breaks. + +Also be aware the "no regressions" rule covers only interfaces the kernel +provides to the userland. It thus does not apply to kernel-internal interfaces +like the module API, which some externally developed drivers use to hook into +the kernel. + +How do I report a regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Just report the issue as outlined in +Documentation/admin-guide/reporting-issues.rst, it already describes the +important points. The following aspects outlined there are especially relevant +for regressions: + + * When checking for existing reports to join, also search the `archives of the + Linux regressions mailing list <https://lore.kernel.org/regressions/>`_ and + `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_. + + * Start your report's subject with "[REGRESSION]". + + * In your report, clearly mention the last kernel version that worked fine and + the first broken one. Ideally try to find the exact change causing the + regression using a bisection, as explained below in more detail. + + * Remember to let the Linux regressions mailing list + (regressions@lists.linux.dev) know about your report: + + * If you report the regression by mail, CC the regressions list. + + * If you report your regression to some bug tracker, forward the submitted + report by mail to the regressions list while CCing the maintainer and the + mailing list for the subsystem in question. + + If it's a regression within a stable or longterm series (e.g. + v5.15.3..v5.15.5), remember to CC the `Linux stable mailing list + <https://lore.kernel.org/stable/>`_ (stable@vger.kernel.org). + + In case you performed a successful bisection, add everyone to the CC the + culprit's commit message mentions in lines starting with "Signed-off-by:". + +When CCing for forwarding your report to the list, consider directly telling the +aforementioned Linux kernel regression tracking bot about your report. To do +that, include a paragraph like this in your mail:: + + #regzbot introduced: v5.13..v5.14-rc1 + +Regzbot will then consider your mail a report for a regression introduced in the +specified version range. In above case Linux v5.13 still worked fine and Linux +v5.14-rc1 was the first version where you encountered the issue. If you +performed a bisection to find the commit that caused the regression, specify the +culprit's commit-id instead:: + + #regzbot introduced: 1f2e3d4c5d + +Placing such a "regzbot command" is in your interest, as it will ensure the +report won't fall through the cracks unnoticed. If you omit this, the Linux +kernel's regressions tracker will take care of telling regzbot about your +regression, as long as you send a copy to the regressions mailing lists. But the +regression tracker is just one human which sometimes has to rest or occasionally +might even enjoy some time away from computers (as crazy as that might sound). +Relying on this person thus will result in an unnecessary delay before the +regressions becomes mentioned `on the list of tracked and unresolved Linux +kernel regressions <https://linux-regtracking.leemhuis.info/regzbot/>`_ and the +weekly regression reports sent by regzbot. Such delays can result in Linus +Torvalds being unaware of important regressions when deciding between "continue +development or call this finished and release the final?". + +Are really all regressions fixed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Nearly all of them are, as long as the change causing the regression (the +"culprit commit") is reliably identified. Some regressions can be fixed without +this, but often it's required. + +Who needs to find the root cause of a regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers of the affected code area should try to locate the culprit on their +own. But for them that's often impossible to do with reasonable effort, as quite +a lot of issues only occur in a particular environment outside the developer's +reach -- for example, a specific hardware platform, firmware, Linux distro, +system's configuration, or application. That's why in the end it's often up to +the reporter to locate the culprit commit; sometimes users might even need to +run additional tests afterwards to pinpoint the exact root cause. Developers +should offer advice and reasonably help where they can, to make this process +relatively easy and achievable for typical users. + +How can I find the culprit? +~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Perform a bisection, as roughly outlined in +Documentation/admin-guide/reporting-issues.rst and described in more detail by +Documentation/admin-guide/bug-bisect.rst. It might sound like a lot of work, but +in many cases finds the culprit relatively quickly. If it's hard or +time-consuming to reliably reproduce the issue, consider teaming up with other +affected users to narrow down the search range together. + +Who can I ask for advice when it comes to regressions? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Send a mail to the regressions mailing list (regressions@lists.linux.dev) while +CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the +issue might better be dealt with in private, feel free to omit the list. + + +Additional details about regressions +------------------------------------ + + +What is the goal of the "no regressions rule"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Users should feel safe when updating kernel versions and not have to worry +something might break. This is in the interest of the kernel developers to make +updating attractive: they don't want users to stay on stable or longterm Linux +series that are either abandoned or more than one and a half years old. That's +in everybody's interest, as `those series might have known bugs, security +issues, or other problematic aspects already fixed in later versions +<http://www.kroah.com/log/blog/2018/08/24/what-stable-kernel-should-i-use/>`_. +Additionally, the kernel developers want to make it simple and appealing for +users to test the latest pre-release or regular release. That's also in +everybody's interest, as it's a lot easier to track down and fix problems, if +they are reported shortly after being introduced. + +Is the "no regressions" rule really adhered in practice? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's taken really seriously, as can be seen by many mailing list posts from +Linux creator and lead developer Linus Torvalds, some of which are quoted in +Documentation/process/handling-regressions.rst. + +Exceptions to this rule are extremely rare; in the past developers almost always +turned out to be wrong when they assumed a particular situation was warranting +an exception. + +Who ensures the "no regressions" is actually followed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The subsystem maintainers should take care of that, which are watched and +supported by the tree maintainers -- e.g. Linus Torvalds for mainline and +Greg Kroah-Hartman et al. for various stable/longterm series. + +All of them are helped by people trying to ensure no regression report falls +through the cracks. One of them is Thorsten Leemhuis, who's currently acting as +the Linux kernel's "regressions tracker"; to facilitate this work he relies on +regzbot, the Linux kernel regression tracking bot. That's why you want to bring +your report on the radar of these people by CCing or forwarding each report to +the regressions mailing list, ideally with a "regzbot command" in your mail to +get it tracked immediately. + +How quickly are regressions normally fixed? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Developers should fix any reported regression as quickly as possible, to provide +affected users with a solution in a timely manner and prevent more users from +running into the issue; nevertheless developers need to take enough time and +care to ensure regression fixes do not cause additional damage. + +The answer thus depends on various factors like the impact of a regression, its +age, or the Linux series in which it occurs. In the end though, most regressions +should be fixed within two weeks. + +Is it a regression, if the issue can be avoided by updating some software? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Almost always: yes. If a developer tells you otherwise, ask the regression +tracker for advice as outlined above. + +Is it a regression, if a newer kernel works slower or consumes more energy? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Yes, but the difference has to be significant. A five percent slow-down in a +micro-benchmark thus is unlikely to qualify as regression, unless it also +influences the results of a broad benchmark by more than one percent. If in +doubt, ask for advice. + +Is it a regression, if an external kernel module breaks when updating Linux? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +No, as the "no regression" rule is about interfaces and services the Linux +kernel provides to the userland. It thus does not cover building or running +externally developed kernel modules, as they run in kernel-space and hook into +the kernel using internal interfaces occasionally changed. + +How are regressions handled that are caused by security fixes? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +In extremely rare situations security issues can't be fixed without causing +regressions; those fixes are given way, as they are the lesser evil in the end. +Luckily this middling almost always can be avoided, as key developers for the +affected area and often Linus Torvalds himself try very hard to fix security +issues without causing regressions. + +If you nevertheless face such a case, check the mailing list archives if people +tried their best to avoid the regression. If not, report it; if in doubt, ask +for advice as outlined above. + +What happens if fixing a regression is impossible without causing another? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Sadly these things happen, but luckily not very often; if they occur, expert +developers of the affected code area should look into the issue to find a fix +that avoids regressions or at least their impact. If you run into such a +situation, do what was outlined already for regressions caused by security +fixes: check earlier discussions if people already tried their best and ask for +advice if in doubt. + +A quick note while at it: these situations could be avoided, if people would +regularly give mainline pre-releases (say v5.15-rc1 or -rc3) from each +development cycle a test run. This is best explained by imagining a change +integrated between Linux v5.14 and v5.15-rc1 which causes a regression, but at +the same time is a hard requirement for some other improvement applied for +5.15-rc1. All these changes often can simply be reverted and the regression thus +solved, if someone finds and reports it before 5.15 is released. A few days or +weeks later this solution can become impossible, as some software might have +started to rely on aspects introduced by one of the follow-up changes: reverting +all changes would then cause a regression for users of said software and thus is +out of the question. + +Is it a regression, if some feature I relied on was removed months ago? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It is, but often it's hard to fix such regressions due to the aspects outlined +in the previous section. It hence needs to be dealt with on a case-by-case +basis. This is another reason why it's in everybody's interest to regularly test +mainline pre-releases. + +Does the "no regression" rule apply if I seem to be the only affected person? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +It does, but only for practical usage: the Linux developers want to be free to +remove support for hardware only to be found in attics and museums anymore. + +Note, sometimes regressions can't be avoided to make progress -- and the latter +is needed to prevent Linux from stagnation. Hence, if only very few users seem +to be affected by a regression, it for the greater good might be in their and +everyone else's interest to lettings things pass. Especially if there is an +easy way to circumvent the regression somehow, for example by updating some +software or using a kernel parameter created just for this purpose. + +Does the regression rule apply for code in the staging tree as well? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Not according to the `help text for the configuration option covering all +staging code <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/staging/Kconfig>`_, +which since its early days states:: + + Please note that these drivers are under heavy development, may or + may not work, and may contain userspace interfaces that most likely + will be changed in the near future. + +The staging developers nevertheless often adhere to the "no regressions" rule, +but sometimes bend it to make progress. That's for example why some users had to +deal with (often negligible) regressions when a WiFi driver from the staging +tree was replaced by a totally different one written from scratch. + +Why do later versions have to be "compiled with a similar configuration"? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Because the Linux kernel developers sometimes integrate changes known to cause +regressions, but make them optional and disable them in the kernel's default +configuration. This trick allows progress, as the "no regressions" rule +otherwise would lead to stagnation. + +Consider for example a new security feature blocking access to some kernel +interfaces often abused by malware, which at the same time are required to run a +few rarely used applications. The outlined approach makes both camps happy: +people using these applications can leave the new security feature off, while +everyone else can enable it without running into trouble. + +How to create a configuration similar to the one of an older kernel? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Start your machine with a known-good kernel and configure the newer Linux +version with ``make olddefconfig``. This makes the kernel's build scripts pick +up the configuration file (the ".config" file) from the running kernel as base +for the new one you are about to compile; afterwards they set all new +configuration options to their default value, which should disable new features +that might cause regressions. + +Can I report a regression I found with pre-compiled vanilla kernels? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You need to ensure the newer kernel was compiled with a similar configuration +file as the older one (see above), as those that built them might have enabled +some known-to-be incompatible feature for the newer kernel. If in doubt, report +the matter to the kernel's provider and ask for advice. + + +More about regression tracking with "regzbot" +--------------------------------------------- + +What is regression tracking and why should I care about it? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rules like "no regressions" need someone to ensure they are followed, otherwise +they are broken either accidentally or on purpose. History has shown this to be +true for Linux kernel development as well. That's why Thorsten Leemhuis, the +Linux Kernel's regression tracker, and some people try to ensure all regression +are fixed by keeping an eye on them until they are resolved. Neither of them are +paid for this, that's why the work is done on a best effort basis. + +Why and how are Linux kernel regressions tracked using a bot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Tracking regressions completely manually has proven to be quite hard due to the +distributed and loosely structured nature of Linux kernel development process. +That's why the Linux kernel's regression tracker developed regzbot to facilitate +the work, with the long term goal to automate regression tracking as much as +possible for everyone involved. + +Regzbot works by watching for replies to reports of tracked regressions. +Additionally, it's looking out for posted or committed patches referencing such +reports with "Link:" tags; replies to such patch postings are tracked as well. +Combined this data provides good insights into the current state of the fixing +process. + +How to see which regressions regzbot tracks currently? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check out `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_. + +What kind of issues are supposed to be tracked by regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot is meant to track regressions, hence please don't involve regzbot for +regular issues. But it's okay for the Linux kernel's regression tracker if you +involve regzbot to track severe issues, like reports about hangs, corrupted +data, or internal errors (Panic, Oops, BUG(), warning, ...). + +How to change aspects of a tracked regression? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By using a 'regzbot command' in a direct or indirect reply to the mail with the +report. The easiest way to do that: find the report in your "Sent" folder or the +mailing list archive and reply to it using your mailer's "Reply-all" function. +In that mail, use one of the following commands in a stand-alone paragraph (IOW: +use blank lines to separate one or multiple of these commands from the rest of +the mail's text). + + * Update when the regression started to happen, for example after performing a + bisection:: + + #regzbot introduced: 1f2e3d4c5d + + * Set or update the title:: + + #regzbot title: foo + + * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of + the issue or a fix are discussed::: + + #regzbot monitor: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + #regzbot monitor: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Point to a place with further details of interest, like a mailing list post + or a ticket in a bug tracker that are slightly related, but about a different + topic:: + + #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Mark a regression as invalid:: + + #regzbot invalid: wasn't a regression, problem has always existed + +Regzbot supports a few other commands primarily used by developers or people +tracking regressions. They and more details about the aforementioned regzbot +commands can be found in the `getting started guide +<https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ and +the `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ +for regzbot. + +.. + end-of-content +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/admin-guide/reporting-regressions.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/admin-guide/sysctl/kernel.rst b/Documentation/admin-guide/sysctl/kernel.rst index d359bcfadd39..1144ea3229a3 100644 --- a/Documentation/admin-guide/sysctl/kernel.rst +++ b/Documentation/admin-guide/sysctl/kernel.rst @@ -595,65 +595,33 @@ Documentation/admin-guide/kernel-parameters.rst). numa_balancing ============== -Enables/disables automatic page fault based NUMA memory -balancing. Memory is moved automatically to nodes -that access it often. +Enables/disables and configures automatic page fault based NUMA memory +balancing. Memory is moved automatically to nodes that access it often. +The value to set can be the result of ORing the following: -Enables/disables automatic NUMA memory balancing. On NUMA machines, there -is a performance penalty if remote memory is accessed by a CPU. When this -feature is enabled the kernel samples what task thread is accessing memory -by periodically unmapping pages and later trapping a page fault. At the -time of the page fault, it is determined if the data being accessed should -be migrated to a local memory node. += ================================= +0 NUMA_BALANCING_DISABLED +1 NUMA_BALANCING_NORMAL +2 NUMA_BALANCING_MEMORY_TIERING += ================================= + +Or NUMA_BALANCING_NORMAL to optimize page placement among different +NUMA nodes to reduce remote accessing. On NUMA machines, there is a +performance penalty if remote memory is accessed by a CPU. When this +feature is enabled the kernel samples what task thread is accessing +memory by periodically unmapping pages and later trapping a page +fault. At the time of the page fault, it is determined if the data +being accessed should be migrated to a local memory node. The unmapping of pages and trapping faults incur additional overhead that ideally is offset by improved memory locality but there is no universal guarantee. If the target workload is already bound to NUMA nodes then this -feature should be disabled. Otherwise, if the system overhead from the -feature is too high then the rate the kernel samples for NUMA hinting -faults may be controlled by the `numa_balancing_scan_period_min_ms, -numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, -numa_balancing_scan_size_mb`_, and numa_balancing_settle_count sysctls. - - -numa_balancing_scan_period_min_ms, numa_balancing_scan_delay_ms, numa_balancing_scan_period_max_ms, numa_balancing_scan_size_mb -=============================================================================================================================== - - -Automatic NUMA balancing scans tasks address space and unmaps pages to -detect if pages are properly placed or if the data should be migrated to a -memory node local to where the task is running. Every "scan delay" the task -scans the next "scan size" number of pages in its address space. When the -end of the address space is reached the scanner restarts from the beginning. - -In combination, the "scan delay" and "scan size" determine the scan rate. -When "scan delay" decreases, the scan rate increases. The scan delay and -hence the scan rate of every task is adaptive and depends on historical -behaviour. If pages are properly placed then the scan delay increases, -otherwise the scan delay decreases. The "scan size" is not adaptive but -the higher the "scan size", the higher the scan rate. - -Higher scan rates incur higher system overhead as page faults must be -trapped and potentially data must be migrated. However, the higher the scan -rate, the more quickly a tasks memory is migrated to a local node if the -workload pattern changes and minimises performance impact due to remote -memory accesses. These sysctls control the thresholds for scan delays and -the number of pages scanned. - -``numa_balancing_scan_period_min_ms`` is the minimum time in milliseconds to -scan a tasks virtual memory. It effectively controls the maximum scanning -rate for each task. - -``numa_balancing_scan_delay_ms`` is the starting "scan delay" used for a task -when it initially forks. - -``numa_balancing_scan_period_max_ms`` is the maximum time in milliseconds to -scan a tasks virtual memory. It effectively controls the minimum scanning -rate for each task. - -``numa_balancing_scan_size_mb`` is how many megabytes worth of pages are -scanned for a given scan. +feature should be disabled. +Or NUMA_BALANCING_MEMORY_TIERING to optimize page placement among +different types of memory (represented as different NUMA nodes) to +place the hot pages in the fast memory. This is implemented based on +unmapping and page fault too. oops_all_cpu_backtrace ====================== @@ -795,6 +763,8 @@ bit 1 print system memory info bit 2 print timer info bit 3 print locks info if ``CONFIG_LOCKDEP`` is on bit 4 print ftrace buffer +bit 5 print all printk messages in buffer +bit 6 print all CPUs backtrace (if available in the arch) ===== ============================================ So for example to print tasks and memory info on panic, user can:: @@ -1029,23 +999,17 @@ This is a directory, with the following entries: * ``poolsize``: the entropy pool size, in bits; * ``urandom_min_reseed_secs``: obsolete (used to determine the minimum - number of seconds between urandom pool reseeding). + number of seconds between urandom pool reseeding). This file is + writable for compatibility purposes, but writing to it has no effect + on any RNG behavior. * ``uuid``: a UUID generated every time this is retrieved (this can thus be used to generate UUIDs at will); * ``write_wakeup_threshold``: when the entropy count drops below this (as a number of bits), processes waiting to write to ``/dev/random`` - are woken up. - -If ``drivers/char/random.c`` is built with ``ADD_INTERRUPT_BENCH`` -defined, these additional entries are present: - -* ``add_interrupt_avg_cycles``: the average number of cycles between - interrupts used to feed the pool; - -* ``add_interrupt_avg_deviation``: the standard deviation seen on the - number of cycles between interrupts used to feed the pool. + are woken up. This file is writable for compatibility purposes, but + writing to it has no effect on any RNG behavior. randomize_va_space diff --git a/Documentation/admin-guide/sysctl/net.rst b/Documentation/admin-guide/sysctl/net.rst index 4150f74c521a..f86b5e1623c6 100644 --- a/Documentation/admin-guide/sysctl/net.rst +++ b/Documentation/admin-guide/sysctl/net.rst @@ -365,6 +365,15 @@ new netns has been created. Default : 0 (for compatibility reasons) +txrehash +-------- + +Controls default hash rethink behaviour on listening socket when SO_TXREHASH +option is set to SOCK_TXREHASH_DEFAULT (i. e. not overridden by setsockopt). + +If set to 1 (default), hash rethink is performed on listening socket. +If set to 0, hash rethink is not performed. + 2. /proc/sys/net/unix - Parameters for Unix domain sockets ---------------------------------------------------------- diff --git a/Documentation/arm/marvell.rst b/Documentation/arm/marvell.rst index 9485a5a2e2e9..2f41caa0096c 100644 --- a/Documentation/arm/marvell.rst +++ b/Documentation/arm/marvell.rst @@ -266,10 +266,12 @@ Avanta family ------------- Flavors: + - 88F6500 - 88F6510 - 88F6530P - 88F6550 - 88F6560 + - 88F6601 Homepage: https://web.archive.org/web/20181005145041/http://www.marvell.com/broadband/ diff --git a/Documentation/arm64/booting.rst b/Documentation/arm64/booting.rst index 52d060caf8bb..29884b261aa9 100644 --- a/Documentation/arm64/booting.rst +++ b/Documentation/arm64/booting.rst @@ -10,9 +10,9 @@ This document is based on the ARM booting document by Russell King and is relevant to all public releases of the AArch64 Linux kernel. The AArch64 exception model is made up of a number of exception levels -(EL0 - EL3), with EL0 and EL1 having a secure and a non-secure -counterpart. EL2 is the hypervisor level and exists only in non-secure -mode. EL3 is the highest priority level and exists only in secure mode. +(EL0 - EL3), with EL0, EL1 and EL2 having a secure and a non-secure +counterpart. EL2 is the hypervisor level, EL3 is the highest priority +level and exists only in secure mode. Both are architecturally optional. For the purposes of this document, we will use the term `boot loader` simply to define all software that executes on the CPU(s) before control @@ -167,8 +167,8 @@ Before jumping into the kernel, the following conditions must be met: All forms of interrupts must be masked in PSTATE.DAIF (Debug, SError, IRQ and FIQ). - The CPU must be in either EL2 (RECOMMENDED in order to have access to - the virtualisation extensions) or non-secure EL1. + The CPU must be in non-secure state, either in EL2 (RECOMMENDED in order + to have access to the virtualisation extensions), or in EL1. - Caches, MMUs diff --git a/Documentation/arm64/elf_hwcaps.rst b/Documentation/arm64/elf_hwcaps.rst index b72ff17d600a..a8f30963e550 100644 --- a/Documentation/arm64/elf_hwcaps.rst +++ b/Documentation/arm64/elf_hwcaps.rst @@ -259,6 +259,11 @@ HWCAP2_RPRES Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001. +HWCAP2_MTE3 + + Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0011, as described + by Documentation/arm64/memory-tagging-extension.rst. + 4. Unused AT_HWCAP bits ----------------------- diff --git a/Documentation/arm64/memory-tagging-extension.rst b/Documentation/arm64/memory-tagging-extension.rst index 7b99c8f428eb..dd27f78d7608 100644 --- a/Documentation/arm64/memory-tagging-extension.rst +++ b/Documentation/arm64/memory-tagging-extension.rst @@ -76,6 +76,9 @@ configurable behaviours: with ``.si_code = SEGV_MTEAERR`` and ``.si_addr = 0`` (the faulting address is unknown). +- *Asymmetric* - Reads are handled as for synchronous mode while writes + are handled as for asynchronous mode. + The user can select the above modes, per thread, using the ``prctl(PR_SET_TAGGED_ADDR_CTRL, flags, 0, 0, 0)`` system call where ``flags`` contains any number of the following values in the ``PR_MTE_TCF_MASK`` @@ -91,8 +94,9 @@ mode is specified, the program will run in that mode. If multiple modes are specified, the mode is selected as described in the "Per-CPU preferred tag checking modes" section below. -The current tag check fault mode can be read using the -``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. +The current tag check fault configuration can be read using the +``prctl(PR_GET_TAGGED_ADDR_CTRL, 0, 0, 0, 0)`` system call. If +multiple modes were requested then all will be reported. Tag checking can also be disabled for a user thread by setting the ``PSTATE.TCO`` bit with ``MSR TCO, #1``. @@ -139,18 +143,25 @@ tag checking mode as the CPU's preferred tag checking mode. The preferred tag checking mode for each CPU is controlled by ``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a -privileged user may write the value ``async`` or ``sync``. The default -preferred mode for each CPU is ``async``. +privileged user may write the value ``async``, ``sync`` or ``asymm``. The +default preferred mode for each CPU is ``async``. To allow a program to potentially run in the CPU's preferred tag checking mode, the user program may set multiple tag check fault mode bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL, -flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking -mode is in the task's set of provided tag checking modes (this will -always be the case at present because the kernel only supports two -tag checking modes, but future kernels may support more modes), that -mode will be selected. Otherwise, one of the modes in the task's mode -set will be selected in a currently unspecified manner. +flags, 0, 0, 0)`` system call. If both synchronous and asynchronous +modes are requested then asymmetric mode may also be selected by the +kernel. If the CPU's preferred tag checking mode is in the task's set +of provided tag checking modes, that mode will be selected. Otherwise, +one of the modes in the task's mode will be selected by the kernel +from the task's mode set using the preference order: + + 1. Asynchronous + 2. Asymmetric + 3. Synchronous + +Note that there is no way for userspace to request multiple modes and +also disable asymmetric mode. Initial process state --------------------- @@ -213,6 +224,29 @@ address ABI control and MTE configuration of a process as per the Documentation/arm64/tagged-address-abi.rst and above. The corresponding ``regset`` is 1 element of 8 bytes (``sizeof(long))``). +Core dump support +----------------- + +The allocation tags for user memory mapped with ``PROT_MTE`` are dumped +in the core file as additional ``PT_ARM_MEMTAG_MTE`` segments. The +program header for such segment is defined as: + +:``p_type``: ``PT_ARM_MEMTAG_MTE`` +:``p_flags``: 0 +:``p_offset``: segment file offset +:``p_vaddr``: segment virtual address, same as the corresponding + ``PT_LOAD`` segment +:``p_paddr``: 0 +:``p_filesz``: segment size in file, calculated as ``p_mem_sz / 32`` + (two 4-bit tags cover 32 bytes of memory) +:``p_memsz``: segment size in memory, same as the corresponding + ``PT_LOAD`` segment +:``p_align``: 0 + +The tags are stored in the core file at ``p_offset`` as two 4-bit tags +in a byte. With the tag granule of 16 bytes, a 4K page requires 128 +bytes in the core file. + Example of correct usage ======================== diff --git a/Documentation/arm64/silicon-errata.rst b/Documentation/arm64/silicon-errata.rst index 5342e895fb60..466cb9e89047 100644 --- a/Documentation/arm64/silicon-errata.rst +++ b/Documentation/arm64/silicon-errata.rst @@ -52,6 +52,12 @@ stable kernels. | Allwinner | A64/R18 | UNKNOWN1 | SUN50I_ERRATUM_UNKNOWN1 | +----------------+-----------------+-----------------+-----------------------------+ +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2064142 | ARM64_ERRATUM_2064142 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2038923 | ARM64_ERRATUM_2038923 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #1902691 | ARM64_ERRATUM_1902691 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #826319 | ARM64_ERRATUM_826319 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A53 | #827319 | ARM64_ERRATUM_827319 | @@ -92,12 +98,20 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A77 | #1508412 | ARM64_ERRATUM_1508412 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2051678 | ARM64_ERRATUM_2051678 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-A510 | #2077057 | ARM64_ERRATUM_2077057 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2119858 | ARM64_ERRATUM_2119858 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2054223 | ARM64_ERRATUM_2054223 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Cortex-A710 | #2224489 | ARM64_ERRATUM_2224489 | +----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X2 | #2119858 | ARM64_ERRATUM_2119858 | ++----------------+-----------------+-----------------+-----------------------------+ +| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 | ++----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 | +----------------+-----------------+-----------------+-----------------------------+ | ARM | Neoverse-N1 | #1349291 | N/A | @@ -122,7 +136,7 @@ stable kernels. +----------------+-----------------+-----------------+-----------------------------+ | Cavium | ThunderX ITS | #23144 | CAVIUM_ERRATUM_23144 | +----------------+-----------------+-----------------+-----------------------------+ -| Cavium | ThunderX GICv3 | #23154 | CAVIUM_ERRATUM_23154 | +| Cavium | ThunderX GICv3 | #23154,38545 | CAVIUM_ERRATUM_23154 | +----------------+-----------------+-----------------+-----------------------------+ | Cavium | ThunderX GICv3 | #38539 | N/A | +----------------+-----------------+-----------------+-----------------------------+ diff --git a/Documentation/asm-annotations.rst b/Documentation/asm-annotations.rst index f4bf0f6395fb..a64f2ca469d4 100644 --- a/Documentation/asm-annotations.rst +++ b/Documentation/asm-annotations.rst @@ -130,14 +130,13 @@ denoting a range of code via ``SYM_*_START/END`` annotations. In fact, this kind of annotation corresponds to the now deprecated ``ENTRY`` and ``ENDPROC`` macros. -* ``SYM_FUNC_START_ALIAS`` and ``SYM_FUNC_START_LOCAL_ALIAS`` serve for those - who decided to have two or more names for one function. The typical use is:: +* ``SYM_FUNC_ALIAS``, ``SYM_FUNC_ALIAS_LOCAL``, and ``SYM_FUNC_ALIAS_WEAK`` can + be used to define multiple names for a function. The typical use is:: - SYM_FUNC_START_ALIAS(__memset) - SYM_FUNC_START(memset) + SYM_FUNC_START(__memset) ... asm insns ... - SYM_FUNC_END(memset) - SYM_FUNC_END_ALIAS(__memset) + SYN_FUNC_END(__memset) + SYM_FUNC_ALIAS(memset, __memset) In this example, one can call ``__memset`` or ``memset`` with the same result, except the debug information for the instructions is generated to diff --git a/Documentation/block/biodoc.rst b/Documentation/block/biodoc.rst deleted file mode 100644 index 2098477851a4..000000000000 --- a/Documentation/block/biodoc.rst +++ /dev/null @@ -1,1164 +0,0 @@ -===================================================== -Notes on the Generic Block Layer Rewrite in Linux 2.5 -===================================================== - -.. note:: - - It seems that there are lot of outdated stuff here. This seems - to be written somewhat as a task list. Yet, eventually, something - here might still be useful. - -Notes Written on Jan 15, 2002: - - - Jens Axboe <jens.axboe@oracle.com> - - Suparna Bhattacharya <suparna@in.ibm.com> - -Last Updated May 2, 2002 - -September 2003: Updated I/O Scheduler portions - - Nick Piggin <npiggin@kernel.dk> - -Introduction -============ - -These are some notes describing some aspects of the 2.5 block layer in the -context of the bio rewrite. The idea is to bring out some of the key -changes and a glimpse of the rationale behind those changes. - -Please mail corrections & suggestions to suparna@in.ibm.com. - -Credits -======= - -2.5 bio rewrite: - - Jens Axboe <jens.axboe@oracle.com> - -Many aspects of the generic block layer redesign were driven by and evolved -over discussions, prior patches and the collective experience of several -people. See sections 8 and 9 for a list of some related references. - -The following people helped with review comments and inputs for this -document: - - - Christoph Hellwig <hch@infradead.org> - - Arjan van de Ven <arjanv@redhat.com> - - Randy Dunlap <rdunlap@xenotime.net> - - Andre Hedrick <andre@linux-ide.org> - -The following people helped with fixes/contributions to the bio patches -while it was still work-in-progress: - - - David S. Miller <davem@redhat.com> - - -.. Description of Contents: - - 1. Scope for tuning of logic to various needs - 1.1 Tuning based on device or low level driver capabilities - - Per-queue parameters - - Highmem I/O support - - I/O scheduler modularization - 1.2 Tuning based on high level requirements/capabilities - 1.2.1 Request Priority/Latency - 1.3 Direct access/bypass to lower layers for diagnostics and special - device operations - 1.3.1 Pre-built commands - 2. New flexible and generic but minimalist i/o structure or descriptor - (instead of using buffer heads at the i/o layer) - 2.1 Requirements/Goals addressed - 2.2 The bio struct in detail (multi-page io unit) - 2.3 Changes in the request structure - 3. Using bios - 3.1 Setup/teardown (allocation, splitting) - 3.2 Generic bio helper routines - 3.2.1 Traversing segments and completion units in a request - 3.2.2 Setting up DMA scatterlists - 3.2.3 I/O completion - 3.2.4 Implications for drivers that do not interpret bios (don't handle - multiple segments) - 3.3 I/O submission - 4. The I/O scheduler - 5. Scalability related changes - 5.1 Granular locking: Removal of io_request_lock - 5.2 Prepare for transition to 64 bit sector_t - 6. Other Changes/Implications - 6.1 Partition re-mapping handled by the generic block layer - 7. A few tips on migration of older drivers - 8. A list of prior/related/impacted patches/ideas - 9. Other References/Discussion Threads - - -Bio Notes -========= - -Let us discuss the changes in the context of how some overall goals for the -block layer are addressed. - -1. Scope for tuning the generic logic to satisfy various requirements -===================================================================== - -The block layer design supports adaptable abstractions to handle common -processing with the ability to tune the logic to an appropriate extent -depending on the nature of the device and the requirements of the caller. -One of the objectives of the rewrite was to increase the degree of tunability -and to enable higher level code to utilize underlying device/driver -capabilities to the maximum extent for better i/o performance. This is -important especially in the light of ever improving hardware capabilities -and application/middleware software designed to take advantage of these -capabilities. - -1.1 Tuning based on low level device / driver capabilities ----------------------------------------------------------- - -Sophisticated devices with large built-in caches, intelligent i/o scheduling -optimizations, high memory DMA support, etc may find some of the -generic processing an overhead, while for less capable devices the -generic functionality is essential for performance or correctness reasons. -Knowledge of some of the capabilities or parameters of the device should be -used at the generic block layer to take the right decisions on -behalf of the driver. - -How is this achieved ? - -Tuning at a per-queue level: - -i. Per-queue limits/values exported to the generic layer by the driver - -Various parameters that the generic i/o scheduler logic uses are set at -a per-queue level (e.g maximum request size, maximum number of segments in -a scatter-gather list, logical block size) - -Some parameters that were earlier available as global arrays indexed by -major/minor are now directly associated with the queue. Some of these may -move into the block device structure in the future. Some characteristics -have been incorporated into a queue flags field rather than separate fields -in themselves. There are blk_queue_xxx functions to set the parameters, -rather than update the fields directly - -Some new queue property settings: - - blk_queue_bounce_limit(q, u64 dma_address) - Enable I/O to highmem pages, dma_address being the - limit. No highmem default. - - blk_queue_max_sectors(q, max_sectors) - Sets two variables that limit the size of the request. - - - The request queue's max_sectors, which is a soft size in - units of 512 byte sectors, and could be dynamically varied - by the core kernel. - - - The request queue's max_hw_sectors, which is a hard limit - and reflects the maximum size request a driver can handle - in units of 512 byte sectors. - - The default for both max_sectors and max_hw_sectors is - 255. The upper limit of max_sectors is 1024. - - blk_queue_max_phys_segments(q, max_segments) - Maximum physical segments you can handle in a request. 128 - default (driver limit). (See 3.2.2) - - blk_queue_max_hw_segments(q, max_segments) - Maximum dma segments the hardware can handle in a request. 128 - default (host adapter limit, after dma remapping). - (See 3.2.2) - - blk_queue_max_segment_size(q, max_seg_size) - Maximum size of a clustered segment, 64kB default. - - blk_queue_logical_block_size(q, logical_block_size) - Lowest possible sector size that the hardware can operate - on, 512 bytes default. - -New queue flags: - - - QUEUE_FLAG_CLUSTER (see 3.2.2) - - QUEUE_FLAG_QUEUED (see 3.2.4) - - -ii. High-mem i/o capabilities are now considered the default - -The generic bounce buffer logic, present in 2.4, where the block layer would -by default copyin/out i/o requests on high-memory buffers to low-memory buffers -assuming that the driver wouldn't be able to handle it directly, has been -changed in 2.5. The bounce logic is now applied only for memory ranges -for which the device cannot handle i/o. A driver can specify this by -setting the queue bounce limit for the request queue for the device -(blk_queue_bounce_limit()). This avoids the inefficiencies of the copyin/out -where a device is capable of handling high memory i/o. - -In order to enable high-memory i/o where the device is capable of supporting -it, the pci dma mapping routines and associated data structures have now been -modified to accomplish a direct page -> bus translation, without requiring -a virtual address mapping (unlike the earlier scheme of virtual address --> bus translation). So this works uniformly for high-memory pages (which -do not have a corresponding kernel virtual address space mapping) and -low-memory pages. - -Note: Please refer to Documentation/core-api/dma-api-howto.rst for a discussion -on PCI high mem DMA aspects and mapping of scatter gather lists, and support -for 64 bit PCI. - -Special handling is required only for cases where i/o needs to happen on -pages at physical memory addresses beyond what the device can support. In these -cases, a bounce bio representing a buffer from the supported memory range -is used for performing the i/o with copyin/copyout as needed depending on -the type of the operation. For example, in case of a read operation, the -data read has to be copied to the original buffer on i/o completion, so a -callback routine is set up to do this, while for write, the data is copied -from the original buffer to the bounce buffer prior to issuing the -operation. Since an original buffer may be in a high memory area that's not -mapped in kernel virtual addr, a kmap operation may be required for -performing the copy, and special care may be needed in the completion path -as it may not be in irq context. Special care is also required (by way of -GFP flags) when allocating bounce buffers, to avoid certain highmem -deadlock possibilities. - -It is also possible that a bounce buffer may be allocated from high-memory -area that's not mapped in kernel virtual addr, but within the range that the -device can use directly; so the bounce page may need to be kmapped during -copy operations. [Note: This does not hold in the current implementation, -though] - -There are some situations when pages from high memory may need to -be kmapped, even if bounce buffers are not necessary. For example a device -may need to abort DMA operations and revert to PIO for the transfer, in -which case a virtual mapping of the page is required. For SCSI it is also -done in some scenarios where the low level driver cannot be trusted to -handle a single sg entry correctly. The driver is expected to perform the -kmaps as needed on such occasions as appropriate. A driver could also use -the blk_queue_bounce() routine on its own to bounce highmem i/o to low -memory for specific requests if so desired. - -iii. The i/o scheduler algorithm itself can be replaced/set as appropriate - -As in 2.4, it is possible to plugin a brand new i/o scheduler for a particular -queue or pick from (copy) existing generic schedulers and replace/override -certain portions of it. The 2.5 rewrite provides improved modularization -of the i/o scheduler. There are more pluggable callbacks, e.g for init, -add request, extract request, which makes it possible to abstract specific -i/o scheduling algorithm aspects and details outside of the generic loop. -It also makes it possible to completely hide the implementation details of -the i/o scheduler from block drivers. - -I/O scheduler wrappers are to be used instead of accessing the queue directly. -See section 4. The I/O scheduler for details. - -1.2 Tuning Based on High level code capabilities ------------------------------------------------- - -i. Application capabilities for raw i/o - -This comes from some of the high-performance database/middleware -requirements where an application prefers to make its own i/o scheduling -decisions based on an understanding of the access patterns and i/o -characteristics - -ii. High performance filesystems or other higher level kernel code's -capabilities - -Kernel components like filesystems could also take their own i/o scheduling -decisions for optimizing performance. Journalling filesystems may need -some control over i/o ordering. - -What kind of support exists at the generic block layer for this ? - -The flags and rw fields in the bio structure can be used for some tuning -from above e.g indicating that an i/o is just a readahead request, or priority -settings (currently unused). As far as user applications are concerned they -would need an additional mechanism either via open flags or ioctls, or some -other upper level mechanism to communicate such settings to block. - -1.2.1 Request Priority/Latency -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -Todo/Under discussion:: - - Arjan's proposed request priority scheme allows higher levels some broad - control (high/med/low) over the priority of an i/o request vs other pending - requests in the queue. For example it allows reads for bringing in an - executable page on demand to be given a higher priority over pending write - requests which haven't aged too much on the queue. Potentially this priority - could even be exposed to applications in some manner, providing higher level - tunability. Time based aging avoids starvation of lower priority - requests. Some bits in the bi_opf flags field in the bio structure are - intended to be used for this priority information. - - -1.3 Direct Access to Low level Device/Driver Capabilities (Bypass mode) ------------------------------------------------------------------------ - -(e.g Diagnostics, Systems Management) - -There are situations where high-level code needs to have direct access to -the low level device capabilities or requires the ability to issue commands -to the device bypassing some of the intermediate i/o layers. -These could, for example, be special control commands issued through ioctl -interfaces, or could be raw read/write commands that stress the drive's -capabilities for certain kinds of fitness tests. Having direct interfaces at -multiple levels without having to pass through upper layers makes -it possible to perform bottom up validation of the i/o path, layer by -layer, starting from the media. - -The normal i/o submission interfaces, e.g submit_bio, could be bypassed -for specially crafted requests which such ioctl or diagnostics -interfaces would typically use, and the elevator add_request routine -can instead be used to directly insert such requests in the queue or preferably -the blk_do_rq routine can be used to place the request on the queue and -wait for completion. Alternatively, sometimes the caller might just -invoke a lower level driver specific interface with the request as a -parameter. - -If the request is a means for passing on special information associated with -the command, then such information is associated with the request->special -field (rather than misuse the request->buffer field which is meant for the -request data buffer's virtual mapping). - -For passing request data, the caller must build up a bio descriptor -representing the concerned memory buffer if the underlying driver interprets -bio segments or uses the block layer end*request* functions for i/o -completion. Alternatively one could directly use the request->buffer field to -specify the virtual address of the buffer, if the driver expects buffer -addresses passed in this way and ignores bio entries for the request type -involved. In the latter case, the driver would modify and manage the -request->buffer, request->sector and request->nr_sectors or -request->current_nr_sectors fields itself rather than using the block layer -end_request or end_that_request_first completion interfaces. -(See 2.3 or Documentation/block/request.rst for a brief explanation of -the request structure fields) - -:: - - [TBD: end_that_request_last should be usable even in this case; - Perhaps an end_that_direct_request_first routine could be implemented to make - handling direct requests easier for such drivers; Also for drivers that - expect bios, a helper function could be provided for setting up a bio - corresponding to a data buffer] - - <JENS: I dont understand the above, why is end_that_request_first() not - usable? Or _last for that matter. I must be missing something> - - <SUP: What I meant here was that if the request doesn't have a bio, then - end_that_request_first doesn't modify nr_sectors or current_nr_sectors, - and hence can't be used for advancing request state settings on the - completion of partial transfers. The driver has to modify these fields - directly by hand. - This is because end_that_request_first only iterates over the bio list, - and always returns 0 if there are none associated with the request. - _last works OK in this case, and is not a problem, as I mentioned earlier - > - -1.3.1 Pre-built Commands -^^^^^^^^^^^^^^^^^^^^^^^^ - -A request can be created with a pre-built custom command to be sent directly -to the device. The cmd block in the request structure has room for filling -in the command bytes. (i.e rq->cmd is now 16 bytes in size, and meant for -command pre-building, and the type of the request is now indicated -through rq->flags instead of via rq->cmd) - -The request structure flags can be set up to indicate the type of request -in such cases (REQ_PC: direct packet command passed to driver, REQ_BLOCK_PC: -packet command issued via blk_do_rq, REQ_SPECIAL: special request). - -It can help to pre-build device commands for requests in advance. -Drivers can now specify a request prepare function (q->prep_rq_fn) that the -block layer would invoke to pre-build device commands for a given request, -or perform other preparatory processing for the request. This is routine is -called by elv_next_request(), i.e. typically just before servicing a request. -(The prepare function would not be called for requests that have RQF_DONTPREP -enabled) - -Aside: - Pre-building could possibly even be done early, i.e before placing the - request on the queue, rather than construct the command on the fly in the - driver while servicing the request queue when it may affect latencies in - interrupt context or responsiveness in general. One way to add early - pre-building would be to do it whenever we fail to merge on a request. - Now REQ_NOMERGE is set in the request flags to skip this one in the future, - which means that it will not change before we feed it to the device. So - the pre-builder hook can be invoked there. - - -2. Flexible and generic but minimalist i/o structure/descriptor -=============================================================== - -2.1 Reason for a new structure and requirements addressed ---------------------------------------------------------- - -Prior to 2.5, buffer heads were used as the unit of i/o at the generic block -layer, and the low level request structure was associated with a chain of -buffer heads for a contiguous i/o request. This led to certain inefficiencies -when it came to large i/o requests and readv/writev style operations, as it -forced such requests to be broken up into small chunks before being passed -on to the generic block layer, only to be merged by the i/o scheduler -when the underlying device was capable of handling the i/o in one shot. -Also, using the buffer head as an i/o structure for i/os that didn't originate -from the buffer cache unnecessarily added to the weight of the descriptors -which were generated for each such chunk. - -The following were some of the goals and expectations considered in the -redesign of the block i/o data structure in 2.5. - -1. Should be appropriate as a descriptor for both raw and buffered i/o - - avoid cache related fields which are irrelevant in the direct/page i/o path, - or filesystem block size alignment restrictions which may not be relevant - for raw i/o. -2. Ability to represent high-memory buffers (which do not have a virtual - address mapping in kernel address space). -3. Ability to represent large i/os w/o unnecessarily breaking them up (i.e - greater than PAGE_SIZE chunks in one shot) -4. At the same time, ability to retain independent identity of i/os from - different sources or i/o units requiring individual completion (e.g. for - latency reasons) -5. Ability to represent an i/o involving multiple physical memory segments - (including non-page aligned page fragments, as specified via readv/writev) - without unnecessarily breaking it up, if the underlying device is capable of - handling it. -6. Preferably should be based on a memory descriptor structure that can be - passed around different types of subsystems or layers, maybe even - networking, without duplication or extra copies of data/descriptor fields - themselves in the process -7. Ability to handle the possibility of splits/merges as the structure passes - through layered drivers (lvm, md, evms), with minimal overhead. - -The solution was to define a new structure (bio) for the block layer, -instead of using the buffer head structure (bh) directly, the idea being -avoidance of some associated baggage and limitations. The bio structure -is uniformly used for all i/o at the block layer ; it forms a part of the -bh structure for buffered i/o, and in the case of raw/direct i/o kiobufs are -mapped to bio structures. - -2.2 The bio struct ------------------- - -The bio structure uses a vector representation pointing to an array of tuples -of <page, offset, len> to describe the i/o buffer, and has various other -fields describing i/o parameters and state that needs to be maintained for -performing the i/o. - -Notice that this representation means that a bio has no virtual address -mapping at all (unlike buffer heads). - -:: - - struct bio_vec { - struct page *bv_page; - unsigned short bv_len; - unsigned short bv_offset; - }; - - /* - * main unit of I/O for the block layer and lower layers (ie drivers) - */ - struct bio { - struct bio *bi_next; /* request queue link */ - struct block_device *bi_bdev; /* target device */ - unsigned long bi_flags; /* status, command, etc */ - unsigned long bi_opf; /* low bits: r/w, high: priority */ - - unsigned int bi_vcnt; /* how may bio_vec's */ - struct bvec_iter bi_iter; /* current index into bio_vec array */ - - unsigned int bi_size; /* total size in bytes */ - unsigned short bi_hw_segments; /* segments after DMA remapping */ - unsigned int bi_max; /* max bio_vecs we can hold - used as index into pool */ - struct bio_vec *bi_io_vec; /* the actual vec list */ - bio_end_io_t *bi_end_io; /* bi_end_io (bio) */ - atomic_t bi_cnt; /* pin count: free when it hits zero */ - void *bi_private; - }; - -With this multipage bio design: - -- Large i/os can be sent down in one go using a bio_vec list consisting - of an array of <page, offset, len> fragments (similar to the way fragments - are represented in the zero-copy network code) -- Splitting of an i/o request across multiple devices (as in the case of - lvm or raid) is achieved by cloning the bio (where the clone points to - the same bi_io_vec array, but with the index and size accordingly modified) -- A linked list of bios is used as before for unrelated merges [#]_ - this - avoids reallocs and makes independent completions easier to handle. -- Code that traverses the req list can find all the segments of a bio - by using rq_for_each_segment. This handles the fact that a request - has multiple bios, each of which can have multiple segments. -- Drivers which can't process a large bio in one shot can use the bi_iter - field to keep track of the next bio_vec entry to process. - (e.g a 1MB bio_vec needs to be handled in max 128kB chunks for IDE) - [TBD: Should preferably also have a bi_voffset and bi_vlen to avoid modifying - bi_offset an len fields] - -.. [#] - - unrelated merges -- a request ends up containing two or more bios that - didn't originate from the same place. - -bi_end_io() i/o callback gets called on i/o completion of the entire bio. - -At a lower level, drivers build a scatter gather list from the merged bios. -The scatter gather list is in the form of an array of <page, offset, len> -entries with their corresponding dma address mappings filled in at the -appropriate time. As an optimization, contiguous physical pages can be -covered by a single entry where <page> refers to the first page and <len> -covers the range of pages (up to 16 contiguous pages could be covered this -way). There is a helper routine (blk_rq_map_sg) which drivers can use to build -the sg list. - -Note: Right now the only user of bios with more than one page is ll_rw_kio, -which in turn means that only raw I/O uses it (direct i/o may not work -right now). The intent however is to enable clustering of pages etc to -become possible. The pagebuf abstraction layer from SGI also uses multi-page -bios, but that is currently not included in the stock development kernels. -The same is true of Andrew Morton's work-in-progress multipage bio writeout -and readahead patches. - -2.3 Changes in the Request Structure ------------------------------------- - -The request structure is the structure that gets passed down to low level -drivers. The block layer make_request function builds up a request structure, -places it on the queue and invokes the drivers request_fn. The driver makes -use of block layer helper routine elv_next_request to pull the next request -off the queue. Control or diagnostic functions might bypass block and directly -invoke underlying driver entry points passing in a specially constructed -request structure. - -Only some relevant fields (mainly those which changed or may be referred -to in some of the discussion here) are listed below, not necessarily in -the order in which they occur in the structure (see include/linux/blkdev.h) -Refer to Documentation/block/request.rst for details about all the request -structure fields and a quick reference about the layers which are -supposed to use or modify those fields:: - - struct request { - struct list_head queuelist; /* Not meant to be directly accessed by - the driver. - Used by q->elv_next_request_fn - rq->queue is gone - */ - . - . - unsigned char cmd[16]; /* prebuilt command data block */ - unsigned long flags; /* also includes earlier rq->cmd settings */ - . - . - sector_t sector; /* this field is now of type sector_t instead of int - preparation for 64 bit sectors */ - . - . - - /* Number of scatter-gather DMA addr+len pairs after - * physical address coalescing is performed. - */ - unsigned short nr_phys_segments; - - /* Number of scatter-gather addr+len pairs after - * physical and DMA remapping hardware coalescing is performed. - * This is the number of scatter-gather entries the driver - * will actually have to deal with after DMA mapping is done. - */ - unsigned short nr_hw_segments; - - /* Various sector counts */ - unsigned long nr_sectors; /* no. of sectors left: driver modifiable */ - unsigned long hard_nr_sectors; /* block internal copy of above */ - unsigned int current_nr_sectors; /* no. of sectors left in the - current segment:driver modifiable */ - unsigned long hard_cur_sectors; /* block internal copy of the above */ - . - . - int tag; /* command tag associated with request */ - void *special; /* same as before */ - char *buffer; /* valid only for low memory buffers up to - current_nr_sectors */ - . - . - struct bio *bio, *biotail; /* bio list instead of bh */ - struct request_list *rl; - } - -See the req_ops and req_flag_bits definitions for an explanation of the various -flags available. Some bits are used by the block layer or i/o scheduler. - -The behaviour of the various sector counts are almost the same as before, -except that since we have multi-segment bios, current_nr_sectors refers -to the numbers of sectors in the current segment being processed which could -be one of the many segments in the current bio (i.e i/o completion unit). -The nr_sectors value refers to the total number of sectors in the whole -request that remain to be transferred (no change). The purpose of the -hard_xxx values is for block to remember these counts every time it hands -over the request to the driver. These values are updated by block on -end_that_request_first, i.e. every time the driver completes a part of the -transfer and invokes block end*request helpers to mark this. The -driver should not modify these values. The block layer sets up the -nr_sectors and current_nr_sectors fields (based on the corresponding -hard_xxx values and the number of bytes transferred) and updates it on -every transfer that invokes end_that_request_first. It does the same for the -buffer, bio, bio->bi_iter fields too. - -The buffer field is just a virtual address mapping of the current segment -of the i/o buffer in cases where the buffer resides in low-memory. For high -memory i/o, this field is not valid and must not be used by drivers. - -Code that sets up its own request structures and passes them down to -a driver needs to be careful about interoperation with the block layer helper -functions which the driver uses. (Section 1.3) - -3. Using bios -============= - -3.1 Setup/Teardown ------------------- - -There are routines for managing the allocation, and reference counting, and -freeing of bios (bio_alloc, bio_get, bio_put). - -This makes use of Ingo Molnar's mempool implementation, which enables -subsystems like bio to maintain their own reserve memory pools for guaranteed -deadlock-free allocations during extreme VM load. For example, the VM -subsystem makes use of the block layer to writeout dirty pages in order to be -able to free up memory space, a case which needs careful handling. The -allocation logic draws from the preallocated emergency reserve in situations -where it cannot allocate through normal means. If the pool is empty and it -can wait, then it would trigger action that would help free up memory or -replenish the pool (without deadlocking) and wait for availability in the pool. -If it is in IRQ context, and hence not in a position to do this, allocation -could fail if the pool is empty. In general mempool always first tries to -perform allocation without having to wait, even if it means digging into the -pool as long it is not less that 50% full. - -On a free, memory is released to the pool or directly freed depending on -the current availability in the pool. The mempool interface lets the -subsystem specify the routines to be used for normal alloc and free. In the -case of bio, these routines make use of the standard slab allocator. - -The caller of bio_alloc is expected to taken certain steps to avoid -deadlocks, e.g. avoid trying to allocate more memory from the pool while -already holding memory obtained from the pool. - -:: - - [TBD: This is a potential issue, though a rare possibility - in the bounce bio allocation that happens in the current code, since - it ends up allocating a second bio from the same pool while - holding the original bio ] - -Memory allocated from the pool should be released back within a limited -amount of time (in the case of bio, that would be after the i/o is completed). -This ensures that if part of the pool has been used up, some work (in this -case i/o) must already be in progress and memory would be available when it -is over. If allocating from multiple pools in the same code path, the order -or hierarchy of allocation needs to be consistent, just the way one deals -with multiple locks. - -The bio_alloc routine also needs to allocate the bio_vec_list (bvec_alloc()) -for a non-clone bio. There are the 6 pools setup for different size biovecs, -so bio_alloc(gfp_mask, nr_iovecs) will allocate a vec_list of the -given size from these slabs. - -The bio_get() routine may be used to hold an extra reference on a bio prior -to i/o submission, if the bio fields are likely to be accessed after the -i/o is issued (since the bio may otherwise get freed in case i/o completion -happens in the meantime). - -The bio_clone_fast() routine may be used to duplicate a bio, where the clone -shares the bio_vec_list with the original bio (i.e. both point to the -same bio_vec_list). This would typically be used for splitting i/o requests -in lvm or md. - -3.2 Generic bio helper Routines -------------------------------- - -3.2.1 Traversing segments and completion units in a request -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The macro rq_for_each_segment() should be used for traversing the bios -in the request list (drivers should avoid directly trying to do it -themselves). Using these helpers should also make it easier to cope -with block changes in the future. - -:: - - struct req_iterator iter; - rq_for_each_segment(bio_vec, rq, iter) - /* bio_vec is now current segment */ - -I/O completion callbacks are per-bio rather than per-segment, so drivers -that traverse bio chains on completion need to keep that in mind. Drivers -which don't make a distinction between segments and completion units would -need to be reorganized to support multi-segment bios. - -3.2.2 Setting up DMA scatterlists -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -The blk_rq_map_sg() helper routine would be used for setting up scatter -gather lists from a request, so a driver need not do it on its own. - - nr_segments = blk_rq_map_sg(q, rq, scatterlist); - -The helper routine provides a level of abstraction which makes it easier -to modify the internals of request to scatterlist conversion down the line -without breaking drivers. The blk_rq_map_sg routine takes care of several -things like collapsing physically contiguous segments (if QUEUE_FLAG_CLUSTER -is set) and correct segment accounting to avoid exceeding the limits which -the i/o hardware can handle, based on various queue properties. - -- Prevents a clustered segment from crossing a 4GB mem boundary -- Avoids building segments that would exceed the number of physical - memory segments that the driver can handle (phys_segments) and the - number that the underlying hardware can handle at once, accounting for - DMA remapping (hw_segments) (i.e. IOMMU aware limits). - -Routines which the low level driver can use to set up the segment limits: - -blk_queue_max_hw_segments() : Sets an upper limit of the maximum number of -hw data segments in a request (i.e. the maximum number of address/length -pairs the host adapter can actually hand to the device at once) - -blk_queue_max_phys_segments() : Sets an upper limit on the maximum number -of physical data segments in a request (i.e. the largest sized scatter list -a driver could handle) - -3.2.3 I/O completion -^^^^^^^^^^^^^^^^^^^^ - -The existing generic block layer helper routines end_request, -end_that_request_first and end_that_request_last can be used for i/o -completion (and setting things up so the rest of the i/o or the next -request can be kicked of) as before. With the introduction of multi-page -bio support, end_that_request_first requires an additional argument indicating -the number of sectors completed. - -3.2.4 Implications for drivers that do not interpret bios -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -(don't handle multiple segments) - -Drivers that do not interpret bios e.g those which do not handle multiple -segments and do not support i/o into high memory addresses (require bounce -buffers) and expect only virtually mapped buffers, can access the rq->buffer -field. As before the driver should use current_nr_sectors to determine the -size of remaining data in the current segment (that is the maximum it can -transfer in one go unless it interprets segments), and rely on the block layer -end_request, or end_that_request_first/last to take care of all accounting -and transparent mapping of the next bio segment when a segment boundary -is crossed on completion of a transfer. (The end*request* functions should -be used if only if the request has come down from block/bio path, not for -direct access requests which only specify rq->buffer without a valid rq->bio) - -3.3 I/O Submission ------------------- - -The routine submit_bio() is used to submit a single io. Higher level i/o -routines make use of this: - -(a) Buffered i/o: - -The routine submit_bh() invokes submit_bio() on a bio corresponding to the -bh, allocating the bio if required. ll_rw_block() uses submit_bh() as before. - -(b) Kiobuf i/o (for raw/direct i/o): - -The ll_rw_kio() routine breaks up the kiobuf into page sized chunks and -maps the array to one or more multi-page bios, issuing submit_bio() to -perform the i/o on each of these. - -The embedded bh array in the kiobuf structure has been removed and no -preallocation of bios is done for kiobufs. [The intent is to remove the -blocks array as well, but it's currently in there to kludge around direct i/o.] -Thus kiobuf allocation has switched back to using kmalloc rather than vmalloc. - -Todo/Observation: - - A single kiobuf structure is assumed to correspond to a contiguous range - of data, so brw_kiovec() invokes ll_rw_kio for each kiobuf in a kiovec. - So right now it wouldn't work for direct i/o on non-contiguous blocks. - This is to be resolved. The eventual direction is to replace kiobuf - by kvec's. - - Badari Pulavarty has a patch to implement direct i/o correctly using - bio and kvec. - - -(c) Page i/o: - -Todo/Under discussion: - - Andrew Morton's multi-page bio patches attempt to issue multi-page - writeouts (and reads) from the page cache, by directly building up - large bios for submission completely bypassing the usage of buffer - heads. This work is still in progress. - - Christoph Hellwig had some code that uses bios for page-io (rather than - bh). This isn't included in bio as yet. Christoph was also working on a - design for representing virtual/real extents as an entity and modifying - some of the address space ops interfaces to utilize this abstraction rather - than buffer_heads. (This is somewhat along the lines of the SGI XFS pagebuf - abstraction, but intended to be as lightweight as possible). - -(d) Direct access i/o: - -Direct access requests that do not contain bios would be submitted differently -as discussed earlier in section 1.3. - -Aside: - - Kvec i/o: - - Ben LaHaise's aio code uses a slightly different structure instead - of kiobufs, called a kvec_cb. This contains an array of <page, offset, len> - tuples (very much like the networking code), together with a callback function - and data pointer. This is embedded into a brw_cb structure when passed - to brw_kvec_async(). - - Now it should be possible to directly map these kvecs to a bio. Just as while - cloning, in this case rather than PRE_BUILT bio_vecs, we set the bi_io_vec - array pointer to point to the veclet array in kvecs. - - TBD: In order for this to work, some changes are needed in the way multi-page - bios are handled today. The values of the tuples in such a vector passed in - from higher level code should not be modified by the block layer in the course - of its request processing, since that would make it hard for the higher layer - to continue to use the vector descriptor (kvec) after i/o completes. Instead, - all such transient state should either be maintained in the request structure, - and passed on in some way to the endio completion routine. - - -4. The I/O scheduler -==================== - -I/O scheduler, a.k.a. elevator, is implemented in two layers. Generic dispatch -queue and specific I/O schedulers. Unless stated otherwise, elevator is used -to refer to both parts and I/O scheduler to specific I/O schedulers. - -Block layer implements generic dispatch queue in `block/*.c`. -The generic dispatch queue is responsible for requeueing, handling non-fs -requests and all other subtleties. - -Specific I/O schedulers are responsible for ordering normal filesystem -requests. They can also choose to delay certain requests to improve -throughput or whatever purpose. As the plural form indicates, there are -multiple I/O schedulers. They can be built as modules but at least one should -be built inside the kernel. Each queue can choose different one and can also -change to another one dynamically. - -A block layer call to the i/o scheduler follows the convention elv_xxx(). This -calls elevator_xxx_fn in the elevator switch (block/elevator.c). Oh, xxx -and xxx might not match exactly, but use your imagination. If an elevator -doesn't implement a function, the switch does nothing or some minimal house -keeping work. - -4.1. I/O scheduler API ----------------------- - -The functions an elevator may implement are: (* are mandatory) - -=============================== ================================================ -elevator_merge_fn called to query requests for merge with a bio - -elevator_merge_req_fn called when two requests get merged. the one - which gets merged into the other one will be - never seen by I/O scheduler again. IOW, after - being merged, the request is gone. - -elevator_merged_fn called when a request in the scheduler has been - involved in a merge. It is used in the deadline - scheduler for example, to reposition the request - if its sorting order has changed. - -elevator_allow_merge_fn called whenever the block layer determines - that a bio can be merged into an existing - request safely. The io scheduler may still - want to stop a merge at this point if it - results in some sort of conflict internally, - this hook allows it to do that. Note however - that two *requests* can still be merged at later - time. Currently the io scheduler has no way to - prevent that. It can only learn about the fact - from elevator_merge_req_fn callback. - -elevator_dispatch_fn* fills the dispatch queue with ready requests. - I/O schedulers are free to postpone requests by - not filling the dispatch queue unless @force - is non-zero. Once dispatched, I/O schedulers - are not allowed to manipulate the requests - - they belong to generic dispatch queue. - -elevator_add_req_fn* called to add a new request into the scheduler - -elevator_former_req_fn -elevator_latter_req_fn These return the request before or after the - one specified in disk sort order. Used by the - block layer to find merge possibilities. - -elevator_completed_req_fn called when a request is completed. - -elevator_set_req_fn -elevator_put_req_fn Must be used to allocate and free any elevator - specific storage for a request. - -elevator_activate_req_fn Called when device driver first sees a request. - I/O schedulers can use this callback to - determine when actual execution of a request - starts. -elevator_deactivate_req_fn Called when device driver decides to delay - a request by requeueing it. - -elevator_init_fn* -elevator_exit_fn Allocate and free any elevator specific storage - for a queue. -=============================== ================================================ - -4.2 Request flows seen by I/O schedulers ----------------------------------------- - -All requests seen by I/O schedulers strictly follow one of the following three -flows. - - set_req_fn -> - - i. add_req_fn -> (merged_fn ->)* -> dispatch_fn -> activate_req_fn -> - (deactivate_req_fn -> activate_req_fn ->)* -> completed_req_fn - ii. add_req_fn -> (merged_fn ->)* -> merge_req_fn - iii. [none] - - -> put_req_fn - -4.3 I/O scheduler implementation --------------------------------- - -The generic i/o scheduler algorithm attempts to sort/merge/batch requests for -optimal disk scan and request servicing performance (based on generic -principles and device capabilities), optimized for: - -i. improved throughput -ii. improved latency -iii. better utilization of h/w & CPU time - -Characteristics: - -i. Binary tree -AS and deadline i/o schedulers use red black binary trees for disk position -sorting and searching, and a fifo linked list for time-based searching. This -gives good scalability and good availability of information. Requests are -almost always dispatched in disk sort order, so a cache is kept of the next -request in sort order to prevent binary tree lookups. - -This arrangement is not a generic block layer characteristic however, so -elevators may implement queues as they please. - -ii. Merge hash -AS and deadline use a hash table indexed by the last sector of a request. This -enables merging code to quickly look up "back merge" candidates, even when -multiple I/O streams are being performed at once on one disk. - -"Front merges", a new request being merged at the front of an existing request, -are far less common than "back merges" due to the nature of most I/O patterns. -Front merges are handled by the binary trees in AS and deadline schedulers. - -iii. Plugging the queue to batch requests in anticipation of opportunities for - merge/sort optimizations - -Plugging is an approach that the current i/o scheduling algorithm resorts to so -that it collects up enough requests in the queue to be able to take -advantage of the sorting/merging logic in the elevator. If the -queue is empty when a request comes in, then it plugs the request queue -(sort of like plugging the bath tub of a vessel to get fluid to build up) -till it fills up with a few more requests, before starting to service -the requests. This provides an opportunity to merge/sort the requests before -passing them down to the device. There are various conditions when the queue is -unplugged (to open up the flow again), either through a scheduled task or -could be on demand. For example wait_on_buffer sets the unplugging going -through sync_buffer() running blk_run_address_space(mapping). Or the caller -can do it explicity through blk_unplug(bdev). So in the read case, -the queue gets explicitly unplugged as part of waiting for completion on that -buffer. - -Aside: - This is kind of controversial territory, as it's not clear if plugging is - always the right thing to do. Devices typically have their own queues, - and allowing a big queue to build up in software, while letting the device be - idle for a while may not always make sense. The trick is to handle the fine - balance between when to plug and when to open up. Also now that we have - multi-page bios being queued in one shot, we may not need to wait to merge - a big request from the broken up pieces coming by. - -4.4 I/O contexts ----------------- - -I/O contexts provide a dynamically allocated per process data area. They may -be used in I/O schedulers, and in the block layer (could be used for IO statis, -priorities for example). See `*io_context` in block/ll_rw_blk.c, and as-iosched.c -for an example of usage in an i/o scheduler. - - -5. Scalability related changes -============================== - -5.1 Granular Locking: io_request_lock replaced by a per-queue lock ------------------------------------------------------------------- - -The global io_request_lock has been removed as of 2.5, to avoid -the scalability bottleneck it was causing, and has been replaced by more -granular locking. The request queue structure has a pointer to the -lock to be used for that queue. As a result, locking can now be -per-queue, with a provision for sharing a lock across queues if -necessary (e.g the scsi layer sets the queue lock pointers to the -corresponding adapter lock, which results in a per host locking -granularity). The locking semantics are the same, i.e. locking is -still imposed by the block layer, grabbing the lock before -request_fn execution which it means that lots of older drivers -should still be SMP safe. Drivers are free to drop the queue -lock themselves, if required. Drivers that explicitly used the -io_request_lock for serialization need to be modified accordingly. -Usually it's as easy as adding a global lock:: - - static DEFINE_SPINLOCK(my_driver_lock); - -and passing the address to that lock to blk_init_queue(). - -5.2 64 bit sector numbers (sector_t prepares for 64 bit support) ----------------------------------------------------------------- - -The sector number used in the bio structure has been changed to sector_t, -which could be defined as 64 bit in preparation for 64 bit sector support. - -6. Other Changes/Implications -============================= - -6.1 Partition re-mapping handled by the generic block layer ------------------------------------------------------------ - -In 2.5 some of the gendisk/partition related code has been reorganized. -Now the generic block layer performs partition-remapping early and thus -provides drivers with a sector number relative to whole device, rather than -having to take partition number into account in order to arrive at the true -sector number. The routine blk_partition_remap() is invoked by -submit_bio_noacct even before invoking the queue specific ->submit_bio, -so the i/o scheduler also gets to operate on whole disk sector numbers. This -should typically not require changes to block drivers, it just never gets -to invoke its own partition sector offset calculations since all bios -sent are offset from the beginning of the device. - - -7. A Few Tips on Migration of older drivers -=========================================== - -Old-style drivers that just use CURRENT and ignores clustered requests, -may not need much change. The generic layer will automatically handle -clustered requests, multi-page bios, etc for the driver. - -For a low performance driver or hardware that is PIO driven or just doesn't -support scatter-gather changes should be minimal too. - -The following are some points to keep in mind when converting old drivers -to bio. - -Drivers should use elv_next_request to pick up requests and are no longer -supposed to handle looping directly over the request list. -(struct request->queue has been removed) - -Now end_that_request_first takes an additional number_of_sectors argument. -It used to handle always just the first buffer_head in a request, now -it will loop and handle as many sectors (on a bio-segment granularity) -as specified. - -Now bh->b_end_io is replaced by bio->bi_end_io, but most of the time the -right thing to use is bio_endio(bio) instead. - -If the driver is dropping the io_request_lock from its request_fn strategy, -then it just needs to replace that with q->queue_lock instead. - -As described in Sec 1.1, drivers can set max sector size, max segment size -etc per queue now. Drivers that used to define their own merge functions i -to handle things like this can now just use the blk_queue_* functions at -blk_init_queue time. - -Drivers no longer have to map a {partition, sector offset} into the -correct absolute location anymore, this is done by the block layer, so -where a driver received a request ala this before:: - - rq->rq_dev = mk_kdev(3, 5); /* /dev/hda5 */ - rq->sector = 0; /* first sector on hda5 */ - -it will now see:: - - rq->rq_dev = mk_kdev(3, 0); /* /dev/hda */ - rq->sector = 123128; /* offset from start of disk */ - -As mentioned, there is no virtual mapping of a bio. For DMA, this is -not a problem as the driver probably never will need a virtual mapping. -Instead it needs a bus mapping (dma_map_page for a single segment or -use dma_map_sg for scatter gather) to be able to ship it to the driver. For -PIO drivers (or drivers that need to revert to PIO transfer once in a -while (IDE for example)), where the CPU is doing the actual data -transfer a virtual mapping is needed. If the driver supports highmem I/O, -(Sec 1.1, (ii) ) it needs to use kmap_atomic or similar to temporarily map -a bio into the virtual address space. - - -8. Prior/Related/Impacted patches -================================= - -8.1. Earlier kiobuf patches (sct/axboe/chait/hch/mkp) ------------------------------------------------------ - -- orig kiobuf & raw i/o patches (now in 2.4 tree) -- direct kiobuf based i/o to devices (no intermediate bh's) -- page i/o using kiobuf -- kiobuf splitting for lvm (mkp) -- elevator support for kiobuf request merging (axboe) - -8.2. Zero-copy networking (Dave Miller) ---------------------------------------- - -8.3. SGI XFS - pagebuf patches - use of kiobufs ------------------------------------------------ -8.4. Multi-page pioent patch for bio (Christoph Hellwig) --------------------------------------------------------- -8.5. Direct i/o implementation (Andrea Arcangeli) since 2.4.10-pre11 --------------------------------------------------------------------- -8.6. Async i/o implementation patch (Ben LaHaise) -------------------------------------------------- -8.7. EVMS layering design (IBM EVMS team) ------------------------------------------ -8.8. Larger page cache size patch (Ben LaHaise) and Large page size (Daniel Phillips) -------------------------------------------------------------------------------------- - - => larger contiguous physical memory buffers - -8.9. VM reservations patch (Ben LaHaise) ----------------------------------------- -8.10. Write clustering patches ? (Marcelo/Quintela/Riel ?) ----------------------------------------------------------- -8.11. Block device in page cache patch (Andrea Archangeli) - now in 2.4.10+ ---------------------------------------------------------------------------- -8.12. Multiple block-size transfers for faster raw i/o (Shailabh Nagar, Badari) -------------------------------------------------------------------------------- -8.13 Priority based i/o scheduler - prepatches (Arjan van de Ven) ------------------------------------------------------------------- -8.14 IDE Taskfile i/o patch (Andre Hedrick) --------------------------------------------- -8.15 Multi-page writeout and readahead patches (Andrew Morton) ---------------------------------------------------------------- -8.16 Direct i/o patches for 2.5 using kvec and bio (Badari Pulavarthy) ------------------------------------------------------------------------ - -9. Other References -=================== - -9.1 The Splice I/O Model ------------------------- - -Larry McVoy (and subsequent discussions on lkml, and Linus' comments - Jan 2001 - -9.2 Discussions about kiobuf and bh design ------------------------------------------- - -On lkml between sct, linus, alan et al - Feb-March 2001 (many of the -initial thoughts that led to bio were brought up in this discussion thread) - -9.3 Discussions on mempool on lkml - Dec 2001. ----------------------------------------------- diff --git a/Documentation/block/capability.rst b/Documentation/block/capability.rst index 160a5148b915..2ae7f064736a 100644 --- a/Documentation/block/capability.rst +++ b/Documentation/block/capability.rst @@ -7,4 +7,4 @@ This file documents the sysfs file ``block/<disk>/capability``. ``capability`` is a bitfield, printed in hexadecimal, indicating which capabilities a specific block device supports: -.. kernel-doc:: include/linux/genhd.h +.. kernel-doc:: include/linux/blkdev.h diff --git a/Documentation/block/index.rst b/Documentation/block/index.rst index 3a41495dd77b..68f115f2b1c6 100644 --- a/Documentation/block/index.rst +++ b/Documentation/block/index.rst @@ -8,7 +8,6 @@ Block :maxdepth: 1 bfq-iosched - biodoc biovecs blk-mq capability diff --git a/Documentation/bpf/bpf_devel_QA.rst b/Documentation/bpf/bpf_devel_QA.rst index 253496af8fef..761474bd7fe6 100644 --- a/Documentation/bpf/bpf_devel_QA.rst +++ b/Documentation/bpf/bpf_devel_QA.rst @@ -658,7 +658,7 @@ when: .. Links .. _Documentation/process/: https://www.kernel.org/doc/html/latest/process/ -.. _netdev-FAQ: ../networking/netdev-FAQ.rst +.. _netdev-FAQ: Documentation/process/maintainer-netdev.rst .. _selftests: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/testing/selftests/bpf/ .. _Documentation/dev-tools/kselftest.rst: diff --git a/Documentation/bpf/bpf_prog_run.rst b/Documentation/bpf/bpf_prog_run.rst new file mode 100644 index 000000000000..4868c909df5c --- /dev/null +++ b/Documentation/bpf/bpf_prog_run.rst @@ -0,0 +1,117 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================================== +Running BPF programs from userspace +=================================== + +This document describes the ``BPF_PROG_RUN`` facility for running BPF programs +from userspace. + +.. contents:: + :local: + :depth: 2 + + +Overview +-------- + +The ``BPF_PROG_RUN`` command can be used through the ``bpf()`` syscall to +execute a BPF program in the kernel and return the results to userspace. This +can be used to unit test BPF programs against user-supplied context objects, and +as way to explicitly execute programs in the kernel for their side effects. The +command was previously named ``BPF_PROG_TEST_RUN``, and both constants continue +to be defined in the UAPI header, aliased to the same value. + +The ``BPF_PROG_RUN`` command can be used to execute BPF programs of the +following types: + +- ``BPF_PROG_TYPE_SOCKET_FILTER`` +- ``BPF_PROG_TYPE_SCHED_CLS`` +- ``BPF_PROG_TYPE_SCHED_ACT`` +- ``BPF_PROG_TYPE_XDP`` +- ``BPF_PROG_TYPE_SK_LOOKUP`` +- ``BPF_PROG_TYPE_CGROUP_SKB`` +- ``BPF_PROG_TYPE_LWT_IN`` +- ``BPF_PROG_TYPE_LWT_OUT`` +- ``BPF_PROG_TYPE_LWT_XMIT`` +- ``BPF_PROG_TYPE_LWT_SEG6LOCAL`` +- ``BPF_PROG_TYPE_FLOW_DISSECTOR`` +- ``BPF_PROG_TYPE_STRUCT_OPS`` +- ``BPF_PROG_TYPE_RAW_TRACEPOINT`` +- ``BPF_PROG_TYPE_SYSCALL`` + +When using the ``BPF_PROG_RUN`` command, userspace supplies an input context +object and (for program types operating on network packets) a buffer containing +the packet data that the BPF program will operate on. The kernel will then +execute the program and return the results to userspace. Note that programs will +not have any side effects while being run in this mode; in particular, packets +will not actually be redirected or dropped, the program return code will just be +returned to userspace. A separate mode for live execution of XDP programs is +provided, documented separately below. + +Running XDP programs in "live frame mode" +----------------------------------------- + +The ``BPF_PROG_RUN`` command has a separate mode for running live XDP programs, +which can be used to execute XDP programs in a way where packets will actually +be processed by the kernel after the execution of the XDP program as if they +arrived on a physical interface. This mode is activated by setting the +``BPF_F_TEST_XDP_LIVE_FRAMES`` flag when supplying an XDP program to +``BPF_PROG_RUN``. + +The live packet mode is optimised for high performance execution of the supplied +XDP program many times (suitable for, e.g., running as a traffic generator), +which means the semantics are not quite as straight-forward as the regular test +run mode. Specifically: + +- When executing an XDP program in live frame mode, the result of the execution + will not be returned to userspace; instead, the kernel will perform the + operation indicated by the program's return code (drop the packet, redirect + it, etc). For this reason, setting the ``data_out`` or ``ctx_out`` attributes + in the syscall parameters when running in this mode will be rejected. In + addition, not all failures will be reported back to userspace directly; + specifically, only fatal errors in setup or during execution (like memory + allocation errors) will halt execution and return an error. If an error occurs + in packet processing, like a failure to redirect to a given interface, + execution will continue with the next repetition; these errors can be detected + via the same trace points as for regular XDP programs. + +- Userspace can supply an ifindex as part of the context object, just like in + the regular (non-live) mode. The XDP program will be executed as though the + packet arrived on this interface; i.e., the ``ingress_ifindex`` of the context + object will point to that interface. Furthermore, if the XDP program returns + ``XDP_PASS``, the packet will be injected into the kernel networking stack as + though it arrived on that ifindex, and if it returns ``XDP_TX``, the packet + will be transmitted *out* of that same interface. Do note, though, that + because the program execution is not happening in driver context, an + ``XDP_TX`` is actually turned into the same action as an ``XDP_REDIRECT`` to + that same interface (i.e., it will only work if the driver has support for the + ``ndo_xdp_xmit`` driver op). + +- When running the program with multiple repetitions, the execution will happen + in batches. The batch size defaults to 64 packets (which is same as the + maximum NAPI receive batch size), but can be specified by userspace through + the ``batch_size`` parameter, up to a maximum of 256 packets. For each batch, + the kernel executes the XDP program repeatedly, each invocation getting a + separate copy of the packet data. For each repetition, if the program drops + the packet, the data page is immediately recycled (see below). Otherwise, the + packet is buffered until the end of the batch, at which point all packets + buffered this way during the batch are transmitted at once. + +- When setting up the test run, the kernel will initialise a pool of memory + pages of the same size as the batch size. Each memory page will be initialised + with the initial packet data supplied by userspace at ``BPF_PROG_RUN`` + invocation. When possible, the pages will be recycled on future program + invocations, to improve performance. Pages will generally be recycled a full + batch at a time, except when a packet is dropped (by return code or because + of, say, a redirection error), in which case that page will be recycled + immediately. If a packet ends up being passed to the regular networking stack + (because the XDP program returns ``XDP_PASS``, or because it ends up being + redirected to an interface that injects it into the stack), the page will be + released and a new one will be allocated when the pool is empty. + + When recycling, the page content is not rewritten; only the packet boundary + pointers (``data``, ``data_end`` and ``data_meta``) in the context object will + be reset to the original values. This means that if a program rewrites the + packet contents, it has to be prepared to see either the original content or + the modified version on subsequent invocations. diff --git a/Documentation/bpf/btf.rst b/Documentation/bpf/btf.rst index 1ebf4c5c7ddc..7940da9bc6c1 100644 --- a/Documentation/bpf/btf.rst +++ b/Documentation/bpf/btf.rst @@ -503,6 +503,19 @@ valid index (starting from 0) pointing to a member or an argument. * ``info.vlen``: 0 * ``type``: the type with ``btf_type_tag`` attribute +Currently, ``BTF_KIND_TYPE_TAG`` is only emitted for pointer types. +It has the following btf type chain: +:: + + ptr -> [type_tag]* + -> [const | volatile | restrict | typedef]* + -> base_type + +Basically, a pointer type points to zero or more +type_tag, then zero or more const/volatile/restrict/typedef +and finally the base type. The base type is one of +int, ptr, array, struct, union, enum, func_proto and float types. + 3. BTF Kernel API ================= @@ -565,18 +578,15 @@ A map can be created with ``btf_fd`` and specified key/value type id.:: In libbpf, the map can be defined with extra annotation like below: :: - struct bpf_map_def SEC("maps") btf_map = { - .type = BPF_MAP_TYPE_ARRAY, - .key_size = sizeof(int), - .value_size = sizeof(struct ipv_counts), - .max_entries = 4, - }; - BPF_ANNOTATE_KV_PAIR(btf_map, int, struct ipv_counts); + struct { + __uint(type, BPF_MAP_TYPE_ARRAY); + __type(key, int); + __type(value, struct ipv_counts); + __uint(max_entries, 4); + } btf_map SEC(".maps"); -Here, the parameters for macro BPF_ANNOTATE_KV_PAIR are map name, key and -value types for the map. During ELF parsing, libbpf is able to extract -key/value type_id's and assign them to BPF_MAP_CREATE attributes -automatically. +During ELF parsing, libbpf is able to extract key/value type_id's and assign +them to BPF_MAP_CREATE attributes automatically. .. _BPF_Prog_Load: @@ -824,13 +834,12 @@ structure has bitfields. For example, for the following map,:: ___A b1:4; enum A b2:4; }; - struct bpf_map_def SEC("maps") tmpmap = { - .type = BPF_MAP_TYPE_ARRAY, - .key_size = sizeof(__u32), - .value_size = sizeof(struct tmp_t), - .max_entries = 1, - }; - BPF_ANNOTATE_KV_PAIR(tmpmap, int, struct tmp_t); + struct { + __uint(type, BPF_MAP_TYPE_ARRAY); + __type(key, int); + __type(value, struct tmp_t); + __uint(max_entries, 1); + } tmpmap SEC(".maps"); bpftool is able to pretty print like below: :: diff --git a/Documentation/bpf/index.rst b/Documentation/bpf/index.rst index ef5c996547ec..96056a7447c7 100644 --- a/Documentation/bpf/index.rst +++ b/Documentation/bpf/index.rst @@ -21,6 +21,7 @@ that goes into great technical depth about the BPF Architecture. helpers programs maps + bpf_prog_run classic_vs_extended.rst bpf_licensing test_debug diff --git a/Documentation/bpf/instruction-set.rst b/Documentation/bpf/instruction-set.rst index 3704836fe6df..5300837ac2c9 100644 --- a/Documentation/bpf/instruction-set.rst +++ b/Documentation/bpf/instruction-set.rst @@ -22,7 +22,13 @@ necessary across calls. Instruction encoding ==================== -eBPF uses 64-bit instructions with the following encoding: +eBPF has two instruction encodings: + + * the basic instruction encoding, which uses 64 bits to encode an instruction + * the wide instruction encoding, which appends a second 64-bit immediate value + (imm64) after the basic instruction for a total of 128 bits. + +The basic instruction encoding looks as follows: ============= ======= =============== ==================== ============ 32 bits (MSB) 16 bits 4 bits 4 bits 8 bits (LSB) @@ -82,9 +88,9 @@ BPF_ALU uses 32-bit wide operands while BPF_ALU64 uses 64-bit wide operands for otherwise identical operations. The code field encodes the operation as below: - ======== ===== ========================== + ======== ===== ================================================= code value description - ======== ===== ========================== + ======== ===== ================================================= BPF_ADD 0x00 dst += src BPF_SUB 0x10 dst -= src BPF_MUL 0x20 dst \*= src @@ -98,8 +104,8 @@ The code field encodes the operation as below: BPF_XOR 0xa0 dst ^= src BPF_MOV 0xb0 dst = src BPF_ARSH 0xc0 sign extending shift right - BPF_END 0xd0 endianness conversion - ======== ===== ========================== + BPF_END 0xd0 byte swap operations (see separate section below) + ======== ===== ================================================= BPF_ADD | BPF_X | BPF_ALU means:: @@ -118,6 +124,42 @@ BPF_XOR | BPF_K | BPF_ALU64 means:: src_reg = src_reg ^ imm32 +Byte swap instructions +---------------------- + +The byte swap instructions use an instruction class of ``BFP_ALU`` and a 4-bit +code field of ``BPF_END``. + +The byte swap instructions instructions operate on the destination register +only and do not use a separate source register or immediate value. + +The 1-bit source operand field in the opcode is used to to select what byte +order the operation convert from or to: + + ========= ===== ================================================= + source value description + ========= ===== ================================================= + BPF_TO_LE 0x00 convert between host byte order and little endian + BPF_TO_BE 0x08 convert between host byte order and big endian + ========= ===== ================================================= + +The imm field encodes the width of the swap operations. The following widths +are supported: 16, 32 and 64. + +Examples: + +``BPF_ALU | BPF_TO_LE | BPF_END`` with imm = 16 means:: + + dst_reg = htole16(dst_reg) + +``BPF_ALU | BPF_TO_BE | BPF_END`` with imm = 64 means:: + + dst_reg = htobe64(dst_reg) + +``BPF_FROM_LE`` and ``BPF_FROM_BE`` exist as aliases for ``BPF_TO_LE`` and +``BPF_TO_LE`` respetively. + + Jump instructions ----------------- @@ -176,63 +218,96 @@ The mode modifier is one of: ============= ===== ==================================== mode modifier value description ============= ===== ==================================== - BPF_IMM 0x00 used for 64-bit mov - BPF_ABS 0x20 legacy BPF packet access - BPF_IND 0x40 legacy BPF packet access - BPF_MEM 0x60 all normal load and store operations + BPF_IMM 0x00 64-bit immediate instructions + BPF_ABS 0x20 legacy BPF packet access (absolute) + BPF_IND 0x40 legacy BPF packet access (indirect) + BPF_MEM 0x60 regular load and store operations BPF_ATOMIC 0xc0 atomic operations ============= ===== ==================================== -BPF_MEM | <size> | BPF_STX means:: + +Regular load and store operations +--------------------------------- + +The ``BPF_MEM`` mode modifier is used to encode regular load and store +instructions that transfer data between a register and memory. + +``BPF_MEM | <size> | BPF_STX`` means:: *(size *) (dst_reg + off) = src_reg -BPF_MEM | <size> | BPF_ST means:: +``BPF_MEM | <size> | BPF_ST`` means:: *(size *) (dst_reg + off) = imm32 -BPF_MEM | <size> | BPF_LDX means:: +``BPF_MEM | <size> | BPF_LDX`` means:: dst_reg = *(size *) (src_reg + off) -Where size is one of: BPF_B or BPF_H or BPF_W or BPF_DW. +Where size is one of: ``BPF_B``, ``BPF_H``, ``BPF_W``, or ``BPF_DW``. Atomic operations ----------------- -eBPF includes atomic operations, which use the immediate field for extra -encoding:: +Atomic operations are operations that operate on memory and can not be +interrupted or corrupted by other access to the same memory region +by other eBPF programs or means outside of this specification. + +All atomic operations supported by eBPF are encoded as store operations +that use the ``BPF_ATOMIC`` mode modifier as follows: + + * ``BPF_ATOMIC | BPF_W | BPF_STX`` for 32-bit operations + * ``BPF_ATOMIC | BPF_DW | BPF_STX`` for 64-bit operations + * 8-bit and 16-bit wide atomic operations are not supported. - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_W | BPF_STX: lock xadd *(u32 *)(dst_reg + off16) += src_reg - .imm = BPF_ADD, .code = BPF_ATOMIC | BPF_DW | BPF_STX: lock xadd *(u64 *)(dst_reg + off16) += src_reg +The imm field is used to encode the actual atomic operation. +Simple atomic operation use a subset of the values defined to encode +arithmetic operations in the imm field to encode the atomic operation: -The basic atomic operations supported are:: + ======== ===== =========== + imm value description + ======== ===== =========== + BPF_ADD 0x00 atomic add + BPF_OR 0x40 atomic or + BPF_AND 0x50 atomic and + BPF_XOR 0xa0 atomic xor + ======== ===== =========== - BPF_ADD - BPF_AND - BPF_OR - BPF_XOR -Each having equivalent semantics with the ``BPF_ADD`` example, that is: the -memory location addresed by ``dst_reg + off`` is atomically modified, with -``src_reg`` as the other operand. If the ``BPF_FETCH`` flag is set in the -immediate, then these operations also overwrite ``src_reg`` with the -value that was in memory before it was modified. +``BPF_ATOMIC | BPF_W | BPF_STX`` with imm = BPF_ADD means:: -The more special operations are:: + *(u32 *)(dst_reg + off16) += src_reg - BPF_XCHG +``BPF_ATOMIC | BPF_DW | BPF_STX`` with imm = BPF ADD means:: -This atomically exchanges ``src_reg`` with the value addressed by ``dst_reg + -off``. :: + *(u64 *)(dst_reg + off16) += src_reg - BPF_CMPXCHG +``BPF_XADD`` is a deprecated name for ``BPF_ATOMIC | BPF_ADD``. -This atomically compares the value addressed by ``dst_reg + off`` with -``R0``. If they match it is replaced with ``src_reg``. In either case, the -value that was there before is zero-extended and loaded back to ``R0``. +In addition to the simple atomic operations, there also is a modifier and +two complex atomic operations: -Note that 1 and 2 byte atomic operations are not supported. + =========== ================ =========================== + imm value description + =========== ================ =========================== + BPF_FETCH 0x01 modifier: return old value + BPF_XCHG 0xe0 | BPF_FETCH atomic exchange + BPF_CMPXCHG 0xf0 | BPF_FETCH atomic compare and exchange + =========== ================ =========================== + +The ``BPF_FETCH`` modifier is optional for simple atomic operations, and +always set for the complex atomic operations. If the ``BPF_FETCH`` flag +is set, then the operation also overwrites ``src_reg`` with the value that +was in memory before it was modified. + +The ``BPF_XCHG`` operation atomically exchanges ``src_reg`` with the value +addressed by ``dst_reg + off``. + +The ``BPF_CMPXCHG`` operation atomically compares the value addressed by +``dst_reg + off`` with ``R0``. If they match, the value addressed by +``dst_reg + off`` is replaced with ``src_reg``. In either case, the +value that was at ``dst_reg + off`` before the operation is zero-extended +and loaded back to ``R0``. Clang can generate atomic instructions by default when ``-mcpu=v3`` is enabled. If a lower version for ``-mcpu`` is set, the only atomic instruction @@ -240,40 +315,52 @@ Clang can generate is ``BPF_ADD`` *without* ``BPF_FETCH``. If you need to enable the atomics features, while keeping a lower ``-mcpu`` version, you can use ``-Xclang -target-feature -Xclang +alu32``. -You may encounter ``BPF_XADD`` - this is a legacy name for ``BPF_ATOMIC``, -referring to the exclusive-add operation encoded when the immediate field is -zero. +64-bit immediate instructions +----------------------------- -16-byte instructions --------------------- +Instructions with the ``BPF_IMM`` mode modifier use the wide instruction +encoding for an extra imm64 value. -eBPF has one 16-byte instruction: ``BPF_LD | BPF_DW | BPF_IMM`` which consists -of two consecutive ``struct bpf_insn`` 8-byte blocks and interpreted as single -instruction that loads 64-bit immediate value into a dst_reg. +There is currently only one such instruction. -Packet access instructions --------------------------- +``BPF_LD | BPF_DW | BPF_IMM`` means:: -eBPF has two non-generic instructions: (BPF_ABS | <size> | BPF_LD) and -(BPF_IND | <size> | BPF_LD) which are used to access packet data. + dst_reg = imm64 -They had to be carried over from classic BPF to have strong performance of -socket filters running in eBPF interpreter. These instructions can only -be used when interpreter context is a pointer to ``struct sk_buff`` and -have seven implicit operands. Register R6 is an implicit input that must -contain pointer to sk_buff. Register R0 is an implicit output which contains -the data fetched from the packet. Registers R1-R5 are scratch registers -and must not be used to store the data across BPF_ABS | BPF_LD or -BPF_IND | BPF_LD instructions. -These instructions have implicit program exit condition as well. When -eBPF program is trying to access the data beyond the packet boundary, -the interpreter will abort the execution of the program. JIT compilers -therefore must preserve this property. src_reg and imm32 fields are -explicit inputs to these instructions. +Legacy BPF Packet access instructions +------------------------------------- -For example, BPF_IND | BPF_W | BPF_LD means:: +eBPF has special instructions for access to packet data that have been +carried over from classic BPF to retain the performance of legacy socket +filters running in the eBPF interpreter. - R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) +The instructions come in two forms: ``BPF_ABS | <size> | BPF_LD`` and +``BPF_IND | <size> | BPF_LD``. -and R1 - R5 are clobbered. +These instructions are used to access packet data and can only be used when +the program context is a pointer to networking packet. ``BPF_ABS`` +accesses packet data at an absolute offset specified by the immediate data +and ``BPF_IND`` access packet data at an offset that includes the value of +a register in addition to the immediate data. + +These instructions have seven implicit operands: + + * Register R6 is an implicit input that must contain pointer to a + struct sk_buff. + * Register R0 is an implicit output which contains the data fetched from + the packet. + * Registers R1-R5 are scratch registers that are clobbered after a call to + ``BPF_ABS | BPF_LD`` or ``BPF_IND`` | BPF_LD instructions. + +These instructions have an implicit program exit condition as well. When an +eBPF program is trying to access the data beyond the packet boundary, the +program execution will be aborted. + +``BPF_ABS | BPF_W | BPF_LD`` means:: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + imm32)) + +``BPF_IND | BPF_W | BPF_LD`` means:: + + R0 = ntohl(*(u32 *) (((struct sk_buff *) R6)->data + src_reg + imm32)) diff --git a/Documentation/bpf/verifier.rst b/Documentation/bpf/verifier.rst index fae5f6273bac..d4326caf01f9 100644 --- a/Documentation/bpf/verifier.rst +++ b/Documentation/bpf/verifier.rst @@ -329,7 +329,7 @@ Program with unreachable instructions:: BPF_EXIT_INSN(), }; -Error: +Error:: unreachable insn 1 diff --git a/Documentation/cdrom/packet-writing.rst b/Documentation/cdrom/packet-writing.rst index c5c957195a5a..43db58c50d29 100644 --- a/Documentation/cdrom/packet-writing.rst +++ b/Documentation/cdrom/packet-writing.rst @@ -11,7 +11,7 @@ Getting started quick - Compile and install kernel and modules, reboot. - You need the udftools package (pktsetup, mkudffs, cdrwtool). - Download from http://sourceforge.net/projects/linux-udf/ + Download from https://github.com/pali/udftools - Grab a new CD-RW disc and format it (assuming CD-RW is hdc, substitute as appropriate):: @@ -102,7 +102,7 @@ Using the pktcdvd sysfs interface Since Linux 2.6.20, the pktcdvd module has a sysfs interface and can be controlled by it. For example the "pktcdvd" tool uses -this interface. (see http://tom.ist-im-web.de/download/pktcdvd ) +this interface. (see http://tom.ist-im-web.de/linux/software/pktcdvd ) "pktcdvd" works similar to "pktsetup", e.g.:: diff --git a/Documentation/conf.py b/Documentation/conf.py index f07f2e9b9f2c..072ee31a301d 100644 --- a/Documentation/conf.py +++ b/Documentation/conf.py @@ -409,135 +409,25 @@ latex_elements = { # Additional stuff for the LaTeX preamble. 'preamble': ''' - % Prevent column squeezing of tabulary. - \\setlength{\\tymin}{20em} % Use some font with UTF-8 support with XeLaTeX \\usepackage{fontspec} \\setsansfont{DejaVu Sans} \\setromanfont{DejaVu Serif} \\setmonofont{DejaVu Sans Mono} - % Adjust \\headheight for fancyhdr - \\addtolength{\\headheight}{1.6pt} - \\addtolength{\\topmargin}{-1.6pt} - ''', + ''', } -# Translations have Asian (CJK) characters which are only displayed if -# xeCJK is used - -latex_elements['preamble'] += ''' - \\IfFontExistsTF{Noto Sans CJK SC}{ - % This is needed for translations - \\usepackage{xeCJK} - \\IfFontExistsTF{Noto Serif CJK SC}{ - \\setCJKmainfont{Noto Serif CJK SC}[AutoFakeSlant] - }{ - \\setCJKmainfont{Noto Sans CJK SC}[AutoFakeSlant] - } - \\setCJKsansfont{Noto Sans CJK SC}[AutoFakeSlant] - \\setCJKmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant] - % CJK Language-specific font choices - \\IfFontExistsTF{Noto Serif CJK SC}{ - \\newCJKfontfamily[SCmain]\\scmain{Noto Serif CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCserif]\\scserif{Noto Serif CJK SC}[AutoFakeSlant] - }{ - \\newCJKfontfamily[SCmain]\\scmain{Noto Sans CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCserif]\\scserif{Noto Sans CJK SC}[AutoFakeSlant] - } - \\newCJKfontfamily[SCsans]\\scsans{Noto Sans CJK SC}[AutoFakeSlant] - \\newCJKfontfamily[SCmono]\\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK TC}{ - \\newCJKfontfamily[TCmain]\\tcmain{Noto Serif CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCserif]\\tcserif{Noto Serif CJK TC}[AutoFakeSlant] - }{ - \\newCJKfontfamily[TCmain]\\tcmain{Noto Sans CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCserif]\\tcserif{Noto Sans CJK TC}[AutoFakeSlant] - } - \\newCJKfontfamily[TCsans]\\tcsans{Noto Sans CJK TC}[AutoFakeSlant] - \\newCJKfontfamily[TCmono]\\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK KR}{ - \\newCJKfontfamily[KRmain]\\krmain{Noto Serif CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRserif]\\krserif{Noto Serif CJK KR}[AutoFakeSlant] - }{ - \\newCJKfontfamily[KRmain]\\krmain{Noto Sans CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRserif]\\krserif{Noto Sans CJK KR}[AutoFakeSlant] - } - \\newCJKfontfamily[KRsans]\\krsans{Noto Sans CJK KR}[AutoFakeSlant] - \\newCJKfontfamily[KRmono]\\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant] - \\IfFontExistsTF{Noto Serif CJK JP}{ - \\newCJKfontfamily[JPmain]\\jpmain{Noto Serif CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPserif]\\jpserif{Noto Serif CJK JP}[AutoFakeSlant] - }{ - \\newCJKfontfamily[JPmain]\\jpmain{Noto Sans CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPserif]\\jpserif{Noto Sans CJK JP}[AutoFakeSlant] - } - \\newCJKfontfamily[JPsans]\\jpsans{Noto Sans CJK JP}[AutoFakeSlant] - \\newCJKfontfamily[JPmono]\\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant] - % Dummy commands for Sphinx < 2.3 (no 'extrapackages' support) - \\providecommand{\\onehalfspacing}{} - \\providecommand{\\singlespacing}{} - % Define custom macros to on/off CJK - \\newcommand{\\kerneldocCJKon}{\\makexeCJKactive\\onehalfspacing} - \\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive\\singlespacing} - \\newcommand{\\kerneldocBeginSC}{% - \\begingroup% - \\scmain% - } - \\newcommand{\\kerneldocEndSC}{\\endgroup} - \\newcommand{\\kerneldocBeginTC}{% - \\begingroup% - \\tcmain% - \\renewcommand{\\CJKrmdefault}{TCserif}% - \\renewcommand{\\CJKsfdefault}{TCsans}% - \\renewcommand{\\CJKttdefault}{TCmono}% - } - \\newcommand{\\kerneldocEndTC}{\\endgroup} - \\newcommand{\\kerneldocBeginKR}{% - \\begingroup% - \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{HalfRight}{`â€,`’}% - \\krmain% - \\renewcommand{\\CJKrmdefault}{KRserif}% - \\renewcommand{\\CJKsfdefault}{KRsans}% - \\renewcommand{\\CJKttdefault}{KRmono}% - \\xeCJKsetup{CJKspace = true} % For inter-phrase space - } - \\newcommand{\\kerneldocEndKR}{\\endgroup} - \\newcommand{\\kerneldocBeginJP}{% - \\begingroup% - \\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}% - \\xeCJKDeclareCharClass{HalfRight}{`â€,`’}% - \\jpmain% - \\renewcommand{\\CJKrmdefault}{JPserif}% - \\renewcommand{\\CJKsfdefault}{JPsans}% - \\renewcommand{\\CJKttdefault}{JPmono}% - } - \\newcommand{\\kerneldocEndJP}{\\endgroup} - % Single spacing in literal blocks - \\fvset{baselinestretch=1} - % To customize \\sphinxtableofcontents - \\usepackage{etoolbox} - % Inactivate CJK after tableofcontents - \\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{} - }{ % No CJK font found - % Custom macros to on/off CJK (Dummy) - \\newcommand{\\kerneldocCJKon}{} - \\newcommand{\\kerneldocCJKoff}{} - \\newcommand{\\kerneldocBeginSC}{} - \\newcommand{\\kerneldocEndSC}{} - \\newcommand{\\kerneldocBeginTC}{} - \\newcommand{\\kerneldocEndTC}{} - \\newcommand{\\kerneldocBeginKR}{} - \\newcommand{\\kerneldocEndKR}{} - \\newcommand{\\kerneldocBeginJP}{} - \\newcommand{\\kerneldocEndJP}{} - } -''' - # Fix reference escape troubles with Sphinx 1.4.x if major == 1: latex_elements['preamble'] += '\\renewcommand*{\\DUrole}[2]{ #2 }\n' + +# Load kerneldoc specific LaTeX settings +latex_elements['preamble'] += ''' + % Load kerneldoc specific LaTeX settings + \\input{kerneldoc-preamble.sty} +''' + # With Sphinx 1.6, it is possible to change the Bg color directly # by using: # \definecolor{sphinxnoteBgColor}{RGB}{204,255,255} @@ -599,6 +489,11 @@ for fn in os.listdir('.'): # If false, no module index is generated. #latex_domain_indices = True +# Additional LaTeX stuff to be copied to build directory +latex_additional_files = [ + 'sphinx/kerneldoc-preamble.sty', +] + # -- Options for manual page output --------------------------------------- diff --git a/Documentation/core-api/entry.rst b/Documentation/core-api/entry.rst new file mode 100644 index 000000000000..e12f22ab33c7 --- /dev/null +++ b/Documentation/core-api/entry.rst @@ -0,0 +1,279 @@ +Entry/exit handling for exceptions, interrupts, syscalls and KVM +================================================================ + +All transitions between execution domains require state updates which are +subject to strict ordering constraints. State updates are required for the +following: + + * Lockdep + * RCU / Context tracking + * Preemption counter + * Tracing + * Time accounting + +The update order depends on the transition type and is explained below in +the transition type sections: `Syscalls`_, `KVM`_, `Interrupts and regular +exceptions`_, `NMI and NMI-like exceptions`_. + +Non-instrumentable code - noinstr +--------------------------------- + +Most instrumentation facilities depend on RCU, so intrumentation is prohibited +for entry code before RCU starts watching and exit code after RCU stops +watching. In addition, many architectures must save and restore register state, +which means that (for example) a breakpoint in the breakpoint entry code would +overwrite the debug registers of the initial breakpoint. + +Such code must be marked with the 'noinstr' attribute, placing that code into a +special section inaccessible to instrumentation and debug facilities. Some +functions are partially instrumentable, which is handled by marking them +noinstr and using instrumentation_begin() and instrumentation_end() to flag the +instrumentable ranges of code: + +.. code-block:: c + + noinstr void entry(void) + { + handle_entry(); // <-- must be 'noinstr' or '__always_inline' + ... + + instrumentation_begin(); + handle_context(); // <-- instrumentable code + instrumentation_end(); + + ... + handle_exit(); // <-- must be 'noinstr' or '__always_inline' + } + +This allows verification of the 'noinstr' restrictions via objtool on +supported architectures. + +Invoking non-instrumentable functions from instrumentable context has no +restrictions and is useful to protect e.g. state switching which would +cause malfunction if instrumented. + +All non-instrumentable entry/exit code sections before and after the RCU +state transitions must run with interrupts disabled. + +Syscalls +-------- + +Syscall-entry code starts in assembly code and calls out into low-level C code +after establishing low-level architecture-specific state and stack frames. This +low-level C code must not be instrumented. A typical syscall handling function +invoked from low-level assembly code looks like this: + +.. code-block:: c + + noinstr void syscall(struct pt_regs *regs, int nr) + { + arch_syscall_enter(regs); + nr = syscall_enter_from_user_mode(regs, nr); + + instrumentation_begin(); + if (!invoke_syscall(regs, nr) && nr != -1) + result_reg(regs) = __sys_ni_syscall(regs); + instrumentation_end(); + + syscall_exit_to_user_mode(regs); + } + +syscall_enter_from_user_mode() first invokes enter_from_user_mode() which +establishes state in the following order: + + * Lockdep + * RCU / Context tracking + * Tracing + +and then invokes the various entry work functions like ptrace, seccomp, audit, +syscall tracing, etc. After all that is done, the instrumentable invoke_syscall +function can be invoked. The instrumentable code section then ends, after which +syscall_exit_to_user_mode() is invoked. + +syscall_exit_to_user_mode() handles all work which needs to be done before +returning to user space like tracing, audit, signals, task work etc. After +that it invokes exit_to_user_mode() which again handles the state +transition in the reverse order: + + * Tracing + * RCU / Context tracking + * Lockdep + +syscall_enter_from_user_mode() and syscall_exit_to_user_mode() are also +available as fine grained subfunctions in cases where the architecture code +has to do extra work between the various steps. In such cases it has to +ensure that enter_from_user_mode() is called first on entry and +exit_to_user_mode() is called last on exit. + +Do not nest syscalls. Nested systcalls will cause RCU and/or context tracking +to print a warning. + +KVM +--- + +Entering or exiting guest mode is very similar to syscalls. From the host +kernel point of view the CPU goes off into user space when entering the +guest and returns to the kernel on exit. + +kvm_guest_enter_irqoff() is a KVM-specific variant of exit_to_user_mode() +and kvm_guest_exit_irqoff() is the KVM variant of enter_from_user_mode(). +The state operations have the same ordering. + +Task work handling is done separately for guest at the boundary of the +vcpu_run() loop via xfer_to_guest_mode_handle_work() which is a subset of +the work handled on return to user space. + +Do not nest KVM entry/exit transitions because doing so is nonsensical. + +Interrupts and regular exceptions +--------------------------------- + +Interrupts entry and exit handling is slightly more complex than syscalls +and KVM transitions. + +If an interrupt is raised while the CPU executes in user space, the entry +and exit handling is exactly the same as for syscalls. + +If the interrupt is raised while the CPU executes in kernel space the entry and +exit handling is slightly different. RCU state is only updated when the +interrupt is raised in the context of the CPU's idle task. Otherwise, RCU will +already be watching. Lockdep and tracing have to be updated unconditionally. + +irqentry_enter() and irqentry_exit() provide the implementation for this. + +The architecture-specific part looks similar to syscall handling: + +.. code-block:: c + + noinstr void interrupt(struct pt_regs *regs, int nr) + { + arch_interrupt_enter(regs); + state = irqentry_enter(regs); + + instrumentation_begin(); + + irq_enter_rcu(); + invoke_irq_handler(regs, nr); + irq_exit_rcu(); + + instrumentation_end(); + + irqentry_exit(regs, state); + } + +Note that the invocation of the actual interrupt handler is within a +irq_enter_rcu() and irq_exit_rcu() pair. + +irq_enter_rcu() updates the preemption count which makes in_hardirq() +return true, handles NOHZ tick state and interrupt time accounting. This +means that up to the point where irq_enter_rcu() is invoked in_hardirq() +returns false. + +irq_exit_rcu() handles interrupt time accounting, undoes the preemption +count update and eventually handles soft interrupts and NOHZ tick state. + +In theory, the preemption count could be updated in irqentry_enter(). In +practice, deferring this update to irq_enter_rcu() allows the preemption-count +code to be traced, while also maintaining symmetry with irq_exit_rcu() and +irqentry_exit(), which are described in the next paragraph. The only downside +is that the early entry code up to irq_enter_rcu() must be aware that the +preemption count has not yet been updated with the HARDIRQ_OFFSET state. + +Note that irq_exit_rcu() must remove HARDIRQ_OFFSET from the preemption count +before it handles soft interrupts, whose handlers must run in BH context rather +than irq-disabled context. In addition, irqentry_exit() might schedule, which +also requires that HARDIRQ_OFFSET has been removed from the preemption count. + +Even though interrupt handlers are expected to run with local interrupts +disabled, interrupt nesting is common from an entry/exit perspective. For +example, softirq handling happens within an irqentry_{enter,exit}() block with +local interrupts enabled. Also, although uncommon, nothing prevents an +interrupt handler from re-enabling interrupts. + +Interrupt entry/exit code doesn't strictly need to handle reentrancy, since it +runs with local interrupts disabled. But NMIs can happen anytime, and a lot of +the entry code is shared between the two. + +NMI and NMI-like exceptions +--------------------------- + +NMIs and NMI-like exceptions (machine checks, double faults, debug +interrupts, etc.) can hit any context and must be extra careful with +the state. + +State changes for debug exceptions and machine-check exceptions depend on +whether these exceptions happened in user-space (breakpoints or watchpoints) or +in kernel mode (code patching). From user-space, they are treated like +interrupts, while from kernel mode they are treated like NMIs. + +NMIs and other NMI-like exceptions handle state transitions without +distinguishing between user-mode and kernel-mode origin. + +The state update on entry is handled in irqentry_nmi_enter() which updates +state in the following order: + + * Preemption counter + * Lockdep + * RCU / Context tracking + * Tracing + +The exit counterpart irqentry_nmi_exit() does the reverse operation in the +reverse order. + +Note that the update of the preemption counter has to be the first +operation on enter and the last operation on exit. The reason is that both +lockdep and RCU rely on in_nmi() returning true in this case. The +preemption count modification in the NMI entry/exit case must not be +traced. + +Architecture-specific code looks like this: + +.. code-block:: c + + noinstr void nmi(struct pt_regs *regs) + { + arch_nmi_enter(regs); + state = irqentry_nmi_enter(regs); + + instrumentation_begin(); + nmi_handler(regs); + instrumentation_end(); + + irqentry_nmi_exit(regs); + } + +and for e.g. a debug exception it can look like this: + +.. code-block:: c + + noinstr void debug(struct pt_regs *regs) + { + arch_nmi_enter(regs); + + debug_regs = save_debug_regs(); + + if (user_mode(regs)) { + state = irqentry_enter(regs); + + instrumentation_begin(); + user_mode_debug_handler(regs, debug_regs); + instrumentation_end(); + + irqentry_exit(regs, state); + } else { + state = irqentry_nmi_enter(regs); + + instrumentation_begin(); + kernel_mode_debug_handler(regs, debug_regs); + instrumentation_end(); + + irqentry_nmi_exit(regs, state); + } + } + +There is no combined irqentry_nmi_if_kernel() function available as the +above cannot be handled in an exception-agnostic way. + +NMIs can happen in any context. For example, an NMI-like exception triggered +while handling an NMI. So NMI entry code has to be reentrant and state updates +need to handle nesting. diff --git a/Documentation/core-api/index.rst b/Documentation/core-api/index.rst index 5de2c7a4b1b3..972d46a5ddf6 100644 --- a/Documentation/core-api/index.rst +++ b/Documentation/core-api/index.rst @@ -44,6 +44,14 @@ Library functionality that is used throughout the kernel. timekeeping errseq +Low level entry and exit +======================== + +.. toctree:: + :maxdepth: 1 + + entry + Concurrency primitives ====================== diff --git a/Documentation/core-api/mm-api.rst b/Documentation/core-api/mm-api.rst index 395835f9289f..f5b2f92822c8 100644 --- a/Documentation/core-api/mm-api.rst +++ b/Documentation/core-api/mm-api.rst @@ -58,15 +58,30 @@ Virtually Contiguous Mappings File Mapping and Page Cache =========================== -.. kernel-doc:: mm/readahead.c - :export: +Filemap +------- .. kernel-doc:: mm/filemap.c :export: +Readahead +--------- + +.. kernel-doc:: mm/readahead.c + :doc: Readahead Overview + +.. kernel-doc:: mm/readahead.c + :export: + +Writeback +--------- + .. kernel-doc:: mm/page-writeback.c :export: +Truncate +-------- + .. kernel-doc:: mm/truncate.c :export: diff --git a/Documentation/core-api/pin_user_pages.rst b/Documentation/core-api/pin_user_pages.rst index fcf605be43d0..b18416f4500f 100644 --- a/Documentation/core-api/pin_user_pages.rst +++ b/Documentation/core-api/pin_user_pages.rst @@ -55,18 +55,18 @@ flags the caller provides. The caller is required to pass in a non-null struct pages* array, and the function then pins pages by incrementing each by a special value: GUP_PIN_COUNTING_BIAS. -For huge pages (and in fact, any compound page of more than 2 pages), the -GUP_PIN_COUNTING_BIAS scheme is not used. Instead, an exact form of pin counting -is achieved, by using the 3rd struct page in the compound page. A new struct -page field, hpage_pinned_refcount, has been added in order to support this. +For compound pages, the GUP_PIN_COUNTING_BIAS scheme is not used. Instead, +an exact form of pin counting is achieved, by using the 2nd struct page +in the compound page. A new struct page field, compound_pincount, has +been added in order to support this. This approach for compound pages avoids the counting upper limit problems that are discussed below. Those limitations would have been aggravated severely by huge pages, because each tail page adds a refcount to the head page. And in -fact, testing revealed that, without a separate hpage_pinned_refcount field, +fact, testing revealed that, without a separate compound_pincount field, page overflows were seen in some huge page stress tests. -This also means that huge pages and compound pages (of order > 1) do not suffer +This also means that huge pages and compound pages do not suffer from the false positives problem that is mentioned below.:: Function @@ -264,9 +264,9 @@ place.) Other diagnostics ================= -dump_page() has been enhanced slightly, to handle these new counting fields, and -to better report on compound pages in general. Specifically, for compound pages -with order > 1, the exact (hpage_pinned_refcount) pincount is reported. +dump_page() has been enhanced slightly, to handle these new counting +fields, and to better report on compound pages in general. Specifically, +for compound pages, the exact (compound_pincount) pincount is reported. References ========== diff --git a/Documentation/core-api/xarray.rst b/Documentation/core-api/xarray.rst index a137a0e6d068..77e0ece2b1d6 100644 --- a/Documentation/core-api/xarray.rst +++ b/Documentation/core-api/xarray.rst @@ -315,11 +315,15 @@ indeed the normal API is implemented in terms of the advanced API. The advanced API is only available to modules with a GPL-compatible license. The advanced API is based around the xa_state. This is an opaque data -structure which you declare on the stack using the XA_STATE() -macro. This macro initialises the xa_state ready to start walking -around the XArray. It is used as a cursor to maintain the position -in the XArray and let you compose various operations together without -having to restart from the top every time. +structure which you declare on the stack using the XA_STATE() macro. +This macro initialises the xa_state ready to start walking around the +XArray. It is used as a cursor to maintain the position in the XArray +and let you compose various operations together without having to restart +from the top every time. The contents of the xa_state are protected by +the rcu_read_lock() or the xas_lock(). If you need to drop whichever of +those locks is protecting your state and tree, you must call xas_pause() +so that future calls do not rely on the parts of the state which were +left unprotected. The xa_state is also used to store errors. You can call xas_error() to retrieve the error. All operations check whether diff --git a/Documentation/cpu-freq/cpu-drivers.rst b/Documentation/cpu-freq/cpu-drivers.rst index 3b32336a7803..d84ededb66f9 100644 --- a/Documentation/cpu-freq/cpu-drivers.rst +++ b/Documentation/cpu-freq/cpu-drivers.rst @@ -75,6 +75,9 @@ And optionally .resume - A pointer to a per-policy resume function which is called with interrupts disabled and _before_ the governor is started again. + .ready - A pointer to a per-policy ready function which is called after + the policy is fully initialized. + .attr - A pointer to a NULL-terminated list of "struct freq_attr" which allow to export values to sysfs. diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst index 8089c559d339..7614a1fc30fa 100644 --- a/Documentation/dev-tools/kasan.rst +++ b/Documentation/dev-tools/kasan.rst @@ -30,7 +30,7 @@ Software tag-based KASAN mode is only supported in Clang. The hardware KASAN mode (#3) relies on hardware to perform the checks but still requires a compiler version that supports memory tagging instructions. -This mode is supported in GCC 10+ and Clang 11+. +This mode is supported in GCC 10+ and Clang 12+. Both software KASAN modes work with SLUB and SLAB memory allocators, while the hardware tag-based KASAN currently only supports SLUB. @@ -206,6 +206,9 @@ additional boot parameters that allow disabling KASAN or controlling features: Asymmetric mode: a bad access is detected synchronously on reads and asynchronously on writes. +- ``kasan.vmalloc=off`` or ``=on`` disables or enables tagging of vmalloc + allocations (default: ``on``). + - ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack traces collection (default: ``on``). @@ -279,8 +282,8 @@ Software tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Software tag-based KASAN currently only supports tagging of slab and page_alloc -memory. +Software tag-based KASAN currently only supports tagging of slab, page_alloc, +and vmalloc memory. Hardware tag-based KASAN ~~~~~~~~~~~~~~~~~~~~~~~~ @@ -303,8 +306,8 @@ Hardware tag-based KASAN uses 0xFF as a match-all pointer tag (accesses through pointers with the 0xFF pointer tag are not checked). The value 0xFE is currently reserved to tag freed memory regions. -Hardware tag-based KASAN currently only supports tagging of slab and page_alloc -memory. +Hardware tag-based KASAN currently only supports tagging of slab, page_alloc, +and VM_ALLOC-based vmalloc memory. If the hardware does not support MTE (pre ARMv8.5), hardware tag-based KASAN will not be enabled. In this case, all KASAN boot parameters are ignored. @@ -319,6 +322,8 @@ checking gets disabled. Shadow memory ------------- +The contents of this section are only applicable to software KASAN modes. + The kernel maps memory in several different parts of the address space. The range of kernel virtual addresses is large: there is not enough real memory to support a real shadow region for every address that could be @@ -349,7 +354,7 @@ CONFIG_KASAN_VMALLOC With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the cost of greater memory usage. Currently, this is supported on x86, -riscv, s390, and powerpc. +arm64, riscv, s390, and powerpc. This works by hooking into vmalloc and vmap and dynamically allocating real shadow memory to back the mappings. diff --git a/Documentation/dev-tools/kfence.rst b/Documentation/dev-tools/kfence.rst index ac6b89d1a8c3..936f6aaa75c8 100644 --- a/Documentation/dev-tools/kfence.rst +++ b/Documentation/dev-tools/kfence.rst @@ -41,6 +41,18 @@ guarded by KFENCE. The default is configurable via the Kconfig option ``CONFIG_KFENCE_SAMPLE_INTERVAL``. Setting ``kfence.sample_interval=0`` disables KFENCE. +The sample interval controls a timer that sets up KFENCE allocations. By +default, to keep the real sample interval predictable, the normal timer also +causes CPU wake-ups when the system is completely idle. This may be undesirable +on power-constrained systems. The boot parameter ``kfence.deferrable=1`` +instead switches to a "deferrable" timer which does not force CPU wake-ups on +idle systems, at the risk of unpredictable sample intervals. The default is +configurable via the Kconfig option ``CONFIG_KFENCE_DEFERRABLE``. + +.. warning:: + The KUnit test suite is very likely to fail when using a deferrable timer + since it currently causes very unpredictable sample intervals. + The KFENCE memory pool is of fixed size, and if the pool is exhausted, no further KFENCE allocations occur. With ``CONFIG_KFENCE_NUM_OBJECTS`` (default 255), the number of available guarded objects can be controlled. Each object diff --git a/Documentation/dev-tools/kselftest.rst b/Documentation/dev-tools/kselftest.rst index dcefee707ccd..a833ecf12fbc 100644 --- a/Documentation/dev-tools/kselftest.rst +++ b/Documentation/dev-tools/kselftest.rst @@ -7,6 +7,14 @@ directory. These are intended to be small tests to exercise individual code paths in the kernel. Tests are intended to be run after building, installing and booting a kernel. +Kselftest from mainline can be run on older stable kernels. Running tests +from mainline offers the best coverage. Several test rings run mainline +kselftest suite on stable releases. The reason is that when a new test +gets added to test existing code to regression test a bug, we should be +able to run that test on an older kernel. Hence, it is important to keep +code that can still test an older kernel and make sure it skips the test +gracefully on newer releases. + You can find additional information on Kselftest framework, how to write new tests using the framework on Kselftest wiki: diff --git a/Documentation/dev-tools/ktap.rst b/Documentation/dev-tools/ktap.rst index 878530cb9c27..5ee735c6687f 100644 --- a/Documentation/dev-tools/ktap.rst +++ b/Documentation/dev-tools/ktap.rst @@ -1,8 +1,8 @@ .. SPDX-License-Identifier: GPL-2.0 -======================================== -The Kernel Test Anything Protocol (KTAP) -======================================== +=================================================== +The Kernel Test Anything Protocol (KTAP), version 1 +=================================================== TAP, or the Test Anything Protocol is a format for specifying test results used by a number of projects. It's website and specification are found at this `link @@ -68,7 +68,7 @@ Test case result lines Test case result lines indicate the final status of a test. They are required and must have the format: -.. code-block:: +.. code-block:: none <result> <number> [<description>][ # [<directive>] [<diagnostic data>]] @@ -117,32 +117,32 @@ separator. Example result lines include: -.. code-block:: +.. code-block:: none ok 1 test_case_name The test "test_case_name" passed. -.. code-block:: +.. code-block:: none not ok 1 test_case_name The test "test_case_name" failed. -.. code-block:: +.. code-block:: none ok 1 test # SKIP necessary dependency unavailable The test "test" was SKIPPED with the diagnostic message "necessary dependency unavailable". -.. code-block:: +.. code-block:: none not ok 1 test # TIMEOUT 30 seconds The test "test" timed out, with diagnostic data "30 seconds". -.. code-block:: +.. code-block:: none ok 5 check return code # rcode=0 @@ -174,6 +174,13 @@ There may be lines within KTAP output that do not follow the format of one of the four formats for lines described above. This is allowed, however, they will not influence the status of the tests. +This is an important difference from TAP. Kernel tests may print messages +to the system console or a log file. Both of these destinations may contain +messages either from unrelated kernel or userspace activity, or kernel +messages from non-test code that is invoked by the test. The kernel code +invoked by the test likely is not aware that a test is in progress and +thus can not print the message as a diagnostic message. + Nested tests ------------ @@ -186,13 +193,16 @@ starting with another KTAP version line and test plan, and end with the overall result. If one of the subtests fail, for example, the parent test should also fail. -Additionally, all result lines in a subtest should be indented. One level of +Additionally, all lines in a subtest should be indented. One level of indentation is two spaces: " ". The indentation should begin at the version line and should end before the parent test's result line. +"Unknown lines" are not considered to be lines in a subtest and thus are +allowed to be either indented or not indented. + An example of a test with two nested subtests: -.. code-block:: +.. code-block:: none KTAP version 1 1..1 @@ -205,7 +215,7 @@ An example of a test with two nested subtests: An example format with multiple levels of nested testing: -.. code-block:: +.. code-block:: none KTAP version 1 1..2 @@ -224,10 +234,15 @@ An example format with multiple levels of nested testing: Major differences between TAP and KTAP -------------------------------------- -Note the major differences between the TAP and KTAP specification: -- yaml and json are not recommended in diagnostic messages -- TODO directive not recognized -- KTAP allows for an arbitrary number of tests to be nested +================================================== ========= =============== +Feature TAP KTAP +================================================== ========= =============== +yaml and json in diagnosic message ok not recommended +TODO directive ok not recognized +allows an arbitrary number of tests to be nested no yes +"Unknown lines" are in category of "Anything else" yes no +"Unknown lines" are incorrect allowed +================================================== ========= =============== The TAP14 specification does permit nested tests, but instead of using another nested version line, uses a line of the form @@ -235,7 +250,7 @@ nested version line, uses a line of the form Example KTAP output -------------------- -.. code-block:: +.. code-block:: none KTAP version 1 1..1 diff --git a/Documentation/dev-tools/kunit/architecture.rst b/Documentation/dev-tools/kunit/architecture.rst index aa2cea821e25..ff9c85a0bff2 100644 --- a/Documentation/dev-tools/kunit/architecture.rst +++ b/Documentation/dev-tools/kunit/architecture.rst @@ -26,10 +26,7 @@ The fundamental unit in KUnit is the test case. The KUnit test cases are grouped into KUnit suites. A KUnit test case is a function with type signature ``void (*)(struct kunit *test)``. These test case functions are wrapped in a struct called -``struct kunit_case``. For code, see: - -.. kernel-doc:: include/kunit/test.h - :identifiers: kunit_case +struct kunit_case. .. note: ``generate_params`` is optional for non-parameterized tests. @@ -152,18 +149,12 @@ Parameterized Tests Each KUnit parameterized test is associated with a collection of parameters. The test is invoked multiple times, once for each parameter value and the parameter is stored in the ``param_value`` field. -The test case includes a ``KUNIT_CASE_PARAM()`` macro that accepts a +The test case includes a KUNIT_CASE_PARAM() macro that accepts a generator function. The generator function is passed the previous parameter and returns the next parameter. It also provides a macro to generate common-case generators based on arrays. -For code, see: - -.. kernel-doc:: include/kunit/test.h - :identifiers: KUNIT_ARRAY_PARAM - - kunit_tool (Command Line Test Harness) ====================================== diff --git a/Documentation/dev-tools/kunit/usage.rst b/Documentation/dev-tools/kunit/usage.rst index 76af931a332c..1c83e7d60a8a 100644 --- a/Documentation/dev-tools/kunit/usage.rst +++ b/Documentation/dev-tools/kunit/usage.rst @@ -242,7 +242,7 @@ example: int rectangle_area(struct shape *this) { - struct rectangle *self = container_of(this, struct shape, parent); + struct rectangle *self = container_of(this, struct rectangle, parent); return self->length * self->width; }; diff --git a/Documentation/dev-tools/sparse.rst b/Documentation/dev-tools/sparse.rst index 02102be7ff49..dc791c8d84d1 100644 --- a/Documentation/dev-tools/sparse.rst +++ b/Documentation/dev-tools/sparse.rst @@ -100,3 +100,5 @@ have already built it. The optional make variable CF can be used to pass arguments to sparse. The build system passes -Wbitwise to sparse automatically. + +Note that sparse defines the __CHECKER__ preprocessor symbol. diff --git a/Documentation/devicetree/bindings/Makefile b/Documentation/devicetree/bindings/Makefile index 41c555181b6f..c9953f86b19d 100644 --- a/Documentation/devicetree/bindings/Makefile +++ b/Documentation/devicetree/bindings/Makefile @@ -3,9 +3,10 @@ DT_DOC_CHECKER ?= dt-doc-validate DT_EXTRACT_EX ?= dt-extract-example DT_MK_SCHEMA ?= dt-mk-schema -DT_SCHEMA_LINT = $(shell which yamllint) +DT_SCHEMA_LINT = $(shell which yamllint || \ + echo "warning: python package 'yamllint' not installed, skipping" >&2) -DT_SCHEMA_MIN_VERSION = 2021.2.1 +DT_SCHEMA_MIN_VERSION = 2022.3 PHONY += check_dtschema_version check_dtschema_version: @@ -24,18 +25,11 @@ quiet_cmd_extract_ex = DTEX $@ $(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE $(call if_changed,extract_ex) -# Use full schemas when checking %.example.dts -DT_TMP_SCHEMA := $(obj)/processed-schema-examples.json - find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \ - -name 'processed-schema*' ! \ - -name '*.example.dt.yaml' \) + -name 'processed-schema*' \) -ifeq ($(DT_SCHEMA_FILES),) -find_cmd = $(find_all_cmd) -else -find_cmd = echo $(addprefix $(srctree)/, $(DT_SCHEMA_FILES)) -endif +find_cmd = $(find_all_cmd) | grep -F "$(DT_SCHEMA_FILES)" +CHK_DT_DOCS := $(shell $(find_cmd)) quiet_cmd_yamllint = LINT $(src) cmd_yamllint = ($(find_cmd) | \ @@ -72,35 +66,14 @@ override DTC_FLAGS := \ # Disable undocumented compatible checks until warning free override DT_CHECKER_FLAGS ?= -$(obj)/processed-schema-examples.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE +$(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE $(call if_changed_rule,chkdt) -ifeq ($(DT_SCHEMA_FILES),) - -# Unless DT_SCHEMA_FILES is specified, use the full schema for dtbs_check too. -# Just copy processed-schema-examples.json - -$(obj)/processed-schema.json: $(obj)/processed-schema-examples.json FORCE - $(call if_changed,copy) - -DT_SCHEMA_FILES = $(DT_DOCS) - -else - -# If DT_SCHEMA_FILES is specified, use it for processed-schema.json - -$(obj)/processed-schema.json: DT_MK_SCHEMA_FLAGS := -u -$(obj)/processed-schema.json: $(DT_SCHEMA_FILES) check_dtschema_version FORCE - $(call if_changed,mk_schema) - -endif - -always-$(CHECK_DT_BINDING) += processed-schema-examples.json -always-$(CHECK_DTBS) += processed-schema.json -always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dts, $(DT_SCHEMA_FILES)) -always-$(CHECK_DT_BINDING) += $(patsubst $(src)/%.yaml,%.example.dt.yaml, $(DT_SCHEMA_FILES)) +always-y += processed-schema.json +always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dts, $(CHK_DT_DOCS)) +always-$(CHECK_DT_BINDING) += $(patsubst $(srctree)/$(src)/%.yaml,%.example.dtb, $(CHK_DT_DOCS)) # Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of # build artifacts here before they are processed by scripts/Makefile.clean clean-files = $(shell find $(obj) \( -name '*.example.dts' -o \ - -name '*.example.dt.yaml' \) -delete 2>/dev/null) + -name '*.example.dtb' \) -delete 2>/dev/null) diff --git a/Documentation/devicetree/bindings/arm/airoha.yaml b/Documentation/devicetree/bindings/arm/airoha.yaml new file mode 100644 index 000000000000..fc19b1a6f37b --- /dev/null +++ b/Documentation/devicetree/bindings/arm/airoha.yaml @@ -0,0 +1,28 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/airoha.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha SoC based Platforms Device Tree Bindings + +maintainers: + - Felix Fietkau <nbd@nbd.name> + - John Crispin <john@phrozen.org> + +description: + Boards with an Airoha SoC shall have the following properties. + +properties: + $nodename: + const: '/' + compatible: + oneOf: + - items: + - enum: + - airoha,en7523-evb + - const: airoha,en7523 + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/altera.yaml b/Documentation/devicetree/bindings/arm/altera.yaml index c15c92fdf2ed..5e2017c0a051 100644 --- a/Documentation/devicetree/bindings/arm/altera.yaml +++ b/Documentation/devicetree/bindings/arm/altera.yaml @@ -13,12 +13,46 @@ properties: $nodename: const: "/" compatible: - items: - - enum: - - altr,socfpga-cyclone5 - - altr,socfpga-arria5 - - altr,socfpga-arria10 - - const: altr,socfpga + oneOf: + - description: Arria 5 boards + items: + - enum: + - altr,socfpga-arria5-socdk + - const: altr,socfpga-arria5 + - const: altr,socfpga + + - description: Arria 10 boards + items: + - enum: + - altr,socfpga-arria10-socdk + - enclustra,mercury-aa1 + - const: altr,socfpga-arria10 + - const: altr,socfpga + + - description: Cyclone 5 boards + items: + - enum: + - altr,socfpga-cyclone5-socdk + - denx,mcvevk + - ebv,socrates + - macnica,sodia + - novtech,chameleon96 + - samtec,vining + - terasic,de0-atlas + - terasic,socfpga-cyclone5-sockit + - const: altr,socfpga-cyclone5 + - const: altr,socfpga + + - description: Stratix 10 boards + items: + - enum: + - altr,socfpga-stratix10-socdk + - const: altr,socfpga-stratix10 + + - description: SoCFPGA VT + items: + - const: altr,socfpga-vt + - const: altr,socfpga additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/amlogic.yaml b/Documentation/devicetree/bindings/arm/amlogic.yaml index 36081734f720..61a6cabb375b 100644 --- a/Documentation/devicetree/bindings/arm/amlogic.yaml +++ b/Documentation/devicetree/bindings/arm/amlogic.yaml @@ -108,6 +108,7 @@ properties: - amlogic,p230 - amlogic,p231 - libretech,aml-s905d-pc + - osmc,vero4k-plus - phicomm,n1 - smartlabs,sml5442tw - videostrong,gxl-kii-pro @@ -170,9 +171,14 @@ properties: - description: Boards with the Amlogic Meson SM1 S905X3/D3/Y3 SoC items: - enum: + - amediatech,x96-air + - amediatech,x96-air-gbit - bananapi,bpi-m5 + - cyx,a95xf3-air + - cyx,a95xf3-air-gbit - hardkernel,odroid-c4 - hardkernel,odroid-hc4 + - haochuangyi,h96-max - khadas,vim3l - seirobotics,sei610 - const: amlogic,sm1 @@ -183,6 +189,12 @@ properties: - amlogic,ad401 - const: amlogic,a1 + - description: Boards with the Amlogic Meson S4 S805X2 SoC + items: + - enum: + - amlogic,aq222 + - const: amlogic,s4 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml index b6b5d3a912b3..0dc957a56d35 100644 --- a/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml +++ b/Documentation/devicetree/bindings/arm/apple/apple,pmgr.yaml @@ -42,7 +42,7 @@ patternProperties: description: The individual power management domains within this controller type: object - $ref: /power/apple,pmgr-pwrstate.yaml# + $ref: /schemas/power/apple,pmgr-pwrstate.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml index f8530a50863a..1706134b75a3 100644 --- a/Documentation/devicetree/bindings/arm/arm,cci-400.yaml +++ b/Documentation/devicetree/bindings/arm/arm,cci-400.yaml @@ -119,6 +119,11 @@ examples: arm,hbi = <0x249>; interrupt-parent = <&gic>; + gic: interrupt-controller { + interrupt-controller; + #interrupt-cells = <3>; + }; + /* * This CCI node corresponds to a CCI component whose control * registers sits at address 0x000000002c090000. diff --git a/Documentation/devicetree/bindings/arm/atmel-at91.yaml b/Documentation/devicetree/bindings/arm/atmel-at91.yaml index c612e1f48dba..4e495e03264b 100644 --- a/Documentation/devicetree/bindings/arm/atmel-at91.yaml +++ b/Documentation/devicetree/bindings/arm/atmel-at91.yaml @@ -8,7 +8,8 @@ title: Atmel AT91 device tree bindings. maintainers: - Alexandre Belloni <alexandre.belloni@bootlin.com> - - Ludovic Desroches <ludovic.desroches@microchip.com> + - Claudiu Beznea <claudiu.beznea@microchip.com> + - Nicolas Ferre <nicolas.ferre@microchip.com> description: | Boards with a SoC of the Atmel AT91 or SMART family shall have the following @@ -174,6 +175,15 @@ properties: - const: microchip,lan9668 - const: microchip,lan966 + - description: Kontron KSwitch D10 MMT series + items: + - enum: + - kontron,kswitch-d10-mmt-8g + - kontron,kswitch-d10-mmt-6g-2gs + - const: kontron,s1921 + - const: microchip,lan9668 + - const: microchip,lan966 + - items: - enum: - atmel,sams70j19 diff --git a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml index 5dc48241efb3..8051a75c2c79 100644 --- a/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml +++ b/Documentation/devicetree/bindings/arm/bcm/bcm2835.yaml @@ -51,6 +51,7 @@ properties: - raspberrypi,3-model-b-plus - raspberrypi,3-compute-module - raspberrypi,3-compute-module-lite + - raspberrypi,model-zero-2-w - const: brcm,bcm2837 additionalProperties: true diff --git a/Documentation/devicetree/bindings/arm/cpu-capacity.txt b/Documentation/devicetree/bindings/arm/cpu-capacity.txt index 380e21c5fc7e..cc5e190390b7 100644 --- a/Documentation/devicetree/bindings/arm/cpu-capacity.txt +++ b/Documentation/devicetree/bindings/arm/cpu-capacity.txt @@ -62,8 +62,8 @@ Example 1 (ARM 64-bit, 6-cpu system, two clusters): The capacities-dmips-mhz or DMIPS/MHz values (scaled to 1024) are 1024 and 578 for cluster0 and cluster1. Further normalization is done by the operating system based on cluster0@max-freq=1100 and -custer1@max-freq=850, final capacities are 1024 for cluster0 and -446 for cluster1 (576*850/1100). +cluster1@max-freq=850, final capacities are 1024 for cluster0 and +446 for cluster1 (578*850/1100). cpus { #address-cells = <2>; diff --git a/Documentation/devicetree/bindings/arm/cpus.yaml b/Documentation/devicetree/bindings/arm/cpus.yaml index 0dcebc48ea22..ed04650291a8 100644 --- a/Documentation/devicetree/bindings/arm/cpus.yaml +++ b/Documentation/devicetree/bindings/arm/cpus.yaml @@ -173,6 +173,7 @@ properties: - nvidia,tegra194-carmel - qcom,krait - qcom,kryo + - qcom,kryo250 - qcom,kryo260 - qcom,kryo280 - qcom,kryo385 @@ -232,17 +233,19 @@ properties: - ti,am4372 cpu-release-addr: - $ref: '/schemas/types.yaml#/definitions/uint64' - + oneOf: + - $ref: '/schemas/types.yaml#/definitions/uint32' + - $ref: '/schemas/types.yaml#/definitions/uint64' description: + The DT specification defines this as 64-bit always, but some 32-bit Arm + systems have used a 32-bit value which must be supported. Required for systems that have an "enable-method" property value of "spin-table". - On ARM v8 64-bit systems must be a two cell - property identifying a 64-bit zero-initialised - memory location. cpu-idle-states: $ref: '/schemas/types.yaml#/definitions/phandle-array' + items: + maxItems: 1 description: | List of phandles to idle state nodes supported by this cpu (see ./idle-states.yaml). diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt index b5cb374dc47d..10a91cc8b997 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,layerscape-dcfg.txt @@ -8,7 +8,7 @@ Required properties: - compatible: Should contain a chip-specific compatible string, Chip-specific strings are of the form "fsl,<chip>-dcfg", The following <chip>s are known to be supported: - ls1012a, ls1021a, ls1043a, ls1046a, ls2080a. + ls1012a, ls1021a, ls1043a, ls1046a, ls2080a, lx2160a - reg : should contain base address and length of DCFG memory-mapped registers diff --git a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt index fd0061712443..a87ec15e28d2 100644 --- a/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt +++ b/Documentation/devicetree/bindings/arm/freescale/fsl,scu.txt @@ -86,6 +86,7 @@ This binding uses the common clock binding[1]. Required properties: - compatible: Should be one of: + "fsl,imx8dxl-clk" "fsl,imx8qm-clk" "fsl,imx8qxp-clk" followed by "fsl,scu-clk" diff --git a/Documentation/devicetree/bindings/arm/fsl.yaml b/Documentation/devicetree/bindings/arm/fsl.yaml index 97f6eebad76a..08bdd30e511c 100644 --- a/Documentation/devicetree/bindings/arm/fsl.yaml +++ b/Documentation/devicetree/bindings/arm/fsl.yaml @@ -762,6 +762,7 @@ properties: - enum: - beacon,imx8mm-beacon-kit # i.MX8MM Beacon Development Kit - boundary,imx8mm-nitrogen8mm # i.MX8MM Nitrogen Board + - emtrion,emcon-mx8mm-avari # emCON-MX8MM SoM on Avari Base - fsl,imx8mm-ddr4-evk # i.MX8MM DDR4 EVK Board - fsl,imx8mm-evk # i.MX8MM EVK Board - gw,imx8mm-gw71xx-0x # i.MX8MM Gateworks Development Kit @@ -769,8 +770,13 @@ properties: - gw,imx8mm-gw73xx-0x # i.MX8MM Gateworks Development Kit - gw,imx8mm-gw7901 # i.MX8MM Gateworks Board - gw,imx8mm-gw7902 # i.MX8MM Gateworks Board + - gw,imx8mm-gw7903 # i.MX8MM Gateworks Board - kontron,imx8mm-n801x-som # i.MX8MM Kontron SL (N801X) SOM + - toradex,verdin-imx8mm # Verdin iMX8M Mini Modules + - toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Modules without Wi-Fi / BT + - toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Modules - variscite,var-som-mx8mm # i.MX8MM Variscite VAR-SOM-MX8MM module + - prt,prt8mm # i.MX8MM Protonic PRT8MM Board - const: fsl,imx8mm - description: Engicam i.Core MX8M Mini SoM based boards @@ -787,6 +793,24 @@ properties: - const: kontron,imx8mm-n801x-som - const: fsl,imx8mm + - description: Toradex Boards with Verdin iMX8M Mini Modules + items: + - enum: + - toradex,verdin-imx8mm-nonwifi-dahlia # Verdin iMX8M Mini Module on Dahlia + - toradex,verdin-imx8mm-nonwifi-dev # Verdin iMX8M Mini Module on Verdin Development Board + - const: toradex,verdin-imx8mm-nonwifi # Verdin iMX8M Mini Module without Wi-Fi / BT + - const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module + - const: fsl,imx8mm + + - description: Toradex Boards with Verdin iMX8M Mini Wi-Fi / BT Modules + items: + - enum: + - toradex,verdin-imx8mm-wifi-dahlia # Verdin iMX8M Mini Wi-Fi / BT Module on Dahlia + - toradex,verdin-imx8mm-wifi-dev # Verdin iMX8M Mini Wi-Fi / BT M. on Verdin Development B. + - const: toradex,verdin-imx8mm-wifi # Verdin iMX8M Mini Wi-Fi / BT Module + - const: toradex,verdin-imx8mm # Verdin iMX8M Mini Module + - const: fsl,imx8mm + - description: Variscite VAR-SOM-MX8MM based boards items: - const: variscite,var-som-mx8mm-symphony diff --git a/Documentation/devicetree/bindings/arm/fw-cfg.txt b/Documentation/devicetree/bindings/arm/fw-cfg.txt deleted file mode 100644 index fd54e1db2156..000000000000 --- a/Documentation/devicetree/bindings/arm/fw-cfg.txt +++ /dev/null @@ -1,38 +0,0 @@ -* QEMU Firmware Configuration bindings for ARM - -QEMU's arm-softmmu and aarch64-softmmu emulation / virtualization targets -provide the following Firmware Configuration interface on the "virt" machine -type: - -- A write-only, 16-bit wide selector (or control) register, -- a read-write, 64-bit wide data register. - -QEMU exposes the control and data register to ARM guests as memory mapped -registers; their location is communicated to the guest's UEFI firmware in the -DTB that QEMU places at the bottom of the guest's DRAM. - -The authoritative guest-side hardware interface documentation to the fw_cfg -device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree. - - -Required properties: - -- compatible: "qemu,fw-cfg-mmio". - -- reg: the MMIO region used by the device. - * Bytes 0x0 to 0x7 cover the data register. - * Bytes 0x8 to 0x9 cover the selector register. - * Further registers may be appended to the region in case of future interface - revisions / feature bits. - -Example: - -/ { - #size-cells = <0x2>; - #address-cells = <0x2>; - - fw-cfg@9020000 { - compatible = "qemu,fw-cfg-mmio"; - reg = <0x0 0x9020000 0x0 0xa>; - }; -}; diff --git a/Documentation/devicetree/bindings/arm/intel,socfpga.yaml b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml new file mode 100644 index 000000000000..6e043459fcd5 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/intel,socfpga.yaml @@ -0,0 +1,26 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/intel,socfpga.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA platform device tree bindings + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + +properties: + $nodename: + const: "/" + compatible: + oneOf: + - description: AgileX boards + items: + - enum: + - intel,n5x-socdk + - intel,socfpga-agilex-socdk + - const: intel,socfpga-agilex + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml b/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml new file mode 100644 index 000000000000..c7c5eb48fc7e --- /dev/null +++ b/Documentation/devicetree/bindings/arm/linux,dummy-virt.yaml @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/linux,dummy-virt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QEMU virt machine + +maintainers: + - Rob Herring <robh@kernel.org> + +properties: + $nodename: + const: "/" + compatible: + const: linux,dummy-virt + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/mediatek.yaml b/Documentation/devicetree/bindings/arm/mediatek.yaml index 0ffe1acf1344..ab0593c77321 100644 --- a/Documentation/devicetree/bindings/arm/mediatek.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek.yaml @@ -32,6 +32,10 @@ properties: - const: mediatek,mt6580 - items: - enum: + - prestigio,pmt5008-3g + - const: mediatek,mt6582 + - items: + - enum: - fairphone,fp1 - mundoreader,bq-aquaris5 - const: mediatek,mt6589 diff --git a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml index 763c62323a74..b31d90dc9eb4 100644 --- a/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml +++ b/Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml @@ -29,6 +29,7 @@ properties: - mediatek,mt8167-mmsys - mediatek,mt8173-mmsys - mediatek,mt8183-mmsys + - mediatek,mt8186-mmsys - mediatek,mt8192-mmsys - mediatek,mt8365-mmsys - const: syscon diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt index 6ce0b212ec6d..606b4b1b709d 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt +++ b/Documentation/devicetree/bindings/arm/msm/qcom,idle-state.txt @@ -81,4 +81,4 @@ Example: }; }; -[1]. Documentation/devicetree/bindings/arm/idle-states.yaml +[1]. Documentation/devicetree/bindings/cpu/idle-states.yaml diff --git a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml index 03882aac8d2d..30fcbe2ad8a3 100644 --- a/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml +++ b/Documentation/devicetree/bindings/arm/msm/qcom,llcc.yaml @@ -27,6 +27,8 @@ properties: - qcom,sm6350-llcc - qcom,sm8150-llcc - qcom,sm8250-llcc + - qcom,sm8350-llcc + - qcom,sm8450-llcc reg: items: diff --git a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml index a316eef1b728..8892eb6bd3ef 100644 --- a/Documentation/devicetree/bindings/arm/mstar/mstar.yaml +++ b/Documentation/devicetree/bindings/arm/mstar/mstar.yaml @@ -23,8 +23,12 @@ properties: - description: infinity2m boards items: - enum: + - 100ask,dongshanpione # 100ask DongShanPiOne - honestar,ssd201htv2 # Honestar SSD201_HT_V2 devkit - m5stack,unitv2 # M5Stack UnitV2 + - miyoo,miyoo-mini # Miyoo Mini + - wirelesstag,ido-som2d01 # Wireless Tag IDO-SOM2D01 + - wirelesstag,ido-sbc2d06-v1b-22w # Wireless Tag IDO-SBC2D06-1VB-22W - const: mstar,infinity2m - description: infinity3 boards diff --git a/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml new file mode 100644 index 000000000000..fcb211add7d3 --- /dev/null +++ b/Documentation/devicetree/bindings/arm/npcm/nuvoton,gcr.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/npcm/nuvoton,gcr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Global Control Registers block in Nuvoton SoCs + +maintainers: + - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + +description: + The Global Control Registers (GCR) are a block of registers in Nuvoton SoCs + that expose misc functionality such as chip model and version information or + pinmux settings. + +properties: + compatible: + items: + - enum: + - nuvoton,wpcm450-gcr + - nuvoton,npcm750-gcr + - const: syscon + - const: simple-mfd + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: + type: object + +examples: + - | + gcr: syscon@800000 { + compatible = "nuvoton,npcm750-gcr", "syscon", "simple-mfd"; + reg = <0x800000 0x1000>; + + mux-controller { + compatible = "mmio-mux"; + #mux-control-cells = <1>; + mux-reg-masks = <0x38 0x07>; + idle-states = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/arm/omap/omap.txt b/Documentation/devicetree/bindings/arm/omap/omap.txt index e77635c5422c..fa8b31660cad 100644 --- a/Documentation/devicetree/bindings/arm/omap/omap.txt +++ b/Documentation/devicetree/bindings/arm/omap/omap.txt @@ -119,6 +119,9 @@ Boards (incomplete list of examples): - OMAP3 BeagleBoard : Low cost community board compatible = "ti,omap3-beagle", "ti,omap3430", "ti,omap3" +- OMAP3 BeagleBoard A to B4 : Early BeagleBoard revisions A to B4 with a timer quirk + compatible = "ti,omap3-beagle-ab4", "ti,omap3-beagle", "ti,omap3430", "ti,omap3" + - OMAP3 Tobi with Overo : Commercial expansion board with daughter board compatible = "gumstix,omap3-overo-tobi", "gumstix,omap3-overo", "ti,omap3430", "ti,omap3" diff --git a/Documentation/devicetree/bindings/arm/pmu.yaml b/Documentation/devicetree/bindings/arm/pmu.yaml index 981bac451698..dbb6f3dc5ae5 100644 --- a/Documentation/devicetree/bindings/arm/pmu.yaml +++ b/Documentation/devicetree/bindings/arm/pmu.yaml @@ -20,6 +20,8 @@ properties: items: - enum: - apm,potenza-pmu + - apple,firestorm-pmu + - apple,icestorm-pmu - arm,armv8-pmuv3 # Only for s/w models - arm,arm1136-pmu - arm,arm1176-pmu @@ -66,6 +68,8 @@ properties: interrupt-affinity: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: When using SPIs, specifies a list of phandles to CPU nodes corresponding directly to the affinity of diff --git a/Documentation/devicetree/bindings/arm/psci.yaml b/Documentation/devicetree/bindings/arm/psci.yaml index 8b77cf83a095..dd83ef278af0 100644 --- a/Documentation/devicetree/bindings/arm/psci.yaml +++ b/Documentation/devicetree/bindings/arm/psci.yaml @@ -101,7 +101,7 @@ properties: bindings in [1]) must specify this property. [1] Kernel documentation - ARM idle states bindings - Documentation/devicetree/bindings/arm/idle-states.yaml + Documentation/devicetree/bindings/cpu/idle-states.yaml patternProperties: "^power-domain-": diff --git a/Documentation/devicetree/bindings/arm/qcom.yaml b/Documentation/devicetree/bindings/arm/qcom.yaml index 370aab274cd1..129cdd246223 100644 --- a/Documentation/devicetree/bindings/arm/qcom.yaml +++ b/Documentation/devicetree/bindings/arm/qcom.yaml @@ -42,13 +42,13 @@ description: | sc7180 sc7280 sdm630 + sdm632 sdm660 sdm845 sdx55 sdx65 sm7225 sm8150 - sdx65 sm8250 sm8350 sm8450 @@ -173,7 +173,21 @@ properties: - const: qcom,apq8094 - items: - - const: qcom,msm8996-mtp + - enum: + - arrow,apq8096-db820c + - inforce,ifc6640 + - const: qcom,apq8096-sbc + - const: qcom,apq8096 + + - items: + - enum: + - qcom,msm8996-mtp + - sony,dora-row + - sony,kagura-row + - sony,keyaki-row + - xiaomi,gemini + - xiaomi,scorpio + - const: qcom,msm8996 - items: - enum: @@ -213,6 +227,11 @@ properties: - items: - enum: + - fairphone,fp3 + - const: qcom,sdm632 + + - items: + - enum: - xiaomi,lavender - const: qcom,sdm660 @@ -230,11 +249,6 @@ properties: - items: - enum: - - qcom,sdx65-mtp - - const: qcom,sdx65 - - - items: - - enum: - qcom,ipq6018-cp01 - qcom,ipq6018-cp01-c1 - const: qcom,ipq6018 @@ -268,6 +282,7 @@ properties: - items: - enum: + - qcom,sm8450-hdk - qcom,sm8450-qrd - const: qcom,sm8450 diff --git a/Documentation/devicetree/bindings/arm/renesas.yaml b/Documentation/devicetree/bindings/arm/renesas.yaml index 6a9350ee690b..fa435d6fda77 100644 --- a/Documentation/devicetree/bindings/arm/renesas.yaml +++ b/Documentation/devicetree/bindings/arm/renesas.yaml @@ -421,6 +421,15 @@ properties: - renesas,r9a07g044l2 # Dual Cortex-A55 RZ/G2L - const: renesas,r9a07g044 + - description: RZ/V2L (R9A07G054) + items: + - enum: + - renesas,smarc-evk # SMARC EVK + - enum: + - renesas,r9a07g054l1 # Single Cortex-A55 RZ/V2L + - renesas,r9a07g054l2 # Dual Cortex-A55 RZ/V2L + - const: renesas,r9a07g054 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml index 4aed16176434..eece92f83a2d 100644 --- a/Documentation/devicetree/bindings/arm/rockchip.yaml +++ b/Documentation/devicetree/bindings/arm/rockchip.yaml @@ -481,6 +481,14 @@ properties: - const: pine64,pinebook-pro - const: rockchip,rk3399 + - description: Pine64 PineNote + items: + - enum: + - pine64,pinenote-v1.1 + - pine64,pinenote-v1.2 + - const: pine64,pinenote + - const: rockchip,rk3566 + - description: Pine64 Rock64 items: - const: pine64,rock64 @@ -651,6 +659,11 @@ properties: - const: rockchip,rk3568-evb1-v10 - const: rockchip,rk3568 + - description: Rockchip RK3568 Banana Pi R2 Pro + items: + - const: rockchip,rk3568-bpi-r2pro + - const: rockchip,rk3568 + additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml index 052cd94113d4..faea33e4f731 100644 --- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml +++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml @@ -140,6 +140,8 @@ properties: items: - enum: - insignal,arndale-octa # Insignal Arndale Octa + - samsung,chagall-wifi # Samsung SM-T800 + - samsung,klimt-wifi # Samsung SM-T700 - samsung,smdk5420 # Samsung SMDK5420 eval - const: samsung,exynos5420 - const: samsung,exynos5 diff --git a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml index b07720ea9611..fa0a1b84122e 100644 --- a/Documentation/devicetree/bindings/arm/stm32/stm32.yaml +++ b/Documentation/devicetree/bindings/arm/stm32/stm32.yaml @@ -28,6 +28,12 @@ properties: - enum: - st,stm32mp153 - st,stm32mp157 + + - description: emtrion STM32MP1 Argon based Boards + items: + - const: emtrion,stm32mp157c-emsbc-argon + - const: emtrion,stm32mp157c-emstamp-argon + - const: st,stm32mp157 - items: - enum: - st,stm32f429i-disco diff --git a/Documentation/devicetree/bindings/arm/sunxi.yaml b/Documentation/devicetree/bindings/arm/sunxi.yaml index c8a3102c0fde..086c68771d2b 100644 --- a/Documentation/devicetree/bindings/arm/sunxi.yaml +++ b/Documentation/devicetree/bindings/arm/sunxi.yaml @@ -444,6 +444,11 @@ properties: - const: haoyu,a10-marsboard - const: allwinner,sun4i-a10 + - description: HAOYU Electronics Marsboard A20 + items: + - const: haoyu,a20-marsboard + - const: allwinner,sun7i-a20 + - description: MapleBoard MP130 items: - const: mapleboard,mp130 diff --git a/Documentation/devicetree/bindings/arm/tesla.yaml b/Documentation/devicetree/bindings/arm/tesla.yaml new file mode 100644 index 000000000000..09856da657dc --- /dev/null +++ b/Documentation/devicetree/bindings/arm/tesla.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/arm/tesla.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tesla Full Self Driving(FSD) platforms device tree bindings + +maintainers: + - Alim Akhtar <alim.akhtar@samsung.com> + - linux-fsd@tesla.com + +properties: + $nodename: + const: '/' + compatible: + oneOf: + + - description: FSD SoC board + items: + - enum: + - tesla,fsd-evb # Tesla FSD Evaluation + - const: tesla,fsd + +additionalProperties: true + +... diff --git a/Documentation/devicetree/bindings/arm/ti/k3.yaml b/Documentation/devicetree/bindings/arm/ti/k3.yaml index b03c10fa2e7a..61c6ab4f52e2 100644 --- a/Documentation/devicetree/bindings/arm/ti/k3.yaml +++ b/Documentation/devicetree/bindings/arm/ti/k3.yaml @@ -46,6 +46,12 @@ properties: - ti,j7200-evm - const: ti,j7200 + - description: K3 AM625 SoC + items: + - enum: + - ti,am625-sk + - const: ti,am625 + - description: K3 AM642 SoC items: - enum: diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.txt b/Documentation/devicetree/bindings/ata/ahci-platform.txt deleted file mode 100644 index 77091a277642..000000000000 --- a/Documentation/devicetree/bindings/ata/ahci-platform.txt +++ /dev/null @@ -1,79 +0,0 @@ -* AHCI SATA Controller - -SATA nodes are defined to describe on-chip Serial ATA controllers. -Each SATA controller should have its own node. - -It is possible, but not required, to represent each port as a sub-node. -It allows to enable each port independently when dealing with multiple -PHYs. - -Required properties: -- compatible : compatible string, one of: - - "brcm,iproc-ahci" - - "hisilicon,hisi-ahci" - - "cavium,octeon-7130-ahci" - - "ibm,476gtr-ahci" - - "marvell,armada-380-ahci" - - "marvell,armada-3700-ahci" - - "snps,dwc-ahci" - - "snps,spear-ahci" - - "generic-ahci" -- interrupts : <interrupt mapping for SATA IRQ> -- reg : <registers mapping> - -Please note that when using "generic-ahci" you must also specify a SoC specific -compatible: - compatible = "manufacturer,soc-model-ahci", "generic-ahci"; - -Optional properties: -- dma-coherent : Present if dma operations are coherent -- clocks : a list of phandle + clock specifier pairs -- resets : a list of phandle + reset specifier pairs -- target-supply : regulator for SATA target power -- phy-supply : regulator for PHY power -- phys : reference to the SATA PHY node -- phy-names : must be "sata-phy" -- ahci-supply : regulator for AHCI controller -- ports-implemented : Mask that indicates which ports that the HBA supports - are available for software to use. Useful if PORTS_IMPL - is not programmed by the BIOS, which is true with - some embedded SOC's. - -Required properties when using sub-nodes: -- #address-cells : number of cells to encode an address -- #size-cells : number of cells representing the size of an address - -Sub-nodes required properties: -- reg : the port number -And at least one of the following properties: -- phys : reference to the SATA PHY node -- target-supply : regulator for SATA target power - -Examples: - sata@ffe08000 { - compatible = "snps,spear-ahci"; - reg = <0xffe08000 0x1000>; - interrupts = <115>; - }; - -With sub-nodes: - sata@f7e90000 { - compatible = "marvell,berlin2q-achi", "generic-ahci"; - reg = <0xe90000 0x1000>; - interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&chip CLKID_SATA>; - #address-cells = <1>; - #size-cells = <0>; - - sata0: sata-port@0 { - reg = <0>; - phys = <&sata_phy 0>; - target-supply = <®_sata0>; - }; - - sata1: sata-port@1 { - reg = <1>; - phys = <&sata_phy 1>; - target-supply = <®_sata1>;; - }; - }; diff --git a/Documentation/devicetree/bindings/ata/ahci-platform.yaml b/Documentation/devicetree/bindings/ata/ahci-platform.yaml new file mode 100644 index 000000000000..c146ab8e14e5 --- /dev/null +++ b/Documentation/devicetree/bindings/ata/ahci-platform.yaml @@ -0,0 +1,189 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/ahci-platform.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: AHCI SATA Controller + +description: | + SATA nodes are defined to describe on-chip Serial ATA controllers. + Each SATA controller should have its own node. + + It is possible, but not required, to represent each port as a sub-node. + It allows to enable each port independently when dealing with multiple + PHYs. + +maintainers: + - Hans de Goede <hdegoede@redhat.com> + - Jens Axboe <axboe@kernel.dk> + +select: + properties: + compatible: + contains: + enum: + - brcm,iproc-ahci + - cavium,octeon-7130-ahci + - hisilicon,hisi-ahci + - ibm,476gtr-ahci + - marvell,armada-3700-ahci + - marvell,armada-8k-ahci + - marvell,berlin2q-ahci + - snps,dwc-ahci + - snps,spear-ahci + required: + - compatible + +allOf: + - $ref: "sata-common.yaml#" + + +properties: + compatible: + oneOf: + - items: + - enum: + - brcm,iproc-ahci + - marvell,armada-8k-ahci + - marvell,berlin2-ahci + - marvell,berlin2q-ahci + - const: generic-ahci + - items: + - enum: + - rockchip,rk3568-dwc-ahci + - const: snps,dwc-ahci + - enum: + - cavium,octeon-7130-ahci + - hisilicon,hisi-ahci + - ibm,476gtr-ahci + - marvell,armada-3700-ahci + - snps,dwc-ahci + - snps,spear-ahci + + reg: + minItems: 1 + maxItems: 2 + + reg-names: + maxItems: 1 + + clocks: + description: + Clock IDs array as required by the controller. + minItems: 1 + maxItems: 3 + + clock-names: + description: + Names of clocks corresponding to IDs in the clock property. + minItems: 1 + maxItems: 3 + + interrupts: + maxItems: 1 + + ahci-supply: + description: + regulator for AHCI controller + + dma-coherent: true + + phy-supply: + description: + regulator for PHY power + + phys: + description: + List of all PHYs on this controller + maxItems: 1 + + phy-names: + description: + Name specifier for the PHYs + maxItems: 1 + + ports-implemented: + $ref: '/schemas/types.yaml#/definitions/uint32' + description: | + Mask that indicates which ports that the HBA supports + are available for software to use. Useful if PORTS_IMPL + is not programmed by the BIOS, which is true with + some embedded SoCs. + maximum: 0x1f + + power-domains: + maxItems: 1 + + resets: + maxItems: 1 + + target-supply: + description: + regulator for SATA target power + +required: + - compatible + - reg + - interrupts + +patternProperties: + "^sata-port@[0-9a-f]+$": + type: object + additionalProperties: false + description: + Subnode with configuration of the Ports. + + properties: + reg: + maxItems: 1 + + phys: + maxItems: 1 + + phy-names: + maxItems: 1 + + target-supply: + description: + regulator for SATA target power + + required: + - reg + + anyOf: + - required: [ phys ] + - required: [ target-supply ] + +unevaluatedProperties: false + +examples: + - | + sata@ffe08000 { + compatible = "snps,spear-ahci"; + reg = <0xffe08000 0x1000>; + interrupts = <115>; + }; + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/berlin2q.h> + sata@f7e90000 { + compatible = "marvell,berlin2q-ahci", "generic-ahci"; + reg = <0xf7e90000 0x1000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&chip CLKID_SATA>; + #address-cells = <1>; + #size-cells = <0>; + + sata0: sata-port@0 { + reg = <0>; + phys = <&sata_phy 0>; + target-supply = <®_sata0>; + }; + + sata1: sata-port@1 { + reg = <1>; + phys = <&sata_phy 1>; + target-supply = <®_sata1>; + }; + }; diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt deleted file mode 100644 index 1c3d3cc70051..000000000000 --- a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.txt +++ /dev/null @@ -1,55 +0,0 @@ -* Cortina Systems Gemini SATA Bridge - -The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that -takes two Faraday Technology FTIDE010 PATA controllers and bridges -them in different configurations to two SATA ports. - -Required properties: -- compatible: should be - "cortina,gemini-sata-bridge" -- reg: registers and size for the block -- resets: phandles to the reset lines for both SATA bridges -- reset-names: must be "sata0", "sata1" -- clocks: phandles to the compulsory peripheral clocks -- clock-names: must be "SATA0_PCLK", "SATA1_PCLK" -- syscon: a phandle to the global Gemini system controller -- cortina,gemini-ata-muxmode: tell the desired multiplexing mode for - the ATA controller and SATA bridges. Values 0..3: - Mode 0: ata0 master <-> sata0 - ata1 master <-> sata1 - ata0 slave interface brought out on IDE pads - Mode 1: ata0 master <-> sata0 - ata1 master <-> sata1 - ata1 slave interface brought out on IDE pads - Mode 2: ata1 master <-> sata1 - ata1 slave <-> sata0 - ata0 master and slave interfaces brought out - on IDE pads - Mode 3: ata0 master <-> sata0 - ata0 slave <-> sata1 - ata1 master and slave interfaces brought out - on IDE pads - -Optional boolean properties: -- cortina,gemini-enable-ide-pins: enables the PATA to IDE connection. - The muxmode setting decides whether ATA0 or ATA1 is brought out, - and whether master, slave or both interfaces get brought out. -- cortina,gemini-enable-sata-bridge: enables the PATA to SATA bridge - inside the Gemnini SoC. The Muxmode decides what PATA blocks will - be muxed out and how. - -Example: - -sata: sata@46000000 { - compatible = "cortina,gemini-sata-bridge"; - reg = <0x46000000 0x100>; - resets = <&rcon 26>, <&rcon 27>; - reset-names = "sata0", "sata1"; - clocks = <&gcc GEMINI_CLK_GATE_SATA0>, - <&gcc GEMINI_CLK_GATE_SATA1>; - clock-names = "SATA0_PCLK", "SATA1_PCLK"; - syscon = <&syscon>; - cortina,gemini-ata-muxmode = <3>; - cortina,gemini-enable-ide-pins; - cortina,gemini-enable-sata-bridge; -}; diff --git a/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml new file mode 100644 index 000000000000..21a90975593b --- /dev/null +++ b/Documentation/devicetree/bindings/ata/cortina,gemini-sata-bridge.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ata/cortina,gemini-sata-bridge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina Systems Gemini SATA Bridge + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + The Gemini SATA bridge in a SoC-internal PATA to SATA bridge that + takes two Faraday Technology FTIDE010 PATA controllers and bridges + them in different configurations to two SATA ports. + +properties: + compatible: + const: cortina,gemini-sata-bridge + + reg: + maxItems: 1 + + resets: + minItems: 2 + maxItems: 2 + description: phandles to the reset lines for both SATA bridges + + reset-names: + items: + - const: sata0 + - const: sata1 + + clocks: + minItems: 2 + maxItems: 2 + description: phandles to the compulsory peripheral clocks + + clock-names: + items: + - const: SATA0_PCLK + - const: SATA1_PCLK + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: a phandle to the global Gemini system controller + + cortina,gemini-ata-muxmode: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 + - 1 + - 2 + - 3 + description: | + Tell the desired multiplexing mode for the ATA controller and SATA + bridges. + Mode 0: ata0 master <-> sata0 + ata1 master <-> sata1 + ata0 slave interface brought out on IDE pads + Mode 1: ata0 master <-> sata0 + ata1 master <-> sata1 + ata1 slave interface brought out on IDE pads + Mode 2: ata1 master <-> sata1 + ata1 slave <-> sata0 + ata0 master and slave interfaces brought out on IDE pads + Mode 3: ata0 master <-> sata0 + ata0 slave <-> sata1 + ata1 master and slave interfaces brought out on IDE pads + + cortina,gemini-enable-ide-pins: + type: boolean + description: Enables the PATA to IDE connection. + The muxmode setting decides whether ATA0 or ATA1 is brought out, + and whether master, slave or both interfaces get brought out. + + cortina,gemini-enable-sata-bridge: + type: boolean + description: Enables the PATA to SATA bridge inside the Gemnini SoC. + The Muxmode decides what PATA blocks will be muxed out and how. + +required: + - clocks + - clock-names + - cortina,gemini-ata-muxmode + - resets + - reset-names + - compatible + - reg + - syscon + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cortina,gemini-clock.h> + sata@46000000 { + compatible = "cortina,gemini-sata-bridge"; + reg = <0x46000000 0x100>; + resets = <&rcon 26>, <&rcon 27>; + reset-names = "sata0", "sata1"; + clocks = <&gcc GEMINI_CLK_GATE_SATA0>, + <&gcc GEMINI_CLK_GATE_SATA1>; + clock-names = "SATA0_PCLK", "SATA1_PCLK"; + syscon = <&syscon>; + cortina,gemini-ata-muxmode = <3>; + cortina,gemini-enable-ide-pins; + cortina,gemini-enable-sata-bridge; + }; diff --git a/Documentation/devicetree/bindings/ata/sata_highbank.yaml b/Documentation/devicetree/bindings/ata/sata_highbank.yaml index ce75d77e9289..49679b58041c 100644 --- a/Documentation/devicetree/bindings/ata/sata_highbank.yaml +++ b/Documentation/devicetree/bindings/ata/sata_highbank.yaml @@ -51,6 +51,9 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 8 + items: + minItems: 2 + maxItems: 2 calxeda,tx-atten: description: | diff --git a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml index 863a287ebc7e..ad313ccaaaef 100644 --- a/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml +++ b/Documentation/devicetree/bindings/bus/allwinner,sun50i-a64-de2.yaml @@ -35,7 +35,10 @@ properties: The SRAM that needs to be claimed to access the display engine bus. $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to SRAM + - description: register value for device ranges: true diff --git a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml index 7b1a08c62aef..d3ed048c9521 100644 --- a/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml +++ b/Documentation/devicetree/bindings/bus/nvidia,tegra210-aconnect.yaml @@ -21,6 +21,7 @@ properties: - const: nvidia,tegra210-aconnect - items: - enum: + - nvidia,tegra234-aconnect - nvidia,tegra186-aconnect - nvidia,tegra194-aconnect - const: nvidia,tegra210-aconnect diff --git a/Documentation/devicetree/bindings/clock/apple,nco.yaml b/Documentation/devicetree/bindings/clock/apple,nco.yaml new file mode 100644 index 000000000000..74eab5c0d24a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/apple,nco.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/apple,nco.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple SoCs' NCO block + +maintainers: + - Martin PoviÅ¡er <povik+lin@cutebit.org> + +description: | + The NCO (Numerically Controlled Oscillator) block found on Apple SoCs + such as the t8103 (M1) is a programmable clock generator performing + fractional division of a high frequency input clock. + + It carries a number of independent channels and is typically used for + generation of audio bitclocks. + +properties: + compatible: + items: + - enum: + - apple,t6000-nco + - apple,t8103-nco + - const: apple,nco + + clocks: + description: + Specifies the reference clock from which the output clocks + are derived through fractional division. + maxItems: 1 + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + nco_clkref: clock-ref { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <900000000>; + clock-output-names = "nco-ref"; + }; + + nco: clock-controller@23b044000 { + compatible = "apple,t8103-nco", "apple,nco"; + reg = <0x3b044000 0x14000>; + #clock-cells = <1>; + clocks = <&nco_clkref>; + }; diff --git a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml index 228c9313df53..f0f9392470a6 100644 --- a/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml +++ b/Documentation/devicetree/bindings/clock/bitmain,bm1880-clk.yaml @@ -61,16 +61,4 @@ examples: #clock-cells = <1>; }; - # Example UART controller node that consumes clock generated by the clock controller: - - | - uart0: serial@58018000 { - compatible = "snps,dw-apb-uart"; - reg = <0x58018000 0x2000>; - clocks = <&clk 45>, <&clk 46>; - clock-names = "baudclk", "apb_pclk"; - interrupts = <0 9 4>; - reg-shift = <2>; - reg-io-width = <4>; - }; - ... diff --git a/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml new file mode 100644 index 000000000000..0abd6ba82dfd --- /dev/null +++ b/Documentation/devicetree/bindings/clock/cirrus,cs2000-cp.yaml @@ -0,0 +1,91 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/cirrus,cs2000-cp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier + +maintainers: + - Kuninori Morimoto <kuninori.morimoto.gx@renesas.com> + +description: | + The CS2000-CP is an extremely versatile system clocking device that + utilizes a programmable phase lock loop. + + Link: https://www.cirrus.com/products/cs2000/ + +properties: + compatible: + enum: + - cirrus,cs2000-cp + + clocks: + description: + Common clock binding for CLK_IN, XTI/REF_CLK + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: clk_in + - const: ref_clk + + '#clock-cells': + const: 0 + + reg: + maxItems: 1 + + cirrus,aux-output-source: + description: + Specifies the function of the auxiliary clock output pin + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 0 # CS2000CP_AUX_OUTPUT_REF_CLK: ref_clk input + - 1 # CS2000CP_AUX_OUTPUT_CLK_IN: clk_in input + - 2 # CS2000CP_AUX_OUTPUT_CLK_OUT: clk_out output + - 3 # CS2000CP_AUX_OUTPUT_PLL_LOCK: pll lock status + default: 0 + + cirrus,clock-skip: + description: + This mode allows the PLL to maintain lock even when CLK_IN + has missing pulses for up to 20 ms. + $ref: /schemas/types.yaml#/definitions/flag + + cirrus,dynamic-mode: + description: + In dynamic mode, the CLK_IN input is used to drive the + digital PLL of the silicon. + If not given, the static mode shall be used to derive the + output signal directly from the REF_CLK input. + $ref: /schemas/types.yaml#/definitions/flag + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/cirrus,cs2000-cp.h> + + i2c@0 { + reg = <0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + + clock-controller@4f { + #clock-cells = <0>; + compatible = "cirrus,cs2000-cp"; + reg = <0x4f>; + clocks = <&rcar_sound 0>, <&x12_clk>; + clock-names = "clk_in", "ref_clk"; + cirrus,aux-output-source = <CS2000CP_AUX_OUTPUT_CLK_OUT>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/cs2000-cp.txt b/Documentation/devicetree/bindings/clock/cs2000-cp.txt deleted file mode 100644 index 54e6df0bee8a..000000000000 --- a/Documentation/devicetree/bindings/clock/cs2000-cp.txt +++ /dev/null @@ -1,22 +0,0 @@ -CIRRUS LOGIC Fractional-N Clock Synthesizer & Clock Multiplier - -Required properties: - -- compatible: "cirrus,cs2000-cp" -- reg: The chip select number on the I2C bus -- clocks: common clock binding for CLK_IN, XTI/REF_CLK -- clock-names: CLK_IN : clk_in, XTI/REF_CLK : ref_clk -- #clock-cells: must be <0> - -Example: - -&i2c2 { - ... - cs2000: clk_multiplier@4f { - #clock-cells = <0>; - compatible = "cirrus,cs2000-cp"; - reg = <0x4f>; - clocks = <&rcar_sound 0>, <&x12_clk>; - clock-names = "clk_in", "ref_clk"; - }; -}; diff --git a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml index ffd6ae0eed64..be66f1e8b547 100644 --- a/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml +++ b/Documentation/devicetree/bindings/clock/idt,versaclock5.yaml @@ -191,11 +191,4 @@ examples: }; }; - /* Consumer referencing the 5P49V5923 pin OUT1 */ - consumer { - /* ... */ - clocks = <&vc5 1>; - /* ... */ - }; - ... diff --git a/Documentation/devicetree/bindings/clock/imx1-clock.yaml b/Documentation/devicetree/bindings/clock/imx1-clock.yaml index f4833a29b79e..56f524780b1a 100644 --- a/Documentation/devicetree/bindings/clock/imx1-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx1-clock.yaml @@ -40,12 +40,3 @@ examples: compatible = "fsl,imx1-ccm"; reg = <0x0021b000 0x1000>; }; - - pwm@208000 { - #pwm-cells = <2>; - compatible = "fsl,imx1-pwm"; - reg = <0x00208000 0x1000>; - interrupts = <34>; - clocks = <&clks IMX1_CLK_DUMMY>, <&clks IMX1_CLK_PER1>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx21-clock.yaml b/Documentation/devicetree/bindings/clock/imx21-clock.yaml index 518ad9a4733c..e2d50544700a 100644 --- a/Documentation/devicetree/bindings/clock/imx21-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx21-clock.yaml @@ -40,12 +40,3 @@ examples: reg = <0x10027000 0x800>; #clock-cells = <1>; }; - - serial@1000a000 { - compatible = "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX21_CLK_UART1_IPG_GATE>, - <&clks IMX21_CLK_PER1>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx23-clock.yaml b/Documentation/devicetree/bindings/clock/imx23-clock.yaml index 5e296a00e14f..7e890ab9c77d 100644 --- a/Documentation/devicetree/bindings/clock/imx23-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx23-clock.yaml @@ -83,12 +83,3 @@ examples: reg = <0x80040000 0x2000>; #clock-cells = <1>; }; - - serial@8006c000 { - compatible = "fsl,imx23-auart"; - reg = <0x8006c000 0x2000>; - interrupts = <24>; - clocks = <&clks 32>; - dmas = <&dma_apbx 6>, <&dma_apbx 7>; - dma-names = "rx", "tx"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx25-clock.yaml b/Documentation/devicetree/bindings/clock/imx25-clock.yaml index 2a2b10778e72..1792e138984b 100644 --- a/Documentation/devicetree/bindings/clock/imx25-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx25-clock.yaml @@ -176,11 +176,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - serial@43f90000 { - compatible = "fsl,imx25-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 79>, <&clks 50>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx27-clock.yaml b/Documentation/devicetree/bindings/clock/imx27-clock.yaml index 160268f24487..99925aa22a4c 100644 --- a/Documentation/devicetree/bindings/clock/imx27-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx27-clock.yaml @@ -44,12 +44,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - serial@1000a000 { - compatible = "fsl,imx27-uart", "fsl,imx21-uart"; - reg = <0x1000a000 0x1000>; - interrupts = <20>; - clocks = <&clks IMX27_CLK_UART1_IPG_GATE>, - <&clks IMX27_CLK_PER1_GATE>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx28-clock.yaml b/Documentation/devicetree/bindings/clock/imx28-clock.yaml index f831b780f951..a542d680b1ca 100644 --- a/Documentation/devicetree/bindings/clock/imx28-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx28-clock.yaml @@ -106,12 +106,3 @@ examples: reg = <0x80040000 0x2000>; #clock-cells = <1>; }; - - serial@8006a000 { - compatible = "fsl,imx28-auart"; - reg = <0x8006a000 0x2000>; - interrupts = <112>; - dmas = <&dma_apbx 8>, <&dma_apbx 9>; - dma-names = "rx", "tx"; - clocks = <&clks 45>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx31-clock.yaml b/Documentation/devicetree/bindings/clock/imx31-clock.yaml index d2336261c922..168c8ada5e81 100644 --- a/Documentation/devicetree/bindings/clock/imx31-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx31-clock.yaml @@ -110,11 +110,3 @@ examples: interrupts = <31>, <53>; #clock-cells = <1>; }; - - serial@43f90000 { - compatible = "fsl,imx31-uart", "fsl,imx21-uart"; - reg = <0x43f90000 0x4000>; - interrupts = <45>; - clocks = <&clks 10>, <&clks 30>; - clock-names = "ipg", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx35-clock.yaml b/Documentation/devicetree/bindings/clock/imx35-clock.yaml index 3e20ccaf8131..6415bb6a8d04 100644 --- a/Documentation/devicetree/bindings/clock/imx35-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx35-clock.yaml @@ -129,11 +129,3 @@ examples: interrupts = <31>; #clock-cells = <1>; }; - - mmc@53fb4000 { - compatible = "fsl,imx35-esdhc"; - reg = <0x53fb4000 0x4000>; - interrupts = <7>; - clocks = <&clks 9>, <&clks 8>, <&clks 43>; - clock-names = "ipg", "ahb", "per"; - }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml index 7caf5cee9199..739c3378f8c8 100644 --- a/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx7ulp-pcc-clock.yaml @@ -108,14 +108,3 @@ examples: "upll", "sosc_bus_clk", "firc_bus_clk", "rosc", "spll_bus_clk"; }; - - mmc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml index ee8efb4ed599..d06344d7e34f 100644 --- a/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml +++ b/Documentation/devicetree/bindings/clock/imx7ulp-scg-clock.yaml @@ -86,14 +86,3 @@ examples: "firc", "upll"; #clock-cells = <1>; }; - - mmc@40380000 { - compatible = "fsl,imx7ulp-usdhc"; - reg = <0x40380000 0x10000>; - interrupts = <GIC_SPI 43 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&scg1 IMX7ULP_CLK_NIC1_BUS_DIV>, - <&scg1 IMX7ULP_CLK_NIC1_DIV>, - <&pcc2 IMX7ULP_CLK_USDHC1>; - clock-names ="ipg", "ahb", "per"; - bus-width = <4>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml index 0f6fe365ebf3..cb80105b3c70 100644 --- a/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml +++ b/Documentation/devicetree/bindings/clock/imx8qxp-lpcg.yaml @@ -101,14 +101,3 @@ examples: "sdhc0_lpcg_ahb_clk"; power-domains = <&pd IMX_SC_R_SDHC_0>; }; - - mmc@5b010000 { - compatible = "fsl,imx8qxp-usdhc", "fsl,imx7d-usdhc"; - interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_HIGH>; - reg = <0x5b010000 0x10000>; - clocks = <&sdhc0_lpcg IMX_LPCG_CLK_4>, - <&sdhc0_lpcg IMX_LPCG_CLK_5>, - <&sdhc0_lpcg IMX_LPCG_CLK_0>; - clock-names = "ipg", "ahb", "per"; - power-domains = <&pd IMX_SC_R_SDHC_0>; - }; diff --git a/Documentation/devicetree/bindings/clock/imx93-clock.yaml b/Documentation/devicetree/bindings/clock/imx93-clock.yaml new file mode 100644 index 000000000000..21a06194e4a3 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imx93-clock.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/imx93-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX93 Clock Control Module Binding + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: | + i.MX93 clock control module is an integrated clock controller, which + includes clock generator, clock gate and supplies to all modules. + +properties: + compatible: + enum: + - fsl,imx93-ccm + + reg: + maxItems: 1 + + clocks: + description: + specify the external clocks used by the CCM module. + items: + - description: 32k osc + - description: 24m osc + - description: ext1 clock input + + clock-names: + description: + specify the external clocks names used by the CCM module. + items: + - const: osc_32k + - const: osc_24m + - const: clk_ext1 + + '#clock-cells': + const: 1 + description: + See include/dt-bindings/clock/imx93-clock.h for the full list of + i.MX93 clock IDs. + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Control Module node: + - | + clock-controller@44450000 { + compatible = "fsl,imx93-ccm"; + reg = <0x44450000 0x10000>; + #clock-cells = <1>; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml b/Documentation/devicetree/bindings/clock/imxrt1050-clock.yaml new file mode 100644 index 000000000000..03fc5c1a2939 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/imxrt1050-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/imxrt1050-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Clock bindings for Freescale i.MXRT + +maintainers: + - Giulio Benetti <giulio.benetti@benettiengineering.com> + - Jesse Taube <Mr.Bossman075@gmail.com> + +description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/imxrt*-clock.h + for the full list of i.MXRT clock IDs. + +properties: + compatible: + const: fsl,imxrt1050-ccm + + reg: + maxItems: 1 + + interrupts: + maxItems: 2 + + clocks: + description: 24m osc + maxItems: 1 + + clock-names: + const: osc + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imxrt1050-clock.h> + + clks: clock-controller@400fc000 { + compatible = "fsl,imxrt1050-ccm"; + reg = <0x400fc000 0x4000>; + interrupts = <95>, <96>; + clocks = <&osc>; + clock-names = "osc"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/intc_stratix10.txt b/Documentation/devicetree/bindings/clock/intc_stratix10.txt deleted file mode 100644 index 9f4ec5cb5c6b..000000000000 --- a/Documentation/devicetree/bindings/clock/intc_stratix10.txt +++ /dev/null @@ -1,20 +0,0 @@ -Device Tree Clock bindings for Intel's SoCFPGA Stratix10 platform - -This binding uses the common clock binding[1]. - -[1] Documentation/devicetree/bindings/clock/clock-bindings.txt - -Required properties: -- compatible : shall be - "intel,stratix10-clkmgr" - -- reg : shall be the control register offset from CLOCK_MANAGER's base for the clock. - -- #clock-cells : from common clock binding, shall be set to 1. - -Example: - clkmgr: clock-controller@ffd10000 { - compatible = "intel,stratix10-clkmgr"; - reg = <0xffd10000 0x1000>; - #clock-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/clock/intel,stratix10.yaml b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml new file mode 100644 index 000000000000..f506e3db9782 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/intel,stratix10.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/intel,stratix10.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intel SoCFPGA Stratix10 platform clock controller binding + +maintainers: + - Dinh Nguyen <dinguyen@kernel.org> + +properties: + compatible: + const: intel,stratix10-clkmgr + + '#clock-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - '#clock-cells' + +additionalProperties: false + +examples: + - | + clock-controller@ffd10000 { + compatible = "intel,stratix10-clkmgr"; + reg = <0xffd10000 0x1000>; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-clock.yaml new file mode 100644 index 000000000000..175f5c8f2bc5 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/marvell,armada-3700-uart-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/marvell,armada-3700-uart-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# +title: Marvell Armada 3720 UART clocks + +maintainers: + - Pali Rohár <pali@kernel.org> + +properties: + compatible: + const: marvell,armada-3700-uart-clock + + reg: + items: + - description: UART Clock Control Register + - description: UART 2 Baud Rate Divisor Register + + clocks: + description: | + List of parent clocks suitable for UART from following set: + "TBG-A-P", "TBG-B-P", "TBG-A-S", "TBG-B-S", "xtal" + UART clock can use one from this set and when more are provided + then kernel would choose and configure the most suitable one. + It is suggest to specify at least one TBG clock to achieve + baudrates above 230400 and also to specify clock which bootloader + used for UART (most probably xtal) for smooth boot log on UART. + + clock-names: + items: + - const: TBG-A-P + - const: TBG-B-P + - const: TBG-A-S + - const: TBG-B-S + - const: xtal + minItems: 1 + + '#clock-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + uartclk: clock-controller@12010 { + compatible = "marvell,armada-3700-uart-clock"; + reg = <0x12010 0x4>, <0x12210 0x4>; + clocks = <&tbg 0>, <&tbg 1>, <&tbg 2>, <&tbg 3>, <&xtalclk>; + clock-names = "TBG-A-P", "TBG-B-P", "TBG-A-S", "TBG-B-S", "xtal"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml index 915f84efd763..0c0b0ae5e2ac 100644 --- a/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml +++ b/Documentation/devicetree/bindings/clock/mediatek,mt7621-sysc.yaml @@ -22,6 +22,11 @@ description: | The clocks are provided inside a system controller node. + This node is also a reset provider for all the peripherals. + + Reset related bits are defined in: + [2]: <include/dt-bindings/reset/mt7621-reset.h>. + properties: compatible: items: @@ -37,6 +42,12 @@ properties: clocks. const: 1 + "#reset-cells": + description: + The first cell indicates the reset bit within the register, see + [2] for available resets. + const: 1 + ralink,memctl: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -61,6 +72,7 @@ examples: compatible = "mediatek,mt7621-sysc", "syscon"; reg = <0x0 0x100>; #clock-cells = <1>; + #reset-cells = <1>; ralink,memctl = <&memc>; clock-output-names = "xtal", "cpu", "bus", "50m", "125m", "150m", diff --git a/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml new file mode 100644 index 000000000000..0c15afa2214c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/microchip,mpfs.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/microchip,mpfs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PolarFire Clock Control Module Binding + +maintainers: + - Daire McNamara <daire.mcnamara@microchip.com> + +description: | + Microchip PolarFire clock control (CLKCFG) is an integrated clock controller, + which gates and enables all peripheral clocks. + + This device tree binding describes 33 gate clocks. Clocks are referenced by + user nodes by the CLKCFG node phandle and the clock index in the group, from + 0 to 32. + +properties: + compatible: + const: microchip,mpfs-clkcfg + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + '#clock-cells': + const: 1 + description: | + The clock consumer should specify the desired clock by having the clock + ID in its "clocks" phandle cell. See include/dt-bindings/clock/microchip,mpfs-clock.h + for the full list of PolarFire clock IDs. + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + # Clock Config node: + - | + #include <dt-bindings/clock/microchip,mpfs-clock.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + clkcfg: clock-controller@20002000 { + compatible = "microchip,mpfs-clkcfg"; + reg = <0x0 0x20002000 0x0 0x1000>; + clocks = <&ref>; + #clock-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml new file mode 100644 index 000000000000..a9ad7ab5230c --- /dev/null +++ b/Documentation/devicetree/bindings/clock/mstar,msc313-cpupll.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/mstar,msc313-cpupll.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MStar/Sigmastar MSC313 CPU PLL + +maintainers: + - Daniel Palmer <daniel@thingy.jp> + +description: | + The MStar/SigmaStar MSC313 and later ARMv7 chips have a scalable + PLL that can be used as the clock source for the CPU(s). + +properties: + compatible: + const: mstar,msc313-cpupll + + "#clock-cells": + const: 1 + + clocks: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - "#clock-cells" + - clocks + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mstar-msc313-mpll.h> + cpupll: cpupll@206400 { + compatible = "mstar,msc313-cpupll"; + reg = <0x206400 0x200>; + #clock-cells = <1>; + clocks = <&mpll MSTAR_MSC313_MPLL_DIV2>; + }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml index ec7ab1483652..1b2181f6d440 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra124-car.yaml @@ -106,10 +106,3 @@ examples: #clock-cells = <1>; #reset-cells = <1>; }; - - usb-controller@c5004000 { - compatible = "nvidia,tegra20-ehci"; - reg = <0xc5004000 0x4000>; - clocks = <&car TEGRA124_CLK_USB2>; - resets = <&car TEGRA124_CLK_USB2>; - }; diff --git a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml index f832abb7f11a..bee2dd4b29bf 100644 --- a/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml +++ b/Documentation/devicetree/bindings/clock/nvidia,tegra20-car.yaml @@ -97,10 +97,3 @@ examples: power-domains = <&domain>; }; }; - - usb-controller@c5004000 { - compatible = "nvidia,tegra20-ehci"; - reg = <0xc5004000 0x4000>; - clocks = <&car TEGRA20_CLK_USB2>; - resets = <&car TEGRA20_CLK_USB2>; - }; diff --git a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml index 8666e995725f..0e96f693b050 100644 --- a/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,a7pll.yaml @@ -10,7 +10,7 @@ maintainers: - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> description: - The A7 PLL on the Qualcomm platforms like SDX55 is used to provide high + The A7 PLL on the Qualcomm platforms like SDX55, SDX65 is used to provide high frequency clock to the CPU. properties: diff --git a/Documentation/devicetree/bindings/clock/qcom,camcc.txt b/Documentation/devicetree/bindings/clock/qcom,camcc.txt deleted file mode 100644 index c5eb6694fda9..000000000000 --- a/Documentation/devicetree/bindings/clock/qcom,camcc.txt +++ /dev/null @@ -1,18 +0,0 @@ -Qualcomm Camera Clock & Reset Controller Binding ------------------------------------------------- - -Required properties : -- compatible : shall contain "qcom,sdm845-camcc". -- reg : shall contain base register location and length. -- #clock-cells : from common clock binding, shall contain 1. -- #reset-cells : from common reset binding, shall contain 1. -- #power-domain-cells : from generic power domain binding, shall contain 1. - -Example: - camcc: clock-controller@ad00000 { - compatible = "qcom,sdm845-camcc"; - reg = <0xad00000 0x10000>; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml new file mode 100644 index 000000000000..7a03ef19c947 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6125.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock Controller Binding for SM6125 + +maintainers: + - Martin Botka <martin.botka@somainline.org> + +description: | + Qualcomm display clock control module which supports the clocks and + power domains on SM6125. + + See also: + dt-bindings/clock/qcom,dispcc-sm6125.h + +properties: + compatible: + enum: + - qcom,sm6125-dispcc + + clocks: + items: + - description: Board XO source + - description: Byte clock from DSI PHY0 + - description: Pixel clock from DSI PHY0 + - description: Pixel clock from DSI PHY1 + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + - description: AHB config clock from GCC + + clock-names: + items: + - const: bi_tcxo + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dsi1_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_clk + - const: cfg_ahb_clk + + '#clock-cells': + const: 1 + + '#power-domain-cells': + const: 1 + + reg: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + - '#power-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,rpmcc.h> + #include <dt-bindings/clock/qcom,gcc-sm6125.h> + clock-controller@5f00000 { + compatible = "qcom,sm6125-dispcc"; + reg = <0x5f00000 0x20000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&dsi0_phy 0>, + <&dsi0_phy 1>, + <&dsi1_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>, + <&gcc GCC_DISP_AHB_CLK>; + clock-names = "bi_tcxo", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dsi1_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk", + "cfg_ahb_clk"; + #clock-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml new file mode 100644 index 000000000000..e706678b353a --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,dispcc-sm6350.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,dispcc-sm6350.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for SM6350 + +maintainers: + - Konrad Dybcio <konrad.dybcio@somainline.org> + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on SM6350. + + See also dt-bindings/clock/qcom,dispcc-sm6350.h. + +properties: + compatible: + const: qcom,sm6350-dispcc + + clocks: + items: + - description: Board XO source + - description: GPLL0 source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + - description: Link clock from DP PHY + - description: VCO DIV clock from DP PHY + + clock-names: + items: + - const: bi_tcxo + - const: gcc_disp_gpll0_clk + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + - const: dp_phy_pll_link_clk + - const: dp_phy_pll_vco_div_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,gcc-sm6350.h> + #include <dt-bindings/clock/qcom,rpmh.h> + clock-controller@af00000 { + compatible = "qcom,sm6350-dispcc"; + reg = <0x0af00000 0x20000>; + clocks = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_DISP_GPLL0_CLK>, + <&dsi_phy 0>, + <&dsi_phy 1>, + <&dp_phy 0>, + <&dp_phy 1>; + clock-names = "bi_tcxo", + "gcc_disp_gpll0_clk", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk", + "dp_phy_pll_link_clk", + "dp_phy_pll_vco_div_clk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml index 8e2eac6cbfb9..97936411b6b4 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-apq8064.yaml @@ -6,6 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Qualcomm Global Clock & Reset Controller Binding for APQ8064 +allOf: + - $ref: qcom,gcc.yaml# + maintainers: - Stephen Boyd <sboyd@kernel.org> - Taniya Das <tdas@codeaurora.org> @@ -17,22 +20,12 @@ description: | See also: - dt-bindings/clock/qcom,gcc-msm8960.h - dt-bindings/reset/qcom,gcc-msm8960.h + - dt-bindings/clock/qcom,gcc-apq8084.h + - dt-bindings/reset/qcom,gcc-apq8084.h properties: compatible: - const: qcom,gcc-apq8064 - - '#clock-cells': - const: 1 - - '#reset-cells': - const: 1 - - '#power-domain-cells': - const: 1 - - reg: - maxItems: 1 + const: qcom,gcc-apq8084 nvmem-cells: minItems: 1 @@ -53,21 +46,13 @@ properties: '#thermal-sensor-cells': const: 1 - protected-clocks: - description: - Protected clock specifier list as per common clock binding. - required: - compatible - - reg - - '#clock-cells' - - '#reset-cells' - - '#power-domain-cells' - nvmem-cells - nvmem-cell-names - '#thermal-sensor-cells' -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml new file mode 100644 index 000000000000..9eb91dd22557 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-ipq8064.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-ipq8064.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding for IPQ8064 + +allOf: + - $ref: qcom,gcc.yaml# + +maintainers: + - Ansuel Smith <ansuelsmth@gmail.com> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains on IPQ8064. + + See also: + - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) + +properties: + compatible: + items: + - const: qcom,gcc-ipq8064 + - const: syscon + + clocks: + items: + - description: PXO source + - description: CXO source + + clock-names: + items: + - const: pxo + - const: cxo + + thermal-sensor: + type: object + + allOf: + - $ref: /schemas/thermal/qcom-tsens.yaml# + +required: + - compatible + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + gcc: clock-controller@900000 { + compatible = "qcom,gcc-ipq8064", "syscon"; + reg = <0x00900000 0x4000>; + clocks = <&pxo_board>, <&cxo_board>; + clock-names = "pxo", "cxo"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + + tsens: thermal-sensor { + compatible = "qcom,ipq8064-tsens"; + + nvmem-cells = <&tsens_calib>, <&tsens_calib_backup>; + nvmem-cell-names = "calib", "calib_backup"; + interrupts = <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "uplow"; + + #qcom,sensors = <11>; + #thermal-sensor-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml new file mode 100644 index 000000000000..6c45e0f85494 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,gcc-other.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,gcc-other.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Global Clock & Reset Controller Binding + +maintainers: + - Stephen Boyd <sboyd@kernel.org> + - Taniya Das <tdas@codeaurora.org> + +description: | + Qualcomm global clock control module which supports the clocks, resets and + power domains. + + See also: + - dt-bindings/clock/qcom,gcc-ipq4019.h + - dt-bindings/clock/qcom,gcc-ipq6018.h + - dt-bindings/reset/qcom,gcc-ipq6018.h + - dt-bindings/clock/qcom,gcc-msm8939.h + - dt-bindings/clock/qcom,gcc-msm8953.h + - 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 (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-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) + +allOf: + - $ref: "qcom,gcc.yaml#" + +properties: + compatible: + enum: + - qcom,gcc-ipq4019 + - qcom,gcc-ipq6018 + - qcom,gcc-mdm9607 + - qcom,gcc-msm8226 + - qcom,gcc-msm8660 + - qcom,gcc-msm8916 + - qcom,gcc-msm8939 + - qcom,gcc-msm8953 + - qcom,gcc-msm8960 + - qcom,gcc-msm8974 + - qcom,gcc-msm8974pro + - qcom,gcc-msm8974pro-ac + - qcom,gcc-mdm9615 + - qcom,gcc-sdm630 + - qcom,gcc-sdm660 + +required: + - compatible + +unevaluatedProperties: false + +examples: + # Example for GCC for MSM8960: + - | + clock-controller@900000 { + compatible = "qcom,gcc-msm8960"; + reg = <0x900000 0x4000>; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml index f66d703bd913..2ed27a2ef445 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gcc.yaml @@ -4,57 +4,17 @@ $id: http://devicetree.org/schemas/clock/qcom,gcc.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Qualcomm Global Clock & Reset Controller Binding +title: Qualcomm Global Clock & Reset Controller Binding Common Bindings maintainers: - Stephen Boyd <sboyd@kernel.org> - Taniya Das <tdas@codeaurora.org> description: | - Qualcomm global clock control module which supports the clocks, resets and - power domains. - - See also: - - dt-bindings/clock/qcom,gcc-apq8084.h - - dt-bindings/reset/qcom,gcc-apq8084.h - - dt-bindings/clock/qcom,gcc-ipq4019.h - - dt-bindings/clock/qcom,gcc-ipq6018.h - - dt-bindings/reset/qcom,gcc-ipq6018.h - - dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - - dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064) - - dt-bindings/clock/qcom,gcc-msm8939.h - - dt-bindings/clock/qcom,gcc-msm8953.h - - 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 (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-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) + Common bindings for Qualcomm global clock control module which supports + the clocks, resets and power domains. properties: - compatible: - enum: - - qcom,gcc-apq8084 - - qcom,gcc-ipq4019 - - qcom,gcc-ipq6018 - - qcom,gcc-ipq8064 - - qcom,gcc-mdm9607 - - qcom,gcc-msm8226 - - qcom,gcc-msm8660 - - qcom,gcc-msm8916 - - qcom,gcc-msm8939 - - qcom,gcc-msm8953 - - qcom,gcc-msm8960 - - qcom,gcc-msm8974 - - qcom,gcc-msm8974pro - - qcom,gcc-msm8974pro-ac - - qcom,gcc-mdm9615 - - qcom,gcc-sdm630 - - qcom,gcc-sdm660 - '#clock-cells': const: 1 @@ -72,22 +32,11 @@ properties: Protected clock specifier list as per common clock binding. required: - - compatible - reg - '#clock-cells' - '#reset-cells' - '#power-domain-cells' -additionalProperties: false +additionalProperties: true -examples: - # Example for GCC for MSM8960: - - | - clock-controller@900000 { - compatible = "qcom,gcc-msm8960"; - reg = <0x900000 0x4000>; - #clock-cells = <1>; - #reset-cells = <1>; - #power-domain-cells = <1>; - }; ... diff --git a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml index 46dff46d5760..9ebcb1943b0a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,gpucc.yaml @@ -17,6 +17,7 @@ description: | dt-bindings/clock/qcom,gpucc-sdm845.h dt-bindings/clock/qcom,gpucc-sc7180.h dt-bindings/clock/qcom,gpucc-sc7280.h + dt-bindings/clock/qcom,gpucc-sm6350.h dt-bindings/clock/qcom,gpucc-sm8150.h dt-bindings/clock/qcom,gpucc-sm8250.h @@ -27,6 +28,7 @@ properties: - qcom,sc7180-gpucc - qcom,sc7280-gpucc - qcom,sc8180x-gpucc + - qcom,sm6350-gpucc - qcom,sm8150-gpucc - qcom,sm8250-gpucc diff --git a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml index 68fdc3d4982a..4b79e89fd174 100644 --- a/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,mmcc.yaml @@ -19,6 +19,7 @@ properties: enum: - qcom,mmcc-apq8064 - qcom,mmcc-apq8084 + - qcom,mmcc-msm8226 - qcom,mmcc-msm8660 - qcom,mmcc-msm8960 - qcom,mmcc-msm8974 diff --git a/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml new file mode 100644 index 000000000000..973e408c6268 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,qcm2290-dispcc.yaml @@ -0,0 +1,87 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,qcm2290-dispcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display Clock & Reset Controller Binding for qcm2290 + +maintainers: + - Loic Poulain <loic.poulain@linaro.org> + +description: | + Qualcomm display clock control module which supports the clocks, resets and + power domains on qcm2290. + + See also dt-bindings/clock/qcom,dispcc-qcm2290.h. + +properties: + compatible: + const: qcom,qcm2290-dispcc + + clocks: + items: + - description: Board XO source + - description: Board active-only XO source + - description: GPLL0 source from GCC + - description: GPLL0 div source from GCC + - description: Byte clock from DSI PHY + - description: Pixel clock from DSI PHY + + clock-names: + items: + - const: bi_tcxo + - const: bi_tcxo_ao + - const: gcc_disp_gpll0_clk_src + - const: gcc_disp_gpll0_div_clk_src + - const: dsi0_phy_pll_out_byteclk + - const: dsi0_phy_pll_out_dsiclk + + '#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,dispcc-qcm2290.h> + #include <dt-bindings/clock/qcom,gcc-qcm2290.h> + #include <dt-bindings/clock/qcom,rpmcc.h> + clock-controller@5f00000 { + compatible = "qcom,qcm2290-dispcc"; + reg = <0x5f00000 0x20000>; + clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, + <&rpmcc RPM_SMD_XO_A_CLK_SRC>, + <&gcc GCC_DISP_GPLL0_CLK_SRC>, + <&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>, + <&dsi0_phy 0>, + <&dsi0_phy 1>; + clock-names = "bi_tcxo", + "bi_tcxo_ao", + "gcc_disp_gpll0_clk_src", + "gcc_disp_gpll0_div_clk_src", + "dsi0_phy_pll_out_byteclk", + "dsi0_phy_pll_out_dsiclk"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml index 8406dde17937..8fcaf418f84a 100644 --- a/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml +++ b/Documentation/devicetree/bindings/clock/qcom,rpmhcc.yaml @@ -20,6 +20,7 @@ properties: - qcom,sc7180-rpmh-clk - qcom,sc7280-rpmh-clk - qcom,sc8180x-rpmh-clk + - qcom,sc8280xp-rpmh-clk - qcom,sdm845-rpmh-clk - qcom,sdx55-rpmh-clk - qcom,sdx65-rpmh-clk diff --git a/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml new file mode 100644 index 000000000000..d4239ccae917 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/qcom,sdm845-camcc.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/qcom,sdm845-camcc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Camera Clock & Reset Controller Binding for SDM845 + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + Qualcomm camera clock control module which supports the clocks, resets and + power domains on SDM845. + + See also dt-bindings/clock/qcom,camcc-sm845.h + +properties: + compatible: + const: qcom,sdm845-camcc + + clocks: + items: + - description: Board XO source + + clock-names: + items: + - const: bi_tcxo + + '#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,sdm845-camcc"; + reg = <0x0ad00000 0x10000>; + clocks = <&rpmhcc RPMH_CXO_CLK>; + clock-names = "bi_tcxo"; + #clock-cells = <1>; + #reset-cells = <1>; + #power-domain-cells = <1>; + }; +... diff --git a/Documentation/devicetree/bindings/clock/qoriq-clock.txt b/Documentation/devicetree/bindings/clock/qoriq-clock.txt index f7d48f23da44..10119d9ef4b1 100644 --- a/Documentation/devicetree/bindings/clock/qoriq-clock.txt +++ b/Documentation/devicetree/bindings/clock/qoriq-clock.txt @@ -44,6 +44,7 @@ Required properties: * "fsl,ls1046a-clockgen" * "fsl,ls1088a-clockgen" * "fsl,ls2080a-clockgen" + * "fsl,lx2160a-clockgen" Chassis-version clock strings include: * "fsl,qoriq-clockgen-1.0": for chassis 1.0 clocks * "fsl,qoriq-clockgen-2.0": for chassis 2.0 clocks diff --git a/Documentation/devicetree/bindings/clock/renesas,9series.yaml b/Documentation/devicetree/bindings/clock/renesas,9series.yaml new file mode 100644 index 000000000000..102eb95cb3fc --- /dev/null +++ b/Documentation/devicetree/bindings/clock/renesas,9series.yaml @@ -0,0 +1,97 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/renesas,9series.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for Renesas 9-series I2C PCIe clock generators + +description: | + The Renesas 9-series are I2C PCIe clock generators providing + from 1 to 20 output clocks. + + When referencing the provided clock in the DT using phandle + and clock specifier, the following mapping applies: + + - 9FGV0241: + 0 -- DIF0 + 1 -- DIF1 + +maintainers: + - Marek Vasut <marex@denx.de> + +properties: + compatible: + enum: + - renesas,9fgv0241 + + reg: + description: I2C device address + enum: [ 0x68, 0x6a ] + + '#clock-cells': + const: 1 + + clocks: + items: + - description: XTal input clock + + renesas,out-amplitude-microvolt: + enum: [ 600000, 700000, 800000, 900000 ] + description: Output clock signal amplitude + + renesas,out-spread-spectrum: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 100000, 99750, 99500 ] + description: Output clock down spread in pcm (1/1000 of percent) + +patternProperties: + "^DIF[0-19]$": + type: object + description: + Description of one of the outputs (DIF0..DIF19). + + properties: + renesas,slew-rate: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 2000000, 3000000 ] + description: Output clock slew rate select in V/ns + + additionalProperties: false + +required: + - compatible + - reg + - clocks + - '#clock-cells' + +additionalProperties: false + +examples: + - | + /* 25MHz reference crystal */ + ref25: ref25m { + compatible = "fixed-clock"; + #clock-cells = <0>; + clock-frequency = <25000000>; + }; + + i2c@0 { + reg = <0x0 0x100>; + #address-cells = <1>; + #size-cells = <0>; + + rs9: clock-generator@6a { + compatible = "renesas,9fgv0241"; + reg = <0x6a>; + #clock-cells = <1>; + + clocks = <&ref25m>; + + DIF0 { + renesas,slew-rate = <3000000>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml index c55a7c494e01..2197c952e21d 100644 --- a/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,cpg-div6-clock.yaml @@ -51,6 +51,18 @@ additionalProperties: false examples: - | #include <dt-bindings/clock/r8a73a4-clock.h> + + cpg_clocks: cpg_clocks@e6150000 { + compatible = "renesas,r8a73a4-cpg-clocks"; + reg = <0xe6150000 0x10000>; + clocks = <&extal1_clk>, <&extal2_clk>; + #clock-cells = <1>; + clock-output-names = "main", "pll0", "pll1", "pll2", + "pll2s", "pll2h", "z", "z2", + "i", "m3", "b", "m1", "m2", + "zx", "zs", "hp"; + }; + sdhi2_clk: sdhi2_clk@e615007c { compatible = "renesas,r8a73a4-div6-clock", "renesas,cpg-div6-clock"; reg = <0xe615007c 4>; diff --git a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml index 30b2e3d0d25d..bd3af8fc616b 100644 --- a/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml +++ b/Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml @@ -4,13 +4,13 @@ $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 +title: Renesas RZ/{G2L,V2L} 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 + On Renesas RZ/{G2L,V2L} SoC, the CPG (Clock Pulse Generator) and Module Standby Mode share the same register block. They provide the following functionalities: @@ -22,7 +22,9 @@ description: | properties: compatible: - const: renesas,r9a07g044-cpg # RZ/G2{L,LC} + enum: + - renesas,r9a07g044-cpg # RZ/G2{L,LC} + - renesas,r9a07g054-cpg # RZ/V2L reg: maxItems: 1 @@ -40,9 +42,9 @@ properties: 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> + <dt-bindings/clock/r9a07g*-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>. + a module number, as defined in the <dt-bindings/clock/r9a07g0*-cpg.h>. const: 2 '#power-domain-cells': @@ -56,7 +58,7 @@ properties: '#reset-cells': description: The single reset specifier cell must be the module number, as defined in - the <dt-bindings/clock/r9a07g044-cpg.h>. + the <dt-bindings/clock/r9a07g0*-cpg.h>. const: 1 required: diff --git a/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml b/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml new file mode 100644 index 000000000000..8f49a1ae03f1 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/starfive,jh7100-audclk.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/starfive,jh7100-audclk.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: StarFive JH7100 Audio Clock Generator + +maintainers: + - Emil Renner Berthing <kernel@esmil.dk> + +properties: + compatible: + const: starfive,jh7100-audclk + + reg: + maxItems: 1 + + clocks: + items: + - description: Audio source clock + - description: External 12.288MHz clock + - description: Domain 7 AHB bus clock + + clock-names: + items: + - const: audio_src + - const: audio_12288 + - const: dom7ahb_bus + + '#clock-cells': + const: 1 + description: + See <dt-bindings/clock/starfive-jh7100-audio.h> for valid indices. + +required: + - compatible + - reg + - clocks + - clock-names + - '#clock-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/starfive-jh7100.h> + + clock-controller@10480000 { + compatible = "starfive,jh7100-audclk"; + reg = <0x10480000 0x10000>; + clocks = <&clkgen JH7100_CLK_AUDIO_SRC>, + <&clkgen JH7100_CLK_AUDIO_12288>, + <&clkgen JH7100_CLK_DOM7AHB_BUS>; + clock-names = "audio_src", "audio_12288", "dom7ahb_bus"; + #clock-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml new file mode 100644 index 000000000000..dc808e2f8327 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/tesla,fsd-clock.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/tesla,fsd-clock.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Tesla FSD (Full Self-Driving) SoC clock controller + +maintainers: + - Alim Akhtar <alim.akhtar@samsung.com> + - linux-fsd@tesla.com + +description: | + FSD clock controller consist of several clock management unit + (CMU), which generates clocks for various inteernal SoC blocks. + The root clock comes from external OSC clock (24 MHz). + + All available clocks are defined as preprocessor macros in + 'dt-bindings/clock/fsd-clk.h' header. + +properties: + compatible: + enum: + - tesla,fsd-clock-cmu + - tesla,fsd-clock-imem + - tesla,fsd-clock-peric + - tesla,fsd-clock-fsys0 + - tesla,fsd-clock-fsys1 + - tesla,fsd-clock-mfc + - tesla,fsd-clock-cam_csi + + clocks: + minItems: 1 + maxItems: 6 + + clock-names: + minItems: 1 + maxItems: 6 + + "#clock-cells": + const: 1 + + reg: + maxItems: 1 + +allOf: + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-cmu + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-imem + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: IMEM TCU clock (from CMU_CMU) + - description: IMEM bus clock (from CMU_CMU) + - description: IMEM DMA clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_imem_tcuclk + - const: dout_cmu_imem_aclk + - const: dout_cmu_imem_dmaclk + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-peric + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: Shared0 PLL div4 clock (from CMU_CMU) + - description: PERIC shared1 div36 clock (from CMU_CMU) + - description: PERIC shared0 div3 TBU clock (from CMU_CMU) + - description: PERIC shared0 div20 clock (from CMU_CMU) + - description: PERIC shared1 div4 DMAclock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_pll_shared0_div4 + - const: dout_cmu_peric_shared1div36 + - const: dout_cmu_peric_shared0div3_tbuclk + - const: dout_cmu_peric_shared0div20 + - const: dout_cmu_peric_shared1div4_dmaclk + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-fsys0 + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: Shared0 PLL div6 clock (from CMU_CMU) + - description: FSYS0 shared1 div4 clock (from CMU_CMU) + - description: FSYS0 shared0 div4 clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_pll_shared0_div6 + - const: dout_cmu_fsys0_shared1div4 + - const: dout_cmu_fsys0_shared0div4 + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-fsys1 + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + - description: FSYS1 shared0 div8 clock (from CMU_CMU) + - description: FSYS1 shared0 div4 clock (from CMU_CMU) + clock-names: + items: + - const: fin_pll + - const: dout_cmu_fsys1_shared0div8 + - const: dout_cmu_fsys1_shared0div4 + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-mfc + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + + - if: + properties: + compatible: + contains: + const: tesla,fsd-clock-cam_csi + then: + properties: + clocks: + items: + - description: External reference clock (24 MHz) + clock-names: + items: + - const: fin_pll + +required: + - compatible + - "#clock-cells" + - clocks + - clock-names + - reg + +additionalProperties: false + +examples: + # Clock controller node for CMU_FSYS1 + - | + #include <dt-bindings/clock/fsd-clk.h> + + clock_fsys1: clock-controller@16810000 { + compatible = "tesla,fsd-clock-fsys1"; + reg = <0x16810000 0x3000>; + #clock-cells = <1>; + + clocks = <&fin_pll>, + <&clock_cmu DOUT_CMU_FSYS1_SHARED0DIV8>, + <&clock_cmu DOUT_CMU_FSYS1_SHARED0DIV4>; + clock-names = "fin_pll", + "dout_cmu_fsys1_shared0div8", + "dout_cmu_fsys1_shared0div4"; + }; + +... diff --git a/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml new file mode 100644 index 000000000000..c56f911fff47 --- /dev/null +++ b/Documentation/devicetree/bindings/clock/ti/ti,clksel.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/clock/ti/ti,clksel.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Binding for TI clksel clock + +maintainers: + - Tony Lindgren <tony@atomide.com> + +description: | + The TI CLKSEL clocks consist of consist of input clock mux bits, and in some + cases also has divider, multiplier and gate bits. + +properties: + compatible: + const: ti,clksel + + reg: + maxItems: 1 + description: The CLKSEL register range + + '#address-cells': + enum: [ 0, 1, 2 ] + + '#size-cells': + enum: [ 0, 1, 2 ] + + ranges: true + + "#clock-cells": + const: 2 + description: The CLKSEL register and bit offset + +required: + - compatible + - reg + - "#clock-cells" + +additionalProperties: + type: object + +examples: + - | + clksel_gfx_fclk: clock@52c { + compatible = "ti,clksel"; + reg = <0x25c 0x4>; + #clock-cells = <2>; + }; +... diff --git a/Documentation/devicetree/bindings/connector/usb-connector.yaml b/Documentation/devicetree/bindings/connector/usb-connector.yaml index 7eb8659fa610..0420fa563532 100644 --- a/Documentation/devicetree/bindings/connector/usb-connector.yaml +++ b/Documentation/devicetree/bindings/connector/usb-connector.yaml @@ -104,8 +104,7 @@ properties: - "1.5A" and "3.0A", 5V 1.5A and 5V 3.0A respectively, as defined in USB Type-C Cable and Connector specification, when Power Delivery is not supported. - allOf: - - $ref: /schemas/types.yaml#/definitions/string + $ref: /schemas/types.yaml#/definitions/string enum: - default - 1.5A diff --git a/Documentation/devicetree/bindings/arm/idle-states.yaml b/Documentation/devicetree/bindings/cpu/idle-states.yaml index 52bce5dbb11f..fa4d4142ac93 100644 --- a/Documentation/devicetree/bindings/arm/idle-states.yaml +++ b/Documentation/devicetree/bindings/cpu/idle-states.yaml @@ -1,25 +1,30 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/arm/idle-states.yaml# +$id: http://devicetree.org/schemas/cpu/idle-states.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: ARM idle states binding description +title: Idle states binding description maintainers: - Lorenzo Pieralisi <lorenzo.pieralisi@arm.com> + - Anup Patel <anup@brainfault.org> description: |+ ========================================== 1 - Introduction ========================================== - ARM systems contain HW capable of managing power consumption dynamically, - where cores can be put in different low-power states (ranging from simple wfi - to power gating) according to OS PM policies. The CPU states representing the - range of dynamic idle states that a processor can enter at run-time, can be - specified through device tree bindings representing the parameters required to - enter/exit specific idle states on a given processor. + ARM and RISC-V systems contain HW capable of managing power consumption + dynamically, where cores can be put in different low-power states (ranging + from simple wfi to power gating) according to OS PM policies. The CPU states + representing the range of dynamic idle states that a processor can enter at + run-time, can be specified through device tree bindings representing the + parameters required to enter/exit specific idle states on a given processor. + + ========================================== + 2 - ARM idle states + ========================================== According to the Server Base System Architecture document (SBSA, [3]), the power states an ARM CPU can be put into are identified by the following list: @@ -43,8 +48,23 @@ description: |+ The device tree binding definition for ARM idle states is the subject of this document. + ========================================== + 3 - RISC-V idle states + ========================================== + + On RISC-V systems, the HARTs (or CPUs) [6] can be put in platform specific + suspend (or idle) states (ranging from simple WFI, power gating, etc). The + RISC-V SBI v0.3 (or higher) [7] hart state management extension provides a + standard mechanism for OS to request HART state transitions. + + The platform specific suspend (or idle) states of a hart can be either + retentive or non-rententive in nature. A retentive suspend state will + preserve HART registers and CSR values for all privilege modes whereas + a non-retentive suspend state will not preserve HART registers and CSR + values. + =========================================== - 2 - idle-states definitions + 4 - idle-states definitions =========================================== Idle states are characterized for a specific system through a set of @@ -211,10 +231,10 @@ description: |+ properties specification that is the subject of the following sections. =========================================== - 3 - idle-states node + 5 - idle-states node =========================================== - ARM processor idle states are defined within the idle-states node, which is + The processor idle states are defined within the idle-states node, which is a direct child of the cpus node [1] and provides a container where the processor idle states, defined as device tree nodes, are listed. @@ -223,7 +243,7 @@ description: |+ just supports idle_standby, an idle-states node is not required. =========================================== - 4 - References + 6 - References =========================================== [1] ARM Linux Kernel documentation - CPUs bindings @@ -238,9 +258,15 @@ description: |+ [4] ARM Architecture Reference Manuals http://infocenter.arm.com/help/index.jsp - [6] ARM Linux Kernel documentation - Booting AArch64 Linux + [5] ARM Linux Kernel documentation - Booting AArch64 Linux Documentation/arm64/booting.rst + [6] RISC-V Linux Kernel documentation - CPUs bindings + Documentation/devicetree/bindings/riscv/cpus.yaml + + [7] RISC-V Supervisor Binary Interface (SBI) + http://github.com/riscv/riscv-sbi-doc/riscv-sbi.adoc + properties: $nodename: const: idle-states @@ -253,7 +279,7 @@ properties: On ARM 32-bit systems this property is optional This assumes that the "enable-method" property is set to "psci" in the cpu - node[6] that is responsible for setting up CPU idle management in the OS + node[5] that is responsible for setting up CPU idle management in the OS implementation. const: psci @@ -265,8 +291,8 @@ patternProperties: as follows. The idle state entered by executing the wfi instruction (idle_standby - SBSA,[3][4]) is considered standard on all ARM platforms and therefore - must not be listed. + SBSA,[3][4]) is considered standard on all ARM and RISC-V platforms and + therefore must not be listed. In addition to the properties listed above, a state node may require additional properties specific to the entry-method defined in the @@ -275,7 +301,27 @@ patternProperties: properties: compatible: - const: arm,idle-state + enum: + - arm,idle-state + - riscv,idle-state + + arm,psci-suspend-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + power_state parameter to pass to the ARM PSCI suspend call. + + Device tree nodes that require usage of PSCI CPU_SUSPEND function + (i.e. idle states node with entry-method property is set to "psci") + must specify this property. + + riscv,sbi-suspend-param: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + suspend_type parameter to pass to the RISC-V SBI HSM suspend call. + + This property is required in idle state nodes of device tree meant + for RISC-V systems. For more details on the suspend_type parameter + refer the SBI specifiation v0.3 (or higher) [7]. local-timer-stop: description: @@ -317,6 +363,8 @@ patternProperties: description: A string used as a descriptive name for the idle state. + additionalProperties: false + required: - compatible - entry-latency-us @@ -337,8 +385,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x0>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@1 { @@ -346,8 +394,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x1>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@100 { @@ -355,8 +403,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@101 { @@ -364,8 +412,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10000 { @@ -373,8 +421,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10000>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10001 { @@ -382,8 +430,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10001>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10100 { @@ -391,8 +439,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@10101 { @@ -400,8 +448,8 @@ examples: compatible = "arm,cortex-a57"; reg = <0x0 0x10101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_0_0 &CPU_SLEEP_0_0 - &CLUSTER_RETENTION_0 &CLUSTER_SLEEP_0>; + cpu-idle-states = <&CPU_RETENTION_0_0>, <&CPU_SLEEP_0_0>, + <&CLUSTER_RETENTION_0>, <&CLUSTER_SLEEP_0>; }; cpu@100000000 { @@ -409,8 +457,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x0>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000001 { @@ -418,8 +466,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x1>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000100 { @@ -427,8 +475,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100000101 { @@ -436,8 +484,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010000 { @@ -445,8 +493,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10000>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010001 { @@ -454,8 +502,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10001>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010100 { @@ -463,8 +511,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10100>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; cpu@100010101 { @@ -472,8 +520,8 @@ examples: compatible = "arm,cortex-a53"; reg = <0x1 0x10101>; enable-method = "psci"; - cpu-idle-states = <&CPU_RETENTION_1_0 &CPU_SLEEP_1_0 - &CLUSTER_RETENTION_1 &CLUSTER_SLEEP_1>; + cpu-idle-states = <&CPU_RETENTION_1_0>, <&CPU_SLEEP_1_0>, + <&CLUSTER_RETENTION_1>, <&CLUSTER_SLEEP_1>; }; idle-states { @@ -567,56 +615,56 @@ examples: device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x0>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@1 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x1>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@2 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x2>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@3 { device_type = "cpu"; compatible = "arm,cortex-a15"; reg = <0x3>; - cpu-idle-states = <&cpu_sleep_0_0 &cluster_sleep_0>; + cpu-idle-states = <&cpu_sleep_0_0>, <&cluster_sleep_0>; }; cpu@100 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x100>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@101 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x101>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@102 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x102>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; cpu@103 { device_type = "cpu"; compatible = "arm,cortex-a7"; reg = <0x103>; - cpu-idle-states = <&cpu_sleep_1_0 &cluster_sleep_1>; + cpu-idle-states = <&cpu_sleep_1_0>, <&cluster_sleep_1>; }; idle-states { @@ -658,4 +706,150 @@ examples: }; }; + - | + // Example 3 (RISC-V 64-bit, 4-cpu systems, two clusters): + + cpus { + #size-cells = <0>; + #address-cells = <1>; + + cpu@0 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x0>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, + <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; + + cpu_intc0: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@1 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x1>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_0_0>, <&CPU_NONRET_0_0>, + <&CLUSTER_RET_0>, <&CLUSTER_NONRET_0>; + + cpu_intc1: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@10 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x10>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, + <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; + + cpu_intc10: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + cpu@11 { + device_type = "cpu"; + compatible = "riscv"; + reg = <0x11>; + riscv,isa = "rv64imafdc"; + mmu-type = "riscv,sv48"; + cpu-idle-states = <&CPU_RET_1_0>, <&CPU_NONRET_1_0>, + <&CLUSTER_RET_1>, <&CLUSTER_NONRET_1>; + + cpu_intc11: interrupt-controller { + #interrupt-cells = <1>; + compatible = "riscv,cpu-intc"; + interrupt-controller; + }; + }; + + idle-states { + CPU_RET_0_0: cpu-retentive-0-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x10000000>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CPU_NONRET_0_0: cpu-nonretentive-0-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x90000000>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_RET_0: cluster-retentive-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x11000000>; + local-timer-stop; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CLUSTER_NONRET_0: cluster-nonretentive-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x91000000>; + local-timer-stop; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + + CPU_RET_1_0: cpu-retentive-1-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x10000010>; + entry-latency-us = <20>; + exit-latency-us = <40>; + min-residency-us = <80>; + }; + + CPU_NONRET_1_0: cpu-nonretentive-1-0 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x90000010>; + entry-latency-us = <250>; + exit-latency-us = <500>; + min-residency-us = <950>; + }; + + CLUSTER_RET_1: cluster-retentive-1 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x11000010>; + local-timer-stop; + entry-latency-us = <50>; + exit-latency-us = <100>; + min-residency-us = <250>; + wakeup-latency-us = <130>; + }; + + CLUSTER_NONRET_1: cluster-nonretentive-1 { + compatible = "riscv,idle-state"; + riscv,sbi-suspend-param = <0x91000010>; + local-timer-stop; + entry-latency-us = <600>; + exit-latency-us = <1100>; + min-residency-us = <2700>; + wakeup-latency-us = <1500>; + }; + }; + }; + ... diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt deleted file mode 100644 index 9299028ee712..000000000000 --- a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.txt +++ /dev/null @@ -1,172 +0,0 @@ -Qualcomm Technologies, Inc. CPUFREQ Bindings - -CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) -SoCs to manage frequency in hardware. It is capable of controlling frequency -for multiple clusters. - -Properties: -- compatible - Usage: required - Value type: <string> - Definition: must be "qcom,cpufreq-hw" or "qcom,cpufreq-epss". - -- clocks - Usage: required - Value type: <phandle> From common clock binding. - Definition: clock handle for XO clock and GPLL0 clock. - -- clock-names - Usage: required - Value type: <string> From common clock binding. - Definition: must be "xo", "alternate". - -- reg - Usage: required - Value type: <prop-encoded-array> - Definition: Addresses and sizes for the memory of the HW bases in - each frequency domain. -- reg-names - Usage: Optional - Value type: <string> - Definition: Frequency domain name i.e. - "freq-domain0", "freq-domain1". - -- #freq-domain-cells: - Usage: required. - Definition: Number of cells in a freqency domain specifier. - -* Property qcom,freq-domain -Devices supporting freq-domain must set their "qcom,freq-domain" property with -phandle to a cpufreq_hw followed by the Domain ID(0/1) in the CPU DT node. - - -Example: - -Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster switch -DCVS state together. - -/ { - cpus { - #address-cells = <2>; - #size-cells = <0>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x0>; - enable-method = "psci"; - next-level-cache = <&L2_0>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_0: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - L3_0: l3-cache { - compatible = "cache"; - }; - }; - }; - - CPU1: cpu@100 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x100>; - enable-method = "psci"; - next-level-cache = <&L2_100>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_100: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU2: cpu@200 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x200>; - enable-method = "psci"; - next-level-cache = <&L2_200>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_200: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU3: cpu@300 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x300>; - enable-method = "psci"; - next-level-cache = <&L2_300>; - qcom,freq-domain = <&cpufreq_hw 0>; - L2_300: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU4: cpu@400 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x400>; - enable-method = "psci"; - next-level-cache = <&L2_400>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_400: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU5: cpu@500 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x500>; - enable-method = "psci"; - next-level-cache = <&L2_500>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_500: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU6: cpu@600 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x600>; - enable-method = "psci"; - next-level-cache = <&L2_600>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_600: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - - CPU7: cpu@700 { - device_type = "cpu"; - compatible = "qcom,kryo385"; - reg = <0x0 0x700>; - enable-method = "psci"; - next-level-cache = <&L2_700>; - qcom,freq-domain = <&cpufreq_hw 1>; - L2_700: l2-cache { - compatible = "cache"; - next-level-cache = <&L3_0>; - }; - }; - }; - - soc { - cpufreq_hw: cpufreq@17d43000 { - compatible = "qcom,cpufreq-hw"; - reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>; - reg-names = "freq-domain0", "freq-domain1"; - - clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>; - clock-names = "xo", "alternate"; - - #freq-domain-cells = <1>; - }; -} diff --git a/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml new file mode 100644 index 000000000000..2f1b8b6852a0 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/cpufreq-qcom-hw.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/cpufreq-qcom-hw.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. CPUFREQ + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +description: | + + CPUFREQ HW is a hardware engine used by some Qualcomm Technologies, Inc. (QTI) + SoCs to manage frequency in hardware. It is capable of controlling frequency + for multiple clusters. + +properties: + compatible: + oneOf: + - description: v1 of CPUFREQ HW + items: + - const: qcom,cpufreq-hw + + - description: v2 of CPUFREQ HW (EPSS) + items: + - enum: + - qcom,sm8250-cpufreq-epss + - const: qcom,cpufreq-epss + + reg: + minItems: 2 + items: + - description: Frequency domain 0 register region + - description: Frequency domain 1 register region + - description: Frequency domain 2 register region + + reg-names: + minItems: 2 + items: + - const: freq-domain0 + - const: freq-domain1 + - const: freq-domain2 + + clocks: + items: + - description: XO Clock + - description: GPLL0 Clock + + clock-names: + items: + - const: xo + - const: alternate + + '#freq-domain-cells': + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - '#freq-domain-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/clock/qcom,rpmh.h> + + // Example 1: Dual-cluster, Quad-core per cluster. CPUs within a cluster + // switch DCVS state together. + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x0>; + enable-method = "psci"; + next-level-cache = <&L2_0>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_0: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + L3_0: l3-cache { + compatible = "cache"; + }; + }; + }; + + CPU1: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x100>; + enable-method = "psci"; + next-level-cache = <&L2_100>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_100: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU2: cpu@200 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x200>; + enable-method = "psci"; + next-level-cache = <&L2_200>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_200: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU3: cpu@300 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x300>; + enable-method = "psci"; + next-level-cache = <&L2_300>; + qcom,freq-domain = <&cpufreq_hw 0>; + L2_300: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU4: cpu@400 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x400>; + enable-method = "psci"; + next-level-cache = <&L2_400>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_400: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU5: cpu@500 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x500>; + enable-method = "psci"; + next-level-cache = <&L2_500>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_500: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU6: cpu@600 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x600>; + enable-method = "psci"; + next-level-cache = <&L2_600>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_600: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + + CPU7: cpu@700 { + device_type = "cpu"; + compatible = "qcom,kryo385"; + reg = <0x0 0x700>; + enable-method = "psci"; + next-level-cache = <&L2_700>; + qcom,freq-domain = <&cpufreq_hw 1>; + L2_700: l2-cache { + compatible = "cache"; + next-level-cache = <&L3_0>; + }; + }; + }; + + soc { + #address-cells = <1>; + #size-cells = <1>; + + cpufreq@17d43000 { + compatible = "qcom,cpufreq-hw"; + reg = <0x17d43000 0x1400>, <0x17d45800 0x1400>; + reg-names = "freq-domain0", "freq-domain1"; + + clocks = <&rpmhcc RPMH_CXO_CLK>, <&gcc GPLL0>; + clock-names = "xo", "alternate"; + + #freq-domain-cells = <1>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml new file mode 100644 index 000000000000..a9a776da5505 --- /dev/null +++ b/Documentation/devicetree/bindings/cpufreq/qcom-cpufreq-nvmem.yaml @@ -0,0 +1,166 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/cpufreq/qcom-cpufreq-nvmem.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. NVMEM CPUFreq bindings + +maintainers: + - Ilia Lin <ilia.lin@kernel.org> + +description: | + In certain Qualcomm Technologies, Inc. SoCs such as QCS404, The CPU supply + voltage is dynamically configured by Core Power Reduction (CPR) depending on + current CPU frequency and efuse values. + CPR provides a power domain with multiple levels that are selected depending + on the CPU OPP in use. The CPUFreq driver sets the CPR power domain level + according to the required OPPs defined in the CPU OPP tables. + +select: + properties: + compatible: + contains: + enum: + - qcom,qcs404 + required: + - compatible + +properties: + cpus: + type: object + + patternProperties: + 'cpu@[0-9a-f]+': + type: object + + properties: + power-domains: + maxItems: 1 + + power-domain-names: + items: + - const: cpr + + required: + - power-domains + - power-domain-names + +patternProperties: + '^opp-table(-[a-z0-9]+)?$': + if: + properties: + compatible: + const: operating-points-v2-kryo-cpu + then: + patternProperties: + '^opp-?[0-9]+$': + required: + - required-opps + +additionalProperties: true + +examples: + - | + / { + model = "Qualcomm Technologies, Inc. QCS404"; + compatible = "qcom,qcs404"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <1>; + #size-cells = <0>; + + CPU0: cpu@100 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU1: cpu@101 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU2: cpu@102 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x102>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + + CPU3: cpu@103 { + device_type = "cpu"; + compatible = "arm,cortex-a53"; + reg = <0x103>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + next-level-cache = <&L2_0>; + #cooling-cells = <2>; + clocks = <&apcs_glb>; + operating-points-v2 = <&cpu_opp_table>; + power-domains = <&cpr>; + power-domain-names = "cpr"; + }; + }; + + cpu_opp_table: opp-table-cpu { + compatible = "operating-points-v2-kryo-cpu"; + opp-shared; + + opp-1094400000 { + opp-hz = /bits/ 64 <1094400000>; + required-opps = <&cpr_opp1>; + }; + opp-1248000000 { + opp-hz = /bits/ 64 <1248000000>; + required-opps = <&cpr_opp2>; + }; + opp-1401600000 { + opp-hz = /bits/ 64 <1401600000>; + required-opps = <&cpr_opp3>; + }; + }; + + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml new file mode 100644 index 000000000000..0ccaab16dc61 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-aes.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-aes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Advanced Encryption Standard (AES) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +properties: + compatible: + const: atmel,at91sam9g46-aes + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: aes_clk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - dmas + - dma-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + + aes: crypto@e1810000 { + compatible = "atmel,at91sam9g46-aes"; + reg = <0xe1810000 0x100>; + interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 27>; + clock-names = "aes_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(1)>, + <&dma0 AT91_XDMAC_DT_PERID(2)>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml new file mode 100644 index 000000000000..5163c51b4547 --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-sha.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-sha.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Secure Hash Algorithm (SHA) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +properties: + compatible: + const: atmel,at91sam9g46-sha + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: sha_clk + + dmas: + maxItems: 1 + description: TX DMA Channel + + dma-names: + const: tx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + + sha: crypto@e1814000 { + compatible = "atmel,at91sam9g46-sha"; + reg = <0xe1814000 0x100>; + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 83>; + clock-names = "sha_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(48)>; + dma-names = "tx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml new file mode 100644 index 000000000000..fcc5adf03cad --- /dev/null +++ b/Documentation/devicetree/bindings/crypto/atmel,at91sam9g46-tdes.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/crypto/atmel,at91sam9g46-tdes.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel Triple Data Encryption Standard (TDES) HW cryptographic accelerator + +maintainers: + - Tudor Ambarus <tudor.ambarus@microchip.com> + +properties: + compatible: + const: atmel,at91sam9g46-tdes + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + const: tdes_clk + + dmas: + items: + - description: TX DMA Channel + - description: RX DMA Channel + + dma-names: + items: + - const: tx + - const: rx + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + + tdes: crypto@e2014000 { + compatible = "atmel,at91sam9g46-tdes"; + reg = <0xe2014000 0x100>; + interrupts = <GIC_SPI 96 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&pmc PMC_TYPE_PERIPHERAL 96>; + clock-names = "tdes_clk"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(54)>, + <&dma0 AT91_XDMAC_DT_PERID(53)>; + dma-names = "tx", "rx"; + }; diff --git a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt b/Documentation/devicetree/bindings/crypto/atmel-crypto.txt deleted file mode 100644 index f2aab3dc2b52..000000000000 --- a/Documentation/devicetree/bindings/crypto/atmel-crypto.txt +++ /dev/null @@ -1,68 +0,0 @@ -* Atmel HW cryptographic accelerators - -These are the HW cryptographic accelerators found on some Atmel products. - -* Advanced Encryption Standard (AES) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-aes". -- reg: Should contain AES registers location and length. -- interrupts: Should contain the IRQ line for the AES. -- dmas: List of two DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. - -Example: -aes@f8038000 { - compatible = "atmel,at91sam9g46-aes"; - reg = <0xf8038000 0x100>; - interrupts = <43 4 0>; - dmas = <&dma1 2 18>, - <&dma1 2 19>; - dma-names = "tx", "rx"; - -* Triple Data Encryption Standard (Triple DES) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-tdes". -- reg: Should contain TDES registers location and length. -- interrupts: Should contain the IRQ line for the TDES. - -Optional properties: -- dmas: List of two DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. - -Example: -tdes@f803c000 { - compatible = "atmel,at91sam9g46-tdes"; - reg = <0xf803c000 0x100>; - interrupts = <44 4 0>; - dmas = <&dma1 2 20>, - <&dma1 2 21>; - dma-names = "tx", "rx"; -}; - -* Secure Hash Algorithm (SHA) - -Required properties: -- compatible : Should be "atmel,at91sam9g46-sha". -- reg: Should contain SHA registers location and length. -- interrupts: Should contain the IRQ line for the SHA. - -Optional properties: -- dmas: One DMA specifiers as described in - atmel-dma.txt and dma.txt files. -- dma-names: Contains one identifier string for each DMA specifier - in the dmas property. Only one "tx" string needed. - -Example: -sha@f8034000 { - compatible = "atmel,at91sam9g46-sha"; - reg = <0xf8034000 0x100>; - interrupts = <42 4 0>; - dmas = <&dma1 2 17>; - dma-names = "tx"; -}; diff --git a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml index 9c53c27bd20a..e0fe63957888 100644 --- a/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml +++ b/Documentation/devicetree/bindings/crypto/intel,ixp4xx-crypto.yaml @@ -22,19 +22,28 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the NPE this crypto engine + - description: the NPE instance number description: phandle to the NPE this crypto engine is using, the cell describing the NPE instance to be used. queue-rx: $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to the RX queue on the NPE + - description: the queue instance number description: phandle to the RX queue on the NPE, the cell describing the queue instance to be used. queue-txready: $ref: /schemas/types.yaml#/definitions/phandle-array - maxItems: 1 + items: + - items: + - description: phandle to the TX READY queue on the NPE + - description: the queue instance number description: phandle to the TX READY queue on the NPE, the cell describing the queue instance to be used. diff --git a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml index e77523b02fad..d4412aea7b73 100644 --- a/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml +++ b/Documentation/devicetree/bindings/display/allwinner,sun4i-a10-display-engine.yaml @@ -69,6 +69,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 2 + items: + maxItems: 1 description: | Available display engine frontends (DE 1.0) or mixers (DE 2.0/3.0) available. diff --git a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml index a1d5a32660e0..a9d34dd7bbc5 100644 --- a/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/brcm,bcm2711-hdmi.yaml @@ -72,8 +72,7 @@ properties: - const: hpd-removed ddc: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle + $ref: /schemas/types.yaml#/definitions/phandle description: > Phandle of the I2C controller used for DDC EDID probing diff --git a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml index d3dd7a79b909..f08a01dfedf3 100644 --- a/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml +++ b/Documentation/devicetree/bindings/display/bridge/adi,adv7511.yaml @@ -76,9 +76,8 @@ properties: adi,input-depth: description: Number of bits per color component at the input. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [ 8, 10, 12 ] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 8, 10, 12 ] adi,input-colorspace: description: Input color space. diff --git a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml index 1d3e88daca04..35a48515836e 100644 --- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml +++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml @@ -83,6 +83,9 @@ properties: type: boolean description: let the driver enable audio HDMI codec function or not. + aux-bus: + $ref: /schemas/display/dp-aux-bus.yaml# + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -91,22 +94,7 @@ properties: $ref: /schemas/graph.yaml#/$defs/port-base unevaluatedProperties: false description: - MIPI DSI/DPI input. - - properties: - endpoint: - $ref: /schemas/media/video-interfaces.yaml# - type: object - additionalProperties: false - - properties: - remote-endpoint: true - - bus-type: - enum: [1, 5] - default: 1 - - data-lanes: true + Video port for MIPI DSI input. port@1: $ref: /schemas/graph.yaml#/properties/port @@ -155,8 +143,6 @@ examples: reg = <0>; anx7625_in: endpoint { remote-endpoint = <&mipi_dsi>; - bus-type = <5>; - data-lanes = <0 1 2 3>; }; }; @@ -167,5 +153,19 @@ examples: }; }; }; + + aux-bus { + panel { + compatible = "innolux,n125hce-gn1"; + power-supply = <&pp3300_disp_x>; + backlight = <&backlight_lcd0>; + + port { + panel_in: endpoint { + remote-endpoint = <&anx7625_out>; + }; + }; + }; + }; }; }; diff --git a/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml new file mode 100644 index 000000000000..b8219eab4475 --- /dev/null +++ b/Documentation/devicetree/bindings/display/bridge/ingenic,jz4780-hdmi.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/bridge/ingenic,jz4780-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Bindings for Ingenic JZ4780 HDMI Transmitter + +maintainers: + - H. Nikolaus Schaller <hns@goldelico.com> + +description: | + The HDMI Transmitter in the Ingenic JZ4780 is a Synopsys DesignWare HDMI 1.4 + TX controller IP with accompanying PHY IP. + +allOf: + - $ref: synopsys,dw-hdmi.yaml# + +properties: + compatible: + const: ingenic,jz4780-dw-hdmi + + reg-io-width: + const: 4 + + clocks: + maxItems: 2 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: Input from LCD controller output. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: Link to the HDMI connector. + +required: + - compatible + - clocks + - clock-names + - ports + - reg-io-width + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/ingenic,jz4780-cgu.h> + + hdmi: hdmi@10180000 { + compatible = "ingenic,jz4780-dw-hdmi"; + reg = <0x10180000 0x8000>; + reg-io-width = <4>; + ddc-i2c-bus = <&i2c4>; + interrupt-parent = <&intc>; + interrupts = <3>; + clocks = <&cgu JZ4780_CLK_AHB0>, <&cgu JZ4780_CLK_HDMI>; + clock-names = "iahb", "isfr"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + hdmi_in: port@0 { + reg = <0>; + dw_hdmi_in: endpoint { + remote-endpoint = <&jz4780_lcd_out>; + }; + }; + hdmi_out: port@1 { + reg = <1>; + dw_hdmi_out: endpoint { + remote-endpoint = <&hdmi_con>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml index 5079c1cc337b..3a8614e0f627 100644 --- a/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml +++ b/Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml @@ -39,6 +39,7 @@ properties: - const: lvds-encoder # Generic LVDS encoder compatible fallback - items: - enum: + - ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver - ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver - const: lvds-decoder # Generic LVDS decoders compatible fallback - enum: @@ -67,7 +68,7 @@ properties: - vesa-24 description: | The color signals mapping order. See details in - Documentation/devicetree/bindings/display/panel/lvds.yaml + Documentation/devicetree/bindings/display/lvds.yaml port@1: $ref: /schemas/graph.yaml#/properties/port diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml index acfc327f70a7..a51baf8a4c76 100644 --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.yaml @@ -28,6 +28,7 @@ properties: - renesas,r8a7793-lvds # for R-Car M2-N compatible LVDS encoders - renesas,r8a7795-lvds # for R-Car H3 compatible LVDS encoders - renesas,r8a7796-lvds # for R-Car M3-W compatible LVDS encoders + - renesas,r8a77961-lvds # for R-Car M3-W+ compatible LVDS encoders - renesas,r8a77965-lvds # for R-Car M3-N compatible LVDS encoders - renesas,r8a77970-lvds # for R-Car V3M compatible LVDS encoders - renesas,r8a77980-lvds # for R-Car V3H compatible LVDS encoders diff --git a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml index 9be44a682e67..b00246faea57 100644 --- a/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml +++ b/Documentation/devicetree/bindings/display/bridge/synopsys,dw-hdmi.yaml @@ -26,9 +26,8 @@ properties: reg-io-width: description: Width (in bytes) of the registers specified by the reg property. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - enum: [1, 4] + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 4] default: 1 clocks: diff --git a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml index b446d0f0f1b4..48a97bb3e2e0 100644 --- a/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml +++ b/Documentation/devicetree/bindings/display/bridge/ti,sn65dsi83.yaml @@ -32,6 +32,9 @@ properties: maxItems: 1 description: GPIO specifier for bridge_en pin (active high). + vcc-supply: + description: A 1.8V power supply (see regulator/regulator.yaml). + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -91,7 +94,6 @@ properties: required: - compatible - reg - - enable-gpios - ports allOf: @@ -133,6 +135,7 @@ examples: reg = <0x2d>; enable-gpios = <&gpio2 1 GPIO_ACTIVE_HIGH>; + vcc-supply = <®_sn65dsi83_1v8>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml index eacfe7165083..3bd670b8e5cd 100644 --- a/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml +++ b/Documentation/devicetree/bindings/display/bridge/toshiba,tc358768.yaml @@ -77,7 +77,10 @@ required: - vddio-supply - ports -additionalProperties: false +allOf: + - $ref: ../dsi-controller.yaml# + +unevaluatedProperties: false examples: - | @@ -87,7 +90,7 @@ examples: #address-cells = <1>; #size-cells = <0>; - dsi_bridge: dsi-bridge@e { + dsi_bridge: dsi@e { compatible = "toshiba,tc358768"; reg = <0xe>; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt b/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt deleted file mode 100644 index 0fba2ee6440a..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos-mic.txt +++ /dev/null @@ -1,51 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC mobile image compressor (MIC) - -MIC (mobile image compressor) resides between decon and mipi dsi. Mipi dsi is -not capable to transfer high resoltuion frame data as decon can send. MIC -solves this problem by compressing the frame data by 1/2 before it is -transferred through mipi dsi. The compressed frame data must be uncompressed in -the panel PCB. - -Required properties: -- compatible: value should be "samsung,exynos5433-mic". -- reg: physical base address and length of the MIC registers set and system - register of mic. -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_mic0", "sclk_rgb_vclk_to_mic0". -- samsung,disp-syscon: the reference node for syscon for DISP block. -- ports: contains a port which is connected to decon node and dsi node. - address-cells and size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the - decon node or dsi node. The reg value must be 0 and 1 respectively. - -Example: -SoC specific DT entry: -mic: mic@13930000 { - compatible = "samsung,exynos5433-mic"; - reg = <0x13930000 0x48>; - clocks = <&cmu_disp CLK_PCLK_MIC0>, - <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; - clock-names = "pclk_mic0", "sclk_rgb_vclk_to_mic0"; - samsung,disp-syscon = <&syscon_disp>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - mic_to_decon: endpoint { - remote-endpoint = <&decon_to_mic>; - }; - }; - - port@1 { - reg = <1>; - mic_to_dsi: endpoint { - remote-endpoint = <&dsi_to_mic>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt deleted file mode 100644 index 775193e1c641..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos5433-decon.txt +++ /dev/null @@ -1,60 +0,0 @@ -Device-Tree bindings for Samsung Exynos SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of: - "samsung,exynos5433-decon", "samsung,exynos5433-decon-tv"; -- reg: physical base address and length of the DECON registers set. -- interrupt-names: should contain the interrupt names depending on mode of work: - video mode: "vsync", - command mode: "lcd_sys", - command mode with software trigger: "lcd_sys", "te". -- interrupts or interrupts-extended: list of interrupt specifiers corresponding - to names privided in interrupt-names, as described in - interrupt-controller/interrupts.txt -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk", "aclk_decon", "aclk_smmu_decon0x", - "aclk_xiu_decon0x", "pclk_smmu_decon0x", "aclk_smmu_decon1x", - "aclk_xiu_decon1x", "pclk_smmu_decon1x", clk_decon_vclk", - "sclk_decon_eclk" -- ports: contains a port which is connected to mic node. address-cells and - size-cells must 1 and 0, respectively. -- port: contains an endpoint node which is connected to the endpoint in the mic - node. The reg value muset be 0. - -Example: -SoC specific DT entry: -decon: decon@13800000 { - compatible = "samsung,exynos5433-decon"; - reg = <0x13800000 0x2104>; - clocks = <&cmu_disp CLK_ACLK_DECON>, <&cmu_disp CLK_ACLK_SMMU_DECON0X>, - <&cmu_disp CLK_ACLK_XIU_DECON0X>, - <&cmu_disp CLK_PCLK_SMMU_DECON0X>, - <&cmu_disp CLK_ACLK_SMMU_DECON1X>, - <&cmu_disp CLK_ACLK_XIU_DECON1X>, - <&cmu_disp CLK_PCLK_SMMU_DECON1X>, - <&cmu_disp CLK_SCLK_DECON_VCLK>, - <&cmu_disp CLK_SCLK_DECON_ECLK>; - clock-names = "aclk_decon", "aclk_smmu_decon0x", "aclk_xiu_decon0x", - "pclk_smmu_decon0x", "aclk_smmu_decon1x", "aclk_xiu_decon1x", - "pclk_smmu_decon1x", "sclk_decon_vclk", "sclk_decon_eclk"; - interrupt-names = "vsync", "lcd_sys"; - interrupts = <0 202 0>, <0 203 0>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - decon_to_mic: endpoint { - remote-endpoint = <&mic_to_decon>; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt b/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt deleted file mode 100644 index 53912c99ec38..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos7-decon.txt +++ /dev/null @@ -1,65 +0,0 @@ -Device-Tree bindings for Samsung Exynos7 SoC display controller (DECON) - -DECON (Display and Enhancement Controller) is the Display Controller for the -Exynos7 series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be "samsung,exynos7-decon"; - -- reg: physical base address and length of the DECON registers set. - -- interrupts: should contain a list of all DECON IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "pclk_decon0", "aclk_decon0", - "decon0_eclk", "decon0_vclk". -- i80-if-timings: timing configuration for lcd i80 interface support. - -Optional Properties: -- power-domains: a phandle to DECON power domain node. -- display-timings: timing settings for DECON, as described in document [1]. - Can be used in case timings cannot be provided otherwise - or to override timings provided by the panel. - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt - -Example: - -SoC specific DT entry: - - decon@13930000 { - compatible = "samsung,exynos7-decon"; - interrupt-parent = <&combiner>; - reg = <0x13930000 0x1000>; - interrupt-names = "lcd_sys", "vsync", "fifo"; - interrupts = <0 188 0>, <0 189 0>, <0 190 0>; - clocks = <&clock_disp PCLK_DECON_INT>, - <&clock_disp ACLK_DECON_INT>, - <&clock_disp SCLK_DECON_INT_ECLK>, - <&clock_disp SCLK_DECON_INT_EXTCLKPLL>; - clock-names = "pclk_decon0", "aclk_decon0", "decon0_eclk", - "decon0_vclk"; - status = "disabled"; - }; - -Board specific DT entry: - - decon@13930000 { - pinctrl-0 = <&lcd_clk &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt deleted file mode 100644 index 58b12e25bbb1..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmi.txt +++ /dev/null @@ -1,64 +0,0 @@ -Device-Tree bindings for drm hdmi driver - -Required properties: -- compatible: value should be one among the following: - 1) "samsung,exynos4210-hdmi" - 2) "samsung,exynos4212-hdmi" - 3) "samsung,exynos5420-hdmi" - 4) "samsung,exynos5433-hdmi" -- reg: physical base address of the hdmi and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- hpd-gpios: following information about the hotplug gpio pin. - a) phandle of the gpio controller node. - b) pin number within the gpio controller. - c) optional flags and pull up/down. -- ddc: phandle to the hdmi ddc node -- phy: phandle to the hdmi phy node -- samsung,syscon-phandle: phandle for system controller node for PMU. -- #sound-dai-cells: should be 0. - -Required properties for Exynos 4210, 4212, 5420 and 5433: -- clocks: list of clock IDs from SoC clock driver. - a) hdmi: Gate of HDMI IP bus clock. - b) sclk_hdmi: Gate of HDMI special clock. - c) sclk_pixel: Pixel special clock, one of the two possible inputs of - HDMI clock mux. - d) sclk_hdmiphy: HDMI PHY clock output, one of two possible inputs of - HDMI clock mux. - e) mout_hdmi: It is required by the driver to switch between the 2 - parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable - after configuration, parent is set to sclk_hdmiphy else - sclk_pixel. -- clock-names: aliases as per driver requirements for above clock IDs: - "hdmi", "sclk_hdmi", "sclk_pixel", "sclk_hdmiphy" and "mout_hdmi". - -Required properties for Exynos 5433: -- clocks: list of clock specifiers according to common clock bindings. - a) hdmi_pclk: Gate of HDMI IP APB bus. - b) hdmi_i_pclk: Gate of HDMI-PHY IP APB bus. - d) i_tmds_clk: Gate of HDMI TMDS clock. - e) i_pixel_clk: Gate of HDMI pixel clock. - f) i_spdif_clk: Gate of HDMI SPDIF clock. - g) oscclk: Oscillator clock, used as parent of following *_user clocks - in case HDMI-PHY is not operational. - h) tmds_clko: TMDS clock generated by HDMI-PHY. - i) tmds_clko_user: MUX used to switch between oscclk and tmds_clko, - respectively if HDMI-PHY is off and operational. - j) pixel_clko: Pixel clock generated by HDMI-PHY. - k) pixel_clko_user: MUX used to switch between oscclk and pixel_clko, - respectively if HDMI-PHY is off and operational. -- clock-names: aliases for above clock specfiers. -- samsung,sysreg: handle to syscon used to control the system registers. - -Example: - - hdmi { - compatible = "samsung,exynos4212-hdmi"; - reg = <0x14530000 0x100000>; - interrupts = <0 95 0>; - hpd-gpios = <&gpx3 7 1>; - ddc = <&hdmi_ddc_node>; - phy = <&hdmi_phy_node>; - samsung,syscon-phandle = <&pmu_system_controller>; - }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt deleted file mode 100644 index 41eee971562b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiddc.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiddc driver - -Required properties: -- compatible: value should be one of the following - 1) "samsung,exynos5-hdmiddc" <DEPRECATED> - 2) "samsung,exynos4210-hdmiddc" - -- reg: I2C address of the hdmiddc device. - -Example: - - hdmiddc { - compatible = "samsung,exynos4210-hdmiddc"; - reg = <0x50>; - }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt b/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt deleted file mode 100644 index 162f641f7639..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_hdmiphy.txt +++ /dev/null @@ -1,15 +0,0 @@ -Device-Tree bindings for hdmiphy driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-hdmiphy" <DEPRECATED> - 2) "samsung,exynos4210-hdmiphy". - 3) "samsung,exynos4212-hdmiphy". -- reg: I2C address of the hdmiphy device. - -Example: - - hdmiphy { - compatible = "samsung,exynos4210-hdmiphy"; - reg = <0x38>; - }; diff --git a/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt b/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt deleted file mode 100644 index 3e38128f866b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/exynos_mixer.txt +++ /dev/null @@ -1,26 +0,0 @@ -Device-Tree bindings for mixer driver - -Required properties: -- compatible: value should be one of the following: - 1) "samsung,exynos5-mixer" <DEPRECATED> - 2) "samsung,exynos4210-mixer" - 3) "samsung,exynos4212-mixer" - 4) "samsung,exynos5250-mixer" - 5) "samsung,exynos5420-mixer" - -- reg: physical base address of the mixer and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- clocks: list of clock IDs from SoC clock driver. - a) mixer: Gate of Mixer IP bus clock. - b) sclk_hdmi: HDMI Special clock, one of the two possible inputs of - mixer mux. - c) hdmi: Gate of HDMI IP bus clock, needed together with sclk_hdmi. - -Example: - - mixer { - compatible = "samsung,exynos5250-mixer"; - reg = <0x14450000 0x10000>; - interrupts = <0 94 0>; - }; diff --git a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt b/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt deleted file mode 100644 index b3096421d42b..000000000000 --- a/Documentation/devicetree/bindings/display/exynos/samsung-fimd.txt +++ /dev/null @@ -1,107 +0,0 @@ -Device-Tree bindings for Samsung SoC display controller (FIMD) - -FIMD (Fully Interactive Mobile Display) is the Display Controller for the -Samsung series of SoCs which transfers the image data from a video memory -buffer to an external LCD interface. - -Required properties: -- compatible: value should be one of the following - "samsung,s3c2443-fimd"; /* for S3C24XX SoCs */ - "samsung,s3c6400-fimd"; /* for S3C64XX SoCs */ - "samsung,s5pv210-fimd"; /* for S5PV210 SoC */ - "samsung,exynos3250-fimd"; /* for Exynos3250/3472 SoCs */ - "samsung,exynos4210-fimd"; /* for Exynos4 SoCs */ - "samsung,exynos5250-fimd"; /* for Exynos5250 SoCs */ - "samsung,exynos5420-fimd"; /* for Exynos5420/5422/5800 SoCs */ - -- reg: physical base address and length of the FIMD registers set. - -- interrupts: should contain a list of all FIMD IP block interrupts in the - order: FIFO Level, VSYNC, LCD_SYSTEM. The interrupt specifier - format depends on the interrupt controller used. - -- interrupt-names: should contain the interrupt names: "fifo", "vsync", - "lcd_sys", in the same order as they were listed in the interrupts - property. - -- pinctrl-0: pin control group to be used for this controller. - -- pinctrl-names: must contain a "default" entry. - -- clocks: must include clock specifiers corresponding to entries in the - clock-names property. - -- clock-names: list of clock names sorted in the same order as the clocks - property. Must contain "sclk_fimd" and "fimd". - -Optional Properties: -- power-domains: a phandle to FIMD power domain node. -- samsung,invert-vden: video enable signal is inverted -- samsung,invert-vclk: video clock signal is inverted -- display-timings: timing settings for FIMD, as described in document [1]. - Can be used in case timings cannot be provided otherwise - or to override timings provided by the panel. -- samsung,sysreg: handle to syscon used to control the system registers -- i80-if-timings: timing configuration for lcd i80 interface support. - - cs-setup: clock cycles for the active period of address signal is enabled - until chip select is enabled. - If not specified, the default value(0) will be used. - - wr-setup: clock cycles for the active period of CS signal is enabled until - write signal is enabled. - If not specified, the default value(0) will be used. - - wr-active: clock cycles for the active period of CS is enabled. - If not specified, the default value(1) will be used. - - wr-hold: clock cycles for the active period of CS is disabled until write - signal is disabled. - If not specified, the default value(0) will be used. - - The parameters are defined as: - - VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? - : : : : : - Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX - | cs-setup+1 | : : : - |<---------->| : : : - Chip Select ???????????????|____________:____________:____________|?? - | wr-setup+1 | | wr-hold+1 | - |<---------->| |<---------->| - Write Enable ????????????????????????????|____________|??????????????? - | wr-active+1| - |<---------->| - Video Data ----------------------------<XXXXXXXXXXXXXXXXXXXXXXXXX>-- - -The device node can contain 'port' child nodes according to the bindings defined -in [2]. The following are properties specific to those nodes: -- reg: (required) port index, can be: - 0 - for CAMIF0 input, - 1 - for CAMIF1 input, - 2 - for CAMIF2 input, - 3 - for parallel output, - 4 - for write-back interface - -[1]: Documentation/devicetree/bindings/display/panel/display-timing.txt -[2]: Documentation/devicetree/bindings/media/video-interfaces.txt - -Example: - -SoC specific DT entry: - - fimd@11c00000 { - compatible = "samsung,exynos4210-fimd"; - interrupt-parent = <&combiner>; - reg = <0x11c00000 0x20000>; - interrupt-names = "fifo", "vsync", "lcd_sys"; - interrupts = <11 0>, <11 1>, <11 2>; - clocks = <&clock 140>, <&clock 283>; - clock-names = "sclk_fimd", "fimd"; - power-domains = <&pd_lcd0>; - status = "disabled"; - }; - -Board specific DT entry: - - fimd@11c00000 { - pinctrl-0 = <&lcd_clk &lcd_data24 &pwm1_out>; - pinctrl-names = "default"; - status = "okay"; - }; diff --git a/Documentation/devicetree/bindings/display/panel/lvds.yaml b/Documentation/devicetree/bindings/display/lvds.yaml index 49460c9dceea..7cd2ce7e9c33 100644 --- a/Documentation/devicetree/bindings/display/panel/lvds.yaml +++ b/Documentation/devicetree/bindings/display/lvds.yaml @@ -1,10 +1,10 @@ # SPDX-License-Identifier: GPL-2.0 %YAML 1.2 --- -$id: http://devicetree.org/schemas/display/panel/lvds.yaml# +$id: http://devicetree.org/schemas/display/lvds.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: LVDS Display Panel +title: LVDS Display Common Properties maintainers: - Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> @@ -13,8 +13,8 @@ maintainers: description: |+ LVDS is a physical layer specification defined in ANSI/TIA/EIA-644-A. Multiple incompatible data link layers have been used over time to transmit image data - to LVDS panels. This bindings supports display panels compatible with the - following specifications. + to LVDS devices. This bindings supports devices compatible with the following + specifications. [JEIDA] "Digital Interface Standards for Monitor", JEIDA-59-1999, February 1999 (Version 1.0), Japan Electronic Industry Development Association (JEIDA) @@ -26,18 +26,7 @@ description: |+ Device compatible with those specifications have been marketed under the FPD-Link and FlatLink brands. -allOf: - - $ref: panel-common.yaml# - properties: - compatible: - contains: - const: panel-lvds - description: - Shall contain "panel-lvds" in addition to a mandatory panel-specific - compatible string defined in individual panel bindings. The "panel-lvds" - value shall never be used on its own. - data-mapping: enum: - jeida-18 @@ -96,22 +85,6 @@ properties: If set, reverse the bit order described in the data mappings below on all data lanes, transmitting bits for slots 6 to 0 instead of 0 to 6. - port: true - ports: true - -required: - - compatible - - data-mapping - - width-mm - - height-mm - - panel-timing - -oneOf: - - required: - - port - - required: - - ports - additionalProperties: true ... diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml new file mode 100644 index 000000000000..61f0ed1e388f --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,aal.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,aal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display adaptive ambient light processor + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display adaptive ambient light processor, namely AAL, + is responsible for backlight power saving and sunlight visibility improving. + AAL device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-aal + - items: + - enum: + - mediatek,mt2712-disp-aal + - mediatek,mt8183-disp-aal + - mediatek,mt8192-disp-aal + - mediatek,mt8195-disp-aal + - enum: + - mediatek,mt8173-disp-aal + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: AAL Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + aal@14015000 { + compatible = "mediatek,mt8173-disp-aal"; + reg = <0 0x14015000 0 0x1000>; + interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_AAL>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x5000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml new file mode 100644 index 000000000000..0ed53b6238f0 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ccorr.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ccorr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display color correction + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display color correction, namely CCORR, reproduces correct color + on panels with different color gamut. + CCORR device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-ccorr + - items: + - const: mediatek,mt8192-disp-ccorr + - items: + - enum: + - mediatek,mt8195-disp-ccorr + - enum: + - mediatek,mt8192-disp-ccorr + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: CCORR Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/power/mt8183-power.h> + #include <dt-bindings/gce/mt8183-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ccorr0: ccorr@1400f000 { + compatible = "mediatek,mt8183-disp-ccorr"; + reg = <0 0x1400f000 0 0x1000>; + interrupts = <GIC_SPI 232 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_CCORR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xf000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml new file mode 100644 index 000000000000..3ad842eb5668 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,color.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,color.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display color processor + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display color processor, namely COLOR, provides hue, luma and + saturation adjustments to get better picture quality and to have one panel + resemble the other in their output characteristics. + COLOR device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-color + - items: + - const: mediatek,mt8167-disp-color + - items: + - const: mediatek,mt8173-disp-color + - items: + - enum: + - mediatek,mt7623-disp-color + - mediatek,mt2712-disp-color + - enum: + - mediatek,mt2701-disp-color + - items: + - enum: + - mediatek,mt8183-disp-color + - mediatek,mt8192-disp-color + - mediatek,mt8195-disp-color + - enum: + - mediatek,mt8173-disp-color + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: COLOR Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + color0: color@14013000 { + compatible = "mediatek,mt8173-disp-color"; + reg = <0 0x14013000 0 0x1000>; + interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_COLOR0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x3000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt deleted file mode 100644 index 78044c340e20..000000000000 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt +++ /dev/null @@ -1,219 +0,0 @@ -Mediatek display subsystem -========================== - -The Mediatek display subsystem consists of various DISP function blocks in the -MMSYS register space. The connections between them can be configured by output -and input selectors in the MMSYS_CONFIG register space. Pixel clock and start -of frame signal are distributed to the other function blocks by a DISP_MUTEX -function block. - -All DISP device tree nodes must be siblings to the central MMSYS_CONFIG node. -For a description of the MMSYS_CONFIG binding, see -Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml. - -DISP function blocks -==================== - -A display stream starts at a source function block that reads pixel data from -memory and ends with a sink function block that drives pixels on a display -interface, or writes pixels back to memory. All DISP function blocks have -their own register space, interrupt, and clock gate. The blocks that can -access memory additionally have to list the IOMMU and local arbiter they are -connected to. - -For a description of the display interface sink function blocks, see -Documentation/devicetree/bindings/display/mediatek/mediatek,dsi.txt and -Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml. - -Required properties (all function blocks): -- compatible: "mediatek,<chip>-disp-<function>", one of - "mediatek,<chip>-disp-ovl" - overlay (4 layers, blending, csc) - "mediatek,<chip>-disp-ovl-2l" - overlay (2 layers, blending, csc) - "mediatek,<chip>-disp-rdma" - read DMA / line buffer - "mediatek,<chip>-disp-wdma" - write DMA - "mediatek,<chip>-disp-ccorr" - color correction - "mediatek,<chip>-disp-color" - color processor - "mediatek,<chip>-disp-dither" - dither - "mediatek,<chip>-disp-aal" - adaptive ambient light controller - "mediatek,<chip>-disp-gamma" - gamma correction - "mediatek,<chip>-disp-merge" - merge streams from two RDMA sources - "mediatek,<chip>-disp-postmask" - control round corner for display frame - "mediatek,<chip>-disp-split" - split stream to two encoders - "mediatek,<chip>-disp-ufoe" - data compression engine - "mediatek,<chip>-dsi" - DSI controller, see mediatek,dsi.txt - "mediatek,<chip>-dpi" - DPI controller, see mediatek,dpi.txt - "mediatek,<chip>-disp-mutex" - display mutex - "mediatek,<chip>-disp-od" - overdrive - the supported chips are mt2701, mt7623, mt2712, mt8167, mt8173, mt8183 and mt8192. -- reg: Physical base address and length of the function block register space -- interrupts: The interrupt signal from the function block (required, except for - merge and split function blocks). -- clocks: device clocks - See Documentation/devicetree/bindings/clock/clock-bindings.txt for details. - For most function blocks this is just a single clock input. Only the DSI and - DPI controller nodes have multiple clock inputs. These are documented in - mediatek,dsi.txt and mediatek,dpi.txt, respectively. - An exception is that the mt8183 mutex is always free running with no clocks property. - -Required properties (DMA function blocks): -- compatible: Should be one of - "mediatek,<chip>-disp-ovl" - "mediatek,<chip>-disp-rdma" - "mediatek,<chip>-disp-wdma" - the supported chips are mt2701, mt8167 and mt8173. -- larb: Should contain a phandle pointing to the local arbiter device as defined - in Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml -- iommus: Should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Optional properties (RDMA function blocks): -- mediatek,rdma-fifo-size: rdma fifo size may be different even in same SOC, add this - property to the corresponding rdma - the value is the Max value which defined in hardware data sheet. - mediatek,rdma-fifo-size of mt8173-rdma0 is 8K - mediatek,rdma-fifo-size of mt8183-rdma0 is 5K - mediatek,rdma-fifo-size of mt8183-rdma1 is 2K - -Examples: - -mmsys: clock-controller@14000000 { - compatible = "mediatek,mt8173-mmsys", "syscon"; - reg = <0 0x14000000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - #clock-cells = <1>; -}; - -ovl0: ovl@1400c000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400c000 0 0x1000>; - interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL0>; - iommus = <&iommu M4U_PORT_DISP_OVL0>; - mediatek,larb = <&larb0>; -}; - -ovl1: ovl@1400d000 { - compatible = "mediatek,mt8173-disp-ovl"; - reg = <0 0x1400d000 0 0x1000>; - interrupts = <GIC_SPI 181 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OVL1>; - iommus = <&iommu M4U_PORT_DISP_OVL1>; - mediatek,larb = <&larb4>; -}; - -rdma0: rdma@1400e000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400e000 0 0x1000>; - interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA0>; - iommus = <&iommu M4U_PORT_DISP_RDMA0>; - mediatek,larb = <&larb0>; - mediatek,rdma-fifosize = <8192>; -}; - -rdma1: rdma@1400f000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x1400f000 0 0x1000>; - interrupts = <GIC_SPI 183 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA1>; - iommus = <&iommu M4U_PORT_DISP_RDMA1>; - mediatek,larb = <&larb4>; -}; - -rdma2: rdma@14010000 { - compatible = "mediatek,mt8173-disp-rdma"; - reg = <0 0x14010000 0 0x1000>; - interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_RDMA2>; - iommus = <&iommu M4U_PORT_DISP_RDMA2>; - mediatek,larb = <&larb4>; -}; - -wdma0: wdma@14011000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14011000 0 0x1000>; - interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA0>; - iommus = <&iommu M4U_PORT_DISP_WDMA0>; - mediatek,larb = <&larb0>; -}; - -wdma1: wdma@14012000 { - compatible = "mediatek,mt8173-disp-wdma"; - reg = <0 0x14012000 0 0x1000>; - interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_WDMA1>; - iommus = <&iommu M4U_PORT_DISP_WDMA1>; - mediatek,larb = <&larb4>; -}; - -color0: color@14013000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14013000 0 0x1000>; - interrupts = <GIC_SPI 187 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR0>; -}; - -color1: color@14014000 { - compatible = "mediatek,mt8173-disp-color"; - reg = <0 0x14014000 0 0x1000>; - interrupts = <GIC_SPI 188 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_COLOR1>; -}; - -aal@14015000 { - compatible = "mediatek,mt8173-disp-aal"; - reg = <0 0x14015000 0 0x1000>; - interrupts = <GIC_SPI 189 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_AAL>; -}; - -gamma@14016000 { - compatible = "mediatek,mt8173-disp-gamma"; - reg = <0 0x14016000 0 0x1000>; - interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_GAMMA>; -}; - -ufoe@1401a000 { - compatible = "mediatek,mt8173-disp-ufoe"; - reg = <0 0x1401a000 0 0x1000>; - interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_UFOE>; -}; - -dsi0: dsi@1401b000 { - /* See mediatek,dsi.txt for details */ -}; - -dpi0: dpi@1401d000 { - /* See mediatek,dpi.txt for details */ -}; - -mutex: mutex@14020000 { - compatible = "mediatek,mt8173-disp-mutex"; - reg = <0 0x14020000 0 0x1000>; - interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_MUTEX_32K>; -}; - -od@14023000 { - compatible = "mediatek,mt8173-disp-od"; - reg = <0 0x14023000 0 0x1000>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; - clocks = <&mmsys CLK_MM_DISP_OD>; -}; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml new file mode 100644 index 000000000000..6657549af165 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dither.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dither.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display dither processor + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display dither processor, namely DITHER, works by approximating + unavailable colors with available colors and by mixing and matching available + colors to mimic unavailable ones. + DITHER device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-dither + - items: + - enum: + - mediatek,mt8192-disp-dither + - mediatek,mt8195-disp-dither + - enum: + - mediatek,mt8183-disp-dither + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: DITHER Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/power/mt8183-power.h> + #include <dt-bindings/gce/mt8183-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + dither0: dither@14012000 { + compatible = "mediatek,mt8183-disp-dither"; + reg = <0 0x14012000 0 0x1000>; + interrupts = <GIC_SPI 235 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_DITHER0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x2000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml index dd2896a40ff0..843f89d6053f 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dpi.yaml @@ -70,8 +70,7 @@ examples: - | #include <dt-bindings/interrupt-controller/arm-gic.h> #include <dt-bindings/clock/mt8173-clk.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> - #include <dt-bindings/interrupt-controller/irq.h> + dpi0: dpi@1401d000 { compatible = "mediatek,mt8173-dpi"; reg = <0x1401d000 0x1000>; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml new file mode 100644 index 000000000000..49248864514b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,dsc.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,dsc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: mediatek display DSC controller + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + The DSC standard is a specification of the algorithms used for + compressing and decompressing image display streams, including + the specification of the syntax and semantics of the compressed + video bit stream. DSC is designed for real-time systems with + real-time compression, transmission, decompression and Display. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8195-disp-dsc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: DSC Wrapper Clock + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + mediatek,gce-client-reg: + description: + The register of client driver can be configured by gce with 4 arguments + defined in this property, such as phandle of gce, subsys id, + register offset and size. + Each subsys id is mapping to a base address of display function blocks + register which is defined in the gce header + include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8195-clk.h> + #include <dt-bindings/power/mt8195-power.h> + #include <dt-bindings/gce/mt8195-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + dsc0: disp_dsc_wrap@1c009000 { + compatible = "mediatek,mt8195-disp-dsc"; + reg = <0 0x1c009000 0 0x1000>; + interrupts = <GIC_SPI 645 IRQ_TYPE_LEVEL_HIGH 0>; + power-domains = <&spm MT8195_POWER_DOMAIN_VDOSYS0>; + clocks = <&vdosys0 CLK_VDO0_DSC_WRAP0>; + mediatek,gce-client-reg = <&gce1 SUBSYS_1c00XXXX 0x9000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml new file mode 100644 index 000000000000..78442339314f --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,gamma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display gamma correction + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display gamma correction, namely GAMMA, provides a nonlinear + operation used to adjust luminance in display system. + GAMMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-gamma + - items: + - const: mediatek,mt8183-disp-gamma + - items: + - enum: + - mediatek,mt8192-disp-gamma + - mediatek,mt8195-disp-gamma + - enum: + - mediatek,mt8183-disp-gamma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: GAMMA Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + gamma@14016000 { + compatible = "mediatek,mt8173-disp-gamma"; + reg = <0 0x14016000 0 0x1000>; + interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_GAMMA>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x6000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml index 111967efa999..bdaf0b51e68c 100644 --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,hdmi.yaml @@ -51,7 +51,10 @@ properties: mediatek,syscon-hdmi: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to system configuration registers + - description: register offset in the system configuration registers description: | phandle link and register offset to the system configuration registers. diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml new file mode 100644 index 000000000000..d635c5dcb68b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,merge.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,merge.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display merge + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display merge, namely MERGE, is used to merge two slice-per-line + inputs into one side-by-side output. + MERGE device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-merge + - items: + - const: mediatek,mt8195-disp-merge + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + oneOf: + - items: + - const: merge + - items: + - const: merge + - const: merge_async + + mediatek,merge-fifo-en: + description: + The setting of merge fifo is mainly provided for the display latency + buffer to ensure that the back-end panel display data will not be + underrun, a little more data is needed in the fifo. + According to the merge fifo settings, when the water level is detected + to be insufficient, it will trigger RDMA sending ultra and preulra + command to SMI to speed up the data rate. + type: boolean + + mediatek,merge-mute: + description: Support mute function. Mute the content of merge output. + type: boolean + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + + resets: + description: reset controller + See Documentation/devicetree/bindings/reset/reset.txt for details. + maxItems: 1 + +required: + - compatible + - reg + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + merge@14017000 { + compatible = "mediatek,mt8173-disp-merge"; + reg = <0 0x14017000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_MERGE>; + clock-names = "merge"; + }; + }; + diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml new file mode 100644 index 000000000000..00e6a1041a9b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,mutex.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,mutex.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek mutex + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek mutex, namely MUTEX, is used to send the triggers signals called + Start Of Frame (SOF) / End Of Frame (EOF) to each sub-modules on the display + data path or MDP data path. + In some SoC, such as mt2701, MUTEX could be a hardware mutex which protects + the shadow register. + MUTEX device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-mutex + - items: + - const: mediatek,mt2712-disp-mutex + - items: + - const: mediatek,mt8167-disp-mutex + - items: + - const: mediatek,mt8173-disp-mutex + - items: + - const: mediatek,mt8183-disp-mutex + - items: + - const: mediatek,mt8192-disp-mutex + - items: + - const: mediatek,mt8195-disp-mutex + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: MUTEX Clock + + mediatek,gce-events: + description: + The event id which is mapping to the specific hardware event signal + to gce. The event id is defined in the gce header + include/dt-bindings/gce/<chip>-gce.h of each chips. + $ref: /schemas/types.yaml#/definitions/uint32-array + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + mutex: mutex@14020000 { + compatible = "mediatek,mt8173-disp-mutex"; + reg = <0 0x14020000 0 0x1000>; + interrupts = <GIC_SPI 169 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_MUTEX_32K>; + mediatek,gce-events = <CMDQ_EVENT_MUTEX0_STREAM_EOF>, + <CMDQ_EVENT_MUTEX1_STREAM_EOF>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml new file mode 100644 index 000000000000..853fcb9db2be --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,od.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,od.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overdirve + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display overdrive, namely OD, increases the transition values + of pixels between consecutive frames to make LCD rotate faster. + OD device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2712-disp-od + - items: + - const: mediatek,mt8173-disp-od + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: OD Clock + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + od@14023000 { + compatible = "mediatek,mt8173-disp-od"; + reg = <0 0x14023000 0 0x1000>; + clocks = <&mmsys CLK_MM_DISP_OD>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml new file mode 100644 index 000000000000..da999ba53b7c --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl-2l.yaml @@ -0,0 +1,88 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ovl-2l.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overlay 2 layer + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display overlay 2 layer, namely OVL-2L, provides 2 more layer + for OVL. + OVL-2L device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8183-disp-ovl-2l + - items: + - const: mediatek,mt8192-disp-ovl-2l + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: OVL-2L Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/power/mt8183-power.h> + #include <dt-bindings/gce/mt8183-gce.h> + #include <dt-bindings/memory/mt8183-larb-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ovl_2l0: ovl@14009000 { + compatible = "mediatek,mt8183-disp-ovl-2l"; + reg = <0 0x14009000 0 0x1000>; + interrupts = <GIC_SPI 226 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&spm MT8183_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_OVL0_2L>; + iommus = <&iommu M4U_PORT_DISP_2L_OVL0_LARB0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0x9000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml new file mode 100644 index 000000000000..f77094e61443 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ovl.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,ovl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display overlay + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display overlay, namely OVL, can do alpha blending from + the memory. + OVL device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-ovl + - items: + - const: mediatek,mt8173-disp-ovl + - items: + - const: mediatek,mt8183-disp-ovl + - items: + - const: mediatek,mt8192-disp-ovl + - items: + - enum: + - mediatek,mt7623-disp-ovl + - mediatek,mt2712-disp-ovl + - enum: + - mediatek,mt2701-disp-ovl + - items: + - enum: + - mediatek,mt8195-disp-ovl + - enum: + - mediatek,mt8183-disp-ovl + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: OVL Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + #include <dt-bindings/memory/mt8173-larb-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ovl0: ovl@1400c000 { + compatible = "mediatek,mt8173-disp-ovl"; + reg = <0 0x1400c000 0 0x1000>; + interrupts = <GIC_SPI 180 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_OVL0>; + iommus = <&iommu M4U_PORT_DISP_OVL0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xc000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml new file mode 100644 index 000000000000..2d769422e29f --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,postmask.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,postmask.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display postmask + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display postmask, namely POSTMASK, provides round corner pattern + generation. + POSTMASK device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8192-disp-postmask + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: POSTMASK Clock + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8192-clk.h> + #include <dt-bindings/power/mt8192-power.h> + #include <dt-bindings/gce/mt8192-gce.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + postmask0: postmask@1400d000 { + compatible = "mediatek,mt8192-disp-postmask"; + reg = <0 0x1400d000 0 0x1000>; + interrupts = <GIC_SPI 262 IRQ_TYPE_LEVEL_HIGH 0>; + power-domains = <&scpsys MT8192_POWER_DOMAIN_DISP>; + clocks = <&mmsys CLK_MM_DISP_POSTMASK0>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xd000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml new file mode 100644 index 000000000000..e8c72afa0630 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,rdma.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,rdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Read Direct Memory Access + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek Read Direct Memory Access(RDMA) component used to read the + data into DMA. It provides real time data to the back-end panel + driver, such as DSI, DPI and DP_INTF. + It contains one line buffer to store the sufficient pixel data. + RDMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt2701-disp-rdma + - items: + - const: mediatek,mt8173-disp-rdma + - items: + - const: mediatek,mt8183-disp-rdma + - items: + - const: mediatek,mt8195-disp-rdma + - items: + - enum: + - mediatek,mt7623-disp-rdma + - mediatek,mt2712-disp-rdma + - enum: + - mediatek,mt2701-disp-rdma + - items: + - enum: + - mediatek,mt8192-disp-rdma + - enum: + - mediatek,mt8183-disp-rdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: RDMA Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,rdma-fifo-size: + description: + rdma fifo size may be different even in same SOC, add this property to the + corresponding rdma. + The value below is the Max value which defined in hardware data sheet + mediatek,rdma-fifo-size of mt8173-rdma0 is 8K + mediatek,rdma-fifo-size of mt8183-rdma0 is 5K + mediatek,rdma-fifo-size of mt8183-rdma1 is 2K + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8192, 5120, 2048] + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + #include <dt-bindings/memory/mt8173-larb-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + rdma0: rdma@1400e000 { + compatible = "mediatek,mt8173-disp-rdma"; + reg = <0 0x1400e000 0 0x1000>; + interrupts = <GIC_SPI 182 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_RDMA0>; + iommus = <&iommu M4U_PORT_DISP_RDMA0>; + mediatek,rdma-fifo-size = <8192>; + mediatek,gce-client-reg = <&gce SUBSYS_1400XXXX 0xe000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml new file mode 100644 index 000000000000..35ace1f322e8 --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,split.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,split.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display split + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display split, namely SPLIT, is used to split stream to two + encoders. + SPLIT device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-split + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: SPLIT Clock + +required: + - compatible + - reg + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + split0: split@14018000 { + compatible = "mediatek,mt8173-disp-split"; + reg = <0 0x14018000 0 0x1000>; + power-domains = <&spm MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_SPLIT0>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.yaml new file mode 100644 index 000000000000..b8bb135fe96b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,ufoe.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/mediatek/mediatek,ufoe.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek display UFOe + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek display UFOe stands for Unified Frame Optimization engine. + UFOe can cut the data rate for DSI port which may lead to reduce power + consumption. + UFOe device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-ufoe + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: UFOe Clock + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufoe@1401a000 { + compatible = "mediatek,mt8173-disp-ufoe"; + reg = <0 0x1401a000 0 0x1000>; + interrupts = <GIC_SPI 191 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_UFOE>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml new file mode 100644 index 000000000000..7d7cc1ab526b --- /dev/null +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,wdma.yaml @@ -0,0 +1,86 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/mediatek/mediatek,wdma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Write Direct Memory Access + +maintainers: + - Chun-Kuang Hu <chunkuang.hu@kernel.org> + - Philipp Zabel <p.zabel@pengutronix.de> + +description: | + Mediatek Write Direct Memory Access(WDMA) component used to write + the data into DMA. + WDMA device node must be siblings to the central MMSYS_CONFIG node. + For a description of the MMSYS_CONFIG binding, see + Documentation/devicetree/bindings/arm/mediatek/mediatek,mmsys.yaml + for details. + +properties: + compatible: + oneOf: + - items: + - const: mediatek,mt8173-disp-wdma + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + power-domains: + description: A phandle and PM domain specifier as defined by bindings of + the power controller specified by phandle. See + Documentation/devicetree/bindings/power/power-domain.yaml for details. + + clocks: + items: + - description: WDMA Clock + + iommus: + description: + This property should point to the respective IOMMU block with master port as argument, + see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + + mediatek,gce-client-reg: + description: The register of client driver can be configured by gce with + 4 arguments defined in this property, such as phandle of gce, subsys id, + register offset and size. Each GCE subsys id is mapping to a client + defined in the header include/dt-bindings/gce/<chip>-gce.h. + $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - power-domains + - clocks + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/power/mt8173-power.h> + #include <dt-bindings/gce/mt8173-gce.h> + #include <dt-bindings/memory/mt8173-larb-port.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + wdma0: wdma@14011000 { + compatible = "mediatek,mt8173-disp-wdma"; + reg = <0 0x14011000 0 0x1000>; + interrupts = <GIC_SPI 185 IRQ_TYPE_LEVEL_LOW>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; + clocks = <&mmsys CLK_MM_DISP_WDMA0>; + iommus = <&iommu M4U_PORT_DISP_WDMA0>; + mediatek,gce-client-reg = <&gce SUBSYS_1401XXXX 0x1000 0x1000>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml index 5457612ab136..cd05cfd76536 100644 --- a/Documentation/devicetree/bindings/display/msm/dp-controller.yaml +++ b/Documentation/devicetree/bindings/display/msm/dp-controller.yaml @@ -21,6 +21,7 @@ properties: - qcom,sc7280-edp - qcom,sc8180x-dp - qcom,sc8180x-edp + - qcom,sm8350-dp reg: items: diff --git a/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml new file mode 100644 index 000000000000..2df64afb76e6 --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-msm8998.yaml @@ -0,0 +1,219 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-msm8998.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for MSM8998 target + +maintainers: + - AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.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 MSM8998 target. + +properties: + compatible: + items: + - const: qcom,msm8998-mdss + + reg: + maxItems: 1 + + reg-names: + const: mdss + + power-domains: + maxItems: 1 + + clocks: + items: + - description: Display AHB clock + - 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 + + ranges: true + +patternProperties: + "^display-controller@[0-9a-f]+$": + type: object + description: Node containing the properties of DPU. + + properties: + compatible: + items: + - const: qcom,msm8998-dpu + + reg: + items: + - description: Address offset and size for mdp register set + - description: Address offset and size for regdma register set + - description: Address offset and size for vbif register set + - description: Address offset and size for non-realtime vbif register set + + reg-names: + items: + - const: mdp + - const: regdma + - const: vbif + - const: vbif_nrt + + clocks: + items: + - description: Display ahb clock + - description: Display axi clock + - description: Display mem-noc clock + - description: Display core clock + - description: Display vsync clock + + clock-names: + items: + - const: iface + - const: bus + - const: mnoc + - 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,mmcc-msm8998.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + mdss: display-subsystem@c900000 { + compatible = "qcom,msm8998-mdss"; + reg = <0x0c900000 0x1000>; + reg-names = "mdss"; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + #address-cells = <1>; + #interrupt-cells = <1>; + #size-cells = <1>; + + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + iommus = <&mmss_smmu 0>; + + power-domains = <&mmcc MDSS_GDSC>; + ranges; + + display-controller@c901000 { + compatible = "qcom,msm8998-dpu"; + reg = <0x0c901000 0x8f000>, + <0x0c9a8e00 0xf0>, + <0x0c9b0000 0x2008>, + <0x0c9b8000 0x1040>; + reg-names = "mdp", "regdma", "vbif", "vbif_nrt"; + + clocks = <&mmcc MDSS_AHB_CLK>, + <&mmcc MDSS_AXI_CLK>, + <&mmcc MNOC_AHB_CLK>, + <&mmcc MDSS_MDP_CLK>, + <&mmcc MDSS_VSYNC_CLK>; + clock-names = "iface", "bus", "mnoc", "core", "vsync"; + + interrupt-parent = <&mdss>; + interrupts = <0>; + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd MSM8998_VDDMX>; + + 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-qcm2290.yaml b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml new file mode 100644 index 000000000000..d31483a78eab --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/dpu-qcm2290.yaml @@ -0,0 +1,215 @@ +# SPDX-License-Identifier: GPL-2.0-only or BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/msm/dpu-qcm2290.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Display DPU dt properties for QCM2290 target + +maintainers: + - Loic Poulain <loic.poulain@linaro.org> + +description: | + Device tree bindings for MSM Mobile Display Subsystem(MDSS) that encapsulates + sub-blocks like DPU display controller and DSI. Device tree bindings of MDSS + and DPU are mentioned for QCM2290 target. + +properties: + compatible: + items: + - const: qcom,qcm2290-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 + + 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,qcm2290-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 AXI clock from gcc + - description: Display AHB clock from dispcc + - description: Display core clock from dispcc + - description: Display lut clock from dispcc + - description: Display vsync clock from dispcc + + clock-names: + items: + - const: bus + - const: iface + - const: core + - const: lut + - 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. 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) + + 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-qcm2290.h> + #include <dt-bindings/clock/qcom,gcc-qcm2290.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interconnect/qcom,qcm2290.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + mdss: mdss@5e00000 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "qcom,qcm2290-mdss", "qcom,mdss"; + reg = <0x05e00000 0x1000>; + reg-names = "mdss"; + power-domains = <&dispcc MDSS_GDSC>; + clocks = <&gcc GCC_DISP_AHB_CLK>, + <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>; + clock-names = "iface", "bus", "core"; + + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH>; + interrupt-controller; + #interrupt-cells = <1>; + + interconnects = <&mmrt_virt MASTER_MDP0 &bimc SLAVE_EBI1>; + interconnect-names = "mdp0-mem"; + + iommus = <&apps_smmu 0x420 0x2>, + <&apps_smmu 0x421 0x0>; + ranges; + + mdss_mdp: mdp@5e01000 { + compatible = "qcom,qcm2290-dpu"; + reg = <0x05e01000 0x8f000>, + <0x05eb0000 0x2008>; + reg-names = "mdp", "vbif"; + + clocks = <&gcc GCC_DISP_HF_AXI_CLK>, + <&dispcc DISP_CC_MDSS_AHB_CLK>, + <&dispcc DISP_CC_MDSS_MDP_CLK>, + <&dispcc DISP_CC_MDSS_MDP_LUT_CLK>, + <&dispcc DISP_CC_MDSS_VSYNC_CLK>; + clock-names = "bus", "iface", "core", "lut", "vsync"; + + operating-points-v2 = <&mdp_opp_table>; + power-domains = <&rpmpd QCM2290_VDDCX>; + + interrupt-parent = <&mdss>; + interrupts = <0>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + dpu_intf1_out: endpoint { + remote-endpoint = <&dsi0_in>; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml index 35426fde8610..7095ec3c890d 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml @@ -14,8 +14,9 @@ allOf: properties: compatible: - items: - - const: qcom,mdss-dsi-ctrl + enum: + - qcom,mdss-dsi-ctrl + - qcom,dsi-ctrl-6g-qcm2290 reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml index 4399715953e1..2d5a766d028f 100644 --- a/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml +++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-10nm.yaml @@ -35,6 +35,38 @@ properties: Connected to DSI0_MIPI_DSI_PLL_VDDA0P9 pin for sc7180 target and connected to VDDA_MIPI_DSI_0_PLL_0P9 pin for sdm845 target + qcom,phy-rescode-offset-top: + $ref: /schemas/types.yaml#/definitions/int8-array + minItems: 5 + maxItems: 5 + description: + Integer array of offset for pull-up legs rescode for all five lanes. + To offset the drive strength from the calibrated value in an increasing + manner, -32 is the weakest and +31 is the strongest. + items: + minimum: -32 + maximum: 31 + + qcom,phy-rescode-offset-bot: + $ref: /schemas/types.yaml#/definitions/int8-array + minItems: 5 + maxItems: 5 + description: + Integer array of offset for pull-down legs rescode for all five lanes. + To offset the drive strength from the calibrated value in a decreasing + manner, -32 is the weakest and +31 is the strongest. + items: + minimum: -32 + maximum: 31 + + qcom,phy-drive-ldo-level: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: + The PHY LDO has an amplitude tuning feature to adjust the LDO output + for the HSTX drive. Use supported levels (mV) to offset the drive level + from the default value. + enum: [ 375, 400, 425, 450, 475, 500 ] + required: - compatible - reg @@ -64,5 +96,9 @@ examples: clocks = <&dispcc DISP_CC_MDSS_AHB_CLK>, <&rpmhcc RPMH_CXO_CLK>; clock-names = "iface", "ref"; + + qcom,phy-rescode-offset-top = /bits/ 8 <0 0 0 0 0>; + qcom,phy-rescode-offset-bot = /bits/ 8 <0 0 0 0 0>; + qcom,phy-drive-ldo-level = <400>; }; ... diff --git a/Documentation/devicetree/bindings/display/msm/gpu.yaml b/Documentation/devicetree/bindings/display/msm/gpu.yaml index 99a1ba3ada56..3397bc31d087 100644 --- a/Documentation/devicetree/bindings/display/msm/gpu.yaml +++ b/Documentation/devicetree/bindings/display/msm/gpu.yaml @@ -64,6 +64,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. phandle to the On Chip Memory (OCMEM) that's present on some a3xx and diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.txt b/Documentation/devicetree/bindings/display/msm/mdp4.txt deleted file mode 100644 index b07eeb38f709..000000000000 --- a/Documentation/devicetree/bindings/display/msm/mdp4.txt +++ /dev/null @@ -1,114 +0,0 @@ -Qualcomm adreno/snapdragon MDP4 display controller - -Description: - -This is the bindings documentation for the MDP4 display controller found in -SoCs like MSM8960, APQ8064 and MSM8660. - -Required properties: -- compatible: - * "qcom,mdp4" - mdp4 -- reg: Physical base address and length of the controller's registers. -- interrupts: The interrupt signal from the display controller. -- clocks: device clocks - See ../clocks/clock-bindings.txt for details. -- clock-names: the following clocks are required. - * "core_clk" - * "iface_clk" - * "bus_clk" - * "lut_clk" - * "hdmi_clk" - * "tv_clk" -- ports: contains the list of output ports from MDP. These connect to interfaces - that are external to the MDP hardware, such as HDMI, DSI, EDP etc (LVDS is a - special case since it is a part of the MDP block itself). - - 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 - - The output port mappings are: - Port 0 -> LCDC/LVDS - Port 1 -> DSI1 Cmd/Video - Port 2 -> DSI2 Cmd/Video - Port 3 -> DTV - -Optional properties: -- clock-names: the following clocks are optional: - * "lut_clk" -- qcom,lcdc-align-lsb: Boolean value indicating that LSB alignment should be - used for LCDC. This is only valid for 18bpp panels. - -Example: - -/ { - ... - - hdmi: hdmi@4a00000 { - ... - ports { - ... - port@0 { - reg = <0>; - hdmi_in: endpoint { - remote-endpoint = <&mdp_dtv_out>; - }; - }; - ... - }; - ... - }; - - ... - - mdp: mdp@5100000 { - compatible = "qcom,mdp4"; - reg = <0x05100000 0xf0000>; - interrupts = <GIC_SPI 75 0>; - clock-names = - "core_clk", - "iface_clk", - "lut_clk", - "hdmi_clk", - "tv_clk"; - clocks = - <&mmcc MDP_CLK>, - <&mmcc MDP_AHB_CLK>, - <&mmcc MDP_AXI_CLK>, - <&mmcc MDP_LUT_CLK>, - <&mmcc HDMI_TV_CLK>, - <&mmcc MDP_TV_CLK>; - - ports { - #address-cells = <1>; - #size-cells = <0>; - - port@0 { - reg = <0>; - mdp_lvds_out: endpoint { - }; - }; - - port@1 { - reg = <1>; - mdp_dsi1_out: endpoint { - }; - }; - - port@2 { - reg = <2>; - mdp_dsi2_out: endpoint { - }; - }; - - port@3 { - reg = <3>; - mdp_dtv_out: endpoint { - remote-endpoint = <&hdmi_in>; - }; - }; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/display/msm/mdp4.yaml b/Documentation/devicetree/bindings/display/msm/mdp4.yaml new file mode 100644 index 000000000000..f63f60fea27c --- /dev/null +++ b/Documentation/devicetree/bindings/display/msm/mdp4.yaml @@ -0,0 +1,124 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/display/msm/mdp4.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Adreno/Snapdragon MDP4 display controller + +description: > + MDP4 display controller found in SoCs like MSM8960, APQ8064 and MSM8660. + +maintainers: + - Rob Clark <robdclark@gmail.com> + +properties: + compatible: + const: qcom,mdp4 + + clocks: + minItems: 6 + maxItems: 6 + + clock-names: + items: + - const: core_clk + - const: iface_clk + - const: bus_clk + - const: lut_clk + - const: hdmi_clk + - const: tv_clk + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: LCDC/LVDS + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: DSI1 Cmd / Video + + port@2: + $ref: /schemas/graph.yaml#/properties/port + description: DSI2 Cmd / Video + + port@3: + $ref: /schemas/graph.yaml#/properties/port + description: Digital TV + + qcom,lcdc-align-lsb: + type: boolean + description: > + Indication that LSB alignment should be used for LCDC. + This is only valid for 18bpp panels. + +required: + - compatible + - reg + - clocks + - ports + +additionalProperties: false + +examples: + - | + mdp: mdp@5100000 { + compatible = "qcom,mdp4"; + reg = <0x05100000 0xf0000>; + interrupts = <0 75 0>; + clock-names = + "core_clk", + "iface_clk", + "bus_clk", + "lut_clk", + "hdmi_clk", + "tv_clk"; + clocks = + <&mmcc 77>, + <&mmcc 86>, + <&mmcc 102>, + <&mmcc 75>, + <&mmcc 97>, + <&mmcc 12>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mdp_lvds_out: endpoint { + }; + }; + + port@1 { + reg = <1>; + mdp_dsi1_out: endpoint { + }; + }; + + port@2 { + reg = <2>; + mdp_dsi2_out: endpoint { + }; + }; + + port@3 { + reg = <3>; + mdp_dtv_out: endpoint { + remote-endpoint = <&hdmi_in>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml index 93878c2cd370..3a8c2c11f9bd 100644 --- a/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml +++ b/Documentation/devicetree/bindings/display/panel/advantech,idk-1110wr.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding <thierry.reding@gmail.com> allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: advantech,idk-1110wr + + required: + - compatible properties: compatible: items: - const: advantech,idk-1110wr - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds data-mapping: const: jeida-24 @@ -35,6 +45,11 @@ additionalProperties: false required: - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/display-timings.yaml b/Documentation/devicetree/bindings/display/panel/display-timings.yaml index 56903ded005e..6d30575819d3 100644 --- a/Documentation/devicetree/bindings/display/panel/display-timings.yaml +++ b/Documentation/devicetree/bindings/display/panel/display-timings.yaml @@ -31,8 +31,7 @@ properties: patternProperties: "^timing": type: object - allOf: - - $ref: panel-timing.yaml# + $ref: panel-timing.yaml# additionalProperties: false diff --git a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml index a69681e724cb..566e11f6bfc0 100644 --- a/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml +++ b/Documentation/devicetree/bindings/display/panel/innolux,ee101ia-01d.yaml @@ -11,15 +11,26 @@ maintainers: - Thierry Reding <thierry.reding@gmail.com> allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: innolux,ee101ia-01d + + required: + - compatible properties: compatible: items: - const: innolux,ee101ia-01d - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds backlight: true + data-mapping: true enable-gpios: true power-supply: true width-mm: true @@ -27,5 +38,13 @@ properties: panel-timing: true port: true +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + additionalProperties: false ... diff --git a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml index 3715882b63b6..3f6efbb942da 100644 --- a/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml +++ b/Documentation/devicetree/bindings/display/panel/leadtek,ltk050h3146w.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: Leadtek LTK050H3146W 5.0in 720x1280 DSI panel maintainers: - - Heiko Stuebner <heiko.stuebner@theobroma-systems.com> + - Quentin Schulz <quentin.schulz@theobroma-systems.com> allOf: - $ref: panel-common.yaml# diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml index b5e7ee230fa6..5cf3c588f46d 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa104xd12.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding <thierry.reding@gmail.com> allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: mitsubishi,aa104xd12 + + required: + - compatible properties: compatible: items: - const: mitsubishi,aa104xd12 - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds vcc-supply: description: Reference to the regulator powering the panel VCC pins. @@ -39,6 +49,11 @@ additionalProperties: false required: - compatible - vcc-supply + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml index 977c50a85b67..54750cc5440d 100644 --- a/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml +++ b/Documentation/devicetree/bindings/display/panel/mitsubishi,aa121td01.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding <thierry.reding@gmail.com> allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: mitsubishi,aa121td01 + + required: + - compatible properties: compatible: items: - const: mitsubishi,aa121td01 - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds vcc-supply: description: Reference to the regulator powering the panel VCC pins. @@ -39,6 +49,11 @@ additionalProperties: false required: - compatible - vcc-supply + - data-mapping + - width-mm + - height-mm + - panel-timing + - port examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml new file mode 100644 index 000000000000..fcc50db6a812 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-lvds.yaml @@ -0,0 +1,57 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-lvds.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic LVDS Display Panel Device Tree Bindings + +maintainers: + - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> + - Thierry Reding <thierry.reding@gmail.com> + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: panel-lvds + + not: + properties: + compatible: + contains: + enum: + - advantech,idk-1110wr + - advantech,idk-2121wr + - innolux,ee101ia-01d + - mitsubishi,aa104xd12 + - mitsubishi,aa121td01 + - sgd,gktw70sdae4se + + required: + - compatible + +properties: + compatible: + items: + - enum: + - auo,b101ew05 + - tbs,a711-panel + + - const: panel-lvds + +unevaluatedProperties: false + +required: + - compatible + - data-mapping + - width-mm + - height-mm + - panel-timing + - port + +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml new file mode 100644 index 000000000000..f29789994b18 --- /dev/null +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/panel/panel-mipi-dbi-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MIPI DBI SPI Panel + +maintainers: + - Noralf Trønnes <noralf@tronnes.org> + +description: | + This binding is for display panels using a MIPI DBI compatible controller + in SPI mode. + + The MIPI Alliance Standard for Display Bus Interface defines the electrical + and logical interfaces for display controllers historically used in mobile + phones. The standard defines 4 display architecture types and this binding is + for type 1 which has full frame memory. There are 3 interface types in the + standard and type C is the serial interface. + + The standard defines the following interface signals for type C: + - Power: + - Vdd: Power supply for display module + - Vddi: Logic level supply for interface signals + Combined into one in this binding called: power-supply + - Interface: + - CSx: Chip select + - SCL: Serial clock + - Dout: Serial out + - Din: Serial in + - SDA: Bidrectional in/out + - D/CX: Data/command selection, high=data, low=command + Called dc-gpios in this binding. + - RESX: Reset when low + Called reset-gpios in this binding. + + The type C interface has 3 options: + + - Option 1: 9-bit mode and D/CX as the 9th bit + | Command | the next command or following data | + |<0><D7><D6><D5><D4><D3><D2><D1><D0>|<D/CX><D7><D6><D5><D4><D3><D2><D1><D0>| + + - Option 2: 16-bit mode and D/CX as a 9th bit + | Command or data | + |<X><X><X><X><X><X><X><D/CX><D7><D6><D5><D4><D3><D2><D1><D0>| + + - Option 3: 8-bit mode and D/CX as a separate interface line + | Command or data | + |<D7><D6><D5><D4><D3><D2><D1><D0>| + + The panel resolution is specified using the panel-timing node properties + hactive (width) and vactive (height). The other mandatory panel-timing + properties should be set to zero except clock-frequency which can be + optionally set to inform about the actual pixel clock frequency. + + If the panel is wired to the controller at an offset specify this using + hback-porch (x-offset) and vback-porch (y-offset). + +allOf: + - $ref: panel-common.yaml# + - $ref: /schemas/spi/spi-peripheral-props.yaml# + +properties: + compatible: + items: + - enum: + - sainsmart18 + - const: panel-mipi-dbi-spi + + write-only: + type: boolean + description: + Controller is not readable (ie. Din (MISO on the SPI interface) is not + wired up). + + dc-gpios: + maxItems: 1 + description: | + Controller data/command selection (D/CX) in 4-line SPI mode. + If not set, the controller is in 3-line SPI mode. + +required: + - compatible + - reg + - panel-timing + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + display@0{ + compatible = "sainsmart18", "panel-mipi-dbi-spi"; + reg = <0>; + spi-max-frequency = <40000000>; + + dc-gpios = <&gpio 24 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 25 GPIO_ACTIVE_HIGH>; + write-only; + + backlight = <&backlight>; + + width-mm = <35>; + height-mm = <28>; + + panel-timing { + hactive = <160>; + vactive = <128>; + hback-porch = <0>; + vback-porch = <0>; + clock-frequency = <0>; + hfront-porch = <0>; + hsync-len = <0>; + vfront-porch = <0>; + vsync-len = <0>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml index 62f5f050c1bc..1eb9dd4f8f58 100644 --- a/Documentation/devicetree/bindings/display/panel/panel-simple.yaml +++ b/Documentation/devicetree/bindings/display/panel/panel-simple.yaml @@ -222,6 +222,8 @@ properties: - logictechno,lttd800480070-l6wh-rt # Mitsubishi "AA070MC01 7.0" WVGA TFT LCD panel - mitsubishi,aa070mc01-ca1 + # Multi-Inno Technology Co.,Ltd MI0700S4T-6 7" 800x480 TFT Resistive Touch Module + - multi-inno,mi0700s4t-6 # Multi-Inno Technology Co.,Ltd MI1010AIT-1CP 10.1" 1280x800 LVDS IPS Cap Touch Mod. - multi-inno,mi1010ait-1cp # NEC LCD Technologies, Ltd. 12.1" WXGA (1280x800) LVDS TFT LCD panel @@ -282,6 +284,8 @@ properties: - sharp,lq101k1ly04 # Sharp 12.3" (2400x1600 pixels) TFT LCD panel - sharp,lq123p1jx31 + # Sharp 14" (1920x1080 pixels) TFT LCD panel + - sharp,lq140m1jw46 # Sharp LS020B1DD01D 2.0" HQVGA TFT LCD panel - sharp,ls020b1dd01d # Shelly SCA07010-BFN-LNN 7.0" WVGA TFT LCD panel diff --git a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml index e63a570ae59d..44e02decdf3a 100644 --- a/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml +++ b/Documentation/devicetree/bindings/display/panel/sgd,gktw70sdae4se.yaml @@ -11,13 +11,23 @@ maintainers: - Thierry Reding <thierry.reding@gmail.com> allOf: - - $ref: lvds.yaml# + - $ref: panel-common.yaml# + - $ref: /schemas/display/lvds.yaml/# + +select: + properties: + compatible: + contains: + const: sgd,gktw70sdae4se + + required: + - compatible properties: compatible: items: - const: sgd,gktw70sdae4se - - {} # panel-lvds, but not listed here to avoid false select + - const: panel-lvds data-mapping: const: jeida-18 @@ -35,6 +45,11 @@ additionalProperties: false required: - compatible + - port + - data-mapping + - width-mm + - height-mm + - panel-timing examples: - |+ diff --git a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml index 78d060097052..059cc6dbcfca 100644 --- a/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml +++ b/Documentation/devicetree/bindings/display/panel/sony,acx424akp.yaml @@ -4,7 +4,12 @@ $id: http://devicetree.org/schemas/display/panel/sony,acx424akp.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Sony ACX424AKP 4" 480x864 AMOLED panel +title: Sony ACX424AKP/ACX424AKM 4" 480x864/480x854 AMOLED panel + +description: The Sony ACX424AKP and ACX424AKM are panels built around + the Novatek NT35560 display controller. The only difference is that + the AKM is configured to use 10 pixels less in the Y axis than the + AKP. maintainers: - Linus Walleij <linus.walleij@linaro.org> @@ -14,7 +19,9 @@ allOf: properties: compatible: - const: sony,acx424akp + enum: + - sony,acx424akp + - sony,acx424akm reg: true reset-gpios: true vddi-supply: diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml b/Documentation/devicetree/bindings/display/renesas,du.yaml index 13efea574584..56cedcd6d576 100644 --- a/Documentation/devicetree/bindings/display/renesas,du.yaml +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml @@ -76,17 +76,21 @@ properties: renesas,cmms: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + maxItems: 1 description: A list of phandles to the CMM instances present in the SoC, one for each available DU channel. renesas,vsps: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + items: + - description: phandle to VSP instance that serves the DU channel + - description: Channel index identifying the LIF instance in that VSP description: A list of phandle and channel index tuples to the VSPs that handle the - memory interfaces for the DU channels. The phandle identifies the VSP - instance that serves the DU channel, and the channel index identifies - the LIF instance in that VSP. + memory interfaces for the DU channels. required: - compatible diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml index 7204da5eb4c5..a8d18a37cb23 100644 --- a/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip-drm.yaml @@ -21,6 +21,8 @@ properties: ports: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Should contain a list of phandles pointing to display interface port of vop devices. vop definitions as defined in diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml new file mode 100644 index 000000000000..f998a3a5b71f --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi-ddc.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-hdmi-ddc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI DDC + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + oneOf: + - const: samsung,exynos4210-hdmiddc + - const: samsung,exynos5-hdmiddc + deprecated: true + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + ddc@50 { + compatible = "samsung,exynos4210-hdmiddc"; + reg = <0x50>; + }; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml new file mode 100644 index 000000000000..cb8e735ce3bd --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-hdmi.yaml @@ -0,0 +1,227 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-hdmi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - samsung,exynos4210-hdmi + - samsung,exynos4212-hdmi + - samsung,exynos5420-hdmi + - samsung,exynos5433-hdmi + + clocks: + minItems: 5 + maxItems: 10 + + clock-names: + minItems: 5 + maxItems: 10 + + ddc: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the HDMI DDC node. + + hdmi-en-supply: + description: + Provides voltage source for DCC lines available on HDMI connector. When + there is no power provided for DDC epprom, some TV-sets do not pulls up + HPD (hot plug detect) line, what causes HDMI block to stay turned off. + When provided, the regulator allows TV-set correctly signal HPD event. + + hpd-gpios: + maxItems: 1 + description: + A GPIO line connected to HPD + + interrupts: + maxItems: 1 + + phy: + $ref: /schemas/types.yaml#/definitions/phandle + description: Phandle to the HDMI PHY node. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,syscon-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the PMU system controller node. + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + + '#sound-dai-cells': + const: 0 + + vdd-supply: + description: + VDD 1.0V HDMI TX. + + vdd_osc-supply: + description: + VDD 1.8V HDMI OSC. + + vdd_pll-supply: + description: + VDD 1.0V HDMI PLL. + +required: + - compatible + - clocks + - clock-names + - ddc + - hpd-gpios + - interrupts + - phy + - reg + - samsung,syscon-phandle + - '#sound-dai-cells' + - vdd-supply + - vdd_osc-supply + - vdd_pll-supply + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-hdmi + then: + properties: + clocks: + items: + - description: Gate of HDMI IP APB bus. + - description: Gate of HDMI-PHY IP APB bus. + - description: Gate of HDMI TMDS clock. + - description: Gate of HDMI pixel clock. + - description: TMDS clock generated by HDMI-PHY. + - description: MUX used to switch between oscclk and tmds_clko, + respectively if HDMI-PHY is off and operational. + - description: Pixel clock generated by HDMI-PHY. + - description: MUX used to switch between oscclk and pixel_clko, + respectively if HDMI-PHY is off and operational. + - description: Oscillator clock, used as parent of following *_user + clocks in case HDMI-PHY is not operational. + - description: Gate of HDMI SPDIF clock. + clock-names: + items: + - const: hdmi_pclk + - const: hdmi_i_pclk + - const: i_tmds_clk + - const: i_pixel_clk + - const: tmds_clko + - const: tmds_clko_user + - const: pixel_clko + - const: pixel_clko_user + - const: oscclk + - const: i_spdif_clk + required: + - samsung,sysreg-phandle + else: + properties: + clocks: + items: + - description: Gate of HDMI IP bus clock. + - description: Gate of HDMI special clock. + - description: Pixel special clock, one of the two possible inputs + of HDMI clock mux. + - description: HDMI PHY clock output, one of two possible inputs of + HDMI clock mux. + - description: It is required by the driver to switch between the 2 + parents i.e. sclk_pixel and sclk_hdmiphy. If hdmiphy is stable + after configuration, parent is set to sclk_hdmiphy else + sclk_pixel. + clock-names: + items: + - const: hdmi + - const: sclk_hdmi + - const: sclk_pixel + - const: sclk_hdmiphy + - const: mout_hdmi + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + hdmi@13970000 { + compatible = "samsung,exynos5433-hdmi"; + reg = <0x13970000 0x70000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cmu_disp CLK_PCLK_HDMI>, + <&cmu_disp CLK_PCLK_HDMIPHY>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO>, + <&cmu_disp CLK_PHYCLK_HDMI_PIXEL>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_TMDS_CLKO_PHY>, + <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_TMDS_CLKO_USER>, + <&cmu_disp CLK_PHYCLK_HDMIPHY_PIXEL_CLKO_PHY>, + <&cmu_disp CLK_MOUT_PHYCLK_HDMIPHY_PIXEL_CLKO_USER>, + <&xxti>, + <&cmu_disp CLK_SCLK_HDMI_SPDIF>; + clock-names = "hdmi_pclk", + "hdmi_i_pclk", + "i_tmds_clk", + "i_pixel_clk", + "tmds_clko", + "tmds_clko_user", + "pixel_clko", + "pixel_clko_user", + "oscclk", + "i_spdif_clk"; + phy = <&hdmiphy>; + ddc = <&hsi2c_11>; + samsung,syscon-phandle = <&pmu_system_controller>; + samsung,sysreg-phandle = <&syscon_disp>; + #sound-dai-cells = <0>; + + hpd-gpios = <&gpa3 0 GPIO_ACTIVE_HIGH>; + vdd-supply = <&ldo6_reg>; + vdd_osc-supply = <&ldo7_reg>; + vdd_pll-supply = <&ldo6_reg>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + hdmi_to_tv: endpoint { + remote-endpoint = <&tv_to_hdmi>; + }; + }; + + port@1 { + reg = <1>; + hdmi_to_mhl: endpoint { + remote-endpoint = <&mhl_to_hdmi>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml new file mode 100644 index 000000000000..ba40284ac66f --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos-mixer.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos-mixer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Mixer + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: + Samsung Exynos SoC Mixer is responsible for mixing and blending multiple data + inputs before passing it to an output device. The output is passed to HDMI. + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos4210-mixer + - samsung,exynos4212-mixer + - samsung,exynos5250-mixer + - samsung,exynos5420-mixer + - const: samsung,exynos5-mixer + deprecated: true + + clocks: + minItems: 3 + items: + - description: Gate of Mixer IP bus clock. + - description: Gate of HDMI IP bus clock, needed together with sclk_hdmi. + - description: HDMI Special clock, one of the two possible inputs of + mixer mux. + - description: Video Processor clock. + - description: Mixer mux clock. + - description: Mixer Special clock. + + clock-names: + minItems: 3 + items: + - const: mixer + - const: hdmi + - const: sclk_hdmi + - const: vp + - const: mout_mixer + - const: sclk_mixer + + interconnects: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + minItems: 1 + items: + - description: Mixer memory region. + - description: Video Processor memory region. + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-mixer + - samsung,exynos4212-mixer + then: + properties: + clocks: + minItems: 6 + maxItems: 6 + regs: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + const: samsung,exynos4212-mixer + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + regs: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5-mixer + - samsung,exynos5250-mixer + - samsung,exynos5420-mixer + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + regs: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5250.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + mixer@14450000 { + compatible = "samsung,exynos5250-mixer"; + reg = <0x14450000 0x10000>; + interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_MIXER>, + <&clock CLK_HDMI>, + <&clock CLK_SCLK_HDMI>; + clock-names = "mixer", + "hdmi", + "sclk_hdmi"; + iommus = <&sysmmu_tv>; + power-domains = <&pd_disp1>; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml new file mode 100644 index 000000000000..6f796835ea03 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-decon.yaml @@ -0,0 +1,148 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos5433-decon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 SoC Display and Enhancement Controller (DECON) + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + DECON (Display and Enhancement Controller) is the Display Controller for the + Exynos5433 series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +properties: + compatible: + enum: + - samsung,exynos5433-decon + - samsung,exynos5433-decon-tv + + clocks: + minItems: 11 + maxItems: 11 + + clock-names: + items: + - const: pclk + - const: aclk_decon + - const: aclk_smmu_decon0x + - const: aclk_xiu_decon0x + - const: pclk_smmu_decon0x + - const: aclk_smmu_decon1x + - const: aclk_xiu_decon1x + - const: pclk_smmu_decon1x + - const: sclk_decon_vclk + - const: sclk_decon_eclk + - const: dsd + + interrupts: + minItems: 3 + maxItems: 4 + description: | + Interrupts depend on mode of work: + - video mode: vsync + - command mode: lcd_sys + - command mode with software trigger: lcd_sys, te + + interrupt-names: + minItems: 3 + items: + - const: fifo + - const: vsync + - const: lcd_sys + - const: te + + iommus: + minItems: 2 + maxItems: 2 + + iommu-names: + items: + - const: m0 + - const: m1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,disp-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - ports + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + display-controller@13800000 { + compatible = "samsung,exynos5433-decon"; + reg = <0x13800000 0x2104>; + clocks = <&cmu_disp CLK_PCLK_DECON>, + <&cmu_disp CLK_ACLK_DECON>, + <&cmu_disp CLK_ACLK_SMMU_DECON0X>, + <&cmu_disp CLK_ACLK_XIU_DECON0X>, + <&cmu_disp CLK_PCLK_SMMU_DECON0X>, + <&cmu_disp CLK_ACLK_SMMU_DECON1X>, + <&cmu_disp CLK_ACLK_XIU_DECON1X>, + <&cmu_disp CLK_PCLK_SMMU_DECON1X>, + <&cmu_disp CLK_SCLK_DECON_VCLK>, + <&cmu_disp CLK_SCLK_DECON_ECLK>, + <&cmu_disp CLK_SCLK_DSD>; + clock-names = "pclk", + "aclk_decon", + "aclk_smmu_decon0x", + "aclk_xiu_decon0x", + "pclk_smmu_decon0x", + "aclk_smmu_decon1x", + "aclk_xiu_decon1x", + "pclk_smmu_decon1x", + "sclk_decon_vclk", + "sclk_decon_eclk", + "dsd"; + power-domains = <&pd_disp>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = <GIC_SPI 201 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 202 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 203 IRQ_TYPE_LEVEL_HIGH>; + samsung,disp-sysreg = <&syscon_disp>; + iommus = <&sysmmu_decon0x>, <&sysmmu_decon1x>; + iommu-names = "m0", "m1"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + decon_to_mic: endpoint { + remote-endpoint = <&mic_to_decon>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml new file mode 100644 index 000000000000..01fccb138ebd --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos5433-mic.yaml @@ -0,0 +1,95 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos5433-mic.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 SoC Mobile Image Compressor (MIC) + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + MIC (Mobile Image Compressor) resides between DECON and MIPI DSI. MIPI DSI is + not capable of transferring high resoltuion frame data as DECON can send. MIC + solves this problem by compressing the frame data by 1/2 before it is + transferred through MIPI DSI. The compressed frame data must be uncompressed + in the panel PCB. + +properties: + compatible: + const: samsung,exynos5433-mic + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: pclk_mic0 + - const: sclk_rgb_vclk_to_mic0 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + Contains a port which is connected to mic node. + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,disp-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface. + +required: + - compatible + - clocks + - clock-names + - ports + - reg + - samsung,disp-syscon + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + image-processor@13930000 { + compatible = "samsung,exynos5433-mic"; + reg = <0x13930000 0x48>; + clocks = <&cmu_disp CLK_PCLK_MIC0>, + <&cmu_disp CLK_SCLK_RGB_VCLK_TO_MIC0>; + clock-names = "pclk_mic0", + "sclk_rgb_vclk_to_mic0"; + power-domains = <&pd_disp>; + samsung,disp-syscon = <&syscon_disp>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + mic_to_decon: endpoint { + remote-endpoint = <&decon_to_mic>; + }; + }; + + port@1 { + reg = <1>; + mic_to_dsi: endpoint { + remote-endpoint = <&dsi_to_mic>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml new file mode 100644 index 000000000000..afa137d47922 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,exynos7-decon.yaml @@ -0,0 +1,120 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,exynos7-decon.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos7 SoC Display and Enhancement Controller (DECON) + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + DECON (Display and Enhancement Controller) is the Display Controller for the + Exynos7 series of SoCs which transfers the image data from a video memory + buffer to an external LCD interface. + +properties: + compatible: + const: samsung,exynos7-decon + + clocks: + minItems: 4 + maxItems: 4 + + clock-names: + items: + - const: pclk_decon0 + - const: aclk_decon0 + - const: decon0_eclk + - const: decon0_vclk + + display-timings: + $ref: ../panel/display-timings.yaml# + + i80-if-timings: + type: object + description: timing configuration for lcd i80 interface support + properties: + cs-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of address signal is enabled until + chip select is enabled. + default: 0 + + wr-active: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is enabled. + default: 1 + + wr-hold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is disabled until write + signal is disabled. + default: 0 + + wr-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS signal is enabled until + write signal is enabled. + default: 0 + + interrupts: + items: + - description: FIFO level + - description: VSYNC + - description: LCD system + + interrupt-names: + items: + - const: fifo + - const: vsync + - const: lcd_sys + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos7-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + display-controller@13930000 { + compatible = "samsung,exynos7-decon"; + reg = <0x13930000 0x1000>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = <GIC_SPI 190 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 189 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 188 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock_disp 100>, /* PCLK_DECON_INT */ + <&clock_disp 101>, /* ACLK_DECON_INT */ + <&clock_disp 102>, /* SCLK_DECON_INT_ECLK */ + <&clock_disp 103>; /* SCLK_DECON_INT_EXTCLKPLL */ + clock-names = "pclk_decon0", + "aclk_decon0", + "decon0_eclk", + "decon0_vclk"; + pinctrl-0 = <&lcd_clk &pwm1_out>; + pinctrl-names = "default"; + }; diff --git a/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml new file mode 100644 index 000000000000..9cf5f120d516 --- /dev/null +++ b/Documentation/devicetree/bindings/display/samsung/samsung,fimd.yaml @@ -0,0 +1,198 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/display/samsung/samsung,fimd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC Fully Interactive Mobile Display (FIMD) + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - samsung,s3c2443-fimd + - samsung,s3c6400-fimd + - samsung,s5pv210-fimd + - samsung,exynos3250-fimd + - samsung,exynos4210-fimd + - samsung,exynos5250-fimd + - samsung,exynos5420-fimd + + '#address-cells': + const: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: sclk_fimd + - const: fimd + + display-timings: + $ref: ../panel/display-timings.yaml# + + i80-if-timings: + type: object + description: | + Timing configuration for lcd i80 interface support. + The parameters are defined as:: + VCLK(internal) __|??????|_____|??????|_____|??????|_____|??????|_____|?? + : : : : : + Address Output --:<XXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XXXXXXXXXXXX:XX + | cs-setup+1 | : : : + |<---------->| : : : + Chip Select ???????????????|____________:____________:____________|?? + | wr-setup+1 | | wr-hold+1 | + |<---------->| |<---------->| + Write Enable ????????????????????????????|____________|??????????????? + | wr-active+1| + |<---------->| + Video Data ----------------------------<XXXXXXXXXXXXXXXXXXXXXXXXX>-- + + properties: + cs-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of address signal is enabled until + chip select is enabled. + default: 0 + + wr-active: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is enabled. + default: 1 + + wr-hold: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS is disabled until write + signal is disabled. + default: 0 + + wr-setup: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Clock cycles for the active period of CS signal is enabled until + write signal is enabled. + default: 0 + + iommus: + minItems: 1 + maxItems: 2 + + iommu-names: + items: + - const: m0 + - const: m1 + + interrupts: + items: + - description: FIFO level + - description: VSYNC + - description: LCD system + + interrupt-names: + items: + - const: fifo + - const: vsync + - const: lcd_sys + + power-domains: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,invert-vden: + type: boolean + description: + Video enable signal is inverted. + + samsung,invert-vclk: + type: boolean + description: + Video clock signal is inverted. + + samsung,sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to System Register syscon. + + '#size-cells': + const: 0 + +patternProperties: + "^port@[0-4]+$": + $ref: /schemas/graph.yaml#/properties/port + description: | + Contains ports with port with index:: + 0 - for CAMIF0 input, + 1 - for CAMIF1 input, + 2 - for CAMIF2 input, + 3 - for parallel output, + 4 - for write-back interface + +required: + - compatible + - clocks + - clock-names + - interrupts + - interrupt-names + - reg + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5420-fimd + then: + properties: + iommus: + minItems: 2 + maxItems: 2 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + + fimd@11c00000 { + compatible = "samsung,exynos4210-fimd"; + interrupt-parent = <&combiner>; + reg = <0x11c00000 0x20000>; + interrupt-names = "fifo", "vsync", "lcd_sys"; + interrupts = <11 0>, <11 1>, <11 2>; + clocks = <&clock CLK_SCLK_FIMD0>, <&clock CLK_FIMD0>; + clock-names = "sclk_fimd", "fimd"; + power-domains = <&pd_lcd0>; + iommus = <&sysmmu_fimd0>; + samsung,sysreg = <&sys_reg>; + + #address-cells = <1>; + #size-cells = <0>; + + samsung,invert-vden; + samsung,invert-vclk; + + pinctrl-0 = <&lcd_clk>, <&lcd_data24>; + pinctrl-names = "default"; + + port@3 { + reg = <3>; + + fimd_dpi_ep: endpoint { + remote-endpoint = <&lcd_ep>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml index 44a29d813f14..27ba4323d221 100644 --- a/Documentation/devicetree/bindings/display/simple-framebuffer.yaml +++ b/Documentation/devicetree/bindings/display/simple-framebuffer.yaml @@ -52,11 +52,13 @@ description: |+ properties: compatible: - items: - - enum: - - apple,simple-framebuffer - - allwinner,simple-framebuffer - - amlogic,simple-framebuffer + oneOf: + - items: + - enum: + - apple,simple-framebuffer + - allwinner,simple-framebuffer + - amlogic,simple-framebuffer + - const: simple-framebuffer - const: simple-framebuffer reg: diff --git a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml index 2ed2a7d0ca2f..9baafd0c42dd 100644 --- a/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml +++ b/Documentation/devicetree/bindings/display/solomon,ssd1307fb.yaml @@ -8,6 +8,7 @@ title: Solomon SSD1307 OLED Controller Framebuffer maintainers: - Maxime Ripard <mripard@kernel.org> + - Javier Martinez Canillas <javierm@redhat.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml index 3d107e9434be..d0a5592bd89d 100644 --- a/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml +++ b/Documentation/devicetree/bindings/display/sprd/sprd,display-subsystem.yaml @@ -45,6 +45,8 @@ properties: ports: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Should contain a list of phandles pointing to display interface port of DPU devices. diff --git a/Documentation/devicetree/bindings/display/ste,mcde.yaml b/Documentation/devicetree/bindings/display/ste,mcde.yaml index de0c678b3c29..564ea845c82e 100644 --- a/Documentation/devicetree/bindings/display/ste,mcde.yaml +++ b/Documentation/devicetree/bindings/display/ste,mcde.yaml @@ -58,8 +58,8 @@ patternProperties: "^dsi@[0-9a-f]+$": description: subnodes for the three DSI host adapters type: object - allOf: - - $ref: dsi-controller.yaml# + $ref: dsi-controller.yaml# + properties: compatible: const: ste,mcde-dsi diff --git a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml index 781c1868b0b8..5c7d2cbc4aac 100644 --- a/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml +++ b/Documentation/devicetree/bindings/display/ti/ti,am65x-dss.yaml @@ -88,8 +88,7 @@ properties: The DSS DPI output port node from video port 2 ti,am65x-oldi-io-ctrl: - $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + $ref: "/schemas/types.yaml#/definitions/phandle" description: phandle to syscon device node mapping OLDI IO_CTRL registers. The mapped range should point to OLDI_DAT0_IO_CTRL, map it and diff --git a/Documentation/devicetree/bindings/dma/dma-router.yaml b/Documentation/devicetree/bindings/dma/dma-router.yaml index e72748496fd9..4b817f5dc30e 100644 --- a/Documentation/devicetree/bindings/dma/dma-router.yaml +++ b/Documentation/devicetree/bindings/dma/dma-router.yaml @@ -24,6 +24,8 @@ properties: dma-masters: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Array of phandles to the DMA controllers the router can direct the signal to. diff --git a/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml new file mode 100644 index 000000000000..54d68fc688b5 --- /dev/null +++ b/Documentation/devicetree/bindings/dma/mediatek,uart-dma.yaml @@ -0,0 +1,122 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/mediatek,uart-dma.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek UART APDMA controller + +maintainers: + - Long Cheng <long.cheng@mediatek.com> + +description: | + The MediaTek UART APDMA controller provides DMA capabilities + for the UART peripheral bus. + +allOf: + - $ref: "dma-controller.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2712-uart-dma + - mediatek,mt8516-uart-dma + - const: mediatek,mt6577-uart-dma + - enum: + - mediatek,mt6577-uart-dma + + reg: + minItems: 1 + maxItems: 16 + + interrupts: + description: | + TX, RX interrupt lines for each UART APDMA channel + minItems: 1 + maxItems: 16 + + clocks: + description: Must contain one entry for the APDMA main clock + maxItems: 1 + + clock-names: + const: apdma + + "#dma-cells": + const: 1 + description: | + The first cell specifies the UART APDMA channel number + + dma-requests: + description: | + Number of virtual channels of the UART APDMA controller + maximum: 16 + + mediatek,dma-33bits: + type: boolean + description: Enable 33-bits UART APDMA support + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +if: + not: + required: + - dma-requests +then: + properties: + interrupts: + maxItems: 8 + reg: + maxItems: 8 + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt2712-clk.h> + soc { + #address-cells = <2>; + #size-cells = <2>; + + apdma: dma-controller@11000400 { + compatible = "mediatek,mt2712-uart-dma", + "mediatek,mt6577-uart-dma"; + reg = <0 0x11000400 0 0x80>, + <0 0x11000480 0 0x80>, + <0 0x11000500 0 0x80>, + <0 0x11000580 0 0x80>, + <0 0x11000600 0 0x80>, + <0 0x11000680 0 0x80>, + <0 0x11000700 0 0x80>, + <0 0x11000780 0 0x80>, + <0 0x11000800 0 0x80>, + <0 0x11000880 0 0x80>, + <0 0x11000900 0 0x80>, + <0 0x11000980 0 0x80>; + interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 105 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 107 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 109 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 112 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>, + <GIC_SPI 114 IRQ_TYPE_LEVEL_LOW>; + dma-requests = <12>; + clocks = <&pericfg CLK_PERI_AP_DMA>; + clock-names = "apdma"; + mediatek,dma-33bits; + #dma-cells = <1>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt b/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt deleted file mode 100644 index fef9c1eeb264..000000000000 --- a/Documentation/devicetree/bindings/dma/mtk-uart-apdma.txt +++ /dev/null @@ -1,56 +0,0 @@ -* Mediatek UART APDMA Controller - -Required properties: -- compatible should contain: - * "mediatek,mt2712-uart-dma" for MT2712 compatible APDMA - * "mediatek,mt6577-uart-dma" for MT6577 and all of the above - * "mediatek,mt8516-uart-dma", "mediatek,mt6577" for MT8516 SoC - -- reg: The base address of the APDMA register bank. - -- interrupts: A single interrupt specifier. - One interrupt per dma-requests, or 8 if no dma-requests property is present - -- dma-requests: The number of DMA channels - -- clocks : Must contain an entry for each entry in clock-names. - See ../clocks/clock-bindings.txt for details. -- clock-names: The APDMA clock for register accesses - -- mediatek,dma-33bits: Present if the DMA requires support - -Examples: - - apdma: dma-controller@11000400 { - compatible = "mediatek,mt2712-uart-dma", - "mediatek,mt6577-uart-dma"; - reg = <0 0x11000400 0 0x80>, - <0 0x11000480 0 0x80>, - <0 0x11000500 0 0x80>, - <0 0x11000580 0 0x80>, - <0 0x11000600 0 0x80>, - <0 0x11000680 0 0x80>, - <0 0x11000700 0 0x80>, - <0 0x11000780 0 0x80>, - <0 0x11000800 0 0x80>, - <0 0x11000880 0 0x80>, - <0 0x11000900 0 0x80>, - <0 0x11000980 0 0x80>; - interrupts = <GIC_SPI 103 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 105 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 106 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 107 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 108 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 109 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 111 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 112 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 113 IRQ_TYPE_LEVEL_LOW>, - <GIC_SPI 114 IRQ_TYPE_LEVEL_LOW>; - dma-requests = <12>; - clocks = <&pericfg CLK_PERI_AP_DMA>; - clock-names = "apdma"; - mediatek,dma-33bits; - #dma-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml index 5c2e2f156e31..fef804565b88 100644 --- a/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml +++ b/Documentation/devicetree/bindings/dma/nvidia,tegra210-adma.yaml @@ -23,7 +23,9 @@ properties: - nvidia,tegra210-adma - nvidia,tegra186-adma - items: - - const: nvidia,tegra194-adma + - enum: + - nvidia,tegra234-adma + - nvidia,tegra194-adma - const: nvidia,tegra186-adma reg: diff --git a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml index 7a4f415d74dc..1e25c5b0fb4d 100644 --- a/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml +++ b/Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L DMA Controller +title: Renesas RZ/{G2L,G2UL,V2L} DMA Controller maintainers: - Biju Das <biju.das.jz@bp.renesas.com> @@ -16,7 +16,9 @@ properties: compatible: items: - enum: + - renesas,r9a07g043-dmac # RZ/G2UL - renesas,r9a07g044-dmac # RZ/G2{L,LC} + - renesas,r9a07g054-dmac # RZ/V2L - const: renesas,rz-dmac reg: diff --git a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml index 75ad898c59bc..47c46af25536 100644 --- a/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml +++ b/Documentation/devicetree/bindings/dma/sifive,fu540-c000-pdma.yaml @@ -22,6 +22,9 @@ description: | https://static.dev.sifive.com/FU540-C000-v1.0.pdf +allOf: + - $ref: "dma-controller.yaml#" + properties: compatible: items: @@ -41,13 +44,12 @@ required: - compatible - reg - interrupts - - '#dma-cells' -additionalProperties: false +unevaluatedProperties: false examples: - | - dma@3000000 { + dma-controller@3000000 { compatible = "sifive,fu540-c000-pdma"; reg = <0x3000000 0x8000>; interrupts = <23>, <24>, <25>, <26>, <27>, <28>, <29>, <30>; diff --git a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml index f751796531c9..7b1833d6caa2 100644 --- a/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml +++ b/Documentation/devicetree/bindings/dma/st,stm32-dmamux.yaml @@ -46,7 +46,7 @@ examples: #dma-cells = <3>; dma-requests = <128>; dma-channels = <16>; - dma-masters = <&dma1 &dma2>; + dma-masters = <&dma1>, <&dma2>; clocks = <&timer_clk>; }; diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml new file mode 100644 index 000000000000..c0a1408b12ec --- /dev/null +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/dma/xilinx/xlnx,zynqmp-dma-1.0.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Xilinx ZynqMP DMA Engine + +description: | + The Xilinx ZynqMP DMA engine supports memory to memory transfers, + memory to device and device to memory transfers. It also has flow + control and rate control support for slave/peripheral dma access. + +maintainers: + - Michael Tretter <m.tretter@pengutronix.de> + +allOf: + - $ref: "../dma-controller.yaml#" + +properties: + "#dma-cells": + const: 1 + + compatible: + const: xlnx,zynqmp-dma-1.0 + + reg: + description: memory map for gdma/adma module access + maxItems: 1 + + interrupts: + description: DMA channel interrupt + maxItems: 1 + + clocks: + description: input clocks + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: clk_main + - const: clk_apb + + xlnx,bus-width: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: + - 64 + - 128 + description: AXI bus width in bits + + iommus: + maxItems: 1 + + power-domains: + maxItems: 1 + + dma-coherent: + description: present if dma operations are coherent + +required: + - "#dma-cells" + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + + fpd_dma_chan1: dma-controller@fd500000 { + compatible = "xlnx,zynqmp-dma-1.0"; + reg = <0xfd500000 0x1000>; + interrupt-parent = <&gic>; + interrupts = <0 117 0x4>; + #dma-cells = <1>; + clock-names = "clk_main", "clk_apb"; + clocks = <&zynqmp_clk GDMA_REF>, <&zynqmp_clk LPD_LSBUS>; + xlnx,bus-width = <128>; + dma-coherent; + }; diff --git a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt b/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt deleted file mode 100644 index 07a5a7aa9ea0..000000000000 --- a/Documentation/devicetree/bindings/dma/xilinx/zynqmp_dma.txt +++ /dev/null @@ -1,26 +0,0 @@ -Xilinx ZynqMP DMA engine, it does support memory to memory transfers, -memory to device and device to memory transfers. It also has flow -control and rate control support for slave/peripheral dma access. - -Required properties: -- compatible : Should be "xlnx,zynqmp-dma-1.0" -- reg : Memory map for gdma/adma module access. -- interrupts : Should contain DMA channel interrupt. -- xlnx,bus-width : Axi buswidth in bits. Should contain 128 or 64 -- clock-names : List of input clocks "clk_main", "clk_apb" - (see clock bindings for details) - -Optional properties: -- dma-coherent : Present if dma operations are coherent. - -Example: -++++++++ -fpd_dma_chan1: dma@fd500000 { - compatible = "xlnx,zynqmp-dma-1.0"; - reg = <0x0 0xFD500000 0x1000>; - interrupt-parent = <&gic>; - interrupts = <0 117 4>; - clock-names = "clk_main", "clk_apb"; - xlnx,bus-width = <128>; - dma-coherent; -}; diff --git a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml index c8b91207f34d..1dcb85a02a76 100644 --- a/Documentation/devicetree/bindings/dvfs/performance-domain.yaml +++ b/Documentation/devicetree/bindings/dvfs/performance-domain.yaml @@ -43,7 +43,6 @@ properties: performance-domains: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 description: A phandle and performance domain specifier as defined by bindings of the performance controller/provider specified by phandle. @@ -52,10 +51,16 @@ additionalProperties: true examples: - | - performance: performance-controller@12340000 { - compatible = "qcom,cpufreq-hw"; - reg = <0x12340000 0x1000>; - #performance-domain-cells = <1>; + soc { + #address-cells = <2>; + #size-cells = <2>; + + performance: performance-controller@11bc00 { + compatible = "mediatek,cpufreq-hw"; + reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>; + + #performance-domain-cells = <1>; + }; }; // The node above defines a performance controller that is a performance diff --git a/Documentation/devicetree/bindings/example-schema.yaml b/Documentation/devicetree/bindings/example-schema.yaml index c078796ae1b5..80a28781845d 100644 --- a/Documentation/devicetree/bindings/example-schema.yaml +++ b/Documentation/devicetree/bindings/example-schema.yaml @@ -162,6 +162,16 @@ properties: don't need a type. enum: [ 100, 200, 300 ] + vendor,int-array-variable-length-and-constrained-values: + description: Array might define what type of elements might be used (e.g. + their range). + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 3 + items: + minimum: 0 + maximum: 8 + child-node: description: Child nodes are just another property from a json-schema perspective. @@ -207,6 +217,10 @@ allOf: then: required: - foo-supply + else: + # If otherwise the property is not allowed: + properties: + foo-supply: false # Altering schema depending on presence of properties is usually done by # dependencies (see above), however some adjustments might require if: - if: diff --git a/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml new file mode 100644 index 000000000000..f9ffe3d6f957 --- /dev/null +++ b/Documentation/devicetree/bindings/extcon/maxim,max77843.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/extcon/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC Extcon + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77843-muic + + connector: + $ref: /schemas/connector/usb-connector.yaml# + + ports: + $ref: /schemas/graph.yaml#/properties/port + description: + Any connector to the data bus of this controller should be modelled using + the OF graph bindings specified + properties: + port: + $ref: /schemas/graph.yaml#/properties/port + +required: + - compatible + - connector + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml index 5c4c6782e052..948e2a38beed 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scmi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scmi.yaml @@ -38,6 +38,9 @@ properties: The virtio transport only supports a single device. items: - const: arm,scmi-virtio + - description: SCMI compliant firmware with OP-TEE transport + items: + - const: linaro,scmi-optee interrupts: description: @@ -78,11 +81,24 @@ properties: '#size-cells': const: 0 + atomic-threshold-us: + description: + An optional time value, expressed in microseconds, representing, on this + platform, the threshold above which any SCMI command, advertised to have + an higher-than-threshold execution latency, should not be considered for + atomic mode of operation, even if requested. + default: 0 + arm,smc-id: $ref: /schemas/types.yaml#/definitions/uint32 description: SMC id required when using smc or hvc transports + linaro,optee-channel-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Channel specifier required when using OP-TEE transport. + protocol@11: type: object properties: @@ -195,6 +211,12 @@ patternProperties: minItems: 1 maxItems: 2 + linaro,optee-channel-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Channel specifier required when using OP-TEE transport and + protocol has a dedicated communication channel. + required: - reg @@ -226,6 +248,16 @@ else: - arm,smc-id - shmem + else: + if: + properties: + compatible: + contains: + const: linaro,scmi-optee + then: + required: + - linaro,optee-channel-id + examples: - | firmware { @@ -240,6 +272,8 @@ examples: #address-cells = <1>; #size-cells = <0>; + atomic-threshold-us = <10000>; + scmi_devpd: protocol@11 { reg = <0x11>; #power-domain-cells = <1>; @@ -330,7 +364,7 @@ examples: firmware { scmi { compatible = "arm,scmi-smc"; - shmem = <&cpu_scp_lpri0 &cpu_scp_lpri1>; + shmem = <&cpu_scp_lpri0>, <&cpu_scp_lpri1>; arm,smc-id = <0xc3000001>; #address-cells = <1>; @@ -340,7 +374,48 @@ examples: reg = <0x11>; #power-domain-cells = <1>; }; + }; + }; + + - | + firmware { + scmi { + compatible = "linaro,scmi-optee"; + linaro,optee-channel-id = <0>; + #address-cells = <1>; + #size-cells = <0>; + + scmi_dvfs1: protocol@13 { + reg = <0x13>; + linaro,optee-channel-id = <1>; + shmem = <&cpu_optee_lpri0>; + #clock-cells = <1>; + }; + + scmi_clk0: protocol@14 { + reg = <0x14>; + #clock-cells = <1>; + }; + }; + }; + + soc { + #address-cells = <2>; + #size-cells = <2>; + + sram@51000000 { + compatible = "mmio-sram"; + reg = <0x0 0x51000000 0x0 0x10000>; + + #address-cells = <1>; + #size-cells = <1>; + ranges = <0 0x0 0x51000000 0x10000>; + + cpu_optee_lpri0: optee-sram-section@0 { + compatible = "arm,scmi-shmem"; + reg = <0x0 0x80>; + }; }; }; diff --git a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml index 23b346bd1252..1f9322925e7c 100644 --- a/Documentation/devicetree/bindings/firmware/arm,scpi.yaml +++ b/Documentation/devicetree/bindings/firmware/arm,scpi.yaml @@ -43,6 +43,7 @@ properties: by remote SCP firmware for use by SCPI message protocol should be specified in any order. minItems: 1 + maxItems: 4 shmem: description: @@ -51,6 +52,7 @@ properties: be any memory reserved for the purpose of this communication between the processors. minItems: 1 + maxItems: 4 power-controller: type: object @@ -235,8 +237,8 @@ examples: firmware { scpi { compatible = "amlogic,meson-gxbb-scpi", "arm,scpi-pre-1.0"; - mboxes = <&mailbox 1 &mailbox 2>; - shmem = <&cpu_scp_lpri &cpu_scp_hpri>; + mboxes = <&mailbox 1>, <&mailbox 2>; + shmem = <&cpu_scp_lpri>, <&cpu_scp_hpri>; scpi_sensors1: sensors { compatible = "amlogic,meson-gxbb-scpi-sensors", "arm,scpi-sensors"; diff --git a/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml new file mode 100644 index 000000000000..fcf0011b8e6d --- /dev/null +++ b/Documentation/devicetree/bindings/firmware/qemu,fw-cfg-mmio.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/firmware/qemu,fw-cfg-mmio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: QEMU Firmware Configuration bindings + +maintainers: + - Rob Herring <robh@kernel.org> + +description: | + Various QEMU emulation / virtualization targets provide the following + Firmware Configuration interface on the "virt" machine type: + + - A write-only, 16-bit wide selector (or control) register, + - a read-write, 64-bit wide data register. + + QEMU exposes the control and data register to guests as memory mapped + registers; their location is communicated to the guest's UEFI firmware in the + DTB that QEMU places at the bottom of the guest's DRAM. + + The authoritative guest-side hardware interface documentation to the fw_cfg + device can be found in "docs/specs/fw_cfg.txt" in the QEMU source tree. + + +properties: + compatible: + const: qemu,fw-cfg-mmio + + reg: + maxItems: 1 + description: | + * Bytes 0x0 to 0x7 cover the data register. + * Bytes 0x8 to 0x9 cover the selector register. + * Further registers may be appended to the region in case of future interface + revisions / feature bits. + + dma-coherent: true + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + fw-cfg@9020000 { + compatible = "qemu,fw-cfg-mmio"; + reg = <0x9020000 0xa>; + }; +... diff --git a/Documentation/devicetree/bindings/gnss/gnss-common.yaml b/Documentation/devicetree/bindings/gnss/gnss-common.yaml new file mode 100644 index 000000000000..963b926e30a7 --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/gnss-common.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/gnss-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common Properties for Global Navigation Satellite Systems (GNSS) + receiver devices + +maintainers: + - Johan Hovold <johan@kernel.org> + +description: | + This document defines device tree properties common to Global Navigation + Satellite System receivers. + +properties: + $nodename: + pattern: "^gnss(@.*)?$" + + lna-supply: + description: A separate regulator supplying power for the Low Noise + Amplifier (LNA). This is an amplifier connected between the GNSS + device and the receiver antenna. + + enable-gpios: + description: A GPIO line that will enable the GNSS receiver when + asserted. If this line is active low, the GPIO phandle should + consequently be tagged with the GPIO_ACTIVE_LOW flag so the operating + system can rely on asserting the line to enable the GNSS device. + maxItems: 1 + + timepulse-gpios: + description: When a timepulse is provided to the GNSS device using a + GPIO line, this is used. + maxItems: 1 + + current-speed: + description: The baudrate in bits per second of the device as it comes + online, current active speed. + $ref: /schemas/types.yaml#/definitions/uint32 + +additionalProperties: true + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + serial { + gnss { + compatible = "u-blox,neo-8"; + vcc-supply = <&gnss_reg>; + timepulse-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + current-speed = <4800>; + }; + }; diff --git a/Documentation/devicetree/bindings/gnss/gnss.txt b/Documentation/devicetree/bindings/gnss/gnss.txt deleted file mode 100644 index d6dc9c0d8249..000000000000 --- a/Documentation/devicetree/bindings/gnss/gnss.txt +++ /dev/null @@ -1,37 +0,0 @@ -GNSS Receiver DT binding - -This documents the binding structure and common properties for GNSS receiver -devices. - -A GNSS receiver node is a node named "gnss" and typically resides on a serial -bus (e.g. UART, I2C or SPI). - -Please refer to the following documents for generic properties: - - Documentation/devicetree/bindings/serial/serial.yaml - Documentation/devicetree/bindings/spi/spi-bus.txt - -Required properties: - -- compatible : A string reflecting the vendor and specific device the node - represents - -Optional properties: -- lna-supply : Separate supply for an LNA -- enable-gpios : GPIO used to enable the device -- timepulse-gpios : Time pulse GPIO - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "u-blox,neo-8"; - - vcc-supply = <&gnss_reg>; - timepulse-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; - - current-speed = <4800>; - }; -}; diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.txt b/Documentation/devicetree/bindings/gnss/sirfstar.txt deleted file mode 100644 index f4252b6b660b..000000000000 --- a/Documentation/devicetree/bindings/gnss/sirfstar.txt +++ /dev/null @@ -1,46 +0,0 @@ -SiRFstar-based GNSS Receiver DT binding - -SiRFstar chipsets are used in GNSS-receiver modules produced by several -vendors and can use UART, SPI or I2C interfaces. - -Please see Documentation/devicetree/bindings/gnss/gnss.txt for generic -properties. - -Required properties: - -- compatible : Must be one of - - "fastrax,uc430" - "linx,r4" - "wi2wi,w2sg0004" - "wi2wi,w2sg0008i" - "wi2wi,w2sg0084i" - -- vcc-supply : Main voltage regulator (pin name: 3V3_IN, VCC, VDD) - -Required properties (I2C): -- reg : I2C slave address - -Required properties (SPI): -- reg : SPI chip select address - -Optional properties: - -- sirf,onoff-gpios : GPIO used to power on and off device (pin name: ON_OFF) -- sirf,wakeup-gpios : GPIO used to determine device power state - (pin name: RFPWRUP, WAKEUP) -- timepulse-gpios : Time pulse GPIO (pin name: 1PPS, TM) - -Example: - -serial@1234 { - compatible = "ns16550a"; - - gnss { - compatible = "wi2wi,w2sg0084i"; - - vcc-supply = <&gnss_reg>; - sirf,onoff-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; - sirf,wakeup-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>; - }; -}; diff --git a/Documentation/devicetree/bindings/gnss/sirfstar.yaml b/Documentation/devicetree/bindings/gnss/sirfstar.yaml new file mode 100644 index 000000000000..991599cdaa6b --- /dev/null +++ b/Documentation/devicetree/bindings/gnss/sirfstar.yaml @@ -0,0 +1,76 @@ +# SPDX-License-Identifier: GPL-2.0 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gnss/sirfstar.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SiRFstar GNSS Receiver Device Tree Bindings + +maintainers: + - Johan Hovold <johan@kernel.org> + +description: + The SiRFstar GNSS receivers have incarnated over the years in different + chips, starting from the SiRFstarIII which was a chip that was introduced in + 2004 and used in a lot of dedicated GPS devices. In 2009 SiRF was acquired + by CSR (Cambridge Silicon Radio) and in 2012 the CSR GPS business was + acquired by Samsung, while some products remained with CSR. In 2014 CSR + was acquired by Qualcomm who still sell some of the SiRF products. + + SiRF chips can be used over UART, I2C or SPI buses. + +allOf: + - $ref: gnss-common.yaml# + +properties: + compatible: + enum: + - csr,gsd4t + - csr,csrg05ta03-icje-r + - fastrax,uc430 + - linx,r4 + - wi2wi,w2sg0004 + - wi2wi,w2sg0008i + - wi2wi,w2sg0084i + + reg: + description: + The I2C Address, SPI chip select address. Not required on UART buses. + + vcc-supply: + description: + Main voltage regulator, pin names such as 3V3_IN, VCC, VDD. + + reset-gpios: + maxItems: 1 + description: An optional active low reset line, should be flagged with + GPIO_ACTIVE_LOW. + + sirf,onoff-gpios: + maxItems: 1 + description: GPIO used to power on and off device, pin name ON_OFF. + + sirf,wakeup-gpios: + maxItems: 1 + description: GPIO used to determine device power state, pin names such + as RFPWRUP, WAKEUP. + +required: + - compatible + - vcc-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + serial { + gnss { + compatible = "wi2wi,w2sg0084i"; + vcc-supply = <&gnss_vcc_reg>; + reset-gpios = <&gpio0 15 GPIO_ACTIVE_LOW>; + sirf,onoff-gpios = <&gpio0 16 GPIO_ACTIVE_HIGH>; + sirf,wakeup-gpios = <&gpio0 17 GPIO_ACTIVE_HIGH>; + current-speed = <38400>; + }; + }; diff --git a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml index 396101a223e7..35a760cfd343 100644 --- a/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml +++ b/Documentation/devicetree/bindings/gnss/u-blox,neo-6m.yaml @@ -6,6 +6,9 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: U-blox GNSS Receiver Device Tree Bindings +allOf: + - $ref: gnss-common.yaml# + maintainers: - Johan Hovold <johan@kernel.org> @@ -29,27 +32,20 @@ properties: description: > Main voltage regulator - timepulse-gpios: - maxItems: 1 - description: > - Time pulse GPIO - u-blox,extint-gpios: maxItems: 1 description: > GPIO connected to the "external interrupt" input pin - + v-bckp-supply: description: > Backup voltage regulator - current-speed: true - required: - compatible - vcc-supply -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml b/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml new file mode 100644 index 000000000000..7c41d8e814cd --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/airoha,en7523-gpio.yaml @@ -0,0 +1,66 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/airoha,en7523-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Airoha EN7523 GPIO controller + +maintainers: + - John Crispin <john@phrozen.org> + +description: | + Airoha's GPIO controller on their ARM EN7523 SoCs consists of two banks of 32 + GPIOs. + +properties: + $nodename: + pattern: "^gpio@[0-9a-f]+$" + + compatible: + items: + - const: airoha,en7523-gpio + + reg: + description: | + The first tuple points to the input register. + The second and third tuple point to the direction registers + The fourth tuple points to the output register + maxItems: 4 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + +additionalProperties: false + +examples: + - | + gpio0: gpio@1fbf0200 { + compatible = "airoha,en7523-gpio"; + reg = <0x1fbf0204 0x4>, + <0x1fbf0200 0x4>, + <0x1fbf0220 0x4>, + <0x1fbf0214 0x4>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio1: gpio@1fbf0270 { + compatible = "airoha,en7523-gpio"; + reg = <0x1fbf0270 0x4>, + <0x1fbf0260 0x4>, + <0x1fbf0264 0x4>, + <0x1fbf0278 0x4>; + gpio-controller; + #gpio-cells = <2>; + }; + +... diff --git a/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml new file mode 100644 index 000000000000..e3e668a12091 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/delta,tn48m-gpio.yaml @@ -0,0 +1,39 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/delta,tn48m-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD GPIO controller + +maintainers: + - Robert Marko <robert.marko@sartura.hr> + +description: | + This module is part of the Delta TN48M multi-function device. For more + details see ../mfd/delta,tn48m-cpld.yaml. + + Delta TN48M has an onboard Lattice CPLD that is used as an GPIO expander. + It provides 12 pins in total, they are input-only or ouput-only type. + +properties: + compatible: + enum: + - delta,tn48m-gpo + - delta,tn48m-gpi + + reg: + maxItems: 1 + + "#gpio-cells": + const: 2 + + gpio-controller: true + +required: + - compatible + - reg + - "#gpio-cells" + - gpio-controller + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt deleted file mode 100644 index d04236558619..000000000000 --- a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.txt +++ /dev/null @@ -1,27 +0,0 @@ -Faraday Technology FTGPIO010 GPIO Controller - -Required properties: - -- compatible : Should be one of - "cortina,gemini-gpio", "faraday,ftgpio010" - "moxa,moxart-gpio", "faraday,ftgpio010" - "faraday,ftgpio010" -- reg : Should contain registers location and length -- interrupts : Should contain the interrupt line for the GPIO block -- gpio-controller : marks this as a GPIO controller -- #gpio-cells : Should be 2, see gpio/gpio.txt -- interrupt-controller : marks this as an interrupt controller -- #interrupt-cells : a standard two-cell interrupt flag, see - interrupt-controller/interrupts.txt - -Example: - -gpio@4d000000 { - compatible = "cortina,gemini-gpio", "faraday,ftgpio010"; - reg = <0x4d000000 0x100>; - interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; - gpio-controller; - #gpio-cells = <2>; - interrupt-controller; - #interrupt-cells = <2>; -}; diff --git a/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml new file mode 100644 index 000000000000..640da5b9b0cc --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/faraday,ftgpio010.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/faraday,ftgpio010.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Faraday Technology FTGPIO010 GPIO Controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +properties: + compatible: + oneOf: + - items: + - const: cortina,gemini-gpio + - const: faraday,ftgpio010 + - items: + - const: moxa,moxart-gpio + - const: faraday,ftgpio010 + - const: faraday,ftgpio010 + + reg: + maxItems: 1 + + resets: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + description: Should contain the interrupt line for the GPIO block + + gpio-controller: true + "#gpio-cells": + const: 2 + + interrupt-controller: true + "#interrupt-cells": + const: 2 + +required: + - compatible + - reg + - interrupts + - "#gpio-cells" + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + gpio@4d000000 { + compatible = "cortina,gemini-gpio", "faraday,ftgpio010"; + reg = <0x4d000000 0x100>; + interrupts = <22 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml index b6a6e742b66d..dc0fc8fc4839 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-pca95xx.yaml @@ -190,14 +190,6 @@ examples: "chg-status+red", "green", "blue", "en-esata", "fault1", "p26", "p27"; }; - - ts3a227@3b { - compatible = "ti,ts3a227e"; - reg = <0x3b>; - interrupt-parent = <&gpio99>; - interrupts = <14 IRQ_TYPE_EDGE_RISING>; - ti,micbias = <0>; /* 2.1V */ - }; }; - | diff --git a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml index e1359391d3a4..d2c39dba56ad 100644 --- a/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml +++ b/Documentation/devicetree/bindings/gpio/gpio-vf610.yaml @@ -25,7 +25,9 @@ properties: - const: fsl,imx7ulp-gpio - const: fsl,vf610-gpio - items: - - const: fsl,imx8ulp-gpio + - enum: + - fsl,imx93-gpio + - fsl,imx8ulp-gpio - const: fsl,imx7ulp-gpio reg: diff --git a/Documentation/devicetree/bindings/gpio/gpio.txt b/Documentation/devicetree/bindings/gpio/gpio.txt index a8895d339bfe..5663e71b751f 100644 --- a/Documentation/devicetree/bindings/gpio/gpio.txt +++ b/Documentation/devicetree/bindings/gpio/gpio.txt @@ -213,7 +213,7 @@ Example of two SOC GPIO banks defined as gpio-controller nodes: gpio-controller; #gpio-cells = <2>; - line_b { + line_b-hog { gpio-hog; gpios = <6 0>; output-low; diff --git a/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml new file mode 100644 index 000000000000..110651eafa70 --- /dev/null +++ b/Documentation/devicetree/bindings/gpio/microchip,mpfs-gpio.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/gpio/microchip,mpfs-gpio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS GPIO Controller Device Tree Bindings + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +properties: + compatible: + items: + - enum: + - microchip,mpfs-gpio + + reg: + maxItems: 1 + + interrupts: + description: + Interrupt mapping, one per GPIO. Maximum 32 GPIOs. + minItems: 1 + maxItems: 32 + + interrupt-controller: true + + clocks: + maxItems: 1 + + "#gpio-cells": + const: 2 + + "#interrupt-cells": + const: 1 + + ngpios: + description: + The number of GPIOs available. + minimum: 1 + maximum: 32 + default: 32 + + gpio-controller: true + +required: + - compatible + - reg + - interrupts + - "#interrupt-cells" + - interrupt-controller + - "#gpio-cells" + - gpio-controller + - clocks + +additionalProperties: false + +examples: + - | + gpio@20122000 { + compatible = "microchip,mpfs-gpio"; + reg = <0x20122000 0x1000>; + clocks = <&clkcfg 25>; + interrupt-parent = <&plic>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <1>; + interrupts = <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>, + <53>, <53>, <53>, <53>; + }; +... diff --git a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml index e04349567eeb..939e31c48081 100644 --- a/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml +++ b/Documentation/devicetree/bindings/gpio/sifive,gpio.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: SiFive GPIO controller maintainers: - - Yash Shah <yash.shah@sifive.com> - Paul Walmsley <paul.walmsley@sifive.com> properties: @@ -80,7 +79,7 @@ examples: interrupts = <7>, <8>, <9>, <10>, <11>, <12>, <13>, <14>, <15>, <16>, <17>, <18>, <19>, <20>, <21>, <22>; reg = <0x10060000 0x1000>; - clocks = <&tlclk PRCI_CLK_TLCLK>; + clocks = <&tlclk FU540_PRCI_CLK_TLCLK>; gpio-controller; #gpio-cells = <2>; interrupt-controller; diff --git a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml index 63a08f3f321d..4d6bfae0653c 100644 --- a/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml +++ b/Documentation/devicetree/bindings/gpu/arm,mali-bifrost.yaml @@ -159,6 +159,21 @@ allOf: power-domains: maxItems: 1 sram-supply: false + - if: + properties: + compatible: + contains: + const: rockchip,rk3568-mali + then: + properties: + clocks: + minItems: 2 + clock-names: + items: + - const: gpu + - const: bus + required: + - clock-names examples: - | diff --git a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml index ae1b37dbee75..0a955c7b9706 100644 --- a/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml +++ b/Documentation/devicetree/bindings/hwlock/ti,omap-hwspinlock.yaml @@ -39,39 +39,8 @@ additionalProperties: false examples: - | - /* OMAP4 SoCs */ - hwspinlock: spinlock@4a0f6000 { + spinlock@4a0f6000 { compatible = "ti,omap4-hwspinlock"; reg = <0x4a0f6000 0x1000>; #hwlock-cells = <1>; }; - - - | - / { - /* K3 AM65x SoCs */ - model = "Texas Instruments K3 AM654 SoC"; - compatible = "ti,am654-evm", "ti,am654"; - #address-cells = <2>; - #size-cells = <2>; - - bus@100000 { - compatible = "simple-bus"; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0x00 0x00100000 0x00 0x00100000 0x00 0x00020000>, /* ctrl mmr */ - <0x00 0x30800000 0x00 0x30800000 0x00 0x0bc00000>; /* Main NavSS */ - - bus@30800000 { - compatible = "simple-mfd"; - #address-cells = <2>; - #size-cells = <2>; - ranges = <0x00 0x30800000 0x00 0x30800000 0x00 0x0bc00000>; - - spinlock@30e00000 { - compatible = "ti,am654-hwspinlock"; - reg = <0x00 0x30e00000 0x00 0x1000>; - #hwlock-cells = <1>; - }; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml index 223393d7cafd..ab87f51c5aef 100644 --- a/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml +++ b/Documentation/devicetree/bindings/hwmon/adi,adm1275.yaml @@ -37,6 +37,72 @@ properties: description: Shunt resistor value in micro-Ohm. + adi,volt-curr-sample-average: + description: | + Number of samples to be used to report voltage and current values. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32, 64, 128] + + adi,power-sample-average: + description: | + Number of samples to be used to report power values. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2, 4, 8, 16, 32, 64, 128] + +allOf: + - if: + properties: + compatible: + contains: + enum: + - adi,adm1075 + - adi,adm1276 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: false + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1275 + then: + properties: + adi,volt-curr-sample-average: + default: 16 + adi,power-sample-average: false + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1272 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: + default: 128 + + - if: + properties: + compatible: + contains: + enum: + - adi,adm1278 + - adi,adm1293 + - adi,adm1294 + then: + properties: + adi,volt-curr-sample-average: + default: 128 + adi,power-sample-average: + default: 1 + required: - compatible - reg @@ -53,5 +119,7 @@ examples: compatible = "adi,adm1272"; reg = <0x10>; shunt-resistor-micro-ohms = <500>; + adi,volt-curr-sample-average = <128>; + adi,power-sample-average = <128>; }; }; diff --git a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml index 6e1d54ff5d5b..30db92977937 100644 --- a/Documentation/devicetree/bindings/hwmon/national,lm90.yaml +++ b/Documentation/devicetree/bindings/hwmon/national,lm90.yaml @@ -60,7 +60,6 @@ additionalProperties: false examples: - | - #include <dt-bindings/gpio/tegra-gpio.h> #include <dt-bindings/interrupt-controller/irq.h> i2c { @@ -71,8 +70,7 @@ examples: compatible = "onnn,nct1008"; reg = <0x4c>; vcc-supply = <&palmas_ldo6_reg>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(O, 4) IRQ_TYPE_LEVEL_LOW>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; #thermal-sensor-cells = <1>; }; }; diff --git a/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml new file mode 100644 index 000000000000..801ca9ba7d34 --- /dev/null +++ b/Documentation/devicetree/bindings/hwmon/ti,tmp464.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/hwmon/ti,tmp464.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TMP464 and TMP468 temperature sensors + +maintainers: + - Agathe Porte <agathe.porte@nokia.com> + +description: | + ±0.0625°C Remote and Local temperature sensor + https://www.ti.com/lit/ds/symlink/tmp464.pdf + https://www.ti.com/lit/ds/symlink/tmp468.pdf + +properties: + compatible: + enum: + - ti,tmp464 + - ti,tmp468 + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +additionalProperties: false + +patternProperties: + "^channel@([0-8])$": + type: object + description: | + Represents channels of the device and their specific configuration. + + properties: + reg: + description: | + The channel number. 0 is local channel, 1-8 are remote channels. + items: + minimum: 0 + maximum: 8 + + label: + description: | + A descriptive name for this channel, like "ambient" or "psu". + + ti,n-factor: + description: | + The value (two's complement) to be programmed in the channel specific N correction register. + For remote channels only. + $ref: /schemas/types.yaml#/definitions/int32 + items: + minimum: -128 + maximum: 127 + + required: + - reg + + additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4b { + compatible = "ti,tmp464"; + reg = <0x4b>; + }; + }; + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + sensor@4b { + compatible = "ti,tmp464"; + reg = <0x4b>; + #address-cells = <1>; + #size-cells = <0>; + + channel@0 { + reg = <0x0>; + label = "local"; + }; + + channel@1 { + reg = <0x1>; + ti,n-factor = <(-10)>; + label = "external"; + }; + + channel@2 { + reg = <0x2>; + ti,n-factor = <0x10>; + label = "somelabel"; + }; + + channel@3 { + reg = <0x3>; + status = "disabled"; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml new file mode 100644 index 000000000000..ea2303c0e143 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/atmel,at91sam-i2c.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/atmel,at91sam-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: I2C for Atmel/Microchip platforms + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +properties: + compatible: + oneOf: + - items: + - enum: + - atmel,at91rm9200-i2c + - atmel,at91sam9261-i2c + - atmel,at91sam9260-i2c + - atmel,at91sam9g20-i2c + - atmel,at91sam9g10-i2c + - atmel,at91sam9x5-i2c + - atmel,sama5d4-i2c + - atmel,sama5d2-i2c + - microchip,sam9x60-i2c + - items: + - const: microchip,sama7g5-i2c + - const: microchip,sam9x60-i2c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + clocks: + maxItems: 1 + + clock-frequency: + default: 100000 + + dmas: + items: + - description: TX DMA Channel Specifier + - description: RX DMA Channel Specifier + + dma-names: + items: + - const: tx + - const: rx + + atmel,fifo-size: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum number of data the RX and TX FIFOs can store for + FIFO capable I2C controllers. + + scl-gpios: true + + sda-gpios: true + +required: + - compatible + - reg + - interrupts + - "#address-cells" + - "#size-cells" + - clocks + +allOf: + - $ref: "i2c-controller.yaml" + - if: + properties: + compatible: + contains: + enum: + - atmel,sama5d4-i2c + - atmel,sama5d2-i2c + - microchip,sam9x60-i2c + - microchip,sama7g5-i2c + then: + properties: + i2c-sda-hold-time-ns: + description: + TWD hold time + maxItems: 1 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/gpio/gpio.h> + + i2c0: i2c@fff84000 { + compatible = "atmel,at91sam9g20-i2c"; + reg = <0xfff84000 0x100>; + interrupts = <12 IRQ_TYPE_LEVEL_HIGH 6>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&twi0_clk>; + clock-frequency = <400000>; + + eeprom@50 { + compatible = "atmel,24c512"; + reg = <0x50>; + pagesize = <128>; + }; + }; + + i2c1: i2c@f8034600 { + compatible = "atmel,sama5d2-i2c"; + reg = <0xf8034600 0x100>; + interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>; + dmas = <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) + AT91_XDMAC_DT_PERID(11)>, + <&dma0 + (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) + AT91_XDMAC_DT_PERID(12)>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&flx0>; + atmel,fifo-size = <16>; + i2c-sda-hold-time-ns = <336>; + pinctrl-names = "default", "gpio"; + pinctrl-0 = <&pinctrl_i2c0>; + pinctrl-1 = <&pinctrl_i2c0_gpio>; + sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; + scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; + + eeprom@54 { + compatible = "atmel,24c02"; + reg = <0x54>; + pagesize = <16>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt deleted file mode 100644 index 2015f50aed0f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt +++ /dev/null @@ -1,82 +0,0 @@ -I2C for Atmel platforms - -Required properties : -- compatible : Must be one of: - "atmel,at91rm9200-i2c", - "atmel,at91sam9261-i2c", - "atmel,at91sam9260-i2c", - "atmel,at91sam9g20-i2c", - "atmel,at91sam9g10-i2c", - "atmel,at91sam9x5-i2c", - "atmel,sama5d4-i2c", - "atmel,sama5d2-i2c", - "microchip,sam9x60-i2c". -- reg: physical base address of the controller and length of memory mapped - region. -- interrupts: interrupt number to the cpu. -- #address-cells = <1>; -- #size-cells = <0>; -- clocks: phandles to input clocks. - -Optional properties: -- clock-frequency: Desired I2C bus frequency in Hz, otherwise defaults to 100000 -- dmas: A list of two dma specifiers, one for each entry in dma-names. -- dma-names: should contain "tx" and "rx". -- atmel,fifo-size: maximum number of data the RX and TX FIFOs can store for FIFO - capable I2C controllers. -- i2c-sda-hold-time-ns: TWD hold time, only available for: - "atmel,sama5d4-i2c", - "atmel,sama5d2-i2c", - "microchip,sam9x60-i2c". -- scl-gpios: specify the gpio related to SCL pin -- sda-gpios: specify the gpio related to SDA pin -- pinctrl: add extra pinctrl to configure i2c pins to gpio function for i2c - bus recovery, call it "gpio" state -- Child nodes conforming to i2c bus binding - - -Examples : - -i2c0: i2c@fff84000 { - compatible = "atmel,at91sam9g20-i2c"; - reg = <0xfff84000 0x100>; - interrupts = <12 4 6>; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&twi0_clk>; - clock-frequency = <400000>; - - 24c512@50 { - compatible = "atmel,24c512"; - reg = <0x50>; - pagesize = <128>; - } -} - -i2c0: i2c@f8034600 { - compatible = "atmel,sama5d2-i2c"; - reg = <0xf8034600 0x100>; - interrupts = <19 IRQ_TYPE_LEVEL_HIGH 7>; - dmas = <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) - AT91_XDMAC_DT_PERID(11)>, - <&dma0 - (AT91_XDMAC_DT_MEM_IF(0) | AT91_XDMAC_DT_PER_IF(1)) - AT91_XDMAC_DT_PERID(12)>; - dma-names = "tx", "rx"; - #address-cells = <1>; - #size-cells = <0>; - clocks = <&flx0>; - atmel,fifo-size = <16>; - i2c-sda-hold-time-ns = <336>; - pinctrl-names = "default", "gpio"; - pinctrl-0 = <&pinctrl_i2c0>; - pinctrl-1 = <&pinctrl_i2c0_gpio>; - sda-gpios = <&pioA 30 GPIO_ACTIVE_HIGH>; - scl-gpios = <&pioA 31 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>; - - wm8731: wm8731@1a { - compatible = "wm8731"; - reg = <0x1a>; - }; -}; diff --git a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml index c167958ae2a9..01720e338b4c 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-imx.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-imx.yaml @@ -88,9 +88,7 @@ unevaluatedProperties: false examples: - | #include <dt-bindings/clock/imx5-clock.h> - #include <dt-bindings/clock/vf610-clock.h> - #include <dt-bindings/gpio/gpio.h> - #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> i2c@83fc4000 { compatible = "fsl,imx51-i2c", "fsl,imx21-i2c"; @@ -99,6 +97,9 @@ examples: clocks = <&clks IMX5_CLK_I2C2_GATE>; }; + - | + #include <dt-bindings/clock/vf610-clock.h> + i2c@40066000 { compatible = "fsl,vf610-i2c"; reg = <0x40066000 0x1000>; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml index 98c6fcf7bf26..018e1b944424 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml +++ b/Documentation/devicetree/bindings/i2c/i2c-mpc.yaml @@ -73,6 +73,7 @@ examples: clock-frequency = <100000>; }; + - | /* MPC5200B based board */ i2c@3d00 { #address-cells = <1>; @@ -84,6 +85,7 @@ examples: fsl,preserve-clocking; }; + - | /* MPC8544 base board */ i2c@3100 { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt index 5ea216ae7084..026985b8f61a 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-mt65xx.txt @@ -12,8 +12,10 @@ Required properties: "mediatek,mt7622-i2c": for MediaTek MT7622 "mediatek,mt7623-i2c", "mediatek,mt6577-i2c": for MediaTek MT7623 "mediatek,mt7629-i2c", "mediatek,mt2712-i2c": for MediaTek MT7629 + "mediatek,mt8168-i2c": for MediaTek MT8168 "mediatek,mt8173-i2c": for MediaTek MT8173 "mediatek,mt8183-i2c": for MediaTek MT8183 + "mediatek,mt8186-i2c": for MediaTek MT8186 "mediatek,mt8192-i2c": for MediaTek MT8192 "mediatek,mt8195-i2c", "mediatek,mt8192-i2c": for MediaTek MT8195 "mediatek,mt8516-i2c", "mediatek,mt2712-i2c": for MediaTek MT8516 diff --git a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt index 7b9fc0c22eaf..924ad8c03464 100644 --- a/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt +++ b/Documentation/devicetree/bindings/i2c/i2c-qcom-cci.txt @@ -10,6 +10,7 @@ PROPERTIES: "qcom,msm8996-cci" "qcom,sdm845-cci" "qcom,sm8250-cci" + "qcom,sm8450-cci" - reg Usage: required @@ -43,7 +44,8 @@ PROPERTIES: SUBNODES: 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". +sdm845, sm8250 and sm8450), described as subdevices named "i2c-bus@0" and +"i2c-bus@1". PROPERTIES: diff --git a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt b/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt deleted file mode 100644 index 66ae46d3bc2f..000000000000 --- a/Documentation/devicetree/bindings/i2c/i2c-s3c2410.txt +++ /dev/null @@ -1,58 +0,0 @@ -* Samsung's I2C controller - -The Samsung's I2C controller is used to interface with I2C devices. - -Required properties: - - compatible: value should be either of the following. - (a) "samsung, s3c2410-i2c", for i2c compatible with s3c2410 i2c. - (b) "samsung, s3c2440-i2c", for i2c compatible with s3c2440 i2c. - (c) "samsung, s3c2440-hdmiphy-i2c", for s3c2440-like i2c used - inside HDMIPHY block found on several samsung SoCs - (d) "samsung, exynos5-sata-phy-i2c", for s3c2440-like i2c used as - a host to SATA PHY controller on an internal bus. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - samsung,i2c-sda-delay: Delay (in ns) applied to data line (SDA) edges. - -Required for all cases except "samsung,s3c2440-hdmiphy-i2c": - - Samsung GPIO variant (deprecated): - - gpios: The order of the gpios should be the following: <SDA, SCL>. - The gpio specifier depends on the gpio controller. Required in all - cases except for "samsung,s3c2440-hdmiphy-i2c" whose input/output - lines are permanently wired to the respective clienta - - Pinctrl variant (preferred, if available): - - pinctrl-0: Pin control group to be used for this controller. - - pinctrl-names: Should contain only one value - "default". - -Optional properties: - - samsung,i2c-slave-addr: Slave address in multi-master environment. If not - specified, default value is 0. - - samsung,i2c-max-bus-freq: Desired frequency in Hz of the bus. If not - specified, the default value in Hz is 100000. - - samsung,sysreg-phandle - handle to syscon used to control the system registers - -Example: - - i2c@13870000 { - compatible = "samsung,s3c2440-i2c"; - reg = <0x13870000 0x100>; - interrupts = <345>; - samsung,i2c-sda-delay = <100>; - samsung,i2c-max-bus-freq = <100000>; - /* Samsung GPIO variant begins here */ - gpios = <&gpd1 2 0 /* SDA */ - &gpd1 3 0 /* SCL */>; - /* Samsung GPIO variant ends here */ - /* Pinctrl variant begins here */ - pinctrl-0 = <&i2c3_bus>; - pinctrl-names = "default"; - /* Pinctrl variant ends here */ - #address-cells = <1>; - #size-cells = <0>; - - wm8994@1a { - compatible = "wlf,wm8994"; - reg = <0x1a>; - }; - }; diff --git a/Documentation/devicetree/bindings/i2c/i2c.txt b/Documentation/devicetree/bindings/i2c/i2c.txt index b864916e087f..fc3dd7ec0445 100644 --- a/Documentation/devicetree/bindings/i2c/i2c.txt +++ b/Documentation/devicetree/bindings/i2c/i2c.txt @@ -95,6 +95,10 @@ wants to support one of the below features, it should adapt these bindings. - smbus-alert states that the optional SMBus-Alert feature apply to this bus. +- mctp-controller + indicates that the system is accessible via this bus as an endpoint for + MCTP over I2C transport. + Required properties (per child device) -------------------------------------- diff --git a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml index febde6cc5f69..af6d64a6da6e 100644 --- a/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/ingenic,i2c.yaml @@ -69,8 +69,7 @@ examples: #size-cells = <0>; reg = <0x10054000 0x1000>; - interrupt-parent = <&intc>; - interrupts = <56>; + interrupts = <56 IRQ_TYPE_LEVEL_LOW>; clocks = <&cgu JZ4780_CLK_SMB4>; pinctrl-names = "default"; @@ -86,7 +85,6 @@ examples: compatible = "nxp,pcf8563"; reg = <0x51>; - interrupt-parent = <&gpf>; interrupts = <30 IRQ_TYPE_LEVEL_LOW>; }; }; diff --git a/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml new file mode 100644 index 000000000000..7bad4b946a34 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/microchip,corei2c.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/microchip,corei2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS I2C Controller Device Tree Bindings + +maintainers: + - Daire McNamara <daire.mcnamara@microchip.com> + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + +properties: + compatible: + oneOf: + - items: + - const: microchip,mpfs-i2c # Microchip PolarFire SoC compatible SoCs + - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core + - const: microchip,corei2c-rtl-v7 # Microchip Fabric based i2c IP core + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: + description: | + Desired I2C bus clock frequency in Hz. As only Standard and Fast + modes are supported, possible values are 100000 and 400000. + enum: [100000, 400000] + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + i2c@2010a000 { + compatible = "microchip,mpfs-i2c", "microchip,corei2c-rtl-v7"; + reg = <0x2010a000 0x1000>; + clocks = <&clkcfg 15>; + interrupt-parent = <&plic>; + interrupts = <58>; + clock-frequency = <100000>; + }; +... diff --git a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml index 052aad44e781..c30107833a51 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,rcar-i2c.yaml @@ -49,6 +49,11 @@ properties: - renesas,i2c-r8a779a0 # R-Car V3U - const: renesas,rcar-gen3-i2c # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,i2c-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-i2c # R-Car Gen4 + reg: maxItems: 1 @@ -132,6 +137,7 @@ allOf: enum: - renesas,rcar-gen2-i2c - renesas,rcar-gen3-i2c + - renesas,rcar-gen4-i2c then: required: - resets diff --git a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml index 402fd125e010..f4b235a87ac6 100644 --- a/Documentation/devicetree/bindings/i2c/renesas,riic.yaml +++ b/Documentation/devicetree/bindings/i2c/renesas,riic.yaml @@ -20,6 +20,7 @@ properties: - renesas,riic-r7s72100 # RZ/A1H - renesas,riic-r7s9210 # RZ/A2M - renesas,riic-r9a07g044 # RZ/G2{L,LC} + - renesas,riic-r9a07g054 # RZ/V2L - const: renesas,riic-rz # RZ/A or RZ/G2L reg: @@ -75,6 +76,7 @@ if: contains: enum: - renesas,riic-r9a07g044 + - renesas,riic-r9a07g054 then: required: - resets diff --git a/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml new file mode 100644 index 000000000000..84051b0129c2 --- /dev/null +++ b/Documentation/devicetree/bindings/i2c/samsung,s3c2410-i2c.yaml @@ -0,0 +1,164 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/i2c/samsung,s3c2410-i2c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC I2C Controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - samsung,s3c2410-i2c + - samsung,s3c2440-i2c + # For s3c2440-like I2C used inside HDMIPHY block found on several SoCs: + - samsung,s3c2440-hdmiphy-i2c + # For s3c2440-like I2C used as a host to SATA PHY controller on an + # internal bus: + - samsung,exynos5-sata-phy-i2c + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: i2c + + gpios: + description: | + The order of the GPIOs should be the following:: <SDA, SCL>. The GPIO + specifier depends on the gpio controller. Required in all cases except + for "samsung,s3c2440-hdmiphy-i2c" whose input/output lines are + permanently wired to the respective client. + This property is deprecated. Use "pinctrl-0" and "pinctrl-names" instead. + deprecated: yes + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + samsung,i2c-max-bus-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Desired frequency in Hz of the bus. + default: 100000 + + samsung,i2c-sda-delay: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Delay (in ns) applied to data line (SDA) edges. + default: 0 + + samsung,i2c-slave-addr: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Slave address in multi-master environment. + default: 0 + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: Pandle to syscon used to control the system registers. + + '#size-cells': + const: 0 + +required: + - compatible + - reg + +allOf: + - $ref: /schemas/i2c/i2c-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2440-hdmiphy-i2c + - samsung,exynos5-sata-phy-i2c + then: + properties: + gpios: false + + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-i2c + - samsung,s3c2440-i2c + - samsung,s3c2440-hdmiphy-i2c + then: + required: + - interrupts + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5250.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + i2c@12c60000 { + compatible = "samsung,s3c2440-i2c"; + reg = <0x12C60000 0x100>; + interrupts = <GIC_SPI 56 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_I2C0>; + clock-names = "i2c"; + pinctrl-names = "default"; + pinctrl-0 = <&i2c0_bus>; + + samsung,sysreg-phandle = <&sysreg_system_controller>; + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <20000>; + samsung,i2c-slave-addr = <0x66>; + + eeprom@50 { + compatible = "samsung,s524ad0xd1"; + reg = <0x50>; + }; + }; + + i2c@12ce0000 { + compatible = "samsung,s3c2440-hdmiphy-i2c"; + reg = <0x12CE0000 0x1000>; + interrupts = <GIC_SPI 64 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_I2C_HDMI>; + clock-names = "i2c"; + + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <66000>; + + phy-i2c@38 { + compatible = "samsung,exynos4212-hdmiphy"; + reg = <0x38>; + }; + }; + + i2c@121d0000 { + compatible = "samsung,exynos5-sata-phy-i2c"; + reg = <0x121D0000 0x100>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&clock CLK_SATA_PHYI2C>; + clock-names = "i2c"; + + samsung,i2c-sda-delay = <100>; + samsung,i2c-max-bus-freq = <40000>; + + phy-i2c@38 { + compatible = "samsung,exynos-sataphy-i2c"; + reg = <0x38>; + }; + }; diff --git a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml index 46b62e1c9273..dccbb18b6dc0 100644 --- a/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml +++ b/Documentation/devicetree/bindings/i2c/st,stm32-i2c.yaml @@ -25,16 +25,9 @@ allOf: i2c-scl-falling-time-ns: default: 10 - - st,syscfg-fmp: - description: Use to set Fast Mode Plus bit within SYSCFG when - Fast Mode Plus speed is selected by slave. - Format is phandle to syscfg / register offset within - syscfg / register bitmask for FMP bit. - $ref: "/schemas/types.yaml#/definitions/phandle-array" - items: - minItems: 3 - maxItems: 3 + else: + properties: + st,syscfg-fmp: false - if: properties: @@ -87,6 +80,16 @@ properties: minimum: 1 maximum: 1000000 + st,syscfg-fmp: + description: Use to set Fast Mode Plus bit within SYSCFG when Fast Mode + Plus speed is selected by slave. + $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to syscfg + - description: register offset within syscfg + - description: register bitmask for FMP bit + required: - compatible - reg @@ -147,4 +150,3 @@ examples: i2c-scl-falling-time-ns = <20>; st,syscfg-fmp = <&syscfg 0x4 0x2>; }; -... diff --git a/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml new file mode 100644 index 000000000000..d259e796c1d6 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/accel/adi,adxl367.yaml @@ -0,0 +1,79 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/accel/adi,adxl367.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices ADXL367 3-Axis Digital Accelerometer + +maintainers: + - Cosmin Tanislav <cosmin.tanislav@analog.com> + +description: | + The ADXL367 is an ultralow power, 3-axis MEMS accelerometer. + + The ADXL367 does not alias input signals by to achieve ultralow power + consumption, it samples the full bandwidth of the sensor at all + data rates. Measurement ranges of +-2g, +-4g, and +-8g are available, + with a resolution of 0.25mg/LSB on the +-2 g range. + + In addition to its ultralow power consumption, the ADXL367 + has many features to enable true system level power reduction. + It includes a deep multimode output FIFO, a built-in micropower + temperature sensor, and an internal ADC for synchronous conversion + of an additional analog input. + https://www.analog.com/en/products/adxl367.html + +properties: + compatible: + enum: + - adi,adxl367 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + spi-max-frequency: true + + vdd-supply: true + vddio-supply: true + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@53 { + compatible = "adi,adxl367"; + reg = <0x53>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + }; + }; + - | + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + accelerometer@0 { + compatible = "adi,adxl367"; + reg = <0>; + spi-max-frequency = <1000000>; + interrupt-parent = <&gpio>; + interrupts = <25 IRQ_TYPE_EDGE_RISING>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml new file mode 100644 index 000000000000..a694d5794d4a --- /dev/null +++ b/Documentation/devicetree/bindings/iio/adc/adi,ad7280a.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/adc/adi,ad7280a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices AD7280a Lithium Ion Battery Monitoring System + +maintainers: + - Michael Hennerich <michael.hennerich@analog.com> + - Jonathan Cameron <jic23@kernel.org> + +description: | + Bindings for the Analog Devices AD7280a Battery Monitoring System. + Used in devices such as hybrid electric cars, battery backup and power tools. + Multiple chips can be daisy chained and accessed via a single SPI interface. + Data sheet found here: + https://www.analog.com/media/en/technical-documentation/data-sheets/AD7280A.pdf + +properties: + compatible: + const: adi,ad7280a + + reg: + maxItems: 1 + + interrupts: + description: IRQ line for the ADC + maxItems: 1 + + spi-max-frequency: true + + adi,voltage-alert-last-chan: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + Allows limiting of scope of which channels are considered for voltage + alerts, typically because not all are wired to anything. Only applies to + last device in the daisy chain. + default: 5 + enum: [3, 4, 5] + + adi,acquisition-time-ns: + description: + Additional time may be needed to charge the sampling capacitors depending + on external writing. + default: 400 + enum: [400, 800, 1200, 1600] + + adi,thermistor-termination: + type: boolean + description: + Enable the thermistor termination function. + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + + adc@0 { + compatible = "adi,ad7280a"; + reg = <0>; + spi-max-frequency = <700000>; + interrupt-parent = <&gpio>; + interrupts = <25 2>; + adi,thermistor-termination; + adi,acquisition-time-ns = <800>; + adi,voltage-alert-last-chan = <5>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml index efed361215b4..31f840d59303 100644 --- a/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/atmel,sama5d2-adc.yaml @@ -7,7 +7,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: AT91 SAMA5D2 Analog to Digital Converter (ADC) maintainers: - - Ludovic Desroches <ludovic.desroches@atmel.com> - Eugen Hristev <eugen.hristev@microchip.com> properties: @@ -72,7 +71,6 @@ required: - atmel,min-sample-rate-hz - atmel,max-sample-rate-hz - atmel,startup-time-ms - - atmel,trigger-edge-type examples: - | diff --git a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml index b939f9652e3a..65581ad4b816 100644 --- a/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/mediatek,mt2701-auxadc.yaml @@ -34,6 +34,7 @@ properties: - items: - enum: - mediatek,mt8183-auxadc + - mediatek,mt8186-auxadc - mediatek,mt8195-auxadc - mediatek,mt8516-auxadc - const: mediatek,mt8173-auxadc diff --git a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml index cbbac4ce56d6..fcc1ba53b20d 100644 --- a/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml +++ b/Documentation/devicetree/bindings/iio/adc/microchip,mcp3201.yaml @@ -10,7 +10,7 @@ maintainers: - Oskar Andero <oskar.andero@gmail.com> description: | - Family of simple ADCs with an I2C inteface. + Family of simple ADCs with a SPI interface. properties: compatible: diff --git a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml index 27e3108661c0..2a94db688830 100644 --- a/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/qcom,spmi-iadc.yaml @@ -51,7 +51,7 @@ examples: #size-cells = <0>; pmic_iadc: adc@3600 { compatible = "qcom,spmi-iadc"; - reg = <0x3600 0x100>; + reg = <0x3600>; interrupts = <0x0 0x36 0x0 IRQ_TYPE_EDGE_RISING>; qcom,external-resistor-micro-ohms = <10000>; #io-channel-cells = <1>; diff --git a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml index 7b895784e008..57a31356082e 100644 --- a/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml +++ b/Documentation/devicetree/bindings/iio/adc/ti,palmas-gpadc.yaml @@ -74,9 +74,9 @@ examples: compatible = "ti,twl6035-pmic", "ti,palmas-pmic"; adc { compatible = "ti,palmas-gpadc"; - interrupts = <18 0 - 16 0 - 17 0>; + interrupts = <18 0>, + <16 0>, + <17 0>; #io-channel-cells = <1>; ti,channel0-current-microamp = <5>; ti,channel3-current-microamp = <10>; diff --git a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml index 87992db389b2..3698b4b0900f 100644 --- a/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml +++ b/Documentation/devicetree/bindings/iio/adc/xlnx,zynqmp-ams.yaml @@ -92,6 +92,10 @@ properties: description: AMS Controller register space maxItems: 1 + clocks: + items: + - description: AMS reference clock + ranges: description: Maps the child address space for PS and/or PL. @@ -181,12 +185,15 @@ properties: required: - compatible - reg + - clocks - ranges additionalProperties: false examples: - | + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + bus { #address-cells = <2>; #size-cells = <2>; @@ -196,6 +203,7 @@ examples: interrupt-parent = <&gic>; interrupts = <0 56 4>; reg = <0x0 0xffa50000 0x0 0x800>; + clocks = <&zynqmp_clk AMS_REF>; #address-cells = <1>; #size-cells = <1>; #io-channel-cells = <1>; diff --git a/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml b/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml new file mode 100644 index 000000000000..336ce96371db --- /dev/null +++ b/Documentation/devicetree/bindings/iio/afe/temperature-sense-rtd.yaml @@ -0,0 +1,101 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/afe/temperature-sense-rtd.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Temperature Sense RTD + +maintainers: + - Liam Beguin <liambeguin@gmail.com> + +description: | + RTDs (Resistance Temperature Detectors) are a kind of temperature sensors + used to get a linear voltage to temperature reading within a give range + (usually 0 to 100 degrees Celsius). + + When an io-channel measures the output voltage across an RTD such as a + PT1000, the interesting measurement is almost always the corresponding + temperature, not the voltage output. This binding describes such a circuit. + + The general transfer function here is (using SI units) + + V = R(T) * iexc + R(T) = r0 * (1 + alpha * T) + T = 1 / (alpha * r0 * iexc) * (V - r0 * iexc) + + The following circuit matches what's in the examples section. + + 5V0 + ----- + | + +---+----+ + | R 5k | + +---+----+ + | + V 1mA + | + +---- Vout + | + +---+----+ + | PT1000 | + +---+----+ + | + ----- + GND + +properties: + compatible: + const: temperature-sense-rtd + + io-channels: + maxItems: 1 + description: | + Channel node of a voltage io-channel. + + '#io-channel-cells': + const: 0 + + excitation-current-microamp: + description: The current fed through the RTD sensor. + + alpha-ppm-per-celsius: + description: | + alpha can also be expressed in micro-ohms per ohm Celsius. It's a linear + approximation of the resistance versus temperature relationship + between 0 and 100 degrees Celsius. + + alpha = (R_100 - R_0) / (100 * R_0) + + Where, R_100 is the resistance of the sensor at 100 degrees Celsius, and + R_0 (or r-naught-ohms) is the resistance of the sensor at 0 degrees + Celsius. + + Pure platinum has an alpha of 3925. Industry standards such as IEC60751 + and ASTM E-1137 specify an alpha of 3850. + + r-naught-ohms: + description: | + Resistance of the sensor at 0 degrees Celsius. + Common values are 100 for PT100, 500 for PT500, and 1000 for PT1000 + +additionalProperties: false +required: + - compatible + - io-channels + - excitation-current-microamp + - alpha-ppm-per-celsius + - r-naught-ohms + +examples: + - | + pt1000_1: temperature-sensor0 { + compatible = "temperature-sense-rtd"; + #io-channel-cells = <0>; + io-channels = <&temp_adc1 0>; + + excitation-current-microamp = <1000>; /* i = U/R = 5 / 5000 */ + alpha-ppm-per-celsius = <3908>; + r-naught-ohms = <1000>; + }; +... diff --git a/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml b/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml new file mode 100644 index 000000000000..cfbf5350db27 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/afe/temperature-transducer.yaml @@ -0,0 +1,114 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/afe/temperature-transducer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Temperature Transducer + +maintainers: + - Liam Beguin <liambeguin@gmail.com> + +description: | + A temperature transducer is a device that converts a thermal quantity + into any other physical quantity. This binding applies to temperature to + voltage (like the LTC2997), and temperature to current (like the AD590) + linear transducers. + In both cases these are assumed to be connected to a voltage ADC. + + When an io-channel measures the output voltage of a temperature analog front + end such as a temperature transducer, the interesting measurement is almost + always the corresponding temperature, not the voltage output. This binding + describes such a circuit. + + The general transfer function here is (using SI units) + V(T) = Rsense * Isense(T) + T = (Isense(T) / alpha) + offset + T = 1 / (Rsense * alpha) * (V + offset * Rsense * alpha) + + When using a temperature to voltage transducer, Rsense is set to 1. + + The following circuits show a temperature to current and a temperature to + voltage transducer that can be used with this binding. + + VCC + ----- + | + +---+---+ + | AD590 | VCC + +---+---+ ----- + | | + V proportional to T +----+----+ + | D+ --+ | + +---- Vout | LTC2997 +--- Vout + | D- --+ | + +---+----+ +---------+ + | Rsense | | + +---+----+ ----- + | GND + ----- + GND + +properties: + compatible: + const: temperature-transducer + + io-channels: + maxItems: 1 + description: | + Channel node of a voltage io-channel. + + '#io-channel-cells': + const: 0 + + sense-offset-millicelsius: + description: | + Temperature offset. + This offset is commonly used to convert from Kelvins to degrees Celsius. + In that case, sense-offset-millicelsius would be set to <(-273150)>. + default: 0 + + sense-resistor-ohms: + description: | + The sense resistor. + By default sense-resistor-ohms cancels out the resistor making the + circuit behave like a temperature transducer. + default: 1 + + alpha-ppm-per-celsius: + description: | + Sometimes referred to as output gain, slope, or temperature coefficient. + + alpha is expressed in parts per million which can be micro-amps per + degrees Celsius or micro-volts per degrees Celsius. The is the main + characteristic of a temperature transducer and should be stated in the + datasheet. + +additionalProperties: false + +required: + - compatible + - io-channels + - alpha-ppm-per-celsius + +examples: + - | + ad950: temperature-sensor-0 { + compatible = "temperature-transducer"; + #io-channel-cells = <0>; + io-channels = <&temp_adc 3>; + + sense-offset-millicelsius = <(-273150)>; /* Kelvin to degrees Celsius */ + sense-resistor-ohms = <8060>; + alpha-ppm-per-celsius = <1>; /* 1 uA/K */ + }; + - | + znq_tmp: temperature-sensor-1 { + compatible = "temperature-transducer"; + #io-channel-cells = <0>; + io-channels = <&temp_adc 2>; + + sense-offset-millicelsius = <(-273150)>; /* Kelvin to degrees Celsius */ + alpha-ppm-per-celsius = <4000>; /* 4 mV/K */ + }; +... diff --git a/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.yaml new file mode 100644 index 000000000000..5277479be382 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/amplifiers/adi,ada4250.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/amplifiers/adi,ada4250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADA4250 Programmable Gain Instrumentation Amplifier + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Precision Low Power, 110kHz, 26uA, Programmable Gain Instrumentation Amplifier. + +properties: + compatible: + enum: + - adi,ada4250 + + reg: + maxItems: 1 + + avdd-supply: true + + adi,refbuf-enable: + description: + Enable internal buffer to drive the reference pin. + type: boolean + + spi-max-frequency: true + +required: + - compatible + - reg + - avdd-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + amplifier@0 { + compatible = "adi,ada4250"; + reg = <0>; + avdd-supply = <&avdd>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml new file mode 100644 index 000000000000..48f9e7d29423 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/dac/adi,ltc2688.yaml @@ -0,0 +1,146 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/dac/adi,ltc2688.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Analog Devices LTC2688 DAC + +maintainers: + - Nuno Sá <nuno.sa@analog.com> + +description: | + Analog Devices LTC2688 16 channel, 16 bit, +-15V DAC + https://www.analog.com/media/en/technical-documentation/data-sheets/ltc2688.pdf + +properties: + compatible: + enum: + - adi,ltc2688 + + reg: + maxItems: 1 + + vcc-supply: + description: Analog Supply Voltage Input. + + iovcc-supply: + description: Digital Input/Output Supply Voltage. + + vref-supply: + description: + Reference Input/Output. The voltage at the REF pin sets the full-scale + range of all channels. If not provided the internal reference is used and + also provided on the VREF pin". + + clr-gpios: + description: + If specified, it will be asserted during driver probe. As the line is + active low, it should be marked GPIO_ACTIVE_LOW. + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + "^channel@([0-9]|1[0-5])$": + type: object + + properties: + reg: + description: The channel number representing the DAC output channel. + maximum: 15 + + adi,toggle-mode: + description: + Set the channel as a toggle enabled channel. Toggle operation enables + fast switching of a DAC output between two different DAC codes without + any SPI transaction. + type: boolean + + adi,output-range-microvolt: + description: Specify the channel output full scale range. + oneOf: + - items: + - const: 0 + - enum: [5000000, 10000000] + - items: + - const: -5000000 + - const: 5000000 + - items: + - const: -10000000 + - const: 10000000 + - items: + - const: -15000000 + - const: 15000000 + + adi,overrange: + description: Enable 5% overrange over the selected full scale range. + type: boolean + + clocks: + maxItems: 1 + + adi,toggle-dither-input: + description: + Selects the TGPx pin to be associated with this channel. This setting + only makes sense for toggle or dither enabled channels. If + @adi,toggle-mode is not set and this property is given, the channel is + assumed to be a dither capable channel. Note that multiple channels + can be mapped to the same pin. If this setting is given, the + respective @clock must also be provided. Mappings between this and + input pins + 0 - TGP1 + 1 - TGP2 + 2 - TGP3 + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + dependencies: + adi,toggle-dither-input: [ clocks ] + + required: + - reg + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + + spi { + #address-cells = <1>; + #size-cells = <0>; + ltc2688: ltc2688@0 { + compatible = "adi,ltc2688"; + reg = <0>; + + vcc-supply = <&vcc>; + iovcc-supply = <&vcc>; + vref-supply = <&vref>; + + #address-cells = <1>; + #size-cells = <0>; + channel@0 { + reg = <0>; + adi,toggle-mode; + adi,overrange; + }; + + channel@1 { + reg = <1>; + adi,output-range-microvolt = <0 10000000>; + + clocks = <&clock_tgp3>; + adi,toggle-dither-input = <2>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml new file mode 100644 index 000000000000..2716c1e8fe31 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv1014.yaml @@ -0,0 +1,134 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,admv1014.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV1014 Microwave Downconverter + +maintainers: + - Antoniu Miclaus <antoniu.miclaus@analog.com> + +description: | + Wideband, microwave downconverter optimized for point to point microwave + radio designs operating in the 24 GHz to 44 GHz frequency range. + + https://www.analog.com/en/products/admv1014.html + +properties: + compatible: + enum: + - adi,admv1014 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: lo_in + description: + External clock that provides the Local Oscilator input. + + vcm-supply: + description: + Common-mode voltage regulator. + + vcc-if-bb-supply: + description: + BB and IF supply voltage regulator. + + vcc-vga-supply: + description: + RF Amplifier supply voltage regulator. + + vcc-vva-supply: + description: + VVA Control Circuit supply voltage regulator. + + vcc-lna-3p3-supply: + description: + Low Noise Amplifier 3.3V supply voltage regulator. + + vcc-lna-1p5-supply: + description: + Low Noise Amplifier 1.5V supply voltage regulator. + + vcc-bg-supply: + description: + Band Gap Circuit supply voltage regulator. + + vcc-quad-supply: + description: + Quadruple supply voltage regulator. + + vcc-mixer-supply: + description: + Mixer supply voltage regulator. + + adi,input-mode: + description: + Select the input mode. + iq - in-phase quadrature (I/Q) input + if - complex intermediate frequency (IF) input + enum: [iq, if] + + adi,detector-enable: + description: + Digital Rx Detector Enable. The Square Law Detector output is + available at output pin VDET. + type: boolean + + adi,p1db-compensation-enable: + description: + Turn on bits to optimize P1dB. + type: boolean + + adi,quad-se-mode: + description: + Switch the LO path from differential to single-ended operation. + se-neg - Single-Ended Mode, Negative Side Disabled. + se-pos - Single-Ended Mode, Positive Side Disabled. + diff - Differential Mode. + enum: [se-neg, se-pos, diff] + +required: + - compatible + - reg + - clocks + - clock-names + - vcm-supply + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + converter@0 { + compatible = "adi,admv1014"; + reg = <0>; + spi-max-frequency = <1000000>; + clocks = <&admv1014_lo>; + clock-names = "lo_in"; + vcm-supply = <&vcm>; + vcc-if-bb-supply = <&vcc_if_bb>; + vcc-vga-supply = <&vcc_vga>; + vcc-vva-supply = <&vcc_vva>; + vcc-lna-3p3-supply = <&vcc_lna_3p3>; + vcc-lna-1p5-supply = <&vcc_lna_1p5>; + vcc-bg-supply = <&vcc_bg>; + vcc-quad-supply = <&vcc_quad>; + vcc-mixer-supply = <&vcc_mixer>; + adi,quad-se-mode = "diff"; + adi,detector-enable; + adi,p1db-compensation-enable; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml new file mode 100644 index 000000000000..da7fe85ec92e --- /dev/null +++ b/Documentation/devicetree/bindings/iio/frequency/adi,admv4420.yaml @@ -0,0 +1,55 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/frequency/adi,admv4420.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ADMV4420 K Band Downconverter + +maintainers: + - Cristian Pop <cristian.pop@analog.com> + +description: + The ADMV4420 is a highly integrated, double balanced, active + mixer with an integrated fractional-N synthesizer, ideally suited + for next generation K band satellite communications + +properties: + compatible: + enum: + - adi,admv4420 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 1000000 + + adi,lo-freq-khz: + description: LO Frequency + $ref: /schemas/types.yaml#/definitions/uint32 + + adi,ref-ext-single-ended-en: + description: External reference selected. + type: boolean + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + spi { + #address-cells = <1>; + #size-cells = <0>; + mixer@0 { + compatible = "adi,admv4420"; + reg = <0>; + spi-max-frequency = <1000000>; + adi,lo-freq-khz = <16750000>; + adi,ref-ext-single-ended-en; + }; + }; +... diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml new file mode 100644 index 000000000000..b8a6ee16854f --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9324.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/semtech,sx9324.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Semtech's SX9324 capacitive proximity sensor + +maintainers: + - Gwendal Grignou <gwendal@chromium.org> + - Daniel Campello <campello@chromium.org> + +description: | + Semtech's SX9324 proximity sensor. + +properties: + compatible: + const: semtech,sx9324 + + reg: + maxItems: 1 + + interrupts: + description: + Generated by device to announce preceding read request has finished + and data is available or that a close/far proximity event has happened. + maxItems: 1 + + vdd-supply: + description: Main power supply + + svdd-supply: + description: Host interface power supply + + "#io-channel-cells": + const: 1 + + semtech,ph0-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Array of 3 entries. Index represent the id of the CS pin. + Value indicates how each CS pin is used during phase 0. + Each of the 3 pins have the following value - + 0 : unused (high impedance) + 1 : measured input + 2 : dynamic shield + 3 : grounded. + For instance, CS0 measured, CS1 shield and CS2 ground is [1, 2, 3] + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph1-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 1. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph2-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 2. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + semtech,ph3-pin: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: Same as ph0-pin for phase 3. + items: + enum: [ 0, 1, 2, 3 ] + minItems: 3 + maxItems: 3 + + + semtech,ph01-resolution: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For phase 0 and 1. + Higher the number, higher the resolution. + default: 128 + + semtech,ph23-resolution: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For phase 2 and 3 + default: 128 + + semtech,startup-sensor: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + description: | + Phase used for start-up proximity detection. + It is used when we enable a phase to remove static offset and measure + only capacitance changes introduced by the user. + + semtech,ph01-proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + PROXRAW filter strength for phase 0 and 1. A value of 0 represents off, + and other values represent 1-1/2^N. + + semtech,ph23-proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + Same as proxraw-strength01, for phase 2 and 3. + + semtech,avg-pos-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] + default: 16 + description: | + Average positive filter strength. A value of 0 represents off and + UINT_MAX (4294967295) represents infinite. Other values + represent 1-1/N. + +required: + - compatible + - reg + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@28 { + compatible = "semtech,sx9324"; + reg = <0x28>; + interrupt-parent = <&pio>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW 5>; + vdd-supply = <&pp3300_a>; + svdd-supply = <&pp1800_prox>; + #io-channel-cells = <1>; + semtech,ph0-pin = <1 2 3>; + semtech,ph1-pin = <3 2 1>; + semtech,ph2-pin = <1 2 3>; + semtech,ph3-pin = <3 2 1>; + semtech,ph01-resolution = <256>; + semtech,ph23-resolution = <256>; + semtech,startup-sensor = <1>; + semtech,ph01-proxraw-strength = <2>; + semtech,ph23-proxraw-strength = <2>; + semtech,avg-pos-strength = <64>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml new file mode 100644 index 000000000000..63e1a1fd00d4 --- /dev/null +++ b/Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml @@ -0,0 +1,89 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/iio/proximity/semtech,sx9360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Semtech's SX9360 capacitive proximity sensor + +maintainers: + - Gwendal Grignou <gwendal@chromium.org> + - Daniel Campello <campello@chromium.org> + +description: | + Semtech's SX9360 proximity sensor. + +properties: + compatible: + const: semtech,sx9360 + + reg: + maxItems: 1 + + interrupts: + description: + Generated by device to announce preceding read request has finished + and data is available or that a close/far proximity event has happened. + maxItems: 1 + + vdd-supply: + description: Main power supply + + svdd-supply: + description: Host interface power supply + + "#io-channel-cells": + const: 1 + + semtech,resolution: + $ref: /schemas/types.yaml#/definitions/uint32-array + enum: [8, 16, 32, 64, 128, 256, 512, 1024] + description: + Capacitance measurement resolution. For both phases, "reference" and + "measurement". Higher the number, higher the resolution. + default: 128 + + semtech,proxraw-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 7 + default: 1 + description: + PROXRAW filter strength for both phases. A value of 0 represents off, + and other values represent 1-1/2^N. + + semtech,avg-pos-strength: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 16, 64, 128, 256, 512, 1024, 4294967295] + default: 16 + description: | + Average positive filter strength. A value of 0 represents off and + UINT_MAX (4294967295) represents infinite. Other values + represent 1-1/N. + +required: + - compatible + - reg + - "#io-channel-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + proximity@28 { + compatible = "semtech,sx9360"; + reg = <0x28>; + interrupt-parent = <&pio>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW 5>; + vdd-supply = <&pp3300_a>; + svdd-supply = <&pp1800_prox>; + #io-channel-cells = <1>; + semtech,resolution = <256>; + semtech,proxraw-strength = <2>; + semtech,avg-pos-strength = <64>; + }; + }; diff --git a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml index 71de5631ebae..9735a2048255 100644 --- a/Documentation/devicetree/bindings/iio/st,st-sensors.yaml +++ b/Documentation/devicetree/bindings/iio/st,st-sensors.yaml @@ -46,6 +46,9 @@ properties: - st,lsm330d-accel - st,lsm330dl-accel - st,lsm330dlc-accel + - description: Silan Accelerometers + enum: + - silan,sc7a20 - description: STMicroelectronics Gyroscopes enum: - st,l3g4200d-gyro diff --git a/Documentation/devicetree/bindings/input/adc-joystick.yaml b/Documentation/devicetree/bindings/input/adc-joystick.yaml index 721878d5b7af..2ee04e03bc22 100644 --- a/Documentation/devicetree/bindings/input/adc-joystick.yaml +++ b/Documentation/devicetree/bindings/input/adc-joystick.yaml @@ -61,11 +61,10 @@ patternProperties: description: EV_ABS specific event code generated by the axis. abs-range: - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - items: - - description: minimum value - - description: maximum value + $ref: /schemas/types.yaml#/definitions/uint32-array + items: + - description: minimum value + - description: maximum value description: > Minimum and maximum values produced by the axis. For an ABS_X axis this will be the left-most and right-most diff --git a/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml new file mode 100644 index 000000000000..b1770640f94b --- /dev/null +++ b/Documentation/devicetree/bindings/input/mediatek,mt6779-keypad.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/mediatek,mt6779-keypad.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek's Keypad Controller device tree bindings + +maintainers: + - Fengping Yu <fengping.yu@mediatek.com> + +allOf: + - $ref: "/schemas/input/matrix-keymap.yaml#" + +description: | + Mediatek's Keypad controller is used to interface a SoC with a matrix-type + keypad device. The keypad controller supports multiple row and column lines. + A key can be placed at each intersection of a unique row and a unique column. + The keypad controller can sense a key-press and key-release and report the + event using a interrupt to the cpu. + +properties: + compatible: + oneOf: + - const: mediatek,mt6779-keypad + - items: + - enum: + - mediatek,mt6873-keypad + - const: mediatek,mt6779-keypad + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: kpd + + wakeup-source: + description: use any event on keypad as wakeup event + type: boolean + + debounce-delay-ms: + maximum: 256 + default: 16 + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/input/input.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + keyboard@10010000 { + compatible = "mediatek,mt6779-keypad"; + reg = <0 0x10010000 0 0x1000>; + interrupts = <GIC_SPI 75 IRQ_TYPE_EDGE_FALLING>; + clocks = <&clk26m>; + clock-names = "kpd"; + }; + }; diff --git a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt index 535d92885372..9d00f2a8e13a 100644 --- a/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt +++ b/Documentation/devicetree/bindings/input/mtk-pmic-keys.txt @@ -9,7 +9,10 @@ For MT6397/MT6323 MFD bindings see: Documentation/devicetree/bindings/mfd/mt6397.txt Required properties: -- compatible: "mediatek,mt6397-keys" or "mediatek,mt6323-keys" +- compatible: Should be one of: + - "mediatek,mt6397-keys" + - "mediatek,mt6323-keys" + - "mediatek,mt6358-keys" - linux,keycodes: See Documentation/devicetree/bindings/input/input.yaml Optional Properties: diff --git a/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml new file mode 100644 index 000000000000..e3a2b871e50c --- /dev/null +++ b/Documentation/devicetree/bindings/input/touchscreen/imagis,ist3038c.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/input/touchscreen/imagis,ist3038c.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Imagis IST30XXC family touchscreen controller bindings + +maintainers: + - Markuss Broks <markuss.broks@gmail.com> + +allOf: + - $ref: touchscreen.yaml# + +properties: + $nodename: + pattern: "^touchscreen@[0-9a-f]+$" + + compatible: + enum: + - imagis,ist3038c + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vdd-supply: + description: Power supply regulator for the chip + + vddio-supply: + description: Power supply regulator for the I2C bus + + 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 + +additionalProperties: false + +required: + - compatible + - reg + - interrupts + - touchscreen-size-x + - touchscreen-size-y + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + touchscreen@50 { + compatible = "imagis,ist3038c"; + reg = <0x50>; + interrupt-parent = <&gpio>; + interrupts = <13 IRQ_TYPE_EDGE_FALLING>; + vdd-supply = <&ldo1_reg>; + vddio-supply = <&ldo2_reg>; + touchscreen-size-x = <720>; + touchscreen-size-y = <1280>; + touchscreen-fuzz-x = <10>; + touchscreen-fuzz-y = <10>; + touchscreen-inverted-x; + touchscreen-inverted-y; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml index e4c3c2818119..89853b482513 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpm.yaml @@ -26,7 +26,6 @@ properties: - qcom,msm8939-bimc - qcom,msm8939-pcnoc - qcom,msm8939-snoc - - qcom,msm8939-snoc-mm - qcom,msm8996-a0noc - qcom,msm8996-a1noc - qcom,msm8996-a2noc @@ -80,7 +79,6 @@ allOf: - qcom,msm8939-bimc - qcom,msm8939-pcnoc - qcom,msm8939-snoc - - qcom,msm8939-snoc-mm - qcom,msm8996-a1noc - qcom,msm8996-a2noc - qcom,msm8996-bimc @@ -107,6 +105,37 @@ allOf: - description: Bus Clock - description: Bus A Clock + # Child node's properties + patternProperties: + '^interconnect-[a-z0-9]+$': + type: object + description: + snoc-mm is a child of snoc, sharing snoc's register address space. + + properties: + compatible: + enum: + - qcom,msm8939-snoc-mm + + '#interconnect-cells': + const: 1 + + clock-names: + items: + - const: bus + - const: bus_a + + clocks: + items: + - description: Bus Clock + - description: Bus A Clock + + required: + - compatible + - '#interconnect-cells' + - clock-names + - clocks + - if: properties: compatible: diff --git a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml index cbb24f9bb609..5a911be0c2ea 100644 --- a/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml +++ b/Documentation/devicetree/bindings/interconnect/qcom,rpmh.yaml @@ -121,6 +121,8 @@ properties: qcom,bcm-voters: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | List of phandles to qcom,bcm-voter nodes that are required by this interconnect to send RPMh commands. diff --git a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt index 23b18b92c558..bde63f8f090e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt +++ b/Documentation/devicetree/bindings/interrupt-controller/amlogic,meson-gpio-intc.txt @@ -18,6 +18,7 @@ Required properties: "amlogic,meson-g12a-gpio-intc" for G12A SoCs (S905D2, S905X2, S905Y2) "amlogic,meson-sm1-gpio-intc" for SM1 SoCs (S905D3, S905X3, S905Y3) "amlogic,meson-a1-gpio-intc" for A1 SoCs (A113L) + "amlogic,meson-s4-gpio-intc" for S4 SoCs (S802X2, S905Y4, S805X2G, S905W2) - reg : Specifies base physical address and size of the registers. - interrupt-controller : Identifies the node as an interrupt controller. - #interrupt-cells : Specifies the number of cells needed to encode an diff --git a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt b/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt deleted file mode 100644 index f4b4193d830e..000000000000 --- a/Documentation/devicetree/bindings/interrupt-controller/andestech,ativic32.txt +++ /dev/null @@ -1,19 +0,0 @@ -* Andestech Internal Vector Interrupt Controller - -The Internal Vector Interrupt Controller (IVIC) is a basic interrupt controller -suitable for a simpler SoC platform not requiring a more sophisticated and -bigger External Vector Interrupt Controller. - - -Main node required properties: - -- compatible : should at least contain "andestech,ativic32". -- interrupt-controller : Identifies the node as an interrupt controller -- #interrupt-cells: 1 cells and refer to interrupt-controller/interrupts - -Examples: - intc: interrupt-controller { - compatible = "andestech,ativic32"; - #interrupt-cells = <1>; - interrupt-controller; - }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml index 97359024709a..85c85b694217 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic.yaml @@ -56,6 +56,8 @@ properties: - 1: virtual HV timer - 2: physical guest timer - 3: virtual guest timer + - 4: 'efficient' CPU PMU + - 5: 'performance' CPU PMU The 3rd cell contains the interrupt flags. This is normally IRQ_TYPE_LEVEL_HIGH (4). @@ -68,6 +70,35 @@ properties: power-domains: maxItems: 1 + affinities: + type: object + additionalProperties: false + description: + FIQ affinity can be expressed as a single "affinities" node, + containing a set of sub-nodes, one per FIQ with a non-default + affinity. + patternProperties: + "^.+-affinity$": + type: object + additionalProperties: false + properties: + apple,fiq-index: + description: + The interrupt number specified as a FIQ, and for which + the affinity is not the default. + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 5 + + cpus: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: + Should be a list of phandles to CPU nodes (as described in + Documentation/devicetree/bindings/arm/cpus.yaml). + + required: + - fiq-index + - cpus + required: - compatible - '#interrupt-cells' diff --git a/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml new file mode 100644 index 000000000000..47a78a167aba --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/apple,aic2.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/apple,aic2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Apple Interrupt Controller 2 + +maintainers: + - Hector Martin <marcan@marcan.st> + +description: | + The Apple Interrupt Controller 2 is a simple interrupt controller present on + Apple ARM SoC platforms starting with t600x (M1 Pro and Max). + + It provides the following features: + + - Level-triggered hardware IRQs wired to SoC blocks + - Single mask bit per IRQ + - Automatic masking on event delivery (auto-ack) + - Software triggering (ORed with hw line) + - Automatic prioritization (single event/ack register per CPU, lower IRQs = + higher priority) + - Automatic masking on ack + - Support for multiple dies + + This device also represents the FIQ interrupt sources on platforms using AIC, + which do not go through a discrete interrupt controller. It also handles + FIQ-based Fast IPIs. + +properties: + compatible: + items: + - const: apple,t6000-aic + - const: apple,aic2 + + interrupt-controller: true + + '#interrupt-cells': + const: 4 + description: | + The 1st cell contains the interrupt type: + - 0: Hardware IRQ + - 1: FIQ + + The 2nd cell contains the die ID. + + The next cell contains the interrupt number. + - HW IRQs: interrupt number + - FIQs: + - 0: physical HV timer + - 1: virtual HV timer + - 2: physical guest timer + - 3: virtual guest timer + + The last cell contains the interrupt flags. This is normally + IRQ_TYPE_LEVEL_HIGH (4). + + reg: + items: + - description: Address and size of the main AIC2 registers. + - description: Address and size of the AIC2 Event register. + + reg-names: + items: + - const: core + - const: event + + power-domains: + maxItems: 1 + +required: + - compatible + - '#interrupt-cells' + - interrupt-controller + - reg + - reg-names + +additionalProperties: false + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + aic: interrupt-controller@28e100000 { + compatible = "apple,t6000-aic", "apple,aic2"; + #interrupt-cells = <4>; + interrupt-controller; + reg = <0x2 0x8e100000 0x0 0xc000>, + <0x2 0x8e10c000 0x0 0x4>; + reg-names = "core", "event"; + }; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml index cfb3ec27bd2b..b7197f78e158 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic-v3.yaml @@ -138,6 +138,8 @@ properties: properties: affinity: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Should be a list of phandles to CPU nodes (as described in Documentation/devicetree/bindings/arm/cpus.yaml). @@ -273,11 +275,11 @@ examples: ppi-partitions { part0: interrupt-partition-0 { - affinity = <&cpu0 &cpu2>; + affinity = <&cpu0>, <&cpu2>; }; part1: interrupt-partition-1 { - affinity = <&cpu1 &cpu3>; + affinity = <&cpu1>, <&cpu3>; }; }; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml index ba282f4c9fd0..62219a5c21c5 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/arm,gic.yaml @@ -58,6 +58,7 @@ properties: - enum: - nvidia,tegra186-agic - nvidia,tegra194-agic + - nvidia,tegra234-agic - const: nvidia,tegra210-agic interrupt-controller: true diff --git a/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml new file mode 100644 index 000000000000..509d20c091af --- /dev/null +++ b/Documentation/devicetree/bindings/interrupt-controller/qcom,mpm.yaml @@ -0,0 +1,96 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/interrupt-controller/qcom,mpm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcom MPM Interrupt Controller + +maintainers: + - Shawn Guo <shawn.guo@linaro.org> + +description: + Qualcomm Technologies Inc. SoCs based on the RPM architecture have a + MSM Power Manager (MPM) that is in always-on domain. In addition to managing + resources during sleep, the hardware also has an interrupt controller that + monitors the interrupts when the system is asleep, wakes up the APSS when + one of these interrupts occur and replays it to GIC interrupt controller + after GIC becomes operational. + +allOf: + - $ref: /schemas/interrupt-controller.yaml# + +properties: + compatible: + items: + - const: qcom,mpm + + reg: + maxItems: 1 + description: + Specifies the base address and size of vMPM registers in RPM MSG RAM. + + interrupts: + maxItems: 1 + description: + Specify the IRQ used by RPM to wakeup APSS. + + mboxes: + maxItems: 1 + description: + Specify the mailbox used to notify RPM for writing vMPM registers. + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + description: + The first cell is the MPM pin number for the interrupt, and the second + is the trigger type. + + qcom,mpm-pin-count: + description: + Specify the total MPM pin count that a SoC supports. + $ref: /schemas/types.yaml#/definitions/uint32 + + qcom,mpm-pin-map: + description: + A set of MPM pin numbers and the corresponding GIC SPIs. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: MPM pin number + - description: GIC SPI number for the MPM pin + +required: + - compatible + - reg + - interrupts + - mboxes + - interrupt-controller + - '#interrupt-cells' + - qcom,mpm-pin-count + - qcom,mpm-pin-map + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + mpm: interrupt-controller@45f01b8 { + compatible = "qcom,mpm"; + interrupts = <GIC_SPI 197 IRQ_TYPE_EDGE_RISING>; + reg = <0x45f01b8 0x1000>; + mboxes = <&apcs_glb 1>; + interrupt-controller; + #interrupt-cells = <2>; + interrupt-parent = <&intc>; + qcom,mpm-pin-count = <96>; + qcom,mpm-pin-map = <2 275>, + <5 296>, + <12 422>, + <24 79>, + <86 183>, + <90 260>, + <91 260>; + }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml index 79d0358e2f61..620f01775e42 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/renesas,irqc.yaml @@ -36,6 +36,7 @@ properties: - renesas,intc-ex-r8a77980 # R-Car V3H - renesas,intc-ex-r8a77990 # R-Car E3 - renesas,intc-ex-r8a77995 # R-Car D3 + - renesas,intc-ex-r8a779a0 # R-Car V3U - const: renesas,irqc '#interrupt-cells': diff --git a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml index 28b6b17fe4b2..27092c6a86c4 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/sifive,plic-1.0.0.yaml @@ -35,6 +35,10 @@ description: contains a specific memory layout, which is documented in chapter 8 of the SiFive U5 Coreplex Series Manual <https://static.dev.sifive.com/U54-MC-RVCoreIP.pdf>. + The thead,c900-plic is different from sifive,plic-1.0.0 in opensbi, the + T-HEAD PLIC implementation requires setting a delegation bit to allow access + from S-mode. So add thead,c900-plic to distinguish them. + maintainers: - Sagar Kadam <sagar.kadam@sifive.com> - Paul Walmsley <paul.walmsley@sifive.com> @@ -42,12 +46,17 @@ maintainers: properties: compatible: - items: - - enum: - - sifive,fu540-c000-plic - - starfive,jh7100-plic - - canaan,k210-plic - - const: sifive,plic-1.0.0 + oneOf: + - items: + - enum: + - sifive,fu540-c000-plic + - starfive,jh7100-plic + - canaan,k210-plic + - const: sifive,plic-1.0.0 + - items: + - enum: + - allwinner,sun20i-d1-plic + - const: thead,c900-plic reg: maxItems: 1 @@ -62,6 +71,7 @@ properties: interrupts-extended: minItems: 1 + maxItems: 15872 description: Specifies which contexts are connected to the PLIC, with "-1" specifying that a context is not present. Each node pointed to should be a @@ -90,12 +100,11 @@ examples: #interrupt-cells = <1>; compatible = "sifive,fu540-c000-plic", "sifive,plic-1.0.0"; interrupt-controller; - interrupts-extended = < - &cpu0_intc 11 - &cpu1_intc 11 &cpu1_intc 9 - &cpu2_intc 11 &cpu2_intc 9 - &cpu3_intc 11 &cpu3_intc 9 - &cpu4_intc 11 &cpu4_intc 9>; + interrupts-extended = <&cpu0_intc 11>, + <&cpu1_intc 11>, <&cpu1_intc 9>, + <&cpu2_intc 11>, <&cpu2_intc 9>, + <&cpu3_intc 11>, <&cpu3_intc 9>, + <&cpu4_intc 11>, <&cpu4_intc 9>; reg = <0xc000000 0x4000000>; riscv,ndev = <10>; }; diff --git a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml index d19c881b4abc..e44daa09b137 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/st,stm32-exti.yaml @@ -20,6 +20,7 @@ properties: - items: - enum: - st,stm32mp1-exti + - st,stm32mp13-exti - const: syscon "#interrupt-cells": diff --git a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml index 3d89668573e8..88c46e61732e 100644 --- a/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml +++ b/Documentation/devicetree/bindings/interrupt-controller/ti,sci-inta.yaml @@ -77,6 +77,8 @@ properties: ti,unmapped-event-sources: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Array of phandles to DMA controllers where the unmapped events originate. diff --git a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml index 0f26fe14c8e2..97e8c471a5e8 100644 --- a/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml +++ b/Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml @@ -101,6 +101,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 32 + items: + maxItems: 1 description: | List of phandle to the local arbiters in the current Socs. Refer to bindings/memory-controllers/mediatek,smi-larb.yaml. It must sort @@ -167,8 +169,8 @@ examples: interrupts = <GIC_SPI 139 IRQ_TYPE_LEVEL_LOW>; clocks = <&infracfg CLK_INFRA_M4U>; clock-names = "bclk"; - mediatek,larbs = <&larb0 &larb1 &larb2 - &larb3 &larb4 &larb5>; + mediatek,larbs = <&larb0>, <&larb1>, <&larb2>, + <&larb3>, <&larb4>, <&larb5>; #iommu-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml index ce0c715205c6..8854569ca3a6 100644 --- a/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml +++ b/Documentation/devicetree/bindings/iommu/renesas,ipmmu-vmsa.yaml @@ -44,6 +44,10 @@ properties: - renesas,ipmmu-r8a77990 # R-Car E3 - renesas,ipmmu-r8a77995 # R-Car D3 - renesas,ipmmu-r8a779a0 # R-Car V3U + - items: + - enum: + - renesas,ipmmu-r8a779f0 # R-Car S4-8 + - const: renesas,rcar-gen4-ipmmu-vmsa # R-Car Gen4 reg: maxItems: 1 @@ -66,6 +70,12 @@ properties: renesas,ipmmu-main: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to main IPMMU + - description: the interrupt bit number associated with the particular + cache IPMMU device. The interrupt bit number needs to match the main + IPMMU IMSSTR register. Only used by cache IPMMU instances. description: Reference to the main IPMMU phandle plus 1 cell. The cell is the interrupt bit number associated with the particular cache IPMMU diff --git a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml index 93d8f8e88cf5..71bc031c4fde 100644 --- a/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml +++ b/Documentation/devicetree/bindings/ipmi/ipmi-ipmb.yaml @@ -36,6 +36,14 @@ properties: $ref: /schemas/types.yaml#/definitions/uint32 description: Number of retries before a failure is declared. Defaults to 1. + slave-dev: + $ref: /schemas/types.yaml#/definitions/phandle + description: | + The slave i2c device. If not present, the main device is used. This + lets you use two devices on the IPMB, one for master and one for slave, + in case you have a slave device that can only be a slave. The slave + will receive messages and the master will transmit. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml index 625082bf3892..f5822f4ea667 100644 --- a/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/led-backlight.yaml @@ -23,6 +23,8 @@ properties: leds: description: A list of LED nodes $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 brightness-levels: description: diff --git a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml index d839e75d9788..1c24b333c6e2 100644 --- a/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml +++ b/Documentation/devicetree/bindings/leds/backlight/qcom-wled.yaml @@ -22,6 +22,7 @@ properties: - qcom,pmi8994-wled - qcom,pmi8998-wled - qcom,pm660l-wled + - qcom,pm6150l-wled - qcom,pm8150l-wled reg: diff --git a/Documentation/devicetree/bindings/leds/common.yaml b/Documentation/devicetree/bindings/leds/common.yaml index 697102707703..328952d7acbb 100644 --- a/Documentation/devicetree/bindings/leds/common.yaml +++ b/Documentation/devicetree/bindings/leds/common.yaml @@ -185,9 +185,11 @@ examples: }; }; - led-controller@0 { + - | + #include <dt-bindings/leds/common.h> + + led-controller { compatible = "maxim,max77693-led"; - reg = <0 0x100>; led { function = LED_FUNCTION_FLASH; @@ -199,6 +201,9 @@ examples: }; }; + - | + #include <dt-bindings/leds/common.h> + i2c { #address-cells = <1>; #size-cells = <0>; diff --git a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml index c7ed2871da06..9362b1ef9e88 100644 --- a/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml +++ b/Documentation/devicetree/bindings/leds/cznic,turris-omnia-leds.yaml @@ -32,8 +32,7 @@ properties: patternProperties: "^multi-led@[0-9a-b]$": type: object - allOf: - - $ref: leds-class-multicolor.yaml# + $ref: leds-class-multicolor.yaml# description: This node represents one of the RGB LED devices on Turris Omnia. No subnodes need to be added for subchannels since this controller only diff --git a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml index c192b5feadc7..f12fe5b53f30 100644 --- a/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml +++ b/Documentation/devicetree/bindings/leds/leds-lp50xx.yaml @@ -55,8 +55,7 @@ properties: patternProperties: '^multi-led@[0-9a-f]$': type: object - allOf: - - $ref: leds-class-multicolor.yaml# + $ref: leds-class-multicolor.yaml# properties: reg: minItems: 1 diff --git a/Documentation/devicetree/bindings/leds/maxim,max77693.yaml b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml new file mode 100644 index 000000000000..86a0005cf156 --- /dev/null +++ b/Documentation/devicetree/bindings/leds/maxim,max77693.yaml @@ -0,0 +1,105 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/leds/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC LEDs + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + There are two LED outputs available - FLED1 and FLED2. Each of them can + control a separate LED or they can be connected together to double the + maximum current for a single connected LED. One LED is represented by one + child node. + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77693-led + + maxim,boost-mode: + description: + In boost mode the device can produce up to 1.2A of total current on both + outputs. The maximum current on each output is reduced to 625mA then. If + not enabled explicitly, boost setting defaults to LEDS_BOOST_FIXED in + case both current sources are used. + See LEDS_BOOST_* in include/dt-bindings/leds/common.h. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2] + + maxim,boost-mvout: + description: | + Output voltage of the boost module in millivolts. + Valid values: 3300 - 5500, step by 25 (rounded down) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 3300 + maximum: 5500 + default: 3300 + + maxim,mvsys-min: + description: | + Low input voltage level in millivolts. Flash is not fired if chip + estimates that system voltage could drop below this level due to flash + power consumption. + Valid values: 2400 - 3400, step by 33 (rounded down) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 2400 + maximum: 3400 + default: 2400 + +patternProperties: + "^([a-z]+-)?led[01]?$": + type: object + $ref: common.yaml# + unevaluatedProperties: false + + properties: + led-sources: + allOf: + - minItems: 1 + maxItems: 2 + items: + minimum: 0 + maximum: 1 + + led-max-microamp: + description: | + Valid values for a LED connected to one FLED output: + 15625 - 250000, step by 15625 (rounded down) + Valid values for a LED connected to both FLED outputs: + 15625 - 500000, step by 15625 (rounded down) + + flash-max-microamp: + description: | + Valid values for a single LED connected to one FLED output + (boost mode must be turned off): + 15625 - 1000000, step by 15625 (rounded down) + Valid values for a single LED connected to both FLED outputs: + 15625 - 1250000, step by 15625 (rounded down) + Valid values for two LEDs case: + 15625 - 625000, step by 15625 (rounded down) + + flash-max-timeout-us: + description: | + Valid values: 62500 - 1000000, step by 62500 (rounded down) + minimum: 62500 + maximum: 1000000 + + required: + - flash-max-microamp + - flash-max-timeout-us + - led-max-microamp + - led-sources + +required: + - compatible + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml index a337bcd80c4a..7a86e7926dd2 100644 --- a/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml +++ b/Documentation/devicetree/bindings/mailbox/fsl,mu.yaml @@ -28,8 +28,13 @@ properties: - const: fsl,imx7ulp-mu - const: fsl,imx8ulp-mu - const: fsl,imx8-mu-scu + - const: fsl,imx8-mu-seco + - const: fsl,imx93-mu-s4 - const: fsl,imx8ulp-mu-s4 - items: + - const: fsl,imx93-mu + - const: fsl,imx8ulp-mu + - items: - enum: - fsl,imx7s-mu - fsl,imx8mq-mu @@ -51,7 +56,14 @@ properties: maxItems: 1 interrupts: - maxItems: 1 + minItems: 1 + maxItems: 2 + + interrupt-names: + minItems: 1 + items: + - const: tx + - const: rx "#mbox-cells": description: | @@ -86,6 +98,27 @@ required: - interrupts - "#mbox-cells" +allOf: + - if: + properties: + compatible: + enum: + - fsl,imx93-mu-s4 + then: + properties: + interrupt-names: + minItems: 2 + interrupts: + minItems: 2 + + else: + properties: + interrupts: + maxItems: 1 + not: + required: + - interrupt-names + additionalProperties: false examples: diff --git a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml index bbb173ea483c..082d397d3e89 100644 --- a/Documentation/devicetree/bindings/mailbox/microchip,polarfire-soc-mailbox.yaml +++ b/Documentation/devicetree/bindings/mailbox/microchip,mpfs-mailbox.yaml @@ -1,7 +1,7 @@ # 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#" +$id: "http://devicetree.org/schemas/mailbox/microchip,mpfs-mailbox.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Microchip PolarFire SoC (MPFS) MSS (microprocessor subsystem) mailbox controller @@ -11,7 +11,7 @@ maintainers: properties: compatible: - const: microchip,polarfire-soc-mailbox + const: microchip,mpfs-mailbox reg: items: @@ -38,7 +38,7 @@ examples: #address-cells = <2>; #size-cells = <2>; mbox: mailbox@37020000 { - compatible = "microchip,polarfire-soc-mailbox"; + compatible = "microchip,mpfs-mailbox"; reg = <0x0 0x37020000 0x0 0x1000>, <0x0 0x2000318c 0x0 0x40>; interrupt-parent = <&L1>; interrupts = <96>; diff --git a/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml new file mode 100644 index 000000000000..fe454a1fba17 --- /dev/null +++ b/Documentation/devicetree/bindings/mailbox/mtk,adsp-mbox.yaml @@ -0,0 +1,50 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mailbox/mtk,adsp-mbox.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek ADSP mailbox + +maintainers: + - Allen-KH Cheng <Allen-KH.Cheng@mediatek.com> + +description: | + The MTK ADSP mailbox Inter-Processor Communication (IPC) enables the SoC + to ommunicate with ADSP by passing messages through two mailbox channels. + The MTK ADSP mailbox IPC also provides the ability for one processor to + signal the other processor using interrupts. + +properties: + compatible: + items: + - const: mediatek,mt8195-adsp-mbox + + "#mbox-cells": + const: 0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - "#mbox-cells" + - reg + - interrupts + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + adsp_mailbox0:mailbox@10816000 { + compatible = "mediatek,mt8195-adsp-mbox"; + #mbox-cells = <0>; + reg = <0x10816000 0x1000>; + interrupts = <GIC_SPI 702 IRQ_TYPE_LEVEL_HIGH 0>; + }; diff --git a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt index 98fe37e8b17b..c2aeba63bd47 100644 --- a/Documentation/devicetree/bindings/mailbox/mtk-gce.txt +++ b/Documentation/devicetree/bindings/mailbox/mtk-gce.txt @@ -10,7 +10,8 @@ mailbox.txt for generic information about mailbox device-tree bindings. Required properties: - compatible: can be "mediatek,mt8173-gce", "mediatek,mt8183-gce", - "mediatek,mt8192-gce", "mediatek,mt8195-gce" or "mediatek,mt6779-gce". + "mediatek,mt8186-gce", "mediatek,mt8192-gce", "mediatek,mt8195-gce" or + "mediatek,mt6779-gce". - reg: Address range of the GCE unit - interrupts: The interrupt signal from the GCE block - clock: Clocks according to the common clock binding @@ -40,8 +41,9 @@ Optional properties for a client mutex node: defined in 'dt-bindings/gce/<chip>-gce.h'. Some vaules of properties are defined in 'dt-bindings/gce/mt8173-gce.h', -'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8192-gce.h', -'dt-bindings/gce/mt8195-gce.h' or 'dt-bindings/gce/mt6779-gce.h'. +'dt-bindings/gce/mt8183-gce.h', 'dt-bindings/gce/mt8186-gce.h' +'dt-bindings/gce/mt8192-gce.h', 'dt-bindings/gce/mt8195-gce.h' or +'dt-bindings/gce/mt6779-gce.h'. Such as sub-system ids, thread priority, event ids. Example: diff --git a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml index 01e9d9155c83..3b5ba7ecc19d 100644 --- a/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml +++ b/Documentation/devicetree/bindings/mailbox/qcom,apcs-kpss-global.yaml @@ -21,6 +21,7 @@ properties: - qcom,msm8916-apcs-kpss-global - qcom,msm8939-apcs-kpss-global - qcom,msm8953-apcs-kpss-global + - qcom,msm8976-apcs-kpss-global - qcom,msm8994-apcs-kpss-global - qcom,msm8996-apcs-hmss-global - qcom,msm8998-apcs-hmss-global diff --git a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml index c3de96d10396..ee7fc3515d89 100644 --- a/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml +++ b/Documentation/devicetree/bindings/media/allwinner,sun4i-a10-video-engine.yaml @@ -48,6 +48,10 @@ properties: allwinner,sram: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to SRAM + - description: register value for device description: Phandle to the device SRAM iommus: diff --git a/Documentation/devicetree/bindings/media/amphion,vpu.yaml b/Documentation/devicetree/bindings/media/amphion,vpu.yaml new file mode 100644 index 000000000000..a9d80eaeeeb6 --- /dev/null +++ b/Documentation/devicetree/bindings/media/amphion,vpu.yaml @@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/amphion,vpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Amphion VPU codec IP + +maintainers: + - Ming Qian <ming.qian@nxp.com> + - Shijie Qin <shijie.qin@nxp.com> + +description: |- + The Amphion MXC video encoder(Windsor) and decoder(Malone) accelerators present + on NXP i.MX8Q SoCs. + +properties: + $nodename: + pattern: "^vpu@[0-9a-f]+$" + + compatible: + items: + - enum: + - nxp,imx8qm-vpu + - nxp,imx8qxp-vpu + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +patternProperties: + "^mailbox@[0-9a-f]+$": + description: + Each vpu encoder or decoder correspond a MU, which used for communication + between driver and firmware. Implement via mailbox on driver. + $ref: ../mailbox/fsl,mu.yaml# + + + "^vpu_core@[0-9a-f]+$": + description: + Each core correspond a decoder or encoder, need to configure them + separately. NXP i.MX8QM SoC has one decoder and two encoder, i.MX8QXP SoC + has one decoder and one encoder. + type: object + + properties: + compatible: + items: + - enum: + - nxp,imx8q-vpu-decoder + - nxp,imx8q-vpu-encoder + + reg: + maxItems: 1 + + power-domains: + maxItems: 1 + + mbox-names: + items: + - const: tx0 + - const: tx1 + - const: rx + + mboxes: + description: + List of phandle of 2 MU channels for tx, 1 MU channel for rx. + maxItems: 3 + + memory-region: + description: + Phandle to the reserved memory nodes to be associated with the + remoteproc device. The reserved memory nodes should be carveout nodes, + and should be defined as per the bindings in + Documentation/devicetree/bindings/reserved-memory/reserved-memory.txt + items: + - description: region reserved for firmware image sections. + - description: region used for RPC shared memory between firmware and + driver. + + required: + - compatible + - reg + - power-domains + - mbox-names + - mboxes + - memory-region + + additionalProperties: false + +required: + - compatible + - reg + - power-domains + +additionalProperties: false + +examples: + # Device node example for i.MX8QM platform: + - | + #include <dt-bindings/firmware/imx/rsrc.h> + + vpu: vpu@2c000000 { + compatible = "nxp,imx8qm-vpu"; + ranges = <0x2c000000 0x2c000000 0x2000000>; + reg = <0x2c000000 0x1000000>; + #address-cells = <1>; + #size-cells = <1>; + power-domains = <&pd IMX_SC_R_VPU>; + + mu_m0: mailbox@2d000000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d000000 0x20000>; + interrupts = <0 472 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_0>; + }; + + mu1_m0: mailbox@2d020000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d020000 0x20000>; + interrupts = <0 473 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_1>; + }; + + mu2_m0: mailbox@2d040000 { + compatible = "fsl,imx6sx-mu"; + reg = <0x2d040000 0x20000>; + interrupts = <0 474 4>; + #mbox-cells = <2>; + power-domains = <&pd IMX_SC_R_VPU_MU_2>; + }; + + vpu_core0: vpu_core@2d080000 { + compatible = "nxp,imx8q-vpu-decoder"; + reg = <0x2d080000 0x10000>; + power-domains = <&pd IMX_SC_R_VPU_DEC_0>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu_m0 0 0>, + <&mu_m0 0 1>, + <&mu_m0 1 0>; + memory-region = <&decoder_boot>, <&decoder_rpc>; + }; + + vpu_core1: vpu_core@2d090000 { + compatible = "nxp,imx8q-vpu-encoder"; + reg = <0x2d090000 0x10000>; + power-domains = <&pd IMX_SC_R_VPU_ENC_0>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu1_m0 0 0>, + <&mu1_m0 0 1>, + <&mu1_m0 1 0>; + memory-region = <&encoder1_boot>, <&encoder1_rpc>; + }; + + vpu_core2: vpu_core@2d0a0000 { + reg = <0x2d0a0000 0x10000>; + compatible = "nxp,imx8q-vpu-encoder"; + power-domains = <&pd IMX_SC_R_VPU_ENC_1>; + mbox-names = "tx0", "tx1", "rx"; + mboxes = <&mu2_m0 0 0>, + <&mu2_m0 0 1>, + <&mu2_m0 1 0>; + memory-region = <&encoder2_boot>, <&encoder2_rpc>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml index 85a8877c2f38..1e2df8cf2937 100644 --- a/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml +++ b/Documentation/devicetree/bindings/media/i2c/hynix,hi846.yaml @@ -49,7 +49,8 @@ properties: description: Definition of the regulator used for the VDDD power supply. port: - $ref: /schemas/graph.yaml#/properties/port + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false properties: endpoint: @@ -68,8 +69,11 @@ properties: - const: 1 - const: 2 + link-frequencies: true + required: - data-lanes + - link-frequencies required: - compatible diff --git a/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml b/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml new file mode 100644 index 000000000000..034a6e3466af --- /dev/null +++ b/Documentation/devicetree/bindings/media/i2c/isil,isl79987.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/i2c/isil,isl79987.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Intersil ISL79987 Analog to MIPI CSI-2 decoder + +maintainers: + - Michael Tretter <m.tretter@pengutronix.de> + - Marek Vasut <marex@denx.de> + +description: + The Intersil ISL79987 is an analog to MIPI CSI-2 decoder which is capable of + receiving up to four analog stream and multiplexing them into up to four MIPI + CSI-2 virtual channels, using one MIPI clock lane and 1/2 data lanes. + +properties: + compatible: + enum: + - isil,isl79987 + + reg: + maxItems: 1 + + reset-gpios: + maxItems: 1 + description: + A GPIO spec for the RSTB pin (active high) + + powerdown-gpios: + maxItems: 1 + description: + A GPIO spec for the Power Down pin (active high) + + ports: + $ref: /schemas/graph.yaml#/properties/ports + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: Output port + + properties: + endpoint: + $ref: /schemas/media/video-interfaces.yaml# + unevaluatedProperties: false + + properties: + data-lanes: + minItems: 1 + maxItems: 2 + + required: + - data-lanes + + patternProperties: + "^port@[1-4]$": + $ref: /schemas/graph.yaml#/properties/port + description: Input ports + + required: + - port@0 + +additionalProperties: false + +required: + - compatible + - reg + - ports + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + isl7998x_mipi@44 { + compatible = "isil,isl79987"; + reg = <0x44>; + powerdown-gpios = <&gpio3 27 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio3 28 GPIO_ACTIVE_HIGH>; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + isl79987_out: endpoint { + remote-endpoint = <&mipi_csi2_in>; + data-lanes = <1 2>; + }; + }; + + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&camera_0>; + }; + }; + + port@2 { + reg = <2>; + endpoint { + remote-endpoint = <&camera_1>; + }; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml index 02f656e78700..90315e217003 100644 --- a/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml +++ b/Documentation/devicetree/bindings/media/i2c/maxim,max9286.yaml @@ -70,6 +70,28 @@ properties: a remote serializer whose high-threshold noise immunity is not enabled is 100000 micro volts + maxim,gpio-poc: + $ref: '/schemas/types.yaml#/definitions/uint32-array' + minItems: 2 + maxItems: 2 + description: | + Index of the MAX9286 gpio output line (0 or 1) that controls Power over + Coax to the cameras and its associated polarity flag. + + The property accepts an array of two unsigned integers, the first being + the gpio line index (0 or 1) and the second being the gpio line polarity + flag (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW) as defined in + <include/dt-bindings/gpio/gpio.h>. + + When the remote cameras power is controlled by one of the MAX9286 gpio + lines, this property has to be used to specify which line among the two + available ones controls the remote camera power enablement. + + When this property is used it is not possible to register a gpio + controller as the gpio lines are controlled directly by the MAX9286 and + not available for consumers, nor the 'poc-supply' property should be + specified. + ports: $ref: /schemas/graph.yaml#/properties/ports @@ -165,7 +187,16 @@ required: - reg - ports - i2c-mux - - gpio-controller + +# If 'maxim,gpio-poc' is present, then 'poc-supply' and 'gpio-controller' +# are not allowed. +if: + required: + - maxim,gpio-poc +then: + properties: + poc-supply: false + gpio-controller: false additionalProperties: false @@ -174,140 +205,174 @@ examples: #include <dt-bindings/gpio/gpio.h> i2c@e66d8000 { - #address-cells = <1>; - #size-cells = <0>; + #address-cells = <1>; + #size-cells = <0>; - reg = <0 0xe66d8000>; + reg = <0 0xe66d8000>; - gmsl-deserializer@2c { - compatible = "maxim,max9286"; - reg = <0x2c>; - poc-supply = <&camera_poc_12v>; - enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>; + gmsl-deserializer@2c { + compatible = "maxim,max9286"; + reg = <0x2c>; + poc-supply = <&camera_poc_12v>; + enable-gpios = <&gpio 13 GPIO_ACTIVE_HIGH>; - gpio-controller; - #gpio-cells = <2>; + gpio-controller; + #gpio-cells = <2>; - maxim,reverse-channel-microvolt = <170000>; + maxim,reverse-channel-microvolt = <170000>; - ports { - #address-cells = <1>; - #size-cells = <0>; + ports { + #address-cells = <1>; + #size-cells = <0>; - port@0 { - reg = <0>; + port@0 { + reg = <0>; - max9286_in0: endpoint { - remote-endpoint = <&rdacm20_out0>; - }; - }; + max9286_in0: endpoint { + remote-endpoint = <&rdacm20_out0>; + }; + }; - port@1 { - reg = <1>; + port@1 { + reg = <1>; - max9286_in1: endpoint { - remote-endpoint = <&rdacm20_out1>; - }; - }; + max9286_in1: endpoint { + remote-endpoint = <&rdacm20_out1>; + }; + }; - port@2 { - reg = <2>; + port@2 { + reg = <2>; - max9286_in2: endpoint { - remote-endpoint = <&rdacm20_out2>; - }; - }; + max9286_in2: endpoint { + remote-endpoint = <&rdacm20_out2>; + }; + }; - port@3 { - reg = <3>; + port@3 { + reg = <3>; - max9286_in3: endpoint { - remote-endpoint = <&rdacm20_out3>; - }; - }; + max9286_in3: endpoint { + remote-endpoint = <&rdacm20_out3>; + }; + }; - port@4 { - reg = <4>; + port@4 { + reg = <4>; - max9286_out: endpoint { - data-lanes = <1 2 3 4>; - remote-endpoint = <&csi40_in>; + max9286_out: endpoint { + data-lanes = <1 2 3 4>; + remote-endpoint = <&csi40_in>; + }; + }; }; - }; - }; - i2c-mux { - #address-cells = <1>; - #size-cells = <0>; + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; - i2c@0 { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; + i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; - camera@51 { - compatible = "imi,rdacm20"; - reg = <0x51>, <0x61>; + camera@51 { + compatible = "imi,rdacm20"; + reg = <0x51>, <0x61>; - port { - rdacm20_out0: endpoint { - remote-endpoint = <&max9286_in0>; - }; - }; + port { + rdacm20_out0: endpoint { + remote-endpoint = <&max9286_in0>; + }; + }; - }; - }; + }; + }; - i2c@1 { - #address-cells = <1>; - #size-cells = <0>; - reg = <1>; + i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + + camera@52 { + compatible = "imi,rdacm20"; + reg = <0x52>, <0x62>; + + port { + rdacm20_out1: endpoint { + remote-endpoint = <&max9286_in1>; + }; + }; + }; + }; - camera@52 { - compatible = "imi,rdacm20"; - reg = <0x52>, <0x62>; + i2c@2 { + #address-cells = <1>; + #size-cells = <0>; + reg = <2>; + + camera@53 { + compatible = "imi,rdacm20"; + reg = <0x53>, <0x63>; + + port { + rdacm20_out2: endpoint { + remote-endpoint = <&max9286_in2>; + }; + }; + }; + }; - port { - rdacm20_out1: endpoint { - remote-endpoint = <&max9286_in1>; + i2c@3 { + #address-cells = <1>; + #size-cells = <0>; + reg = <3>; + + camera@54 { + compatible = "imi,rdacm20"; + reg = <0x54>, <0x64>; + + port { + rdacm20_out3: endpoint { + remote-endpoint = <&max9286_in3>; + }; + }; + }; }; - }; }; - }; - - i2c@2 { - #address-cells = <1>; - #size-cells = <0>; - reg = <2>; - - camera@53 { - compatible = "imi,rdacm20"; - reg = <0x53>, <0x63>; + }; - port { - rdacm20_out2: endpoint { - remote-endpoint = <&max9286_in2>; + /* + * Example of a deserializer that controls the camera Power over Coax + * through one of its gpio lines. + */ + gmsl-deserializer@6c { + compatible = "maxim,max9286"; + reg = <0x6c>; + enable-gpios = <&gpio 14 GPIO_ACTIVE_HIGH>; + + /* + * The remote camera power is controlled by MAX9286 GPIO line #0. + * No 'poc-supply' nor 'gpio-controller' are specified. + */ + maxim,gpio-poc = <0 GPIO_ACTIVE_LOW>; + + /* + * Do not describe connections as they're the same as in the previous + * example. + */ + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@4 { + reg = <4>; }; - }; }; - }; - i2c@3 { - #address-cells = <1>; - #size-cells = <0>; - reg = <3>; - - camera@54 { - compatible = "imi,rdacm20"; - reg = <0x54>, <0x64>; - - port { - rdacm20_out3: endpoint { - remote-endpoint = <&max9286_in3>; - }; - }; + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; }; - }; }; - }; }; diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml new file mode 100644 index 000000000000..9b179bb44dfb --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-decoder.yaml @@ -0,0 +1,169 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,vcodec-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Video Decode Accelerator + +maintainers: + - Yunfei Dong <yunfei.dong@mediatek.com> + +description: |+ + Mediatek Video Decode is the video decode hardware present in Mediatek + SoCs which supports high resolution decoding functionalities. + +properties: + compatible: + enum: + - mediatek,mt8173-vcodec-dec + - mediatek,mt8183-vcodec-dec + + reg: + maxItems: 12 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 8 + + clock-names: + items: + - const: vcodecpll + - const: univpll_d2 + - const: clk_cci400_sel + - const: vdec_sel + - const: vdecpll + - const: vencpll + - const: venc_lt_sel + - const: vdec_bus_clk_src + + assigned-clocks: true + + assigned-clock-parents: true + + assigned-clock-rates: true + + power-domains: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + mediatek,vpu: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to vpu. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to scp. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - iommus + - assigned-clocks + - assigned-clock-parents + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8183-vcodec-dec + + then: + required: + - mediatek,scp + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8173-vcodec-dec + + then: + required: + - mediatek,vpu + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/memory/mt8173-larb-port.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/mt8173-power.h> + + vcodec_dec: vcodec@16000000 { + compatible = "mediatek,mt8173-vcodec-dec"; + reg = <0x16000000 0x100>, /*VDEC_SYS*/ + <0x16020000 0x1000>, /*VDEC_MISC*/ + <0x16021000 0x800>, /*VDEC_LD*/ + <0x16021800 0x800>, /*VDEC_TOP*/ + <0x16022000 0x1000>, /*VDEC_CM*/ + <0x16023000 0x1000>, /*VDEC_AD*/ + <0x16024000 0x1000>, /*VDEC_AV*/ + <0x16025000 0x1000>, /*VDEC_PP*/ + <0x16026800 0x800>, /*VP8_VD*/ + <0x16027000 0x800>, /*VP6_VD*/ + <0x16027800 0x800>, /*VP8_VL*/ + <0x16028400 0x400>; /*VP9_VD*/ + interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>; + iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>, + <&iommu M4U_PORT_HW_VDEC_PP_EXT>, + <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>, + <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>, + <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>, + <&iommu M4U_PORT_HW_VDEC_UFO_EXT>, + <&iommu M4U_PORT_HW_VDEC_VLD_EXT>, + <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>; + mediatek,vpu = <&vpu>; + power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; + clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>, + <&topckgen CLK_TOP_UNIVPLL_D2>, + <&topckgen CLK_TOP_CCI400_SEL>, + <&topckgen CLK_TOP_VDEC_SEL>, + <&topckgen CLK_TOP_VCODECPLL>, + <&apmixedsys CLK_APMIXED_VENCPLL>, + <&topckgen CLK_TOP_VENC_LT_SEL>, + <&topckgen CLK_TOP_VCODECPLL_370P5>; + clock-names = "vcodecpll", + "univpll_d2", + "clk_cci400_sel", + "vdec_sel", + "vdecpll", + "vencpll", + "venc_lt_sel", + "vdec_bus_clk_src"; + assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>, + <&topckgen CLK_TOP_CCI400_SEL>, + <&topckgen CLK_TOP_VDEC_SEL>, + <&apmixedsys CLK_APMIXED_VCODECPLL>, + <&apmixedsys CLK_APMIXED_VENCPLL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>, + <&topckgen CLK_TOP_UNIVPLL_D2>, + <&topckgen CLK_TOP_VCODECPLL>; + assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml new file mode 100644 index 000000000000..e7b65a91c92c --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-encoder.yaml @@ -0,0 +1,179 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek,vcodec-encoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Video Encode Accelerator + +maintainers: + - Yunfei Dong <yunfei.dong@mediatek.com> + +description: |+ + Mediatek Video Encode is the video encode hardware present in Mediatek + SoCs which supports high resolution encoding functionalities. + +properties: + compatible: + enum: + - mediatek,mt8173-vcodec-enc-vp8 + - mediatek,mt8173-vcodec-enc + - mediatek,mt8183-vcodec-enc + - mediatek,mt8192-vcodec-enc + - mediatek,mt8195-vcodec-enc + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 5 + + clock-names: + minItems: 1 + maxItems: 5 + + assigned-clocks: true + + assigned-clock-parents: true + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + mediatek,vpu: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to vpu. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: + Describes point to scp. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - iommus + - assigned-clocks + - assigned-clock-parents + +allOf: + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8183-vcodec-enc + - mediatek,mt8192-vcodec-enc + + then: + required: + - mediatek,scp + + - if: + properties: + compatible: + contains: + enum: + - mediatek,mt8173-vcodec-enc-vp8 + - mediatek,mt8173-vcodec-enc + + then: + required: + - mediatek,vpu + + - if: + properties: + compatible: + enum: + - mediatek,mt8173-vcodec-enc + - mediatek,mt8192-vcodec-enc + - mediatek,mt8173-vcodec-enc + + then: + properties: + clock: + items: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: venc_sel + else: # for vp8 hw decoder + properties: + clock: + items: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: venc_lt_sel + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/memory/mt8173-larb-port.h> + #include <dt-bindings/interrupt-controller/irq.h> + + vcodec_enc_avc: vcodec@18002000 { + compatible = "mediatek,mt8173-vcodec-enc"; + reg = <0x18002000 0x1000>; + interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>; + iommus = <&iommu M4U_PORT_VENC_RCPU>, + <&iommu M4U_PORT_VENC_REC>, + <&iommu M4U_PORT_VENC_BSDMA>, + <&iommu M4U_PORT_VENC_SV_COMV>, + <&iommu M4U_PORT_VENC_RD_COMV>, + <&iommu M4U_PORT_VENC_CUR_LUMA>, + <&iommu M4U_PORT_VENC_CUR_CHROMA>, + <&iommu M4U_PORT_VENC_REF_LUMA>, + <&iommu M4U_PORT_VENC_REF_CHROMA>, + <&iommu M4U_PORT_VENC_NBM_RDMA>, + <&iommu M4U_PORT_VENC_NBM_WDMA>; + mediatek,vpu = <&vpu>; + clocks = <&topckgen CLK_TOP_VENC_SEL>; + clock-names = "venc_sel"; + assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>; + }; + + vcodec_enc_vp8: vcodec@19002000 { + compatible = "mediatek,mt8173-vcodec-enc-vp8"; + reg = <0x19002000 0x1000>; /* VENC_LT_SYS */ + interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>; + iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>, + <&iommu M4U_PORT_VENC_REC_FRM_SET2>, + <&iommu M4U_PORT_VENC_BSDMA_SET2>, + <&iommu M4U_PORT_VENC_SV_COMA_SET2>, + <&iommu M4U_PORT_VENC_RD_COMA_SET2>, + <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>, + <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>, + <&iommu M4U_PORT_VENC_REF_LUMA_SET2>, + <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>; + mediatek,vpu = <&vpu>; + clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; + clock-names = "venc_lt_sel"; + assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml new file mode 100644 index 000000000000..7687be0f50aa --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek,vcodec-subdev-decoder.yaml @@ -0,0 +1,271 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/mediatek,vcodec-subdev-decoder.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Mediatek Video Decode Accelerator With Multi Hardware + +maintainers: + - Yunfei Dong <yunfei.dong@mediatek.com> + +description: | + Mediatek Video Decode is the video decode hardware present in Mediatek + SoCs which supports high resolution decoding functionalities. Required + parent and child device node. + + About the Decoder Hardware Block Diagram, please check below: + + +---------------------------------+------------------------------------+ + | | | + | input -> lat HW -> lat buffer --|--> lat buffer -> core HW -> output | + | || | || | + +------------||-------------------+---------------------||-------------+ + lat workqueue | core workqueue <parent> + -------------||-----------------------------------------||------------------ + || || <child> + \/ <----------------HW index-------------->\/ + +------------------------------------------------------+ + | enable/disable | + | clk power irq iommu | + | (lat/lat soc/core0/core1) | + +------------------------------------------------------+ + + As above, there are parent and child devices, child mean each hardware. The child device + controls the information of each hardware independent which include clk/power/irq. + + There are two workqueues in parent device: lat workqueue and core workqueue. They are used + to lat and core hardware deocder. Lat workqueue need to get input bitstream and lat buffer, + then enable lat to decode, writing the result to lat buffer, dislabe hardware when lat decode + done. Core workqueue need to get lat buffer and output buffer, then enable core to decode, + writing the result to output buffer, disable hardware when core decode done. These two + hardwares will decode each frame cyclically. + + For the smi common may not the same for each hardware, can't combine all hardware in one node, + or leading to iommu fault when access dram data. + +properties: + compatible: + const: mediatek,mt8192-vcodec-dec + + reg: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + mediatek,scp: + $ref: /schemas/types.yaml#/definitions/phandle + maxItems: 1 + description: | + The node of system control processor (SCP), using + the remoteproc & rpmsg framework. + + dma-ranges: + maxItems: 1 + description: | + Describes the physical address space of IOMMU maps to memory. + + "#address-cells": + const: 2 + + "#size-cells": + const: 2 + + ranges: true + +# Required child node: +patternProperties: + '^vcodec-lat@[0-9a-f]+$': + type: object + + properties: + compatible: + const: mediatek,mtk-vcodec-lat + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + clocks: + maxItems: 5 + + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + power-domains: + maxItems: 1 + + required: + - compatible + - reg + - interrupts + - iommus + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - power-domains + + additionalProperties: false + + '^vcodec-core@[0-9a-f]+$': + type: object + + properties: + compatible: + const: mediatek,mtk-vcodec-core + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + iommus: + minItems: 1 + maxItems: 32 + description: | + List of the hardware port in respective IOMMU block for current Socs. + Refer to bindings/iommu/mediatek,iommu.yaml. + + clocks: + maxItems: 5 + + clock-names: + items: + - const: sel + - const: soc-vdec + - const: soc-lat + - const: vdec + - const: top + + assigned-clocks: + maxItems: 1 + + assigned-clock-parents: + maxItems: 1 + + power-domains: + maxItems: 1 + + required: + - compatible + - reg + - interrupts + - iommus + - clocks + - clock-names + - assigned-clocks + - assigned-clock-parents + - power-domains + + additionalProperties: false + +required: + - compatible + - reg + - iommus + - mediatek,scp + - dma-ranges + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/mt8192-larb-port.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/mt8192-clk.h> + #include <dt-bindings/power/mt8192-power.h> + + bus@16000000 { + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0x16000000 0x16000000 0 0x40000>; + + video-codec@16000000 { + compatible = "mediatek,mt8192-vcodec-dec"; + mediatek,scp = <&scp>; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>; + dma-ranges = <0x1 0x0 0x0 0x40000000 0x0 0xfff00000>; + #address-cells = <2>; + #size-cells = <2>; + ranges = <0 0 0 0x16000000 0 0x40000>; + reg = <0 0x16000000 0 0x1000>; /* VDEC_SYS */ + vcodec-lat@10000 { + compatible = "mediatek,mtk-vcodec-lat"; + reg = <0 0x10000 0 0x800>; + interrupts = <GIC_SPI 426 IRQ_TYPE_LEVEL_HIGH 0>; + iommus = <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_VLD2_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_TILE_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_WDMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_LAT0_RG_CTRL_DMA_EXT>, + <&iommu0 M4U_PORT_L5_VDEC_UFO_ENC_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys_soc CLK_VDEC_SOC_VDEC>, + <&vdecsys_soc CLK_VDEC_SOC_LAT>, + <&vdecsys_soc CLK_VDEC_SOC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC>; + }; + + vcodec-core@25000 { + compatible = "mediatek,mtk-vcodec-core"; + reg = <0 0x25000 0 0x1000>; + interrupts = <GIC_SPI 425 IRQ_TYPE_LEVEL_HIGH 0>; + iommus = <&iommu0 M4U_PORT_L4_VDEC_MC_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_UFO_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_RD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PRED_WR_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_PPWRAP_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_TILE_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_VLD2_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_AVC_MV_EXT>, + <&iommu0 M4U_PORT_L4_VDEC_RG_CTRL_DMA_EXT>; + clocks = <&topckgen CLK_TOP_VDEC_SEL>, + <&vdecsys CLK_VDEC_VDEC>, + <&vdecsys CLK_VDEC_LAT>, + <&vdecsys CLK_VDEC_LARB1>, + <&topckgen CLK_TOP_MAINPLL_D4>; + clock-names = "sel", "soc-vdec", "soc-lat", "vdec", "top"; + assigned-clocks = <&topckgen CLK_TOP_VDEC_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_MAINPLL_D4>; + power-domains = <&spm MT8192_POWER_DOMAIN_VDEC2>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt deleted file mode 100644 index 39c1028b2dfb..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Mediatek JPEG Decoder - -Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs - -Required properties: -- compatible : must be one of the following string: - "mediatek,mt8173-jpgdec" - "mediatek,mt7623-jpgdec", "mediatek,mt2701-jpgdec" - "mediatek,mt2701-jpgdec" -- reg : physical base address of the jpeg decoder registers and length of - memory mapped region. -- interrupts : interrupt number to the interrupt controller. -- clocks: device clocks, see - Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "jpgdec-smi" and "jpgdec". -- power-domains: a phandle to the power domain, see - Documentation/devicetree/bindings/power/power_domain.txt for details. -- mediatek,larb: must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. -- iommus: should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Example: - jpegdec: jpegdec@15004000 { - compatible = "mediatek,mt2701-jpgdec"; - reg = <0 0x15004000 0 0x1000>; - interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>; - clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, - <&imgsys CLK_IMG_JPGDEC>; - clock-names = "jpgdec-smi", - "jpgdec"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; - iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, - <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; - }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml new file mode 100644 index 000000000000..052e752157b4 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-decoder.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek-jpeg-decoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek JPEG Decoder Device Tree Bindings + +maintainers: + - Xia Jiang <xia.jiang@mediatek.com> + +description: |- + Mediatek JPEG Decoder is the JPEG decode hardware present in Mediatek SoCs + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt8173-jpgdec + - mediatek,mt2701-jpgdec + - items: + - enum: + - mediatek,mt7623-jpgdec + - const: mediatek,mt2701-jpgdec + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 2 + minItems: 2 + + clock-names: + items: + - const: jpgdec-smi + - const: jpgdec + + power-domains: + maxItems: 1 + + iommus: + maxItems: 2 + description: | + Points to the respective IOMMU block with master port as argument, see + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + Ports are according to the HW. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2701-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/mt2701-larb-port.h> + #include <dt-bindings/power/mt2701-power.h> + jpegdec: jpegdec@15004000 { + compatible = "mediatek,mt2701-jpgdec"; + reg = <0x15004000 0x1000>; + interrupts = <GIC_SPI 143 IRQ_TYPE_LEVEL_LOW>; + clocks = <&imgsys CLK_IMG_JPGDEC_SMI>, + <&imgsys CLK_IMG_JPGDEC>; + clock-names = "jpgdec-smi", + "jpgdec"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + iommus = <&iommu MT2701_M4U_PORT_JPGDEC_WDMA>, + <&iommu MT2701_M4U_PORT_JPGDEC_BSDMA>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt deleted file mode 100644 index 5e53c6ab52d0..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.txt +++ /dev/null @@ -1,35 +0,0 @@ -* MediaTek JPEG Encoder - -MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs - -Required properties: -- compatible : "mediatek,mt2701-jpgenc" - followed by "mediatek,mtk-jpgenc" -- reg : physical base address of the JPEG encoder registers and length of - memory mapped region. -- interrupts : interrupt number to the interrupt controller. -- clocks: device clocks, see - Documentation/devicetree/bindings/clock/clock-bindings.txt for details. -- clock-names: must contain "jpgenc". It is the clock of JPEG encoder. -- power-domains: a phandle to the power domain, see - Documentation/devicetree/bindings/power/power_domain.txt for details. -- mediatek,larb: must contain the local arbiters in the current SoCs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. -- iommus: should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. - -Example: - jpegenc: jpegenc@1500a000 { - compatible = "mediatek,mt2701-jpgenc", - "mediatek,mtk-jpgenc"; - reg = <0 0x1500a000 0 0x1000>; - interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>; - clocks = <&imgsys CLK_IMG_VENC>; - clock-names = "jpgenc"; - power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; - mediatek,larb = <&larb2>; - iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>, - <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>; - }; diff --git a/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml new file mode 100644 index 000000000000..8bfdfdfaba59 --- /dev/null +++ b/Documentation/devicetree/bindings/media/mediatek-jpeg-encoder.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/mediatek-jpeg-encoder.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek JPEG Encoder Device Tree Bindings + +maintainers: + - Xia Jiang <xia.jiang@mediatek.com> + +description: |- + MediaTek JPEG Encoder is the JPEG encode hardware present in MediaTek SoCs + +properties: + compatible: + items: + - enum: + - mediatek,mt2701-jpgenc + - mediatek,mt8183-jpgenc + - const: mediatek,mtk-jpgenc + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: jpgenc + + power-domains: + maxItems: 1 + + iommus: + maxItems: 2 + description: | + Points to the respective IOMMU block with master port as argument, see + Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. + Ports are according to the HW. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - power-domains + - iommus + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2701-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/memory/mt2701-larb-port.h> + #include <dt-bindings/power/mt2701-power.h> + jpegenc: jpegenc@1500a000 { + compatible = "mediatek,mt2701-jpgenc", + "mediatek,mtk-jpgenc"; + reg = <0x1500a000 0x1000>; + interrupts = <GIC_SPI 141 IRQ_TYPE_LEVEL_LOW>; + clocks = <&imgsys CLK_IMG_VENC>; + clock-names = "jpgenc"; + power-domains = <&scpsys MT2701_POWER_DOMAIN_ISP>; + iommus = <&iommu MT2701_M4U_PORT_JPGENC_RDMA>, + <&iommu MT2701_M4U_PORT_JPGENC_BSDMA>; + }; diff --git a/Documentation/devicetree/bindings/media/mediatek-mdp.txt b/Documentation/devicetree/bindings/media/mediatek-mdp.txt index caa24943da33..53ef26e2c857 100644 --- a/Documentation/devicetree/bindings/media/mediatek-mdp.txt +++ b/Documentation/devicetree/bindings/media/mediatek-mdp.txt @@ -27,9 +27,6 @@ Required properties (DMA function blocks, child node): - iommus: should point to the respective IOMMU block with master port as argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml for details. -- mediatek,larb: must contain the local arbiters in the current Socs, see - Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml - for details. Example: mdp_rdma0: rdma@14001000 { @@ -40,7 +37,6 @@ Example: <&mmsys CLK_MM_MUTEX_32K>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_RDMA0>; - mediatek,larb = <&larb0>; mediatek,vpu = <&vpu>; }; @@ -51,7 +47,6 @@ Example: <&mmsys CLK_MM_MUTEX_32K>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_RDMA1>; - mediatek,larb = <&larb4>; }; mdp_rsz0: rsz@14003000 { @@ -81,7 +76,6 @@ Example: clocks = <&mmsys CLK_MM_MDP_WDMA>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WDMA>; - mediatek,larb = <&larb0>; }; mdp_wrot0: wrot@14007000 { @@ -90,7 +84,6 @@ Example: clocks = <&mmsys CLK_MM_MDP_WROT0>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WROT0>; - mediatek,larb = <&larb0>; }; mdp_wrot1: wrot@14008000 { @@ -99,5 +92,4 @@ Example: clocks = <&mmsys CLK_MM_MDP_WROT1>; power-domains = <&scpsys MT8173_POWER_DOMAIN_MM>; iommus = <&iommu M4U_PORT_MDP_WROT1>; - mediatek,larb = <&larb4>; }; diff --git a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt b/Documentation/devicetree/bindings/media/mediatek-vcodec.txt deleted file mode 100644 index 665a9508708e..000000000000 --- a/Documentation/devicetree/bindings/media/mediatek-vcodec.txt +++ /dev/null @@ -1,131 +0,0 @@ -Mediatek Video Codec - -Mediatek Video Codec is the video codec hw present in Mediatek SoCs which -supports high resolution encoding and decoding functionalities. - -Required properties: -- compatible : must be one of the following string: - "mediatek,mt8173-vcodec-enc-vp8" for mt8173 vp8 encoder. - "mediatek,mt8173-vcodec-enc" for mt8173 avc encoder. - "mediatek,mt8183-vcodec-enc" for MT8183 encoder. - "mediatek,mt8173-vcodec-dec" for MT8173 decoder. - "mediatek,mt8192-vcodec-enc" for MT8192 encoder. - "mediatek,mt8183-vcodec-dec" for MT8183 decoder. - "mediatek,mt8195-vcodec-enc" for MT8195 encoder. -- reg : Physical base address of the video codec registers and length of - memory mapped region. -- interrupts : interrupt number to the cpu. -- mediatek,larb : must contain the local arbiters in the current Socs. -- clocks : list of clock specifiers, corresponding to entries in - the clock-names property. -- clock-names: avc encoder must contain "venc_sel", vp8 encoder must - contain "venc_lt_sel", decoder must contain "vcodecpll", "univpll_d2", - "clk_cci400_sel", "vdec_sel", "vdecpll", "vencpll", "venc_lt_sel", - "vdec_bus_clk_src". -- iommus : should point to the respective IOMMU block with master port as - argument, see Documentation/devicetree/bindings/iommu/mediatek,iommu.yaml - for details. -- dma-ranges : describes the dma address range space that the codec hw access. -One of the two following nodes: -- mediatek,vpu : the node of the video processor unit, if using VPU. -- mediatek,scp : the node of the SCP unit, if using SCP. - - -Example: - -vcodec_dec: vcodec@16000000 { - compatible = "mediatek,mt8173-vcodec-dec"; - reg = <0 0x16000000 0 0x100>, /*VDEC_SYS*/ - <0 0x16020000 0 0x1000>, /*VDEC_MISC*/ - <0 0x16021000 0 0x800>, /*VDEC_LD*/ - <0 0x16021800 0 0x800>, /*VDEC_TOP*/ - <0 0x16022000 0 0x1000>, /*VDEC_CM*/ - <0 0x16023000 0 0x1000>, /*VDEC_AD*/ - <0 0x16024000 0 0x1000>, /*VDEC_AV*/ - <0 0x16025000 0 0x1000>, /*VDEC_PP*/ - <0 0x16026800 0 0x800>, /*VP8_VD*/ - <0 0x16027000 0 0x800>, /*VP6_VD*/ - <0 0x16027800 0 0x800>, /*VP8_VL*/ - <0 0x16028400 0 0x400>; /*VP9_VD*/ - interrupts = <GIC_SPI 204 IRQ_TYPE_LEVEL_LOW>; - mediatek,larb = <&larb1>; - iommus = <&iommu M4U_PORT_HW_VDEC_MC_EXT>, - <&iommu M4U_PORT_HW_VDEC_PP_EXT>, - <&iommu M4U_PORT_HW_VDEC_AVC_MV_EXT>, - <&iommu M4U_PORT_HW_VDEC_PRED_RD_EXT>, - <&iommu M4U_PORT_HW_VDEC_PRED_WR_EXT>, - <&iommu M4U_PORT_HW_VDEC_UFO_EXT>, - <&iommu M4U_PORT_HW_VDEC_VLD_EXT>, - <&iommu M4U_PORT_HW_VDEC_VLD2_EXT>; - mediatek,vpu = <&vpu>; - power-domains = <&scpsys MT8173_POWER_DOMAIN_VDEC>; - clocks = <&apmixedsys CLK_APMIXED_VCODECPLL>, - <&topckgen CLK_TOP_UNIVPLL_D2>, - <&topckgen CLK_TOP_CCI400_SEL>, - <&topckgen CLK_TOP_VDEC_SEL>, - <&topckgen CLK_TOP_VCODECPLL>, - <&apmixedsys CLK_APMIXED_VENCPLL>, - <&topckgen CLK_TOP_VENC_LT_SEL>, - <&topckgen CLK_TOP_VCODECPLL_370P5>; - clock-names = "vcodecpll", - "univpll_d2", - "clk_cci400_sel", - "vdec_sel", - "vdecpll", - "vencpll", - "venc_lt_sel", - "vdec_bus_clk_src"; - assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>, - <&topckgen CLK_TOP_CCI400_SEL>, - <&topckgen CLK_TOP_VDEC_SEL>, - <&apmixedsys CLK_APMIXED_VCODECPLL>, - <&apmixedsys CLK_APMIXED_VENCPLL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>, - <&topckgen CLK_TOP_UNIVPLL_D2>, - <&topckgen CLK_TOP_VCODECPLL>; - assigned-clock-rates = <0>, <0>, <0>, <1482000000>, <800000000>; - }; - -vcodec_enc_avc: vcodec@18002000 { - compatible = "mediatek,mt8173-vcodec-enc"; - reg = <0 0x18002000 0 0x1000>; - interrupts = <GIC_SPI 198 IRQ_TYPE_LEVEL_LOW>; - iommus = <&iommu M4U_PORT_VENC_RCPU>, - <&iommu M4U_PORT_VENC_REC>, - <&iommu M4U_PORT_VENC_BSDMA>, - <&iommu M4U_PORT_VENC_SV_COMV>, - <&iommu M4U_PORT_VENC_RD_COMV>, - <&iommu M4U_PORT_VENC_CUR_LUMA>, - <&iommu M4U_PORT_VENC_CUR_CHROMA>, - <&iommu M4U_PORT_VENC_REF_LUMA>, - <&iommu M4U_PORT_VENC_REF_CHROMA>, - <&iommu M4U_PORT_VENC_NBM_RDMA>, - <&iommu M4U_PORT_VENC_NBM_WDMA>; - mediatek,larb = <&larb3>; - mediatek,vpu = <&vpu>; - clocks = <&topckgen CLK_TOP_VENC_SEL>; - clock-names = "venc_sel"; - assigned-clocks = <&topckgen CLK_TOP_VENC_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL>; - }; - -vcodec_enc_vp8: vcodec@19002000 { - compatible = "mediatek,mt8173-vcodec-enc-vp8"; - reg = <0 0x19002000 0 0x1000>; /* VENC_LT_SYS */ - interrupts = <GIC_SPI 202 IRQ_TYPE_LEVEL_LOW>; - iommus = <&iommu M4U_PORT_VENC_RCPU_SET2>, - <&iommu M4U_PORT_VENC_REC_FRM_SET2>, - <&iommu M4U_PORT_VENC_BSDMA_SET2>, - <&iommu M4U_PORT_VENC_SV_COMA_SET2>, - <&iommu M4U_PORT_VENC_RD_COMA_SET2>, - <&iommu M4U_PORT_VENC_CUR_LUMA_SET2>, - <&iommu M4U_PORT_VENC_CUR_CHROMA_SET2>, - <&iommu M4U_PORT_VENC_REF_LUMA_SET2>, - <&iommu M4U_PORT_VENC_REC_CHROMA_SET2>; - mediatek,larb = <&larb5>; - mediatek,vpu = <&vpu>; - clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; - clock-names = "venc_lt_sel"; - assigned-clocks = <&topckgen CLK_TOP_VENC_LT_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_VCODECPLL_370P5>; - }; diff --git a/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml new file mode 100644 index 000000000000..e8544fb2d034 --- /dev/null +++ b/Documentation/devicetree/bindings/media/microchip,csi2dc.yaml @@ -0,0 +1,197 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/media/microchip,csi2dc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip CSI2 Demux Controller (CSI2DC) + +maintainers: + - Eugen Hristev <eugen.hristev@microchip.com> + +description: + CSI2DC - Camera Serial Interface 2 Demux Controller + + CSI2DC is a hardware block that receives incoming data from either from an + IDI interface or from a parallel bus interface. + It filters IDI packets based on their data type and virtual channel + identifier, then converts the byte stream to a pixel stream into a cross + clock domain towards a parallel interface that can be read by a sensor + controller. + IDI interface is Synopsys proprietary. + CSI2DC can act a simple bypass bridge if the incoming data is coming from + a parallel interface. + + CSI2DC provides two pipes, one video pipe and one data pipe. Video pipe + is connected at the output to a sensor controller and the data pipe is + accessible as a DMA slave port to a DMA controller. + + CSI2DC supports a single 'port' node as a sink port with either Synopsys + 32-bit IDI interface or a parallel interface. + + CSI2DC supports one 'port' node as source port with parallel interface. + This is called video pipe. + This port has an 'endpoint' that can be connected to a sink port of another + controller (next in pipeline). + + CSI2DC also supports direct access to the data through AHB, via DMA channel, + called data pipe. + For data pipe to be available, a dma controller and a dma channel must be + referenced. + +properties: + compatible: + const: microchip,sama7g5-csi2dc + + reg: + maxItems: 1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + description: + CSI2DC must have two clocks to function correctly. One clock is the + peripheral clock for the inside functionality of the hardware block. + This is named 'pclk'. The second clock must be the cross domain clock, + in which CSI2DC will perform clock crossing. This clock must be fed + by the next controller in pipeline, which usually is a sensor controller. + Normally this clock should be given by this sensor controller who + is also a clock source. This clock is named 'scck', sensor controller clock. + items: + - const: pclk + - const: scck + + dmas: + maxItems: 1 + + dma-names: + const: rx + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Input port node, single endpoint describing the input port. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + description: Endpoint connected to input device + + properties: + bus-type: + enum: [4, 5, 6] + default: 4 + + bus-width: + enum: [8, 9, 10, 11, 12, 13, 14] + default: 14 + + clock-noncontinuous: + type: boolean + description: + Presence of this boolean property decides whether clock is + continuous or noncontinuous. + + remote-endpoint: true + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + description: + Output port node, single endpoint describing the output port. + + properties: + endpoint: + unevaluatedProperties: false + $ref: video-interfaces.yaml# + description: Endpoint connected to output device + + properties: + bus-type: + enum: [5, 6] + default: 5 + + bus-width: + enum: [8, 9, 10, 11, 12, 13, 14] + default: 14 + + remote-endpoint: true + + required: + - port@0 + - port@1 + +additionalProperties: false + +required: + - compatible + - reg + - clocks + - clock-names + - ports + +examples: + # Example for connecting to a parallel sensor controller block (video pipe) + # and the input is received from Synopsys IDI interface + - | + csi2dc@e1404000 { + compatible = "microchip,sama7g5-csi2dc"; + reg = <0xe1404000 0x500>; + clocks = <&pclk>, <&scck>; + clock-names = "pclk", "scck"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; /* must be 0, first child port */ + csi2dc_in: endpoint { /* input from IDI interface */ + bus-type = <4>; /* MIPI CSI2 D-PHY */ + remote-endpoint = <&csi2host_out>; + }; + }; + + port@1 { + reg = <1>; /* must be 1, second child port */ + csi2dc_out: endpoint { + remote-endpoint = <&xisc_in>; /* output to sensor controller */ + }; + }; + }; + }; + + # Example for connecting to a DMA master as an AHB slave + # and the input is received from Synopsys IDI interface + - | + #include <dt-bindings/dma/at91.h> + csi2dc@e1404000 { + compatible = "microchip,sama7g5-csi2dc"; + reg = <0xe1404000 0x500>; + clocks = <&pclk>, <&scck>; + clock-names = "pclk", "scck"; + dmas = <&dma0 AT91_XDMAC_DT_PERID(34)>; + dma-names = "rx"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; /* must be 0, first child port */ + csi2dc_input: endpoint { /* input from IDI interface */ + remote-endpoint = <&csi2host_out>; + }; + }; + + port@1 { + reg = <1>; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml index e2e6e9aa0fe6..36b135bf9f2a 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx-mipi-csi2.yaml @@ -1,7 +1,7 @@ # SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) %YAML 1.2 --- -$id: http://devicetree.org/schemas/media/nxp,imx7-mipi-csi2.yaml# +$id: http://devicetree.org/schemas/media/nxp,imx-mipi-csi2.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP i.MX7 and i.MX8 MIPI CSI-2 receiver diff --git a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml index 5922a2795167..4f7b78265336 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx7-csi.yaml @@ -17,6 +17,7 @@ properties: compatible: oneOf: - enum: + - fsl,imx8mq-csi - fsl,imx7-csi - fsl,imx6ul-csi - items: diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml index 1b3e1c4b99ed..2a14e3b0e004 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-mipi-csi2.yaml @@ -58,11 +58,11 @@ properties: req_gpr is the gpr register offset of RX_ENABLE for the mipi phy. $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The 'gpr' is the phandle to general purpose register node. - - description: The 'req_gpr' is the gpr register offset containing - CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. - maximum: 0xff + - items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset containing + CSI2_1_RX_ENABLE or CSI2_2_RX_ENABLE respectively. + maximum: 0xff interconnects: maxItems: 1 diff --git a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml index 762be3f96ce9..7dc13a4b1805 100644 --- a/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml +++ b/Documentation/devicetree/bindings/media/nxp,imx8mq-vpu.yaml @@ -5,7 +5,7 @@ $id: "http://devicetree.org/schemas/media/nxp,imx8mq-vpu.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Hantro G1/G2 VPU codecs implemented on i.MX8MQ SoCs +title: Hantro G1/G2 VPU codecs implemented on i.MX8M SoCs maintainers: - Philipp Zabel <p.zabel@pengutronix.de> @@ -15,33 +15,21 @@ description: properties: compatible: - const: nxp,imx8mq-vpu + oneOf: + - const: nxp,imx8mq-vpu + deprecated: true + - const: nxp,imx8mq-vpu-g1 + - const: nxp,imx8mq-vpu-g2 + - const: nxp,imx8mm-vpu-g1 reg: - maxItems: 3 - - reg-names: - items: - - const: g1 - - const: g2 - - const: ctrl + maxItems: 1 interrupts: - maxItems: 2 - - interrupt-names: - items: - - const: g1 - - const: g2 + maxItems: 1 clocks: - maxItems: 3 - - clock-names: - items: - - const: g1 - - const: g2 - - const: bus + maxItems: 1 power-domains: maxItems: 1 @@ -49,31 +37,33 @@ properties: required: - compatible - reg - - reg-names - interrupts - - interrupt-names - clocks - - clock-names additionalProperties: false examples: - | #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/power/imx8mq-power.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + vpu_g1: video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g1"; + reg = <0x38300000 0x10000>; + interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G1>; + }; + - | + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/power/imx8mq-power.h> #include <dt-bindings/interrupt-controller/arm-gic.h> - vpu: video-codec@38300000 { - compatible = "nxp,imx8mq-vpu"; - reg = <0x38300000 0x10000>, - <0x38310000 0x10000>, - <0x38320000 0x10000>; - reg-names = "g1", "g2", "ctrl"; - interrupts = <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; - interrupt-names = "g1", "g2"; - clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>, - <&clk IMX8MQ_CLK_VPU_G2_ROOT>, - <&clk IMX8MQ_CLK_VPU_DEC_ROOT>; - clock-names = "g1", "g2", "bus"; - power-domains = <&pgc_vpu>; + vpu_g2: video-codec@38300000 { + compatible = "nxp,imx8mq-vpu-g2"; + reg = <0x38310000 0x10000>; + interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clk IMX8MQ_CLK_VPU_G2_ROOT>; + power-domains = <&vpu_blk_ctrl IMX8MQ_VPUBLK_PD_G2>; }; diff --git a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml index 304908072d72..12ec3e1ea869 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8916-camss.yaml @@ -83,10 +83,6 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 1 - data-lanes: description: An array of physical data lanes indexes. @@ -99,7 +95,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -114,16 +109,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml index 38be41e932f0..6aeb3d6d02d5 100644 --- a/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,msm8996-camss.yaml @@ -105,10 +105,6 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: description: An array of physical data lanes indexes. @@ -121,7 +117,6 @@ properties: maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -136,16 +131,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -160,16 +150,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -184,16 +169,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml index 841a1aafdd13..338ab28d5f3b 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm660-camss.yaml @@ -111,16 +111,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -135,16 +130,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -159,16 +149,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -183,16 +168,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: diff --git a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml index 9ca5dfa7f226..f9a003882f84 100644 --- a/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml +++ b/Documentation/devicetree/bindings/media/qcom,sdm845-camss.yaml @@ -105,15 +105,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@1: @@ -128,16 +124,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - items: - - const: 7 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@2: @@ -152,15 +143,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes port@3: @@ -175,15 +162,11 @@ properties: unevaluatedProperties: false properties: - clock-lanes: - maxItems: 1 - data-lanes: minItems: 1 maxItems: 4 required: - - clock-lanes - data-lanes reg: @@ -203,9 +186,13 @@ properties: - const: vfe1 - const: vfe_lite - vdda-supply: + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: description: - Definition of the regulator used as analog power supply. + Phandle to 1.8V regulator supply to PHY refclk pll block. required: - clock-names @@ -217,7 +204,8 @@ required: - power-domains - reg - reg-names - - vdda-supply + - vdda-phy-supply + - vdda-pll-supply additionalProperties: false @@ -361,7 +349,8 @@ examples: "vfe1", "vfe_lite"; - vdda-supply = <®_2v8>; + vdda-phy-supply = <&vreg_l1a_0p875>; + vdda-pll-supply = <&vreg_l26a_1p2>; ports { #address-cells = <1>; diff --git a/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml new file mode 100644 index 000000000000..07a2af12f37d --- /dev/null +++ b/Documentation/devicetree/bindings/media/qcom,sm8250-camss.yaml @@ -0,0 +1,463 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/media/qcom,sm8250-camss.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm CAMSS ISP + +maintainers: + - Robert Foss <robert.foss@linaro.org> + +description: | + The CAMSS IP is a CSI decoder and ISP present on Qualcomm platforms. + +properties: + compatible: + const: qcom,sm8250-camss + + clocks: + minItems: 37 + maxItems: 37 + + clock-names: + items: + - const: cam_ahb_clk + - const: cam_hf_axi + - const: cam_sf_axi + - const: camnoc_axi + - const: camnoc_axi_src + - const: core_ahb + - const: cpas_ahb + - const: csiphy0 + - const: csiphy0_timer + - const: csiphy1 + - const: csiphy1_timer + - const: csiphy2 + - const: csiphy2_timer + - const: csiphy3 + - const: csiphy3_timer + - const: csiphy4 + - const: csiphy4_timer + - const: csiphy5 + - const: csiphy5_timer + - const: slow_ahb_src + - const: vfe0_ahb + - const: vfe0_axi + - const: vfe0 + - const: vfe0_cphy_rx + - const: vfe0_csid + - const: vfe0_areg + - const: vfe1_ahb + - const: vfe1_axi + - const: vfe1 + - const: vfe1_cphy_rx + - const: vfe1_csid + - const: vfe1_areg + - const: vfe_lite_ahb + - const: vfe_lite_axi + - const: vfe_lite + - const: vfe_lite_cphy_rx + - const: vfe_lite_csid + + interrupts: + minItems: 14 + maxItems: 14 + + interrupt-names: + items: + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: csid0 + - const: csid1 + - const: csid2 + - const: csid3 + - const: vfe0 + - const: vfe1 + - const: vfe_lite0 + - const: vfe_lite1 + + iommus: + minItems: 8 + maxItems: 8 + + interconnects: + minItems: 4 + maxItems: 4 + + interconnect-names: + items: + - const: cam_ahb + - const: cam_hf_0_mnoc + - const: cam_sf_0_mnoc + - const: cam_sf_icp_mnoc + + power-domains: + items: + - description: IFE0 GDSC - Image Front End, Global Distributed Switch Controller. + - description: IFE1 GDSC - Image Front End, Global Distributed Switch Controller. + - description: Titan GDSC - Titan ISP Block, Global Distributed Switch Controller. + + ports: + $ref: /schemas/graph.yaml#/properties/ports + + description: + CSI input ports. + + properties: + port@0: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@1: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@2: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@3: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@4: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + port@5: + $ref: /schemas/graph.yaml#/$defs/port-base + unevaluatedProperties: false + description: + Input port for receiving CSI data. + + properties: + endpoint: + $ref: video-interfaces.yaml# + unevaluatedProperties: false + + properties: + clock-lanes: + maxItems: 1 + + data-lanes: + minItems: 1 + maxItems: 4 + + required: + - clock-lanes + - data-lanes + + reg: + minItems: 10 + maxItems: 10 + + reg-names: + items: + - const: csiphy0 + - const: csiphy1 + - const: csiphy2 + - const: csiphy3 + - const: csiphy4 + - const: csiphy5 + - const: vfe0 + - const: vfe1 + - const: vfe_lite0 + - const: vfe_lite1 + + vdda-phy-supply: + description: + Phandle to a regulator supply to PHY core block. + + vdda-pll-supply: + description: + Phandle to 1.8V regulator supply to PHY refclk pll block. + +required: + - clock-names + - clocks + - compatible + - interconnects + - interconnect-names + - interrupts + - interrupt-names + - iommus + - power-domains + - reg + - reg-names + - vdda-phy-supply + - vdda-pll-supply + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,camcc-sm8250.h> + #include <dt-bindings/interconnect/qcom,sm8250.h> + #include <dt-bindings/clock/qcom,gcc-sm8250.h> + #include <dt-bindings/power/qcom-rpmpd.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + camss: camss@ac6a000 { + compatible = "qcom,sm8250-camss"; + + reg = <0 0xac6a000 0 0x2000>, + <0 0xac6c000 0 0x2000>, + <0 0xac6e000 0 0x1000>, + <0 0xac70000 0 0x1000>, + <0 0xac72000 0 0x1000>, + <0 0xac74000 0 0x1000>, + <0 0xacb4000 0 0xd000>, + <0 0xacc3000 0 0xd000>, + <0 0xacd9000 0 0x2200>, + <0 0xacdb200 0 0x2200>; + reg-names = "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + vdda-phy-supply = <&vreg_l5a_0p88>; + vdda-pll-supply = <&vreg_l9a_1p2>; + + interrupts = <GIC_SPI 477 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 478 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 479 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 448 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 86 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 89 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 464 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 466 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 468 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 359 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 465 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 467 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 469 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 360 IRQ_TYPE_LEVEL_HIGH>; + interrupt-names = "csiphy0", + "csiphy1", + "csiphy2", + "csiphy3", + "csiphy4", + "csiphy5", + "csid0", + "csid1", + "csid2", + "csid3", + "vfe0", + "vfe1", + "vfe_lite0", + "vfe_lite1"; + + power-domains = <&camcc IFE_0_GDSC>, + <&camcc IFE_1_GDSC>, + <&camcc TITAN_TOP_GDSC>; + + clocks = <&gcc GCC_CAMERA_AHB_CLK>, + <&gcc GCC_CAMERA_HF_AXI_CLK>, + <&gcc GCC_CAMERA_SF_AXI_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_CLK>, + <&camcc CAM_CC_CAMNOC_AXI_CLK_SRC>, + <&camcc CAM_CC_CORE_AHB_CLK>, + <&camcc CAM_CC_CPAS_AHB_CLK>, + <&camcc CAM_CC_CSIPHY0_CLK>, + <&camcc CAM_CC_CSI0PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY1_CLK>, + <&camcc CAM_CC_CSI1PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY2_CLK>, + <&camcc CAM_CC_CSI2PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY3_CLK>, + <&camcc CAM_CC_CSI3PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY4_CLK>, + <&camcc CAM_CC_CSI4PHYTIMER_CLK>, + <&camcc CAM_CC_CSIPHY5_CLK>, + <&camcc CAM_CC_CSI5PHYTIMER_CLK>, + <&camcc CAM_CC_SLOW_AHB_CLK_SRC>, + <&camcc CAM_CC_IFE_0_AHB_CLK>, + <&camcc CAM_CC_IFE_0_AXI_CLK>, + <&camcc CAM_CC_IFE_0_CLK>, + <&camcc CAM_CC_IFE_0_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_0_CSID_CLK>, + <&camcc CAM_CC_IFE_0_AREG_CLK>, + <&camcc CAM_CC_IFE_1_AHB_CLK>, + <&camcc CAM_CC_IFE_1_AXI_CLK>, + <&camcc CAM_CC_IFE_1_CLK>, + <&camcc CAM_CC_IFE_1_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_1_CSID_CLK>, + <&camcc CAM_CC_IFE_1_AREG_CLK>, + <&camcc CAM_CC_IFE_LITE_AHB_CLK>, + <&camcc CAM_CC_IFE_LITE_AXI_CLK>, + <&camcc CAM_CC_IFE_LITE_CLK>, + <&camcc CAM_CC_IFE_LITE_CPHY_RX_CLK>, + <&camcc CAM_CC_IFE_LITE_CSID_CLK>; + clock-names = "cam_ahb_clk", + "cam_hf_axi", + "cam_sf_axi", + "camnoc_axi", + "camnoc_axi_src", + "core_ahb", + "cpas_ahb", + "csiphy0", + "csiphy0_timer", + "csiphy1", + "csiphy1_timer", + "csiphy2", + "csiphy2_timer", + "csiphy3", + "csiphy3_timer", + "csiphy4", + "csiphy4_timer", + "csiphy5", + "csiphy5_timer", + "slow_ahb_src", + "vfe0_ahb", + "vfe0_axi", + "vfe0", + "vfe0_cphy_rx", + "vfe0_csid", + "vfe0_areg", + "vfe1_ahb", + "vfe1_axi", + "vfe1", + "vfe1_cphy_rx", + "vfe1_csid", + "vfe1_areg", + "vfe_lite_ahb", + "vfe_lite_axi", + "vfe_lite", + "vfe_lite_cphy_rx", + "vfe_lite_csid"; + + iommus = <&apps_smmu 0x800 0x400>, + <&apps_smmu 0x801 0x400>, + <&apps_smmu 0x840 0x400>, + <&apps_smmu 0x841 0x400>, + <&apps_smmu 0xC00 0x400>, + <&apps_smmu 0xC01 0x400>, + <&apps_smmu 0xC40 0x400>, + <&apps_smmu 0xC41 0x400>; + + interconnects = <&gem_noc MASTER_AMPSS_M0 &config_noc SLAVE_CAMERA_CFG>, + <&mmss_noc MASTER_CAMNOC_HF &mc_virt SLAVE_EBI_CH0>, + <&mmss_noc MASTER_CAMNOC_SF &mc_virt SLAVE_EBI_CH0>, + <&mmss_noc MASTER_CAMNOC_ICP &mc_virt SLAVE_EBI_CH0>; + interconnect-names = "cam_ahb", + "cam_hf_0_mnoc", + "cam_sf_0_mnoc", + "cam_sf_icp_mnoc"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/media/renesas,csi2.yaml b/Documentation/devicetree/bindings/media/renesas,csi2.yaml index e6a036721082..b520d6c5c102 100644 --- a/Documentation/devicetree/bindings/media/renesas,csi2.yaml +++ b/Documentation/devicetree/bindings/media/renesas,csi2.yaml @@ -67,7 +67,10 @@ properties: maxItems: 1 data-lanes: - maxItems: 1 + minItems: 1 + maxItems: 4 + items: + maximum: 4 required: - clock-lanes diff --git a/Documentation/devicetree/bindings/media/ti,cal.yaml b/Documentation/devicetree/bindings/media/ti,cal.yaml index 66c5d392fa75..7e078424ca4d 100644 --- a/Documentation/devicetree/bindings/media/ti,cal.yaml +++ b/Documentation/devicetree/bindings/media/ti,cal.yaml @@ -48,6 +48,10 @@ properties: ti,camerrx-control: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to device control module + - description: offset to the control_camerarx_core register description: phandle to the device control module and offset to the control_camerarx_core register diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml new file mode 100644 index 000000000000..f3e62ee07126 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2-timings.yaml @@ -0,0 +1,135 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr2-timings.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR2 SDRAM AC timing parameters for a given speed-bin + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: jedec,lpddr2-timings + + max-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. + + min-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Minimum DDR clock frequency for the speed-bin, in Hz. + + tCKESR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in pico seconds. + + tDQSCK-max: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + DQS output data access time from CK_t/CK_c in pico seconds. + + tDQSCK-max-derated: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + DQS output data access time from CK_t/CK_c, temperature de-rated, in pico + seconds. + + tFAW: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Four-bank activate window in pico seconds. + + tRAS-max-ns: + description: | + Row active time in nano seconds. + + tRAS-min: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row active time in pico seconds. + + tRCD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + RAS-to-CAS delay in pico seconds. + + tRPab: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (all banks) in pico seconds. + + tRRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Active bank A to active bank B in pico seconds. + + tRTP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal READ to PRECHARGE command delay in pico seconds. + + tWR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + WRITE recovery time in pico seconds. + + tWTR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal WRITE-to-READ command delay in pico seconds. + + tXP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Exit power-down to next valid command delay in pico seconds. + + tZQCL: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Long calibration time in pico seconds. + + tZQCS: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Short calibration time in pico seconds. + + tZQinit: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Initialization calibration time in pico seconds. + +required: + - compatible + - min-freq + - max-freq + +additionalProperties: false + +examples: + - | + timings { + compatible = "jedec,lpddr2-timings"; + min-freq = <10000000>; + max-freq = <400000000>; + tCKESR = <15000>; + tDQSCK-max = <5500>; + tFAW = <50000>; + tRAS-max-ns = <70000>; + tRAS-min = <42000>; + tRPab = <21000>; + tRCD = <18000>; + tRRD = <10000>; + tRTP = <7500>; + tWR = <15000>; + tWTR = <7500>; + tXP = <7500>; + tZQCL = <360000>; + tZQCS = <90000>; + tZQinit = <1000000>; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml index 25ed0266f6dd..dd2141cad866 100644 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr2.yaml @@ -30,12 +30,26 @@ properties: maximum: 255 description: | Revision 1 value of SDRAM chip. Obtained from device datasheet. + Property is deprecated, use revision-id instead. + deprecated: true revision-id2: $ref: /schemas/types.yaml#/definitions/uint32 maximum: 255 description: | Revision 2 value of SDRAM chip. Obtained from device datasheet. + Property is deprecated, use revision-id instead. + deprecated: true + + revision-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + description: | + Revision IDs read from Mode Register 6 and 7. One byte per uint32 cell (i.e. <MR6 MR7>). + minItems: 2 + maxItems: 2 + items: + minimum: 0 + maximum: 255 density: $ref: /schemas/types.yaml#/definitions/uint32 @@ -142,14 +156,12 @@ properties: patternProperties: "^lpddr2-timings": - type: object + $ref: jedec,lpddr2-timings.yaml description: | The lpddr2 node may have one or more child nodes of type "lpddr2-timings". "lpddr2-timings" provides AC timing parameters of the device for a given speed-bin. The user may provide the timings for as many - speed-bins as is required. Please see Documentation/devicetree/ - bindings/memory-controllers/ddr/lpddr2-timings.txt for more information - on "lpddr2-timings". + speed-bins as is required. required: - compatible @@ -164,8 +176,7 @@ examples: compatible = "elpida,ECB240ABACN", "jedec,lpddr2-s4"; density = <2048>; io-width = <32>; - revision-id1 = <1>; - revision-id2 = <0>; + revision-id = <1 0>; tRPab-min-tck = <3>; tRCD-min-tck = <3>; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml new file mode 100644 index 000000000000..97c3e988af5f --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3-timings.yaml @@ -0,0 +1,157 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr3-timings.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR3 SDRAM AC timing parameters for a given speed-bin + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + const: jedec,lpddr3-timings + + reg: + maxItems: 1 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. + Property is deprecated, use max-freq. + deprecated: true + + max-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Maximum DDR clock frequency for the speed-bin, in Hz. + + min-freq: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Minimum DDR clock frequency for the speed-bin, in Hz. + + tCKE: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width (HIGH and LOW pulse width) in pico seconds. + + tCKESR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in pico seconds. + + tFAW: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Four-bank activate window in pico seconds. + + tMRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Mode register set command delay in pico seconds. + + tR2R-C2C: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Additional READ-to-READ delay in chip-to-chip cases in pico seconds. + + tRAS: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row active time in pico seconds. + + tRC: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + ACTIVATE-to-ACTIVATE command period in pico seconds. + + tRCD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + RAS-to-CAS delay in pico seconds. + + tRFC: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Refresh Cycle time in pico seconds. + + tRPab: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (all banks) in pico seconds. + + tRPpb: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Row precharge time (single banks) in pico seconds. + + tRRD: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Active bank A to active bank B in pico seconds. + + tRTP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal READ to PRECHARGE command delay in pico seconds. + + tW2W-C2C: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Additional WRITE-to-WRITE delay in chip-to-chip cases in pico seconds. + + tWR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + WRITE recovery time in pico seconds. + + tWTR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Internal WRITE-to-READ command delay in pico seconds. + + tXP: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Exit power-down to next valid command delay in pico seconds. + + tXSR: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + SELF REFRESH exit to next valid command delay in pico seconds. + +required: + - compatible + - min-freq + - max-freq + +additionalProperties: false + +examples: + - | + lpddr3 { + timings { + compatible = "jedec,lpddr3-timings"; + max-freq = <800000000>; + min-freq = <100000000>; + tCKE = <3750>; + tCKESR = <3750>; + tFAW = <25000>; + tMRD = <7000>; + tR2R-C2C = <0>; + tRAS = <23000>; + tRC = <33750>; + tRCD = <10000>; + tRFC = <65000>; + tRPab = <12000>; + tRPpb = <12000>; + tRRD = <6000>; + tRTP = <3750>; + tW2W-C2C = <0>; + tWR = <7500>; + tWTR = <3750>; + tXP = <3750>; + tXSR = <70000>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml new file mode 100644 index 000000000000..c542f32c39fa --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/ddr/jedec,lpddr3.yaml @@ -0,0 +1,263 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/ddr/jedec,lpddr3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LPDDR3 SDRAM compliant to JEDEC JESD209-3 + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + items: + - enum: + - samsung,K3QF2F20DB + - const: jedec,lpddr3 + + '#address-cells': + const: 1 + deprecated: true + + density: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Density in megabits of SDRAM chip. + enum: + - 4096 + - 8192 + - 16384 + - 32768 + + io-width: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + IO bus width in bits of SDRAM chip. + enum: + - 32 + - 16 + + manufacturer-id: + $ref: /schemas/types.yaml#/definitions/uint32 + description: | + Manufacturer ID value read from Mode Register 5. The property is + deprecated, manufacturer should be derived from the compatible. + deprecated: true + + revision-id: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + maximum: 255 + description: | + Revision value of SDRAM chip read from Mode Registers 6 and 7. + + '#size-cells': + const: 0 + deprecated: true + + tCKE-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + CKE minimum pulse width (HIGH and LOW pulse width) in terms of number + of clock cycles. + + tCKESR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + CKE minimum pulse width during SELF REFRESH (low pulse width during + SELF REFRESH) in terms of number of clock cycles. + + tDQSCK-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + DQS output data access time from CK_t/CK_c in terms of number of clock + cycles. + + tFAW-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + Four-bank activate window in terms of number of clock cycles. + + tMRD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Mode register set command delay in terms of number of clock cycles. + + tR2R-C2C-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Additional READ-to-READ delay in chip-to-chip cases in terms of number + of clock cycles. + + tRAS-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + Row active time in terms of number of clock cycles. + + tRC-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 63 + description: | + ACTIVATE-to-ACTIVATE command period in terms of number of clock cycles. + + tRCD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + RAS-to-CAS delay in terms of number of clock cycles. + + tRFC-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Refresh Cycle time in terms of number of clock cycles. + + tRL-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + READ data latency in terms of number of clock cycles. + + tRPab-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Row precharge time (all banks) in terms of number of clock cycles. + + tRPpb-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Row precharge time (single banks) in terms of number of clock cycles. + + tRRD-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Active bank A to active bank B in terms of number of clock cycles. + + tRTP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Internal READ to PRECHARGE command delay in terms of number of clock + cycles. + + tW2W-C2C-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + description: | + Additional WRITE-to-WRITE delay in chip-to-chip cases in terms of number + of clock cycles. + + tWL-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + WRITE data latency in terms of number of clock cycles. + + tWR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + WRITE recovery time in terms of number of clock cycles. + + tWTR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 15 + description: | + Internal WRITE-to-READ command delay in terms of number of clock cycles. + + tXP-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 255 + description: | + Exit power-down to next valid command delay in terms of number of clock + cycles. + + tXSR-min-tck: + $ref: /schemas/types.yaml#/definitions/uint32 + maximum: 1023 + description: | + SELF REFRESH exit to next valid command delay in terms of number of clock + cycles. + +patternProperties: + "^timings((-[0-9])+|(@[0-9a-f]+))?$": + $ref: jedec,lpddr3-timings.yaml + description: | + The lpddr3 node may have one or more child nodes with timings. + Each timing node provides AC timing parameters of the device for a given + speed-bin. The user may provide the timings for as many speed-bins as is + required. + +required: + - compatible + - density + - io-width + +additionalProperties: false + +examples: + - | + lpddr3 { + compatible = "samsung,K3QF2F20DB", "jedec,lpddr3"; + density = <16384>; + io-width = <32>; + + tCKE-min-tck = <2>; + tCKESR-min-tck = <2>; + tDQSCK-min-tck = <5>; + tFAW-min-tck = <5>; + tMRD-min-tck = <5>; + tR2R-C2C-min-tck = <0>; + tRAS-min-tck = <5>; + tRC-min-tck = <6>; + tRCD-min-tck = <3>; + tRFC-min-tck = <17>; + tRL-min-tck = <14>; + tRPab-min-tck = <2>; + tRPpb-min-tck = <2>; + tRRD-min-tck = <2>; + tRTP-min-tck = <2>; + tW2W-C2C-min-tck = <0>; + tWL-min-tck = <8>; + tWR-min-tck = <7>; + tWTR-min-tck = <2>; + tXP-min-tck = <2>; + tXSR-min-tck = <12>; + + timings { + compatible = "jedec,lpddr3-timings"; + max-freq = <800000000>; + min-freq = <100000000>; + tCKE = <3750>; + tCKESR = <3750>; + tFAW = <25000>; + tMRD = <7000>; + tR2R-C2C = <0>; + tRAS = <23000>; + tRC = <33750>; + tRCD = <10000>; + tRFC = <65000>; + tRPab = <12000>; + tRPpb = <12000>; + tRRD = <6000>; + tRTP = <3750>; + tW2W-C2C = <0>; + tWR = <7500>; + tWTR = <3750>; + tXP = <3750>; + tXSR = <70000>; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt deleted file mode 100644 index 9ceb19e0c7fd..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr2-timings.txt +++ /dev/null @@ -1,52 +0,0 @@ -* AC timing parameters of LPDDR2(JESD209-2) memories for a given speed-bin - -Required properties: -- compatible : Should be "jedec,lpddr2-timings" -- min-freq : minimum DDR clock frequency for the speed-bin. Type is <u32> -- max-freq : maximum DDR clock frequency for the speed-bin. Type is <u32> - -Optional properties: - -The following properties represent AC timing parameters from the memory -data-sheet of the device for a given speed-bin. All these properties are -of type <u32> and the default unit is ps (pico seconds). Parameters with -a different unit have a suffix indicating the unit such as 'tRAS-max-ns' -- tRCD -- tWR -- tRAS-min -- tRRD -- tWTR -- tXP -- tRTP -- tDQSCK-max -- tFAW -- tZQCS -- tZQinit -- tRPab -- tZQCL -- tCKESR -- tRAS-max-ns -- tDQSCK-max-derated - -Example: - -timings_elpida_ECB240ABACN_400mhz: lpddr2-timings@0 { - compatible = "jedec,lpddr2-timings"; - min-freq = <10000000>; - max-freq = <400000000>; - tRPab = <21000>; - tRCD = <18000>; - tWR = <15000>; - tRAS-min = <42000>; - tRRD = <10000>; - tWTR = <7500>; - tXP = <7500>; - tRTP = <7500>; - tCKESR = <15000>; - tDQSCK-max = <5500>; - tFAW = <50000>; - tZQCS = <90000>; - tZQCL = <360000>; - tZQinit = <1000000>; - tRAS-max-ns = <70000>; -}; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt deleted file mode 100644 index 84705e50a3fd..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt +++ /dev/null @@ -1,58 +0,0 @@ -* AC timing parameters of LPDDR3 memories for a given speed-bin. - -The structures are based on LPDDR2 and extended where needed. - -Required properties: -- compatible : Should be "jedec,lpddr3-timings" -- min-freq : minimum DDR clock frequency for the speed-bin. Type is <u32> -- reg : maximum DDR clock frequency for the speed-bin. Type is <u32> - -Optional properties: - -The following properties represent AC timing parameters from the memory -data-sheet of the device for a given speed-bin. All these properties are -of type <u32> and the default unit is ps (pico seconds). -- tRFC -- tRRD -- tRPab -- tRPpb -- tRCD -- tRC -- tRAS -- tWTR -- tWR -- tRTP -- tW2W-C2C -- tR2R-C2C -- tFAW -- tXSR -- tXP -- tCKE -- tCKESR -- tMRD - -Example: - -timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 { - compatible = "jedec,lpddr3-timings"; - reg = <800000000>; /* workaround: it shows max-freq */ - min-freq = <100000000>; - tRFC = <65000>; - tRRD = <6000>; - tRPab = <12000>; - tRPpb = <12000>; - tRCD = <10000>; - tRC = <33750>; - tRAS = <23000>; - tWTR = <3750>; - tWR = <7500>; - tRTP = <3750>; - tW2W-C2C = <0>; - tR2R-C2C = <0>; - tFAW = <25000>; - tXSR = <70000>; - tXP = <3750>; - tCKE = <3750>; - tCKESR = <3750>; - tMRD = <7000>; -}; diff --git a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt b/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt deleted file mode 100644 index 031af5fb0379..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt +++ /dev/null @@ -1,107 +0,0 @@ -* LPDDR3 SDRAM memories compliant to JEDEC JESD209-3C - -Required properties: -- compatible : Should be "<vendor>,<type>", and generic value "jedec,lpddr3". - Example "<vendor>,<type>" values: - "samsung,K3QF2F20DB" - -- density : <u32> representing density in Mb (Mega bits) -- io-width : <u32> representing bus width. Possible values are 8, 16, 32, 64 -- #address-cells: Must be set to 1 -- #size-cells: Must be set to 0 - -Optional properties: - -- manufacturer-id : <u32> Manufacturer ID value read from Mode Register 5 -- revision-id : <u32 u32> Revision IDs read from Mode Registers 6 and 7 - -The following optional properties represent the minimum value of some AC -timing parameters of the DDR device in terms of number of clock cycles. -These values shall be obtained from the device data-sheet. -- tRFC-min-tck -- tRRD-min-tck -- tRPab-min-tck -- tRPpb-min-tck -- tRCD-min-tck -- tRC-min-tck -- tRAS-min-tck -- tWTR-min-tck -- tWR-min-tck -- tRTP-min-tck -- tW2W-C2C-min-tck -- tR2R-C2C-min-tck -- tWL-min-tck -- tDQSCK-min-tck -- tRL-min-tck -- tFAW-min-tck -- tXSR-min-tck -- tXP-min-tck -- tCKE-min-tck -- tCKESR-min-tck -- tMRD-min-tck - -Child nodes: -- The lpddr3 node may have one or more child nodes of type "lpddr3-timings". - "lpddr3-timings" provides AC timing parameters of the device for - a given speed-bin. Please see - Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3-timings.txt - for more information on "lpddr3-timings" - -Example: - -samsung_K3QF2F20DB: lpddr3 { - compatible = "samsung,K3QF2F20DB", "jedec,lpddr3"; - density = <16384>; - io-width = <32>; - manufacturer-id = <1>; - revision-id = <123 234>; - #address-cells = <1>; - #size-cells = <0>; - - tRFC-min-tck = <17>; - tRRD-min-tck = <2>; - tRPab-min-tck = <2>; - tRPpb-min-tck = <2>; - tRCD-min-tck = <3>; - tRC-min-tck = <6>; - tRAS-min-tck = <5>; - tWTR-min-tck = <2>; - tWR-min-tck = <7>; - tRTP-min-tck = <2>; - tW2W-C2C-min-tck = <0>; - tR2R-C2C-min-tck = <0>; - tWL-min-tck = <8>; - tDQSCK-min-tck = <5>; - tRL-min-tck = <14>; - tFAW-min-tck = <5>; - tXSR-min-tck = <12>; - tXP-min-tck = <2>; - tCKE-min-tck = <2>; - tCKESR-min-tck = <2>; - tMRD-min-tck = <5>; - - timings_samsung_K3QF2F20DB_800mhz: lpddr3-timings@800000000 { - compatible = "jedec,lpddr3-timings"; - /* workaround: 'reg' shows max-freq */ - reg = <800000000>; - min-freq = <100000000>; - tRFC = <65000>; - tRRD = <6000>; - tRPab = <12000>; - tRPpb = <12000>; - tRCD = <10000>; - tRC = <33750>; - tRAS = <23000>; - tWTR = <3750>; - tWR = <7500>; - tRTP = <3750>; - tW2W-C2C = <0>; - tR2R-C2C = <0>; - tFAW = <25000>; - tXSR = <70000>; - tXP = <3750>; - tCKE = <3750>; - tCKESR = <3750>; - tMRD = <7000>; - }; -} diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml new file mode 100644 index 000000000000..3be1db30bf41 --- /dev/null +++ b/Documentation/devicetree/bindings/memory-controllers/fsl/fsl,ifc.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/memory-controllers/fsl/fsl,ifc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: FSL/NXP Integrated Flash Controller + +maintainers: + - Li Yang <leoyang.li@nxp.com> + +description: | + NXP's integrated flash controller (IFC) is an advanced version of the + enhanced local bus controller which includes similar programming and signal + interfaces with an extended feature set. The IFC provides access to multiple + external memory types, such as NAND flash (SLC and MLC), NOR flash, EPROM, + SRAM and other memories where address and data are shared on a bus. + +properties: + $nodename: + pattern: "^memory-controller@[0-9a-f]+$" + + compatible: + const: fsl,ifc + + "#address-cells": + enum: [2, 3] + description: | + Should be either two or three. The first cell is the chipselect + number, and the remaining cells are the offset into the chipselect. + + "#size-cells": + enum: [1, 2] + description: | + Either one or two, depending on how large each chipselect can be. + + reg: + maxItems: 1 + + interrupts: + minItems: 1 + maxItems: 2 + description: | + IFC may have one or two interrupts. If two interrupt specifiers are + present, the first is the "common" interrupt (CM_EVTER_STAT), and the + second is the NAND interrupt (NAND_EVTER_STAT). If there is only one, + that interrupt reports both types of event. + + little-endian: + type: boolean + description: | + If this property is absent, the big-endian mode will be in use as default + for registers. + + ranges: + description: | + Each range corresponds to a single chipselect, and covers the entire + access window as configured. + +patternProperties: + "^.*@[a-f0-9]+(,[a-f0-9]+)+$": + type: object + description: | + Child device nodes describe the devices connected to IFC such as NOR (e.g. + cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices + like FPGAs, CPLDs, etc. + + required: + - compatible + - reg + +required: + - compatible + - reg + - interrupts + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + + memory-controller@ffe1e000 { + compatible = "fsl,ifc"; + #address-cells = <2>; + #size-cells = <1>; + reg = <0x0 0xffe1e000 0 0x2000>; + interrupts = <16 2 19 2>; + little-endian; + + /* NOR, NAND Flashes and CPLD on board */ + ranges = <0x0 0x0 0x0 0xee000000 0x02000000>, + <0x1 0x0 0x0 0xffa00000 0x00010000>, + <0x3 0x0 0x0 0xffb00000 0x00020000>; + + flash@0,0 { + #address-cells = <1>; + #size-cells = <1>; + compatible = "cfi-flash"; + reg = <0x0 0x0 0x2000000>; + bank-width = <2>; + device-width = <1>; + + partition@0 { + /* 32MB for user data */ + reg = <0x0 0x02000000>; + label = "NOR Data"; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt b/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt deleted file mode 100644 index 89427b018ba7..000000000000 --- a/Documentation/devicetree/bindings/memory-controllers/fsl/ifc.txt +++ /dev/null @@ -1,82 +0,0 @@ -Integrated Flash Controller - -Properties: -- name : Should be ifc -- compatible : should contain "fsl,ifc". The version of the integrated - flash controller can be found in the IFC_REV register at - offset zero. - -- #address-cells : Should be either two or three. The first cell is the - chipselect number, and the remaining cells are the - offset into the chipselect. -- #size-cells : Either one or two, depending on how large each chipselect - can be. -- reg : Offset and length of the register set for the device -- interrupts: IFC may have one or two interrupts. If two interrupt - specifiers are present, the first is the "common" - interrupt (CM_EVTER_STAT), and the second is the NAND - interrupt (NAND_EVTER_STAT). If there is only one, - that interrupt reports both types of event. - -- little-endian : If this property is absent, the big-endian mode will - be in use as default for registers. - -- ranges : Each range corresponds to a single chipselect, and covers - the entire access window as configured. - -Child device nodes describe the devices connected to IFC such as NOR (e.g. -cfi-flash) and NAND (fsl,ifc-nand). There might be board specific devices -like FPGAs, CPLDs, etc. - -Example: - - ifc@ffe1e000 { - compatible = "fsl,ifc", "simple-bus"; - #address-cells = <2>; - #size-cells = <1>; - reg = <0x0 0xffe1e000 0 0x2000>; - interrupts = <16 2 19 2>; - little-endian; - - /* NOR, NAND Flashes and CPLD on board */ - ranges = <0x0 0x0 0x0 0xee000000 0x02000000 - 0x1 0x0 0x0 0xffa00000 0x00010000 - 0x3 0x0 0x0 0xffb00000 0x00020000>; - - flash@0,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "cfi-flash"; - reg = <0x0 0x0 0x2000000>; - bank-width = <2>; - device-width = <1>; - - partition@0 { - /* 32MB for user data */ - reg = <0x0 0x02000000>; - label = "NOR Data"; - }; - }; - - flash@1,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,ifc-nand"; - reg = <0x1 0x0 0x10000>; - - partition@0 { - /* This location must not be altered */ - /* 1MB for u-boot Bootloader Image */ - reg = <0x0 0x00100000>; - label = "NAND U-Boot Image"; - read-only; - }; - }; - - cpld@3,0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "fsl,p1010rdb-cpld"; - reg = <0x3 0x0 0x000001f>; - }; - }; diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml index 3a82b0b27fa0..a98b359bf909 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-common.yaml @@ -16,7 +16,7 @@ description: | MediaTek SMI have two generations of HW architecture, here is the list which generation the SoCs use: generation 1: mt2701 and mt7623. - generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8192 and mt8195. + generation 2: mt2712, mt6779, mt8167, mt8173, mt8183, mt8186, mt8192 and mt8195. There's slight differences between the two SMI, for generation 2, the register which control the iommu port is at each larb's register base. But @@ -35,6 +35,7 @@ properties: - mediatek,mt8167-smi-common - mediatek,mt8173-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8186-smi-common - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp @@ -88,10 +89,9 @@ allOf: - mediatek,mt2701-smi-common then: properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 3 + maxItems: 3 clock-names: items: - const: apb @@ -108,10 +108,9 @@ allOf: required: - mediatek,smi properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 3 + maxItems: 3 clock-names: items: - const: apb @@ -127,16 +126,16 @@ allOf: enum: - mediatek,mt6779-smi-common - mediatek,mt8183-smi-common + - mediatek,mt8186-smi-common - mediatek,mt8192-smi-common - mediatek,mt8195-smi-common-vdo - mediatek,mt8195-smi-common-vpp then: properties: - clock: - items: - minItems: 4 - maxItems: 4 + clocks: + minItems: 4 + maxItems: 4 clock-names: items: - const: apb @@ -146,10 +145,9 @@ allOf: else: # for gen2 HW that don't have gals properties: - clock: - items: - minItems: 2 - maxItems: 2 + clocks: + minItems: 2 + maxItems: 2 clock-names: items: - const: apb diff --git a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml index eaeff1ada7f8..c886681f62a7 100644 --- a/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/mediatek,smi-larb.yaml @@ -23,6 +23,7 @@ properties: - mediatek,mt8167-smi-larb - mediatek,mt8173-smi-larb - mediatek,mt8183-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8192-smi-larb - mediatek,mt8195-smi-larb @@ -52,7 +53,7 @@ properties: maxItems: 1 mediatek,smi: - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle description: a phandle to the smi_common node. mediatek,larb-id: @@ -75,15 +76,16 @@ allOf: compatible: enum: - mediatek,mt8183-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8195-smi-larb then: properties: - clock: - items: - minItems: 3 - maxItems: 3 + clocks: + minItems: 2 + maxItems: 3 clock-names: + minItems: 2 items: - const: apb - const: smi @@ -91,10 +93,9 @@ allOf: else: properties: - clock: - items: - minItems: 2 - maxItems: 2 + clocks: + minItems: 2 + maxItems: 2 clock-names: items: - const: apb @@ -108,7 +109,7 @@ allOf: - mediatek,mt2701-smi-larb - mediatek,mt2712-smi-larb - mediatek,mt6779-smi-larb - - mediatek,mt8167-smi-larb + - mediatek,mt8186-smi-larb - mediatek,mt8192-smi-larb - mediatek,mt8195-smi-larb diff --git a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml index 294f1036420d..9a6dbf54b540 100644 --- a/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/renesas,rpc-if.yaml @@ -40,7 +40,8 @@ properties: - items: - enum: - renesas,r9a07g044-rpc-if # RZ/G2{L,LC} - - const: renesas,rzg2l-rpc-if # RZ/G2L family + - renesas,r9a07g054-rpc-if # RZ/V2L + - const: renesas,rzg2l-rpc-if reg: items: diff --git a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml index fe8639dcffab..f152243f6b18 100644 --- a/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml +++ b/Documentation/devicetree/bindings/memory-controllers/samsung,exynos5422-dmc.yaml @@ -45,14 +45,15 @@ properties: $ref: '/schemas/types.yaml#/definitions/phandle-array' minItems: 1 maxItems: 16 + items: + maxItems: 1 description: phandles of the PPMU events used by the controller. device-handle: $ref: '/schemas/types.yaml#/definitions/phandle' description: | phandle of the connected DRAM memory device. For more information please - refer to documentation file: - Documentation/devicetree/bindings/memory-controllers/ddr/lpddr3.txt + refer to jedec,lpddr3.yaml. operating-points-v2: true diff --git a/Documentation/devicetree/bindings/mfd/ab8500.txt b/Documentation/devicetree/bindings/mfd/ab8500.txt deleted file mode 100644 index 937b3e5505e0..000000000000 --- a/Documentation/devicetree/bindings/mfd/ab8500.txt +++ /dev/null @@ -1,282 +0,0 @@ -* AB8500 Multi-Functional Device (MFD) - -Required parent device properties: -- compatible : contains "stericsson,ab8500" or "stericsson,ab8505"; -- interrupts : contains the IRQ line for the AB8500 -- interrupt-controller : describes the AB8500 as an Interrupt Controller (has its own domain) -- #interrupt-cells : should be 2, for 2-cell format - - The first cell is the AB8500 local IRQ number - - The second cell is used to specify optional parameters - - 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 - -The AB8500 consists of a large and varied group of sub-devices: - -Device IRQ Names Supply Names Description ------- --------- ------------ ----------- -ab8500-bm : : : Battery Manager -ab8500-btemp : : : Battery Temperature -ab8500-charger : : : Battery Charger -ab8500-codec : : : Audio Codec -ab8500-fg : : vddadc : Fuel Gauge - : NCONV_ACCU : : Accumulate N Sample Conversion - : BATT_OVV : : Battery Over Voltage - : LOW_BAT_F : : LOW threshold battery voltage - : CC_INT_CALIB : : Coulomb Counter Internal Calibration - : CCEOC : : Coulomb Counter End of Conversion -ab8500-btemp : : vtvout : Battery Temperature - : BAT_CTRL_INDB : : Battery Removal Indicator - : BTEMP_LOW : : Btemp < BtempLow, if battery temperature is lower than -10°C - : BTEMP_LOW_MEDIUM : : BtempLow < Btemp < BtempMedium,if battery temperature is between -10 and 0°C - : BTEMP_MEDIUM_HIGH : : BtempMedium < Btemp < BtempHigh,if battery temperature is between 0°C and MaxTemp - : BTEMP_HIGH : : Btemp > BtempHigh, if battery temperature is higher than MaxTemp -ab8500-charger : : vddadc : Charger interface - : MAIN_CH_UNPLUG_DET : : main charger unplug detection management (not in 8505) - : MAIN_CHARGE_PLUG_DET : : main charger plug detection management (not in 8505) - : MAIN_EXT_CH_NOT_OK : : main charger not OK - : MAIN_CH_TH_PROT_R : : Die temp is above main charger - : MAIN_CH_TH_PROT_F : : Die temp is below main charger - : VBUS_DET_F : : VBUS falling detected - : VBUS_DET_R : : VBUS rising detected - : USB_LINK_STATUS : : USB link status has changed - : USB_CH_TH_PROT_R : : Die temp is above usb charger - : USB_CH_TH_PROT_F : : Die temp is below usb charger - : USB_CHARGER_NOT_OKR : : allowed USB charger not ok detection - : VBUS_OVV : : Overvoltage on Vbus ball detected (USB charge is stopped) - : CH_WD_EXP : : Charger watchdog detected -ab8500-gpadc : HW_CONV_END : vddadc : Analogue to Digital Converter - SW_CONV_END : : -ab8500-gpio : : : GPIO Controller (AB8500) -ab8505-gpio : : : GPIO Controller (AB8505) -ab8500-ponkey : ONKEY_DBF : : Power-on Key - ONKEY_DBR : : -ab8500-pwm : : : Pulse Width Modulator -ab8500-regulator : : : Regulators (AB8500) -ab8505-regulator : : : Regulators (AB8505) -ab8500-rtc : 60S : : Real Time Clock - : ALARM : : -ab8500-sysctrl : : : System Control -ab8500-usb : ID_WAKEUP_R : vddulpivio18 : Universal Serial Bus - : ID_WAKEUP_F : v-ape : - : VBUS_DET_F : musb_1v8 : - : VBUS_DET_R : : - : USB_LINK_STATUS : : - : USB_ADP_PROBE_PLUG : : - : USB_ADP_PROBE_UNPLUG : : - -Required child device properties: -- compatible : "stericsson,ab8500-[bm|btemp|charger|fg|gpadc|gpio|ponkey| - pwm|regulator|rtc|sysctrl|usb]"; - - A few child devices require ADC channels from the GPADC node. Those follow the - standard bindings from - https://github.com/devicetree-org/dt-schema/blob/master/schemas/iio/iio-consumer.yaml - and Documentation/devicetree/bindings/iio/adc/adc.yaml - - abx500-temp : io-channels "aux1" and "aux2" for measuring external - temperatures. - ab8500-fg : io-channel "main_bat_v" for measuring main battery voltage, - ab8500-btemp : io-channels "btemp_ball" and "bat_ctrl" for measuring the - battery voltage. - ab8500-charger : io-channels "main_charger_v", "main_charger_c", "vbus_v", - "usb_charger_c" for measuring voltage and current of the - different charging supplies. - -Optional child device properties: -- interrupts : contains the device IRQ(s) using the 2-cell format (see above) -- interrupt-names : contains names of IRQ resource in the order in which they were - supplied in the interrupts property -- <supply_name>-supply : contains a phandle to the regulator supply node in Device Tree - -Non-standard child device properties: - - Audio CODEC: - - stericsson,amic[1|2]-type-single-ended : Single-ended Analoge Mic (default: differential) - - stericsson,amic1a-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,amic1b-bias-vamic2 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,amic2-bias-vamic1 : Analoge Mic wishes to use a non-standard Vamic - - stericsson,earpeice-cmv : Earpeice voltage (only: 950 | 1100 | 1270 | 1580) - -ab8500 { - compatible = "stericsson,ab8500"; - interrupts = <0 40 0x4>; - interrupt-controller; - #interrupt-cells = <2>; - - ab8500-rtc { - compatible = "stericsson,ab8500-rtc"; - interrupts = <17 0x4 - 18 0x4>; - interrupt-names = "60S", "ALARM"; - }; - - ab8500-gpadc { - compatible = "stericsson,ab8500-gpadc"; - interrupts = <32 0x4 - 39 0x4>; - interrupt-names = "HW_CONV_END", "SW_CONV_END"; - vddadc-supply = <&ab8500_ldo_tvout_reg>; - #address-cells = <1>; - #size-cells = <0>; - #io-channel-cells = <1>; - - /* GPADC channels */ - bat_ctrl: channel@1 { - reg = <0x01>; - }; - btemp_ball: channel@2 { - reg = <0x02>; - }; - main_charger_v: channel@3 { - reg = <0x03>; - }; - acc_detect1: channel@4 { - reg = <0x04>; - }; - acc_detect2: channel@5 { - reg = <0x05>; - }; - adc_aux1: channel@6 { - reg = <0x06>; - }; - adc_aux2: channel@7 { - reg = <0x07>; - }; - main_batt_v: channel@8 { - reg = <0x08>; - }; - vbus_v: channel@9 { - reg = <0x09>; - }; - main_charger_c: channel@a { - reg = <0x0a>; - }; - usb_charger_c: channel@b { - reg = <0x0b>; - }; - bk_bat_v: channel@c { - reg = <0x0c>; - }; - die_temp: channel@d { - reg = <0x0d>; - }; - usb_id: channel@e { - reg = <0x0e>; - }; - xtal_temp: channel@12 { - reg = <0x12>; - }; - vbat_true_meas: channel@13 { - reg = <0x13>; - }; - bat_ctrl_and_ibat: channel@1c { - reg = <0x1c>; - }; - vbat_meas_and_ibat: channel@1d { - reg = <0x1d>; - }; - vbat_true_meas_and_ibat: channel@1e { - reg = <0x1e>; - }; - bat_temp_and_ibat: channel@1f { - reg = <0x1f>; - }; - }; - - ab8500_temp { - compatible = "stericsson,abx500-temp"; - io-channels = <&gpadc 0x06>, - <&gpadc 0x07>; - io-channel-name = "aux1", "aux2"; - }; - - ab8500_battery: ab8500_battery { - stericsson,battery-type = "LIPO"; - thermistor-on-batctrl; - }; - - ab8500_fg { - compatible = "stericsson,ab8500-fg"; - battery = <&ab8500_battery>; - io-channels = <&gpadc 0x08>; - io-channel-name = "main_bat_v"; - }; - - ab8500_btemp { - compatible = "stericsson,ab8500-btemp"; - battery = <&ab8500_battery>; - io-channels = <&gpadc 0x02>, - <&gpadc 0x01>; - io-channel-name = "btemp_ball", - "bat_ctrl"; - }; - - ab8500_charger { - compatible = "stericsson,ab8500-charger"; - battery = <&ab8500_battery>; - vddadc-supply = <&ab8500_ldo_tvout_reg>; - io-channels = <&gpadc 0x03>, - <&gpadc 0x0a>, - <&gpadc 0x09>, - <&gpadc 0x0b>; - io-channel-name = "main_charger_v", - "main_charger_c", - "vbus_v", - "usb_charger_c"; - }; - - ab8500-usb { - compatible = "stericsson,ab8500-usb"; - interrupts = < 90 0x4 - 96 0x4 - 14 0x4 - 15 0x4 - 79 0x4 - 74 0x4 - 75 0x4>; - interrupt-names = "ID_WAKEUP_R", - "ID_WAKEUP_F", - "VBUS_DET_F", - "VBUS_DET_R", - "USB_LINK_STATUS", - "USB_ADP_PROBE_PLUG", - "USB_ADP_PROBE_UNPLUG"; - vddulpivio18-supply = <&ab8500_ldo_intcore_reg>; - v-ape-supply = <&db8500_vape_reg>; - musb_1v8-supply = <&db8500_vsmps2_reg>; - }; - - ab8500-ponkey { - compatible = "stericsson,ab8500-ponkey"; - interrupts = <6 0x4 - 7 0x4>; - interrupt-names = "ONKEY_DBF", "ONKEY_DBR"; - }; - - ab8500-sysctrl { - compatible = "stericsson,ab8500-sysctrl"; - }; - - ab8500-pwm { - compatible = "stericsson,ab8500-pwm"; - }; - - codec: ab8500-codec { - compatible = "stericsson,ab8500-codec"; - - stericsson,earpeice-cmv = <950>; /* Units in mV. */ - }; - - ab8500-regulators { - compatible = "stericsson,ab8500-regulator"; - - ab8500_ldo_aux1_reg: ab8500_ldo_aux1 { - /* - * See: Documentation/devicetree/bindings/regulator/regulator.txt - * for more information on regulators - */ - }; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml index be4a2df71c25..b85819fbb07c 100644 --- a/Documentation/devicetree/bindings/mfd/brcm,cru.yaml +++ b/Documentation/devicetree/bindings/mfd/brcm,cru.yaml @@ -39,7 +39,7 @@ patternProperties: '^phy@[a-f0-9]+$': $ref: ../phy/bcm-ns-usb2-phy.yaml - '^pin-controller@[a-f0-9]+$': + '^pinctrl@[a-f0-9]+$': $ref: ../pinctrl/brcm,ns-pinmux.yaml '^syscon@[a-f0-9]+$': @@ -94,7 +94,7 @@ examples: reg = <0x180 0x4>; }; - pin-controller@1c0 { + pinctrl@1c0 { compatible = "brcm,bcm4708-pinmux"; reg = <0x1c0 0x24>; reg-names = "cru_gpio_control"; diff --git a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml index c00ad3e21c21..ad285cb480c9 100644 --- a/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml +++ b/Documentation/devicetree/bindings/mfd/cirrus,lochnagar.yaml @@ -126,7 +126,7 @@ properties: clock-frequency: const: 12288000 - lochnagar-pinctrl: + pinctrl: type: object $ref: /schemas/pinctrl/cirrus,lochnagar.yaml# @@ -255,7 +255,7 @@ required: - reg - reset-gpios - lochnagar-clk - - lochnagar-pinctrl + - pinctrl additionalProperties: false @@ -293,7 +293,7 @@ examples: clock-frequency = <32768>; }; - lochnagar-pinctrl { + pinctrl { compatible = "cirrus,lochnagar-pinctrl"; gpio-controller; diff --git a/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.yaml new file mode 100644 index 000000000000..f6967c1f6235 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/delta,tn48m-cpld.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/delta,tn48m-cpld.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD controller + +maintainers: + - Robert Marko <robert.marko@sartura.hr> + +description: | + Lattice CPLD onboard the TN48M switches is used for system + management. + + It provides information about the hardware model, revision, + PSU status etc. + + It is also being used as a GPIO expander and reset controller + for the switch MAC-s and other peripherals. + +properties: + compatible: + const: delta,tn48m-cpld + + reg: + description: + I2C device address. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +required: + - compatible + - reg + - "#address-cells" + - "#size-cells" + +patternProperties: + "^gpio(@[0-9a-f]+)?$": + $ref: ../gpio/delta,tn48m-gpio.yaml + + "^reset-controller?$": + $ref: ../reset/delta,tn48m-reset.yaml + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + cpld@41 { + compatible = "delta,tn48m-cpld"; + reg = <0x41>; + #address-cells = <1>; + #size-cells = <0>; + + gpio@31 { + compatible = "delta,tn48m-gpo"; + reg = <0x31>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@3a { + compatible = "delta,tn48m-gpi"; + reg = <0x3a>; + gpio-controller; + #gpio-cells = <2>; + }; + + gpio@40 { + compatible = "delta,tn48m-gpi"; + reg = <0x40>; + gpio-controller; + #gpio-cells = <2>; + }; + + reset-controller { + compatible = "delta,tn48m-reset"; + #reset-cells = <1>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml index d1f53bd449f7..afec0bd2f1de 100644 --- a/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml +++ b/Documentation/devicetree/bindings/mfd/google,cros-ec.yaml @@ -31,25 +31,21 @@ properties: controller-data: description: - SPI controller data, see bindings/spi/spi-samsung.txt + SPI controller data, see bindings/spi/samsung,spi-peripheral-props.yaml type: object google,cros-ec-spi-pre-delay: description: This property specifies the delay in usecs between the assertion of the CS and the first clock pulse. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 0 - - minimum: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 google,cros-ec-spi-msg-delay: description: This property specifies the delay in usecs between messages. - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 - - default: 0 - - minimum: 0 + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 google,has-vbc-nvram: description: @@ -89,6 +85,10 @@ properties: ec-pwm: $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" + deprecated: true + + pwm: + $ref: "/schemas/pwm/google,cros-ec-pwm.yaml#" keyboard-controller: $ref: "/schemas/input/google,cros-ec-keyb.yaml#" @@ -148,18 +148,21 @@ patternProperties: required: - compatible -if: - properties: - compatible: - contains: - enum: - - google,cros-ec-i2c - - google,cros-ec-rpmsg -then: - properties: - google,cros-ec-spi-pre-delay: false - google,cros-ec-spi-msg-delay: false - spi-max-frequency: false +allOf: + - if: + properties: + compatible: + contains: + enum: + - google,cros-ec-i2c + - google,cros-ec-rpmsg + then: + properties: + google,cros-ec-spi-pre-delay: false + google,cros-ec-spi-msg-delay: false + spi-max-frequency: false + else: + $ref: /schemas/spi/spi-peripheral-props.yaml additionalProperties: false @@ -200,7 +203,7 @@ examples: spi-max-frequency = <5000000>; proximity { - compatible = "google,cros-ec-mkbp-proximity"; + compatible = "google,cros-ec-mkbp-proximity"; }; cbas { diff --git a/Documentation/devicetree/bindings/mfd/max14577.txt b/Documentation/devicetree/bindings/mfd/max14577.txt deleted file mode 100644 index be11943a0560..000000000000 --- a/Documentation/devicetree/bindings/mfd/max14577.txt +++ /dev/null @@ -1,147 +0,0 @@ -Maxim MAX14577/77836 Multi-Function Device - -MAX14577 is a Multi-Function Device with Micro-USB Interface Circuit, Li+ -Battery Charger and SFOUT LDO output for powering USB devices. It is -interfaced to host controller using I2C. - -MAX77836 additionally contains PMIC (with two LDO regulators) and Fuel Gauge. -For the description of Fuel Gauge low SOC alert interrupt see: -../power/supply/max17040_battery.txt - - -Required properties: -- compatible : Must be "maxim,max14577" or "maxim,max77836". -- reg : I2C slave address for the max14577 chip (0x25 for max14577/max77836) -- interrupts : IRQ line for the chip. - - -Required nodes: - - charger : - Node for configuring the charger driver. - Required properties: - - compatible : "maxim,max14577-charger" - or "maxim,max77836-charger" - - maxim,fast-charge-uamp : Current in uA for Fast Charge; - Valid values: - - for max14577: 90000 - 950000; - - for max77836: 45000 - 475000; - - maxim,eoc-uamp : Current in uA for End-Of-Charge mode; - Valid values: - - for max14577: 50000 - 200000; - - for max77836: 5000 - 100000; - - maxim,ovp-uvolt : OverVoltage Protection Threshold in uV; - In an overvoltage condition, INT asserts and charging - stops. Valid values: - - 6000000, 6500000, 7000000, 7500000; - - maxim,constant-uvolt : Battery Constant Voltage in uV; - Valid values: - - 4000000 - 4280000 (step by 20000); - - 4350000; - - -Optional nodes: -- max14577-muic/max77836-muic : - Node used only by extcon consumers. - Required properties: - - compatible : "maxim,max14577-muic" or "maxim,max77836-muic" - -- regulators : - Required properties: - - compatible : "maxim,max14577-regulator" - or "maxim,max77836-regulator" - - May contain a sub-node per regulator from the list below. Each - sub-node should contain the constraints and initialization information - for that regulator. See regulator.txt for a description of standard - properties for these sub-nodes. - - List of valid regulator names: - - for max14577: CHARGER, SAFEOUT. - - for max77836: CHARGER, SAFEOUT, LDO1, LDO2. - - The SAFEOUT is a fixed voltage regulator so there is no need to specify - voltages for it. - - -Example: - -#include <dt-bindings/interrupt-controller/irq.h> - -max14577@25 { - compatible = "maxim,max14577"; - reg = <0x25>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - muic: max14577-muic { - compatible = "maxim,max14577-muic"; - }; - - regulators { - compatible = "maxim,max14577-regulator"; - - SAFEOUT { - regulator-name = "SAFEOUT"; - }; - CHARGER { - regulator-name = "CHARGER"; - regulator-min-microamp = <90000>; - regulator-max-microamp = <950000>; - regulator-boot-on; - }; - }; - - charger { - compatible = "maxim,max14577-charger"; - - maxim,constant-uvolt = <4350000>; - maxim,fast-charge-uamp = <450000>; - maxim,eoc-uamp = <50000>; - maxim,ovp-uvolt = <6500000>; - }; -}; - - -max77836@25 { - compatible = "maxim,max77836"; - reg = <0x25>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - muic: max77836-muic { - compatible = "maxim,max77836-muic"; - }; - - regulators { - compatible = "maxim,max77836-regulator"; - - SAFEOUT { - regulator-name = "SAFEOUT"; - }; - CHARGER { - regulator-name = "CHARGER"; - regulator-min-microamp = <90000>; - regulator-max-microamp = <950000>; - regulator-boot-on; - }; - LDO1 { - regulator-name = "LDO1"; - regulator-min-microvolt = <2700000>; - regulator-max-microvolt = <2700000>; - }; - LDO2 { - regulator-name = "LDO2"; - regulator-min-microvolt = <800000>; - regulator-max-microvolt = <3950000>; - }; - }; - - charger { - compatible = "maxim,max77836-charger"; - - maxim,constant-uvolt = <4350000>; - maxim,fast-charge-uamp = <225000>; - maxim,eoc-uamp = <7500>; - maxim,ovp-uvolt = <6500000>; - }; -}; diff --git a/Documentation/devicetree/bindings/mfd/max77693.txt b/Documentation/devicetree/bindings/mfd/max77693.txt deleted file mode 100644 index 1032df14498b..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77693.txt +++ /dev/null @@ -1,194 +0,0 @@ -Maxim MAX77693 multi-function device - -MAX77693 is a Multifunction device with the following submodules: -- PMIC, -- CHARGER, -- LED, -- MUIC, -- HAPTIC - -It is interfaced to host controller using i2c. -This document describes the bindings for the mfd device. - -Required properties: -- compatible : Must be "maxim,max77693". -- reg : Specifies the i2c slave address of PMIC block. -- interrupts : This i2c device has an IRQ line connected to the main SoC. - -Optional properties: -- regulators : The regulators of max77693 have to be instantiated under subnode - named "regulators" using the following format. - - regulators { - regulator-compatible = ESAFEOUT1/ESAFEOUT2/CHARGER - standard regulator constraints[*]. - }; - - [*] refer Documentation/devicetree/bindings/regulator/regulator.txt - -- haptic : The MAX77693 haptic device utilises a PWM controlled motor to provide - users with tactile feedback. PWM period and duty-cycle are varied in - order to provide the appropriate level of feedback. - - Required properties: - - compatible : Must be "maxim,max77693-haptic" - - haptic-supply : power supply for the haptic motor - [*] refer Documentation/devicetree/bindings/regulator/regulator.txt - - pwms : phandle to the physical PWM(Pulse Width Modulation) device. - PWM properties should be named "pwms". And number of cell is different - for each pwm device. - To get more information, please refer to documentation. - [*] refer Documentation/devicetree/bindings/pwm/pwm.txt - -- charger : Node configuring the charger driver. - If present, required properties: - - compatible : Must be "maxim,max77693-charger". - - Optional properties (if not set, defaults will be used): - - maxim,constant-microvolt : Battery constant voltage in uV. The charger - will operate in fast charge constant current mode till battery voltage - reaches this level. Then the charger will switch to fast charge constant - voltage mode. Also vsys (system voltage) will be set to this value when - DC power is supplied but charger is not enabled. - Valid values: 3650000 - 4400000, step by 25000 (rounded down) - Default: 4200000 - - - maxim,min-system-microvolt : Minimal system voltage in uV. - Valid values: 3000000 - 3700000, step by 100000 (rounded down) - Default: 3600000 - - - maxim,thermal-regulation-celsius : Temperature in Celsius for entering - high temperature charging mode. If die temperature exceeds this value - the charging current will be reduced by 105 mA/Celsius. - Valid values: 70, 85, 100, 115 - Default: 100 - - - maxim,battery-overcurrent-microamp : Overcurrent protection threshold - in uA (current from battery to system). - Valid values: 2000000 - 3500000, step by 250000 (rounded down) - Default: 3500000 - - - maxim,charge-input-threshold-microvolt : Threshold voltage in uV for - triggering input voltage regulation loop. If input voltage decreases - below this value, the input current will be reduced to reach the - threshold voltage. - Valid values: 4300000, 4700000, 4800000, 4900000 - Default: 4300000 - -- led : the LED submodule device node - -There are two LED outputs available - FLED1 and FLED2. Each of them can -control a separate LED or they can be connected together to double -the maximum current for a single connected LED. One LED is represented -by one child node. - -Required properties: -- compatible : Must be "maxim,max77693-led". - -Optional properties: -- maxim,boost-mode : - In boost mode the device can produce up to 1.2A of total current - on both outputs. The maximum current on each output is reduced - to 625mA then. If not enabled explicitly, boost setting defaults to - LEDS_BOOST_FIXED in case both current sources are used. - Possible values: - LEDS_BOOST_OFF (0) - no boost, - LEDS_BOOST_ADAPTIVE (1) - adaptive mode, - LEDS_BOOST_FIXED (2) - fixed mode. -- maxim,boost-mvout : Output voltage of the boost module in millivolts. - Valid values: 3300 - 5500, step by 25 (rounded down) - Default: 3300 -- maxim,mvsys-min : Low input voltage level in millivolts. Flash is not fired - if chip estimates that system voltage could drop below this level due - to flash power consumption. - Valid values: 2400 - 3400, step by 33 (rounded down) - Default: 2400 - -Required properties for the LED child node: -- led-sources : see Documentation/devicetree/bindings/leds/common.txt; - device current output identifiers: 0 - FLED1, 1 - FLED2 -- led-max-microamp : see Documentation/devicetree/bindings/leds/common.txt - Valid values for a LED connected to one FLED output: - 15625 - 250000, step by 15625 (rounded down) - Valid values for a LED connected to both FLED outputs: - 15625 - 500000, step by 15625 (rounded down) -- flash-max-microamp : see Documentation/devicetree/bindings/leds/common.txt - Valid values for a single LED connected to one FLED output - (boost mode must be turned off): - 15625 - 1000000, step by 15625 (rounded down) - Valid values for a single LED connected to both FLED outputs: - 15625 - 1250000, step by 15625 (rounded down) - Valid values for two LEDs case: - 15625 - 625000, step by 15625 (rounded down) -- flash-max-timeout-us : see Documentation/devicetree/bindings/leds/common.txt - Valid values: 62500 - 1000000, step by 62500 (rounded down) - -Optional properties for the LED child node: -- label : see Documentation/devicetree/bindings/leds/common.txt - -Optional nodes: -- max77693-muic : - Node used only by extcon consumers. - Required properties: - - compatible : "maxim,max77693-muic" - -Example: -#include <dt-bindings/leds/common.h> - - max77693@66 { - compatible = "maxim,max77693"; - reg = <0x66>; - interrupt-parent = <&gpx1>; - interrupts = <5 IRQ_TYPE_LEVEL_LOW>; - - regulators { - esafeout@1 { - regulator-compatible = "ESAFEOUT1"; - regulator-name = "ESAFEOUT1"; - regulator-boot-on; - }; - esafeout@2 { - regulator-compatible = "ESAFEOUT2"; - regulator-name = "ESAFEOUT2"; - }; - charger@0 { - regulator-compatible = "CHARGER"; - regulator-name = "CHARGER"; - regulator-min-microamp = <60000>; - regulator-max-microamp = <2580000>; - regulator-boot-on; - }; - }; - - haptic { - compatible = "maxim,max77693-haptic"; - haptic-supply = <&haptic_supply>; - pwms = <&pwm 0 40000 0>; - pwm-names = "haptic"; - }; - - charger { - compatible = "maxim,max77693-charger"; - - maxim,constant-microvolt = <4200000>; - maxim,min-system-microvolt = <3600000>; - maxim,thermal-regulation-celsius = <75>; - maxim,battery-overcurrent-microamp = <3000000>; - maxim,charge-input-threshold-microvolt = <4300000>; - }; - - led { - compatible = "maxim,max77693-led"; - maxim,boost-mode = <LEDS_BOOST_FIXED>; - maxim,boost-mvout = <5000>; - maxim,mvsys-min = <2400>; - - camera_flash: flash-led { - label = "max77693-flash"; - led-sources = <0>, <1>; - led-max-microamp = <500000>; - flash-max-microamp = <1250000>; - flash-max-timeout-us = <1000000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/max77802.txt b/Documentation/devicetree/bindings/mfd/max77802.txt deleted file mode 100644 index 09decac20d91..000000000000 --- a/Documentation/devicetree/bindings/mfd/max77802.txt +++ /dev/null @@ -1,25 +0,0 @@ -Maxim MAX77802 multi-function device - -The Maxim MAX77802 is a Power Management IC (PMIC) that contains 10 high -efficiency Buck regulators, 32 Low-DropOut (LDO) regulators used to power -up application processors and peripherals, a 2-channel 32kHz clock outputs, -a Real-Time-Clock (RTC) and a I2C interface to program the individual -regulators, clocks outputs and the RTC. - -Bindings for the built-in 32k clock generator block and -regulators are defined in ../clk/maxim,max77802.txt and -../regulator/max77802.txt respectively. - -Required properties: -- compatible : Must be "maxim,max77802" -- reg : Specifies the I2C slave address of PMIC block. -- interrupts : I2C device IRQ line connected to the main SoC. - -Example: - - max77802: pmic@9 { - compatible = "maxim,max77802"; - interrupt-parent = <&intc>; - interrupts = <26 IRQ_TYPE_NONE>; - reg = <0x09>; - }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml new file mode 100644 index 000000000000..27870b8760a6 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max14577.yaml @@ -0,0 +1,195 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX14577 is a MicroUSB and Companion Power Management IC which + includes voltage safeout regulators, charger and MicroUSB management IC. + + The Maxim MAX77836 is a MicroUSB and Companion Power Management IC which + includes voltage safeout and LDO regulators, charger, fuel-gauge and MicroUSB + management IC. + +properties: + compatible: + enum: + - maxim,max14577 + - maxim,max77836 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + wakeup-source: true + + charger: + $ref: /schemas/power/supply/maxim,max14577.yaml + + extcon: + type: object + properties: + compatible: + enum: + - maxim,max14577-muic + - maxim,max77836-muic + + required: + - compatible + + regulators: + $ref: /schemas/regulator/maxim,max14577.yaml + +required: + - compatible + - interrupts + - reg + - charger + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577 + then: + properties: + charger: + properties: + compatible: + const: maxim,max14577-charger + extcon: + properties: + compatible: + const: maxim,max14577-muic + regulator: + properties: + compatible: + const: maxim,max14577-regulator + else: + properties: + charger: + properties: + compatible: + const: maxim,max77836-charger + extcon: + properties: + compatible: + const: maxim,max77836-muic + regulator: + properties: + compatible: + const: maxim,max77836-regulator + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@25 { + compatible = "maxim,max14577"; + reg = <0x25>; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + + extcon { + compatible = "maxim,max14577-muic"; + }; + + regulators { + compatible = "maxim,max14577-regulator"; + + SAFEOUT { + regulator-name = "SAFEOUT"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <90000>; + regulator-max-microamp = <950000>; + regulator-boot-on; + }; + }; + + charger { + compatible = "maxim,max14577-charger"; + + maxim,constant-uvolt = <4350000>; + maxim,fast-charge-uamp = <450000>; + maxim,eoc-uamp = <50000>; + maxim,ovp-uvolt = <6500000>; + }; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@25 { + compatible = "maxim,max77836"; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_NONE>; + reg = <0x25>; + wakeup-source; + + extcon { + compatible = "maxim,max77836-muic"; + }; + + regulators { + compatible = "maxim,max77836-regulator"; + + SAFEOUT { + regulator-name = "SAFEOUT"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <45000>; + regulator-max-microamp = <475000>; + regulator-boot-on; + }; + + LDO1 { + regulator-name = "MOT_2.7V"; + regulator-min-microvolt = <1100000>; + regulator-max-microvolt = <2700000>; + }; + + LDO2 { + regulator-name = "UNUSED_LDO2"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <3950000>; + }; + }; + + charger { + compatible = "maxim,max77836-charger"; + + maxim,constant-uvolt = <4350000>; + maxim,fast-charge-uamp = <225000>; + maxim,eoc-uamp = <7500>; + maxim,ovp-uvolt = <6500000>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml new file mode 100644 index 000000000000..906101197e11 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77693.yaml @@ -0,0 +1,143 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX77693 is a MicroUSB and Companion Power Management IC which + includes voltage current regulators, charger, LED/flash, haptic motor driver + and MicroUSB management IC. + +properties: + compatible: + const: maxim,max77693 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + charger: + $ref: /schemas/power/supply/maxim,max77693.yaml + + led: + $ref: /schemas/leds/maxim,max77693.yaml + + max77693-muic: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77693-muic + + required: + - compatible + + motor-driver: + type: object + additionalProperties: false + + properties: + compatible: + const: maxim,max77693-haptic + + haptic-supply: + description: Power supply to the haptic motor + + pwms: + maxItems: 1 + + required: + - compatible + - haptic-supply + - pwms + + regulators: + $ref: ../regulator/maxim,max77693.yaml + description: + List of child nodes that specify the regulators. + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/leds/common.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max77693"; + reg = <0x66>; + interrupt-parent = <&gpx1>; + interrupts = <5 IRQ_TYPE_LEVEL_LOW>; + + regulators { + ESAFEOUT1 { + regulator-name = "ESAFEOUT1"; + }; + + ESAFEOUT2 { + regulator-name = "ESAFEOUT2"; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <60000>; + regulator-max-microamp = <2580000>; + }; + }; + + motor-driver { + compatible = "maxim,max77693-haptic"; + haptic-supply = <&ldo26_reg>; + pwms = <&pwm 0 38022 0>; + }; + + charger { + compatible = "maxim,max77693-charger"; + + maxim,constant-microvolt = <4350000>; + maxim,min-system-microvolt = <3600000>; + maxim,thermal-regulation-celsius = <100>; + maxim,battery-overcurrent-microamp = <3500000>; + maxim,charge-input-threshold-microvolt = <4300000>; + }; + + led { + compatible = "maxim,max77693-led"; + maxim,boost-mode = <LEDS_BOOST_FIXED>; + maxim,boost-mvout = <5000>; + maxim,mvsys-min = <2400>; + + flash-led { + label = "max77693-flash"; + function = LED_FUNCTION_FLASH; + color = <LED_COLOR_ID_WHITE>; + led-sources = <0>, <1>; + led-max-microamp = <500000>; + flash-max-microamp = <1250000>; + flash-max-timeout-us = <1000000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml new file mode 100644 index 000000000000..74a6867d3c82 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77714.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77714.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MAX77714 PMIC with GPIO, RTC and watchdog from Maxim Integrated. + +maintainers: + - Luca Ceresoli <luca@lucaceresoli.net> + +description: | + MAX77714 is a Power Management IC with 4 buck regulators, 9 + low-dropout regulators, 8 GPIOs, RTC and watchdog. + +properties: + compatible: + const: maxim,max77714 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + description: + The first cell is the IRQ number, the second cell is the trigger type. + + regulators: + type: object + additionalProperties: false + + patternProperties: + '^(buck[0-3]|ldo[0-8])$': + type: object + unevaluatedProperties: false + $ref: /schemas/regulator/regulator.yaml# + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - "#interrupt-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@1c { + compatible = "maxim,max77714"; + reg = <0x1c>; + interrupt-parent = <&gpio2>; + interrupts = <3 IRQ_TYPE_LEVEL_LOW>; + + interrupt-controller; + #interrupt-cells = <2>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml new file mode 100644 index 000000000000..baa1346ac5d5 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77802.yaml @@ -0,0 +1,194 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77802 Power Management IC + +maintainers: + - Javier Martinez Canillas <javier@dowhile0.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77802 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77802 is a Power Management IC which includes voltage and + current regulators (10 high efficiency Buck regulators and 32 Low-DropOut + (LDO)), RTC and clock outputs. + + The MAX77802 provides two 32.768khz clock outputs that can be controlled + (gated/ungated) over I2C. The clock IDs are defined as preprocessor macros + in dt-bindings/clock/maxim,max77802.h. + +properties: + compatible: + const: maxim,max77802 + + '#clock-cells': + const: 1 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + regulators: + $ref: /schemas/regulator/maxim,max77802.yaml + description: + List of child nodes that specify the regulators. + + inb1-supply: + description: Power supply for buck1 + inb2-supply: + description: Power supply for buck2 + inb3-supply: + description: Power supply for buck3 + inb4-supply: + description: Power supply for buck4 + inb5-supply: + description: Power supply for buck5 + inb6-supply: + description: Power supply for buck6 + inb7-supply: + description: Power supply for buck7 + inb8-supply: + description: Power supply for buck8 + inb9-supply: + description: Power supply for buck9 + inb10-supply: + description: Power supply for buck10 + + inl1-supply: + description: Power supply for LDO8, LDO15 + inl2-supply: + description: Power supply for LDO17, LDO27, LDO30, LDO35 + inl3-supply: + description: Power supply for LDO3, LDO5, LDO7, LDO7 + inl4-supply: + description: Power supply for LDO10, LDO11, LDO13, LDO14 + inl5-supply: + description: Power supply for LDO9, LDO19 + inl6-supply: + description: Power supply for LDO4, LDO21, LDO24, LDO33 + inl7-supply: + description: Power supply for LDO18, LDO20, LDO28, LDO29 + inl9-supply: + description: Power supply for LDO12, LDO23, LDO25, LDO26, LDO32, LDO34 + inl10-supply: + description: Power supply for LDO1, LDO2 + + wakeup-source: true + +required: + - compatible + - '#clock-cells' + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/regulator/maxim,max77802.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@9 { + compatible = "maxim,max77802"; + interrupt-parent = <&gpx3>; + interrupts = <1 IRQ_TYPE_NONE>; + pinctrl-names = "default"; + pinctrl-0 = <&max77802_irq>, <&pmic_selb>, + <&pmic_dvs_1>, <&pmic_dvs_2>, <&pmic_dvs_3>; + wakeup-source; + reg = <0x9>; + #clock-cells = <1>; + + inb1-supply = <&tps65090_dcdc2>; + inb2-supply = <&tps65090_dcdc1>; + inb3-supply = <&tps65090_dcdc2>; + inb4-supply = <&tps65090_dcdc2>; + inb5-supply = <&tps65090_dcdc1>; + inb6-supply = <&tps65090_dcdc2>; + inb7-supply = <&tps65090_dcdc1>; + inb8-supply = <&tps65090_dcdc1>; + inb9-supply = <&tps65090_dcdc1>; + inb10-supply = <&tps65090_dcdc1>; + + inl1-supply = <&buck5_reg>; + inl2-supply = <&buck7_reg>; + inl3-supply = <&buck9_reg>; + inl4-supply = <&buck9_reg>; + inl5-supply = <&buck9_reg>; + inl6-supply = <&tps65090_dcdc2>; + inl7-supply = <&buck9_reg>; + inl9-supply = <&tps65090_dcdc2>; + inl10-supply = <&buck7_reg>; + + regulators { + BUCK1 { + regulator-name = "vdd_mif"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1300000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <12500>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + BUCK2 { + regulator-name = "vdd_arm"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <1500000>; + regulator-always-on; + regulator-boot-on; + regulator-ramp-delay = <12500>; + regulator-coupled-with = <&buck3_reg>; + regulator-coupled-max-spread = <300000>; + regulator-state-mem { + regulator-off-in-suspend; + }; + }; + + // ... + + BUCK10 { + regulator-name = "vdd_1v8"; + regulator-min-microvolt = <1800000>; + regulator-max-microvolt = <1800000>; + regulator-always-on; + regulator-boot-on; + regulator-state-mem { + regulator-on-in-suspend; + }; + }; + + LDO1 { + regulator-name = "vdd_1v0"; + regulator-min-microvolt = <1000000>; + regulator-max-microvolt = <1000000>; + regulator-always-on; + regulator-initial-mode = <MAX77802_OPMODE_NORMAL>; + regulator-state-mem { + regulator-on-in-suspend; + regulator-mode = <MAX77802_OPMODE_LP>; + }; + }; + + // ... + + LDO35 { + regulator-name = "ldo_35"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml new file mode 100644 index 000000000000..61a0f9dcb983 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/maxim,max77843.yaml @@ -0,0 +1,144 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB + Integrated Circuit (MUIC). + + The Maxim MAX77843 is a MicroUSB and Companion Power Management IC which + includes voltage current regulators, charger, fuel-gauge, haptic motor driver + and MicroUSB management IC. + +properties: + compatible: + const: maxim,max77843 + + interrupts: + maxItems: 1 + + reg: + maxItems: 1 + + extcon: + $ref: /schemas/extcon/maxim,max77843.yaml + + motor-driver: + type: object + properties: + compatible: + const: maxim,max77843-haptic + + haptic-supply: + description: Power supply to the haptic motor + + pwms: + maxItems: 1 + + required: + - compatible + - haptic-supply + - pwms + + regulators: + $ref: /schemas/regulator/maxim,max77843.yaml + +required: + - compatible + - interrupts + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@66 { + compatible = "maxim,max77843"; + interrupt-parent = <&gpa1>; + interrupts = <5 IRQ_TYPE_EDGE_FALLING>; + reg = <0x66>; + + extcon { + compatible = "maxim,max77843-muic"; + + connector { + compatible = "samsung,usb-connector-11pin", + "usb-b-connector"; + label = "micro-USB"; + type = "micro"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + /* + * TODO: The DTS this is based on does not have + * port@0 which is a required property. The ports + * look incomplete and need fixing. + * Add a disabled port just to satisfy dtschema. + */ + reg = <0>; + status = "disabled"; + }; + + port@3 { + reg = <3>; + endpoint { + remote-endpoint = <&mhl_to_musb_con>; + }; + }; + }; + }; + + ports { + port { + endpoint { + remote-endpoint = <&usb_to_muic>; + }; + }; + }; + }; + + regulators { + compatible = "maxim,max77843-regulator"; + + SAFEOUT1 { + regulator-name = "SAFEOUT1"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <4950000>; + }; + + SAFEOUT2 { + regulator-name = "SAFEOUT2"; + regulator-min-microvolt = <3300000>; + regulator-max-microvolt = <4950000>; + }; + + CHARGER { + regulator-name = "CHARGER"; + regulator-min-microamp = <100000>; + regulator-max-microamp = <3150000>; + }; + }; + + motor-driver { + compatible = "maxim,max77843-haptic"; + haptic-supply = <&ldo38_reg>; + pwms = <&pwm 0 33670 0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/mt6397.txt b/Documentation/devicetree/bindings/mfd/mt6397.txt index 99a84b69a29f..293db2a71ef2 100644 --- a/Documentation/devicetree/bindings/mfd/mt6397.txt +++ b/Documentation/devicetree/bindings/mfd/mt6397.txt @@ -20,7 +20,7 @@ This document describes the binding for MFD device and its sub module. Required properties: compatible: "mediatek,mt6323" for PMIC MT6323 - "mediatek,mt6358" for PMIC MT6358 + "mediatek,mt6358" for PMIC MT6358 and MT6366 "mediatek,mt6359" for PMIC MT6359 "mediatek,mt6397" for PMIC MT6397 diff --git a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt index 7a27c500ff63..a461ec2f758f 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,spmi-pmic.txt @@ -35,6 +35,7 @@ Required properties: "qcom,pm8916", "qcom,pm8941", "qcom,pm8950", + "qcom,pm8953", "qcom,pm8994", "qcom,pm8998", "qcom,pma8084", diff --git a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt index c5f4f0ddfcc3..add61bcc3c74 100644 --- a/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt +++ b/Documentation/devicetree/bindings/mfd/qcom,tcsr.txt @@ -10,6 +10,7 @@ Required properties: "qcom,tcsr-ipq8064", "syscon" for IPQ8064 "qcom,tcsr-apq8064", "syscon" for APQ8064 "qcom,tcsr-msm8660", "syscon" for MSM8660 + "qcom,tcsr-msm8953", "syscon" for MSM8953 "qcom,tcsr-msm8960", "syscon" for MSM8960 "qcom,tcsr-msm8974", "syscon" for MSM8974 "qcom,tcsr-apq8084", "syscon" for APQ8084 diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt deleted file mode 100644 index 30ea27c3936d..000000000000 --- a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.txt +++ /dev/null @@ -1,72 +0,0 @@ -Samsung Exynos SoC Low Power Audio Subsystem (LPASS) - -Required properties: - - - compatible : "samsung,exynos5433-lpass" - - reg : should contain the LPASS top SFR region location - and size - - clock-names : should contain following required clocks: "sfr0_ctrl" - - clocks : should contain clock specifiers of all clocks, which - input names have been specified in clock-names - property, in same order. - - #address-cells : should be 1 - - #size-cells : should be 1 - - ranges : must be present - -Each IP block of the Low Power Audio Subsystem should be specified as -an optional sub-node. For "samsung,exynos5433-lpass" compatible this includes: -UART, SLIMBUS, PCM, I2S, DMAC, Timers 0...4, VIC, WDT 0...1 devices. - -Bindings of the sub-nodes are described in: - ../serial/samsung_uart.yaml - ../sound/samsung-i2s.txt - ../dma/arm-pl330.txt - - -Example: - -audio-subsystem { - compatible = "samsung,exynos5433-lpass"; - reg = <0x11400000 0x100>, <0x11500000 0x08>; - clocks = <&cmu_aud CLK_PCLK_SFR0_CTRL>; - clock-names = "sfr0_ctrl"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - adma: adma@11420000 { - compatible = "arm,pl330", "arm,primecell"; - reg = <0x11420000 0x1000>; - interrupts = <0 73 0>; - clocks = <&cmu_aud CLK_ACLK_DMAC>; - clock-names = "apb_pclk"; - #dma-cells = <1>; - #dma-channels = <8>; - #dma-requests = <32>; - }; - - i2s0: i2s0@11440000 { - compatible = "samsung,exynos7-i2s"; - reg = <0x11440000 0x100>; - dmas = <&adma 0 &adma 2>; - dma-names = "tx", "rx"; - interrupts = <0 70 0>; - clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, - <&cmu_aud CLK_SCLK_AUD_I2S>, - <&cmu_aud CLK_SCLK_I2S_BCLK>; - clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; - pinctrl-names = "default"; - pinctrl-0 = <&i2s0_bus>; - }; - - serial_3: serial@11460000 { - compatible = "samsung,exynos5433-uart"; - reg = <0x11460000 0x100>; - interrupts = <0 67 0>; - clocks = <&cmu_aud CLK_PCLK_AUD_UART>, - <&cmu_aud CLK_SCLK_AUD_UART>; - clock-names = "uart", "clk_uart_baud0"; - pinctrl-names = "default"; - pinctrl-0 = <&uart_aud_bus>; - }; - }; diff --git a/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml new file mode 100644 index 000000000000..bae55c98961c --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/samsung,exynos5433-lpass.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/samsung,exynos5433-lpass.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Low Power Audio Subsystem (LPASS) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + const: samsung,exynos5433-lpass + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: sfr0_ctrl + + power-domains: + maxItems: 1 + + ranges: true + + reg: + minItems: 2 + maxItems: 2 + + '#size-cells': + const: 1 + +patternProperties: + "^dma-controller@[0-9a-f]+$": + $ref: /schemas/dma/arm,pl330.yaml + + "^i2s@[0-9a-f]+$": + $ref: /schemas/sound/samsung-i2s.yaml + + "^serial@[0-9a-f]+$": + $ref: /schemas/serial/samsung_uart.yaml + +required: + - compatible + - '#address-cells' + - clocks + - clock-names + - ranges + - reg + - '#size-cells' + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + audio-subsystem@11400000 { + compatible = "samsung,exynos5433-lpass"; + reg = <0x11400000 0x100>, <0x11500000 0x08>; + clocks = <&cmu_aud CLK_PCLK_SFR0_CTRL>; + clock-names = "sfr0_ctrl"; + power-domains = <&pd_aud>; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + dma-controller@11420000 { + compatible = "arm,pl330", "arm,primecell"; + reg = <0x11420000 0x1000>; + interrupts = <GIC_SPI 73 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cmu_aud CLK_ACLK_DMAC>; + clock-names = "apb_pclk"; + #dma-cells = <1>; + #dma-channels = <8>; + #dma-requests = <32>; + power-domains = <&pd_aud>; + }; + + i2s@11440000 { + compatible = "samsung,exynos7-i2s"; + reg = <0x11440000 0x100>; + dmas = <&adma 0>, <&adma 2>; + dma-names = "tx", "rx"; + interrupts = <GIC_SPI 70 IRQ_TYPE_LEVEL_HIGH>; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_aud CLK_PCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_AUD_I2S>, + <&cmu_aud CLK_SCLK_I2S_BCLK>; + clock-names = "iis", "i2s_opclk0", "i2s_opclk1"; + #clock-cells = <1>; + pinctrl-names = "default"; + pinctrl-0 = <&i2s0_bus>; + power-domains = <&pd_aud>; + #sound-dai-cells = <1>; + }; + + serial@11460000 { + compatible = "samsung,exynos5433-uart"; + reg = <0x11460000 0x100>; + interrupts = <GIC_SPI 67 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&cmu_aud CLK_PCLK_AUD_UART>, + <&cmu_aud CLK_SCLK_AUD_UART>; + clock-names = "uart", "clk_uart_baud0"; + pinctrl-names = "default"; + pinctrl-0 = <&uart_aud_bus>; + power-domains = <&pd_aud>; + }; + }; diff --git a/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml new file mode 100644 index 000000000000..6de74c701635 --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/silergy,sy7636a.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/silergy,sy7636a.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: silergy sy7636a PMIC + +maintainers: + - Alistair Francis <alistair@alistair23.me> + +properties: + compatible: + const: silergy,sy7636a + + reg: + description: + I2C device address. + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + + '#thermal-sensor-cells': + const: 0 + + epd-pwr-good-gpios: + description: + Specifying the power good GPIOs. + maxItems: 1 + + regulators: + type: object + + properties: + compatible: + const: silergy,sy7636a-regulator + + vcom: + type: object + $ref: /schemas/regulator/regulator.yaml# + description: + The regulator for the compenstation voltage. Enabling/disabling this + enables/disables the entire device. + properties: + regulator-name: + const: vcom + + additionalProperties: false + +required: + - compatible + - reg + - '#thermal-sensor-cells' + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@62 { + compatible = "silergy,sy7636a"; + reg = <0x62>; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_epdpmic>; + #thermal-sensor-cells = <0>; + + regulators { + reg_epdpmic: vcom { + regulator-name = "vcom"; + regulator-boot-on; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml new file mode 100644 index 000000000000..623a4b5cd27a --- /dev/null +++ b/Documentation/devicetree/bindings/mfd/stericsson,ab8500.yaml @@ -0,0 +1,500 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mfd/stericsson,ab8500.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ST-Ericsson Analog Baseband AB8500 and AB8505 + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: + the AB8500 "Analog Baseband" is the mixed-signals integrated circuit + handling power management (regulators), analog-to-digital conversion + (ADC), battery charging, fuel gauging of the battery, battery-backed + RTC, PWM, USB PHY and some GPIO lines in the ST-Ericsson U8500 platforms + in connection with the DB8500 digital baseband. The DB8500 PRCMU + communicates directly and autonomously with the AB8500 and thus it + appears as a subnode of the DB8500 PRCMU. An altered version called + AB8505 also exist, the difference in AB8505 is that some of the USB and + USB charging handling has changed, and it has an embedded USB-to-serial + converter. Most subblocks takes their interrupts directly from the + AB8500 embedded interrupt controller. + +properties: + $nodename: + pattern: '^ab850[05]$' + + compatible: + enum: + - stericsson,ab8500 + - stericsson,ab8505 + + interrupts: + maxItems: 1 + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + # Some subnodes use a reg, some don't. Those that do use a single cell. + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + clock-controller: + description: Node describing the AB8500 clock controller. This + provides the reference clock for the entire U8500 system and + the DB8500 counterpart. + type: object + + properties: + compatible: + const: stericsson,ab8500-clk + + '#clock-cells': + const: 1 + + gpio: + description: Node describing the AB8500 GPIO controller. A few + GPIO pins available for misc usage. + type: object + + properties: + compatible: + enum: + - stericsson,ab8500-gpio + - stericsson,ab8505-gpio + + gpio-controller: true + + '#gpio-cells': + const: 2 + + rtc: + description: Node describing the AB8500 battery-backed RTC. + type: object + + properties: + compatible: + const: stericsson,ab8500-rtc + + interrupts: + items: + - description: 60 second interval alarm interrupt + - description: RTC alarm + + interrupt-names: + items: + - const: 60S + - const: ALARM + + adc: + description: Node describing the AB8500 general purpose analog to digital + converter, GPADC. + type: object + + properties: + compatible: + const: stericsson,ab8500-gpadc + + # AB8505 only supports one (software) EOC interrupt + interrupts: + minItems: 1 + maxItems: 2 + + interrupt-names: true + + vddadc-supply: true + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + + '#io-channel-cells': + const: 1 + + patternProperties: + "^channel@[0-9a-f]+$": + type: object + $ref: ../iio/adc/adc.yaml# + description: Represents each of the external channels which are + connected to the ADC. + + properties: + reg: + items: + minimum: 1 + maximum: 31 + + required: + - reg + + additionalProperties: false + + required: + - compatible + - interrupts + - interrupt-names + - vddadc-supply + - '#address-cells' + - '#size-cells' + - '#io-channel-cells' + + additionalProperties: false + + thermal: + description: Node describing the AB8500 thermal control block. All this block + really does is to fire an interrupt when the die becomes 130 degrees Celsius + in temperature. + type: object + + properties: + compatible: + const: stericsson,abx500-temp + + interrupts: + items: + - description: Thermal warm warning interrupt + + interrupt-names: + items: + - const: ABX500_TEMP_WARM + + required: + - compatible + - interrupts + - interrupt-names + + additionalProperties: false + + ab8500_fg: + description: Node describing the AB8500 fuel gauge control block. + type: object + $ref: ../power/supply/stericsson,ab8500-fg.yaml + + ab8500_btemp: + description: Node describing the AB8500 battery temperature control block. + type: object + $ref: ../power/supply/stericsson,ab8500-btemp.yaml + + ab8500_charger: + description: Node describing the AB8500 battery charger control block. + type: object + $ref: ../power/supply/stericsson,ab8500-charger.yaml + + ab8500_chargalg: + description: Node describing the AB8500 battery charger algorithm. + type: object + $ref: ../power/supply/stericsson,ab8500-chargalg.yaml + + phy: + description: Node describing the AB8500 USB PHY control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-usb + + interrupts: + items: + - description: ID wakeup rising IRQ + - description: ID wakeup falling IRQ + - description: VBUS detection falling IRQ + - description: VBUS detection rising IRQ + - description: USB link status change IRQ + - description: ADP probe plug IRQ + - description: ADP probe unplug IRQ + + interrupt-names: + items: + - const: ID_WAKEUP_R + - const: ID_WAKEUP_F + - const: VBUS_DET_F + - const: VBUS_DET_R + - const: USB_LINK_STATUS + - const: USB_ADP_PROBE_PLUG + - const: USB_ADP_PROBE_UNPLUG + + vddulpivio18-supply: true + v-ape-supply: true + musb_1v8-supply: true + + clocks: + items: + - description: PRCMY system clock + + clock-names: + items: + - const: sysclk + + '#phy-cells': + const: 0 + + required: + - compatible + - interrupts + - interrupt-names + - vddulpivio18-supply + - v-ape-supply + - musb_1v8-supply + - clocks + - clock-names + - '#phy-cells' + + additionalProperties: false + + key: + description: Node describing the AB8500 power-on key control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-poweron-key + + interrupts: + items: + - description: ON key falling IRQ + - description: ON key rising IRQ + + interrupt-names: + items: + - const: ONKEY_DBF + - const: ONKEY_DBR + + required: + - compatible + - interrupts + - interrupt-names + + additionalProperties: false + + ab8500-sysctrl: + description: Node describing the AB8500 system control block. + type: object + + properties: + compatible: + const: stericsson,ab8500-sysctrl + + required: + - compatible + + additionalProperties: false + + codec: + description: Node describing the AB8500 audio codec block. + type: object + + properties: + compatible: + const: stericsson,ab8500-codec + + V-AUD-supply: true + V-AMIC1-supply: true + V-AMIC2-supply: true + V-DMIC-supply: true + + clocks: + items: + - description: Audio system clock + + clock-names: + items: + - const: audioclk + + stericsson,earpeice-cmv: + description: Earpeice voltage + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [ 950, 1100, 1270, 1580 ] + + required: + - compatible + + additionalProperties: false + + regulator: + description: Node describing the AB8500 internal regulators. + type: object + + properties: + compatible: + enum: + - stericsson,ab8500-regulator + - stericsson,ab8505-regulator + + vin-supply: + description: The regulator supplying all of the internal regulators + with power. + + ab8500_ldo_aux1: + description: The voltage for the auxilary LDO regulator 1 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux2: + description: The voltage for the auxilary LDO regulator 2 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux3: + description: The voltage for the auxilary LDO regulator 3 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux4: + description: The voltage for the auxilary LDO regulator 4 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux5: + description: The voltage for the auxilary LDO regulator 5 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_aux6: + description: The voltage for the auxilary LDO regulator 6 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + # There is never any AUX7 regulator which is confusing + + ab8500_ldo_aux8: + description: The voltage for the auxilary LDO regulator 8 + only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_intcore: + description: The LDO regulator for the internal core voltage + of the AB8500 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_adc: + description: Analog power regulator for the analog to digital converter + ADC, only present on AB8505 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_tvout: + description: The voltage for the TV output regulator, incidentally + this voltage is also used for other purposes such as measuring + the temperature of the NTC thermistor on the battery. + Only present on AB8500. + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_audio: + description: The LDO regulator for the audio codec output + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_anamic1: + description: The LDO regulator for the analog microphone 1 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_anamic2: + description: The LDO regulator for the analog microphone 2 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_dmic: + description: The LDO regulator for the digital microphone + only present on AB8500 + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ldo_ana: + description: Analog power regulator for CSI and DSI interfaces, + Camera Serial Interface CSI and Display Serial Interface DSI. + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + + additionalProperties: false + + + regulator-external: + description: Node describing the AB8500 external regulators. This + concerns the autonomous regulators VSMPS1, VSMPS2 and VSMPS3 + that are normally controlled by external electronics but also + sometimes need to be explicitly controlled by software. + type: object + + properties: + compatible: + const: stericsson,ab8500-ext-regulator + + ab8500_ext1: + description: The voltage for the VSMPS1 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ext2: + description: The voltage for the VSMPS2 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + ab8500_ext3: + description: The voltage for the VSMPS3 external regulator + type: object + $ref: ../regulator/regulator.yaml# + + required: + - compatible + + additionalProperties: false + +patternProperties: + "^pwm@[1-9]+?$": + type: object + $ref: ../pwm/pwm.yaml# + description: Represents each of the PWM blocks in the AB8500 + + properties: + compatible: + const: stericsson,ab8500-pwm + + reg: true + + clocks: + items: + - description: internal clock + + clock-names: + items: + - const: intclk + + required: + - compatible + - reg + +required: + - compatible + - clock-controller + - gpio + - rtc + - adc + - thermal + - ab8500_fg + - ab8500_btemp + - ab8500_charger + - ab8500_chargalg + - phy + - key + - regulator + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml index a0d4bad5dc81..1d4d88f7e82d 100644 --- a/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml +++ b/Documentation/devicetree/bindings/mfd/stericsson,db8500-prcmu.yaml @@ -263,6 +263,7 @@ patternProperties: set of devicetree bindings. The AB8505 is a newer version of the same ASIC. type: object + $ref: stericsson,ab8500.yaml# required: - compatible diff --git a/Documentation/devicetree/bindings/mfd/syscon.yaml b/Documentation/devicetree/bindings/mfd/syscon.yaml index eeac1cbc5a17..13baa452cc9d 100644 --- a/Documentation/devicetree/bindings/mfd/syscon.yaml +++ b/Documentation/devicetree/bindings/mfd/syscon.yaml @@ -44,6 +44,11 @@ properties: - hisilicon,hi6220-sramctrl - hisilicon,pcie-sas-subctrl - hisilicon,peri-subctrl + - intel,lgm-syscon + - marvell,armada-3700-usb2-host-misc + - mediatek,mt8135-pctl-a-syscfg + - mediatek,mt8135-pctl-b-syscfg + - microchip,lan966x-cpu-syscon - microchip,sparx5-cpu-syscon - mstar,msc313-pmsleep - rockchip,px30-qos diff --git a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml index 272832e9f8f2..fa86691ebf16 100644 --- a/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml +++ b/Documentation/devicetree/bindings/mfd/ti,j721e-system-controller.yaml @@ -20,7 +20,7 @@ description: | maintainers: - Kishon Vijay Abraham I <kishon@ti.com> - - Roger Quadros <rogerq@ti.com + - Roger Quadros <rogerq@kernel.org> properties: compatible: diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt index 2a1827ab50d2..5ec124b138a6 100644 --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.txt @@ -17,6 +17,16 @@ other tasks. Definition: should specify the dsp domain name this fastrpc corresponds to. must be one of this: "adsp", "mdsp", "sdsp", "cdsp" +- qcom,non-secure-domain: + Usage: required + Value type: <boolean> + Definition: Property to specify that dsp domain is non-secure. + +- qcom,vmids: + Usage: optional + Value type: <u32 array> + Definition: Virtual machine IDs for remote processor. + - #address-cells Usage: required Value type: <u32> diff --git a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml index 4f62ad6ce50c..7803597b6366 100644 --- a/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml +++ b/Documentation/devicetree/bindings/mmc/allwinner,sun4i-a10-mmc.yaml @@ -24,6 +24,7 @@ properties: - const: allwinner,sun7i-a20-mmc - const: allwinner,sun8i-a83t-emmc - const: allwinner,sun9i-a80-mmc + - const: allwinner,sun20i-d1-mmc - const: allwinner,sun50i-a64-emmc - const: allwinner,sun50i-a64-mmc - const: allwinner,sun50i-a100-emmc @@ -50,11 +51,17 @@ properties: - const: allwinner,sun50i-h6-mmc - const: allwinner,sun50i-a64-mmc - items: + - const: allwinner,sun20i-d1-emmc + - const: allwinner,sun50i-a100-emmc + - items: - const: allwinner,sun50i-h616-emmc - const: allwinner,sun50i-a100-emmc - items: - const: allwinner,sun50i-h616-mmc - const: allwinner,sun50i-a100-mmc + - items: + - const: allwinner,suniv-f1c100s-mmc + - const: allwinner,sun7i-a20-mmc reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml index 17acbc665f5a..7dbbcae9485c 100644 --- a/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml +++ b/Documentation/devicetree/bindings/mmc/fsl-imx-esdhc.yaml @@ -47,6 +47,7 @@ properties: - const: fsl,imx7d-usdhc - items: - enum: + - fsl,imx93-usdhc - fsl,imx8ulp-usdhc - const: fsl,imx8mm-usdhc diff --git a/Documentation/devicetree/bindings/mmc/litex,mmc.yaml b/Documentation/devicetree/bindings/mmc/litex,mmc.yaml new file mode 100644 index 000000000000..ef9e0da44bf8 --- /dev/null +++ b/Documentation/devicetree/bindings/mmc/litex,mmc.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-or-later OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mmc/litex,mmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: LiteX LiteSDCard device + +maintainers: + - Gabriel Somlo <gsomlo@gmail.com> + +description: | + LiteSDCard is a small footprint, configurable SDCard core for FPGA based + system on chips. + + The hardware source is Open Source and can be found on at + https://github.com/enjoy-digital/litesdcard/. + +allOf: + - $ref: mmc-controller.yaml# + +properties: + compatible: + const: litex,mmc + + reg: + items: + - description: PHY registers + - description: CORE registers + - description: DMA Reader buffer + - description: DMA Writer buffer + - description: IRQ registers + minItems: 4 + + reg-names: + items: + - const: phy + - const: core + - const: reader + - const: writer + - const: irq + minItems: 4 + + clocks: + maxItems: 1 + description: + Handle to reference clock. + + vmmc-supply: + description: + Handle to fixed-voltage supply for the card power. + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - clocks + - vmmc-supply + +additionalProperties: false + +examples: + - | + mmc: mmc@12005000 { + compatible = "litex,mmc"; + reg = <0x12005000 0x100>, + <0x12003800 0x100>, + <0x12003000 0x100>, + <0x12004800 0x100>, + <0x12004000 0x100>; + reg-names = "phy", "core", "reader", "writer", "irq"; + clocks = <&reference_clk>; + vmmc-supply = <&vreg_mmc>; + interrupts = <4>; + }; diff --git a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml index faf89b0c918f..297ada03e3de 100644 --- a/Documentation/devicetree/bindings/mmc/mtk-sd.yaml +++ b/Documentation/devicetree/bindings/mmc/mtk-sd.yaml @@ -30,6 +30,9 @@ properties: - const: mediatek,mt7623-mmc - const: mediatek,mt2701-mmc - items: + - const: mediatek,mt8186-mmc + - const: mediatek,mt8183-mmc + - items: - const: mediatek,mt8192-mmc - const: mediatek,mt8183-mmc - items: diff --git a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml index 9ce6e06c19db..9ac4986988c5 100644 --- a/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml +++ b/Documentation/devicetree/bindings/mmc/renesas,sdhi.yaml @@ -57,7 +57,9 @@ properties: - renesas,sdhi-r8a77990 # R-Car E3 - renesas,sdhi-r8a77995 # R-Car D3 - renesas,sdhi-r8a779a0 # R-Car V3U + - renesas,sdhi-r9a07g043 # RZ/G2UL - renesas,sdhi-r9a07g044 # RZ/G2{L,LC} + - renesas,sdhi-r9a07g054 # RZ/V2L - const: renesas,rcar-gen3-sdhi # R-Car Gen3 or RZ/G2 reg: @@ -107,7 +109,10 @@ allOf: properties: compatible: contains: - const: renesas,sdhi-r9a07g044 + enum: + - renesas,sdhi-r9a07g043 + - renesas,sdhi-r9a07g044 + - renesas,sdhi-r9a07g054 then: properties: clocks: diff --git a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml index 9fbf16b3bc8d..0566493c4def 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml +++ b/Documentation/devicetree/bindings/mmc/sdhci-am654.yaml @@ -21,6 +21,7 @@ properties: - const: ti,j721e-sdhci-4bit - const: ti,am64-sdhci-8bit - const: ti,am64-sdhci-4bit + - const: ti,am62-sdhci - items: - const: ti,j7200-sdhci-8bit - const: ti,j721e-sdhci-8bit diff --git a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt index 6a8cc261bf61..6216ed777343 100644 --- a/Documentation/devicetree/bindings/mmc/sdhci-msm.txt +++ b/Documentation/devicetree/bindings/mmc/sdhci-msm.txt @@ -14,6 +14,7 @@ Required properties: full compatible strings with SoC and version: "qcom,apq8084-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8226-sdhci", "qcom,sdhci-msm-v4" + "qcom,msm8953-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8974-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8916-sdhci", "qcom,sdhci-msm-v4" "qcom,msm8992-sdhci", "qcom,sdhci-msm-v4" diff --git a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt b/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt deleted file mode 100644 index efa5b2aba829..000000000000 --- a/Documentation/devicetree/bindings/mtd/cortina,gemini-flash.txt +++ /dev/null @@ -1,24 +0,0 @@ -Flash device on Cortina Systems Gemini SoC - -This flash is regular CFI compatible (Intel or AMD extended) flash chips with -some special bits that can be controlled by the machine's system controller. - -Required properties: -- compatible : must be "cortina,gemini-flash", "cfi-flash"; -- reg : memory address for the flash chip -- 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.yaml. - -The device tree may optionally contain sub-nodes describing partitions of the -address space. See partition.txt for more detail. - -Example: - -flash@30000000 { - compatible = "cortina,gemini-flash", "cfi-flash"; - reg = <0x30000000 0x01000000>; - syscon = <&syscon>; - bank-width = <2>; -}; diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml index 39421f7233e4..4abfb4cfc157 100644 --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.yaml @@ -47,7 +47,8 @@ properties: identified by the JEDEC READ ID opcode (0x9F). reg: - maxItems: 1 + minItems: 1 + maxItems: 2 spi-max-frequency: true spi-rx-bus-width: true diff --git a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml index f827984936f6..82eb4e0f453b 100644 --- a/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml +++ b/Documentation/devicetree/bindings/mtd/mtd-physmap.yaml @@ -44,7 +44,9 @@ properties: - numonyx,js28f128 - sst,sst39vf320 - xlnx,xps-mch-emc-2.00.a - - const: cfi-flash + - enum: + - cfi-flash + - jedec-flash - items: - enum: - cypress,cy7c1019dv33-10zsxi @@ -127,6 +129,20 @@ required: - compatible - reg +if: + properties: + compatible: + contains: + const: cortina,gemini-flash +then: + properties: + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to the syscon controller + required: + - syscon + # FIXME: A parent bus may define timing properties additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml new file mode 100644 index 000000000000..804479999ccb --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/mxicy,nand-ecc-engine.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/mxicy,nand-ecc-engine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Macronix NAND ECC engine device tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +properties: + compatible: + const: mxicy,nand-ecc-engine-rev3 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + interrupts: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + /* External configuration */ + spi_controller0: spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + nand-ecc-engine = <&ecc_engine0>; + }; + }; + + ecc_engine0: ecc@43c40000 { + compatible = "mxicy,nand-ecc-engine-rev3"; + reg = <0x43c40000 0x10000>; + }; + + - | + /* Pipelined configuration */ + spi_controller1: spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x4000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 15>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + nand-ecc-engine = <&ecc_engine1>; + + flash@0 { + compatible = "spi-nand"; + reg = <0>; + nand-ecc-engine = <&spi_controller1>; + }; + }; + + ecc_engine1: ecc@43c40000 { + compatible = "mxicy,nand-ecc-engine-rev3"; + reg = <0x43c40000 0x10000>; + }; diff --git a/Documentation/devicetree/bindings/mtd/nand-chip.yaml b/Documentation/devicetree/bindings/mtd/nand-chip.yaml new file mode 100644 index 000000000000..97ac3a3fbb52 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/nand-chip.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/nand-chip.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NAND Chip and NAND Controller Generic Binding + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +description: | + This file covers the generic description of a NAND chip. It implies that the + bus interface should not be taken into account: both raw NAND devices and + SPI-NAND devices are concerned by this description. + +properties: + reg: + description: + Contains the chip-select IDs. + + nand-ecc-engine: + description: | + A phandle on the hardware ECC engine if any. There are + basically three possibilities: + 1/ The ECC engine is part of the NAND controller, in this + case the phandle should reference the parent node. + 2/ The ECC engine is part of the NAND part (on-die), in this + case the phandle should reference the node itself. + 3/ The ECC engine is external, in this case the phandle should + reference the specific ECC engine node. + $ref: /schemas/types.yaml#/definitions/phandle + + nand-use-soft-ecc-engine: + description: Use a software ECC engine. + type: boolean + + nand-no-ecc-engine: + description: Do not use any ECC correction. + type: boolean + + nand-ecc-algo: + description: + Desired ECC algorithm. + $ref: /schemas/types.yaml#/definitions/string + enum: [hamming, bch, rs] + + nand-ecc-strength: + description: + Maximum number of bits that can be corrected per ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + nand-ecc-step-size: + description: + Number of data bytes covered by a single ECC step. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + + secure-regions: + description: + Regions in the NAND chip which are protected using a secure element + like Trustzone. This property contains the start address and size of + the secure regions present. + $ref: /schemas/types.yaml#/definitions/uint64-matrix + +required: + - reg + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/mtd/nand-controller.yaml b/Documentation/devicetree/bindings/mtd/nand-controller.yaml index bd217e6f5018..359a015d4e5a 100644 --- a/Documentation/devicetree/bindings/mtd/nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/nand-controller.yaml @@ -39,8 +39,6 @@ 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 @@ -48,51 +46,27 @@ properties: 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. + minItems: 1 + maxItems: 8 patternProperties: "^nand@[a-f0-9]$": type: object + $ref: "nand-chip.yaml#" + properties: reg: description: - Contains the native Ready/Busy IDs. - - nand-ecc-engine: - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle - description: | - A phandle on the hardware ECC engine if any. There are - basically three possibilities: - 1/ The ECC engine is part of the NAND controller, in this - case the phandle should reference the parent node. - 2/ The ECC engine is part of the NAND part (on-die), in this - case the phandle should reference the node itself. - 3/ The ECC engine is external, in this case the phandle should - reference the specific ECC engine node. - - nand-use-soft-ecc-engine: - type: boolean - description: Use a software ECC engine. - - nand-no-ecc-engine: - type: boolean - description: Do not use any ECC correction. + Contains the chip-select IDs. nand-ecc-placement: - allOf: - - $ref: /schemas/types.yaml#/definitions/string - - enum: [ oob, interleaved ] description: Location of the ECC bytes. This location is unknown by default but can be explicitly set to "oob", if all ECC bytes are known to be stored in the OOB area, or "interleaved" if ECC bytes will be interleaved with regular data in the main area. - - nand-ecc-algo: - description: - Desired ECC algorithm. $ref: /schemas/types.yaml#/definitions/string - enum: [hamming, bch, rs] + enum: [ oob, interleaved ] nand-bus-width: description: @@ -102,7 +76,6 @@ patternProperties: default: 8 nand-on-flash-bbt: - $ref: /schemas/types.yaml#/definitions/flag description: With this property, the OS will search the device for a Bad Block Table (BBT). If not found, it will create one, reserve @@ -111,21 +84,9 @@ patternProperties: few pages of all the blocks will be scanned at boot time to find Bad Block Markers (BBM). These markers will help to build a volatile BBT in RAM. - - nand-ecc-strength: - description: - Maximum number of bits that can be corrected per ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 - - nand-ecc-step-size: - description: - Number of data bytes covered by a single ECC step. - $ref: /schemas/types.yaml#/definitions/uint32 - minimum: 1 + $ref: /schemas/types.yaml#/definitions/flag nand-ecc-maximize: - $ref: /schemas/types.yaml#/definitions/flag description: Whether or not the ECC strength should be maximized. The maximum ECC strength is both controller and chip @@ -134,18 +95,19 @@ patternProperties: constraint into account. This is particularly useful when only the in-band area is used by the upper layers, and you want to make your NAND as reliable as possible. + $ref: /schemas/types.yaml#/definitions/flag nand-is-boot-medium: - $ref: /schemas/types.yaml#/definitions/flag description: Whether or not the NAND chip is a boot medium. Drivers might use this information to select ECC algorithms supported by the boot ROM or similar restrictions. + $ref: /schemas/types.yaml#/definitions/flag nand-rb: - $ref: /schemas/types.yaml#/definitions/uint32-array description: Contains the native Ready/Busy IDs. + $ref: /schemas/types.yaml#/definitions/uint32-array rb-gpios: description: @@ -154,12 +116,12 @@ patternProperties: Ready/Busy pins. Active state refers to the NAND ready state and should be set to GPIOD_ACTIVE_HIGH unless the signal is inverted. - secure-regions: - $ref: /schemas/types.yaml#/definitions/uint64-matrix + wp-gpios: description: - Regions in the NAND chip which are protected using a secure element - like Trustzone. This property contains the start address and size of - the secure regions present. + Contains one GPIO descriptor for the Write Protect pin. + Active state refers to the NAND Write Protect state and should be + set to GPIOD_ACTIVE_LOW unless the signal is inverted. + maxItems: 1 required: - reg @@ -181,10 +143,7 @@ examples: nand@0 { reg = <0>; /* Native CS */ - nand-use-soft-ecc-engine; - nand-ecc-algo = "bch"; - - /* controller specific properties */ + /* NAND chip specific properties */ }; nand@1 { diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt deleted file mode 100644 index 1d61a029395e..000000000000 --- a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.txt +++ /dev/null @@ -1,42 +0,0 @@ -Broadcom BCM47xx Partitions -=========================== - -Broadcom is one of hardware manufacturers providing SoCs (BCM47xx) used in -home routers. Their BCM947xx boards using CFE bootloader have several partitions -without any on-flash partition table. On some devices their sizes and/or -meanings can also vary so fixed partitioning can't be used. - -Discovering partitions on these devices is possible thanks to having a special -header and/or magic signature at the beginning of each of them. They are also -block aligned which is important for determinig a size. - -Most of partitions use ASCII text based magic for determining a type. More -complex partitions (like TRX with its HDR0 magic) may include extra header -containing some details, including a length. - -A list of supported partitions includes: -1) Bootloader with Broadcom's CFE (Common Firmware Environment) -2) NVRAM with configuration/calibration data -3) Device manufacturer's data with some default values (e.g. SSIDs) -4) TRX firmware container which can hold up to 4 subpartitions -5) Backup TRX firmware used after failed upgrade - -As mentioned earlier, role of some partitions may depend on extra configuration. -For example both: main firmware and backup firmware use the same TRX format with -the same header. To distinguish currently used firmware a CFE's environment -variable "bootpartition" is used. - - -Devices using Broadcom partitions described above should should have flash node -with a subnode named "partitions" using following properties: - -Required properties: -- compatible : (required) must be "brcm,bcm947xx-cfe-partitions" - -Example: - -flash@0 { - partitions { - compatible = "brcm,bcm947xx-cfe-partitions"; - }; -}; diff --git a/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml new file mode 100644 index 000000000000..3484e06d6bcb --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml @@ -0,0 +1,48 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/partitions/brcm,bcm947xx-cfe-partitions.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM47xx Partitions + +description: | + Broadcom is one of hardware manufacturers providing SoCs (BCM47xx) used in + home routers. Their BCM947xx boards using CFE bootloader have several + partitions without any on-flash partition table. On some devices their sizes + and/or meanings can also vary so fixed partitioning can't be used. + + Discovering partitions on these devices is possible thanks to having a special + header and/or magic signature at the beginning of each of them. They are also + block aligned which is important for determinig a size. + + Most of partitions use ASCII text based magic for determining a type. More + complex partitions (like TRX with its HDR0 magic) may include extra header + containing some details, including a length. + + A list of supported partitions includes: + 1) Bootloader with Broadcom's CFE (Common Firmware Environment) + 2) NVRAM with configuration/calibration data + 3) Device manufacturer's data with some default values (e.g. SSIDs) + 4) TRX firmware container which can hold up to 4 subpartitions + 5) Backup TRX firmware used after failed upgrade + + As mentioned earlier, role of some partitions may depend on extra + configuration. For example both: main firmware and backup firmware use the + same TRX format with the same header. To distinguish currently used firmware a + CFE's environment variable "bootpartition" is used. + +maintainers: + - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> + +properties: + compatible: + const: brcm,bcm947xx-cfe-partitions + +additionalProperties: false + +examples: + - | + partitions { + compatible = "brcm,bcm947xx-cfe-partitions"; + }; diff --git a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml index 0922536b1811..d681a4676f06 100644 --- a/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml +++ b/Documentation/devicetree/bindings/mtd/rockchip,nand-controller.yaml @@ -96,8 +96,7 @@ patternProperties: rockchip,boot-ecc-strength: enum: [16, 24, 40, 60, 70] - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32 + $ref: /schemas/types.yaml#/definitions/uint32 description: | If specified it indicates that a different BCH/ECC setting is supported by the boot ROM. diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.txt b/Documentation/devicetree/bindings/mtd/spi-nand.txt deleted file mode 100644 index 8b51f3b6d55c..000000000000 --- a/Documentation/devicetree/bindings/mtd/spi-nand.txt +++ /dev/null @@ -1,5 +0,0 @@ -SPI NAND flash - -Required properties: -- compatible: should be "spi-nand" -- reg: should encode the chip-select line used to access the NAND chip diff --git a/Documentation/devicetree/bindings/mtd/spi-nand.yaml b/Documentation/devicetree/bindings/mtd/spi-nand.yaml new file mode 100644 index 000000000000..431faac518a4 --- /dev/null +++ b/Documentation/devicetree/bindings/mtd/spi-nand.yaml @@ -0,0 +1,27 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/mtd/spi-nand.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI-NAND flash device tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: "nand-chip.yaml#" + +properties: + compatible: + const: spi-nand + + reg: + description: Encode the chip-select line on the SPI bus + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false diff --git a/Documentation/devicetree/bindings/nds32/andestech-boards b/Documentation/devicetree/bindings/nds32/andestech-boards deleted file mode 100644 index f5d75693e3c7..000000000000 --- a/Documentation/devicetree/bindings/nds32/andestech-boards +++ /dev/null @@ -1,40 +0,0 @@ -Andestech(nds32) AE3XX Platform ------------------------------------------------------------------------------ -The AE3XX prototype demonstrates the AE3XX example platform on the FPGA. It -is composed of one Andestech(nds32) processor and AE3XX. - -Required properties (in root node): -- compatible = "andestech,ae3xx"; - -Example: -/dts-v1/; -/ { - compatible = "andestech,ae3xx"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <&intc>; -}; - -Andestech(nds32) AG101P Platform ------------------------------------------------------------------------------ -AG101P is a generic SoC Platform IP that works with any of Andestech(nds32) -processors to provide a cost-effective and high performance solution for -majority of embedded systems in variety of application domains. Users may -simply attach their IP on one of the system buses together with certain glue -logics to complete a SoC solution for a specific application. With -comprehensive simulation and design environments, users may evaluate the -system performance of their applications and track bugs of their designs -efficiently. The optional hardware development platform further provides real -system environment for early prototyping and software/hardware co-development. - -Required properties (in root node): - compatible = "andestech,ag101p"; - -Example: -/dts-v1/; -/ { - compatible = "andestech,ag101p"; - #address-cells = <1>; - #size-cells = <1>; - interrupt-parent = <&intc>; -}; diff --git a/Documentation/devicetree/bindings/nds32/atl2c.txt b/Documentation/devicetree/bindings/nds32/atl2c.txt deleted file mode 100644 index da8ab8e7ae9b..000000000000 --- a/Documentation/devicetree/bindings/nds32/atl2c.txt +++ /dev/null @@ -1,28 +0,0 @@ -* Andestech L2 cache Controller - -The level-2 cache controller plays an important role in reducing memory latency -for high performance systems, such as thoese designs with AndesCore processors. -Level-2 cache controller in general enhances overall system performance -signigicantly and the system power consumption might be reduced as well by -reducing DRAM accesses. - -This binding specifies what properties must be available in the device tree -representation of an Andestech L2 cache controller. - -Required properties: - - compatible: - Usage: required - Value type: <string> - Definition: "andestech,atl2c" - - reg : Physical base address and size of cache controller's memory mapped - - cache-unified : Specifies the cache is a unified cache. - - cache-level : Should be set to 2 for a level 2 cache. - -* Example - - cache-controller@e0500000 { - compatible = "andestech,atl2c"; - reg = <0xe0500000 0x1000>; - cache-unified; - cache-level = <2>; - }; diff --git a/Documentation/devicetree/bindings/nds32/cpus.txt b/Documentation/devicetree/bindings/nds32/cpus.txt deleted file mode 100644 index 6f9e311b6589..000000000000 --- a/Documentation/devicetree/bindings/nds32/cpus.txt +++ /dev/null @@ -1,38 +0,0 @@ -* Andestech Processor Binding - -This binding specifies what properties must be available in the device tree -representation of a Andestech Processor Core, which is the root node in the -tree. - -Required properties: - - - compatible: - Usage: required - Value type: <string> - Definition: Should be "andestech,<core_name>", "andestech,nds32v3" as fallback. - Must contain "andestech,nds32v3" as the most generic value, in addition to - one of the following identifiers for a particular CPU core: - "andestech,n13" - "andestech,n15" - "andestech,d15" - "andestech,n10" - "andestech,d10" - - device_type - Usage: required - Value type: <string> - Definition: must be "cpu" - - reg: Contains CPU index. - - clock-frequency: Contains the clock frequency for CPU, in Hz. - -* Examples - -/ { - cpus { - cpu@0 { - device_type = "cpu"; - compatible = "andestech,n13", "andestech,nds32v3"; - reg = <0x0>; - clock-frequency = <60000000> - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml index 8d8560a67abf..098b2bf7d976 100644 --- a/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml +++ b/Documentation/devicetree/bindings/net/allwinner,sun4i-a10-emac.yaml @@ -29,6 +29,10 @@ properties: allwinner,sram: description: Phandle to the device SRAM $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to SRAM + - description: register value for device required: - compatible diff --git a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml index c93fe9d3ea82..3c51b2d02957 100644 --- a/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml +++ b/Documentation/devicetree/bindings/net/can/allwinner,sun4i-a10-can.yaml @@ -10,6 +10,9 @@ maintainers: - Chen-Yu Tsai <wens@csie.org> - Maxime Ripard <mripard@kernel.org> +allOf: + - $ref: can-controller.yaml# + properties: compatible: oneOf: diff --git a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml index 2cd145a642f1..8bad328b184d 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,c_can.yaml @@ -56,10 +56,10 @@ properties: offset). $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The phandle to the system control region. - - description: The register offset. - - description: The CAN instance number. + - items: + - description: The phandle to the system control region. + - description: The register offset. + - description: The CAN instance number. resets: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml index 401ab7cdb379..26aa0830eea1 100644 --- a/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml +++ b/Documentation/devicetree/bindings/net/can/bosch,m_can.yaml @@ -9,7 +9,10 @@ title: Bosch MCAN controller Bindings description: Bosch MCAN controller for CAN bus maintainers: - - Sriram Dash <sriram.dash@samsung.com> + - Chandrasekar Ramakrishnan <rcsekar@samsung.com> + +allOf: + - $ref: can-controller.yaml# properties: compatible: @@ -66,8 +69,8 @@ properties: M_CAN includes the following elements according to user manual: 11-bit Filter 0-128 elements / 0-128 words 29-bit Filter 0-64 elements / 0-128 words - Rx FIFO 0 0-64 elements / 0-1152 words - Rx FIFO 1 0-64 elements / 0-1152 words + Rx FIFO 0 0-64 elements / 0-1152 words + Rx FIFO 1 0-64 elements / 0-1152 words Rx Buffers 0-64 elements / 0-1152 words Tx Event FIFO 0-32 elements / 0-64 words Tx Buffers 0-32 elements / 0-576 words @@ -101,6 +104,7 @@ properties: - description: Tx Buffers 0-32 elements / 0-576 words minimum: 0 maximum: 32 + minItems: 1 power-domains: description: diff --git a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml index 3f0ee17c1461..e52db841bb8c 100644 --- a/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml +++ b/Documentation/devicetree/bindings/net/can/fsl,flexcan.yaml @@ -84,12 +84,12 @@ properties: req_bit is the bit offset of CAN stop request. $ref: /schemas/types.yaml#/definitions/phandle-array items: - items: - - description: The 'gpr' is the phandle to general purpose register node. - - description: The 'req_gpr' is the gpr register offset of CAN stop request. - maximum: 0xff - - description: The 'req_bit' is the bit offset of CAN stop request. - maximum: 0x1f + - items: + - description: The 'gpr' is the phandle to general purpose register node. + - description: The 'req_gpr' is the gpr register offset of CAN stop request. + maximum: 0xff + - description: The 'req_bit' is the bit offset of CAN stop request. + maximum: 0x1f fsl,clk-source: description: | diff --git a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml index 2a884c1fe0e0..b3826af6bd6e 100644 --- a/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml +++ b/Documentation/devicetree/bindings/net/can/microchip,mcp251xfd.yaml @@ -11,6 +11,9 @@ title: maintainers: - Marc Kleine-Budde <mkl@pengutronix.de> +allOf: + - $ref: can-controller.yaml# + properties: compatible: oneOf: diff --git a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml index 546c6e6d2fb0..f98c53dc1894 100644 --- a/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml +++ b/Documentation/devicetree/bindings/net/can/renesas,rcar-canfd.yaml @@ -33,8 +33,11 @@ properties: - items: - enum: - renesas,r9a07g044-canfd # RZ/G2{L,LC} + - renesas,r9a07g054-canfd # RZ/V2L - const: renesas,rzg2l-canfd # RZ/G2L family + - const: renesas,r8a779a0-canfd # R-Car V3U + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt index 0968b40aef1e..e3501bfa22e9 100644 --- a/Documentation/devicetree/bindings/net/can/tcan4x5x.txt +++ b/Documentation/devicetree/bindings/net/can/tcan4x5x.txt @@ -31,7 +31,7 @@ tcan4x5x: tcan4x5x@0 { #address-cells = <1>; #size-cells = <1>; spi-max-frequency = <10000000>; - bosch,mram-cfg = <0x0 0 0 32 0 0 1 1>; + bosch,mram-cfg = <0x0 0 0 16 0 0 1 1>; interrupt-parent = <&gpio1>; interrupts = <14 IRQ_TYPE_LEVEL_LOW>; device-state-gpios = <&gpio3 21 GPIO_ACTIVE_HIGH>; diff --git a/Documentation/devicetree/bindings/net/can/xilinx,can.yaml b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml new file mode 100644 index 000000000000..65af8183cb9c --- /dev/null +++ b/Documentation/devicetree/bindings/net/can/xilinx,can.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/can/xilinx,can.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: + Xilinx Axi CAN/Zynq CANPS controller + +maintainers: + - Appana Durga Kedareswara rao <appana.durga.rao@xilinx.com> + +properties: + compatible: + enum: + - xlnx,zynq-can-1.0 + - xlnx,axi-can-1.00.a + - xlnx,canfd-1.0 + - xlnx,canfd-2.0 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + minItems: 1 + maxItems: 2 + + clock-names: + maxItems: 2 + + power-domains: + maxItems: 1 + + tx-fifo-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Tx fifo depth (Zynq, Axi CAN). + + rx-fifo-depth: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Rx fifo depth (Zynq, Axi CAN, CAN FD in sequential Rx mode) + + tx-mailbox-count: + $ref: "/schemas/types.yaml#/definitions/uint32" + description: CAN Tx mailbox buffer count (CAN FD) + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +allOf: + - $ref: can-controller.yaml# + - if: + properties: + compatible: + contains: + enum: + - xlnx,zynq-can-1.0 + + then: + properties: + clock-names: + items: + - const: can_clk + - const: pclk + required: + - tx-fifo-depth + - rx-fifo-depth + + - if: + properties: + compatible: + contains: + enum: + - xlnx,axi-can-1.00.a + + then: + properties: + clock-names: + items: + - const: can_clk + - const: s_axi_aclk + required: + - tx-fifo-depth + - rx-fifo-depth + + - if: + properties: + compatible: + contains: + enum: + - xlnx,canfd-1.0 + - xlnx,canfd-2.0 + + then: + properties: + clock-names: + items: + - const: can_clk + - const: s_axi_aclk + required: + - tx-mailbox-count + - rx-fifo-depth + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + can@e0008000 { + compatible = "xlnx,zynq-can-1.0"; + reg = <0xe0008000 0x1000>; + clocks = <&clkc 19>, <&clkc 36>; + clock-names = "can_clk", "pclk"; + interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH>; + interrupt-parent = <&intc>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; + + - | + can@40000000 { + compatible = "xlnx,axi-can-1.00.a"; + reg = <0x40000000 0x10000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>; + tx-fifo-depth = <0x40>; + rx-fifo-depth = <0x40>; + }; + + - | + can@40000000 { + compatible = "xlnx,canfd-1.0"; + reg = <0x40000000 0x2000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>; + tx-mailbox-count = <0x20>; + rx-fifo-depth = <0x20>; + }; + + - | + can@ff060000 { + compatible = "xlnx,canfd-2.0"; + reg = <0xff060000 0x6000>; + clocks = <&clkc 0>, <&clkc 1>; + clock-names = "can_clk", "s_axi_aclk"; + interrupt-parent = <&intc>; + interrupts = <GIC_SPI 59 IRQ_TYPE_EDGE_RISING>; + tx-mailbox-count = <0x20>; + rx-fifo-depth = <0x40>; + }; diff --git a/Documentation/devicetree/bindings/net/can/xilinx_can.txt b/Documentation/devicetree/bindings/net/can/xilinx_can.txt deleted file mode 100644 index 100cc40b8510..000000000000 --- a/Documentation/devicetree/bindings/net/can/xilinx_can.txt +++ /dev/null @@ -1,61 +0,0 @@ -Xilinx Axi CAN/Zynq CANPS controller Device Tree Bindings ---------------------------------------------------------- - -Required properties: -- compatible : Should be: - - "xlnx,zynq-can-1.0" for Zynq CAN controllers - - "xlnx,axi-can-1.00.a" for Axi CAN controllers - - "xlnx,canfd-1.0" for CAN FD controllers - - "xlnx,canfd-2.0" for CAN FD 2.0 controllers -- reg : Physical base address and size of the controller - registers map. -- interrupts : Property with a value describing the interrupt - number. -- clock-names : List of input clock names - - "can_clk", "pclk" (For CANPS), - - "can_clk", "s_axi_aclk" (For AXI CAN and CAN FD). - (See clock bindings for details). -- clocks : Clock phandles (see clock bindings for details). -- tx-fifo-depth : Can Tx fifo depth (Zynq, Axi CAN). -- rx-fifo-depth : Can Rx fifo depth (Zynq, Axi CAN, CAN FD in - sequential Rx mode). -- tx-mailbox-count : Can Tx mailbox buffer count (CAN FD). -- rx-mailbox-count : Can Rx mailbox buffer count (CAN FD in mailbox Rx - mode). - - -Example: - -For Zynq CANPS Dts file: - zynq_can_0: can@e0008000 { - compatible = "xlnx,zynq-can-1.0"; - clocks = <&clkc 19>, <&clkc 36>; - clock-names = "can_clk", "pclk"; - reg = <0xe0008000 0x1000>; - interrupts = <0 28 4>; - interrupt-parent = <&intc>; - tx-fifo-depth = <0x40>; - rx-fifo-depth = <0x40>; - }; -For Axi CAN Dts file: - axi_can_0: axi-can@40000000 { - compatible = "xlnx,axi-can-1.00.a"; - clocks = <&clkc 0>, <&clkc 1>; - clock-names = "can_clk","s_axi_aclk" ; - reg = <0x40000000 0x10000>; - interrupt-parent = <&intc>; - interrupts = <0 59 1>; - tx-fifo-depth = <0x40>; - rx-fifo-depth = <0x40>; - }; -For CAN FD Dts file: - canfd_0: canfd@40000000 { - compatible = "xlnx,canfd-1.0"; - clocks = <&clkc 0>, <&clkc 1>; - clock-names = "can_clk", "s_axi_aclk"; - reg = <0x40000000 0x2000>; - interrupt-parent = <&intc>; - interrupts = <0 59 1>; - tx-mailbox-count = <0x20>; - rx-fifo-depth = <0x20>; - }; diff --git a/Documentation/devicetree/bindings/net/cdns,macb.yaml b/Documentation/devicetree/bindings/net/cdns,macb.yaml index 8dd06db34169..6cd3d853dcba 100644 --- a/Documentation/devicetree/bindings/net/cdns,macb.yaml +++ b/Documentation/devicetree/bindings/net/cdns,macb.yaml @@ -81,6 +81,25 @@ properties: phy-handle: true + phys: + maxItems: 1 + + phy-names: + const: sgmii-phy + description: + Required with ZynqMP SoC when in SGMII mode. + Should reference PS-GTR generic PHY device for this controller + instance. See ZynqMP example. + + resets: + maxItems: 1 + description: + Recommended with ZynqMP, specify reset control for this + controller instance with zynqmp-reset driver. + + reset-names: + maxItems: 1 + fixed-link: true iommus: @@ -157,3 +176,40 @@ examples: reset-gpios = <&pioE 6 1>; }; }; + + - | + #include <dt-bindings/clock/xlnx-zynqmp-clk.h> + #include <dt-bindings/power/xlnx-zynqmp-power.h> + #include <dt-bindings/reset/xlnx-zynqmp-resets.h> + #include <dt-bindings/phy/phy.h> + + bus { + #address-cells = <2>; + #size-cells = <2>; + gem1: ethernet@ff0c0000 { + compatible = "cdns,zynqmp-gem", "cdns,gem"; + interrupt-parent = <&gic>; + interrupts = <0 59 4>, <0 59 4>; + reg = <0x0 0xff0c0000 0x0 0x1000>; + clocks = <&zynqmp_clk LPD_LSBUS>, <&zynqmp_clk GEM1_REF>, + <&zynqmp_clk GEM1_TX>, <&zynqmp_clk GEM1_RX>, + <&zynqmp_clk GEM_TSU>; + clock-names = "pclk", "hclk", "tx_clk", "rx_clk", "tsu_clk"; + #address-cells = <1>; + #size-cells = <0>; + #stream-id-cells = <1>; + iommus = <&smmu 0x875>; + power-domains = <&zynqmp_firmware PD_ETH_1>; + resets = <&zynqmp_reset ZYNQMP_RESET_GEM1>; + reset-names = "gem1_rst"; + status = "okay"; + phy-mode = "sgmii"; + phy-names = "sgmii-phy"; + phys = <&psgtr 1 PHY_TYPE_SGMII 1 1>; + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt deleted file mode 100644 index 6c559981d110..000000000000 --- a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.txt +++ /dev/null @@ -1,92 +0,0 @@ -Cortina Systems Gemini Ethernet Controller -========================================== - -This ethernet controller is found in the Gemini SoC family: -StorLink SL3512 and SL3516, also known as Cortina Systems -CS3512 and CS3516. - -Required properties: -- compatible: must be "cortina,gemini-ethernet" -- reg: must contain the global registers and the V-bit and A-bit - memory areas, in total three register sets. -- syscon: a phandle to the system controller -- #address-cells: must be specified, must be <1> -- #size-cells: must be specified, must be <1> -- ranges: should be state like this giving a 1:1 address translation - for the subnodes - -The subnodes represents the two ethernet ports in this device. -They are not independent of each other since they share resources -in the parent node, and are thus children. - -Required subnodes: -- port0: contains the resources for ethernet port 0 -- port1: contains the resources for ethernet port 1 - -Required subnode properties: -- compatible: must be "cortina,gemini-ethernet-port" -- reg: must contain two register areas: the DMA/TOE memory and - the GMAC memory area of the port -- interrupts: should contain the interrupt line of the port. - this is nominally a level interrupt active high. -- resets: this must provide an SoC-integrated reset line for - the port. -- clocks: this should contain a handle to the PCLK clock for - clocking the silicon in this port -- clock-names: must be "PCLK" - -Optional subnode properties: -- phy-mode: see ethernet.txt -- phy-handle: see ethernet.txt - -Example: - -mdio-bus { - (...) - phy0: ethernet-phy@1 { - reg = <1>; - device_type = "ethernet-phy"; - }; - phy1: ethernet-phy@3 { - reg = <3>; - device_type = "ethernet-phy"; - }; -}; - - -ethernet@60000000 { - compatible = "cortina,gemini-ethernet"; - reg = <0x60000000 0x4000>, /* Global registers, queue */ - <0x60004000 0x2000>, /* V-bit */ - <0x60006000 0x2000>; /* A-bit */ - syscon = <&syscon>; - #address-cells = <1>; - #size-cells = <1>; - ranges; - - gmac0: ethernet-port@0 { - compatible = "cortina,gemini-ethernet-port"; - reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */ - <0x6000a000 0x2000>; /* Port 0 GMAC */ - interrupt-parent = <&intcon>; - interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; - resets = <&syscon GEMINI_RESET_GMAC0>; - clocks = <&syscon GEMINI_CLK_GATE_GMAC0>; - clock-names = "PCLK"; - phy-mode = "rgmii"; - phy-handle = <&phy0>; - }; - - gmac1: ethernet-port@1 { - compatible = "cortina,gemini-ethernet-port"; - reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */ - <0x6000e000 0x2000>; /* Port 1 GMAC */ - interrupt-parent = <&intcon>; - interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; - resets = <&syscon GEMINI_RESET_GMAC1>; - clocks = <&syscon GEMINI_CLK_GATE_GMAC1>; - clock-names = "PCLK"; - phy-mode = "rgmii"; - phy-handle = <&phy1>; - }; -}; diff --git a/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml new file mode 100644 index 000000000000..cc01b9b5752a --- /dev/null +++ b/Documentation/devicetree/bindings/net/cortina,gemini-ethernet.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/cortina,gemini-ethernet.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cortina Systems Gemini Ethernet Controller + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: | + This ethernet controller is found in the Gemini SoC family: + StorLink SL3512 and SL3516, also known as Cortina Systems + CS3512 and CS3516. + +properties: + compatible: + const: cortina,gemini-ethernet + + reg: + minItems: 3 + description: must contain the global registers and the V-bit and A-bit + memory areas, in total three register sets. + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + ranges: true + +#The subnodes represents the two ethernet ports in this device. +#They are not independent of each other since they share resources +#in the parent node, and are thus children. +patternProperties: + "^ethernet-port@[0-9]+$": + type: object + description: contains the resources for ethernet port + allOf: + - $ref: ethernet-controller.yaml# + properties: + compatible: + const: cortina,gemini-ethernet-port + + reg: + items: + - description: DMA/TOE memory + - description: GMAC memory area of the port + + interrupts: + maxItems: 1 + description: should contain the interrupt line of the port. + this is nominally a level interrupt active high. + + resets: + maxItems: 1 + description: this must provide an SoC-integrated reset line for the port. + + clocks: + maxItems: 1 + description: this should contain a handle to the PCLK clock for + clocking the silicon in this port + + clock-names: + const: PCLK + + required: + - reg + - compatible + - interrupts + - resets + - clocks + - clock-names + +required: + - compatible + - reg + - ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/clock/cortina,gemini-clock.h> + #include <dt-bindings/reset/cortina,gemini-reset.h> + mdio0: mdio { + #address-cells = <1>; + #size-cells = <0>; + phy0: ethernet-phy@1 { + reg = <1>; + device_type = "ethernet-phy"; + }; + phy1: ethernet-phy@3 { + reg = <3>; + device_type = "ethernet-phy"; + }; + }; + + + ethernet@60000000 { + compatible = "cortina,gemini-ethernet"; + reg = <0x60000000 0x4000>, /* Global registers, queue */ + <0x60004000 0x2000>, /* V-bit */ + <0x60006000 0x2000>; /* A-bit */ + #address-cells = <1>; + #size-cells = <1>; + ranges; + + gmac0: ethernet-port@0 { + compatible = "cortina,gemini-ethernet-port"; + reg = <0x60008000 0x2000>, /* Port 0 DMA/TOE */ + <0x6000a000 0x2000>; /* Port 0 GMAC */ + interrupt-parent = <&intcon>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH>; + resets = <&syscon GEMINI_RESET_GMAC0>; + clocks = <&syscon GEMINI_CLK_GATE_GMAC0>; + clock-names = "PCLK"; + phy-mode = "rgmii"; + phy-handle = <&phy0>; + }; + + gmac1: ethernet-port@1 { + compatible = "cortina,gemini-ethernet-port"; + reg = <0x6000c000 0x2000>, /* Port 1 DMA/TOE */ + <0x6000e000 0x2000>; /* Port 1 GMAC */ + interrupt-parent = <&intcon>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>; + resets = <&syscon GEMINI_RESET_GMAC1>; + clocks = <&syscon GEMINI_CLK_GATE_GMAC1>; + clock-names = "PCLK"; + phy-mode = "rgmii"; + phy-handle = <&phy1>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/davicom,dm9051.yaml b/Documentation/devicetree/bindings/net/davicom,dm9051.yaml new file mode 100644 index 000000000000..52e852fef753 --- /dev/null +++ b/Documentation/devicetree/bindings/net/davicom,dm9051.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/davicom,dm9051.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Davicom DM9051 SPI Ethernet Controller + +maintainers: + - Joseph CHANG <josright123@gmail.com> + +description: | + The DM9051 is a fully integrated and cost-effective low pin count single + chip Fast Ethernet controller with a Serial Peripheral Interface (SPI). + +allOf: + - $ref: ethernet-controller.yaml# + +properties: + compatible: + const: davicom,dm9051 + + reg: + maxItems: 1 + + spi-max-frequency: + maximum: 45000000 + + interrupts: + maxItems: 1 + + local-mac-address: true + + mac-address: true + +required: + - compatible + - reg + - spi-max-frequency + - interrupts + +additionalProperties: false + +examples: + # Raspberry Pi platform + - | + /* for Raspberry Pi with pin control stuff for GPIO irq */ + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + spi { + #address-cells = <1>; + #size-cells = <0>; + + ethernet@0 { + compatible = "davicom,dm9051"; + reg = <0>; /* spi chip select */ + local-mac-address = [00 00 00 00 00 00]; + interrupt-parent = <&gpio>; + interrupts = <26 IRQ_TYPE_LEVEL_LOW>; + spi-max-frequency = <31200000>; + }; + }; diff --git a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml index 702df848a71d..09317e16cb5d 100644 --- a/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml +++ b/Documentation/devicetree/bindings/net/dsa/dsa-port.yaml @@ -15,7 +15,7 @@ description: Ethernet switch port Description allOf: - - $ref: "http://devicetree.org/schemas/net/ethernet-controller.yaml#" + - $ref: /schemas/net/ethernet-controller.yaml# properties: reg: @@ -34,6 +34,8 @@ properties: full routing information must be given, not just the one hop routes to neighbouring switches $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 ethernet: description: @@ -51,6 +53,8 @@ properties: - edsa - ocelot - ocelot-8021q + - rtl8_4 + - rtl8_4t - seville phy-handle: true diff --git a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml index 84985f53bffd..184152087b60 100644 --- a/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml +++ b/Documentation/devicetree/bindings/net/dsa/microchip,ksz.yaml @@ -42,6 +42,12 @@ properties: description: Set if the output SYNCLKO frequency should be set to 125MHz instead of 25MHz. + microchip,synclko-disable: + $ref: /schemas/types.yaml#/definitions/flag + description: + Set if the output SYNCLKO clock should be disabled. Do not mix with + microchip,synclko-125. + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt b/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt deleted file mode 100644 index 7959ec237983..000000000000 --- a/Documentation/devicetree/bindings/net/dsa/realtek-smi.txt +++ /dev/null @@ -1,240 +0,0 @@ -Realtek SMI-based Switches -========================== - -The SMI "Simple Management Interface" is a two-wire protocol using -bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does -not use the MDIO protocol. This binding defines how to specify the -SMI-based Realtek devices. - -Required properties: - -- compatible: must be exactly one of: - "realtek,rtl8365mb" (4+1 ports) - "realtek,rtl8366" - "realtek,rtl8366rb" (4+1 ports) - "realtek,rtl8366s" (4+1 ports) - "realtek,rtl8367" - "realtek,rtl8367b" - "realtek,rtl8368s" (8 port) - "realtek,rtl8369" - "realtek,rtl8370" (8 port) - -Required properties: -- mdc-gpios: GPIO line for the MDC clock line. -- mdio-gpios: GPIO line for the MDIO data line. -- reset-gpios: GPIO line for the reset signal. - -Optional properties: -- realtek,disable-leds: if the LED drivers are not used in the - hardware design this will disable them so they are not turned on - and wasting power. - -Required subnodes: - -- interrupt-controller - - This defines an interrupt controller with an IRQ line (typically - a GPIO) that will demultiplex and handle the interrupt from the single - interrupt line coming out of one of the SMI-based chips. It most - importantly provides link up/down interrupts to the PHY blocks inside - the ASIC. - -Required properties of interrupt-controller: - -- interrupt: parent interrupt, see interrupt-controller/interrupts.txt -- interrupt-controller: see interrupt-controller/interrupts.txt -- #address-cells: should be <0> -- #interrupt-cells: should be <1> - -- mdio - - This defines the internal MDIO bus of the SMI device, mostly for the - purpose of being able to hook the interrupts to the right PHY and - the right PHY to the corresponding port. - -Required properties of mdio: - -- compatible: should be set to "realtek,smi-mdio" for all SMI devices - -See net/mdio.txt for additional MDIO bus properties. - -See net/dsa/dsa.txt for a list of additional required and optional properties -and subnodes of DSA switches. - -Examples: - -An example for the RTL8366RB: - -switch { - compatible = "realtek,rtl8366rb"; - /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */ - mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; - mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; - - switch_intc: interrupt-controller { - /* GPIO 15 provides the interrupt */ - interrupt-parent = <&gpio0>; - interrupts = <15 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - port@0 { - reg = <0>; - label = "lan0"; - phy-handle = <&phy0>; - }; - port@1 { - reg = <1>; - label = "lan1"; - phy-handle = <&phy1>; - }; - port@2 { - reg = <2>; - label = "lan2"; - phy-handle = <&phy2>; - }; - port@3 { - reg = <3>; - label = "lan3"; - phy-handle = <&phy3>; - }; - port@4 { - reg = <4>; - label = "wan"; - phy-handle = <&phy4>; - }; - port@5 { - reg = <5>; - label = "cpu"; - ethernet = <&gmac0>; - phy-mode = "rgmii"; - fixed-link { - speed = <1000>; - full-duplex; - }; - }; - }; - - mdio { - compatible = "realtek,smi-mdio", "dsa-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - phy0: phy@0 { - reg = <0>; - interrupt-parent = <&switch_intc>; - interrupts = <0>; - }; - phy1: phy@1 { - reg = <1>; - interrupt-parent = <&switch_intc>; - interrupts = <1>; - }; - phy2: phy@2 { - reg = <2>; - interrupt-parent = <&switch_intc>; - interrupts = <2>; - }; - phy3: phy@3 { - reg = <3>; - interrupt-parent = <&switch_intc>; - interrupts = <3>; - }; - phy4: phy@4 { - reg = <4>; - interrupt-parent = <&switch_intc>; - interrupts = <12>; - }; - }; -}; - -An example for the RTL8365MB-VC: - -switch { - compatible = "realtek,rtl8365mb"; - mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; - mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>; - reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; - - switch_intc: interrupt-controller { - interrupt-parent = <&gpio5>; - interrupts = <1 IRQ_TYPE_LEVEL_LOW>; - interrupt-controller; - #address-cells = <0>; - #interrupt-cells = <1>; - }; - - ports { - #address-cells = <1>; - #size-cells = <0>; - reg = <0>; - port@0 { - reg = <0>; - label = "swp0"; - phy-handle = <ðphy0>; - }; - port@1 { - reg = <1>; - label = "swp1"; - phy-handle = <ðphy1>; - }; - port@2 { - reg = <2>; - label = "swp2"; - phy-handle = <ðphy2>; - }; - port@3 { - reg = <3>; - label = "swp3"; - phy-handle = <ðphy3>; - }; - port@6 { - reg = <6>; - label = "cpu"; - ethernet = <&fec1>; - phy-mode = "rgmii"; - tx-internal-delay-ps = <2000>; - rx-internal-delay-ps = <2000>; - - fixed-link { - speed = <1000>; - full-duplex; - pause; - }; - }; - }; - - mdio { - compatible = "realtek,smi-mdio"; - #address-cells = <1>; - #size-cells = <0>; - - ethphy0: phy@0 { - reg = <0>; - interrupt-parent = <&switch_intc>; - interrupts = <0>; - }; - ethphy1: phy@1 { - reg = <1>; - interrupt-parent = <&switch_intc>; - interrupts = <1>; - }; - ethphy2: phy@2 { - reg = <2>; - interrupt-parent = <&switch_intc>; - interrupts = <2>; - }; - ethphy3: phy@3 { - reg = <3>; - interrupt-parent = <&switch_intc>; - interrupts = <3>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/net/dsa/realtek.yaml b/Documentation/devicetree/bindings/net/dsa/realtek.yaml new file mode 100644 index 000000000000..8756060895a8 --- /dev/null +++ b/Documentation/devicetree/bindings/net/dsa/realtek.yaml @@ -0,0 +1,394 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/dsa/realtek.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Realtek switches for unmanaged switches + +allOf: + - $ref: dsa.yaml# + +maintainers: + - Linus Walleij <linus.walleij@linaro.org> + +description: + Realtek advertises these chips as fast/gigabit switches or unmanaged + switches. They can be controlled using different interfaces, like SMI, + MDIO or SPI. + + The SMI "Simple Management Interface" is a two-wire protocol using + bit-banged GPIO that while it reuses the MDIO lines MCK and MDIO does + not use the MDIO protocol. This binding defines how to specify the + SMI-based Realtek devices. The realtek-smi driver is a platform driver + and it must be inserted inside a platform node. + + The MDIO-connected switches use MDIO protocol to access their registers. + The realtek-mdio driver is an MDIO driver and it must be inserted inside + an MDIO node. + +properties: + compatible: + enum: + - realtek,rtl8365mb + - realtek,rtl8366 + - realtek,rtl8366rb + - realtek,rtl8366s + - realtek,rtl8367 + - realtek,rtl8367b + - realtek,rtl8367rb + - realtek,rtl8367s + - realtek,rtl8368s + - realtek,rtl8369 + - realtek,rtl8370 + description: | + realtek,rtl8365mb: 4+1 ports + realtek,rtl8366: 5+1 ports + realtek,rtl8366rb: 5+1 ports + realtek,rtl8366s: 5+1 ports + realtek,rtl8367: + realtek,rtl8367b: + realtek,rtl8367rb: 5+2 ports + realtek,rtl8367s: 5+2 ports + realtek,rtl8368s: 8 ports + realtek,rtl8369: 8+1 ports + realtek,rtl8370: 8+2 ports + + mdc-gpios: + description: GPIO line for the MDC clock line. + maxItems: 1 + + mdio-gpios: + description: GPIO line for the MDIO data line. + maxItems: 1 + + reset-gpios: + description: GPIO to be used to reset the whole device + maxItems: 1 + + realtek,disable-leds: + type: boolean + description: | + if the LED drivers are not used in the hardware design, + this will disable them so they are not turned on + and wasting power. + + interrupt-controller: + type: object + description: | + This defines an interrupt controller with an IRQ line (typically + a GPIO) that will demultiplex and handle the interrupt from the single + interrupt line coming out of one of the Realtek switch chips. It most + importantly provides link up/down interrupts to the PHY blocks inside + the ASIC. + + properties: + + interrupt-controller: true + + interrupts: + maxItems: 1 + description: + A single IRQ line from the switch, either active LOW or HIGH + + '#address-cells': + const: 0 + + '#interrupt-cells': + const: 1 + + required: + - interrupt-controller + - '#address-cells' + - '#interrupt-cells' + + mdio: + $ref: /schemas/net/mdio.yaml# + unevaluatedProperties: false + + properties: + compatible: + const: realtek,smi-mdio + +if: + required: + - reg + +then: + not: + required: + - mdc-gpios + - mdio-gpios + - mdio + + properties: + mdc-gpios: false + mdio-gpios: false + mdio: false + +else: + required: + - mdc-gpios + - mdio-gpios + - mdio + - reset-gpios + +required: + - compatible + + # - mdc-gpios + # - mdio-gpios + # - reset-gpios + # - mdio + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + platform { + switch { + compatible = "realtek,rtl8366rb"; + /* 22 = MDIO (has input reads), 21 = MDC (clock, output only) */ + mdc-gpios = <&gpio0 21 GPIO_ACTIVE_HIGH>; + mdio-gpios = <&gpio0 22 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio0 14 GPIO_ACTIVE_LOW>; + + switch_intc1: interrupt-controller { + /* GPIO 15 provides the interrupt */ + interrupt-parent = <&gpio0>; + interrupts = <15 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "lan0"; + phy-handle = <&phy0>; + }; + port@1 { + reg = <1>; + label = "lan1"; + phy-handle = <&phy1>; + }; + port@2 { + reg = <2>; + label = "lan2"; + phy-handle = <&phy2>; + }; + port@3 { + reg = <3>; + label = "lan3"; + phy-handle = <&phy3>; + }; + port@4 { + reg = <4>; + label = "wan"; + phy-handle = <&phy4>; + }; + port@5 { + reg = <5>; + label = "cpu"; + ethernet = <&gmac0>; + phy-mode = "rgmii"; + fixed-link { + speed = <1000>; + full-duplex; + }; + }; + }; + + mdio { + compatible = "realtek,smi-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + phy0: ethernet-phy@0 { + reg = <0>; + interrupt-parent = <&switch_intc1>; + interrupts = <0>; + }; + phy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&switch_intc1>; + interrupts = <1>; + }; + phy2: ethernet-phy@2 { + reg = <2>; + interrupt-parent = <&switch_intc1>; + interrupts = <2>; + }; + phy3: ethernet-phy@3 { + reg = <3>; + interrupt-parent = <&switch_intc1>; + interrupts = <3>; + }; + phy4: ethernet-phy@4 { + reg = <4>; + interrupt-parent = <&switch_intc1>; + interrupts = <12>; + }; + }; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + platform { + switch { + compatible = "realtek,rtl8365mb"; + mdc-gpios = <&gpio1 16 GPIO_ACTIVE_HIGH>; + mdio-gpios = <&gpio1 17 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio5 0 GPIO_ACTIVE_LOW>; + + switch_intc2: interrupt-controller { + interrupt-parent = <&gpio5>; + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + label = "swp0"; + phy-handle = <ðphy0>; + }; + port@1 { + reg = <1>; + label = "swp1"; + phy-handle = <ðphy1>; + }; + port@2 { + reg = <2>; + label = "swp2"; + phy-handle = <ðphy2>; + }; + port@3 { + reg = <3>; + label = "swp3"; + phy-handle = <ðphy3>; + }; + port@6 { + reg = <6>; + label = "cpu"; + ethernet = <&fec1>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <2000>; + + fixed-link { + speed = <1000>; + full-duplex; + pause; + }; + }; + }; + + mdio { + compatible = "realtek,smi-mdio"; + #address-cells = <1>; + #size-cells = <0>; + + ethphy0: ethernet-phy@0 { + reg = <0>; + interrupt-parent = <&switch_intc2>; + interrupts = <0>; + }; + ethphy1: ethernet-phy@1 { + reg = <1>; + interrupt-parent = <&switch_intc2>; + interrupts = <1>; + }; + ethphy2: ethernet-phy@2 { + reg = <2>; + interrupt-parent = <&switch_intc2>; + interrupts = <2>; + }; + ethphy3: ethernet-phy@3 { + reg = <3>; + interrupt-parent = <&switch_intc2>; + interrupts = <3>; + }; + }; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + mdio { + #address-cells = <1>; + #size-cells = <0>; + + switch@29 { + compatible = "realtek,rtl8367s"; + reg = <29>; + + reset-gpios = <&gpio2 20 GPIO_ACTIVE_LOW>; + + switch_intc3: interrupt-controller { + interrupt-parent = <&gpio0>; + interrupts = <11 IRQ_TYPE_EDGE_FALLING>; + interrupt-controller; + #address-cells = <0>; + #interrupt-cells = <1>; + }; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + label = "lan4"; + }; + + port@1 { + reg = <1>; + label = "lan3"; + }; + + port@2 { + reg = <2>; + label = "lan2"; + }; + + port@3 { + reg = <3>; + label = "lan1"; + }; + + port@4 { + reg = <4>; + label = "wan"; + }; + + port@7 { + reg = <7>; + ethernet = <ðernet>; + phy-mode = "rgmii"; + tx-internal-delay-ps = <2000>; + rx-internal-delay-ps = <0>; + + 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 34c5463abcec..817794e56227 100644 --- a/Documentation/devicetree/bindings/net/ethernet-controller.yaml +++ b/Documentation/devicetree/bindings/net/ethernet-controller.yaml @@ -13,6 +13,10 @@ properties: $nodename: pattern: "^ethernet(@.*)?$" + label: + $ref: /schemas/types.yaml#/definitions/string + description: Human readable label on a port of a box. + local-mac-address: description: Specifies the MAC address that was assigned to the network device. diff --git a/Documentation/devicetree/bindings/net/fsl,fec.yaml b/Documentation/devicetree/bindings/net/fsl,fec.yaml index fd8371e31867..daa2f79a294f 100644 --- a/Documentation/devicetree/bindings/net/fsl,fec.yaml +++ b/Documentation/devicetree/bindings/net/fsl,fec.yaml @@ -158,11 +158,13 @@ properties: fsl,stop-mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to general purpose register node + - description: the gpr register offset for ENET stop request + - description: the gpr bit offset for ENET stop request description: Register bits of stop mode control, the format is <&gpr req_gpr req_bit>. - gpr is the phandle to general purpose register node. - req_gpr is the gpr register offset for ENET stop request. - req_bit is the gpr bit offset for ENET stop request. mdio: $ref: mdio.yaml# diff --git a/Documentation/devicetree/bindings/net/fsl-fman.txt b/Documentation/devicetree/bindings/net/fsl-fman.txt index 020337f3c05f..801efc7d6818 100644 --- a/Documentation/devicetree/bindings/net/fsl-fman.txt +++ b/Documentation/devicetree/bindings/net/fsl-fman.txt @@ -388,14 +388,24 @@ PROPERTIES Value type: <prop-encoded-array> Definition: A standard property. -- bus-frequency +- clocks + Usage: optional + Value type: <phandle> + Definition: A reference to the input clock of the controller + from which the MDC frequency is derived. + +- clock-frequency Usage: optional Value type: <u32> - Definition: Specifies the external MDIO bus clock speed to - be used, if different from the standard 2.5 MHz. - This may be due to the standard speed being unsupported (e.g. - due to a hardware problem), or to advertise that all relevant - components in the system support a faster speed. + Definition: Specifies the external MDC frequency, in Hertz, to + be used. Requires that the input clock is specified in the + "clocks" property. See also: mdio.yaml. + +- suppress-preamble + Usage: optional + Value type: <boolean> + Definition: Disable generation of preamble bits. See also: + mdio.yaml. - interrupts Usage: required for external MDIO diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml index 67eaf02dda80..4e1b79818aff 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-ethernet.yaml @@ -29,12 +29,18 @@ properties: queue-rx: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX queue node + - description: RX queue instance to use description: phandle to the RX queue on the NPE queue-txready: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TX READY queue node + - description: TX READY queue instance to use description: phandle to the TX READY queue on the NPE phy-mode: true @@ -43,7 +49,10 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the NPE this ethernet instance is using + - description: the NPE instance to use description: phandle to the NPE this ethernet instance is using and the instance to use in the second cell diff --git a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml index 4dcd53c3e0b4..e6329febb60c 100644 --- a/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml +++ b/Documentation/devicetree/bindings/net/intel,ixp4xx-hss.yaml @@ -25,39 +25,62 @@ properties: intel,npe-handle: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + items: + - description: phandle to the NPE this HSS instance is using + - description: the NPE instance number description: phandle to the NPE this HSS instance is using and the instance to use in the second cell intel,queue-chl-rxtrig: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX trigger queue on the NPE + - description: the queue instance number description: phandle to the RX trigger queue on the NPE intel,queue-chl-txready: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TX ready queue on the NPE + - description: the queue instance number description: phandle to the TX ready queue on the NPE intel,queue-pkt-rx: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the RX queue on the NPE + - description: the queue instance number description: phandle to the packet RX queue on the NPE intel,queue-pkt-tx: $ref: '/schemas/types.yaml#/definitions/phandle-array' maxItems: 4 + items: + items: + - description: phandle to the TX queue on the NPE + - description: the queue instance number description: phandle to the packet TX0, TX1, TX2 and TX3 queues on the NPE intel,queue-pkt-rxfree: $ref: '/schemas/types.yaml#/definitions/phandle-array' maxItems: 4 + items: + items: + - description: phandle to the RXFREE queue on the NPE + - description: the queue instance number description: phandle to the packet RXFREE0, RXFREE1, RXFREE2 and RXFREE3 queues on the NPE intel,queue-pkt-txdone: $ref: '/schemas/types.yaml#/definitions/phandle-array' - maxItems: 1 + items: + - items: + - description: phandle to the TXDONE queue on the NPE + - description: the queue instance number description: phandle to the packet TXDONE queue on the NPE cts-gpios: diff --git a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt index 691f886cfc4a..2bf31572b08d 100644 --- a/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt +++ b/Documentation/devicetree/bindings/net/marvell-armada-370-neta.txt @@ -5,6 +5,7 @@ Required properties: "marvell,armada-370-neta" "marvell,armada-xp-neta" "marvell,armada-3700-neta" + "marvell,armada-ac5-neta" - reg: address and length of the register set for the device. - interrupts: interrupt for the device - phy: See ethernet.txt file in the same directory. diff --git a/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml new file mode 100644 index 000000000000..afd11c9422fa --- /dev/null +++ b/Documentation/devicetree/bindings/net/mctp-i2c-controller.yaml @@ -0,0 +1,92 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mctp-i2c-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MCTP I2C transport binding + +maintainers: + - Matt Johnston <matt@codeconstruct.com.au> + +description: | + An mctp-i2c-controller defines a local MCTP endpoint on an I2C controller. + MCTP I2C is specified by DMTF DSP0237. + + An mctp-i2c-controller must be attached to an I2C adapter which supports + slave functionality. I2C busses (either directly or as subordinate mux + busses) are attached to the mctp-i2c-controller with a 'mctp-controller' + property on each used bus. Each mctp-controller I2C bus will be presented + to the host system as a separate MCTP I2C instance. + +properties: + compatible: + const: mctp-i2c-controller + + reg: + minimum: 0x40000000 + maximum: 0x4000007f + description: | + 7 bit I2C address of the local endpoint. + I2C_OWN_SLAVE_ADDRESS (1<<30) flag must be set. + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + // Basic case of a single I2C bus + #include <dt-bindings/i2c/i2c.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + mctp-controller; + + mctp@30 { + compatible = "mctp-i2c-controller"; + reg = <(0x30 | I2C_OWN_SLAVE_ADDRESS)>; + }; + }; + + - | + // Mux topology with multiple MCTP-handling busses under + // a single mctp-i2c-controller. + // i2c1 and i2c6 can have MCTP devices, i2c5 does not. + #include <dt-bindings/i2c/i2c.h> + + i2c1: i2c { + #address-cells = <1>; + #size-cells = <0>; + mctp-controller; + + mctp@50 { + compatible = "mctp-i2c-controller"; + reg = <(0x50 | I2C_OWN_SLAVE_ADDRESS)>; + }; + }; + + i2c-mux { + #address-cells = <1>; + #size-cells = <0>; + i2c-parent = <&i2c1>; + + i2c5: i2c@0 { + #address-cells = <1>; + #size-cells = <0>; + reg = <0>; + eeprom@33 { + reg = <0x33>; + }; + }; + + i2c6: i2c@1 { + #address-cells = <1>; + #size-cells = <0>; + reg = <1>; + mctp-controller; + }; + }; diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt b/Documentation/devicetree/bindings/net/mediatek-dwmac.txt deleted file mode 100644 index afbcaebf062e..000000000000 --- a/Documentation/devicetree/bindings/net/mediatek-dwmac.txt +++ /dev/null @@ -1,91 +0,0 @@ -MediaTek DWMAC glue layer controller - -This file documents platform glue layer for stmmac. -Please see stmmac.txt for the other unchanged properties. - -The device node has following properties. - -Required properties: -- compatible: Should be "mediatek,mt2712-gmac" for MT2712 SoC -- reg: Address and length of the register set for the device -- interrupts: Should contain the MAC interrupts -- interrupt-names: Should contain a list of interrupt names corresponding to - the interrupts in the interrupts property, if available. - Should be "macirq" for the main MAC IRQ -- clocks: Must contain a phandle for each entry in clock-names. -- clock-names: The name of the clock listed in the clocks property. These are - "axi", "apb", "mac_main", "ptp_ref", "rmii_internal" for MT2712 SoC. -- mac-address: See ethernet.txt in the same directory -- phy-mode: See ethernet.txt in the same directory -- mediatek,pericfg: A phandle to the syscon node that control ethernet - interface and timing delay. - -Optional properties: -- mediatek,tx-delay-ps: TX clock delay macro value. Default is 0. - It should be defined for RGMII/MII interface. - It should be defined for RMII interface when the reference clock is from MT2712 SoC. -- mediatek,rx-delay-ps: RX clock delay macro value. Default is 0. - It should be defined for RGMII/MII interface. - It should be defined for RMII interface. -Both delay properties need to be a multiple of 170 for RGMII interface, -or will round down. Range 0~31*170. -Both delay properties need to be a multiple of 550 for MII/RMII interface, -or will round down. Range 0~31*550. - -- mediatek,rmii-rxc: boolean property, if present indicates that the RMII - reference clock, which is from external PHYs, is connected to RXC pin - on MT2712 SoC. - Otherwise, is connected to TXC pin. -- mediatek,rmii-clk-from-mac: boolean property, if present indicates that - MT2712 SoC provides the RMII reference clock, which outputs to TXC pin only. -- mediatek,txc-inverse: boolean property, if present indicates that - 1. tx clock will be inversed in MII/RGMII case, - 2. tx clock inside MAC will be inversed relative to reference clock - which is from external PHYs in RMII case, and it rarely happen. - 3. the reference clock, which outputs to TXC pin will be inversed in RMII case - when the reference clock is from MT2712 SoC. -- mediatek,rxc-inverse: boolean property, if present indicates that - 1. rx clock will be inversed in MII/RGMII case. - 2. reference clock will be inversed when arrived at MAC in RMII case, when - the reference clock is from external PHYs. - 3. the inside clock, which be sent to MAC, will be inversed in RMII case when - the reference clock is from MT2712 SoC. -- assigned-clocks: mac_main and ptp_ref clocks -- assigned-clock-parents: parent clocks of the assigned clocks - -Example: - eth: ethernet@1101c000 { - compatible = "mediatek,mt2712-gmac"; - reg = <0 0x1101c000 0 0x1300>; - interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>; - interrupt-names = "macirq"; - phy-mode ="rgmii-rxid"; - mac-address = [00 55 7b b5 7d f7]; - clock-names = "axi", - "apb", - "mac_main", - "ptp_ref", - "rmii_internal"; - clocks = <&pericfg CLK_PERI_GMAC>, - <&pericfg CLK_PERI_GMAC_PCLK>, - <&topckgen CLK_TOP_ETHER_125M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; - assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_SEL>, - <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>, - <&topckgen CLK_TOP_APLL1_D3>, - <&topckgen CLK_TOP_ETHERPLL_50M>; - power-domains = <&scpsys MT2712_POWER_DOMAIN_AUDIO>; - mediatek,pericfg = <&pericfg>; - mediatek,tx-delay-ps = <1530>; - mediatek,rx-delay-ps = <1530>; - mediatek,rmii-rxc; - mediatek,txc-inverse; - mediatek,rxc-inverse; - snps,txpbl = <1>; - snps,rxpbl = <1>; - snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>; - snps,reset-active-low; - }; diff --git a/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml new file mode 100644 index 000000000000..901944683322 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mediatek-dwmac.yaml @@ -0,0 +1,175 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mediatek-dwmac.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: MediaTek DWMAC glue layer controller + +maintainers: + - Biao Huang <biao.huang@mediatek.com> + +description: + This file documents platform glue layer for stmmac. + +# We need a select here so we don't match all nodes with 'snps,dwmac' +select: + properties: + compatible: + contains: + enum: + - mediatek,mt2712-gmac + - mediatek,mt8195-gmac + required: + - compatible + +allOf: + - $ref: "snps,dwmac.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt2712-gmac + - const: snps,dwmac-4.20a + - items: + - enum: + - mediatek,mt8195-gmac + - const: snps,dwmac-5.10a + + clocks: + minItems: 5 + items: + - description: AXI clock + - description: APB clock + - description: MAC Main clock + - description: PTP clock + - description: RMII reference clock provided by MAC + - description: MAC clock gate + + clock-names: + minItems: 5 + items: + - const: axi + - const: apb + - const: mac_main + - const: ptp_ref + - const: rmii_internal + - const: mac_cg + + mediatek,pericfg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + The phandle to the syscon node that control ethernet + interface and timing delay. + + mediatek,tx-delay-ps: + description: + The internal TX clock delay (provided by this driver) in nanoseconds. + For MT2712 RGMII interface, Allowed value need to be a multiple of 170, + or will round down. Range 0~31*170. + For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, + or will round down. Range 0~31*550. + For MT8195 RGMII/RMII/MII interface, Allowed value need to be a multiple of 290, + or will round down. Range 0~31*290. + + mediatek,rx-delay-ps: + description: + The internal RX clock delay (provided by this driver) in nanoseconds. + For MT2712 RGMII interface, Allowed value need to be a multiple of 170, + or will round down. Range 0~31*170. + For MT2712 RMII/MII interface, Allowed value need to be a multiple of 550, + or will round down. Range 0~31*550. + For MT8195 RGMII/RMII/MII interface, Allowed value need to be a multiple + of 290, or will round down. Range 0~31*290. + + mediatek,rmii-rxc: + type: boolean + description: + If present, indicates that the RMII reference clock, which is from external + PHYs, is connected to RXC pin. Otherwise, is connected to TXC pin. + + mediatek,rmii-clk-from-mac: + type: boolean + description: + If present, indicates that MAC provides the RMII reference clock, which + outputs to TXC pin only. + + mediatek,txc-inverse: + type: boolean + description: + If present, indicates that + 1. tx clock will be inversed in MII/RGMII case, + 2. tx clock inside MAC will be inversed relative to reference clock + which is from external PHYs in RMII case, and it rarely happen. + 3. the reference clock, which outputs to TXC pin will be inversed in RMII case + when the reference clock is from MAC. + + mediatek,rxc-inverse: + type: boolean + description: + If present, indicates that + 1. rx clock will be inversed in MII/RGMII case. + 2. reference clock will be inversed when arrived at MAC in RMII case, when + the reference clock is from external PHYs. + 3. the inside clock, which be sent to MAC, will be inversed in RMII case when + the reference clock is from MAC. + + mediatek,mac-wol: + type: boolean + description: + If present, indicates that MAC supports WOL(Wake-On-LAN), and MAC WOL will be enabled. + Otherwise, PHY WOL is perferred. + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - phy-mode + - mediatek,pericfg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2712-clk.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/power/mt2712-power.h> + + eth: ethernet@1101c000 { + compatible = "mediatek,mt2712-gmac", "snps,dwmac-4.20a"; + reg = <0x1101c000 0x1300>; + interrupts = <GIC_SPI 237 IRQ_TYPE_LEVEL_LOW>; + interrupt-names = "macirq"; + phy-mode ="rgmii-rxid"; + mac-address = [00 55 7b b5 7d f7]; + clock-names = "axi", + "apb", + "mac_main", + "ptp_ref", + "rmii_internal"; + clocks = <&pericfg CLK_PERI_GMAC>, + <&pericfg CLK_PERI_GMAC_PCLK>, + <&topckgen CLK_TOP_ETHER_125M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; + assigned-clocks = <&topckgen CLK_TOP_ETHER_125M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_SEL>, + <&topckgen CLK_TOP_ETHER_50M_RMII_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_ETHERPLL_125M>, + <&topckgen CLK_TOP_APLL1_D3>, + <&topckgen CLK_TOP_ETHERPLL_50M>; + power-domains = <&scpsys MT2712_POWER_DOMAIN_AUDIO>; + mediatek,pericfg = <&pericfg>; + mediatek,tx-delay-ps = <1530>; + snps,txpbl = <1>; + snps,rxpbl = <1>; + snps,reset-gpio = <&pio 87 GPIO_ACTIVE_LOW>; + snps,reset-delays-us = <0 10000 10000>; + }; diff --git a/Documentation/devicetree/bindings/net/micrel.txt b/Documentation/devicetree/bindings/net/micrel.txt index 8d157f0295a5..c5ab62c39133 100644 --- a/Documentation/devicetree/bindings/net/micrel.txt +++ b/Documentation/devicetree/bindings/net/micrel.txt @@ -45,3 +45,20 @@ Optional properties: In fiber mode, auto-negotiation is disabled and the PHY can only work in 100base-fx (full and half duplex) modes. + + - lan8814,ignore-ts: If present the PHY will not support timestamping. + + This option acts as check whether Timestamping is supported by + hardware or not. LAN8814 phy support hardware tmestamping. + + - lan8814,latency_rx_10: Configures Latency value of phy in ingress at 10 Mbps. + + - lan8814,latency_tx_10: Configures Latency value of phy in egress at 10 Mbps. + + - lan8814,latency_rx_100: Configures Latency value of phy in ingress at 100 Mbps. + + - lan8814,latency_tx_100: Configures Latency value of phy in egress at 100 Mbps. + + - lan8814,latency_rx_1000: Configures Latency value of phy in ingress at 1000 Mbps. + + - lan8814,latency_tx_1000: Configures Latency value of phy in egress at 1000 Mbps. diff --git a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml index e79e4e166ad8..13812768b923 100644 --- a/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,lan966x-switch.yaml @@ -38,6 +38,7 @@ properties: - description: register based extraction - description: frame dma based extraction - description: analyzer interrupt + - description: ptp interrupt interrupt-names: minItems: 1 @@ -45,6 +46,7 @@ properties: - const: xtr - const: fdma - const: ana + - const: ptp resets: items: diff --git a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml index 347b912a46bb..6c86d3d85e99 100644 --- a/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml +++ b/Documentation/devicetree/bindings/net/microchip,sparx5-switch.yaml @@ -53,12 +53,14 @@ properties: items: - description: register based extraction - description: frame dma based extraction + - description: ptp interrupt interrupt-names: minItems: 1 items: - const: xtr - const: fdma + - const: ptp resets: items: diff --git a/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml new file mode 100644 index 000000000000..ee0a504bdb24 --- /dev/null +++ b/Documentation/devicetree/bindings/net/mscc,vsc7514-switch.yaml @@ -0,0 +1,191 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/net/mscc,vsc7514-switch.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip VSC7514 Ethernet switch controller + +maintainers: + - Vladimir Oltean <vladimir.oltean@nxp.com> + - Claudiu Manoil <claudiu.manoil@nxp.com> + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +description: | + Bindings for the Microchip VSC7514 switch driver + + The VSC7514 switch driver handles up to 11 ports and can inject/extract + packets using CPU. Additionally, PTP is supported as well as FDMA for faster + packet extraction/injection. + +properties: + $nodename: + pattern: "^switch@[0-9a-f]+$" + + compatible: + const: mscc,vsc7514-switch + + reg: + items: + - description: system target + - description: rewriter target + - description: qs target + - description: PTP target + - description: Port0 target + - description: Port1 target + - description: Port2 target + - description: Port3 target + - description: Port4 target + - description: Port5 target + - description: Port6 target + - description: Port7 target + - description: Port8 target + - description: Port9 target + - description: Port10 target + - description: QSystem target + - description: Analyzer target + - description: S0 target + - description: S1 target + - description: S2 target + - description: fdma target + + reg-names: + items: + - const: sys + - const: rew + - const: qs + - const: ptp + - const: port0 + - const: port1 + - const: port2 + - const: port3 + - const: port4 + - const: port5 + - const: port6 + - const: port7 + - const: port8 + - const: port9 + - const: port10 + - const: qsys + - const: ana + - const: s0 + - const: s1 + - const: s2 + - const: fdma + + interrupts: + minItems: 1 + items: + - description: PTP ready + - description: register based extraction + - description: frame dma based extraction + + interrupt-names: + minItems: 1 + items: + - const: ptp_rdy + - const: xtr + - const: fdma + + ethernet-ports: + type: object + + properties: + '#address-cells': + const: 1 + '#size-cells': + const: 0 + + additionalProperties: false + + patternProperties: + "^port@[0-9a-f]+$": + type: object + description: Ethernet ports handled by the switch + + $ref: ethernet-controller.yaml# + + unevaluatedProperties: false + + properties: + reg: + description: Switch port number + + phy-handle: true + + phy-mode: true + + fixed-link: true + + mac-address: true + + required: + - reg + - phy-mode + + oneOf: + - required: + - phy-handle + - required: + - fixed-link + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - ethernet-ports + +additionalProperties: false + +examples: + - | + switch@1010000 { + compatible = "mscc,vsc7514-switch"; + reg = <0x1010000 0x10000>, + <0x1030000 0x10000>, + <0x1080000 0x100>, + <0x10e0000 0x10000>, + <0x11e0000 0x100>, + <0x11f0000 0x100>, + <0x1200000 0x100>, + <0x1210000 0x100>, + <0x1220000 0x100>, + <0x1230000 0x100>, + <0x1240000 0x100>, + <0x1250000 0x100>, + <0x1260000 0x100>, + <0x1270000 0x100>, + <0x1280000 0x100>, + <0x1800000 0x80000>, + <0x1880000 0x10000>, + <0x1040000 0x10000>, + <0x1050000 0x10000>, + <0x1060000 0x10000>, + <0x1a0 0x1c4>; + reg-names = "sys", "rew", "qs", "ptp", "port0", "port1", + "port2", "port3", "port4", "port5", "port6", + "port7", "port8", "port9", "port10", "qsys", + "ana", "s0", "s1", "s2", "fdma"; + interrupts = <18 21 16>; + interrupt-names = "ptp_rdy", "xtr", "fdma"; + + ethernet-ports { + #address-cells = <1>; + #size-cells = <0>; + + port0: port@0 { + reg = <0>; + phy-handle = <&phy0>; + phy-mode = "internal"; + }; + port1: port@1 { + reg = <1>; + phy-handle = <&phy1>; + phy-mode = "internal"; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/net/mscc-miim.txt b/Documentation/devicetree/bindings/net/mscc-miim.txt index 7104679cf59d..70e0cb1ee485 100644 --- a/Documentation/devicetree/bindings/net/mscc-miim.txt +++ b/Documentation/devicetree/bindings/net/mscc-miim.txt @@ -2,7 +2,7 @@ Microsemi MII Management Controller (MIIM) / MDIO ================================================= Properties: -- compatible: must be "mscc,ocelot-miim" +- compatible: must be "mscc,ocelot-miim" or "microchip,lan966x-miim" - reg: The base address of the MDIO bus controller register bank. Optionally, a second register bank can be defined if there is an associated reset register for internal PHYs diff --git a/Documentation/devicetree/bindings/net/mscc-ocelot.txt b/Documentation/devicetree/bindings/net/mscc-ocelot.txt deleted file mode 100644 index 3b6290b45ce5..000000000000 --- a/Documentation/devicetree/bindings/net/mscc-ocelot.txt +++ /dev/null @@ -1,83 +0,0 @@ -Microsemi Ocelot network Switch -=============================== - -The Microsemi Ocelot network switch can be found on Microsemi SoCs (VSC7513, -VSC7514) - -Required properties: -- compatible: Should be "mscc,vsc7514-switch" -- reg: Must contain an (offset, length) pair of the register set for each - entry in reg-names. -- reg-names: Must include the following entries: - - "sys" - - "rew" - - "qs" - - "ptp" (optional due to backward compatibility) - - "qsys" - - "ana" - - "portX" with X from 0 to the number of last port index available on that - switch -- interrupts: Should contain the switch interrupts for frame extraction, - frame injection and PTP ready. -- interrupt-names: should contain the interrupt names: "xtr", "inj". Can contain - "ptp_rdy" which is optional due to backward compatibility. -- ethernet-ports: A container for child nodes representing switch ports. - -The ethernet-ports container has the following properties - -Required properties: - -- #address-cells: Must be 1 -- #size-cells: Must be 0 - -Each port node must have the following mandatory properties: -- reg: Describes the port address in the switch - -Port nodes may also contain the following optional standardised -properties, described in binding documents: - -- phy-handle: Phandle to a PHY on an MDIO bus. See - Documentation/devicetree/bindings/net/ethernet.txt for details. - -Example: - - switch@1010000 { - compatible = "mscc,vsc7514-switch"; - reg = <0x1010000 0x10000>, - <0x1030000 0x10000>, - <0x1080000 0x100>, - <0x10e0000 0x10000>, - <0x11e0000 0x100>, - <0x11f0000 0x100>, - <0x1200000 0x100>, - <0x1210000 0x100>, - <0x1220000 0x100>, - <0x1230000 0x100>, - <0x1240000 0x100>, - <0x1250000 0x100>, - <0x1260000 0x100>, - <0x1270000 0x100>, - <0x1280000 0x100>, - <0x1800000 0x80000>, - <0x1880000 0x10000>; - reg-names = "sys", "rew", "qs", "ptp", "port0", "port1", - "port2", "port3", "port4", "port5", "port6", - "port7", "port8", "port9", "port10", "qsys", - "ana"; - interrupts = <18 21 22>; - interrupt-names = "ptp_rdy", "xtr", "inj"; - - ethernet-ports { - #address-cells = <1>; - #size-cells = <0>; - - port0: port@0 { - reg = <0>; - phy-handle = <&phy0>; - }; - port1: port@1 { - reg = <1>; - phy-handle = <&phy1>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml index ee4afe361fac..011363166789 100644 --- a/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml +++ b/Documentation/devicetree/bindings/net/nxp,dwmac-imx.yaml @@ -54,6 +54,10 @@ properties: intf_mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to the GPR syscon + - description: the offset of the GPR register description: Should be phandle/offset pair. The phandle to the syscon node which encompases the GPR register, and the offset of the GPR register. diff --git a/Documentation/devicetree/bindings/net/qcom,ethqos.txt b/Documentation/devicetree/bindings/net/qcom,ethqos.txt index fcf5035810b5..1f5746849a71 100644 --- a/Documentation/devicetree/bindings/net/qcom,ethqos.txt +++ b/Documentation/devicetree/bindings/net/qcom,ethqos.txt @@ -7,7 +7,9 @@ This device has following properties: Required properties: -- compatible: Should be qcom,qcs404-ethqos" +- compatible: Should be one of: + "qcom,qcs404-ethqos" + "qcom,sm8150-ethqos" - reg: Address and length of the register set for the device diff --git a/Documentation/devicetree/bindings/net/qcom,ipa.yaml b/Documentation/devicetree/bindings/net/qcom,ipa.yaml index b86edf67ce62..58ecc62adfaa 100644 --- a/Documentation/devicetree/bindings/net/qcom,ipa.yaml +++ b/Documentation/devicetree/bindings/net/qcom,ipa.yaml @@ -107,6 +107,10 @@ properties: - const: imem - const: config + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: phandle to the AOSS side-channel message RAM + qcom,smem-states: $ref: /schemas/types.yaml#/definitions/phandle-array description: State bits used in by the AP to signal the modem. @@ -222,6 +226,8 @@ examples: "imem", "config"; + qcom,qmp = <&aoss_qmp>; + qcom,smem-states = <&ipa_smp2p_out 0>, <&ipa_smp2p_out 1>; qcom,smem-state-names = "ipa-clock-enabled-valid", diff --git a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml index bda821065a2b..ee2ccacc39ff 100644 --- a/Documentation/devicetree/bindings/net/renesas,etheravb.yaml +++ b/Documentation/devicetree/bindings/net/renesas,etheravb.yaml @@ -45,8 +45,10 @@ properties: - items: - enum: + - renesas,r9a07g043-gbeth # RZ/G2UL - renesas,r9a07g044-gbeth # RZ/G2{L,LC} - - const: renesas,rzg2l-gbeth # RZ/G2L + - renesas,r9a07g054-gbeth # RZ/V2L + - const: renesas,rzg2l-gbeth # RZ/{G2L,G2UL,V2L} family reg: true diff --git a/Documentation/devicetree/bindings/net/snps,dwmac.yaml b/Documentation/devicetree/bindings/net/snps,dwmac.yaml index 7eb43707e601..2d5248f5b919 100644 --- a/Documentation/devicetree/bindings/net/snps,dwmac.yaml +++ b/Documentation/devicetree/bindings/net/snps,dwmac.yaml @@ -340,21 +340,21 @@ allOf: description: Programmable Burst Length (tx and rx) $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,txpbl: description: Tx Programmable Burst Length. If set, DMA tx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,rxpbl: description: Rx Programmable Burst Length. If set, DMA rx will use this value rather than snps,pbl. $ref: /schemas/types.yaml#/definitions/uint32 - enum: [2, 4, 8] + enum: [1, 2, 4, 8, 16, 32] snps,no-pbl-x8: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml index aad5a9f3f962..e602761f7b14 100644 --- a/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml +++ b/Documentation/devicetree/bindings/net/socionext,uniphier-ave4.yaml @@ -66,6 +66,10 @@ properties: socionext,syscon-phy-mode: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to syscon that configures phy mode + - description: ID of MAC instance description: A phandle to syscon with one argument that configures phy mode. The argument is the ID of MAC instance. diff --git a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml index 3d8a3b763ae6..5c93167b3b41 100644 --- a/Documentation/devicetree/bindings/net/stm32-dwmac.yaml +++ b/Documentation/devicetree/bindings/net/stm32-dwmac.yaml @@ -74,6 +74,10 @@ properties: st,syscon: $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: phandle to the syscon node which encompases the glue register + - description: offset of the control register description: Should be phandle/offset pair. The phandle to the syscon node which encompases the glue register, and the offset of the control register diff --git a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml index 07a00f53adbf..31bf825c6598 100644 --- a/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml +++ b/Documentation/devicetree/bindings/net/ti,cpsw-switch.yaml @@ -88,8 +88,7 @@ properties: type: object description: CPSW external ports - allOf: - - $ref: ethernet-controller.yaml# + $ref: ethernet-controller.yaml# properties: reg: diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml index 4b97a0f1175b..b8281d8be940 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpsw-nuss.yaml @@ -136,6 +136,11 @@ properties: ti,syscon-efuse: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the system control device node which + provides access to efuse + - description: offset to efuse registers??? description: Phandle to the system control device node which provides access to efuse IO range with MAC addresses diff --git a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml index 1a81bf70c88c..a30419ef550a 100644 --- a/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml +++ b/Documentation/devicetree/bindings/net/ti,k3-am654-cpts.yaml @@ -103,12 +103,6 @@ properties: clocks: maxItems: 8 - assigned-clocks: - maxItems: 1 - - assigned-clocks-parents: - maxItems: 1 - required: - clocks diff --git a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml index 269cd63fb544..249967d8d750 100644 --- a/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml +++ b/Documentation/devicetree/bindings/net/wireless/mediatek,mt76.yaml @@ -18,7 +18,7 @@ description: | wireless device. The node is expected to be specified as a child node of the PCI controller to which the wireless chip is connected. Alternatively, it can specify the wireless part of the MT7628/MT7688 - or MT7622 SoC. + or MT7622/MT7986 SoC. allOf: - $ref: ieee80211.yaml# @@ -29,9 +29,13 @@ properties: - mediatek,mt76 - mediatek,mt7628-wmac - mediatek,mt7622-wmac + - mediatek,mt7986-wmac reg: - maxItems: 1 + minItems: 1 + maxItems: 3 + description: + MT7986 should contain 3 regions consys, dcm, and sku, in this order. interrupts: maxItems: 1 @@ -39,6 +43,17 @@ properties: power-domains: maxItems: 1 + memory-region: + maxItems: 1 + + resets: + maxItems: 1 + description: + Specify the consys reset for mt7986. + + reset-name: + const: consys + mediatek,infracfg: $ref: /schemas/types.yaml#/definitions/phandle description: @@ -54,6 +69,10 @@ properties: mediatek,mtd-eeprom: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to MTD partition + - description: offset containing EEPROM data description: Phandle to a MTD partition + offset containing EEPROM data @@ -69,6 +88,15 @@ properties: calibration data is generic and specific calibration data should be pulled from the OTP ROM + mediatek,disable-radar-background: + type: boolean + description: + Disable/enable radar/CAC detection running on a dedicated offchannel + chain available on some hw. + Background radar/CAC detection allows to avoid the CAC downtime + switching on a different channel during CAC detection on the selected + radar channel. + led: type: object $ref: /schemas/leds/common.yaml# @@ -165,7 +193,7 @@ required: - compatible - reg -additionalProperties: false +unevaluatedProperties: false examples: - | @@ -231,3 +259,15 @@ examples: power-domains = <&scpsys 3>; }; + + - | + wifi@18000000 { + compatible = "mediatek,mt7986-wmac"; + resets = <&watchdog 23>; + reset-names = "consys"; + reg = <0x18000000 0x1000000>, + <0x10003000 0x1000>, + <0x11d10000 0x1000>; + interrupts = <GIC_SPI 213 IRQ_TYPE_LEVEL_HIGH>; + memory-region = <&wmcpu_emi>; + }; diff --git a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml index 6687ab720304..e558587ff885 100644 --- a/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml +++ b/Documentation/devicetree/bindings/nvmem/allwinner,sun4i-a10-sid.yaml @@ -20,6 +20,7 @@ properties: - const: allwinner,sun7i-a20-sid - const: allwinner,sun8i-a83t-sid - const: allwinner,sun8i-h3-sid + - const: allwinner,sun20i-d1-sid - const: allwinner,sun50i-a64-sid - items: - const: allwinner,sun50i-a100-sid diff --git a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml index 8c3f0cd22821..25033de3ef6b 100644 --- a/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml +++ b/Documentation/devicetree/bindings/nvmem/brcm,nvram.yaml @@ -14,6 +14,8 @@ description: | NVRAM can be accessed on Broadcom BCM47xx MIPS and Northstar ARM Cortex-A9 devices usiong I/O mapped memory. + NVRAM variables can be defined as NVMEM device subnodes. + maintainers: - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> @@ -27,11 +29,30 @@ properties: reg: maxItems: 1 + board_id: + type: object + description: Board identification name + + et0macaddr: + type: object + description: First Ethernet interface's MAC address + + et1macaddr: + type: object + description: Second Ethernet interface's MAC address + + et2macaddr: + type: object + description: Third Ethernet interface's MAC address + unevaluatedProperties: false examples: - | nvram@1eff0000 { - compatible = "brcm,nvram"; - reg = <0x1eff0000 0x10000>; + compatible = "brcm,nvram"; + reg = <0x1eff0000 0x10000>; + + mac: et0macaddr { + }; }; diff --git a/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml new file mode 100644 index 000000000000..80914b93638e --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/fsl,layerscape-sfp.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/fsl,layerscape-sfp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Layerscape Security Fuse Processor + +maintainers: + - Michael Walle <michael@walle.cc> + +description: | + SFP is the security fuse processor which among other things provide a + unique identifier per part. + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + enum: + - fsl,ls1028a-sfp + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + efuse@1e80000 { + compatible = "fsl,ls1028a-sfp"; + reg = <0x1e80000 0x8000>; + }; diff --git a/Documentation/devicetree/bindings/nvmem/nvmem.yaml b/Documentation/devicetree/bindings/nvmem/nvmem.yaml index 43ed7e32e5ac..3bb349c634cb 100644 --- a/Documentation/devicetree/bindings/nvmem/nvmem.yaml +++ b/Documentation/devicetree/bindings/nvmem/nvmem.yaml @@ -60,9 +60,6 @@ patternProperties: description: Size in bit within the address range specified by reg. - required: - - reg - additionalProperties: true examples: diff --git a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml index a835e64bc6f5..ee79e13b5fe0 100644 --- a/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml +++ b/Documentation/devicetree/bindings/nvmem/qcom,spmi-sdam.yaml @@ -38,34 +38,6 @@ required: - reg - ranges -patternProperties: - "^.*@[0-9a-f]+$": - type: object - - properties: - reg: - maxItems: 1 - description: - Offset and size in bytes within the storage device. - - bits: - $ref: /schemas/types.yaml#/definitions/uint32-array - maxItems: 1 - items: - items: - - minimum: 0 - maximum: 7 - description: - Offset in bit within the address range specified by reg. - - minimum: 1 - description: - Size in bit within the address range specified by reg. - - required: - - reg - - additionalProperties: false - unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml new file mode 100644 index 000000000000..a7644ebbc2ca --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/sunplus,sp7021-ocotp.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/sunplus,sp7021-ocotp.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: On-Chip OTP Memory for Sunplus SP7021 + +maintainers: + - Vincent Shih <vincent.sunplus@gmail.com> + +allOf: + - $ref: "nvmem.yaml#" + +properties: + compatible: + const: sunplus,sp7021-ocotp + + reg: + maxItems: 2 + + reg-names: + items: + - const: hb_gpio + - const: otprx + + clocks: + maxItems: 1 + + "#address-cells": + const: 1 + + "#size-cells": + const: 1 + + thermal-calibration: + type: object + description: thermal calibration values + + disconnect-voltage: + type: object + description: disconnect voltages of usb2 port 0 and port 1 + + mac-address0: + type: object + description: MAC address of ethernet port 0 + + mac-address1: + type: object + description: MAC address of ethernet port 1 + +required: + - compatible + - reg + - reg-names + - clocks + +unevaluatedProperties: false + +examples: + - | + otp: otp@9c00af00 { + compatible = "sunplus,sp7021-ocotp"; + reg = <0x9c00af00 0x34>, <0x9c00af80 0x58>; + reg-names = "hb_gpio", "otprx"; + clocks = <&clkc 0x15>; + + #address-cells = <1>; + #size-cells = <1>; + therm_calib: thermal-calibration@14 { + reg = <0x14 0x3>; + }; + disc_vol: disconnect-voltage@18 { + reg = <0x18 0x2>; + }; + mac_addr0: mac-address0@34 { + reg = <0x34 0x6>; + }; + mac_addr1: mac-address1@3a { + reg = <0x3a 0x6>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml new file mode 100644 index 000000000000..e70b2a60cb9a --- /dev/null +++ b/Documentation/devicetree/bindings/nvmem/u-boot,env.yaml @@ -0,0 +1,62 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/nvmem/u-boot,env.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: U-Boot environment variables + +description: | + U-Boot uses environment variables to store device parameters and + configuration. They may be used for booting process, setup or keeping end user + info. + + Data is stored using U-Boot specific formats (variant specific header and NUL + separated key-value pairs). + + Environment data can be stored on various storage entities, e.g.: + 1. Raw flash partition + 2. UBI volume + + This binding allows marking storage device (as containing env data) and + specifying used format. + + Right now only flash partition case is covered but it may be extended to e.g. + UBI volumes in the future. + +maintainers: + - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> + +properties: + compatible: + oneOf: + - description: A standalone env data block + const: u-boot,env + - description: Two redundant blocks with active one flagged + const: u-boot,env-redundant-bool + - description: Two redundant blocks with active having higher counter + const: u-boot,env-redundant-count + + reg: + maxItems: 1 + +additionalProperties: false + +examples: + - | + partitions { + compatible = "fixed-partitions"; + #address-cells = <1>; + #size-cells = <1>; + + partition@0 { + reg = <0x0 0x40000>; + label = "u-boot"; + read-only; + }; + + env: partition@40000 { + compatible = "u-boot,env"; + reg = <0x40000 0x10000>; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml index 15a76bcd6d42..76c8acd981b3 100644 --- a/Documentation/devicetree/bindings/opp/opp-v2-base.yaml +++ b/Documentation/devicetree/bindings/opp/opp-v2-base.yaml @@ -93,6 +93,21 @@ patternProperties: minItems: 1 maxItems: 8 # Should be enough regulators + opp-microwatt: + description: | + The power for the OPP in micro-Watts. + + Entries for multiple regulators shall be provided in the same field + separated by angular brackets <>. If current values aren't required + for a regulator, then it shall be filled with 0. If power values + aren't required for any of the regulators, then this field is not + required. The OPP binding doesn't provide any provisions to relate the + values to their power supplies or the order in which the supplies need + to be configured and that is left for the implementation specific + binding. + minItems: 1 + maxItems: 8 # Should be enough regulators + opp-level: description: A value representing the performance level of the device. @@ -177,6 +192,8 @@ patternProperties: for the functioning of the current device at the current OPP (where this property is present). $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 patternProperties: '^opp-microvolt-': @@ -203,6 +220,14 @@ patternProperties: minItems: 1 maxItems: 8 # Should be enough regulators + '^opp-microwatt': + description: + Named opp-microwatt property. Similar to opp-microamp property, + but for microwatt instead. + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 8 # Should be enough regulators + dependencies: opp-avg-kBps: [ opp-peak-kBps ] diff --git a/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml new file mode 100644 index 000000000000..8c2e9ac5f68d --- /dev/null +++ b/Documentation/devicetree/bindings/opp/opp-v2-kryo-cpu.yaml @@ -0,0 +1,257 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/opp-v2-kryo-cpu.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. NVMEM OPP bindings + +maintainers: + - Ilia Lin <ilia.lin@kernel.org> + +allOf: + - $ref: opp-v2-base.yaml# + +description: | + In certain Qualcomm Technologies, Inc. SoCs like APQ8096 and MSM8996, + the CPU frequencies subset and voltage value of each OPP varies based on + the silicon variant in use. + Qualcomm Technologies, Inc. Process Voltage Scaling Tables + defines the voltage and frequency value based on the msm-id in SMEM + and speedbin blown in the efuse combination. + The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC + to provide the OPP framework with required information (existing HW bitmap). + This is used to determine the voltage and frequency value for each OPP of + operating-points-v2 table when it is parsed by the OPP framework. + +properties: + compatible: + const: operating-points-v2-kryo-cpu + + nvmem-cells: + description: | + A phandle pointing to a nvmem-cells node representing the + efuse registers that has information about the + speedbin that is used to select the right frequency/voltage + value pair. + + opp-shared: true + +patternProperties: + '^opp-?[0-9]+$': + type: object + + properties: + opp-hz: true + + opp-microvolt: true + + opp-supported-hw: + description: | + A single 32 bit bitmap value, representing compatible HW. + Bitmap: + 0: MSM8996 V3, speedbin 0 + 1: MSM8996 V3, speedbin 1 + 2: MSM8996 V3, speedbin 2 + 3: unused + 4: MSM8996 SG, speedbin 0 + 5: MSM8996 SG, speedbin 1 + 6: MSM8996 SG, speedbin 2 + 7-31: unused + maximum: 0x77 + + clock-latency-ns: true + + required-opps: true + + required: + - opp-hz + +required: + - compatible + +if: + required: + - nvmem-cells +then: + patternProperties: + '^opp-?[0-9]+$': + required: + - opp-supported-hw + +additionalProperties: false + +examples: + - | + / { + model = "Qualcomm Technologies, Inc. DB820c"; + compatible = "arrow,apq8096-db820c", "qcom,apq8096-sbc", "qcom,apq8096"; + #address-cells = <2>; + #size-cells = <2>; + + cpus { + #address-cells = <2>; + #size-cells = <0>; + + CPU0: cpu@0 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x0>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 0>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + L2_0: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU1: cpu@1 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x1>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 0>; + operating-points-v2 = <&cluster0_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_0>; + }; + + CPU2: cpu@100 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x100>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 1>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + L2_1: l2-cache { + compatible = "cache"; + cache-level = <2>; + }; + }; + + CPU3: cpu@101 { + device_type = "cpu"; + compatible = "qcom,kryo"; + reg = <0x0 0x101>; + enable-method = "psci"; + cpu-idle-states = <&CPU_SLEEP_0>; + capacity-dmips-mhz = <1024>; + clocks = <&kryocc 1>; + operating-points-v2 = <&cluster1_opp>; + #cooling-cells = <2>; + next-level-cache = <&L2_1>; + }; + + cpu-map { + cluster0 { + core0 { + cpu = <&CPU0>; + }; + + core1 { + cpu = <&CPU1>; + }; + }; + + cluster1 { + core0 { + cpu = <&CPU2>; + }; + + core1 { + cpu = <&CPU3>; + }; + }; + }; + }; + + cluster0_opp: opp-table-0 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x71>; + clock-latency-ns = <200000>; + }; + opp-2188800000 { + opp-hz = /bits/ 64 <2188800000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + cluster1_opp: opp-table-1 { + compatible = "operating-points-v2-kryo-cpu"; + nvmem-cells = <&speedbin_efuse>; + opp-shared; + + opp-307200000 { + opp-hz = /bits/ 64 <307200000>; + opp-microvolt = <905000 905000 1140000>; + opp-supported-hw = <0x77>; + clock-latency-ns = <200000>; + }; + opp-1593600000 { + opp-hz = /bits/ 64 <1593600000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x70>; + clock-latency-ns = <200000>; + }; + opp-2150400000 { + opp-hz = /bits/ 64 <2150400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x31>; + clock-latency-ns = <200000>; + }; + opp-2342400000 { + opp-hz = /bits/ 64 <2342400000>; + opp-microvolt = <1140000 905000 1140000>; + opp-supported-hw = <0x10>; + clock-latency-ns = <200000>; + }; + }; + + smem { + compatible = "qcom,smem"; + memory-region = <&smem_mem>; + hwlocks = <&tcsr_mutex 3>; + }; + + soc { + #address-cells = <1>; + #size-cells = <1>; + + qfprom: qfprom@74000 { + compatible = "qcom,msm8996-qfprom", "qcom,qfprom"; + reg = <0x00074000 0x8ff>; + #address-cells = <1>; + #size-cells = <1>; + + speedbin_efuse: speedbin@133 { + reg = <0x133 0x1>; + bits = <5 3>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml new file mode 100644 index 000000000000..14a7a689ad6d --- /dev/null +++ b/Documentation/devicetree/bindings/opp/opp-v2-qcom-level.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/opp/opp-v2-qcom-level.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm OPP bindings to describe OPP nodes. + +maintainers: + - Niklas Cassel <nks@flawful.org> + +allOf: + - $ref: opp-v2-base.yaml# + +properties: + compatible: + const: operating-points-v2-qcom-level + +patternProperties: + '^opp-?[0-9]+$': + type: object + + properties: + opp-level: true + + qcom,opp-fuse-level: + description: | + A positive value representing the fuse corner/level associated with + this OPP node. Sometimes several corners/levels shares a certain fuse + corner/level. A fuse corner/level contains e.g. ref uV, min uV, + and max uV. + $ref: /schemas/types.yaml#/definitions/uint32 + + required: + - opp-level + - qcom,opp-fuse-level + +required: + - compatible + +additionalProperties: false + +examples: + - | + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; diff --git a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt b/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt deleted file mode 100644 index 64f07417ecfb..000000000000 --- a/Documentation/devicetree/bindings/opp/qcom-nvmem-cpufreq.txt +++ /dev/null @@ -1,796 +0,0 @@ -Qualcomm Technologies, Inc. NVMEM CPUFreq and OPP bindings -=================================== - -In Certain Qualcomm Technologies, Inc. SoCs like apq8096 and msm8996, -the CPU frequencies subset and voltage value of each OPP varies based on -the silicon variant in use. -Qualcomm Technologies, Inc. Process Voltage Scaling Tables -defines the voltage and frequency value based on the msm-id in SMEM -and speedbin blown in the efuse combination. -The qcom-cpufreq-nvmem driver reads the msm-id and efuse value from the SoC -to provide the OPP framework with required information (existing HW bitmap). -This is used to determine the voltage and frequency value for each OPP of -operating-points-v2 table when it is parsed by the OPP framework. - -Required properties: --------------------- -In 'cpu' nodes: -- operating-points-v2: Phandle to the operating-points-v2 table to use. - -In 'operating-points-v2' table: -- compatible: Should be - - 'operating-points-v2-kryo-cpu' for apq8096, msm8996, msm8974, - apq8064, ipq8064, msm8960 and ipq8074. - -Optional properties: --------------------- -In 'cpu' nodes: -- power-domains: A phandle pointing to the PM domain specifier which provides - the performance states available for active state management. - Please refer to the power-domains bindings - Documentation/devicetree/bindings/power/power_domain.txt - and also examples below. -- power-domain-names: Should be - - 'cpr' for qcs404. - -In 'operating-points-v2' table: -- nvmem-cells: A phandle pointing to a nvmem-cells node representing the - efuse registers that has information about the - speedbin that is used to select the right frequency/voltage - value pair. - Please refer the for nvmem-cells - bindings Documentation/devicetree/bindings/nvmem/nvmem.txt - and also examples below. - -In every OPP node: -- opp-supported-hw: A single 32 bit bitmap value, representing compatible HW. - Bitmap: - 0: MSM8996 V3, speedbin 0 - 1: MSM8996 V3, speedbin 1 - 2: MSM8996 V3, speedbin 2 - 3: unused - 4: MSM8996 SG, speedbin 0 - 5: MSM8996 SG, speedbin 1 - 6: MSM8996 SG, speedbin 2 - 7-31: unused - -Example 1: ---------- - - cpus { - #address-cells = <2>; - #size-cells = <0>; - - CPU0: cpu@0 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x0>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - L2_0: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU1: cpu@1 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x1>; - enable-method = "psci"; - clocks = <&kryocc 0>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster0_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_0>; - }; - - CPU2: cpu@100 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x100>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - L2_1: l2-cache { - compatible = "cache"; - cache-level = <2>; - }; - }; - - CPU3: cpu@101 { - device_type = "cpu"; - compatible = "qcom,kryo"; - reg = <0x0 0x101>; - enable-method = "psci"; - clocks = <&kryocc 1>; - cpu-supply = <&pm8994_s11_saw>; - operating-points-v2 = <&cluster1_opp>; - #cooling-cells = <2>; - next-level-cache = <&L2_1>; - }; - - cpu-map { - cluster0 { - core0 { - cpu = <&CPU0>; - }; - - core1 { - cpu = <&CPU1>; - }; - }; - - cluster1 { - core0 { - cpu = <&CPU2>; - }; - - core1 { - cpu = <&CPU3>; - }; - }; - }; - }; - - cluster0_opp: opp_table0 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-422400000 { - opp-hz = /bits/ 64 <422400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-768000000 { - opp-hz = /bits/ 64 <768000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-844800000 { - opp-hz = /bits/ 64 <844800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-960000000 { - opp-hz = /bits/ 64 <960000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1228800000 { - opp-hz = /bits/ 64 <1228800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x72>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x5>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1497600000 { - opp-hz = /bits/ 64 <1497600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x4>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x20>; - clock-latency-ns = <200000>; - }; - opp-2188800000 { - opp-hz = /bits/ 64 <2188800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - - cluster1_opp: opp_table1 { - compatible = "operating-points-v2-kryo-cpu"; - nvmem-cells = <&speedbin_efuse>; - opp-shared; - - opp-307200000 { - opp-hz = /bits/ 64 <307200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x77>; - clock-latency-ns = <200000>; - }; - opp-384000000 { - opp-hz = /bits/ 64 <384000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-403200000 { - opp-hz = /bits/ 64 <403200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-460800000 { - opp-hz = /bits/ 64 <460800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-480000000 { - opp-hz = /bits/ 64 <480000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-537600000 { - opp-hz = /bits/ 64 <537600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-556800000 { - opp-hz = /bits/ 64 <556800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-614400000 { - opp-hz = /bits/ 64 <614400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-652800000 { - opp-hz = /bits/ 64 <652800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-691200000 { - opp-hz = /bits/ 64 <691200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-729600000 { - opp-hz = /bits/ 64 <729600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-748800000 { - opp-hz = /bits/ 64 <748800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-806400000 { - opp-hz = /bits/ 64 <806400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-825600000 { - opp-hz = /bits/ 64 <825600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-883200000 { - opp-hz = /bits/ 64 <883200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-902400000 { - opp-hz = /bits/ 64 <902400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-940800000 { - opp-hz = /bits/ 64 <940800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-979200000 { - opp-hz = /bits/ 64 <979200000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1036800000 { - opp-hz = /bits/ 64 <1036800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1056000000 { - opp-hz = /bits/ 64 <1056000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1113600000 { - opp-hz = /bits/ 64 <1113600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1132800000 { - opp-hz = /bits/ 64 <1132800000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1190400000 { - opp-hz = /bits/ 64 <1190400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1209600000 { - opp-hz = /bits/ 64 <1209600000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1248000000 { - opp-hz = /bits/ 64 <1248000000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1286400000 { - opp-hz = /bits/ 64 <1286400000>; - opp-microvolt = <905000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1324800000 { - opp-hz = /bits/ 64 <1324800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1363200000 { - opp-hz = /bits/ 64 <1363200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1440000000 { - opp-hz = /bits/ 64 <1440000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1478400000 { - opp-hz = /bits/ 64 <1478400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1516800000 { - opp-hz = /bits/ 64 <1516800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1555200000 { - opp-hz = /bits/ 64 <1555200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1593600000 { - opp-hz = /bits/ 64 <1593600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1632000000 { - opp-hz = /bits/ 64 <1632000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1670400000 { - opp-hz = /bits/ 64 <1670400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1708800000 { - opp-hz = /bits/ 64 <1708800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1747200000 { - opp-hz = /bits/ 64 <1747200000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x70>; - clock-latency-ns = <200000>; - }; - opp-1785600000 { - opp-hz = /bits/ 64 <1785600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x7>; - clock-latency-ns = <200000>; - }; - opp-1804800000 { - opp-hz = /bits/ 64 <1804800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x6>; - clock-latency-ns = <200000>; - }; - opp-1824000000 { - opp-hz = /bits/ 64 <1824000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x71>; - clock-latency-ns = <200000>; - }; - opp-1900800000 { - opp-hz = /bits/ 64 <1900800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x74>; - clock-latency-ns = <200000>; - }; - opp-1920000000 { - opp-hz = /bits/ 64 <1920000000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-1977600000 { - opp-hz = /bits/ 64 <1977600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-1996800000 { - opp-hz = /bits/ 64 <1996800000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2054400000 { - opp-hz = /bits/ 64 <2054400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x30>; - clock-latency-ns = <200000>; - }; - opp-2073600000 { - opp-hz = /bits/ 64 <2073600000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x1>; - clock-latency-ns = <200000>; - }; - opp-2150400000 { - opp-hz = /bits/ 64 <2150400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x31>; - clock-latency-ns = <200000>; - }; - opp-2246400000 { - opp-hz = /bits/ 64 <2246400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - opp-2342400000 { - opp-hz = /bits/ 64 <2342400000>; - opp-microvolt = <1140000 905000 1140000>; - opp-supported-hw = <0x10>; - clock-latency-ns = <200000>; - }; - }; - -.... - -reserved-memory { - #address-cells = <2>; - #size-cells = <2>; - ranges; -.... - smem_mem: smem-mem@86000000 { - reg = <0x0 0x86000000 0x0 0x200000>; - no-map; - }; -.... -}; - -smem { - compatible = "qcom,smem"; - memory-region = <&smem_mem>; - hwlocks = <&tcsr_mutex 3>; -}; - -soc { -.... - qfprom: qfprom@74000 { - compatible = "qcom,qfprom"; - reg = <0x00074000 0x8ff>; - #address-cells = <1>; - #size-cells = <1>; - .... - speedbin_efuse: speedbin@133 { - reg = <0x133 0x1>; - bits = <5 3>; - }; - }; -}; - -Example 2: ---------- - - cpus { - #address-cells = <1>; - #size-cells = <0>; - - CPU0: cpu@100 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x100>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU1: cpu@101 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x101>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU2: cpu@102 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x102>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - - CPU3: cpu@103 { - device_type = "cpu"; - compatible = "arm,cortex-a53"; - reg = <0x103>; - .... - clocks = <&apcs_glb>; - operating-points-v2 = <&cpu_opp_table>; - power-domains = <&cpr>; - power-domain-names = "cpr"; - }; - }; - - cpu_opp_table: cpu-opp-table { - compatible = "operating-points-v2-kryo-cpu"; - opp-shared; - - opp-1094400000 { - opp-hz = /bits/ 64 <1094400000>; - required-opps = <&cpr_opp1>; - }; - opp-1248000000 { - opp-hz = /bits/ 64 <1248000000>; - required-opps = <&cpr_opp2>; - }; - opp-1401600000 { - opp-hz = /bits/ 64 <1401600000>; - required-opps = <&cpr_opp3>; - }; - }; - - cpr_opp_table: cpr-opp-table { - compatible = "operating-points-v2-qcom-level"; - - cpr_opp1: opp1 { - opp-level = <1>; - qcom,opp-fuse-level = <1>; - }; - cpr_opp2: opp2 { - opp-level = <2>; - qcom,opp-fuse-level = <2>; - }; - cpr_opp3: opp3 { - opp-level = <3>; - qcom,opp-fuse-level = <3>; - }; - }; - -.... - -soc { -.... - cpr: power-controller@b018000 { - compatible = "qcom,qcs404-cpr", "qcom,cpr"; - reg = <0x0b018000 0x1000>; - .... - vdd-apc-supply = <&pms405_s3>; - #power-domain-cells = <0>; - operating-points-v2 = <&cpr_opp_table>; - .... - }; -}; diff --git a/Documentation/devicetree/bindings/opp/qcom-opp.txt b/Documentation/devicetree/bindings/opp/qcom-opp.txt deleted file mode 100644 index 41d3e4ff2dc3..000000000000 --- a/Documentation/devicetree/bindings/opp/qcom-opp.txt +++ /dev/null @@ -1,19 +0,0 @@ -Qualcomm OPP bindings to describe OPP nodes - -The bindings are based on top of the operating-points-v2 bindings -described in Documentation/devicetree/bindings/opp/opp-v2-base.yaml -Additional properties are described below. - -* OPP Table Node - -Required properties: -- compatible: Allow OPPs to express their compatibility. It should be: - "operating-points-v2-qcom-level" - -* OPP Node - -Required properties: -- qcom,opp-fuse-level: A positive value representing the fuse corner/level - associated with this OPP node. Sometimes several corners/levels shares - a certain fuse corner/level. A fuse corner/level contains e.g. ref uV, - min uV, and max uV. diff --git a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml index 643a6333b07b..252e5b72aee0 100644 --- a/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/fsl,imx6q-pcie.yaml @@ -25,6 +25,8 @@ properties: - fsl,imx6qp-pcie - fsl,imx7d-pcie - fsl,imx8mq-pcie + - fsl,imx8mm-pcie + - fsl,imx8mp-pcie reg: items: diff --git a/Documentation/devicetree/bindings/pci/mvebu-pci.txt b/Documentation/devicetree/bindings/pci/mvebu-pci.txt index 6173af6885f8..6d022a9d36ee 100644 --- a/Documentation/devicetree/bindings/pci/mvebu-pci.txt +++ b/Documentation/devicetree/bindings/pci/mvebu-pci.txt @@ -77,9 +77,15 @@ and the following optional properties: - marvell,pcie-lane: the physical PCIe lane number, for ports having multiple lanes. If this property is not found, we assume that the value is 0. +- num-lanes: number of SerDes PCIe lanes for this link (1 or 4) - reset-gpios: optional GPIO to PERST# - reset-delay-us: delay in us to wait after reset de-assertion, if not specified will default to 100ms, as required by the PCIe specification. +- interrupt-names: list of interrupt names, supported are: + - "intx" - interrupt line triggered by one of the legacy interrupt +- interrupts or interrupts-extended: List of the interrupt sources which + corresponding to the "interrupt-names". If non-empty then also additional + 'interrupt-controller' subnode must be defined. Example: @@ -141,6 +147,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 58>; marvell,pcie-port = <0>; marvell,pcie-lane = <0>; + num-lanes = <1>; /* low-active PERST# reset on GPIO 25 */ reset-gpios = <&gpio0 25 1>; /* wait 20ms for device settle after reset deassertion */ @@ -161,6 +168,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 59>; marvell,pcie-port = <0>; marvell,pcie-lane = <1>; + num-lanes = <1>; clocks = <&gateclk 6>; }; @@ -177,6 +185,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 60>; marvell,pcie-port = <0>; marvell,pcie-lane = <2>; + num-lanes = <1>; clocks = <&gateclk 7>; }; @@ -193,6 +202,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 61>; marvell,pcie-port = <0>; marvell,pcie-lane = <3>; + num-lanes = <1>; clocks = <&gateclk 8>; }; @@ -209,6 +219,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 62>; marvell,pcie-port = <1>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 9>; }; @@ -225,6 +236,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 63>; marvell,pcie-port = <1>; marvell,pcie-lane = <1>; + num-lanes = <1>; clocks = <&gateclk 10>; }; @@ -241,6 +253,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 64>; marvell,pcie-port = <1>; marvell,pcie-lane = <2>; + num-lanes = <1>; clocks = <&gateclk 11>; }; @@ -257,6 +270,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 65>; marvell,pcie-port = <1>; marvell,pcie-lane = <3>; + num-lanes = <1>; clocks = <&gateclk 12>; }; @@ -273,6 +287,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 99>; marvell,pcie-port = <2>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 26>; }; @@ -289,6 +304,7 @@ pcie-controller { interrupt-map = <0 0 0 0 &mpic 103>; marvell,pcie-port = <3>; marvell,pcie-lane = <0>; + num-lanes = <1>; clocks = <&gateclk 27>; }; }; diff --git a/Documentation/devicetree/bindings/pci/qcom,pcie.txt b/Documentation/devicetree/bindings/pci/qcom,pcie.txt index a0ae024c2d0c..0adb56d5645e 100644 --- a/Documentation/devicetree/bindings/pci/qcom,pcie.txt +++ b/Documentation/devicetree/bindings/pci/qcom,pcie.txt @@ -15,6 +15,8 @@ - "qcom,pcie-sc8180x" for sc8180x - "qcom,pcie-sdm845" for sdm845 - "qcom,pcie-sm8250" for sm8250 + - "qcom,pcie-sm8450-pcie0" for PCIe0 on sm8450 + - "qcom,pcie-sm8450-pcie1" for PCIe1 on sm8450 - "qcom,pcie-ipq6018" for ipq6018 - reg: @@ -169,6 +171,24 @@ - "ddrss_sf_tbu" PCIe SF TBU clock - "pipe" PIPE clock +- clock-names: + Usage: required for sm8450-pcie0 and sm8450-pcie1 + Value type: <stringlist> + Definition: Should contain the following entries + - "aux" Auxiliary clock + - "cfg" Configuration clock + - "bus_master" Master AXI clock + - "bus_slave" Slave AXI clock + - "slave_q2a" Slave Q2A clock + - "tbu" PCIe TBU clock + - "ddrss_sf_tbu" PCIe SF TBU clock + - "pipe" PIPE clock + - "pipe_mux" PIPE MUX + - "phy_pipe" PIPE output clock + - "ref" REFERENCE clock + - "aggre0" Aggre NoC PCIe0 AXI clock, only for sm8450-pcie0 + - "aggre1" Aggre NoC PCIe1 AXI clock + - resets: Usage: required Value type: <prop-encoded-array> @@ -246,7 +266,7 @@ - "ahb" AHB reset - reset-names: - Usage: required for sc8180x, sdm845 and sm8250 + Usage: required for sc8180x, sdm845, sm8250 and sm8450 Value type: <stringlist> Definition: Should contain the following entries - "pci" PCIe core reset diff --git a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml index 392f0ab488c2..195e6afeb169 100644 --- a/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml +++ b/Documentation/devicetree/bindings/pci/sifive,fu740-pcie.yaml @@ -104,7 +104,7 @@ examples: <0x0 0x0 0x0 0x2 &plic0 58>, <0x0 0x0 0x0 0x3 &plic0 59>, <0x0 0x0 0x0 0x4 &plic0 60>; - clocks = <&prci PRCI_CLK_PCIE_AUX>; + clocks = <&prci FU740_PRCI_CLK_PCIE_AUX>; resets = <&prci 4>; pwren-gpios = <&gpio 5 0>; reset-gpios = <&gpio 8 0>; diff --git a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml index 179ab0858482..437e61618d06 100644 --- a/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml +++ b/Documentation/devicetree/bindings/pci/socionext,uniphier-pcie-ep.yaml @@ -20,7 +20,9 @@ allOf: properties: compatible: - const: socionext,uniphier-pro5-pcie-ep + enum: + - socionext,uniphier-pro5-pcie-ep + - socionext,uniphier-nx1-pcie-ep reg: minItems: 4 @@ -41,20 +43,26 @@ properties: - const: atu clocks: + minItems: 1 maxItems: 2 clock-names: - items: - - const: gio - - const: link + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for NX1 resets: + minItems: 1 maxItems: 2 reset-names: - items: - - const: gio - - const: link + oneOf: + - items: # for Pro5 + - const: gio + - const: link + - const: link # for NX1 num-ib-windows: const: 16 diff --git a/Documentation/devicetree/bindings/peci/peci-aspeed.yaml b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml new file mode 100644 index 000000000000..1e68a801a92a --- /dev/null +++ b/Documentation/devicetree/bindings/peci/peci-aspeed.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/peci/peci-aspeed.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Aspeed PECI Bus Device Tree Bindings + +maintainers: + - Iwona Winiarska <iwona.winiarska@intel.com> + - Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> + +allOf: + - $ref: peci-controller.yaml# + +properties: + compatible: + enum: + - aspeed,ast2400-peci + - aspeed,ast2500-peci + - aspeed,ast2600-peci + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + description: + Clock source for PECI controller. Should reference the external + oscillator clock. + maxItems: 1 + + resets: + maxItems: 1 + + cmd-timeout-ms: + minimum: 1 + maximum: 1000 + default: 1000 + + clock-frequency: + description: + The desired operation frequency of PECI controller in Hz. + minimum: 2000 + maximum: 2000000 + default: 1000000 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/ast2600-clock.h> + peci-controller@1e78b000 { + compatible = "aspeed,ast2600-peci"; + reg = <0x1e78b000 0x100>; + interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&syscon ASPEED_CLK_GATE_REF0CLK>; + resets = <&syscon ASPEED_RESET_PECI>; + cmd-timeout-ms = <1000>; + clock-frequency = <1000000>; + }; +... diff --git a/Documentation/devicetree/bindings/peci/peci-controller.yaml b/Documentation/devicetree/bindings/peci/peci-controller.yaml new file mode 100644 index 000000000000..bbc3d3f3a929 --- /dev/null +++ b/Documentation/devicetree/bindings/peci/peci-controller.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/peci/peci-controller.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Generic Device Tree Bindings for PECI + +maintainers: + - Iwona Winiarska <iwona.winiarska@intel.com> + +description: + PECI (Platform Environment Control Interface) is an interface that provides a + communication channel from Intel processors and chipset components to external + monitoring or control devices. + +properties: + $nodename: + pattern: "^peci-controller(@.*)?$" + + cmd-timeout-ms: + description: + Command timeout in units of ms. + +additionalProperties: true + +examples: + - | + peci-controller@1e78b000 { + reg = <0x1e78b000 0x100>; + cmd-timeout-ms = <500>; + }; +... diff --git a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml index aef63a542f34..c87821be158b 100644 --- a/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml +++ b/Documentation/devicetree/bindings/perf/arm,dsu-pmu.yaml @@ -35,6 +35,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 12 + items: + maxItems: 1 description: List of phandles for the CPUs connected to this DSU instance. required: diff --git a/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml new file mode 100644 index 000000000000..a18dd0a8c43a --- /dev/null +++ b/Documentation/devicetree/bindings/perf/marvell-cn10k-ddr.yaml @@ -0,0 +1,37 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/perf/marvell-cn10k-ddr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Marvell CN10K DDR performance monitor + +maintainers: + - Bharat Bhushan <bbhushan2@marvell.com> + +properties: + compatible: + items: + - enum: + - marvell,cn10k-ddr-pmu + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + bus { + #address-cells = <2>; + #size-cells = <2>; + + pmu@87e1c0000000 { + compatible = "marvell,cn10k-ddr-pmu"; + reg = <0x87e1 0xc0000000 0x0 0x10000>; + }; + }; diff --git a/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt b/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt deleted file mode 100644 index 1bd15785b4ae..000000000000 --- a/Documentation/devicetree/bindings/perf/nds32v3-pmu.txt +++ /dev/null @@ -1,17 +0,0 @@ -* NDS32 Performance Monitor Units - -NDS32 core have a PMU for counting cpu and cache events like cache misses. -The NDS32 PMU representation in the device tree should be done as under: - -Required properties: - -- compatible : - "andestech,nds32v3-pmu" - -- interrupts : The interrupt number for NDS32 PMU is 13. - -Example: -pmu{ - compatible = "andestech,nds32v3-pmu"; - interrupts = <13>; -} diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml index 078af52b16ed..0fa4b32b097e 100644 --- a/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml +++ b/Documentation/devicetree/bindings/phy/allwinner,sun50i-a64-usb-phy.yaml @@ -15,7 +15,9 @@ properties: const: 1 compatible: - const: allwinner,sun50i-a64-usb-phy + enum: + - allwinner,sun20i-d1-usb-phy + - allwinner,sun50i-a64-usb-phy reg: items: diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml new file mode 100644 index 000000000000..07be031d82e6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/cdns,dphy-rx.yaml @@ -0,0 +1,42 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/cdns,dphy-rx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence DPHY Rx Device Tree Bindings + +maintainers: + - Pratyush Yadav <p.yadav@ti.com> + +properties: + compatible: + items: + - const: cdns,dphy-rx + + reg: + maxItems: 1 + + "#phy-cells": + const: 0 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + dphy0: phy@4580000 { + compatible = "cdns,dphy-rx"; + reg = <0x4580000 0x1100>; + #phy-cells = <0>; + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>; + }; diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.txt b/Documentation/devicetree/bindings/phy/cdns,dphy.txt deleted file mode 100644 index 1095bc4e72d9..000000000000 --- a/Documentation/devicetree/bindings/phy/cdns,dphy.txt +++ /dev/null @@ -1,20 +0,0 @@ -Cadence DPHY -============ - -Cadence DPHY block. - -Required properties: -- compatible: should be set to "cdns,dphy". -- reg: physical base address and length of the DPHY registers. -- clocks: DPHY reference clocks. -- clock-names: must contain "psm" and "pll_ref". -- #phy-cells: must be set to 0. - -Example: - dphy0: dphy@fd0e0000{ - compatible = "cdns,dphy"; - reg = <0x0 0xfd0e0000 0x0 0x1000>; - clocks = <&psm_clk>, <&pll_ref_clk>; - clock-names = "psm", "pll_ref"; - #phy-cells = <0>; - }; diff --git a/Documentation/devicetree/bindings/phy/cdns,dphy.yaml b/Documentation/devicetree/bindings/phy/cdns,dphy.yaml new file mode 100644 index 000000000000..c50629bd1b51 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/cdns,dphy.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/cdns,dphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence DPHY Device Tree Bindings + +maintainers: + - Pratyush Yadav <p.yadav@ti.com> + +properties: + compatible: + items: + - const: cdns,dphy + + reg: + maxItems: 1 + + clocks: + items: + - description: PMA state machine clock + - description: PLL reference clock + + clock-names: + items: + - const: psm + - const: pll_ref + + "#phy-cells": + const: 0 + + power-domains: + maxItems: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/soc/ti,sci_pm_domain.h> + + dphy0: phy@fd0e0000{ + compatible = "cdns,dphy"; + reg = <0xfd0e0000 0x1000>; + clocks = <&psm_clk>, <&pll_ref_clk>; + clock-names = "psm", "pll_ref"; + power-domains = <&k3_pds 147 TI_SCI_PD_EXCLUSIVE>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml new file mode 100644 index 000000000000..4d91e2f4f247 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/fsl,lynx-28g.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/fsl,lynx-28g.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale Lynx 28G SerDes PHY binding + +maintainers: + - Ioana Ciornei <ioana.ciornei@nxp.com> + +properties: + compatible: + enum: + - fsl,lynx-28g + + reg: + maxItems: 1 + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - "#phy-cells" + +additionalProperties: false + +examples: + - | + soc { + #address-cells = <2>; + #size-cells = <2>; + serdes_1: phy@1ea0000 { + compatible = "fsl,lynx-28g"; + reg = <0x0 0x1ea0000 0x0 0x1e30>; + #phy-cells = <1>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml index 347d0cdfb80d..5d54b0a0e873 100644 --- a/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml +++ b/Documentation/devicetree/bindings/phy/intel,combo-phy.yaml @@ -47,10 +47,18 @@ properties: intel,syscfg: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to Chip configuration registers + - description: ComboPhy instance id description: Chip configuration registers handle and ComboPhy instance id intel,hsio: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to HSIO registers + - description: ComboPhy instance id description: HSIO registers handle and ComboPhy instance id on NOC intel,aggregation: diff --git a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml index 05ee274b4b71..7b2e1bc119be 100644 --- a/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml +++ b/Documentation/devicetree/bindings/phy/mediatek,tphy.yaml @@ -80,6 +80,8 @@ properties: - mediatek,mt2712-tphy - mediatek,mt7629-tphy - mediatek,mt8183-tphy + - mediatek,mt8186-tphy + - mediatek,mt8192-tphy - const: mediatek,generic-tphy-v2 - items: - enum: diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml new file mode 100644 index 000000000000..f14454401419 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/phy-rockchip-naneng-combphy.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/phy-rockchip-naneng-combphy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Rockchip SoC Naneng Combo Phy Device Tree Bindings + +maintainers: + - Heiko Stuebner <heiko@sntech.de> + +properties: + compatible: + enum: + - rockchip,rk3568-naneng-combphy + + reg: + maxItems: 1 + + clocks: + items: + - description: reference clock + - description: apb clock + - description: pipe clock + + clock-names: + items: + - const: ref + - const: apb + - const: pipe + + resets: + items: + - description: exclusive PHY reset line + + rockchip,enable-ssc: + type: boolean + description: + The option SSC can be enabled for U3, SATA and PCIE. + Most commercially available platforms use SSC to reduce EMI. + + rockchip,ext-refclk: + type: boolean + description: + Many PCIe connections, especially backplane connections, + require a synchronous reference clock between the two link partners. + To achieve this a common clock source, referred to as REFCLK in + the PCI Express Card Electromechanical Specification, + should be used by both ends of the PCIe link. + In PCIe mode one can choose to use an internal or an external reference + clock. + By default the internal clock is selected. The PCIe PHY provides a 100MHz + differential clock output(optional with SSC) for system applications. + When selecting this option an externally 100MHz differential + reference clock needs to be provided to the PCIe PHY. + + rockchip,pipe-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional phy settings are accessed through GRF regs. + + rockchip,pipe-phy-grf: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Some additional pipe settings are accessed through GRF regs. + + "#phy-cells": + const: 1 + +required: + - compatible + - reg + - clocks + - clock-names + - resets + - rockchip,pipe-grf + - rockchip,pipe-phy-grf + - "#phy-cells" + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/rk3568-cru.h> + + pipegrf: syscon@fdc50000 { + compatible = "rockchip,rk3568-pipe-grf", "syscon"; + reg = <0xfdc50000 0x1000>; + }; + + pipe_phy_grf0: syscon@fdc70000 { + compatible = "rockchip,rk3568-pipe-phy-grf", "syscon"; + reg = <0xfdc70000 0x1000>; + }; + + combphy0: phy@fe820000 { + compatible = "rockchip,rk3568-naneng-combphy"; + reg = <0xfe820000 0x100>; + clocks = <&pmucru CLK_PCIEPHY0_REF>, + <&cru PCLK_PIPEPHY0>, + <&cru PCLK_PIPE>; + clock-names = "ref", "apb", "pipe"; + assigned-clocks = <&pmucru CLK_PCIEPHY0_REF>; + assigned-clock-rates = <100000000>; + resets = <&cru SRST_PIPEPHY0>; + rockchip,pipe-grf = <&pipegrf>; + rockchip,pipe-phy-grf = <&pipe_phy_grf0>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml index 267b695215b6..dc287d428e49 100644 --- a/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml +++ b/Documentation/devicetree/bindings/phy/phy-stm32-usbphyc.yaml @@ -76,8 +76,7 @@ patternProperties: connector: type: object - allOf: - - $ref: ../connector/usb-connector.yaml + $ref: /schemas/connector/usb-connector.yaml properties: vbus-supply: true diff --git a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml index 9076e19b6417..a5850ff529f8 100644 --- a/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,edp-phy.yaml @@ -16,7 +16,9 @@ description: properties: compatible: - const: qcom,sc8180x-edp-phy + enum: + - qcom,sc7280-edp-phy + - qcom,sc8180x-edp-phy reg: items: diff --git a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml index e417cd667997..e20d9b087bb8 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qmp-phy.yaml @@ -32,6 +32,7 @@ properties: - qcom,sc8180x-qmp-pcie-phy - qcom,sc8180x-qmp-ufs-phy - qcom,sc8180x-qmp-usb3-phy + - qcom,sc8280xp-qmp-ufs-phy - qcom,sdm845-qhp-pcie-phy - qcom,sdm845-qmp-pcie-phy - qcom,sdm845-qmp-ufs-phy @@ -280,6 +281,8 @@ allOf: - qcom,sdm845-qmp-ufs-phy - qcom,sm8150-qmp-ufs-phy - qcom,sm8250-qmp-ufs-phy + - qcom,sc8180x-qmp-ufs-phy + - qcom,sc8280xp-qmp-ufs-phy then: properties: clocks: diff --git a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml index e651a63a4be3..0ab3dad3f121 100644 --- a/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,qusb2-phy.yaml @@ -19,6 +19,7 @@ properties: - items: - enum: - qcom,ipq8074-qusb2-phy + - qcom,msm8953-qusb2-phy - qcom,msm8996-qusb2-phy - qcom,msm8998-qusb2-phy - qcom,qcm2290-qusb2-phy diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt deleted file mode 100644 index b3b75c1e6285..000000000000 --- a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.txt +++ /dev/null @@ -1,84 +0,0 @@ -Qualcomm's USB HS PHY - -PROPERTIES - -- compatible: - Usage: required - Value type: <string> - Definition: Should contain "qcom,usb-hs-phy" and more specifically one of the - following: - - "qcom,usb-hs-phy-apq8064" - "qcom,usb-hs-phy-msm8916" - "qcom,usb-hs-phy-msm8974" - -- #phy-cells: - Usage: required - Value type: <u32> - Definition: Should contain 0 - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: Should contain clock specifier for the reference and sleep - clocks - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: Should contain "ref" and "sleep" for the reference and sleep - clocks respectively - -- resets: - Usage: required - Value type: <prop-encoded-array> - Definition: Should contain the phy and POR resets - -- reset-names: - Usage: required - Value type: <stringlist> - Definition: Should contain "phy" and "por" for the phy and POR resets - respectively - -- v3p3-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 3.3V supply - -- v1p8-supply: - Usage: required - Value type: <phandle> - Definition: Should contain a reference to the 1.8V supply - -- extcon: - Usage: optional - Value type: <prop-encoded-array> - Definition: Should contain the vbus extcon - -- qcom,init-seq: - Usage: optional - Value type: <u8 array> - Definition: Should contain a sequence of ULPI address and value pairs to - program into the ULPI_EXT_VENDOR_SPECIFIC area. This is related - to Device Mode Eye Diagram test. The addresses are offsets - from the ULPI_EXT_VENDOR_SPECIFIC address, for example, - <0x1 0x53> would mean "write the value 0x53 to address 0x81". - -EXAMPLE - -otg: usb-controller { - ulpi { - phy { - compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy"; - #phy-cells = <0>; - clocks = <&xo_board>, <&gcc GCC_USB2A_PHY_SLEEP_CLK>; - clock-names = "ref", "sleep"; - resets = <&gcc GCC_USB2A_PHY_BCR>, <&otg 0>; - reset-names = "phy", "por"; - v3p3-supply = <&pm8941_l24>; - v1p8-supply = <&pm8941_l6>; - extcon = <&smbb>; - qcom,init-seq = /bits/ 8 <0x1 0x63>; - }; - }; -}; diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml new file mode 100644 index 000000000000..e23e5590eaa3 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/qcom,usb-hs-phy.yaml @@ -0,0 +1,109 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/qcom,usb-hs-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm's USB HS PHY binding description + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +if: + properties: + compatible: + contains: + const: qcom,usb-hs-phy-apq8064 + then: + properties: + resets: + maxItems: 1 + + reset-names: + const: por + + else: + properties: + resets: + minItems: 2 + maxItems: 2 + + reset-names: + items: + - const: phy + - const: por + +properties: + compatible: + items: + - enum: + - qcom,usb-hs-phy-apq8064 + - qcom,usb-hs-phy-msm8226 + - qcom,usb-hs-phy-msm8916 + - qcom,usb-hs-phy-msm8974 + - const: qcom,usb-hs-phy + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + maxItems: 2 + contains: + items: + - const: ref + - const: sleep + + resets: true + + reset-names: true + + v1p8-supply: true + + v3p3-supply: true + + extcon: true + + "#phy-cells": + const: 0 + + qcom,init-seq: + $ref: /schemas/types.yaml#/definitions/uint8-matrix + description: > + Sequence of ULPI address and value pairs to + program into the ULPI_EXT_VENDOR_SPECIFIC area. + This is related to Device Mode Eye Diagram test. + maxItems: 32 # no hard limit + items: + items: + - description: > + the address is offset from the ULPI_EXT_VENDOR_SPECIFIC address + - description: value + +required: + - clocks + - clock-names + - resets + - reset-names + - "#phy-cells" + +additionalProperties: false + +examples: + - | + otg: usb-controller { + ulpi { + phy { + compatible = "qcom,usb-hs-phy-msm8974", "qcom,usb-hs-phy"; + #phy-cells = <0>; + clocks = <&clk 0>, <&clk 258>; + clock-names = "ref", "sleep"; + resets = <&gcc 10>, <&otg 0>; + reset-names = "phy", "por"; + v3p3-supply = <&pm8941_l24>; + v1p8-supply = <&pm8941_l6>; + extcon = <&smbb>; + qcom,init-seq = /bits/ 8 <0x1 0x63>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml index 0dfe6914ec87..1ce251de0855 100644 --- a/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml +++ b/Documentation/devicetree/bindings/phy/qcom,usb-snps-femto-v2.yaml @@ -15,8 +15,11 @@ description: | properties: compatible: enum: + - qcom,usb-snps-hs-5nm-phy - qcom,usb-snps-hs-7nm-phy - qcom,sc7280-usb-hs-phy + - qcom,sc8180x-usb-hs-phy + - qcom,sc8280xp-usb-hs-phy - qcom,sm8150-usb-hs-phy - qcom,sm8250-usb-hs-phy - qcom,sm8350-usb-hs-phy diff --git a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml index 3a6e1165419c..16807bbbdcb1 100644 --- a/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml +++ b/Documentation/devicetree/bindings/phy/renesas,usb2-phy.yaml @@ -33,7 +33,8 @@ properties: - items: - enum: - renesas,usb2-phy-r9a07g044 # RZ/G2{L,LC} - - const: renesas,rzg2l-usb2-phy # RZ/G2L family + - renesas,usb2-phy-r9a07g054 # RZ/V2L + - const: renesas,rzg2l-usb2-phy reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml new file mode 100644 index 000000000000..838c6d480ce6 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,dp-video-phy.yaml @@ -0,0 +1,41 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,dp-video-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC DisplayPort PHY + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + enum: + - samsung,exynos5250-dp-video-phy + - samsung,exynos5420-dp-video-phy + + "#phy-cells": + const: 0 + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + +required: + - compatible + - "#phy-cells" + - samsung,pmu-syscon + +additionalProperties: false + +examples: + - | + phy { + compatible = "samsung,exynos5420-dp-video-phy"; + samsung,pmu-syscon = <&pmu_system_controller>; + #phy-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml new file mode 100644 index 000000000000..c61574e10b2a --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,exynos-hdmi-phy.yaml @@ -0,0 +1,44 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,exynos-hdmi-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC HDMI PHY + +maintainers: + - Inki Dae <inki.dae@samsung.com> + - Joonyoung Shim <jy0922.shim@samsung.com> + - Seung-Woo Kim <sw0312.kim@samsung.com> + - Kyungmin Park <kyungmin.park@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + oneOf: + - enum: + - samsung,exynos4210-hdmiphy + - samsung,exynos4212-hdmiphy + - const: samsung,exynos5-hdmiphy + deprecated: true + + reg: + maxItems: 1 + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + i2c { + #address-cells = <1>; + #size-cells = <0>; + + hdmi-phy@38 { + compatible = "samsung,exynos4210-hdmiphy"; + reg = <0x38>; + }; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml new file mode 100644 index 000000000000..62b39bb46585 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,exynos5250-sata-phy.yaml @@ -0,0 +1,64 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,exynos5250-sata-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5250 SoC SATA PHY + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + const: samsung,exynos5250-sata-phy + + clocks: + maxItems: 1 + + clock-names: + items: + - const: sata_phyctrl + + "#phy-cells": + const: 0 + + reg: + maxItems: 1 + + samsung,syscon-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + samsung,exynos-sataphy-i2c-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to I2C SATA interface. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,syscon-phandle + - samsung,exynos-sataphy-i2c-phandle + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5250.h> + + phy@12170000 { + compatible = "samsung,exynos5250-sata-phy"; + reg = <0x12170000 0x1ff>; + clocks = <&clock CLK_SATA_PHYCTRL>; + clock-names = "sata_phyctrl"; + #phy-cells = <0>; + samsung,syscon-phandle = <&pmu_system_controller>; + samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml new file mode 100644 index 000000000000..54aa056b224d --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,mipi-video-phy.yaml @@ -0,0 +1,113 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,mipi-video-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC MIPI CSIS/DSIM DPHY + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: | + For samsung,s5pv210-mipi-video-phy compatible PHYs the second cell in the + PHY specifier identifies the PHY and its meaning is as follows:: + 0 - MIPI CSIS 0, + 1 - MIPI DSIM 0, + 2 - MIPI CSIS 1, + 3 - MIPI DSIM 1. + + samsung,exynos5420-mipi-video-phy and samsung,exynos5433-mipi-video-phy + support additional fifth PHY:: + 4 - MIPI CSIS 2. + +properties: + compatible: + enum: + - samsung,s5pv210-mipi-video-phy + - samsung,exynos5420-mipi-video-phy + - samsung,exynos5433-mipi-video-phy + + "#phy-cells": + const: 1 + + syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface, valid only for + samsung,s5pv210-mipi-video-phy and samsung,exynos5420-mipi-video-phy. + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,disp-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to DISP system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,cam0-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to CAM0 system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + + samsung,cam1-sysreg: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to CAM1 system controller interface, valid for + samsung,exynos5433-mipi-video-phy. + +required: + - compatible + - "#phy-cells" + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-mipi-video-phy + - samsung,exynos5420-mipi-video-phy + then: + properties: + samsung,pmu-syscon: false + samsung,disp-sysreg: false + samsung,cam0-sysreg: false + samsung,cam1-sysreg: false + required: + - syscon + else: + properties: + syscon: false + required: + - samsung,pmu-syscon + - samsung,disp-sysreg + - samsung,cam0-sysreg + - samsung,cam1-sysreg + +additionalProperties: false + +examples: + - | + phy { + compatible = "samsung,exynos5433-mipi-video-phy"; + #phy-cells = <1>; + samsung,pmu-syscon = <&pmu_system_controller>; + samsung,cam0-sysreg = <&syscon_cam0>; + samsung,cam1-sysreg = <&syscon_cam1>; + samsung,disp-sysreg = <&syscon_disp>; + }; + + - | + phy { + compatible = "samsung,s5pv210-mipi-video-phy"; + syscon = <&pmu_system_controller>; + #phy-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml new file mode 100644 index 000000000000..056e270a4e88 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,usb2-phy.yaml @@ -0,0 +1,102 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,usb2-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S5P/Exynos SoC USB 2.0 PHY + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: | + The first phandle argument in the PHY specifier identifies the PHY, its + meaning is compatible dependent. For the currently supported SoCs (Exynos4210 + and Exynos4212) it is as follows:: + 0 - USB device ("device"), + 1 - USB host ("host"), + 2 - HSIC0 ("hsic0"), + 3 - HSIC1 ("hsic1"), + Exynos3250 has only USB device phy available as phy 0. + + Exynos4210 and Exynos4212 use mode switching and require that mode switch + register is supplied. + +properties: + compatible: + enum: + - samsung,exynos3250-usb2-phy + - samsung,exynos4210-usb2-phy + - samsung,exynos4x12-usb2-phy + - samsung,exynos5250-usb2-phy + - samsung,exynos5420-usb2-phy + - samsung,s5pv210-usb2-phy + + clocks: + items: + - description: PHY module gate clock. + - description: Reference rate clock of PHY module. + + clock-names: + items: + - const: phy + - const: ref + + "#phy-cells": + const: 1 + + reg: + maxItems: 1 + + samsung,pmureg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + samsung,sysreg-phandle: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to system registers interface. + + vbus-supply: + description: + VBUS power source. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,pmureg-phandle + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos4x12-usb2-phy + - samsung,exynos5250-usb2-phy + - samsung,exynos5420-usb2-phy + then: + required: + - samsung,sysreg-phandle + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + + phy@12130000 { + compatible = "samsung,exynos5420-usb2-phy"; + reg = <0x12130000 0x100>; + #phy-cells = <1>; + clocks = <&clock CLK_USBH20>, <&clock CLK_SCLK_USBPHY300>; + clock-names = "phy", "ref"; + samsung,sysreg-phandle = <&sysreg_system_controller>; + samsung,pmureg-phandle = <&pmu_system_controller>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml new file mode 100644 index 000000000000..f83f0f8135b9 --- /dev/null +++ b/Documentation/devicetree/bindings/phy/samsung,usb3-drd-phy.yaml @@ -0,0 +1,126 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/samsung,usb3-drd-phy.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 3.0 DRD PHY USB 2.0 PHY + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Marek Szyprowski <m.szyprowski@samsung.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +description: | + For samsung,exynos5250-usbdrd-phy and samsung,exynos5420-usbdrd-phy + compatible PHYs, the second cell in the PHY specifier identifies the + PHY id, which is interpreted as follows:: + 0 - UTMI+ type phy, + 1 - PIPE3 type phy. + + For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, + 'usbdrd_phy' nodes should have numbered alias in the aliases node, in the + form of usbdrdphyN, N = 0, 1... (depending on number of controllers). + +properties: + compatible: + enum: + - samsung,exynos5250-usbdrd-phy + - samsung,exynos5420-usbdrd-phy + - samsung,exynos5433-usbdrd-phy + - samsung,exynos7-usbdrd-phy + + clocks: + minItems: 2 + maxItems: 5 + + clock-names: + minItems: 2 + maxItems: 5 + description: | + At least two clocks:: + - Main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), used + for register access. + - PHY reference clock (usually crystal clock), used for PHY operations, + associated by phy name. It is used to determine bit values for clock + settings register. For Exynos5420 this is given as 'sclk_usbphy30' + in the CMU. + + "#phy-cells": + const: 1 + + port: + $ref: /schemas/graph.yaml#/properties/port + description: + Any connector to the data bus of this controller should be modelled using + the OF graph bindings specified. + + reg: + maxItems: 1 + + samsung,pmu-syscon: + $ref: /schemas/types.yaml#/definitions/phandle + description: + Phandle to PMU system controller interface. + + vbus-supply: + description: + VBUS power source. + + vbus-boost-supply: + description: + VBUS Boost 5V power source. + +required: + - compatible + - clocks + - clock-names + - "#phy-cells" + - reg + - samsung,pmu-syscon + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-usbdrd-phy + - samsung,exynos7-usbdrd-phy + then: + properties: + clocks: + minItems: 5 + maxItems: 5 + clock-names: + items: + - const: phy + - const: ref + - const: phy_utmi + - const: phy_pipe + - const: itp + else: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: phy + - const: ref + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + + phy@12100000 { + compatible = "samsung,exynos5420-usbdrd-phy"; + reg = <0x12100000 0x100>; + #phy-cells = <1>; + clocks = <&clock CLK_USBD300>, <&clock CLK_SCLK_USBPHY300>; + clock-names = "phy", "ref"; + samsung,pmu-syscon = <&pmu_system_controller>; + vbus-supply = <&usb300_vbus_reg>; + }; diff --git a/Documentation/devicetree/bindings/phy/samsung-phy.txt b/Documentation/devicetree/bindings/phy/samsung-phy.txt deleted file mode 100644 index 8f51aee91101..000000000000 --- a/Documentation/devicetree/bindings/phy/samsung-phy.txt +++ /dev/null @@ -1,210 +0,0 @@ -Samsung S5P/Exynos SoC series MIPI CSIS/DSIM DPHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the listed compatibles: - - "samsung,s5pv210-mipi-video-phy" - - "samsung,exynos5420-mipi-video-phy" - - "samsung,exynos5433-mipi-video-phy" -- #phy-cells : from the generic phy bindings, must be 1; - -In case of s5pv210 and exynos5420 compatible PHYs: -- syscon - phandle to the PMU system controller - -In case of exynos5433 compatible PHY: - - samsung,pmu-syscon - phandle to the PMU system controller - - samsung,disp-sysreg - phandle to the DISP system registers controller - - samsung,cam0-sysreg - phandle to the CAM0 system registers controller - - samsung,cam1-sysreg - phandle to the CAM1 system registers controller - -For "samsung,s5pv210-mipi-video-phy" compatible PHYs the second cell in -the PHY specifier identifies the PHY and its meaning is as follows: - 0 - MIPI CSIS 0, - 1 - MIPI DSIM 0, - 2 - MIPI CSIS 1, - 3 - MIPI DSIM 1. -"samsung,exynos5420-mipi-video-phy" and "samsung,exynos5433-mipi-video-phy" -supports additional fifth PHY: - 4 - MIPI CSIS 2. - -Samsung Exynos SoC series Display Port PHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the following supported values: - - "samsung,exynos5250-dp-video-phy" - - "samsung,exynos5420-dp-video-phy" -- samsung,pmu-syscon: phandle for PMU system controller interface, used to - control pmu registers for power isolation. -- #phy-cells : from the generic PHY bindings, must be 0; - -Samsung S5P/Exynos SoC series USB PHY -------------------------------------------------- - -Required properties: -- compatible : should be one of the listed compatibles: - - "samsung,exynos3250-usb2-phy" - - "samsung,exynos4210-usb2-phy" - - "samsung,exynos4x12-usb2-phy" - - "samsung,exynos5250-usb2-phy" - - "samsung,exynos5420-usb2-phy" - - "samsung,s5pv210-usb2-phy" -- reg : a list of registers used by phy driver - - first and obligatory is the location of phy modules registers -- samsung,sysreg-phandle - handle to syscon used to control the system registers -- samsung,pmureg-phandle - handle to syscon used to control PMU registers -- #phy-cells : from the generic phy bindings, must be 1; -- clocks and clock-names: - - the "phy" clock is required by the phy module, used as a gate - - the "ref" clock is used to get the rate of the clock provided to the - PHY module - -Optional properties: -- vbus-supply: power-supply phandle for vbus power source - -The first phandle argument in the PHY specifier identifies the PHY, its -meaning is compatible dependent. For the currently supported SoCs (Exynos 4210 -and Exynos 4212) it is as follows: - 0 - USB device ("device"), - 1 - USB host ("host"), - 2 - HSIC0 ("hsic0"), - 3 - HSIC1 ("hsic1"), -Exynos3250 has only USB device phy available as phy 0. - -Exynos 4210 and Exynos 4212 use mode switching and require that mode switch -register is supplied. - -Example: - -For Exynos 4412 (compatible with Exynos 4212): - -usbphy: phy@125b0000 { - compatible = "samsung,exynos4x12-usb2-phy"; - reg = <0x125b0000 0x100>; - clocks = <&clock 305>, <&clock 2>; - clock-names = "phy", "ref"; - #phy-cells = <1>; - samsung,sysreg-phandle = <&sys_reg>; - samsung,pmureg-phandle = <&pmu_reg>; -}; - -Then the PHY can be used in other nodes such as: - -phy-consumer@12340000 { - phys = <&usbphy 2>; - phy-names = "phy"; -}; - -Refer to DT bindings documentation of particular PHY consumer devices for more -information about required PHYs and the way of specification. - -Samsung SATA PHY Controller ---------------------------- - -SATA PHY nodes are defined to describe on-chip SATA Physical layer controllers. -Each SATA PHY controller should have its own node. - -Required properties: -- compatible : compatible list, contains "samsung,exynos5250-sata-phy" -- reg : offset and length of the SATA PHY register set; -- #phy-cells : must be zero -- clocks : must be exactly one entry -- clock-names : must be "sata_phyctrl" -- samsung,exynos-sataphy-i2c-phandle : a phandle to the I2C device, no arguments -- samsung,syscon-phandle : a phandle to the PMU system controller, no arguments - -Example: - sata_phy: sata-phy@12170000 { - compatible = "samsung,exynos5250-sata-phy"; - reg = <0x12170000 0x1ff>; - clocks = <&clock 287>; - clock-names = "sata_phyctrl"; - #phy-cells = <0>; - samsung,exynos-sataphy-i2c-phandle = <&sata_phy_i2c>; - samsung,syscon-phandle = <&pmu_syscon>; - }; - -Device-Tree bindings for sataphy i2c client driver --------------------------------------------------- - -Required properties: -compatible: Should be "samsung,exynos-sataphy-i2c" -- reg: I2C address of the sataphy i2c device. - -Example: - - sata_phy_i2c:sata-phy@38 { - compatible = "samsung,exynos-sataphy-i2c"; - reg = <0x38>; - }; - -Samsung Exynos5 SoC series USB DRD PHY controller --------------------------------------------------- - -Required properties: -- compatible : Should be set to one of the following supported values: - - "samsung,exynos5250-usbdrd-phy" - for exynos5250 SoC, - - "samsung,exynos5420-usbdrd-phy" - for exynos5420 SoC. - - "samsung,exynos5433-usbdrd-phy" - for exynos5433 SoC. - - "samsung,exynos7-usbdrd-phy" - for exynos7 SoC. -- reg : Register offset and length of USB DRD PHY register set; -- clocks: Clock IDs array as required by the controller -- clock-names: names of clocks correseponding to IDs in the clock property; - Required clocks: - - phy: main PHY clock (same as USB DRD controller i.e. DWC3 IP clock), - used for register access. - - ref: PHY's reference clock (usually crystal clock), used for - PHY operations, associated by phy name. It is used to - determine bit values for clock settings register. - For Exynos5420 this is given as 'sclk_usbphy30' in CMU. - - optional clocks: Exynos5433 & Exynos7 SoC has now following additional - gate clocks available: - - phy_pipe: for PIPE3 phy - - phy_utmi: for UTMI+ phy - - itp: for ITP generation -- samsung,pmu-syscon: phandle for PMU system controller interface, used to - control pmu registers for power isolation. -- #phy-cells : from the generic PHY bindings, must be 1; - -For "samsung,exynos5250-usbdrd-phy" and "samsung,exynos5420-usbdrd-phy" -compatible PHYs, the second cell in the PHY specifier identifies the -PHY id, which is interpreted as follows: - 0 - UTMI+ type phy, - 1 - PIPE3 type phy, - -Example: - usbdrd_phy: usbphy@12100000 { - compatible = "samsung,exynos5250-usbdrd-phy"; - reg = <0x12100000 0x100>; - clocks = <&clock 286>, <&clock 1>; - clock-names = "phy", "ref"; - samsung,pmu-syscon = <&pmu_system_controller>; - #phy-cells = <1>; - }; - -- aliases: For SoCs like Exynos5420 having multiple USB 3.0 DRD PHY controllers, - 'usbdrd_phy' nodes should have numbered alias in the aliases node, - in the form of usbdrdphyN, N = 0, 1... (depending on number of - controllers). -Example: - aliases { - usbdrdphy0 = &usb3_phy0; - usbdrdphy1 = &usb3_phy1; - }; - -Samsung Exynos SoC series PCIe PHY controller --------------------------------------------------- -Required properties: -- compatible : Should be set to "samsung,exynos5440-pcie-phy" -- #phy-cells : Must be zero -- reg : a register used by phy driver. - - First is for phy register, second is for block register. -- reg-names : Must be set to "phy" and "block". - -Example: - pcie_phy0: pcie-phy@270000 { - #phy-cells = <0>; - compatible = "samsung,exynos5440-pcie-phy"; - reg = <0x270000 0x1000>, <0x271000 0x40>; - reg-names = "phy", "block"; - }; diff --git a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml index cbbf5e8b1197..8694b9eb52f9 100644 --- a/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml +++ b/Documentation/devicetree/bindings/phy/ti,omap-usb2.yaml @@ -8,7 +8,7 @@ title: OMAP USB2 PHY maintainers: - Kishon Vijay Abraham I <kishon@ti.com> - - Roger Quadros <rogerq@ti.com> + - Roger Quadros <rogerq@kernel.org> properties: compatible: @@ -45,6 +45,10 @@ properties: syscon-phy-power: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to the system control module + - description: register offset to power on/off the PHY description: phandle/offset pair. Phandle to the system control module and register offset to power on/off the PHY. diff --git a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml index 6107880e5246..02b76f15e717 100644 --- a/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml +++ b/Documentation/devicetree/bindings/phy/ti,tcan104x-can.yaml @@ -37,6 +37,12 @@ properties: max bit rate supported in bps minimum: 1 + mux-states: + description: + mux controller node to route the signals from controller to + transceiver. + maxItems: 1 + required: - compatible - '#phy-cells' @@ -53,4 +59,5 @@ examples: max-bitrate = <5000000>; standby-gpios = <&wakeup_gpio1 16 GPIO_ACTIVE_LOW>; enable-gpios = <&main_gpio1 67 GPIO_ACTIVE_HIGH>; + mux-states = <&mux0 1>; }; diff --git a/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml new file mode 100644 index 000000000000..51492fe738ec --- /dev/null +++ b/Documentation/devicetree/bindings/phy/transmit-amplitude.yaml @@ -0,0 +1,103 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/phy/transmit-amplitude.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common PHY and network PCS transmit amplitude property binding + +description: + Binding describing the peak-to-peak transmit amplitude for common PHYs + and network PCSes. + +maintainers: + - Marek Behún <kabel@kernel.org> + +properties: + tx-p2p-microvolt: + description: + Transmit amplitude voltages in microvolts, peak-to-peak. If this property + contains multiple values for various PHY modes, the + 'tx-p2p-microvolt-names' property must be provided and contain + corresponding mode names. + + tx-p2p-microvolt-names: + description: | + Names of the modes corresponding to voltages in the 'tx-p2p-microvolt' + property. Required only if multiple voltages are provided. + + If a value of 'default' is provided, the system should use it for any PHY + mode that is otherwise not defined here. If 'default' is not provided, the + system should use manufacturer default value. + minItems: 1 + maxItems: 16 + items: + enum: + - default + + # ethernet modes + - sgmii + - qsgmii + - xgmii + - 1000base-x + - 2500base-x + - 5gbase-r + - rxaui + - xaui + - 10gbase-kr + - usxgmii + - 10gbase-r + - 25gbase-r + + # PCIe modes + - pcie + - pcie1 + - pcie2 + - pcie3 + - pcie4 + - pcie5 + - pcie6 + + # USB modes + - usb + - usb-ls + - usb-fs + - usb-hs + - usb-ss + - usb-ss+ + - usb-4 + + # storage modes + - sata + - ufs-hs + - ufs-hs-a + - ufs-hs-b + + # display modes + - lvds + - dp + - dp-rbr + - dp-hbr + - dp-hbr2 + - dp-hbr3 + - dp-uhbr-10 + - dp-uhbr-13.5 + - dp-uhbr-20 + + # camera modes + - mipi-dphy + - mipi-dphy-univ + - mipi-dphy-v2.5-univ + +dependencies: + tx-p2p-microvolt-names: [ tx-p2p-microvolt ] + +additionalProperties: true + +examples: + - | + phy: phy { + #phy-cells = <1>; + tx-p2p-microvolt = <915000>, <1100000>, <1200000>; + tx-p2p-microvolt-names = "2500base-x", "usb-hs", "usb-ss"; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml index d316cc082107..7c25c8d51116 100644 --- a/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/aspeed,ast2500-pinctrl.yaml @@ -29,6 +29,8 @@ properties: aspeed,external-nodes: minItems: 2 maxItems: 2 + items: + maxItems: 1 $ref: /schemas/types.yaml#/definitions/phandle-array description: | A cell of phandles to external controller nodes: @@ -73,6 +75,7 @@ additionalProperties: false examples: - | + #include <dt-bindings/clock/aspeed-clock.h> apb { compatible = "simple-bus"; #address-cells = <1>; @@ -82,6 +85,8 @@ examples: syscon: scu@1e6e2000 { compatible = "aspeed,ast2500-scu", "syscon", "simple-mfd"; reg = <0x1e6e2000 0x1a8>; + #clock-cells = <1>; + #reset-cells = <1>; pinctrl: pinctrl { compatible = "aspeed,ast2500-pinctrl"; @@ -102,6 +107,12 @@ examples: gfx: display@1e6e6000 { compatible = "aspeed,ast2500-gfx", "syscon"; reg = <0x1e6e6000 0x1000>; + reg-io-width = <4>; + clocks = <&syscon ASPEED_CLK_GATE_D1CLK>; + resets = <&syscon ASPEED_RESET_CRT1>; + interrupts = <0x19>; + syscon = <&syscon>; + memory-region = <&gfx_memory>; }; }; @@ -128,3 +139,10 @@ examples: }; }; }; + + gfx_memory: framebuffer { + size = <0x01000000>; + alignment = <0x01000000>; + compatible = "shared-dma-pool"; + reusable; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt index 4eaae32821ae..e047a198db38 100644 --- a/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm11351-pinctrl.txt @@ -85,7 +85,7 @@ Optional Properties (for I2C pins): - function: String. Specifies the pin mux selection. Values must be one of: "alt1", "alt2", "alt3", "alt4" - bias-pull-up: Integer. Pull up strength in Ohm. There are 3 - pull-up resisitors (1.2k, 1.8k, 2.7k) available + pull-up resistors (1.2k, 1.8k, 2.7k) available in parallel for I2C pins, so the valid values are: 568, 720, 831, 1080, 1200, 1800, 2700 Ohm. - bias-disable: No arguments. Disable pin bias. diff --git a/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml new file mode 100644 index 000000000000..175a992f15e1 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/brcm,bcm4908-pinctrl.yaml @@ -0,0 +1,72 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/brcm,bcm4908-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Broadcom BCM4908 pin controller + +maintainers: + - RafaÅ‚ MiÅ‚ecki <rafal@milecki.pl> + +description: + Binding for pin controller present on BCM4908 family SoCs. + +properties: + compatible: + const: brcm,bcm4908-pinctrl + + reg: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + $ref: pinmux-node.yaml# + + properties: + function: + enum: [ led_0, led_1, led_2, led_3, led_4, led_5, led_6, led_7, led_8, + led_9, led_10, led_11, led_12, led_13, led_14, led_15, led_16, + led_17, led_18, led_19, led_20, led_21, led_22, led_23, led_24, + led_25, led_26, led_27, led_28, led_29, led_30, led_31, + hs_uart, i2c, i2s, nand_ctrl, nand_data, emmc_ctrl, usb0_pwr, + usb1_pwr ] + + groups: + minItems: 1 + maxItems: 2 + items: + enum: [ led_0_grp_a, led_1_grp_a, led_2_grp_a, led_3_grp_a, + led_4_grp_a, led_5_grp_a, led_6_grp_a, led_7_grp_a, + led_8_grp_a, led_9_grp_a, led_10_grp_a, led_10_grp_b, + led_11_grp_a, led_11_grp_b, led_12_grp_a, led_12_grp_b, + led_13_grp_a, led_13_grp_b, led_14_grp_a, led_15_grp_a, + led_16_grp_a, led_17_grp_a, led_18_grp_a, led_19_grp_a, + led_20_grp_a, led_21_grp_a, led_22_grp_a, led_23_grp_a, + led_24_grp_a, led_25_grp_a, led_26_grp_a, led_27_grp_a, + led_28_grp_a, led_29_grp_a, led_30_grp_a, led_31_grp_a, + led_31_grp_b, hs_uart_grp, i2c_grp_a, i2c_grp_b, i2s_grp, + nand_ctrl_grp, nand_data_grp, emmc_ctrl_grp, usb0_pwr_grp, + usb1_pwr_grp ] + +allOf: + - $ref: pinctrl.yaml# + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + pinctrl@ff800560 { + compatible = "brcm,bcm4908-pinctrl"; + reg = <0xff800560 0x10>; + + led_0-a-pins { + function = "led_0"; + groups = "led_0_grp_a"; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml index a44691d9c57d..53e963e090f2 100644 --- a/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml +++ b/Documentation/devicetree/bindings/pinctrl/canaan,k210-fpioa.yaml @@ -39,6 +39,10 @@ properties: canaan,k210-sysctl-power: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle of the K210 system controller node + - description: offset of its power domain control register description: | phandle of the K210 system controller node and offset of its power domain control register. diff --git a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml index c85f759ae5a3..8a90d8273767 100644 --- a/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml +++ b/Documentation/devicetree/bindings/pinctrl/cirrus,madera.yaml @@ -107,9 +107,6 @@ properties: additionalProperties: false -allOf: - - $ref: "pinctrl.yaml#" - required: - pinctrl-0 - pinctrl-names diff --git a/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml new file mode 100644 index 000000000000..66baa6082a4f --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/fsl,imx93-pinctrl.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/fsl,imx93-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Freescale IMX93 IOMUX Controller + +maintainers: + - Peng Fan <peng.fan@nxp.com> + +description: + Please refer to fsl,imx-pinctrl.txt and pinctrl-bindings.txt in this directory + for common binding part and usage. + +allOf: + - $ref: "pinctrl.yaml#" + +properties: + compatible: + const: fsl,imx93-iomuxc + + reg: + maxItems: 1 + +# Client device subnode's properties +patternProperties: + 'grp$': + type: object + description: + Pinctrl node's client devices use subnodes for desired pin configuration. + Client device subnodes use below standard properties. + + properties: + fsl,pins: + description: + each entry consists of 6 integers and represents the mux and config + setting for one pin. The first 5 integers <mux_reg conf_reg input_reg + mux_val input_val> are specified using a PIN_FUNC_ID macro, which can + be found in <arch/arm64/boot/dts/freescale/imx8mp-pinfunc.h>. The last + integer CONFIG is the pad setting value like pull-up on this pin. Please + refer to i.MX8M Plus Reference Manual for detailed CONFIG settings. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: | + "mux_reg" indicates the offset of mux register. + - description: | + "conf_reg" indicates the offset of pad configuration register. + - description: | + "input_reg" indicates the offset of select input register. + - description: | + "mux_val" indicates the mux value to be applied. + - description: | + "input_val" indicates the select input value to be applied. + - description: | + "pad_setting" indicates the pad configuration value to be applied. + + + required: + - fsl,pins + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + # Pinmux controller node + - | + iomuxc: pinctrl@443c0000 { + compatible = "fsl,imx93-iomuxc"; + reg = <0x30330000 0x10000>; + + pinctrl_uart3: uart3grp { + fsl,pins = + <0x48 0x1f8 0x41c 0x1 0x0 0x49>, + <0x4c 0x1fc 0x418 0x1 0x0 0x49>; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml index 6953c958ff7c..161088a8be33 100644 --- a/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/mediatek,mt65xx-pinctrl.yaml @@ -44,6 +44,8 @@ properties: mediatek,pctl-regmap: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 minItems: 1 maxItems: 2 description: | diff --git a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt index 0aff1f28495c..8146193bd8ac 100644 --- a/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/meson,pinctrl.txt @@ -16,6 +16,7 @@ Required properties for the root node: "amlogic,meson-g12a-periphs-pinctrl" "amlogic,meson-g12a-aobus-pinctrl" "amlogic,meson-a1-periphs-pinctrl" + "amlogic,meson-s4-periphs-pinctrl" - reg: address and size of registers controlling irq functionality === GPIO sub-nodes === diff --git a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml index cb554084bdf1..0df4e114fdd6 100644 --- a/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/microchip,sparx5-sgpio.yaml @@ -145,7 +145,7 @@ examples: clocks = <&sys_clk>; pinctrl-0 = <&sgpio2_pins>; pinctrl-names = "default"; - reg = <0x1101059c 0x100>; + reg = <0x1101059c 0x118>; microchip,sgpio-port-ranges = <0 0>, <16 18>, <28 31>; bus-frequency = <25000000>; sgpio_in2: gpio@0 { diff --git a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt index 3bb76487669f..5d84fd299ccf 100644 --- a/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt +++ b/Documentation/devicetree/bindings/pinctrl/mscc,ocelot-pinctrl.txt @@ -4,8 +4,8 @@ Microsemi Ocelot pin controller Device Tree Bindings Required properties: - compatible : Should be "mscc,ocelot-pinctrl", "mscc,jaguar2-pinctrl", "microchip,sparx5-pinctrl", - "mscc,luton-pinctrl", "mscc,serval-pinctrl" or - "microchip,lan966x-pinctrl" + "mscc,luton-pinctrl", "mscc,serval-pinctrl", + "microchip,lan966x-pinctrl" or "mscc,servalt-pinctrl" - reg : Address and length of the register set for the device - gpio-controller : Indicates this device is a GPIO controller - #gpio-cells : Must be 2. diff --git a/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml new file mode 100644 index 000000000000..47a56b83a610 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/nuvoton,wpcm450-pinctrl.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/nuvoton,wpcm450-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton WPCM450 pin control and GPIO + +maintainers: + - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + +properties: + compatible: + const: nuvoton,wpcm450-pinctrl + + reg: + maxItems: 1 + + '#address-cells': + const: 1 + + '#size-cells': + const: 0 + +patternProperties: + # There are three kinds of subnodes: + # 1. a GPIO controller node for each GPIO bank + # 2. a pinmux node configures pin muxing for a group of pins (e.g. rmii2) + # 3. a pinconf node configures properties of a single pin + + "^gpio@[0-7]$": + type: object + + description: + Eight GPIO banks (gpio@0 to gpio@7), that each contain between 14 and 18 + GPIOs. Some GPIOs support interrupts. + + properties: + reg: + minimum: 0 + maximum: 7 + + gpio-controller: true + + "#gpio-cells": + const: 2 + + interrupt-controller: true + + "#interrupt-cells": + const: 2 + + interrupts: + maxItems: 3 + description: + The interrupts associated with this GPIO bank + + required: + - reg + - gpio-controller + - '#gpio-cells' + + "^mux-": + $ref: pinmux-node.yaml# + + properties: + groups: + description: + One or more groups of pins to mux to a certain function + items: + enum: [ smb3, smb4, smb5, scs1, scs2, scs3, smb0, smb1, smb2, bsp, + hsp1, hsp2, r1err, r1md, rmii2, r2err, r2md, kbcc, dvo, + clko, smi, uinc, gspi, mben, xcs2, xcs1, sdio, sspi, fi0, + fi1, fi2, fi3, fi4, fi5, fi6, fi7, fi8, fi9, fi10, fi11, + fi12, fi13, fi14, fi15, pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, + pwm6, pwm7, hg0, hg1, hg2, hg3, hg4, hg5, hg6, hg7 ] + function: + description: + The function that a group of pins is muxed to + enum: [ smb3, smb4, smb5, scs1, scs2, scs3, smb0, smb1, smb2, bsp, + hsp1, hsp2, r1err, r1md, rmii2, r2err, r2md, kbcc, dvo0, + dvo1, dvo2, dvo3, dvo4, dvo5, dvo6, dvo7, clko, smi, uinc, + gspi, mben, xcs2, xcs1, sdio, sspi, fi0, fi1, fi2, fi3, fi4, + fi5, fi6, fi7, fi8, fi9, fi10, fi11, fi12, fi13, fi14, fi15, + pwm0, pwm1, pwm2, pwm3, pwm4, pwm5, pwm6, pwm7, hg0, hg1, + hg2, hg3, hg4, hg5, hg6, hg7, gpio ] + + dependencies: + groups: [ function ] + function: [ groups ] + + additionalProperties: false + + "^cfg-": + $ref: pincfg-node.yaml# + + properties: + pins: + description: + A list of pins to configure in certain ways, such as enabling + debouncing + items: + pattern: "^gpio1?[0-9]{1,2}$" + + input-debounce: true + + additionalProperties: false + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/gpio/gpio.h> + pinctrl: pinctrl@b8003000 { + compatible = "nuvoton,wpcm450-pinctrl"; + reg = <0xb8003000 0x1000>; + #address-cells = <1>; + #size-cells = <0>; + + gpio0: gpio@0 { + reg = <0>; + gpio-controller; + #gpio-cells = <2>; + interrupts = <2 IRQ_TYPE_LEVEL_HIGH>, + <3 IRQ_TYPE_LEVEL_HIGH>, + <4 IRQ_TYPE_LEVEL_HIGH>; + }; + + mux-rmii2 { + groups = "rmii2"; + function = "rmii2"; + }; + + pinmux_uid: mux-uid { + groups = "gspi", "sspi"; + function = "gpio"; + }; + + pinctrl_uid: cfg-uid { + pins = "gpio14"; + input-debounce = <1>; + }; + }; + + gpio-keys { + compatible = "gpio-keys"; + pinctrl-names = "default"; + pinctrl-0 = <&pinctrl_uid>, <&pinmux_uid>; + + uid { + label = "UID"; + linux,code = <102>; + gpios = <&gpio0 14 GPIO_ACTIVE_HIGH>; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml new file mode 100644 index 000000000000..8a2bb8608291 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8186.yaml @@ -0,0 +1,297 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/pinctrl-mt8186.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek MT8186 Pin Controller + +maintainers: + - Sean Wang <sean.wang@mediatek.com> + +description: | + The Mediatek's Pin controller is used to control SoC pins. + +properties: + compatible: + const: mediatek,mt8186-pinctrl + + gpio-controller: true + + '#gpio-cells': + description: | + Number of cells in GPIO specifier. Since the generic GPIO binding is used, + the amount of cells must be specified as 2. See the below + mentioned gpio binding representation for description of particular cells. + const: 2 + + gpio-ranges: + maxItems: 1 + + reg: + description: | + Physical address base for gpio base registers. There are 8 different GPIO + physical address base in mt8186. + maxItems: 8 + + reg-names: + description: | + Gpio base register names. + items: + - const: iocfg0 + - const: iocfg_bm + - const: iocfg_bl + - const: iocfg_br + - const: iocfg_lm + - const: iocfg_rb + - const: iocfg_tl + - const: eint + + interrupt-controller: true + + '#interrupt-cells': + const: 2 + + interrupts: + description: The interrupt outputs to sysirq + maxItems: 1 + + mediatek,rsel-resistance-in-si-unit: + type: boolean + description: | + Identifying i2c pins pull up/down type which is RSEL. It can support + RSEL define or si unit value(ohm) to set different resistance. + +# PIN CONFIGURATION NODES +patternProperties: + '-pins$': + type: object + additionalProperties: false + patternProperties: + '^pins': + type: object + additionalProperties: false + description: | + A pinctrl node should contain at least one subnodes representing the + pinctrl groups available on the machine. Each subnode will list the + pins it needs, and how they should be configured, with regard to muxer + configuration, pullups, drive strength, input enable/disable and + input schmitt. + An example of using macro: + pincontroller { + /* GPIO0 set as multifunction GPIO0 */ + gpio-pins { + pins { + pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; + } + }; + /* GPIO128 set as multifunction SDA0 */ + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO128__FUNC_SDA0>; + } + }; + }; + $ref: "pinmux-node.yaml" + + properties: + pinmux: + description: | + Integer array, represents gpio pin number and mux setting. + Supported pin number and mux varies for different SoCs, and are + defined as macros in dt-bindings/pinctrl/<soc>-pinfunc.h + directly. + + drive-strength: + enum: [2, 4, 6, 8, 10, 12, 14, 16] + + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + + bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8186 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203] + description: mt8186 pull down RSEL type define value. + - enum: [75000, 5000] + description: mt8186 pull down RSEL type si unit value(ohm). + description: | + For pull down type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull down type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8186. + For pull down type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + define in mt8186. It can also support resistance value(ohm) + "75000" & "5000" in mt8186. + An example of using RSEL define: + pincontroller { + i2c0_pin { + pins { + pinmux = <PINMUX_GPIO128__FUNC_SDA0>; + bias-pull-down = <MTK_PULL_SET_RSEL_001>; + } + }; + }; + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel-resistance-in-si-unit; + } + pincontroller { + i2c0_pin { + pins { + pinmux = <PINMUX_GPIO128__FUNC_SDA0>; + bias-pull-down = <75000>; + } + }; + }; + + bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8186 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203] + description: mt8186 pull up RSEL type define value. + - enum: [1000, 5000, 10000, 75000] + description: mt8186 pull up RSEL type si unit value(ohm). + description: | + For pull up type is normal, it don't need add RSEL & R1R0 define + and resistance value. + For pull up type is PUPD/R0/R1 type, it can add R1R0 define to + set different resistance. It can support "MTK_PUPD_SET_R1R0_00" & + "MTK_PUPD_SET_R1R0_01" & "MTK_PUPD_SET_R1R0_10" & + "MTK_PUPD_SET_R1R0_11" define in mt8186. + For pull up type is RSEL, it can add RSEL define & resistance + value(ohm) to set different resistance by identifying property + "mediatek,rsel-resistance-in-si-unit". + It can support "MTK_PULL_SET_RSEL_000" & "MTK_PULL_SET_RSEL_001" + & "MTK_PULL_SET_RSEL_010" & "MTK_PULL_SET_RSEL_011" + define in mt8186. It can also support resistance value(ohm) + "1000" & "5000" & "10000" & "75000" in mt8186. + An example of using si unit resistance value(ohm): + &pio { + mediatek,rsel-resistance-in-si-unit; + } + pincontroller { + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO128__FUNC_SDA0>; + bias-pull-up = <1000>; + } + }; + }; + + bias-disable: true + + output-high: true + + output-low: true + + input-enable: true + + input-disable: true + + input-schmitt-enable: true + + input-schmitt-disable: true + + required: + - pinmux + +required: + - compatible + - reg + - interrupts + - interrupt-controller + - '#interrupt-cells' + - gpio-controller + - '#gpio-cells' + - gpio-ranges + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/mt8186-pinfunc.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + pio: pinctrl@10005000 { + compatible = "mediatek,mt8186-pinctrl"; + reg = <0x10005000 0x1000>, + <0x10002000 0x0200>, + <0x10002200 0x0200>, + <0x10002400 0x0200>, + <0x10002600 0x0200>, + <0x10002A00 0x0200>, + <0x10002c00 0x0200>, + <0x1000b000 0x1000>; + reg-names = "iocfg0", "iocfg_bm", "iocfg_bl", + "iocfg_br", "iocfg_lm", "iocfg_rb", + "iocfg_tl", "eint"; + gpio-controller; + #gpio-cells = <2>; + gpio-ranges = <&pio 0 0 185>; + interrupt-controller; + interrupts = <GIC_SPI 186 IRQ_TYPE_LEVEL_HIGH 0>; + #interrupt-cells = <2>; + + pio-pins { + pins { + pinmux = <PINMUX_GPIO0__FUNC_GPIO0>; + output-low; + }; + }; + + spi0-pins { + pins-spi { + pinmux = <PINMUX_GPIO0__FUNC_SPI0_CLK_B>, + <PINMUX_GPIO1__FUNC_SPI0_CSB_B>, + <PINMUX_GPIO2__FUNC_SPI0_MO_B>; + bias-disable; + }; + pins-spi-mi { + pinmux = <PINMUX_GPIO3__FUNC_SPI0_MI_B>; + bias-pull-down; + }; + }; + + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO127__FUNC_SCL0>, + <PINMUX_GPIO128__FUNC_SDA0>; + bias-pull-up = <MTK_PULL_SET_RSEL_001>; + mediatek,drive-strength-adv = <7>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml index 328ea59c5466..c5b755514c46 100644 --- a/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml +++ b/Documentation/devicetree/bindings/pinctrl/pinctrl-mt8195.yaml @@ -98,7 +98,41 @@ patternProperties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] + mediatek,drive-strength-adv: + description: | + Describe the specific driving setup property. + For I2C pins, the existing generic driving setup can only support + 2/4/6/8/10/12/14/16mA driving. But in specific driving setup, they + can support 0.125/0.25/0.5/1mA adjustment. If we enable specific + driving setup, the existing generic setup will be disabled. + The specific driving setup is controlled by E1E0EN. + When E1=0/E0=0, the strength is 0.125mA. + When E1=0/E0=1, the strength is 0.25mA. + When E1=1/E0=0, the strength is 0.5mA. + When E1=1/E0=1, the strength is 1mA. + EN is used to enable or disable the specific driving setup. + Valid arguments are described as below: + 0: (E1, E0, EN) = (0, 0, 0) + 1: (E1, E0, EN) = (0, 0, 1) + 2: (E1, E0, EN) = (0, 1, 0) + 3: (E1, E0, EN) = (0, 1, 1) + 4: (E1, E0, EN) = (1, 0, 0) + 5: (E1, E0, EN) = (1, 0, 1) + 6: (E1, E0, EN) = (1, 1, 0) + 7: (E1, E0, EN) = (1, 1, 1) + So the valid arguments are from 0 to 7. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3, 4, 5, 6, 7] + bias-pull-down: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8195 pull down PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + description: mt8195 pull down RSEL type define value. + - enum: [75000, 5000] + description: mt8195 pull down RSEL type si unit value(ohm). description: | For pull down type is normal, it don't need add RSEL & R1R0 define and resistance value. @@ -115,13 +149,6 @@ patternProperties: & "MTK_PULL_SET_RSEL_110" & "MTK_PULL_SET_RSEL_111" define in mt8195. It can also support resistance value(ohm) "75000" & "5000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull down PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull down RSEL type define value. - - enum: [75000, 5000] - - description: mt8195 pull down RSEL type si unit value(ohm). An example of using RSEL define: pincontroller { @@ -146,6 +173,14 @@ patternProperties: }; bias-pull-up: + oneOf: + - type: boolean + - enum: [100, 101, 102, 103] + description: mt8195 pull up PUPD/R0/R1 type define value. + - enum: [200, 201, 202, 203, 204, 205, 206, 207] + description: mt8195 pull up RSEL type define value. + - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] + description: mt8195 pull up RSEL type si unit value(ohm). description: | For pull up type is normal, it don't need add RSEL & R1R0 define and resistance value. @@ -163,13 +198,6 @@ patternProperties: define in mt8195. It can also support resistance value(ohm) "1000" & "1500" & "2000" & "3000" & "4000" & "5000" & "10000" & "75000" in mt8195. - oneOf: - - enum: [100, 101, 102, 103] - - description: mt8195 pull up PUPD/R0/R1 type define value. - - enum: [200, 201, 202, 203, 204, 205, 206, 207] - - description: mt8195 pull up RSEL type define value. - - enum: [1000, 1500, 2000, 3000, 4000, 5000, 10000, 75000] - - description: mt8195 pull up RSEL type si unit value(ohm). An example of using RSEL define: pincontroller { i2c0-pins { @@ -268,4 +296,13 @@ examples: bias-pull-down; }; }; + + i2c0-pins { + pins { + pinmux = <PINMUX_GPIO8__FUNC_SDA0>, + <PINMUX_GPIO9__FUNC_SCL0>; + bias-disable; + mediatek,drive-strength-adv = <7>; + }; + }; }; diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml index 64c0a41ca0c3..d4da558cde54 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,msm8953-pinctrl.yaml @@ -34,6 +34,8 @@ properties: gpio-controller: true + gpio-reserved-ranges: true + '#gpio-cells': description: Specifying the pin number and flags, as defined in include/dt-bindings/gpio/gpio.h diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml index 9400b665a46f..fe2bcf0694d9 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-gpio.yaml @@ -36,6 +36,7 @@ properties: - qcom,pm8350-gpio - qcom,pm8350b-gpio - qcom,pm8350c-gpio + - qcom,pm8450-gpio - qcom,pm8916-gpio - qcom,pm8917-gpio - qcom,pm8921-gpio diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml index 35c846f59979..df79274d0ec3 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,pmic-mpp.yaml @@ -21,6 +21,7 @@ properties: - qcom,pm8019-mpp - qcom,pm8038-mpp - qcom,pm8058-mpp + - qcom,pm8226-mpp - qcom,pm8821-mpp - qcom,pm8841-mpp - qcom,pm8916-mpp diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml new file mode 100644 index 000000000000..87a381c9a19d --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/qcom,sc8280xp-pinctrl.yaml @@ -0,0 +1,151 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/qcom,sc8280xp-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Technologies, Inc. SC8280XP TLMM block + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: | + This binding describes the Top Level Mode Multiplexer block found in the + SC8280XP platform. + +allOf: + - $ref: /schemas/pinctrl/qcom,tlmm-common.yaml# + +properties: + compatible: + const: qcom,sc8280xp-tlmm + + reg: + maxItems: 1 + + 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 + +additionalProperties: false + +patternProperties: + '-state$': + oneOf: + - $ref: "#/$defs/qcom-sc8280xp-tlmm-state" + - patternProperties: + ".*": + $ref: "#/$defs/qcom-sc8280xp-tlmm-state" + +'$defs': + qcom-sc8280xp-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-9][0-9]|2[0-1][0-9]|22[0-7])$" + - enum: [ sdc2_clk, sdc2_cmd, sdc2_data, ufs_reset, ufs1_reset ] + minItems: 1 + maxItems: 16 + + function: + description: + Specify the alternative function to be configured for the specified + pins. + + enum: [ atest_char, atest_usb, audio_ref, cam_mclk, cci_async, cci_i2c, + cci_timer0, cci_timer1, cci_timer2, cci_timer3, cci_timer4, + cci_timer5, cci_timer6, cci_timer7, cci_timer8, cci_timer9, + cmu_rng, cri_trng, cri_trng0, cri_trng1, dbg_out, ddr_bist, + ddr_pxi0, ddr_pxi1, ddr_pxi2, ddr_pxi3, ddr_pxi4, ddr_pxi5, + ddr_pxi6, ddr_pxi7, dp2_hot, dp3_hot, edp0_lcd, edp1_lcd, + edp2_lcd, edp3_lcd, edp_hot, emac0_dll, emac0_mcg0, emac0_mcg1, + emac0_mcg2, emac0_mcg3, emac0_phy, emac0_ptp, emac1_dll0, + emac1_dll1, emac1_mcg0, emac1_mcg1, emac1_mcg2, emac1_mcg3, + emac1_phy, emac1_ptp, gcc_gp1, gcc_gp2, gcc_gp3, gcc_gp4, + gcc_gp5, gpio, hs1_mi2s, hs2_mi2s, hs3_mi2s, ibi_i3c, + jitter_bist, lpass_slimbus, mdp0_vsync0, mdp0_vsync1, + mdp0_vsync2, mdp0_vsync3, mdp0_vsync4, mdp0_vsync5, + mdp0_vsync6, mdp0_vsync7, mdp0_vsync8, mdp1_vsync0, + mdp1_vsync1, mdp1_vsync2, mdp1_vsync3, mdp1_vsync4, + mdp1_vsync5, mdp1_vsync6, mdp1_vsync7, mdp1_vsync8, mdp_vsync, + mi2s0_data0, mi2s0_data1, mi2s0_sck, mi2s0_ws, mi2s1_data0, + mi2s1_data1, mi2s1_sck, mi2s1_ws, mi2s2_data0, mi2s2_data1, + mi2s2_sck, mi2s2_ws, mi2s_mclk1, mi2s_mclk2, pcie2a_clkreq, + pcie2b_clkreq, pcie3a_clkreq, pcie3b_clkreq, pcie4_clkreq, + phase_flag, pll_bist, pll_clk, prng_rosc0, prng_rosc1, + prng_rosc2, prng_rosc3, qdss_cti, qdss_gpio, qspi, qspi_clk, + qspi_cs, qup0, qup1, qup2, qup3, qup4, qup5, qup6, qup7, qup8, + qup9, qup10, qup11, qup12, qup13, qup14, qup15, qup16, qup17, + qup18, qup19, qup20, qup21, qup22, qup23, rgmii_0, rgmii_1, + sd_write, sdc40, sdc42, sdc43, sdc4_clk, sdc4_cmd, tb_trig, + tgu, tsense_pwm1, tsense_pwm2, tsense_pwm3, tsense_pwm4, + usb0_dp, usb0_phy, usb0_sbrx, usb0_sbtx, usb0_usb4, usb1_dp, + usb1_phy, usb1_sbrx, usb1_sbtx, usb1_usb4, usb2phy_ac, + vsense_trigger ] + + 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@f100000 { + compatible = "qcom,sc8280xp-tlmm"; + reg = <0x0f100000 0x300000>; + interrupts = <GIC_SPI 208 IRQ_TYPE_LEVEL_HIGH>; + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + gpio-ranges = <&tlmm 0 0 230>; + + gpio-wo-subnode-state { + pins = "gpio1"; + function = "gpio"; + }; + + uart-w-subnodes-state { + rx { + pins = "gpio4"; + function = "qup14"; + bias-pull-up; + }; + + tx { + pins = "gpio5"; + function = "qup14"; + bias-disable; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml index be8cb0ead62f..780f15bb5e40 100644 --- a/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml +++ b/Documentation/devicetree/bindings/pinctrl/qcom,tlmm-common.yaml @@ -73,7 +73,6 @@ $defs: properties: drive-strength: enum: [2, 4, 6, 8, 10, 12, 14, 16] - default: 2 description: Selects the drive strength for the specified pins, in mA. diff --git a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml index f0c52feb24d7..9de8b0c075e2 100644 --- a/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml +++ b/Documentation/devicetree/bindings/pinctrl/ralink,rt2880-pinmux.yaml @@ -10,7 +10,7 @@ maintainers: - Sergio Paracuellos <sergio.paracuellos@gmail.com> description: - The rt2880 pinmux can only set the muxing of pin groups. muxing indiviual pins + The rt2880 pinmux can only set the muxing of pin groups. Muxing indiviual pins is not supported. There is no pinconf support. properties: @@ -29,12 +29,13 @@ patternProperties: properties: groups: description: Name of the pin group to use for the functions. - enum: [i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, mdio, - pcie, sdhci] + enum: [i2c, jtag, mdio, pcie, rgmii1, rgmii2, sdhci, spi, + uart1, uart2, uart3, wdt] function: description: The mux function to select - enum: [gpio, i2c, spi, uart1, uart2, uart3, rgmii1, rgmii2, - mdio, nand1, nand2, sdhci] + enum: [gpio, i2c, i2s, jtag, mdio, nand1, nand2, pcie refclk, + pcie rst, pcm, rgmii1, rgmii2, sdhci, spdif2, spdif3, + spi, uart1, uart2, uart3, wdt refclk, wdt rst] required: - groups diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml index 8548e3639b75..2a57df75d832 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,pfc.yaml @@ -44,6 +44,7 @@ properties: - renesas,pfc-r8a77990 # R-Car E3 - renesas,pfc-r8a77995 # R-Car D3 - renesas,pfc-r8a779a0 # R-Car V3U + - renesas,pfc-r8a779f0 # R-Car S4-8 - renesas,pfc-sh73a0 # SH-Mobile AG5 reg: diff --git a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml index b749c82edebd..9ccf54870aa4 100644 --- a/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/renesas,rzg2l-pinctrl.yaml @@ -4,14 +4,14 @@ $id: http://devicetree.org/schemas/pinctrl/renesas,rzg2l-pinctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L combined Pin and GPIO controller +title: Renesas RZ/{G2L,V2L} combined Pin and GPIO controller maintainers: - Geert Uytterhoeven <geert+renesas@glider.be> - Lad Prabhakar <prabhakar.mahadev-lad.rj@bp.renesas.com> description: - The Renesas SoCs of the RZ/G2L series feature a combined Pin and GPIO + The Renesas SoCs of the RZ/{G2L,V2L} series feature a combined Pin and GPIO controller. Pin multiplexing and GPIO configuration is performed on a per-pin basis. Each port features up to 8 pins, each of them configurable for GPIO function @@ -20,8 +20,15 @@ description: properties: compatible: - enum: - - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + oneOf: + - items: + - enum: + - renesas,r9a07g044-pinctrl # RZ/G2{L,LC} + + - items: + - enum: + - renesas,r9a07g054-pinctrl # RZ/V2L + - const: renesas,r9a07g044-pinctrl # RZ/G2{L,LC} fallback for RZ/V2L reg: maxItems: 1 @@ -76,6 +83,7 @@ additionalProperties: output-impedance-ohms: enum: [ 33, 50, 66, 100 ] power-source: + description: I/O voltage in millivolt. enum: [ 1800, 2500, 3300 ] slew-rate: true gpio-hog: true diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml new file mode 100644 index 000000000000..f73348c54748 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-gpio-bank.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl-gpio-bank.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - gpio bank + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + GPIO bank description for Samsung S3C/S5P/Exynos SoC pin controller. + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + '#gpio-cells': + const: 2 + + gpio-controller: true + + '#interrupt-cells': + description: + For GPIO banks supporting external GPIO interrupts or external wake-up + interrupts. + const: 2 + + interrupt-controller: + description: + For GPIO banks supporting external GPIO interrupts or external wake-up + interrupts. + + interrupts: + description: + For GPIO banks supporting direct external wake-up interrupts (without + multiplexing). Number of interrupts must match number of wake-up capable + pins of this bank. + minItems: 1 + maxItems: 8 + +required: + - '#gpio-cells' + - gpio-controller + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml new file mode 100644 index 000000000000..c71939ac8b63 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-pins-cfg.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl-pins-cfg.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - pins configuration + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + Pins configuration for Samsung S3C/S5P/Exynos SoC pin controller. + + The values used for config properties should be derived from the hardware + manual and these values are programmed as-is into the pin pull up/down and + driver strength register of the pin-controller. + See also include/dt-bindings/pinctrl/samsung.h with useful constants. + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + samsung,pins: + description: | + List of pins to configure. For initial and sleep states, the maximum + number is one pin. In other cases there is no upper limit. + + The pins should use lowercase names matching hardware manual, e.g. for + GPA0 bank: gpa0-0, gpa0-1, gpa0-2. + $ref: /schemas/types.yaml#/definitions/string-array + + samsung,pin-function: + description: | + The pin function selection that should be applied on the pins listed in the + child node is specified using the "samsung,pin-function" property. The value + of this property that should be applied to each of the pins listed in the + "samsung,pins" property should be picked from the hardware manual of the SoC + for the specified pin group. This property is optional in the child node if + no specific function selection is desired for the pins listed in the child + node. The value of this property is used as-is to program the pin-controller + function selector register of the pin-bank. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + samsung,pin-drv: + description: Drive strength configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 0 + maximum: 15 + + samsung,pin-pud: + description: Pull up/down configuration. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + samsung,pin-val: + description: Initial value of pin output buffer. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1] + + samsung,pin-con-pdn: + description: Function in power down mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + + samsung,pin-pud-pdn: + description: Pull up/down configuration in power down mode. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + +required: + - samsung,pins + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml new file mode 100644 index 000000000000..a822f70f5702 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.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/samsung,pinctrl-wakeup-interrupt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller - wake-up interrupt controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + External wake-up interrupts for Samsung S3C/S5P/Exynos SoC pin controller. + For S3C24xx, S3C64xx, S5PV210 and Exynos4210 compatible wake-up interrupt + controllers, only one pin-controller device node can include external wake-up + interrupts child node (in other words, only one External wake-up interrupts + pin-controller is supported). + For newer controllers, multiple pin-controller device node can include + external wake-up interrupts child node. + + See also Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml for + additional information and example. + +properties: + compatible: + enum: + - samsung,s3c2410-wakeup-eint + - samsung,s3c2412-wakeup-eint + - samsung,s3c64xx-wakeup-eint + - samsung,s5pv210-wakeup-eint + - samsung,exynos4210-wakeup-eint + - samsung,exynos7-wakeup-eint + - samsung,exynos850-wakeup-eint + - samsung,exynosautov9-wakeup-eint + + interrupts: + description: + Interrupt used by multiplexed external wake-up interrupts. + minItems: 1 + maxItems: 6 + +required: + - compatible + +allOf: + - if: + properties: + compatible: + contains: + enum: + - samsung,s3c2410-wakeup-eint + - samsung,s3c2412-wakeup-eint + then: + properties: + interrupts: + minItems: 6 + maxItems: 6 + required: + - interrupts + + - if: + properties: + compatible: + contains: + const: samsung,s3c64xx-wakeup-eint + then: + properties: + interrupts: + minItems: 4 + maxItems: 4 + required: + - interrupts + + - if: + properties: + compatible: + contains: + enum: + - samsung,s5pv210-wakeup-eint + - samsung,exynos4210-wakeup-eint + - samsung,exynos7-wakeup-eint + then: + properties: + interrupts: + minItems: 1 + maxItems: 1 + required: + - interrupts + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos850-wakeup-eint + - samsung,exynosautov9-wakeup-eint + then: + properties: + interrupts: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml new file mode 100644 index 000000000000..989e48c051cf --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml @@ -0,0 +1,393 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/samsung,pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC pin controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + - Tomasz Figa <tomasz.figa@gmail.com> + +description: | + This is a part of device tree bindings for Samsung S3C/S5P/Exynos SoC pin + controller. + + Pin group settings (like drive strength, pull up/down) are available as + macros in include/dt-bindings/pinctrl/samsung.h. + + All the pin controller nodes should be represented in the aliases node using + the following format 'pinctrl{n}' where n is a unique number for the alias. + + The controller supports three types of interrupts:: + - External GPIO interrupts (see interrupts property in pin controller node); + + - External wake-up interrupts - multiplexed (capable of waking up the system + see interrupts property in external wake-up interrupt controller node - + samsung,pinctrl-wakeup-interrupt.yaml); + + - External wake-up interrupts - direct (capable of waking up the system, see + interrupts property in every bank of pin controller with external wake-up + interrupt controller - samsung,pinctrl-gpio-bank.yaml). + +properties: + $nodename: + pattern: "^pinctrl(@.*)?" + + compatible: + enum: + - samsung,s3c2412-pinctrl + - samsung,s3c2416-pinctrl + - samsung,s3c2440-pinctrl + - samsung,s3c2450-pinctrl + - samsung,s3c64xx-pinctrl + - samsung,s5pv210-pinctrl + - samsung,exynos3250-pinctrl + - samsung,exynos4210-pinctrl + - samsung,exynos4x12-pinctrl + - samsung,exynos5250-pinctrl + - samsung,exynos5260-pinctrl + - samsung,exynos5410-pinctrl + - samsung,exynos5420-pinctrl + - samsung,exynos5433-pinctrl + - samsung,exynos7-pinctrl + - samsung,exynos7885-pinctrl + - samsung,exynos850-pinctrl + - samsung,exynosautov9-pinctrl + - tesla,fsd-pinctrl + + interrupts: + description: + Required for GPIO banks supporting external GPIO interrupts. + maxItems: 1 + + power-domains: + maxItems: 1 + + reg: + description: + Second base address of the pin controller if the specific registers of + the pin controller are separated into the different base address. + Only certain banks of certain pin controller might need it. + minItems: 1 + maxItems: 2 + + wakeup-interrupt-controller: + $ref: samsung,pinctrl-wakeup-interrupt.yaml + +patternProperties: + "^[a-z]+[0-9]*-gpio-bank$": + description: + Pin banks of the controller are represented by child nodes of the + controller node. Bank name is taken from name of the node. + $ref: samsung,pinctrl-gpio-bank.yaml + + "^[a-z0-9-]+-pins$": + oneOf: + - $ref: samsung,pinctrl-pins-cfg.yaml + required: + - samsung,pins + - type: object + patternProperties: + "^[a-z0-9-]+-pins$": + $ref: samsung,pinctrl-pins-cfg.yaml + + additionalProperties: false + + "^(initial|sleep)-state$": + patternProperties: + "^(pin-[a-z0-9-]+|[a-z0-9-]+-pin)$": + $ref: samsung,pinctrl-pins-cfg.yaml + + properties: + samsung,pins: + description: See samsung,pinctrl-pins-cfg.yaml + $ref: /schemas/types.yaml#/definitions/string-array + maxItems: 1 + + required: + - samsung,pins + + unevaluatedProperties: false + +required: + - compatible + - reg + +allOf: + - $ref: "pinctrl.yaml#" + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-pinctrl + then: + properties: + reg: + minItems: 1 + maxItems: 2 + else: + properties: + reg: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/samsung.h> + + pinctrl@7f008000 { + compatible = "samsung,s3c64xx-pinctrl"; + reg = <0x7f008000 0x1000>; + interrupt-parent = <&vic1>; + interrupts = <21>; + + wakeup-interrupt-controller { + compatible = "samsung,s3c64xx-wakeup-eint"; + interrupts-extended = <&vic0 0>, + <&vic0 1>, + <&vic1 0>, + <&vic1 1>; + }; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpa-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + uart0-data-pins { + samsung,pins = "gpa-0", "gpa-1"; + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; + samsung,pin-pud = <S3C64XX_PIN_PULL_NONE>; + }; + + // ... + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/samsung.h> + + pinctrl@11400000 { + compatible = "samsung,exynos4210-pinctrl"; + reg = <0x11400000 0x1000>; + interrupts = <GIC_SPI 47 IRQ_TYPE_LEVEL_HIGH>; + + pinctrl-names = "default"; + pinctrl-0 = <&sleep0>; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpa0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + uart0-data-pins { + samsung,pins = "gpa0-0", "gpa0-1"; + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; + }; + + // ... + + sleep0: sleep-state { + gpa0-0-pin { + samsung,pins = "gpa0-0"; + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_INPUT>; + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>; + }; + + gpa0-1-pin { + samsung,pins = "gpa0-1"; + samsung,pin-con-pdn = <EXYNOS_PIN_PDN_OUT0>; + samsung,pin-pud-pdn = <EXYNOS_PIN_PULL_NONE>; + }; + + // ... + }; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/samsung.h> + + pinctrl@11000000 { + compatible = "samsung,exynos4210-pinctrl"; + reg = <0x11000000 0x1000>; + interrupts = <GIC_SPI 46 IRQ_TYPE_LEVEL_HIGH>; + + wakeup-interrupt-controller { + compatible = "samsung,exynos4210-wakeup-eint"; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + }; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpj0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + /* Pin bank without external interrupts */ + gpy0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + }; + + /* Pin bank with external direct wake-up interrupts */ + gpx0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <2>; + }; + + // ... + + sd0-clk-pins { + samsung,pins = "gpk0-0"; + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; + }; + + sd4-bus-width8-pins { + part-1-pins { + samsung,pins = "gpk0-3", "gpk0-4", + "gpk0-5", "gpk0-6"; + samsung,pin-function = <EXYNOS_PIN_FUNC_3>; + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; + }; + + part-2-pins { + samsung,pins = "gpk1-3", "gpk1-4", + "gpk1-5", "gpk1-6"; + samsung,pin-function = <EXYNOS_PIN_FUNC_4>; + samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; + }; + }; + + // ... + + otg-gp-pins { + samsung,pins = "gpx3-3"; + samsung,pin-function = <EXYNOS_PIN_FUNC_OUTPUT>; + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; + samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; + samsung,pin-val = <0>; + }; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/samsung.h> + + pinctrl@10580000 { + compatible = "samsung,exynos5433-pinctrl"; + reg = <0x10580000 0x1a20>, <0x11090000 0x100>; + + pinctrl-names = "default"; + pinctrl-0 = <&initial_alive>; + + wakeup-interrupt-controller { + compatible = "samsung,exynos7-wakeup-eint"; + interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH>; + }; + + /* Pin bank with external direct wake-up interrupts */ + gpa0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + + interrupt-controller; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH>; + #interrupt-cells = <2>; + }; + + // ... + + te-irq-pins { + samsung,pins = "gpf1-3"; + samsung,pin-function = <0xf>; + }; + + // .. + + initial_alive: initial-state { + gpa0-0-pin { + samsung,pins = "gpa0-0"; + samsung,pin-function = <EXYNOS_PIN_FUNC_INPUT>; + samsung,pin-pud = <EXYNOS_PIN_PULL_DOWN>; + samsung,pin-drv = <EXYNOS5433_PIN_DRV_FAST_SR1>; + }; + + // ... + }; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/pinctrl/samsung.h> + + pinctrl@114b0000 { + compatible = "samsung,exynos5433-pinctrl"; + reg = <0x114b0000 0x1000>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + power-domains = <&pd_aud>; + + /* Pin bank with external GPIO or muxed external wake-up interrupts */ + gpz0-gpio-bank { + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + }; + + // ... + + i2s0-bus-pins { + samsung,pins = "gpz0-0", "gpz0-1", "gpz0-2", "gpz0-3", + "gpz0-4", "gpz0-5", "gpz0-6"; + samsung,pin-function = <EXYNOS_PIN_FUNC_2>; + samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; + samsung,pin-drv = <EXYNOS5433_PIN_DRV_FAST_SR1>; + }; + + // ... + }; diff --git a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt b/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt deleted file mode 100644 index 9e70edceb21b..000000000000 --- a/Documentation/devicetree/bindings/pinctrl/samsung-pinctrl.txt +++ /dev/null @@ -1,383 +0,0 @@ -Samsung GPIO and Pin Mux/Config controller - -Samsung's ARM based SoC's integrates a GPIO and Pin mux/config hardware -controller. It controls the input/output settings on the available pads/pins -and also provides ability to multiplex and configure the output of various -on-chip controllers onto these pads. - -Required Properties: -- compatible: should be one of the following. - - "samsung,s3c2412-pinctrl": for S3C2412-compatible pin-controller, - - "samsung,s3c2416-pinctrl": for S3C2416-compatible pin-controller, - - "samsung,s3c2440-pinctrl": for S3C2440-compatible pin-controller, - - "samsung,s3c2450-pinctrl": for S3C2450-compatible pin-controller, - - "samsung,s3c64xx-pinctrl": for S3C64xx-compatible pin-controller, - - "samsung,s5pv210-pinctrl": for S5PV210-compatible pin-controller, - - "samsung,exynos3250-pinctrl": for Exynos3250 compatible pin-controller. - - "samsung,exynos4210-pinctrl": for Exynos4210 compatible pin-controller. - - "samsung,exynos4x12-pinctrl": for Exynos4x12 compatible pin-controller. - - "samsung,exynos5250-pinctrl": for Exynos5250 compatible pin-controller. - - "samsung,exynos5260-pinctrl": for Exynos5260 compatible pin-controller. - - "samsung,exynos5410-pinctrl": for Exynos5410 compatible pin-controller. - - "samsung,exynos5420-pinctrl": for Exynos5420 compatible pin-controller. - - "samsung,exynos5433-pinctrl": for Exynos5433 compatible pin-controller. - - "samsung,exynos7-pinctrl": for Exynos7 compatible pin-controller. - - "samsung,exynos7885-pinctrl": for Exynos7885 compatible pin-controller. - - "samsung,exynos850-pinctrl": for Exynos850 compatible pin-controller. - - "samsung,exynosautov9-pinctrl": for ExynosAutov9 compatible pin-controller. - -- reg: Base address of the pin controller hardware module and length of - the address space it occupies. - - - reg: Second base address of the pin controller if the specific registers - of the pin controller are separated into the different base address. - - Eg: GPF[1-5] of Exynos5433 are separated into the two base address. - - First base address is for GPAx and GPF[1-5] external interrupt - registers. - - Second base address is for GPF[1-5] pinctrl registers. - - pinctrl_0: pinctrl@10580000 { - compatible = "samsung,exynos5433-pinctrl"; - reg = <0x10580000 0x1a20>, <0x11090000 0x100>; - - wakeup-interrupt-controller { - compatible = "samsung,exynos7-wakeup-eint"; - interrupts = <0 16 0>; - }; - }; - -- Pin banks as child nodes: Pin banks of the controller are represented by child - nodes of the controller node. Bank name is taken from name of the node. Each - bank node must contain following properties: - - - gpio-controller: identifies the node as a gpio controller and pin bank. - - #gpio-cells: number of cells in GPIO specifier. Since the generic GPIO - binding is used, the amount of cells must be specified as 2. See the below - mentioned gpio binding representation for description of particular cells. - - Eg: <&gpx2 6 0> - <[phandle of the gpio controller node] - [pin number within the gpio controller] - [flags]> - - Values for gpio specifier: - - Pin number: is a value between 0 to 7. - - Flags: 0 - Active High - 1 - Active Low - -- Pin mux/config groups as child nodes: The pin mux (selecting pin function - mode) and pin config (pull up/down, driver strength) settings are represented - as child nodes of the pin-controller node. There should be at least one - child node and there is no limit on the count of these child nodes. It is - also possible for a child node to consist of several further child nodes - to allow grouping multiple pinctrl groups into one. The format of second - level child nodes is exactly the same as for first level ones and is - described below. - - The child node should contain a list of pin(s) on which a particular pin - function selection or pin configuration (or both) have to applied. This - list of pins is specified using the property name "samsung,pins". There - should be at least one pin specified for this property and there is no upper - limit on the count of pins that can be specified. The pins are specified - using pin names which are derived from the hardware manual of the SoC. As - an example, the pins in GPA0 bank of the pin controller can be represented - as "gpa0-0", "gpa0-1", "gpa0-2" and so on. The names should be in lower case. - The format of the pin names should be (as per the hardware manual) - "[pin bank name]-[pin number within the bank]". - - The pin function selection that should be applied on the pins listed in the - child node is specified using the "samsung,pin-function" property. The value - of this property that should be applied to each of the pins listed in the - "samsung,pins" property should be picked from the hardware manual of the SoC - for the specified pin group. This property is optional in the child node if - no specific function selection is desired for the pins listed in the child - node. The value of this property is used as-is to program the pin-controller - function selector register of the pin-bank. - - The child node can also optionally specify one or more of the pin - configuration that should be applied on all the pins listed in the - "samsung,pins" property of the child node. The following pin configuration - properties are supported. - - - samsung,pin-val: Initial value of pin output buffer. - - samsung,pin-pud: Pull up/down configuration. - - samsung,pin-drv: Drive strength configuration. - - samsung,pin-pud-pdn: Pull up/down configuration in power down mode. - - samsung,pin-drv-pdn: Drive strength configuration in power down mode. - - The values specified by these config properties should be derived from the - hardware manual and these values are programmed as-is into the pin - pull up/down and driver strength register of the pin-controller. - - Note: A child should include at least a pin function selection property or - pin configuration property (one or more) or both. - - The client nodes that require a particular pin function selection and/or - pin configuration should use the bindings listed in the "pinctrl-bindings.txt" - file. - -External GPIO and Wakeup Interrupts: - -The controller supports two types of external interrupts over gpio. The first -is the external gpio interrupt and second is the external wakeup interrupts. -The difference between the two is that the external wakeup interrupts can be -used as system wakeup events. - -A. External GPIO Interrupts: For supporting external gpio interrupts, the - following properties should be specified in the pin-controller device node. - - - interrupts: interrupt specifier for the controller. The format and value of - the interrupt specifier depends on the interrupt parent for the controller. - - In addition, following properties must be present in node of every bank - of pins supporting GPIO interrupts: - - - interrupt-controller: identifies the controller node as interrupt-parent. - - #interrupt-cells: the value of this property should be 2. - - First Cell: represents the external gpio interrupt number local to the - external gpio interrupt space of the controller. - - Second Cell: flags to identify the type of the interrupt - - 1 = rising edge triggered - - 2 = falling edge triggered - - 3 = rising and falling edge triggered - - 4 = high level triggered - - 8 = low level triggered - -B. External Wakeup Interrupts: For supporting external wakeup interrupts, a - child node representing the external wakeup interrupt controller should be - included in the pin-controller device node. - - Only one pin-controller device node can include external wakeup interrupts - child node (in other words, only one External Wakeup Interrupts - pin-controller is supported). - - This child node should include following properties: - - - compatible: identifies the type of the external wakeup interrupt controller - The possible values are: - - samsung,s3c2410-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C24xx SoCs except S3C2412 and S3C2413, - - samsung,s3c2412-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C2412 and S3C2413 SoCs, - - samsung,s3c64xx-wakeup-eint: represents wakeup interrupt controller - found on Samsung S3C64xx SoCs, - - samsung,s5pv210-wakeup-eint: represents wakeup interrupt controller - found on Samsung S5Pv210 SoCs, - - samsung,exynos4210-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos4210 and S5PC110/S5PV210 SoCs. - - samsung,exynos7-wakeup-eint: represents wakeup interrupt controller - found on Samsung Exynos7 SoC. - - interrupts: interrupt used by multiplexed wakeup interrupts. - - In addition, following properties must be present in node of every bank - of pins supporting wake-up interrupts: - - - interrupt-controller: identifies the node as interrupt-parent. - - #interrupt-cells: the value of this property should be 2 - - First Cell: represents the external wakeup interrupt number local to - the external wakeup interrupt space of the controller. - - Second Cell: flags to identify the type of the interrupt - - 1 = rising edge triggered - - 2 = falling edge triggered - - 3 = rising and falling edge triggered - - 4 = high level triggered - - 8 = low level triggered - - Node of every bank of pins supporting direct wake-up interrupts (without - multiplexing) must contain following properties: - - - interrupts: interrupts of the interrupt parent which are used for external - wakeup interrupts from pins of the bank, must contain interrupts for all - pins of the bank. - -Aliases: - -All the pin controller nodes should be represented in the aliases node using -the following format 'pinctrl{n}' where n is a unique number for the alias. - -Aliases for controllers compatible with "samsung,exynos7-pinctrl": -- pinctrl0: pin controller of ALIVE block, -- pinctrl1: pin controller of BUS0 block, -- pinctrl2: pin controller of NFC block, -- pinctrl3: pin controller of TOUCH block, -- pinctrl4: pin controller of FF block, -- pinctrl5: pin controller of ESE block, -- pinctrl6: pin controller of FSYS0 block, -- pinctrl7: pin controller of FSYS1 block, -- pinctrl8: pin controller of BUS1 block, -- pinctrl9: pin controller of AUDIO block, - -Example: A pin-controller node with pin banks: - - pinctrl_0: pinctrl@11400000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11400000 0x1000>; - interrupts = <0 47 0>; - - /* ... */ - - /* Pin bank without external interrupts */ - gpy0: gpy0 { - gpio-controller; - #gpio-cells = <2>; - }; - - /* ... */ - - /* Pin bank with external GPIO or muxed wake-up interrupts */ - gpj0: gpj0 { - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - #interrupt-cells = <2>; - }; - - /* ... */ - - /* Pin bank with external direct wake-up interrupts */ - gpx0: gpx0 { - gpio-controller; - #gpio-cells = <2>; - - interrupt-controller; - interrupt-parent = <&gic>; - interrupts = <0 16 0>, <0 17 0>, <0 18 0>, <0 19 0>, - <0 20 0>, <0 21 0>, <0 22 0>, <0 23 0>; - #interrupt-cells = <2>; - }; - - /* ... */ - }; - -Example 1: A pin-controller node with pin groups. - - #include <dt-bindings/pinctrl/samsung.h> - - pinctrl_0: pinctrl@11400000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11400000 0x1000>; - interrupts = <0 47 0>; - - /* ... */ - - uart0_data: uart0-data { - samsung,pins = "gpa0-0", "gpa0-1"; - samsung,pin-function = <EXYNOS_PIN_FUNC_2>; - samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; - }; - - uart0_fctl: uart0-fctl { - samsung,pins = "gpa0-2", "gpa0-3"; - samsung,pin-function = <EXYNOS_PIN_FUNC_2>; - samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; - }; - - uart1_data: uart1-data { - samsung,pins = "gpa0-4", "gpa0-5"; - samsung,pin-function = <EXYNOS_PIN_FUNC_2>; - samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; - }; - - uart1_fctl: uart1-fctl { - samsung,pins = "gpa0-6", "gpa0-7"; - samsung,pin-function = <EXYNOS_PIN_FUNC_2>; - samsung,pin-pud = <EXYNOS_PIN_PULL_NONE>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; - }; - - i2c2_bus: i2c2-bus { - samsung,pins = "gpa0-6", "gpa0-7"; - samsung,pin-function = <EXYNOS_PIN_FUNC_3>; - samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV1>; - }; - - sd4_bus8: sd4-bus-width8 { - part-1 { - samsung,pins = "gpk0-3", "gpk0-4", - "gpk0-5", "gpk0-6"; - samsung,pin-function = <EXYNOS_PIN_FUNC_3>; - samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; - }; - part-2 { - samsung,pins = "gpk1-3", "gpk1-4", - "gpk1-5", "gpk1-6"; - samsung,pin-function = <EXYNOS_PIN_FUNC_4>; - samsung,pin-pud = <EXYNOS_PIN_PULL_UP>; - samsung,pin-drv = <EXYNOS4_PIN_DRV_LV4>; - }; - }; - }; - -Example 2: A pin-controller node with external wakeup interrupt controller node. - - pinctrl_1: pinctrl@11000000 { - compatible = "samsung,exynos4210-pinctrl"; - reg = <0x11000000 0x1000>; - interrupts = <0 46 0> - - /* ... */ - - wakeup-interrupt-controller { - compatible = "samsung,exynos4210-wakeup-eint"; - interrupt-parent = <&gic>; - interrupts = <0 32 0>; - }; - }; - -Example 3: A uart client node that supports 'default' and 'flow-control' states. - - uart@13800000 { - compatible = "samsung,exynos4210-uart"; - reg = <0x13800000 0x100>; - interrupts = <0 52 0>; - pinctrl-names = "default", "flow-control; - pinctrl-0 = <&uart0_data>; - pinctrl-1 = <&uart0_data>, <&uart0_fctl>; - }; - -Example 4: Set up the default pin state for uart controller. - - static int s3c24xx_serial_probe(struct platform_device *pdev) { - struct pinctrl *pinctrl; - - /* ... */ - - pinctrl = devm_pinctrl_get_select_default(&pdev->dev); - } - -Example 5: A display port client node that supports 'default' pinctrl state - and gpio binding. - - display-port-controller { - /* ... */ - - samsung,hpd-gpio = <&gpx2 6 0>; - pinctrl-names = "default"; - pinctrl-0 = <&dp_hpd>; - }; - -Example 6: Request the gpio for display port controller - - static int exynos_dp_probe(struct platform_device *pdev) - { - int hpd_gpio, ret; - struct device *dev = &pdev->dev; - struct device_node *dp_node = dev->of_node; - - /* ... */ - - hpd_gpio = of_get_named_gpio(dp_node, "samsung,hpd-gpio", 0); - - /* ... */ - - ret = devm_gpio_request_one(&pdev->dev, hpd_gpio, GPIOF_IN, - "hpd_gpio"); - /* ... */ - } diff --git a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml index 83a18d0331b1..335ffc1353b5 100644 --- a/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml +++ b/Documentation/devicetree/bindings/pinctrl/st,stm32-pinctrl.yaml @@ -41,11 +41,13 @@ properties: maxItems: 1 st,syscfg: - description: Should be phandle/offset/mask - - Phandle to the syscon node which includes IRQ mux selection. - - The offset of the IRQ mux selection register. - - The field mask of IRQ mux, needed if different of 0xf. + description: Phandle+args to the syscon node which includes IRQ mux selection. $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + - items: + - description: syscon node which includes IRQ mux selection + - description: The offset of the IRQ mux selection register + - description: The field mask of IRQ mux, needed if different of 0xf st,package: description: diff --git a/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml new file mode 100644 index 000000000000..d8e75b3e64f1 --- /dev/null +++ b/Documentation/devicetree/bindings/pinctrl/sunplus,sp7021-pinctrl.yaml @@ -0,0 +1,374 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pinctrl/sunplus,sp7021-pinctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus SP7021 Pin Controller Device Tree Bindings + +maintainers: + - Dvorkin Dmitry <dvorkin@tibbo.com> + - Wells Lu <wellslutw@gmail.com> + +description: | + The Sunplus SP7021 pin controller is used to control SoC pins. Please + refer to pinctrl-bindings.txt in this directory for details of the common + pinctrl bindings used by client devices. + + SP7021 has 99 digital GPIO pins which are numbered from GPIO 0 to 98. All + are multiplexed with some special function pins. SP7021 has 3 types of + special function pins: + + (1) function-group pins: + Ex 1 (SPI-NOR flash): + If control-field SPI_FLASH_SEL is set to 1, GPIO 83, 84, 86 and 87 + will be pins of SPI-NOR flash. If it is set to 2, GPIO 76, 78, 79 + and 81 will be pins of SPI-NOR flash. + + Ex 2 (UART_0): + If control-bit UA0_SEL is set to 1, GPIO 88 and 89 will be TX and + RX pins of UART_0 (UART channel 0). + + Ex 3 (eMMC): + If control-bit EMMC_SEL is set to 1, GPIO 72, 73, 74, 75, 76, 77, + 78, 79, 80, 81 will be pins of an eMMC device. + + Properties "function" and "groups" are used to select function-group + pins. + + (2) fully pin-mux (like phone exchange mux) pins: + GPIO 8 to 71 are 'fully pin-mux' pins. Any pins of peripherals of + SP7021 (ex: UART_1, UART_2, UART_3, UART_4, I2C_0, I2C_1, and etc.) + can be routed to any pins of fully pin-mux pins. + + Ex 1 (UART channel 1): + If control-field UA1_TX_SEL is set to 3, TX pin of UART_1 will be + routed to GPIO 10 (3 - 1 + 8 = 10). + If control-field UA1_RX_SEL is set to 4, RX pin of UART_1 will be + routed to GPIO 11 (4 - 1 + 8 = 11). + If control-field UA1_RTS_SEL is set to 5, RTS pin of UART_1 will + be routed to GPIO 12 (5 - 1 + 8 = 12). + If control-field UA1_CTS_SEL is set to 6, CTS pin of UART_1 will + be routed to GPIO 13 (6 - 1 + 8 = 13). + + Ex 2 (I2C channel 0): + If control-field I2C0_CLK_SEL is set to 20, CLK pin of I2C_0 will + be routed to GPIO 27 (20 - 1 + 8 = 27). + If control-field I2C0_DATA_SEL is set to 21, DATA pin of I2C_0 + will be routed to GPIO 28 (21 - 1 + 9 = 28). + + Totally, SP7021 has 120 peripheral pins. The peripheral pins can be + routed to any of 64 'fully pin-mux' pins. + + (3) I/O processor pins + SP7021 has a built-in I/O processor. + Any GPIO pins (GPIO 0 to 98) can be set to pins of I/O processor. + + Vendor property "sunplus,pins" is used to select "fully pin-mux" pins, + "I/O processor pins" and "digital GPIO" pins. + + The device node of pin controller of Sunplus SP7021 has following + properties. + +properties: + compatible: + const: sunplus,sp7021-pctl + + gpio-controller: true + + '#gpio-cells': + const: 2 + + reg: + items: + - description: the MOON2 registers + - description: the GPIOXT registers + - description: the FIRST registers + - description: the MOON1 registers + + reg-names: + items: + - const: moon2 + - const: gpioxt + - const: first + - const: moon1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +patternProperties: + '-pins$': + type: object + description: | + A pinctrl node should contain at least one subnodes representing the + pins or function-pins group available on the machine. Each subnode + will list the pins it needs, and how they should be configured. + + Pinctrl node's client devices use subnodes for desired pin + configuration. Client device subnodes use below standard properties. + $ref: pinmux-node.yaml# + + properties: + sunplus,pins: + description: | + Define 'sunplus,pins' which are used by pinctrl node's client + device. + + It consists of one or more integers which represents the config + setting for corresponding pin. Each integer defines a individual + pin in which: + + Bit 32~24: defines GPIO number. Its range is 0 ~ 98. + Bit 23~16: defines types: (1) fully pin-mux pins + (2) IO processor pins + (3) digital GPIO pins + Bit 15~8: defines pins of peripherals (which are defined in + 'include/dt-binging/pinctrl/sppctl.h'). + Bit 7~0: defines types or initial-state of digital GPIO pins. + + Please use macro SPPCTL_IOPAD to define the integers for pins. + + $ref: /schemas/types.yaml#/definitions/uint32-array + + function: + description: | + Define pin-function which is used by pinctrl node's client device. + The name should be one of string in the following enumeration. + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ SPI_FLASH, SPI_FLASH_4BIT, SPI_NAND, CARD0_EMMC, SD_CARD, + UA0, FPGA_IFX, HDMI_TX, LCDIF, USB0_OTG, USB1_OTG ] + + groups: + description: | + Define pin-group in a specified pin-function. + The name should be one of string in the following enumeration. + $ref: "/schemas/types.yaml#/definitions/string" + enum: [ SPI_FLASH1, SPI_FLASH2, SPI_FLASH_4BIT1, SPI_FLASH_4BIT2, + SPI_NAND, CARD0_EMMC, SD_CARD, UA0, FPGA_IFX, HDMI_TX1, + HDMI_TX2, HDMI_TX3, LCDIF, USB0_OTG, USB1_OTG ] + + sunplus,zerofunc: + description: | + This is a vendor specific property. It is used to disable pins + which are not used by pinctrl node's client device. + Some pins may be enabled by boot-loader. We can use this + property to disable them. + $ref: /schemas/types.yaml#/definitions/uint32-array + + additionalProperties: false + + allOf: + - if: + properties: + function: + enum: + - SPI_FLASH + then: + properties: + groups: + enum: + - SPI_FLASH1 + - SPI_FLASH2 + - if: + properties: + function: + enum: + - SPI_FLASH_4BIT + then: + properties: + groups: + enum: + - SPI_FLASH_4BIT1 + - SPI_FLASH_4BIT2 + - if: + properties: + function: + enum: + - SPI_NAND + then: + properties: + groups: + enum: + - SPI_NAND + - if: + properties: + function: + enum: + - CARD0_EMMC + then: + properties: + groups: + enum: + - CARD0_EMMC + - if: + properties: + function: + enum: + - SD_CARD + then: + properties: + groups: + enum: + - SD_CARD + - if: + properties: + function: + enum: + - UA0 + then: + properties: + groups: + enum: + - UA0 + - if: + properties: + function: + enum: + - FPGA_IFX + then: + properties: + groups: + enum: + - FPGA_IFX + - if: + properties: + function: + enum: + - HDMI_TX + then: + properties: + groups: + enum: + - HDMI_TX1 + - HDMI_TX2 + - HDMI_TX3 + - if: + properties: + function: + enum: + - LCDIF + then: + properties: + groups: + enum: + - LCDIF + - if: + properties: + function: + enum: + - USB0_OTG + then: + properties: + groups: + enum: + - USB0_OTG + - if: + properties: + function: + enum: + - USB1_OTG + then: + properties: + groups: + enum: + - USB1_OTG + +required: + - compatible + - reg + - reg-names + - "#gpio-cells" + - gpio-controller + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/pinctrl/sppctl-sp7021.h> + + pinctl@9c000100 { + compatible = "sunplus,sp7021-pctl"; + reg = <0x9c000100 0x100>, <0x9c000300 0x100>, + <0x9c0032e4 0x1c>, <0x9c000080 0x20>; + reg-names = "moon2", "gpioxt", "first", "moon1"; + gpio-controller; + #gpio-cells = <2>; + clocks = <&clkc 0x83>; + resets = <&rstc 0x73>; + + uart0-pins { + function = "UA0"; + groups = "UA0"; + }; + + spinand0-pins { + function = "SPI_NAND"; + groups = "SPI_NAND"; + }; + + uart1-pins { + sunplus,pins = < + SPPCTL_IOPAD(11, SPPCTL_PCTL_G_PMUX, MUXF_UA1_TX, 0) + SPPCTL_IOPAD(10, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RX, 0) + >; + }; + + uart2-pins { + sunplus,pins = < + SPPCTL_IOPAD(20, SPPCTL_PCTL_G_PMUX, MUXF_UA1_TX, 0) + SPPCTL_IOPAD(21, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RX, 0) + SPPCTL_IOPAD(22, SPPCTL_PCTL_G_PMUX, MUXF_UA1_RTS, 0) + SPPCTL_IOPAD(23, SPPCTL_PCTL_G_PMUX, MUXF_UA1_CTS, 0) + >; + }; + + emmc-pins { + function = "CARD0_EMMC"; + groups = "CARD0_EMMC"; + }; + + sdcard-pins { + function = "SD_CARD"; + groups = "SD_CARD"; + sunplus,pins = < SPPCTL_IOPAD(91, SPPCTL_PCTL_G_GPIO, 0, 0) >; + }; + + hdmi_A_tx1-pins { + function = "HDMI_TX"; + groups = "HDMI_TX1"; + }; + hdmi_A_tx2-pins { + function = "HDMI_TX"; + groups = "HDMI_TX2"; + }; + hdmi_A_tx3-pins { + function = "HDMI_TX"; + groups = "HDMI_TX3"; + }; + + ethernet-pins { + sunplus,pins = < + SPPCTL_IOPAD(49,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_CLK_OUT,0) + SPPCTL_IOPAD(44,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_MAC_SMI_MDC,0) + SPPCTL_IOPAD(43,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_MAC_SMI_MDIO,0) + SPPCTL_IOPAD(52,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXEN,0) + SPPCTL_IOPAD(50,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXD0,0) + SPPCTL_IOPAD(51,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_TXD1,0) + SPPCTL_IOPAD(46,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_CRSDV,0) + SPPCTL_IOPAD(47,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_RXD0,0) + SPPCTL_IOPAD(48,SPPCTL_PCTL_G_PMUX,MUXF_L2SW_P0_MAC_RMII_RXD1,0) + >; + sunplus,zerofunc = < + MUXF_L2SW_LED_FLASH0 + MUXF_L2SW_LED_ON0 + MUXF_L2SW_P0_MAC_RMII_RXER + >; + }; + }; +... diff --git a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml index 5dae04d2936c..7657721a4e96 100644 --- a/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml +++ b/Documentation/devicetree/bindings/power/amlogic,meson-sec-pwrc.yaml @@ -12,13 +12,14 @@ maintainers: - Jianxin Pan <jianxin.pan@amlogic.com> description: |+ - Secure Power Domains used in Meson A1/C1 SoCs, and should be the child node + Secure Power Domains used in Meson A1/C1/S4 SoCs, and should be the child node of secure-monitor. properties: compatible: enum: - amlogic,meson-a1-pwrc + - amlogic,meson-s4-pwrc "#power-domain-cells": const: 1 diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt b/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt deleted file mode 100644 index ab0d5ebbad4e..000000000000 --- a/Documentation/devicetree/bindings/power/avs/qcom,cpr.txt +++ /dev/null @@ -1,130 +0,0 @@ -QCOM CPR (Core Power Reduction) - -CPR (Core Power Reduction) is a technology to reduce core power on a CPU -or other device. Each OPP of a device corresponds to a "corner" that has -a range of valid voltages for a particular frequency. While the device is -running at a particular frequency, CPR monitors dynamic factors such as -temperature, etc. and suggests adjustments to the voltage to save power -and meet silicon characteristic requirements. - -- compatible: - Usage: required - Value type: <string> - Definition: should be "qcom,qcs404-cpr", "qcom,cpr" for qcs404 - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: base address and size of the rbcpr register region - -- interrupts: - Usage: required - Value type: <prop-encoded-array> - Definition: should specify the CPR interrupt - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: phandle to the reference clock - -- clock-names: - Usage: required - Value type: <stringlist> - Definition: must be "ref" - -- vdd-apc-supply: - Usage: required - Value type: <phandle> - Definition: phandle to the vdd-apc-supply regulator - -- #power-domain-cells: - Usage: required - Value type: <u32> - Definition: should be 0 - -- operating-points-v2: - Usage: required - Value type: <phandle> - Definition: A phandle to the OPP table containing the - performance states supported by the CPR - power domain - -- acc-syscon: - Usage: optional - Value type: <phandle> - Definition: phandle to syscon for writing ACC settings - -- nvmem-cells: - Usage: required - Value type: <phandle> - Definition: phandle to nvmem cells containing the data - that makes up a fuse corner, for each fuse corner. - As well as the CPR fuse revision. - -- nvmem-cell-names: - Usage: required - Value type: <stringlist> - Definition: should be "cpr_quotient_offset1", "cpr_quotient_offset2", - "cpr_quotient_offset3", "cpr_init_voltage1", - "cpr_init_voltage2", "cpr_init_voltage3", "cpr_quotient1", - "cpr_quotient2", "cpr_quotient3", "cpr_ring_osc1", - "cpr_ring_osc2", "cpr_ring_osc3", "cpr_fuse_revision" - for qcs404. - -Example: - - cpr_opp_table: cpr-opp-table { - compatible = "operating-points-v2-qcom-level"; - - cpr_opp1: opp1 { - opp-level = <1>; - qcom,opp-fuse-level = <1>; - }; - cpr_opp2: opp2 { - opp-level = <2>; - qcom,opp-fuse-level = <2>; - }; - cpr_opp3: opp3 { - opp-level = <3>; - qcom,opp-fuse-level = <3>; - }; - }; - - power-controller@b018000 { - compatible = "qcom,qcs404-cpr", "qcom,cpr"; - reg = <0x0b018000 0x1000>; - interrupts = <0 15 IRQ_TYPE_EDGE_RISING>; - clocks = <&xo_board>; - clock-names = "ref"; - vdd-apc-supply = <&pms405_s3>; - #power-domain-cells = <0>; - operating-points-v2 = <&cpr_opp_table>; - acc-syscon = <&tcsr>; - - nvmem-cells = <&cpr_efuse_quot_offset1>, - <&cpr_efuse_quot_offset2>, - <&cpr_efuse_quot_offset3>, - <&cpr_efuse_init_voltage1>, - <&cpr_efuse_init_voltage2>, - <&cpr_efuse_init_voltage3>, - <&cpr_efuse_quot1>, - <&cpr_efuse_quot2>, - <&cpr_efuse_quot3>, - <&cpr_efuse_ring1>, - <&cpr_efuse_ring2>, - <&cpr_efuse_ring3>, - <&cpr_efuse_revision>; - nvmem-cell-names = "cpr_quotient_offset1", - "cpr_quotient_offset2", - "cpr_quotient_offset3", - "cpr_init_voltage1", - "cpr_init_voltage2", - "cpr_init_voltage3", - "cpr_quotient1", - "cpr_quotient2", - "cpr_quotient3", - "cpr_ring_osc1", - "cpr_ring_osc2", - "cpr_ring_osc3", - "cpr_fuse_revision"; - }; diff --git a/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml new file mode 100644 index 000000000000..3301fa0c2653 --- /dev/null +++ b/Documentation/devicetree/bindings/power/avs/qcom,cpr.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/avs/qcom,cpr.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Core Power Reduction (CPR) bindings + +maintainers: + - Niklas Cassel <nks@flawful.org> + +description: | + CPR (Core Power Reduction) is a technology to reduce core power on a CPU + or other device. Each OPP of a device corresponds to a "corner" that has + a range of valid voltages for a particular frequency. While the device is + running at a particular frequency, CPR monitors dynamic factors such as + temperature, etc. and suggests adjustments to the voltage to save power + and meet silicon characteristic requirements. + +properties: + compatible: + items: + - enum: + - qcom,qcs404-cpr + - const: qcom,cpr + + reg: + description: Base address and size of the RBCPR register region. + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Reference clock. + + clock-names: + items: + - const: ref + + vdd-apc-supply: + description: APC regulator supply. + + '#power-domain-cells': + const: 0 + + operating-points-v2: + description: | + A phandle to the OPP table containing the performance states + supported by the CPR power domain. + + acc-syscon: + description: A phandle to the syscon used for writing ACC settings. + + nvmem-cells: + items: + - description: Corner 1 quotient offset + - description: Corner 2 quotient offset + - description: Corner 3 quotient offset + - description: Corner 1 initial voltage + - description: Corner 2 initial voltage + - description: Corner 3 initial voltage + - description: Corner 1 quotient + - description: Corner 2 quotient + - description: Corner 3 quotient + - description: Corner 1 ring oscillator + - description: Corner 2 ring oscillator + - description: Corner 3 ring oscillator + - description: Fuse revision + + nvmem-cell-names: + items: + - const: cpr_quotient_offset1 + - const: cpr_quotient_offset2 + - const: cpr_quotient_offset3 + - const: cpr_init_voltage1 + - const: cpr_init_voltage2 + - const: cpr_init_voltage3 + - const: cpr_quotient1 + - const: cpr_quotient2 + - const: cpr_quotient3 + - const: cpr_ring_osc1 + - const: cpr_ring_osc2 + - const: cpr_ring_osc3 + - const: cpr_fuse_revision + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - vdd-apc-supply + - '#power-domain-cells' + - operating-points-v2 + - nvmem-cells + - nvmem-cell-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + cpr_opp_table: opp-table-cpr { + compatible = "operating-points-v2-qcom-level"; + + cpr_opp1: opp1 { + opp-level = <1>; + qcom,opp-fuse-level = <1>; + }; + cpr_opp2: opp2 { + opp-level = <2>; + qcom,opp-fuse-level = <2>; + }; + cpr_opp3: opp3 { + opp-level = <3>; + qcom,opp-fuse-level = <3>; + }; + }; + + power-controller@b018000 { + compatible = "qcom,qcs404-cpr", "qcom,cpr"; + reg = <0x0b018000 0x1000>; + interrupts = <0 15 IRQ_TYPE_EDGE_RISING>; + clocks = <&xo_board>; + clock-names = "ref"; + vdd-apc-supply = <&pms405_s3>; + #power-domain-cells = <0>; + operating-points-v2 = <&cpr_opp_table>; + acc-syscon = <&tcsr>; + + nvmem-cells = <&cpr_efuse_quot_offset1>, + <&cpr_efuse_quot_offset2>, + <&cpr_efuse_quot_offset3>, + <&cpr_efuse_init_voltage1>, + <&cpr_efuse_init_voltage2>, + <&cpr_efuse_init_voltage3>, + <&cpr_efuse_quot1>, + <&cpr_efuse_quot2>, + <&cpr_efuse_quot3>, + <&cpr_efuse_ring1>, + <&cpr_efuse_ring2>, + <&cpr_efuse_ring3>, + <&cpr_efuse_revision>; + nvmem-cell-names = "cpr_quotient_offset1", + "cpr_quotient_offset2", + "cpr_quotient_offset3", + "cpr_init_voltage1", + "cpr_init_voltage2", + "cpr_init_voltage3", + "cpr_quotient1", + "cpr_quotient2", + "cpr_quotient3", + "cpr_ring_osc1", + "cpr_ring_osc2", + "cpr_ring_osc3", + "cpr_fuse_revision"; + }; diff --git a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml index 01bdda167eef..747622bdc57b 100644 --- a/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml +++ b/Documentation/devicetree/bindings/power/fsl,imx-gpcv2.yaml @@ -28,6 +28,7 @@ properties: - fsl,imx8mn-gpc - fsl,imx8mq-gpc - fsl,imx8mm-gpc + - fsl,imx8mp-gpc reg: maxItems: 1 @@ -57,6 +58,7 @@ properties: include/dt-bindings/power/imx7-power.h for fsl,imx7d-gpc and include/dt-bindings/power/imx8m-power.h for fsl,imx8mq-gpc include/dt-bindings/power/imx8mm-power.h for fsl,imx8mm-gpc + include/dt-bindings/power/imx8mp-power.h for fsl,imx8mp-gpc maxItems: 1 clocks: diff --git a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml index f234a756c193..135c6f722091 100644 --- a/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/mediatek,power-controller.yaml @@ -26,7 +26,9 @@ properties: - mediatek,mt8167-power-controller - mediatek,mt8173-power-controller - mediatek,mt8183-power-controller + - mediatek,mt8186-power-controller - mediatek,mt8192-power-controller + - mediatek,mt8195-power-controller '#power-domain-cells': const: 1 @@ -64,6 +66,7 @@ patternProperties: "include/dt-bindings/power/mt8173-power.h" - for MT8173 type power domain. "include/dt-bindings/power/mt8183-power.h" - for MT8183 type power domain. "include/dt-bindings/power/mt8192-power.h" - for MT8192 type power domain. + "include/dt-bindings/power/mt8195-power.h" - for MT8195 type power domain. maxItems: 1 clocks: diff --git a/Documentation/devicetree/bindings/power/power-domain.yaml b/Documentation/devicetree/bindings/power/power-domain.yaml index 3143ed9a3313..889091b9814f 100644 --- a/Documentation/devicetree/bindings/power/power-domain.yaml +++ b/Documentation/devicetree/bindings/power/power-domain.yaml @@ -29,6 +29,8 @@ properties: domain-idle-states: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Phandles of idle states that defines the available states for the power-domain provider. The idle state definitions are compatible with the @@ -42,6 +44,8 @@ properties: operating-points-v2: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: Phandles to the OPP tables of power domains provided by a power domain provider. If the provider provides a single power domain only or all diff --git a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml index f48bc41d81ec..940e97b565bf 100644 --- a/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml +++ b/Documentation/devicetree/bindings/power/qcom,rpmpd.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - qcom,mdm9607-rpmpd + - qcom,msm8226-rpmpd - qcom,msm8916-rpmpd - qcom,msm8939-rpmpd - qcom,msm8953-rpmpd diff --git a/Documentation/devicetree/bindings/power/renesas,apmu.yaml b/Documentation/devicetree/bindings/power/renesas,apmu.yaml index 391897d897f2..4d293b2b2f84 100644 --- a/Documentation/devicetree/bindings/power/renesas,apmu.yaml +++ b/Documentation/devicetree/bindings/power/renesas,apmu.yaml @@ -35,6 +35,8 @@ properties: cpus: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | Array of phandles pointing to CPU cores, which should match the order of CPU cores used by the WUPCR and PSTR registers in the Advanced Power diff --git a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml index 84ddc772b003..bb433e75a0ee 100644 --- a/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml +++ b/Documentation/devicetree/bindings/power/renesas,rzg2l-sysc.yaml @@ -4,14 +4,14 @@ $id: "http://devicetree.org/schemas/power/renesas,rzg2l-sysc.yaml#" $schema: "http://devicetree.org/meta-schemas/core.yaml#" -title: Renesas RZ/G2L System Controller (SYSC) +title: Renesas RZ/{G2L,V2L} System Controller (SYSC) maintainers: - Geert Uytterhoeven <geert+renesas@glider.be> description: - The RZ/G2L System Controller (SYSC) performs system control of the LSI and - supports following functions, + The RZ/{G2L,V2L} System Controller (SYSC) performs system control of the LSI + and supports following functions, - External terminal state capture function - 34-bit address space access function - Low power consumption control @@ -21,6 +21,7 @@ properties: compatible: enum: - renesas,r9a07g044-sysc # RZ/G2{L,LC} + - renesas,r9a07g054-sysc # RZ/V2L reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml index 9b9d71087466..3deb0fc8dfd3 100644 --- a/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml +++ b/Documentation/devicetree/bindings/power/rockchip,power-controller.yaml @@ -129,6 +129,8 @@ $defs: pm_qos: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | A number of phandles to qos blocks which need to be saved and restored while power domain switches state. diff --git a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml index c73abb2ff513..2dda91587dc3 100644 --- a/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml +++ b/Documentation/devicetree/bindings/power/supply/cw2015_battery.yaml @@ -14,6 +14,9 @@ description: | phandle in monitored-battery. If specified the driver uses the charge-full-design-microamp-hours property of the battery. +allOf: + - $ref: power-supply.yaml# + properties: compatible: const: cellwise,cw2015 @@ -37,9 +40,6 @@ properties: minimum: 250 power-supplies: - description: - Specifies supplies used for charging the battery connected to this gauge - $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 8 # Should be enough diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml new file mode 100644 index 000000000000..3978b48299de --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max14577.yaml @@ -0,0 +1,84 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC Charger + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for + additional information and example. + +properties: + compatible: + enum: + - maxim,max14577-charger + - maxim,max77836-charger + + maxim,constant-uvolt: + description: + Battery Constant Voltage in uV + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 4000000 + maximum: 4350000 + + maxim,eoc-uamp: + description: | + Current in uA for End-Of-Charge mode. + MAX14577: 50000-20000 + MAX77836: 5000-100000 + $ref: /schemas/types.yaml#/definitions/uint32 + + maxim,fast-charge-uamp: + description: | + Current in uA for Fast Charge + MAX14577: 90000-950000 + MAX77836: 45000-475000 + $ref: /schemas/types.yaml#/definitions/uint32 + + maxim,ovp-uvolt: + description: + OverVoltage Protection Threshold in uV; In an overvoltage condition, INT + asserts and charging stops. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [6000000, 6500000, 7000000, 7500000] + +required: + - compatible + - maxim,constant-uvolt + - maxim,eoc-uamp + - maxim,fast-charge-uamp + - maxim,ovp-uvolt + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577-charger + then: + properties: + maxim,eoc-uamp: + minimum: 50000 + maximum: 200000 + maxim,fast-charge-uamp: + minimum: 90000 + maximum: 950000 + else: + # max77836 + properties: + maxim,eoc-uamp: + minimum: 5000 + maximum: 100000 + maxim,fast-charge-uamp: + minimum: 45000 + maximum: 475000 + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml new file mode 100644 index 000000000000..a21dc1a8890f --- /dev/null +++ b/Documentation/devicetree/bindings/power/supply/maxim,max77693.yaml @@ -0,0 +1,70 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/power/supply/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC Charger + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77693-charger + + maxim,constant-microvolt: + description: | + Battery constant voltage in uV. The charger will operate in fast + charge constant current mode till battery voltage reaches this level. + Then the charger will switch to fast charge constant voltage mode. + Also vsys (system voltage) will be set to this value when DC power is + supplied but charger is not enabled. + Valid values: 3650000 - 4400000, step by 25000 (rounded down) + minimum: 3650000 + maximum: 4400000 + default: 4200000 + + maxim,min-system-microvolt: + description: | + Minimal system voltage in uV. + enum: [3000000, 3100000, 3200000, 3300000, 3400000, 3500000, + 3600000, 3700000] + default: 3600000 + + maxim,thermal-regulation-celsius: + description: | + Temperature in Celsius for entering high temperature charging mode. + If die temperature exceeds this value the charging current will be + reduced by 105 mA/Celsius. + enum: [70, 85, 100, 115] + default: 100 + + maxim,battery-overcurrent-microamp: + description: | + Overcurrent protection threshold in uA (current from battery to + system). + Valid values: 2000000 - 3500000, step by 250000 (rounded down) + minimum: 2000000 + maximum: 3500000 + default: 3500000 + + maxim,charge-input-threshold-microvolt: + description: | + Threshold voltage in uV for triggering input voltage regulation loop. + If input voltage decreases below this value, the input current will + be reduced to reach the threshold voltage. + enum: [4300000, 4700000, 4800000, 4900000] + default: 4300000 + +required: + - compatible + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/power/supply/power-supply.yaml b/Documentation/devicetree/bindings/power/supply/power-supply.yaml index 259760167759..531b67225c74 100644 --- a/Documentation/devicetree/bindings/power/supply/power-supply.yaml +++ b/Documentation/devicetree/bindings/power/supply/power-supply.yaml @@ -12,6 +12,8 @@ maintainers: properties: power-supplies: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: This property is added to a supply in order to list the devices which supply it power, referenced by their phandles. diff --git a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml index 72e8f274c791..99f506d6b0a0 100644 --- a/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml +++ b/Documentation/devicetree/bindings/power/supply/sbs,sbs-manager.yaml @@ -46,9 +46,7 @@ additionalProperties: false patternProperties: "^i2c@[1-4]$": type: object - - allOf: - - $ref: /schemas/i2c/i2c-controller.yaml# + $ref: /schemas/i2c/i2c-controller.yaml# examples: - | diff --git a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml index 54ac42a9d354..2ce408a7c0ae 100644 --- a/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml +++ b/Documentation/devicetree/bindings/power/supply/stericsson,ab8500-fg.yaml @@ -25,6 +25,11 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle deprecated: true + line-impedance-micro-ohms: + description: The line impedance between the battery and the + AB8500 inputs, to compensate for this when determining internal + resistance. + interrupts: maxItems: 5 diff --git a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml index 800d511502c4..e93e935564fb 100644 --- a/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/allwinner,sun4i-a10-pwm.yaml @@ -52,33 +52,36 @@ properties: resets: maxItems: 1 -if: - properties: - compatible: - contains: - const: allwinner,sun50i-h6-pwm - -then: - properties: - clocks: - maxItems: 2 - - clock-names: - items: - - const: mod - - const: bus - - required: - - clock-names - - resets - -else: - properties: - clocks: - maxItems: 1 + +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + const: allwinner,sun50i-h6-pwm + + then: + properties: + clocks: + maxItems: 2 + + clock-names: + items: + - const: mod + - const: bus + + required: + - clock-names + - resets + + else: + properties: + clocks: + maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml index 4080e098f746..119de3d7f9dd 100644 --- a/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/brcm,bcm7038-pwm.yaml @@ -28,7 +28,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml index 4cfbffd8414a..7ab6912a845f 100644 --- a/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/google,cros-ec-pwm.yaml @@ -16,6 +16,9 @@ description: | An EC PWM node should be only found as a sub-node of the EC node (see Documentation/devicetree/bindings/mfd/google,cros-ec.yaml). +allOf: + - $ref: pwm.yaml# + properties: compatible: const: google,cros-ec-pwm @@ -39,7 +42,7 @@ examples: compatible = "google,cros-ec-spi"; reg = <0>; - cros_ec_pwm: ec-pwm { + cros_ec_pwm: pwm { compatible = "google,cros-ec-pwm"; #pwm-cells = <1>; }; diff --git a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml index 379d693889f6..b3da4e629341 100644 --- a/Documentation/devicetree/bindings/pwm/imx-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-pwm.yaml @@ -9,6 +9,9 @@ title: Freescale i.MX PWM controller maintainers: - Philipp Zabel <p.zabel@pengutronix.de> +allOf: + - $ref: pwm.yaml# + properties: "#pwm-cells": description: | @@ -59,7 +62,6 @@ properties: maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml index fe9ef42544f1..8bef9dfeba9a 100644 --- a/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/imx-tpm-pwm.yaml @@ -13,6 +13,9 @@ description: | The TPM counter and period counter are shared between multiple channels, so all channels should use same period setting. +allOf: + - $ref: pwm.yaml# + properties: "#pwm-cells": const: 3 @@ -34,7 +37,6 @@ properties: maxItems: 1 required: - - "#pwm-cells" - compatible - reg - clocks diff --git a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml index ff6880a02ce6..ec9f6bab798c 100644 --- a/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/intel,keembay-pwm.yaml @@ -31,7 +31,6 @@ required: - compatible - reg - clocks - - '#pwm-cells' additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml index 11a606536169..59d7c4d864c1 100644 --- a/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/intel,lgm-pwm.yaml @@ -9,6 +9,9 @@ title: LGM SoC PWM fan controller maintainers: - Rahul Tanwar <rtanwar@maxlinear.com> +allOf: + - $ref: pwm.yaml# + properties: compatible: const: intel,lgm-pwm diff --git a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml index 1d7c27be50da..0a46af240d83 100644 --- a/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/iqs620a-pwm.yaml @@ -15,6 +15,9 @@ description: | Documentation/devicetree/bindings/mfd/iqs62x.yaml for further details as well as an example. +allOf: + - $ref: pwm.yaml# + properties: compatible: enum: @@ -25,7 +28,6 @@ properties: required: - compatible - - "#pwm-cells" additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml new file mode 100644 index 000000000000..a7fae1772a81 --- /dev/null +++ b/Documentation/devicetree/bindings/pwm/microchip,corepwm.yaml @@ -0,0 +1,81 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) + +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/pwm/microchip,corepwm.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip IP corePWM controller bindings + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +description: | + corePWM is an 16 channel pulse width modulator FPGA IP + + https://www.microsemi.com/existing-parts/parts/152118 + +allOf: + - $ref: pwm.yaml# + +properties: + compatible: + items: + - const: microchip,corepwm-rtl-v4 + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + "#pwm-cells": + const: 2 + + microchip,sync-update-mask: + description: | + Depending on how the IP is instantiated, there are two modes of operation. + In synchronous mode, all channels are updated at the beginning of the PWM period, + and in asynchronous mode updates happen as the control registers are written. + A 16 bit wide "SHADOW_REG_EN" parameter of the IP core controls whether synchronous + mode is possible for each channel, and is set by the bitstream programmed to the + FPGA. If the IP core is instantiated with SHADOW_REG_ENx=1, both registers that + control the duty cycle for channel x have a second "shadow"/buffer reg synthesised. + At runtime a bit wide register exposed to APB can be used to toggle on/off + synchronised mode for all channels it has been synthesised for. + Each bit of "microchip,sync-update-mask" corresponds to a PWM channel & represents + whether synchronous mode is possible for the PWM channel. + + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + microchip,dac-mode-mask: + description: | + Optional, per-channel Low Ripple DAC mode is possible on this IP core. It creates + a minimum period pulse train whose High/Low average is that of the chosen duty + cycle. This "DAC" will have far better bandwidth and ripple performance than the + standard PWM algorithm can achieve. A 16 bit DAC_MODE module parameter of the IP + core, set at instantiation and by the bitstream programmed to the FPGA, determines + whether a given channel operates in regular PWM or DAC mode. + Each bit corresponds to a PWM channel & represents whether DAC mode is enabled + for that channel. + + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + +required: + - compatible + - reg + - clocks + +additionalProperties: false + +examples: + - | + pwm@41000000 { + compatible = "microchip,corepwm-rtl-v4"; + microchip,sync-update-mask = /bits/ 32 <0>; + clocks = <&clkcfg 30>; + reg = <0x41000000 0xF0>; + #pwm-cells = <2>; + }; diff --git a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml index 8740e076061e..a34cbc13f691 100644 --- a/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/mxs-pwm.yaml @@ -10,6 +10,9 @@ maintainers: - Shawn Guo <shawnguo@kernel.org> - Anson Huang <anson.huang@nxp.com> +allOf: + - $ref: pwm.yaml# + properties: compatible: enum: @@ -28,7 +31,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - fsl,pwm-number additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt index 902b271891ae..691e58b6c223 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt +++ b/Documentation/devicetree/bindings/pwm/pwm-mtk-disp.txt @@ -6,6 +6,7 @@ Required properties: - "mediatek,mt6595-disp-pwm": found on mt6595 SoC. - "mediatek,mt8167-disp-pwm", "mediatek,mt8173-disp-pwm": found on mt8167 SoC. - "mediatek,mt8173-disp-pwm": found on mt8173 SoC. + - "mediatek,mt8183-disp-pwm": found on mt8183 SoC.$ - reg: physical base address and length of the controller's registers. - #pwm-cells: must be 2. See pwm.yaml in this directory for a description of the cell format. diff --git a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml index 81a54a4e8e3e..a336ff9364a9 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-rockchip.yaml @@ -51,42 +51,44 @@ properties: required: - compatible - reg - - "#pwm-cells" - -if: - properties: - compatible: - contains: - enum: - - rockchip,rk3328-pwm - - rockchip,rv1108-pwm - -then: - properties: - clocks: - items: - - description: Used to derive the functional clock for the device. - - description: Used as the APB bus clock. - - clock-names: - items: - - const: pwm - - const: pclk - - required: - - clocks - - clock-names - -else: - properties: - clocks: - maxItems: 1 - description: - Used both to derive the functional clock - for the device and as the bus clock. - - required: - - clocks + +allOf: + - $ref: pwm.yaml# + + - if: + properties: + compatible: + contains: + enum: + - rockchip,rk3328-pwm + - rockchip,rv1108-pwm + + then: + properties: + clocks: + items: + - description: Used to derive the functional clock for the device. + - description: Used as the APB bus clock. + + clock-names: + items: + - const: pwm + - const: pclk + + required: + - clocks + - clock-names + + else: + properties: + clocks: + maxItems: 1 + description: + Used both to derive the functional clock + for the device and as the bus clock. + + required: + - clocks additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml index 188679cb8b8c..fe603fb1b2cc 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-samsung.yaml @@ -86,7 +86,6 @@ required: - clocks - clock-names - compatible - - "#pwm-cells" - reg additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml index 84e66913d042..605c1766dba8 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-sifive.yaml @@ -8,7 +8,6 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: SiFive PWM controller maintainers: - - Yash Shah <yash.shah@sifive.com> - Sagar Kadam <sagar.kadam@sifive.com> - Paul Walmsley <paul.walmsley@sifive.com> @@ -22,6 +21,9 @@ description: https://github.com/sifive/sifive-blocks/tree/master/src/main/scala/devices/pwm +allOf: + - $ref: pwm.yaml# + properties: compatible: items: @@ -55,7 +57,6 @@ required: - compatible - reg - clocks - - "#pwm-cells" - interrupts additionalProperties: false diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml index ed35b6cc48d5..3840ae709bc6 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiecap.yaml @@ -47,7 +47,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names diff --git a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml index ee312cb210e6..70a8f766212e 100644 --- a/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml +++ b/Documentation/devicetree/bindings/pwm/pwm-tiehrpwm.yaml @@ -48,7 +48,6 @@ properties: required: - compatible - reg - - "#pwm-cells" - clocks - clock-names diff --git a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml index 7ea1070b4b3a..1c94acbc2b4a 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,pwm-rcar.yaml @@ -59,21 +59,23 @@ properties: required: - compatible - reg - - '#pwm-cells' - clocks - power-domains -if: - not: - properties: - compatible: - contains: - enum: - - renesas,pwm-r8a7778 - - renesas,pwm-r8a7779 -then: - required: - - resets +allOf: + - $ref: pwm.yaml# + + - 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 1f5c6384182e..c6b2ab56b7fe 100644 --- a/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml +++ b/Documentation/devicetree/bindings/pwm/renesas,tpu-pwm.yaml @@ -68,7 +68,6 @@ properties: required: - compatible - reg - - '#pwm-cells' - clocks - power-domains diff --git a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml index d350f5edfb67..46622661e5fb 100644 --- a/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml +++ b/Documentation/devicetree/bindings/pwm/toshiba,pwm-visconti.yaml @@ -9,6 +9,9 @@ title: Toshiba Visconti PWM Controller maintainers: - Nobuhiro Iwamatsu <nobuhiro1.iwamatsu@toshiba.co.jp> +allOf: + - $ref: pwm.yaml# + properties: compatible: items: @@ -23,7 +26,6 @@ properties: required: - compatible - reg - - '#pwm-cells' additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/max77802.txt b/Documentation/devicetree/bindings/regulator/max77802.txt deleted file mode 100644 index b82943d83677..000000000000 --- a/Documentation/devicetree/bindings/regulator/max77802.txt +++ /dev/null @@ -1,111 +0,0 @@ -Binding for Maxim MAX77802 regulators - -This is a part of device tree bindings of MAX77802 multi-function device. -More information can be found in bindings/mfd/max77802.txt file. - -The MAX77802 PMIC has 10 high-efficiency Buck and 32 Low-dropout (LDO) -regulators that can be controlled over I2C. - -Following properties should be present in main device node of the MFD chip. - -Optional properties: -- inb1-supply: The input supply for BUCK1 -- inb2-supply: The input supply for BUCK2 -- inb3-supply: The input supply for BUCK3 -- inb4-supply: The input supply for BUCK4 -- inb5-supply: The input supply for BUCK5 -- inb6-supply: The input supply for BUCK6 -- inb7-supply: The input supply for BUCK7 -- inb8-supply: The input supply for BUCK8 -- inb9-supply: The input supply for BUCK9 -- inb10-supply: The input supply for BUCK10 -- inl1-supply: The input supply for LDO8 and LDO15 -- inl2-supply: The input supply for LDO17, LDO27, LDO30 and LDO35 -- inl3-supply: The input supply for LDO3, LDO5, LDO6 and LDO7 -- inl4-supply: The input supply for LDO10, LDO11, LDO13 and LDO14 -- inl5-supply: The input supply for LDO9 and LDO19 -- inl6-supply: The input supply for LDO4, LDO21, LDO24 and LDO33 -- inl7-supply: The input supply for LDO18, LDO20, LDO28 and LDO29 -- inl9-supply: The input supply for LDO12, LDO23, LDO25, LDO26, LDO32 and LDO34 -- inl10-supply: The input supply for LDO1 and LDO2 - -Optional nodes: -- regulators : The regulators of max77802 have to be instantiated - under subnode named "regulators" using the following format. - - regulator-name { - standard regulator constraints.... - }; - refer Documentation/devicetree/bindings/regulator/regulator.txt - -The regulator node name should be initialized with a string to get matched -with their hardware counterparts as follow. The valid names are: - - -LDOn : for LDOs, where n can lie in ranges 1-15, 17-21, 23-30 - and 32-35. - example: LDO1, LDO2, LDO35. - -BUCKn : for BUCKs, where n can lie in range 1 to 10. - example: BUCK1, BUCK5, BUCK10. - -The max77802 regulator supports two different operating modes: Normal and Low -Power Mode. Some regulators support the modes to be changed at startup or by -the consumers during normal operation while others only support to change the -mode during system suspend. The standard regulator suspend states binding can -be used to configure the regulator operating mode. - -The regulators that support the standard "regulator-initial-mode" property, -changing their mode during normal operation are: LDOs 1, 3, 20 and 21. - -The possible values for "regulator-initial-mode" and "regulator-mode" are: - 1: Normal regulator voltage output mode. - 3: Low Power which reduces the quiescent current down to only 1uA - -The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h -header and can be included by device tree source files. - -The standard "regulator-mode" property can only be used for regulators that -support changing their mode to Low Power Mode during suspend. These regulators -are: BUCKs 2-4 and LDOs 1-35. Also, it only takes effect if the regulator has -been enabled for the given suspend state using "regulator-on-in-suspend" and -has not been disabled for that state using "regulator-off-in-suspend". - -Example: - - max77802@9 { - compatible = "maxim,max77802"; - interrupt-parent = <&wakeup_eint>; - interrupts = <26 0>; - reg = <0x09>; - #address-cells = <1>; - #size-cells = <0>; - - inb1-supply = <&parent_reg>; - - regulators { - ldo1_reg: LDO1 { - regulator-name = "vdd_1v0"; - regulator-min-microvolt = <1000000>; - regulator-max-microvolt = <1000000>; - regulator-always-on; - regulator-initial-mode = <MAX77802_OPMODE_LP>; - }; - - ldo11_reg: LDO11 { - regulator-name = "vdd_ldo11"; - regulator-min-microvolt = <1900000>; - regulator-max-microvolt = <1900000>; - regulator-always-on; - regulator-state-mem { - regulator-on-in-suspend; - regulator-mode = <MAX77802_OPMODE_LP>; - }; - }; - - buck1_reg: BUCK1 { - regulator-name = "vdd_mif"; - regulator-min-microvolt = <950000>; - regulator-max-microvolt = <1300000>; - regulator-always-on; - regulator-boot-on; - }; - }; diff --git a/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml new file mode 100644 index 000000000000..16f01886a601 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max14577.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max14577.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX14577/MAX77836 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX14577/MAX77836 MicroUSB + Integrated Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max14577.yaml for + additional information and example. + +properties: + compatible: + enum: + - maxim,max14577-regulator + - maxim,max77836-regulator + + CHARGER: + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Current regulator. + + properties: + regulator-min-microvolt: false + regulator-max-microvolt: false + + SAFEOUT: + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Safeout LDO regulator (fixed voltage). + + properties: + regulator-min-microamp: false + regulator-max-microamp: false + regulator-min-microvolt: + const: 4900000 + regulator-max-microvolt: + const: 4900000 + +patternProperties: + "^LDO[12]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: | + Current regulator. + + properties: + regulator-min-microamp: false + regulator-max-microamp: false + regulator-min-microvolt: + minimum: 800000 + regulator-max-microvolt: + maximum: 3950000 + +allOf: + - if: + properties: + compatible: + contains: + const: maxim,max14577-regulator + then: + properties: + LDO1: false + LDO2: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml new file mode 100644 index 000000000000..20d8559bdc2b --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77693.yaml @@ -0,0 +1,60 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77693.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77693 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Chanwoo Choi <cw00.choi@samsung.com> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77693 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77693.yaml for + additional information and example. + +properties: + CHARGER: + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Current regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microamp: + minimum: 60000 + regulator-max-microamp: + maximum: 2580000 + + required: + - regulator-name + +patternProperties: + "^ESAFEOUT[12]$": + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Safeout LDO regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microvolt: + minimum: 3300000 + regulator-max-microvolt: + maximum: 4950000 + + required: + - regulator-name + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml new file mode 100644 index 000000000000..f2b4dd15a0f3 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77802.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77802.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77802 Power Management IC regulators + +maintainers: + - Javier Martinez Canillas <javier@dowhile0.org> + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77802 Power Management + Integrated Circuit (PMIC). + + The Maxim MAX77686 provides 10 high-efficiency Buck and 32 Low-DropOut (LDO) + regulators. + + See also Documentation/devicetree/bindings/mfd/maxim,max77802.yaml for + additional information and example. + + Certain regulators support "regulator-initial-mode" and "regulator-mode". + The valid modes list is defined in the dt-bindings/regulator/maxim,max77802.h + and their meaning is:: + 1 - Normal regulator voltage output mode. + 3 - Low Power which reduces the quiescent current down to only 1uA + + The standard "regulator-mode" property can only be used for regulators that + support changing their mode to Low Power Mode during suspend. These + regulators are:: bucks 2-4 and LDOs 1-35. Also, it only takes effect if the + regulator has been enabled for the given suspend state using + "regulator-on-in-suspend" and has not been disabled for that state using + "regulator-off-in-suspend". + +patternProperties: + # LDO1, LDO3, LDO20, LDO21 + "^LDO([13]|2[01])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + LDOs supporting the regulator-initial-mode property and changing their + mode during normal operation. + + # LDO2, LDO4-15, LDO17-19, LDO23-30, LDO32-35 + "^LDO([24-9]|1[0-5789]|2[3-9]|3[02345])$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + LDOs supporting the regulator-mode property (changing mode to Low Power + Mode during suspend). + + properties: + regulator-initial-mode: false + + # buck2-4 + "^BUCK[2-4]$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + description: + bucks supporting the regulator-mode property (changing mode to Low Power + Mode during suspend). + + properties: + regulator-initial-mode: false + + # buck1, buck5-10 + "^BUCK([15-9]|10)$": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + properties: + regulator-initial-mode: false + + patternProperties: + regulator-state-(standby|mem|disk): + type: object + properties: + regulator-mode: false + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml new file mode 100644 index 000000000000..a963025e96c1 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/maxim,max77843.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/maxim,max77843.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Maxim MAX77843 MicroUSB and Companion Power Management IC regulators + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + This is a part of device tree bindings for Maxim MAX77843 MicroUSB Integrated + Circuit (MUIC). + + See also Documentation/devicetree/bindings/mfd/maxim,max77843.yaml for + additional information and example. + +properties: + compatible: + const: maxim,max77843-regulator + + CHARGER: + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Current regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microamp: + minimum: 100000 + regulator-max-microamp: + maximum: 3150000 + + required: + - regulator-name + +patternProperties: + "^SAFEOUT[12]$": + type: object + $ref: regulator.yaml# + additionalProperties: false + description: | + Safeout LDO regulator. + + properties: + regulator-name: true + regulator-always-on: true + regulator-boot-on: true + regulator-min-microvolt: + minimum: 3300000 + regulator-max-microvolt: + maximum: 4950000 + + required: + - regulator-name + +required: + - compatible + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml index 35c53e27f78c..5898dcf10f06 100644 --- a/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml +++ b/Documentation/devicetree/bindings/regulator/maxim,max8973.yaml @@ -113,7 +113,7 @@ examples: }; - | - #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> i2c { @@ -123,8 +123,7 @@ examples: regulator@1b { compatible = "maxim,max77621"; reg = <0x1b>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(Y, 1) IRQ_TYPE_LEVEL_LOW>; + interrupts = <1 IRQ_TYPE_LEVEL_LOW>; regulator-always-on; regulator-boot-on; diff --git a/Documentation/devicetree/bindings/regulator/pfuze100.yaml b/Documentation/devicetree/bindings/regulator/pfuze100.yaml index f578e72778a7..a26bbd68b729 100644 --- a/Documentation/devicetree/bindings/regulator/pfuze100.yaml +++ b/Documentation/devicetree/bindings/regulator/pfuze100.yaml @@ -70,7 +70,11 @@ properties: $ref: "regulator.yaml#" type: object - "^(vsnvs|vref|vrefddr|swbst|coin)$": + "^vldo[1-4]$": + $ref: "regulator.yaml#" + type: object + + "^(vsnvs|vref|vrefddr|swbst|coin|v33|vccsd)$": $ref: "regulator.yaml#" type: object diff --git a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml index 5c73d3f639c7..e28ee9e46788 100644 --- a/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/qcom,rpmh-regulator.yaml @@ -48,6 +48,7 @@ description: | For PMI8998, bob For PMR735A, smps1 - smps3, ldo1 - ldo7 For PMX55, smps1 - smps7, ldo1 - ldo16 + For PMX65, smps1 - smps8, ldo1 - ldo21 properties: compatible: @@ -70,6 +71,7 @@ properties: - qcom,pmm8155au-rpmh-regulators - qcom,pmr735a-rpmh-regulators - qcom,pmx55-rpmh-regulators + - qcom,pmx65-rpmh-regulators qcom,pmic-id: description: | diff --git a/Documentation/devicetree/bindings/regulator/regulator.yaml b/Documentation/devicetree/bindings/regulator/regulator.yaml index ed560ee8714e..a9b66ececccf 100644 --- a/Documentation/devicetree/bindings/regulator/regulator.yaml +++ b/Documentation/devicetree/bindings/regulator/regulator.yaml @@ -213,6 +213,8 @@ properties: is 2-way - all coupled regulators should be linked with each other. A regulator should not be coupled with its supplier. $ref: "/schemas/types.yaml#/definitions/phandle-array" + items: + maxItems: 1 regulator-coupled-max-spread: description: Array of maximum spread between voltages of coupled regulators diff --git a/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml new file mode 100644 index 000000000000..28725c5467fc --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/richtek,rt5190a-regulator.yaml @@ -0,0 +1,141 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/richtek,rt5190a-regulator.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Richtek RT5190A PMIC Regulator + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT5190A integrates 1 channel buck controller, 3 channels high efficiency + synchronous buck converters, 1 LDO, I2C control interface and peripherial + logical control. + + It also supports mute AC OFF depop sound and quick setting storage while + input power is removed. + +properties: + compatible: + enum: + - richtek,rt5190a + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + vin2-supply: + description: phandle to buck2 input voltage. + + vin3-supply: + description: phandle to buck3 input voltage. + + vin4-supply: + description: phandle to buck4 input voltage. + + vinldo-supply: + description: phandle to ldo input voltage + + richtek,mute-enable: + description: | + The mute function uses 'mutein', 'muteout', and 'vdet' pins as the control + signal. When enabled, The normal behavior is to bypass the 'mutein' signal + 'muteout'. But if the power source removal is detected from 'vdet', + whatever the 'mutein' signal is, it will pull down the 'muteout' to force + speakers mute. this function is commonly used to prevent the speaker pop + noise during AC power turned off in the modern TV system design. + type: boolean + + regulators: + type: object + + patternProperties: + "^buck[1-4]$|^ldo$": + type: object + $ref: regulator.yaml# + description: | + regulator description for buck1 and buck4. + + properties: + regulator-allowed-modes: + description: | + buck operating mode, only buck1/4 support mode operating. + 0: auto mode + 1: force pwm mode + items: + enum: [0, 1] + + richtek,latchup-enable: + type: boolean + description: | + If specified, undervolt protection mode changes from the default + hiccup to latchup. + + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/regulator/richtek,rt5190a-regulator.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + pmic@64 { + compatible = "richtek,rt5190a"; + reg = <0x64>; + interrupts-extended = <&gpio26 0 IRQ_TYPE_LEVEL_LOW>; + vin2-supply = <&rt5190_buck1>; + vin3-supply = <&rt5190_buck1>; + vin4-supply = <&rt5190_buck1>; + + regulators { + rt5190_buck1: buck1 { + regulator-name = "rt5190a-buck1"; + regulator-min-microvolt = <5090000>; + regulator-max-microvolt = <5090000>; + regulator-allowed-modes = <RT5190A_OPMODE_AUTO RT5190A_OPMODE_FPWM>; + regulator-boot-on; + }; + buck2 { + regulator-name = "rt5190a-buck2"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + }; + buck3 { + regulator-name = "rt5190a-buck3"; + regulator-min-microvolt = <600000>; + regulator-max-microvolt = <1400000>; + regulator-boot-on; + }; + buck4 { + regulator-name = "rt5190a-buck4"; + regulator-min-microvolt = <850000>; + regulator-max-microvolt = <850000>; + regulator-allowed-modes = <RT5190A_OPMODE_AUTO RT5190A_OPMODE_FPWM>; + regulator-boot-on; + }; + ldo { + regulator-name = "rt5190a-ldo"; + regulator-min-microvolt = <1200000>; + regulator-max-microvolt = <1200000>; + regulator-boot-on; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml index df0191b1ceba..38bdaef4fa39 100644 --- a/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml +++ b/Documentation/devicetree/bindings/regulator/st,stm32-booster.yaml @@ -23,7 +23,7 @@ properties: - st,stm32mp1-booster st,syscfg: - $ref: "/schemas/types.yaml#/definitions/phandle-array" + $ref: "/schemas/types.yaml#/definitions/phandle" description: phandle to system configuration controller. vdda-supply: diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml new file mode 100644 index 000000000000..12aeddedde05 --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps62360.yaml @@ -0,0 +1,98 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps62360.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Texas Instruments TPS6236x Voltage Regulators + +maintainers: + - Laxman Dewangan <ldewangan@nvidia.com> + +description: | + The TPS6236x are a family of step down dc-dc converter with + an input voltage range of 2.5V to 5.5V. The devices provide + up to 3A peak load current, and an output voltage range of + 0.77V to 1.4V (TPS62360/62) and 0.5V to 1.77V (TPS62361B/63). + + Datasheet is available at: + https://www.ti.com/lit/gpn/tps62360 + +allOf: + - $ref: "regulator.yaml#" + +properties: + compatible: + enum: + - ti,tps62360 + - ti,tps62361 + - ti,tps62362 + - ti,tps62363 + + reg: + maxItems: 1 + + ti,vsel0-gpio: + description: | + GPIO for controlling VSEL0 line. If this property + is missing, then assume that there is no GPIO for + VSEL0 control. + maxItems: 1 + + ti,vsel1-gpio: + description: | + GPIO for controlling VSEL1 line. If this property + is missing, then assume that there is no GPIO for + VSEL1 control. + maxItems: 1 + + ti,enable-vout-discharge: + description: Enable output discharge. + type: boolean + + ti,enable-pull-down: + description: Enable pull down. + type: boolean + + ti,vsel0-state-high: + description: | + Initial state of VSEL0 input is high. If this property + is missing, then assume the state as low. + type: boolean + + ti,vsel1-state-high: + description: | + Initial state of VSEL1 input is high. If this property + is missing, then assume the state as low. + type: boolean + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@60 { + compatible = "ti,tps62361"; + reg = <0x60>; + regulator-name = "tps62361-vout"; + regulator-min-microvolt = <500000>; + regulator-max-microvolt = <1500000>; + regulator-boot-on; + ti,vsel0-gpio = <&gpio1 16 GPIO_ACTIVE_HIGH>; + ti,vsel1-gpio = <&gpio1 17 GPIO_ACTIVE_HIGH>; + ti,vsel0-state-high; + ti,vsel1-state-high; + ti,enable-pull-down; + ti,enable-vout-discharge; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml new file mode 100644 index 000000000000..0f29c75f42ea --- /dev/null +++ b/Documentation/devicetree/bindings/regulator/ti,tps62864.yaml @@ -0,0 +1,63 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/regulator/ti,tps62864.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TI TPS62864/TPS6286/TPS62868/TPS62869 voltage regulator + +maintainers: + - Vincent Whitchurch <vincent.whitchurch@axis.com> + +properties: + compatible: + enum: + - ti,tps62864 + - ti,tps62866 + - ti,tps62868 + - ti,tps62869 + + reg: + maxItems: 1 + + regulators: + type: object + + properties: + "SW": + type: object + $ref: regulator.yaml# + unevaluatedProperties: false + + additionalProperties: false + +required: + - compatible + - reg + - regulators + +additionalProperties: false + +examples: + - | + #include <dt-bindings/regulator/ti,tps62864.h> + i2c { + #address-cells = <1>; + #size-cells = <0>; + + regulator@48 { + compatible = "ti,tps62864"; + reg = <0x48>; + + regulators { + SW { + regulator-name = "+0.85V"; + regulator-min-microvolt = <800000>; + regulator-max-microvolt = <890000>; + regulator-initial-mode = <TPS62864_MODE_FPWM>; + }; + }; + }; + }; + +... diff --git a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt b/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt deleted file mode 100644 index 1b20c3dbcdb8..000000000000 --- a/Documentation/devicetree/bindings/regulator/tps62360-regulator.txt +++ /dev/null @@ -1,44 +0,0 @@ -TPS62360 Voltage regulators - -Required properties: -- compatible: Must be one of the following. - "ti,tps62360" - "ti,tps62361", - "ti,tps62362", - "ti,tps62363", -- reg: I2C slave address - -Optional properties: -- ti,enable-vout-discharge: Enable output discharge. This is boolean value. -- ti,enable-pull-down: Enable pull down. This is boolean value. -- ti,vsel0-gpio: GPIO for controlling VSEL0 line. - If this property is missing, then assume that there is no GPIO - for vsel0 control. -- ti,vsel1-gpio: Gpio for controlling VSEL1 line. - If this property is missing, then assume that there is no GPIO - for vsel1 control. -- ti,vsel0-state-high: Initial state of vsel0 input is high. - If this property is missing, then assume the state as low (0). -- ti,vsel1-state-high: Initial state of vsel1 input is high. - If this property is missing, then assume the state as low (0). - -Any property defined as part of the core regulator binding, defined in -regulator.txt, can also be used. - -Example: - - abc: tps62360 { - compatible = "ti,tps62361"; - reg = <0x60>; - regulator-name = "tps62361-vout"; - regulator-min-microvolt = <500000>; - regulator-max-microvolt = <1500000>; - regulator-boot-on - ti,vsel0-gpio = <&gpio1 16 0>; - ti,vsel1-gpio = <&gpio1 17 0>; - ti,vsel0-state-high; - ti,vsel1-state-high; - ti,enable-pull-down; - ti,enable-force-pwm; - ti,enable-vout-discharge; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml index d21a25ee96e6..5b693a2d049c 100644 --- a/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/mtk,scp.yaml @@ -17,6 +17,7 @@ properties: compatible: enum: - mediatek,mt8183-scp + - mediatek,mt8186-scp - mediatek,mt8192-scp - mediatek,mt8195-scp diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml index c635c181d2c2..a4409c398193 100644 --- a/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml +++ b/Documentation/devicetree/bindings/remoteproc/qcom,adsp.yaml @@ -47,6 +47,10 @@ properties: - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-mpss-pas + - qcom,sm8450-slpi-pas reg: maxItems: 1 @@ -115,6 +119,12 @@ properties: qcom,halt-regs: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle reference to a syscon representing TCSR + - description: offsets within syscon for q6 halt registers + - description: offsets within syscon for modem halt registers + - description: offsets within syscon for nc halt registers description: Phandle reference to a syscon representing TCSR followed by the three offsets within syscon for q6, modem and nc halt registers. @@ -175,6 +185,10 @@ allOf: - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas + - qcom,sm8450-mpss-pas then: properties: clocks: @@ -283,6 +297,9 @@ allOf: - qcom,sm8350-adsp-pas - qcom,sm8350-cdsp-pas - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-cdsp-pas + - qcom,sm8450-slpi-pas then: properties: interrupts: @@ -312,6 +329,7 @@ allOf: - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-mpss-pas then: properties: interrupts: @@ -434,6 +452,7 @@ allOf: - qcom,sm6350-mpss-pas - qcom,sm8150-mpss-pas - qcom,sm8350-mpss-pas + - qcom,sm8450-mpss-pas then: properties: power-domains: @@ -458,6 +477,8 @@ allOf: - qcom,sm8250-slpi-pas - qcom,sm8350-adsp-pas - qcom,sm8350-slpi-pas + - qcom,sm8450-adsp-pas + - qcom,sm8450-slpi-pas then: properties: power-domains: @@ -475,6 +496,7 @@ allOf: contains: enum: - qcom,sm8350-cdsp-pas + - qcom,sm8450-cdsp-pas then: properties: power-domains: diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt b/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt deleted file mode 100644 index 1337a3d93d35..000000000000 --- a/Documentation/devicetree/bindings/remoteproc/qcom,hexagon-v56.txt +++ /dev/null @@ -1,140 +0,0 @@ -Qualcomm Technology Inc. Hexagon v56 Peripheral Image Loader - -This document defines the binding for a component that loads and boots firmware -on the Qualcomm Technology Inc. Hexagon v56 core. - -- compatible: - Usage: required - Value type: <string> - Definition: must be one of: - "qcom,qcs404-cdsp-pil", - "qcom,sdm845-adsp-pil" - -- reg: - Usage: required - Value type: <prop-encoded-array> - Definition: must specify the base address and size of the qdsp6ss register - -- interrupts-extended: - Usage: required - Value type: <prop-encoded-array> - Definition: must list the watchdog, fatal IRQs ready, handover and - stop-ack IRQs - -- interrupt-names: - Usage: required - Value type: <stringlist> - Definition: must be "wdog", "fatal", "ready", "handover", "stop-ack" - -- clocks: - Usage: required - Value type: <prop-encoded-array> - Definition: List of phandles and clock specifier pairs for the Hexagon, - per clock-names below. - -- clock-names: - Usage: required for SDM845 ADSP - Value type: <stringlist> - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway_cbcr", "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", "qdsp6ss_sleep" - and "qdsp6ss_core". - -- clock-names: - Usage: required for QCS404 CDSP - Value type: <stringlist> - Definition: List of clock input name strings sorted in the same - order as the clocks property. Definition must have - "xo", "sway", "tbu", "bimc", "ahb_aon", "q6ss_slave", - "q6ss_master", "q6_axim". - -- power-domains: - Usage: required - Value type: <phandle> - Definition: reference to cx power domain node. - -- resets: - Usage: required - Value type: <phandle> - Definition: reference to the list of resets for the Hexagon. - -- reset-names: - Usage: required for SDM845 ADSP - Value type: <stringlist> - Definition: must be "pdc_sync" and "cc_lpass" - -- reset-names: - Usage: required for QCS404 CDSP - Value type: <stringlist> - Definition: must be "restart" - -- qcom,halt-regs: - Usage: required - Value type: <prop-encoded-array> - Definition: a phandle reference to a syscon representing TCSR followed - by the offset within syscon for Hexagon halt register. - -- memory-region: - Usage: required - Value type: <phandle> - Definition: reference to the reserved-memory for the firmware - -- qcom,smem-states: - Usage: required - Value type: <phandle> - Definition: reference to the smem state for requesting the Hexagon 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 "glink-edge" that describes the -communication edge, channels and devices related to the Hexagon. -See ../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 SDM845 boards. - - remoteproc@17300000 { - compatible = "qcom,sdm845-adsp-pil"; - reg = <0x17300000 0x40c>; - - interrupts-extended = <&intc GIC_SPI 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 = <&rpmhcc RPMH_CXO_CLK>, - <&gcc GCC_LPASS_SWAY_CLK>, - <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, - <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, - <&lpasscc LPASS_QDSP6SS_XO_CLK>, - <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, - <&lpasscc LPASS_QDSP6SS_CORE_CLK>; - clock-names = "xo", "sway_cbcr", - "lpass_ahbs_aon_cbcr", - "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", - "qdsp6ss_sleep", "qdsp6ss_core"; - - power-domains = <&rpmhpd SDM845_CX>; - - resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, - <&aoss_reset AOSS_CC_LPASS_RESTART>; - reset-names = "pdc_sync", "cc_lpass"; - - qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; - - memory-region = <&pil_adsp_mem>; - - qcom,smem-states = <&adsp_smp2p_out 0>; - qcom,smem-state-names = "stop"; - }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml new file mode 100644 index 000000000000..31413cfe10db --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,qcs404-cdsp-pil.yaml @@ -0,0 +1,161 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,qcs404-cdsp-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm QCS404 CDSP Peripheral Image Loader + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. CDSP (Compute DSP). + +properties: + compatible: + enum: + - qcom,qcs404-cdsp-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + 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 + + 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 + + power-domains: + items: + - description: CX power domain + + resets: + items: + - description: AOSS restart + + reset-names: + items: + - const: restart + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + 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. + + 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 + description: The names of the state bits used for SMP2P output + items: + - const: stop + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-qcs404.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/clock/qcom,turingcc-qcs404.h> + remoteproc@b00000 { + compatible = "qcom,qcs404-cdsp-pil"; + reg = <0x00b00000 0x4040>; + + interrupts-extended = <&intc GIC_SPI 229 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&cdsp_smp2p_in 3 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", + "handover", "stop-ack"; + + clocks = <&xo_board>, + <&gcc GCC_CDSP_CFG_AHB_CLK>, + <&gcc GCC_CDSP_TBU_CLK>, + <&gcc GCC_BIMC_CDSP_CLK>, + <&turingcc TURING_WRAPPER_AON_CLK>, + <&turingcc TURING_Q6SS_AHBS_AON_CLK>, + <&turingcc TURING_Q6SS_AHBM_AON_CLK>, + <&turingcc TURING_Q6SS_Q6_AXIM_CLK>; + clock-names = "xo", + "sway", + "tbu", + "bimc", + "ahb_aon", + "q6ss_slave", + "q6ss_master", + "q6_axim"; + + power-domains = <&rpmhpd SDM845_CX>; + + resets = <&gcc GCC_CDSP_RESTART>; + reset-names = "restart"; + + qcom,halt-regs = <&tcsr 0x19004>; + + memory-region = <&cdsp_fw_mem>; + + qcom,smem-states = <&cdsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml new file mode 100644 index 000000000000..2424de733ee4 --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sc7280-wpss-pil.yaml @@ -0,0 +1,219 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sc7280-wpss-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SC7280 WPSS Peripheral Image Loader + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. WPSS. + +properties: + compatible: + enum: + - qcom,sc7280-wpss-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + 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 + + clocks: + items: + - description: GCC WPSS AHB BDG Master clock + - description: GCC WPSS AHB clock + - description: GCC WPSS RSCP clock + - description: XO clock + + clock-names: + items: + - const: ahb_bdg + - const: ahb + - const: rscp + - const: xo + + power-domains: + items: + - description: CX power domain + - description: MX power domain + + power-domain-names: + items: + - const: cx + - const: mx + + resets: + items: + - description: AOSS restart + - description: PDC SYNC + + reset-names: + items: + - const: restart + - const: pdc_sync + + memory-region: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the reserved-memory for the Hexagon core + + firmware-name: + $ref: /schemas/types.yaml#/definitions/string + description: + The name of the firmware which should be loaded for this remote + processor. + + 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. + + qcom,qmp: + $ref: /schemas/types.yaml#/definitions/phandle + description: Reference to the AOSS side-channel message RAM. + + 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 + description: The names of the state bits used for SMP2P output + items: + - const: stop + + glink-edge: + type: object + description: | + Qualcomm G-Link subnode which represents communication edge, channels + and devices related to the ADSP. + + properties: + interrupts: + items: + - description: IRQ from WPSS to GLINK + + mboxes: + items: + - description: Mailbox for communication between APPS and WPSS + + label: + description: The names of the state bits used for SMP2P output + items: + - const: wpss + + qcom,remote-pid: + $ref: /schemas/types.yaml#/definitions/uint32 + description: ID of the shared memory used by GLINK for communication with WPSS + maxItems: 1 + + required: + - interrupts + - mboxes + - label + - qcom,remote-pid + + additionalProperties: false + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - power-domain-names + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,qmp + - qcom,smem-states + - qcom,smem-state-names + - glink-edge + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,gcc-sc7280.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + #include <dt-bindings/mailbox/qcom-ipcc.h> + remoteproc@8a00000 { + compatible = "qcom,sc7280-wpss-pil"; + reg = <0x08a00000 0x10000>; + + interrupts-extended = <&intc GIC_SPI 587 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 0 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 1 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 2 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 3 IRQ_TYPE_EDGE_RISING>, + <&wpss_smp2p_in 7 IRQ_TYPE_EDGE_RISING>; + interrupt-names = "wdog", "fatal", "ready", "handover", + "stop-ack", "shutdown-ack"; + + clocks = <&gcc GCC_WPSS_AHB_BDG_MST_CLK>, + <&gcc GCC_WPSS_AHB_CLK>, + <&gcc GCC_WPSS_RSCP_CLK>, + <&rpmhcc RPMH_CXO_CLK>; + clock-names = "ahb_bdg", "ahb", + "rscp", "xo"; + + power-domains = <&rpmhpd SC7280_CX>, + <&rpmhpd SC7280_MX>; + power-domain-names = "cx", "mx"; + + memory-region = <&wpss_mem>; + + qcom,qmp = <&aoss_qmp>; + + qcom,smem-states = <&wpss_smp2p_out 0>; + qcom,smem-state-names = "stop"; + + resets = <&aoss_reset AOSS_CC_WCSS_RESTART>, + <&pdc_reset PDC_WPSS_SYNC_RESET>; + reset-names = "restart", "pdc_sync"; + + qcom,halt-regs = <&tcsr_mutex 0x37000>; + + glink-edge { + interrupts-extended = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP + IRQ_TYPE_EDGE_RISING>; + mboxes = <&ipcc IPCC_CLIENT_WPSS + IPCC_MPROC_SIGNAL_GLINK_QMP>; + + label = "wpss"; + qcom,remote-pid = <13>; + }; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml new file mode 100644 index 000000000000..1535bbbe25da --- /dev/null +++ b/Documentation/devicetree/bindings/remoteproc/qcom,sdm845-adsp-pil.yaml @@ -0,0 +1,160 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/remoteproc/qcom,sdm845-adsp-pil.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm SDM845 ADSP Peripheral Image Loader + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + +description: + This document defines the binding for a component that loads and boots firmware + on the Qualcomm Technology Inc. ADSP. + +properties: + compatible: + enum: + - qcom,sdm845-adsp-pil + + reg: + maxItems: 1 + description: + The base address and size of the qdsp6ss register + + 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 + + clocks: + items: + - description: XO clock + - description: SWAY clock + - description: LPASS AHBS AON clock + - description: LPASS AHBM AON clock + - description: QDSP XO clock + - description: Q6SP6SS SLEEP clock + - description: Q6SP6SS CORE clock + + clock-names: + items: + - const: xo + - const: sway_cbcr + - const: lpass_ahbs_aon_cbcr + - const: lpass_ahbm_aon_cbcr + - const: qdsp6ss_xo + - const: qdsp6ss_sleep + - const: qdsp6ss_core + + power-domains: + items: + - description: CX power domain + + resets: + items: + - description: PDC AUDIO SYNC RESET + - description: CC LPASS restart + + reset-names: + items: + - const: pdc_sync + - const: cc_lpass + + memory-region: + maxItems: 1 + description: Reference to the reserved-memory for the Hexagon core + + 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. + + 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 + description: The names of the state bits used for SMP2P output + items: + - const: stop + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + - clock-names + - power-domains + - resets + - reset-names + - qcom,halt-regs + - memory-region + - qcom,smem-states + - qcom,smem-state-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/clock/qcom,gcc-sdm845.h> + #include <dt-bindings/clock/qcom,lpass-sdm845.h> + #include <dt-bindings/power/qcom-rpmpd.h> + #include <dt-bindings/reset/qcom,sdm845-pdc.h> + #include <dt-bindings/reset/qcom,sdm845-aoss.h> + remoteproc@17300000 { + compatible = "qcom,sdm845-adsp-pil"; + reg = <0x17300000 0x40c>; + + interrupts-extended = <&intc GIC_SPI 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 = <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_LPASS_SWAY_CLK>, + <&lpasscc LPASS_Q6SS_AHBS_AON_CLK>, + <&lpasscc LPASS_Q6SS_AHBM_AON_CLK>, + <&lpasscc LPASS_QDSP6SS_XO_CLK>, + <&lpasscc LPASS_QDSP6SS_SLEEP_CLK>, + <&lpasscc LPASS_QDSP6SS_CORE_CLK>; + clock-names = "xo", "sway_cbcr", + "lpass_ahbs_aon_cbcr", + "lpass_ahbm_aon_cbcr", "qdsp6ss_xo", + "qdsp6ss_sleep", "qdsp6ss_core"; + + power-domains = <&rpmhpd SDM845_CX>; + + resets = <&pdc_reset PDC_AUDIO_SYNC_RESET>, + <&aoss_reset AOSS_CC_LPASS_RESTART>; + reset-names = "pdc_sync", "cc_lpass"; + + qcom,halt-regs = <&tcsr_mutex_regs 0x22000>; + + memory-region = <&pil_adsp_mem>; + + qcom,smem-states = <&adsp_smp2p_out 0>; + qcom,smem-state-names = "stop"; + }; diff --git a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml index b587c97c282b..be3d9b0e876b 100644 --- a/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/st,stm32-rproc.yaml @@ -29,17 +29,22 @@ properties: st,syscfg-holdboot: description: remote processor reset hold boot - - Phandle of syscon block. - - The offset of the hold boot setting register. - - The field mask of the hold boot. $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: The offset of the hold boot setting register + - description: The field mask of the hold boot st,syscfg-tz: description: Reference to the system configuration which holds the RCC trust zone mode $ref: "/schemas/types.yaml#/definitions/phandle-array" - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: FIXME + - description: FIXME interrupts: description: Should contain the WWDG1 watchdog reset interrupt @@ -93,20 +98,32 @@ properties: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the system configuration which holds the remote - maxItems: 1 + items: + - items: + - description: Phandle of syscon block + - description: FIXME + - description: FIXME st,syscfg-m4-state: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the tamp register which exposes the Cortex-M4 state. - maxItems: 1 + items: + - items: + - description: Phandle of syscon block with the tamp register + - description: FIXME + - description: FIXME st,syscfg-rsc-tbl: $ref: "/schemas/types.yaml#/definitions/phandle-array" description: | Reference to the tamp register which references the Cortex-M4 resource table address. - maxItems: 1 + items: + - items: + - description: Phandle of syscon block with the tamp register + - description: FIXME + - description: FIXME st,auto-boot: $ref: /schemas/types.yaml#/definitions/flag diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml index 7b56497eec4d..cedbc5efdc56 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-dsp-rproc.yaml @@ -79,6 +79,8 @@ properties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. The regions should be defined as child nodes of the respective SRAM node, and @@ -140,6 +142,14 @@ examples: #address-cells = <2>; #size-cells = <2>; + mailbox0_cluster3: mailbox-0 { + #mbox-cells = <1>; + }; + + mailbox0_cluster4: mailbox-1 { + #mbox-cells = <1>; + }; + bus@100000 { compatible = "simple-bus"; #address-cells = <2>; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml index d9c7e8c2b268..fb9605f0655b 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,k3-r5f-rproc.yaml @@ -95,8 +95,7 @@ patternProperties: addresses. Cache and memory access settings are provided through a Memory Protection Unit (MPU), programmable only from the R5Fs. - allOf: - - $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# + $ref: /schemas/arm/keystone/ti,k3-sci-common.yaml# properties: compatible: @@ -189,6 +188,8 @@ patternProperties: $ref: /schemas/types.yaml#/definitions/phandle-array minItems: 1 maxItems: 4 + items: + maxItems: 1 description: | phandles to one or more reserved on-chip SRAM regions. The regions should be defined as child nodes of the respective SRAM node, and @@ -236,6 +237,14 @@ examples: #address-cells = <2>; #size-cells = <2>; + mailbox0: mailbox-0 { + #mbox-cells = <1>; + }; + + mailbox1: mailbox-1 { + #mbox-cells = <1>; + }; + bus@100000 { compatible = "simple-bus"; #address-cells = <2>; diff --git a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml index c6c12129d6b7..1fdc2741c36e 100644 --- a/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml +++ b/Documentation/devicetree/bindings/remoteproc/ti,omap-remoteproc.yaml @@ -123,13 +123,14 @@ properties: ti,bootreg: $ref: /schemas/types.yaml#/definitions/phandle-array - description: | - Should be a triple of the phandle to the System Control - Configuration region that contains the boot address - register, the register offset of the boot address - register within the System Control module, and the bit - shift within the register. This property is required for - all the DSP instances on OMAP4, OMAP5 and DRA7xx SoCs. + items: + - items: + - description: phandle to the System Control Configuration region + - description: register offset of the boot address register + - description: the bit shift within the register + description: + This property is required for all the DSP instances on OMAP4, OMAP5 + and DRA7xx SoCs. ti,autosuspend-delay-ms: description: | @@ -140,6 +141,8 @@ properties: ti,timers: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | One or more phandles to OMAP DMTimer nodes, that serve as System/Tick timers for the OS running on the remote @@ -156,6 +159,8 @@ properties: ti,watchdog-timers: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + maxItems: 1 description: | One or more phandles to OMAP DMTimer nodes, used to serve as Watchdog timers for the processor cores. This diff --git a/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml new file mode 100644 index 000000000000..257a0b51994a --- /dev/null +++ b/Documentation/devicetree/bindings/reserved-memory/google,open-dice.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reserved-memory/google,open-dice.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Open Profile for DICE Device Tree Bindings + +description: | + This binding represents a reserved memory region containing data + generated by the Open Profile for DICE protocol. + + See https://pigweed.googlesource.com/open-dice/ + +maintainers: + - David Brazdil <dbrazdil@google.com> + +allOf: + - $ref: "reserved-memory.yaml" + +properties: + compatible: + const: google,open-dice + + reg: + description: page-aligned region of memory containing DICE data + +required: + - compatible + - reg + - no-map + +unevaluatedProperties: false + +examples: + - | + reserved-memory { + #address-cells = <2>; + #size-cells = <1>; + + dice: dice@12340000 { + compatible = "google,open-dice"; + reg = <0x00 0x12340000 0x2000>; + no-map; + }; + }; diff --git a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml index a4bf757d6881..618105f079be 100644 --- a/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml +++ b/Documentation/devicetree/bindings/reserved-memory/shared-dma-pool.yaml @@ -56,6 +56,16 @@ properties: If this property is present, then Linux will use the region for the default pool of the consistent DMA allocator. +if: + properties: + compatible: + contains: + const: restricted-dma-pool +then: + properties: + no-map: false + reusable: false + unevaluatedProperties: false examples: diff --git a/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml b/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml new file mode 100644 index 000000000000..0e5ee8decc0d --- /dev/null +++ b/Documentation/devicetree/bindings/reset/delta,tn48m-reset.yaml @@ -0,0 +1,35 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/reset/delta,tn48m-reset.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Delta Networks TN48M CPLD reset controller + +maintainers: + - Robert Marko <robert.marko@sartura.hr> + +description: | + This module is part of the Delta TN48M multi-function device. For more + details see ../mfd/delta,tn48m-cpld.yaml. + + Reset controller modules provides resets for the following: + * 88F7040 SoC + * 88F6820 SoC + * 98DX3265 switch MAC-s + * 88E1680 PHY-s + * 88E1512 PHY + * PoE PSE controller + +properties: + compatible: + const: delta,tn48m-reset + + "#reset-cells": + const: 1 + +required: + - compatible + - "#reset-cells" + +additionalProperties: false diff --git a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml index b13514e6783d..86c2569ced97 100644 --- a/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml +++ b/Documentation/devicetree/bindings/reset/renesas,rzg2l-usbphy-ctrl.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/reset/renesas,rzg2l-usbphy-ctrl.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L USBPHY Control +title: Renesas RZ/{G2L,V2L} USBPHY Control maintainers: - Biju Das <biju.das.jz@bp.renesas.com> @@ -18,6 +18,7 @@ properties: items: - enum: - renesas,r9a07g044-usbphy-ctrl # RZ/G2{L,LC} + - renesas,r9a07g054-usbphy-ctrl # RZ/V2L - const: renesas,rzg2l-usbphy-ctrl reg: diff --git a/Documentation/devicetree/bindings/riscv/cpus.yaml b/Documentation/devicetree/bindings/riscv/cpus.yaml index aa5fb64d57eb..d632ac76532e 100644 --- a/Documentation/devicetree/bindings/riscv/cpus.yaml +++ b/Documentation/devicetree/bindings/riscv/cpus.yaml @@ -99,6 +99,14 @@ properties: - compatible - interrupt-controller + cpu-idle-states: + $ref: '/schemas/types.yaml#/definitions/phandle-array' + items: + maxItems: 1 + description: | + List of phandles to idle state nodes supported + by this hart (see ./idle-states.yaml). + required: - riscv,isa - interrupt-controller diff --git a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml index 2b1f91603897..e2d330bd4608 100644 --- a/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml +++ b/Documentation/devicetree/bindings/riscv/sifive-l2-cache.yaml @@ -9,7 +9,6 @@ title: SiFive L2 Cache Controller maintainers: - Sagar Kadam <sagar.kadam@sifive.com> - - Yash Shah <yash.shah@sifive.com> - Paul Walmsley <paul.walmsley@sifive.com> description: diff --git a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml index c1527637eb74..3ce45456d867 100644 --- a/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml +++ b/Documentation/devicetree/bindings/rng/atmel,at91-trng.yaml @@ -9,7 +9,7 @@ title: Atmel AT91 True Random Number Generator maintainers: - Nicolas Ferre <nicolas.ferre@microchip.com> - Alexandre Belloni <alexandre.belloni@bootlin.com> - - Ludovic Desroches <ludovic.desroches@microchip.com> + - Claudiu Beznea <claudiu.beznea@microchip.com> properties: compatible: diff --git a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml index beeb90e55727..0b767fec39d8 100644 --- a/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml +++ b/Documentation/devicetree/bindings/rtc/allwinner,sun6i-a31-rtc.yaml @@ -16,16 +16,22 @@ properties: compatible: oneOf: - - const: allwinner,sun6i-a31-rtc - - const: allwinner,sun8i-a23-rtc - - const: allwinner,sun8i-h3-rtc - - const: allwinner,sun8i-r40-rtc - - const: allwinner,sun8i-v3-rtc - - const: allwinner,sun50i-h5-rtc + - enum: + - allwinner,sun6i-a31-rtc + - allwinner,sun8i-a23-rtc + - allwinner,sun8i-h3-rtc + - allwinner,sun8i-r40-rtc + - allwinner,sun8i-v3-rtc + - allwinner,sun50i-h5-rtc + - allwinner,sun50i-h6-rtc + - allwinner,sun50i-h616-rtc + - allwinner,sun50i-r329-rtc - items: - const: allwinner,sun50i-a64-rtc - const: allwinner,sun8i-h3-rtc - - const: allwinner,sun50i-h6-rtc + - items: + - const: allwinner,sun20i-d1-rtc + - const: allwinner,sun50i-r329-rtc reg: maxItems: 1 @@ -37,7 +43,12 @@ properties: - description: RTC Alarm 1 clocks: - maxItems: 1 + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 clock-output-names: minItems: 1 @@ -85,6 +96,7 @@ allOf: enum: - allwinner,sun8i-h3-rtc - allwinner,sun50i-h5-rtc + - allwinner,sun50i-h6-rtc then: properties: @@ -96,19 +108,68 @@ allOf: properties: compatible: contains: - const: allwinner,sun50i-h6-rtc + const: allwinner,sun50i-h616-rtc then: properties: - clock-output-names: + clocks: minItems: 3 maxItems: 3 + items: + - description: Bus clock for register access + - description: 24 MHz oscillator + - description: 32 kHz clock from the CCU + + clock-names: + minItems: 3 + maxItems: 3 + items: + - const: bus + - const: hosc + - const: pll-32k + + required: + - clocks + - clock-names - if: properties: compatible: contains: - const: allwinner,sun8i-r40-rtc + const: allwinner,sun50i-r329-rtc + + then: + properties: + clocks: + minItems: 3 + maxItems: 4 + items: + - description: Bus clock for register access + - description: 24 MHz oscillator + - description: AHB parent for internal SPI clock + - description: External 32768 Hz oscillator + + clock-names: + minItems: 3 + maxItems: 4 + items: + - const: bus + - const: hosc + - const: ahb + - const: ext-osc32k + + required: + - clocks + - clock-names + + - if: + properties: + compatible: + contains: + enum: + - allwinner,sun8i-r40-rtc + - allwinner,sun50i-h616-rtc + - allwinner,sun50i-r329-rtc then: properties: @@ -127,7 +188,6 @@ required: - compatible - reg - interrupts - - clock-output-names additionalProperties: false diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt b/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt deleted file mode 100644 index 3f0e2a5950eb..000000000000 --- a/Documentation/devicetree/bindings/rtc/atmel,at91sam9-rtc.txt +++ /dev/null @@ -1,25 +0,0 @@ -Atmel AT91SAM9260 Real Time Timer - -Required properties: -- compatible: should be one of the following: - - "atmel,at91sam9260-rtt" - - "microchip,sam9x60-rtt", "atmel,at91sam9260-rtt" -- reg: should encode the memory region of the RTT controller -- interrupts: rtt alarm/event interrupt -- clocks: should contain the 32 KHz slow clk that will drive the RTT block. -- atmel,rtt-rtc-time-reg: should encode the GPBR register used to store - the time base when the RTT is used as an RTC. - The first cell should point to the GPBR node and the second one - encode the offset within the GPBR block (or in other words, the - GPBR register used to store the time base). - - -Example: - -rtt@fffffd20 { - compatible = "atmel,at91sam9260-rtt"; - reg = <0xfffffd20 0x10>; - interrupts = <1 4 7>; - clocks = <&clk32k>; - atmel,rtt-rtc-time-reg = <&gpbr 0x0>; -}; diff --git a/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml new file mode 100644 index 000000000000..0ef1b7ff4a77 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/atmel,at91sam9260-rtt.yaml @@ -0,0 +1,69 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) 2022 Microchip Technology, Inc. and its subsidiaries +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/rtc/atmel,at91sam9260-rtt.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Atmel AT91 RTT Device Tree Bindings + +allOf: + - $ref: "rtc.yaml#" + +maintainers: + - Alexandre Belloni <alexandre.belloni@bootlin.com> + +properties: + compatible: + oneOf: + - items: + - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt + - items: + - const: microchip,sama7g5-rtt + - const: microchip,sam9x60-rtt + - const: atmel,at91sam9260-rtt + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + atmel,rtt-rtc-time-reg: + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: Phandle to the GPBR node. + - description: Offset within the GPBR block. + description: + Should encode the GPBR register used to store the time base when the + RTT is used as an RTC. The first cell should point to the GPBR node + and the second one encodes the offset within the GPBR block (or in + other words, the GPBR register used to store the time base). + +required: + - compatible + - reg + - interrupts + - clocks + - atmel,rtt-rtc-time-reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + rtc@fffffd20 { + compatible = "atmel,at91sam9260-rtt"; + reg = <0xfffffd20 0x10>; + interrupts = <1 IRQ_TYPE_LEVEL_HIGH 7>; + clocks = <&clk32k>; + atmel,rtt-rtc-time-reg = <&gpbr 0x0>; + }; diff --git a/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.yaml new file mode 100644 index 000000000000..a2e984ea3553 --- /dev/null +++ b/Documentation/devicetree/bindings/rtc/microchip,mfps-rtc.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/microchip,mfps-rtc.yaml# + +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip PolarFire Soc (MPFS) RTC Device Tree Bindings + +allOf: + - $ref: rtc.yaml# + +maintainers: + - Daire McNamara <daire.mcnamara@microchip.com> + - Lewis Hanly <lewis.hanly@microchip.com> + +properties: + compatible: + enum: + - microchip,mpfs-rtc + + reg: + maxItems: 1 + + interrupts: + items: + - description: | + RTC_WAKEUP interrupt + - description: | + RTC_MATCH, asserted when the content of the Alarm register is equal + to that of the RTC's count register. + + clocks: + maxItems: 1 + + clock-names: + items: + - const: rtc + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + rtc@20124000 { + compatible = "microchip,mpfs-rtc"; + reg = <0x20124000 0x1000>; + clocks = <&clkcfg 21>; + clock-names = "rtc"; + interrupts = <80>, <81>; + }; +... diff --git a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml index 6e04e3848261..ff364bd0fbac 100644 --- a/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml +++ b/Documentation/devicetree/bindings/serial/fsl-lpuart.yaml @@ -20,15 +20,15 @@ properties: - fsl,ls1021a-lpuart - fsl,ls1028a-lpuart - fsl,imx7ulp-lpuart - - fsl,imx8qm-lpuart + - fsl,imx8qxp-lpuart - fsl,imxrt1050-lpuart - items: - - enum: - - fsl,imx8qxp-lpuart - - fsl,imx8ulp-lpuart + - const: fsl,imx8ulp-lpuart - const: fsl,imx7ulp-lpuart - items: - - const: fsl,imx8qm-lpuart + - enum: + - fsl,imx8qm-lpuart + - fsl,imx8dxl-lpuart - const: fsl,imx8qxp-lpuart reg: diff --git a/Documentation/devicetree/bindings/serial/mtk-uart.txt b/Documentation/devicetree/bindings/serial/mtk-uart.txt index b3a0bfef0d54..113b5d6a2245 100644 --- a/Documentation/devicetree/bindings/serial/mtk-uart.txt +++ b/Documentation/devicetree/bindings/serial/mtk-uart.txt @@ -20,6 +20,7 @@ Required properties: * "mediatek,mt8135-uart" for MT8135 compatible UARTS * "mediatek,mt8173-uart" for MT8173 compatible UARTS * "mediatek,mt8183-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS + * "mediatek,mt8186-uart", "mediatek,mt6577-uart" for MT8183 compatible UARTS * "mediatek,mt8192-uart", "mediatek,mt6577-uart" for MT8192 compatible UARTS * "mediatek,mt8195-uart", "mediatek,mt6577-uart" for MT8195 compatible UARTS * "mediatek,mt8516-uart" for MT8516 compatible UARTS diff --git a/Documentation/devicetree/bindings/serial/mvebu-uart.txt b/Documentation/devicetree/bindings/serial/mvebu-uart.txt index 2d0dbdf32d1d..a062bbca532c 100644 --- a/Documentation/devicetree/bindings/serial/mvebu-uart.txt +++ b/Documentation/devicetree/bindings/serial/mvebu-uart.txt @@ -14,7 +14,10 @@ Required properties: is provided (possible only with the "marvell,armada-3700-uart" compatible string for backward compatibility), it will only work if the baudrate was initialized by the bootloader and no baudrate - change will then be possible. + change will then be possible. When provided it should be UART1-clk + for standard variant of UART and UART2-clk for extended variant + of UART. TBG clock (with UART TBG divisors d1=d2=1) or xtal clock + should not be used and are supported only for backward compatibility. - interrupts: - Must contain three elements for the standard variant of the IP (marvell,armada-3700-uart): "uart-sum", "uart-tx" and "uart-rx", @@ -34,7 +37,7 @@ Example: uart0: serial@12000 { compatible = "marvell,armada-3700-uart"; reg = <0x12000 0x18>; - clocks = <&xtalclk>; + clocks = <&uartclk 0>; interrupts = <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH>, <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH>, @@ -45,7 +48,7 @@ Example: uart1: serial@12200 { compatible = "marvell,armada-3700-uart-ext"; reg = <0x12200 0x30>; - clocks = <&xtalclk>; + clocks = <&uartclk 1>; interrupts = <GIC_SPI 30 IRQ_TYPE_EDGE_RISING>, <GIC_SPI 31 IRQ_TYPE_EDGE_RISING>; diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt deleted file mode 100644 index a08df97a69e6..000000000000 --- a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.txt +++ /dev/null @@ -1,17 +0,0 @@ -RDA Micro UART - -Required properties: -- compatible : "rda,8810pl-uart" for RDA8810PL SoCs. -- reg : Offset and length of the register set for the device. -- interrupts : Should contain UART interrupt. -- clocks : Phandle to the input clock. - - -Example: - - uart2: serial@20a90000 { - compatible = "rda,8810pl-uart"; - reg = <0x20a90000 0x1000>; - interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&uart_clk>; - }; diff --git a/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml new file mode 100644 index 000000000000..5f4ed8221270 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/rda,8810pl-uart.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/serial/rda,8810pl-uart.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: RDA Micro UART Interface + +maintainers: + - Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org> + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: rda,8810pl-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + uart3: serial@20a90000 { + compatible = "rda,8810pl-uart"; + reg = <0x20a90000 0x1000>; + interrupts = <11 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&uart_clk>; + }; +... diff --git a/Documentation/devicetree/bindings/serial/renesas,sci.yaml b/Documentation/devicetree/bindings/serial/renesas,sci.yaml index 8dda4e10e09d..bf7708a7a2c0 100644 --- a/Documentation/devicetree/bindings/serial/renesas,sci.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,sci.yaml @@ -17,6 +17,7 @@ properties: oneOf: - items: - enum: + - renesas,r9a07g043-sci # RZ/G2UL - renesas,r9a07g044-sci # RZ/G2{L,LC} - renesas,r9a07g054-sci # RZ/V2L - const: renesas,sci # generic SCI compatible UART @@ -67,6 +68,7 @@ if: compatible: contains: enum: + - renesas,r9a07g043-sci - renesas,r9a07g044-sci - renesas,r9a07g054-sci then: diff --git a/Documentation/devicetree/bindings/serial/renesas,scif.yaml b/Documentation/devicetree/bindings/serial/renesas,scif.yaml index ba5d3e0acc63..5d37f8f189fb 100644 --- a/Documentation/devicetree/bindings/serial/renesas,scif.yaml +++ b/Documentation/devicetree/bindings/serial/renesas,scif.yaml @@ -73,12 +73,12 @@ properties: - items: - enum: - renesas,scif-r9a07g044 # RZ/G2{L,LC} - - renesas,scif-r9a07g054 # RZ/V2L - items: - enum: + - renesas,scif-r9a07g043 # RZ/G2UL - renesas,scif-r9a07g054 # RZ/V2L - - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback for RZ/V2L + - const: renesas,scif-r9a07g044 # RZ/G2{L,LC} fallback reg: maxItems: 1 @@ -167,7 +167,6 @@ if: - renesas,rcar-gen3-scif - renesas,rcar-gen4-scif - renesas,scif-r9a07g044 - - renesas,scif-r9a07g054 then: required: - resets diff --git a/Documentation/devicetree/bindings/serial/samsung_uart.yaml b/Documentation/devicetree/bindings/serial/samsung_uart.yaml index 2940afb874b3..d4688e317fc5 100644 --- a/Documentation/devicetree/bindings/serial/samsung_uart.yaml +++ b/Documentation/devicetree/bindings/serial/samsung_uart.yaml @@ -20,12 +20,14 @@ properties: items: - enum: - apple,s5l-uart + - axis,artpec8-uart - samsung,s3c2410-uart - samsung,s3c2412-uart - samsung,s3c2440-uart - samsung,s3c6400-uart - samsung,s5pv210-uart - samsung,exynos4210-uart + - samsung,exynos5433-uart - samsung,exynos850-uart reg: @@ -110,7 +112,9 @@ allOf: contains: enum: - apple,s5l-uart + - axis,artpec8-uart - samsung,exynos4210-uart + - samsung,exynos5433-uart then: properties: clocks: diff --git a/Documentation/devicetree/bindings/serial/sifive-serial.yaml b/Documentation/devicetree/bindings/serial/sifive-serial.yaml index 09aae43f65a7..b0a8871e3641 100644 --- a/Documentation/devicetree/bindings/serial/sifive-serial.yaml +++ b/Documentation/devicetree/bindings/serial/sifive-serial.yaml @@ -59,7 +59,7 @@ examples: interrupt-parent = <&plic0>; interrupts = <80>; reg = <0x10010000 0x1000>; - clocks = <&prci PRCI_CLK_TLCLK>; + clocks = <&prci FU540_PRCI_CLK_TLCLK>; }; ... diff --git a/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml new file mode 100644 index 000000000000..2e9b64abde70 --- /dev/null +++ b/Documentation/devicetree/bindings/serial/sunplus,sp7021-uart.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/serial/sunplus,sp7021-uart.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Sunplus SoC SP7021 UART Controller Device Tree Bindings + +maintainers: + - Hammer Hsieh <hammerh0314@gmail.com> + +allOf: + - $ref: serial.yaml# + +properties: + compatible: + const: sunplus,sp7021-uart + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + - resets + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + aliases { + serial0 = &uart0; + }; + + uart0: serial@9c000900 { + compatible = "sunplus,sp7021-uart"; + reg = <0x9c000900 0x80>; + interrupt-parent = <&intc>; + interrupts = <53 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc 0x28>; + resets = <&rstc 0x18>; + }; +... diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml new file mode 100644 index 000000000000..c1e29d94f40e --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mp-hsio-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MP HSIO blk-ctrl + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +description: + The i.MX8MP HSIO blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the high-speed IO + (USB an PCIe) peripherals located in the HSIO domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mp-hsio-blk-ctrl + - const: syscon + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 6 + maxItems: 6 + + power-domain-names: + items: + - const: bus + - const: usb + - const: usb-phy1 + - const: usb-phy2 + - const: pcie + - const: pcie-phy + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: usb + - const: pcie + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mp-clock.h> + #include <dt-bindings/power/imx8mp-power.h> + + hsio_blk_ctrl: blk-ctrl@32f10000 { + compatible = "fsl,imx8mp-hsio-blk-ctrl", "syscon"; + reg = <0x32f10000 0x24>; + clocks = <&clk IMX8MP_CLK_USB_ROOT>, + <&clk IMX8MP_CLK_PCIE_ROOT>; + clock-names = "usb", "pcie"; + power-domains = <&pgc_hsiomix>, <&pgc_hsiomix>, + <&pgc_usb1_phy>, <&pgc_usb2_phy>, + <&pgc_hsiomix>, <&pgc_pcie_phy>; + power-domain-names = "bus", "usb", "usb-phy1", + "usb-phy2", "pcie", "pcie-phy"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml new file mode 100644 index 000000000000..7263ebedf09f --- /dev/null +++ b/Documentation/devicetree/bindings/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml @@ -0,0 +1,71 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/soc/imx/fsl,imx8mq-vpu-blk-ctrl.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: NXP i.MX8MQ VPU blk-ctrl + +maintainers: + - Lucas Stach <l.stach@pengutronix.de> + +description: + The i.MX8MQ VPU blk-ctrl is a top-level peripheral providing access to + the NoC and ensuring proper power sequencing of the VPU peripherals + located in the VPU domain of the SoC. + +properties: + compatible: + items: + - const: fsl,imx8mq-vpu-blk-ctrl + + reg: + maxItems: 1 + + '#power-domain-cells': + const: 1 + + power-domains: + minItems: 3 + maxItems: 3 + + power-domain-names: + items: + - const: bus + - const: g1 + - const: g2 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: g1 + - const: g2 + +required: + - compatible + - reg + - power-domains + - power-domain-names + - clocks + - clock-names + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/imx8mq-clock.h> + #include <dt-bindings/power/imx8mq-power.h> + + vpu_blk_ctrl: blk-ctrl@38320000 { + compatible = "fsl,imx8mq-vpu-blk-ctrl"; + reg = <0x38320000 0x100>; + power-domains = <&pgc_vpu>, <&pgc_vpu>, <&pgc_vpu>; + power-domain-names = "bus", "g1", "g2"; + clocks = <&clk IMX8MQ_CLK_VPU_G1_ROOT>, + <&clk IMX8MQ_CLK_VPU_G2_ROOT>; + clock-names = "g1", "g2"; + #power-domain-cells = <1>; + }; diff --git a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt index d74a7a5ae9f2..214a34633824 100644 --- a/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt +++ b/Documentation/devicetree/bindings/soc/mediatek/pwrap.txt @@ -27,6 +27,7 @@ Required properties in pwrap device node. "mediatek,mt8135-pwrap" for MT8135 SoCs "mediatek,mt8173-pwrap" for MT8173 SoCs "mediatek,mt8183-pwrap" for MT8183 SoCs + "mediatek,mt8186-pwrap" for MT8186 SoCs "mediatek,mt8195-pwrap" for MT8195 SoCs "mediatek,mt8516-pwrap" for MT8516 SoCs - interrupts: IRQ for pwrap in SOC diff --git a/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml new file mode 100644 index 000000000000..b0dae51e1d42 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/microchip/microchip,mpfs-sys-controller.yaml @@ -0,0 +1,40 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/microchip/microchip,mpfs-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: | + PolarFire SoC devices include a microcontroller acting as the system controller, + which provides "services" to the main processor and to the FPGA fabric. These + services include hardware rng, reprogramming of the FPGA and verfification of the + eNVM contents etc. More information on these services can be found online, at + https://onlinedocs.microchip.com/pr/GUID-1409CF11-8EF9-4C24-A94E-70979A688632-en-US-1/index.html + + Communication with the system controller is done via a mailbox, of which the client + portion is documented here. + +properties: + mboxes: + maxItems: 1 + + compatible: + const: microchip,mpfs-sys-controller + +required: + - compatible + - mboxes + +additionalProperties: false + +examples: + - | + syscontroller { + compatible = "microchip,mpfs-sys-controller"; + mboxes = <&mbox 0>; + }; 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 deleted file mode 100644 index 2cd3bc6bd8d6..000000000000 --- a/Documentation/devicetree/bindings/soc/microchip/microchip,polarfire-soc-sys-controller.yaml +++ /dev/null @@ -1,35 +0,0 @@ -# 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,eud.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml new file mode 100644 index 000000000000..c98aab209bc5 --- /dev/null +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,eud.yaml @@ -0,0 +1,77 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/soc/qcom/qcom,eud.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Qualcomm Embedded USB Debugger + +maintainers: + - Souradeep Chowdhury <quic_schowdhu@quicinc.com> + +description: + This binding is used to describe the Qualcomm Embedded USB Debugger, which is + mini USB-hub implemented on chip to support USB-based debug capabilities. + +properties: + compatible: + items: + - enum: + - qcom,sc7280-eud + - const: qcom,eud + + reg: + items: + - description: EUD Base Register Region + - description: EUD Mode Manager Register + + interrupts: + description: EUD interrupt + maxItems: 1 + + ports: + $ref: /schemas/graph.yaml#/properties/ports + description: + These ports is to be attached to the endpoint of the DWC3 controller node + and type C connector node. The controller has the "usb-role-switch" + property. + + properties: + port@0: + $ref: /schemas/graph.yaml#/properties/port + description: This port is to be attached to the DWC3 controller. + + port@1: + $ref: /schemas/graph.yaml#/properties/port + description: This port is to be attached to the type C connector. + +required: + - compatible + - reg + - ports + +additionalProperties: false + +examples: + - | + eud@88e0000 { + compatible = "qcom,sc7280-eud","qcom,eud"; + reg = <0x88e0000 0x2000>, + <0x88e2000 0x1000>; + ports { + #address-cells = <1>; + #size-cells = <0>; + port@0 { + reg = <0>; + eud_ep: endpoint { + remote-endpoint = <&usb2_role_switch>; + }; + }; + port@1 { + reg = <1>; + eud_con: endpoint { + remote-endpoint = <&con_eud>; + }; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml index a776cd37c297..95fcb43675d6 100644 --- a/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml +++ b/Documentation/devicetree/bindings/soc/qcom/qcom,geni-se.yaml @@ -103,7 +103,7 @@ patternProperties: supports up to 50MHz, up to four chip selects, programmable data path from 4 bits to 32 bits and numerous protocol variants. - $ref: /spi/spi-controller.yaml# + $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml index dfebf425ca49..b2ba7bed89b2 100644 --- a/Documentation/devicetree/bindings/soc/rockchip/grf.yaml +++ b/Documentation/devicetree/bindings/soc/rockchip/grf.yaml @@ -15,6 +15,7 @@ properties: - items: - enum: - rockchip,rk3288-sgrf + - rockchip,rk3568-usb2phy-grf - rockchip,rv1108-usbgrf - const: syscon - items: diff --git a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml index 273f2d95a043..a98ed66d092e 100644 --- a/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml +++ b/Documentation/devicetree/bindings/soc/samsung/exynos-usi.yaml @@ -17,13 +17,6 @@ description: | child nodes, each representing a serial sub-node device. The mode setting selects which particular function will be used. - Refer to next bindings documentation for information on protocol subnodes that - can exist under USI node: - - [1] Documentation/devicetree/bindings/serial/samsung_uart.yaml - [2] Documentation/devicetree/bindings/i2c/i2c-exynos5.txt - [3] Documentation/devicetree/bindings/spi/spi-samsung.txt - properties: $nodename: pattern: "^usi@[0-9a-f]+$" @@ -48,6 +41,10 @@ properties: samsung,sysreg: $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle to System Register syscon node + - description: offset of SW_CONF register for this USI controller description: Should be phandle/offset pair. The phandle to System Register syscon node (for the same domain where this USI controller resides) and the offset @@ -71,10 +68,17 @@ properties: This property is optional. patternProperties: - # All other properties should be child nodes - "^(serial|spi|i2c)@[0-9a-f]+$": + "^i2c@[0-9a-f]+$": + $ref: /schemas/i2c/i2c-exynos5.yaml + description: Child node describing underlying I2C + + "^serial@[0-9a-f]+$": + $ref: /schemas/serial/samsung_uart.yaml + description: Child node describing underlying UART/serial + + "^spi@[0-9a-f]+$": type: object - description: Child node describing underlying USI serial protocol + description: Child node describing underlying SPI required: - compatible diff --git a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml index 9d128b9e7deb..64461d432004 100644 --- a/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml +++ b/Documentation/devicetree/bindings/soc/ti/ti,pruss.yaml @@ -281,10 +281,7 @@ patternProperties: PRUSS INTC Node. Each PRUSS has a single interrupt controller instance that is common to all the PRU cores. This should be represented as an interrupt-controller node. - - allOf: - - $ref: /schemas/interrupt-controller/ti,pruss-intc.yaml# - + $ref: /schemas/interrupt-controller/ti,pruss-intc.yaml# type: object mdio@[a-f0-9]+$: @@ -292,10 +289,7 @@ patternProperties: MDIO Node. Each PRUSS has an MDIO module that can be used to control external PHYs. The MDIO module used within the PRU-ICSS is an instance of the MDIO Controller used in TI Davinci SoCs. - - allOf: - - $ref: /schemas/net/ti,davinci-mdio.yaml# - + $ref: /schemas/net/ti,davinci-mdio.yaml# type: object "^(pru|rtu|txpru)@[0-9a-f]+$": @@ -305,10 +299,7 @@ patternProperties: inactive by using the standard DT string property, "status". The ICSSG IP present on K3 SoCs have additional auxiliary PRU cores with slightly different IP integration. - - allOf: - - $ref: /schemas/remoteproc/ti,pru-rproc.yaml# - + $ref: /schemas/remoteproc/ti,pru-rproc.yaml# type: object required: diff --git a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml index 7d48ea094c66..c21c807b667c 100644 --- a/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/allwinner,sun4i-a10-i2s.yaml @@ -31,6 +31,10 @@ properties: - const: allwinner,sun50i-a64-i2s - const: allwinner,sun8i-h3-i2s - const: allwinner,sun50i-h6-i2s + - const: allwinner,sun50i-r329-i2s + - items: + - const: allwinner,sun20i-d1-i2s + - const: allwinner,sun50i-r329-i2s reg: maxItems: 1 @@ -67,6 +71,7 @@ allOf: - allwinner,sun8i-h3-i2s - allwinner,sun50i-a64-codec-i2s - allwinner,sun50i-h6-i2s + - allwinner,sun50i-r329-i2s then: required: diff --git a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml index 2e35aeaa8781..8b5be4b92f35 100644 --- a/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml +++ b/Documentation/devicetree/bindings/sound/amlogic,gx-sound-card.yaml @@ -57,7 +57,7 @@ patternProperties: rate sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle of the CPU DAI patternProperties: @@ -71,7 +71,7 @@ patternProperties: properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle of the codec DAI required: diff --git a/Documentation/devicetree/bindings/sound/arndale.txt b/Documentation/devicetree/bindings/sound/arndale.txt deleted file mode 100644 index 17530120ccfc..000000000000 --- a/Documentation/devicetree/bindings/sound/arndale.txt +++ /dev/null @@ -1,25 +0,0 @@ -Audio Binding for Arndale boards - -Required properties: -- compatible : Can be one of the following: - "samsung,arndale-rt5631", - "samsung,arndale-wm1811" - -- samsung,audio-cpu: The phandle of the Samsung I2S controller -- samsung,audio-codec: The phandle of the audio codec - -Optional: -- samsung,model: The name of the sound-card - -Arndale Boards has many audio daughter cards, one of them is -rt5631/alc5631. Below example shows audio bindings for rt5631/ -alc5631 based codec. - -Example: - -sound { - compatible = "samsung,arndale-rt5631"; - - samsung,audio-cpu = <&i2s0> - samsung,audio-codec = <&rt5631>; -}; diff --git a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml index 476dcb49ece6..5c368674d11a 100644 --- a/Documentation/devicetree/bindings/sound/audio-graph-port.yaml +++ b/Documentation/devicetree/bindings/sound/audio-graph-port.yaml @@ -71,4 +71,24 @@ patternProperties: description: CPU to Codec rate channels. $ref: /schemas/types.yaml#/definitions/uint32 + dai-tdm-slot-width-map: + description: Mapping of sample widths to slot widths. For hardware + that cannot support a fixed slot width or a slot width always + equal to sample width. A matrix of one or more 3-tuples. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - + description: Sample width in bits + minimum: 8 + maximum: 64 + - + description: Slot width in bits + minimum: 8 + maximum: 256 + - + description: Slot count + minimum: 1 + maximum: 64 + additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml new file mode 100644 index 000000000000..dce86dafe382 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/awinic,aw8738.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/awinic,aw8738.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Awinic AW8738 Audio Amplifier + +maintainers: + - Stephan Gerhold <stephan@gerhold.net> + +description: + The Awinic AW8738 is a simple audio amplifier with different operation modes + (set using one-wire pulse control). The mode configures the speaker-guard + function (primarily the power limit for the amplifier). + +allOf: + - $ref: name-prefix.yaml# + +properties: + compatible: + const: awinic,aw8738 + + mode-gpios: + description: + GPIO used for one-wire pulse control. The pin is typically called SHDN + (active-low), but this is misleading since it is actually more than + just a simple shutdown/enable control. + maxItems: 1 + + awinic,mode: + description: Operation mode (number of pulses for one-wire pulse control) + $ref: /schemas/types.yaml#/definitions/uint32 + minimum: 1 + maximum: 7 + + sound-name-prefix: true + +required: + - compatible + - mode-gpios + - awinic,mode + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + audio-amplifier { + compatible = "awinic,aw8738"; + mode-gpios = <&msmgpio 114 GPIO_ACTIVE_HIGH>; + awinic,mode = <5>; + sound-name-prefix = "Speaker Amp"; + }; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt deleted file mode 100644 index bd863bd69501..000000000000 --- a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.txt +++ /dev/null @@ -1,86 +0,0 @@ -Texas Instruments McASP controller - -Required properties: -- compatible : - "ti,dm646x-mcasp-audio" : for DM646x platforms - "ti,da830-mcasp-audio" : for both DA830 & DA850 platforms - "ti,am33xx-mcasp-audio" : for AM33xx platforms (AM33xx, AM43xx, TI81xx) - "ti,dra7-mcasp-audio" : for DRA7xx platforms - "ti,omap4-mcasp-audio" : for OMAP4 - -- reg : Should contain reg specifiers for the entries in the reg-names property. -- reg-names : Should contain: - * "mpu" for the main registers (required). For compatibility with - existing software, it is recommended this is the first entry. - * "dat" for separate data port register access (optional). -- op-mode : I2S/DIT ops mode. 0 for I2S mode. 1 for DIT mode used for S/PDIF, - IEC60958-1, and AES-3 formats. -- tdm-slots : Slots for TDM operation. Indicates number of channels transmitted - or received over one serializer. -- serial-dir : A list of serializer configuration. Each entry is a number - indication for serializer pin direction. - (0 - INACTIVE, 1 - TX, 2 - RX) -- dmas: two element list of DMA controller phandles and DMA request line - ordered pairs. -- dma-names: identifier string for each DMA request line in the dmas property. - These strings correspond 1:1 with the ordered pairs in dmas. The dma - identifiers must be "rx" and "tx". - -Optional properties: - -- ti,hwmods : Must be "mcasp<n>", n is controller instance starting 0 -- tx-num-evt : FIFO levels. -- rx-num-evt : FIFO levels. -- dismod : Specify the drive on TX pin during inactive slots - 0 : 3-state - 2 : logic low - 3 : logic high - Defaults to 'logic low' when the property is not present -- sram-size-playback : size of sram to be allocated during playback -- sram-size-capture : size of sram to be allocated during capture -- interrupts : Interrupt numbers for McASP -- interrupt-names : Known interrupt names are "tx" and "rx" -- pinctrl-0: Should specify pin control group used for this controller. -- pinctrl-names: Should contain only one value - "default", for more details - please refer to pinctrl-bindings.txt -- fck_parent : Should contain a valid clock name which will be used as parent - for the McASP fck -- auxclk-fs-ratio: When McASP is bus master indicates the ratio between AUCLK - and FS rate if applicable: - AUCLK rate = auxclk-fs-ratio * FS rate - -Optional GPIO support: -If any McASP pin need to be used as GPIO then the McASP node must have: -... - gpio-controller - #gpio-cells = <2>; -... - -When requesting a GPIO, the first parameter is the PIN index in McASP_P* -registers. -For example to request the AXR2 pin of mcasp8: -function-gpios = <&mcasp8 2 0>; - -Or to request the ACLKR pin of mcasp8: -function-gpios = <&mcasp8 29 0>; - -For generic gpio information, please refer to bindings/gpio/gpio.txt - -Example: - -mcasp0: mcasp0@1d00000 { - compatible = "ti,da830-mcasp-audio"; - reg = <0x100000 0x3000>; - reg-names "mpu"; - interrupts = <82>, <83>; - interrupt-names = "tx", "rx"; - op-mode = <0>; /* MCASP_IIS_MODE */ - tdm-slots = <2>; - serial-dir = < - 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ - 0 0 0 0 - 0 0 0 1 - 2 0 0 0 >; - tx-num-evt = <1>; - rx-num-evt = <1>; -}; diff --git a/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml new file mode 100644 index 000000000000..f46c66bc6b2d --- /dev/null +++ b/Documentation/devicetree/bindings/sound/davinci-mcasp-audio.yaml @@ -0,0 +1,201 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/davinci-mcasp-audio.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: McASP Controller for TI SoCs + +maintainers: + - Jayesh Choudhary <j-choudhary@ti.com> + +properties: + compatible: + enum: + - ti,dm646x-mcasp-audio + - ti,da830-mcasp-audio + - ti,am33xx-mcasp-audio + - ti,dra7-mcasp-audio + - ti,omap4-mcasp-audio + + reg: + minItems: 1 + items: + - description: CFG registers + - description: data registers + + reg-names: + minItems: 1 + items: + - const: mpu + - const: dat + + op-mode: + $ref: /schemas/types.yaml#/definitions/uint32 + description: 0 - I2S or 1 - DIT operation mode + enum: + - 0 + - 1 + + tdm-slots: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + number of channels over one serializer + the property is ignored in DIT mode + minimum: 2 + maximum: 32 + + serial-dir: + description: + A list of serializer configuration + Entry is indication for serializer pin direction + 0 - Inactive, 1 - TX, 2 - RX + All AXR pins should be present in the array even if inactive + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 25 + items: + minimum: 0 + maximum: 2 + + dmas: + minItems: 1 + items: + - description: transmission DMA channel + - description: reception DMA channel + + dma-names: + minItems: 1 + items: + - const: tx + - const: rx + + ti,hwmods: + $ref: /schemas/types.yaml#/definitions/string + description: Name of hwmod associated with McASP + maxItems: 1 + deprecated: true + + tx-num-evt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + configures WFIFO threshold + 0 disables the FIFO use + if property is missing, then also FIFO use is disabled + + rx-num-evt: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + configures RFIFO threshold + 0 disables the FIFO use + if property is missing, then also FIFO use is disabled + + dismod: + $ref: /schemas/types.yaml#/definitions/uint32 + description: + specify the drive on TX pin during inactive time slots + 0 - 3-state, 2 - logic low, 3 - logic high + enum: + - 0 + - 2 + - 3 + default: 2 + + interrupts: + anyOf: + - minItems: 1 + items: + - description: TX interrupt + - description: RX interrupt + - items: + - description: common/combined interrupt + + interrupt-names: + oneOf: + - minItems: 1 + items: + - const: tx + - const: rx + - const: common + + fck_parent: + $ref: /schemas/types.yaml#/definitions/string + description: parent clock name for McASP fck + maxItems: 1 + + auxclk-fs-ratio: + $ref: /schemas/types.yaml#/definitions/uint32 + description: ratio of AUCLK and FS rate if applicable + + gpio-controller: true + + "#gpio-cells": + const: 2 + + clocks: + minItems: 1 + items: + - description: functional clock + - description: module specific optional ahclkx clock + - description: module specific optional ahclkr clock + + clock-names: + minItems: 1 + items: + - const: fck + - const: ahclkx + - const: ahclkr + + power-domains: + description: phandle to the corresponding power-domain + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + port: + description: connection for when McASP is used via graph card + type: object + +required: + - compatible + - reg + - reg-names + - dmas + - dma-names + - interrupts + - interrupt-names + +allOf: + - if: + properties: + opmode: + enum: + - 0 + + then: + required: + - tdm-slots + +additionalProperties: false + +examples: + - | + mcasp0: mcasp0@1d00000 { + compatible = "ti,da830-mcasp-audio"; + reg = <0x100000 0x3000>; + reg-names = "mpu"; + interrupts = <82>, <83>; + interrupt-names = "tx", "rx"; + op-mode = <0>; /* MCASP_IIS_MODE */ + tdm-slots = <2>; + dmas = <&main_udmap 0xc400>, <&main_udmap 0x4400>; + dma-names = "tx", "rx"; + serial-dir = < + 0 0 0 0 /* 0: INACTIVE, 1: TX, 2: RX */ + 0 0 0 0 + 0 0 0 1 + 2 0 0 0 >; + tx-num-evt = <1>; + rx-num-evt = <1>; + }; diff --git a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt index 23d83fa7609f..8b4f4015cfe4 100644 --- a/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt +++ b/Documentation/devicetree/bindings/sound/fsl-asoc-card.txt @@ -40,6 +40,8 @@ The compatible list for this generic sound card currently: "fsl,imx-audio-tlv320aic32x4" + "fsl,imx-audio-tlv320aic31xx" + "fsl,imx-audio-si476x" "fsl,imx-audio-wm8958" @@ -82,6 +84,7 @@ Optional properties: - dai-format : audio format, for details see simple-card.yaml. - frame-inversion : dai-link uses frame clock inversion, for details see simple-card.yaml. - bitclock-inversion : dai-link uses bit clock inversion, for details see simple-card.yaml. + - mclk-id : main clock id, specific for each card configuration. Optional unless SSI is selected as a CPU DAI: diff --git a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml index 77adbebed824..c3e9f3485449 100644 --- a/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml +++ b/Documentation/devicetree/bindings/sound/google,cros-ec-codec.yaml @@ -8,6 +8,7 @@ title: Audio codec controlled by ChromeOS EC maintainers: - Cheng-Yi Chiang <cychiang@chromium.org> + - Tzung-Bi Shih <tzungbi@google.com> description: | Google's ChromeOS EC codec is a digital mic codec provided by the diff --git a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml index 837e3faa63a9..233caa0ade87 100644 --- a/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml +++ b/Documentation/devicetree/bindings/sound/google,sc7180-trogdor.yaml @@ -62,13 +62,15 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 required: - link-name diff --git a/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml new file mode 100644 index 000000000000..869b40363af8 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/google,sc7280-herobrine.yaml @@ -0,0 +1,180 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/google,sc7280-herobrine.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google SC7280-Herobrine ASoC sound card driver + +maintainers: + - Srinivasa Rao Mandadapu <srivasam@codeaurora.org> + - Judy Hsiao <judyhsiao@chromium.org> + +description: + This binding describes the SC7280 sound card which uses LPASS for audio. + +properties: + compatible: + enum: + - google,sc7280-herobrine + + 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. + + model: + $ref: /schemas/types.yaml#/definitions/string + description: User specified audio sound card name + + "#address-cells": + const: 1 + + "#size-cells": + const: 0 + +patternProperties: + "^dai-link@[0-9a-f]$": + 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 + + reg: + maxItems: 1 + description: dai link address. + + cpu: + description: Holds subnode which indicates cpu dai. + type: object + properties: + sound-dai: true + + required: + - sound-dai + + additionalProperties: false + + codec: + description: Holds subnode which indicates codec dai. + type: object + properties: + sound-dai: true + + required: + - sound-dai + + additionalProperties: false + + required: + - link-name + - cpu + - codec + - reg + + additionalProperties: false + +required: + - compatible + - model + - "#address-cells" + - "#size-cells" + +additionalProperties: false + +examples: + + - | + #include <dt-bindings/sound/qcom,lpass.h> + sound { + compatible = "google,sc7280-herobrine"; + model = "sc7280-wcd938x-max98360a-4dmic"; + + audio-routing = + "IN1_HPHL", "HPHL_OUT", + "IN2_HPHR", "HPHR_OUT", + "AMIC1", "MIC BIAS1", + "AMIC2", "MIC BIAS2", + "VA DMIC0", "MIC BIAS3", + "VA DMIC1", "MIC BIAS3", + "VA DMIC2", "MIC BIAS4", + "VA DMIC3", "MIC BIAS4", + "TX SWR_ADC0", "ADC1_OUTPUT", + "TX SWR_ADC1", "ADC2_OUTPUT", + "TX SWR_ADC2", "ADC3_OUTPUT", + "TX SWR_DMIC0", "DMIC1_OUTPUT", + "TX SWR_DMIC1", "DMIC2_OUTPUT", + "TX SWR_DMIC2", "DMIC3_OUTPUT", + "TX SWR_DMIC3", "DMIC4_OUTPUT"; + + #address-cells = <1>; + #size-cells = <0>; + + dai-link@0 { + link-name = "WCD Playback"; + reg = <LPASS_CDC_DMA_RX0>; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_RX0>; + }; + + codec { + sound-dai = <&wcd938x 0>, <&swr0 0>, <&rxmacro 0>; + }; + }; + dai-link@1 { + link-name = "WCD Capture"; + reg = <LPASS_CDC_DMA_TX3>; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_TX3>; + }; + + codec { + sound-dai = <&wcd938x 1>, <&swr1 0>, <&txmacro 0>; + }; + }; + + dai-link@2 { + link-name = "MI2S Playback"; + reg = <MI2S_SECONDARY>; + cpu { + sound-dai = <&lpass_cpu MI2S_SECONDARY>; + }; + + codec { + sound-dai = <&max98360a>; + }; + }; + + dai-link@3 { + link-name = "DMIC Capture"; + reg = <LPASS_CDC_DMA_VA_TX0>; + cpu { + sound-dai = <&lpass_cpu LPASS_CDC_DMA_VA_TX0>; + }; + + codec { + sound-dai = <&vamacro 0>; + }; + }; + + dai-link@5 { + link-name = "DP Playback"; + reg = <LPASS_DP_RX>; + cpu { + sound-dai = <&lpass_cpu LPASS_DP_RX>; + }; + + codec { + sound-dai = <&mdss_dp>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml index d1816dd061cf..bb3a435722c7 100644 --- a/Documentation/devicetree/bindings/sound/imx-audio-card.yaml +++ b/Documentation/devicetree/bindings/sound/imx-audio-card.yaml @@ -59,13 +59,16 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + minItems: 1 + maxItems: 2 fsl,mclk-equal-bclk: description: Indicates mclk can be equal to bclk, especially for sai interface diff --git a/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml new file mode 100644 index 000000000000..04414eb4ada9 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/microchip,pdmc.yaml @@ -0,0 +1,100 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/microchip,pdmc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip Pulse Density Microphone Controller + +maintainers: + - Codrin Ciubotariu <codrin.ciubotariu@microchip.com> + +description: + The Microchip Pulse Density Microphone Controller (PDMC) interfaces up to 4 + digital microphones having Pulse Density Modulated (PDM) outputs. + +properties: + compatible: + const: microchip,sama7g5-pdmc + + reg: + maxItems: 1 + + "#sound-dai-cells": + const: 0 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: Peripheral Bus Clock + - description: Generic Clock + + clock-names: + items: + - const: pclk + - const: gclk + + dmas: + description: RX DMA Channel + maxItems: 1 + + dma-names: + const: rx + + microchip,mic-pos: + description: | + Position of PDM microphones on the DS line and the sampling edge (rising + or falling) of the CLK line. A microphone is represented as a pair of DS + line and the sampling edge. The first microphone is mapped to channel 0, + the second to channel 1, etc. + $ref: /schemas/types.yaml#/definitions/uint32-matrix + items: + items: + - description: value for DS line + - description: value for sampling edge + anyOf: + - enum: + - [0, 0] + - [0, 1] + - [1, 0] + - [1, 1] + minItems: 1 + maxItems: 4 + uniqueItems: true + +required: + - compatible + - reg + - "#sound-dai-cells" + - interrupts + - clocks + - clock-names + - dmas + - dma-names + - microchip,mic-pos + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/at91.h> + #include <dt-bindings/dma/at91.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/sound/microchip,pdmc.h> + + pdmc: sound@e1608000 { + compatible = "microchip,sama7g5-pdmc"; + reg = <0xe1608000 0x4000>; + #sound-dai-cells = <0>; + interrupts = <GIC_SPI 68 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&dma0 AT91_XDMAC_DT_PERID(37)>; + dma-names = "rx"; + clocks = <&pmc PMC_TYPE_PERIPHERAL 68>, <&pmc PMC_TYPE_GCK 68>; + clock-names = "pclk", "gclk"; + microchip,mic-pos = <MCHP_PDMC_DS0 MCHP_PDMC_CLK_POSITIVE>, + <MCHP_PDMC_DS0 MCHP_PDMC_CLK_NEGATIVE>, + <MCHP_PDMC_DS1 MCHP_PDMC_CLK_POSITIVE>, + <MCHP_PDMC_DS1 MCHP_PDMC_CLK_NEGATIVE>; + }; diff --git a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml index 6d0975b33d15..4452a4070eff 100644 --- a/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml +++ b/Documentation/devicetree/bindings/sound/mt8195-afe-pcm.yaml @@ -19,6 +19,12 @@ properties: interrupts: maxItems: 1 + resets: + maxItems: 1 + + reset-names: + const: audiosys + memory-region: maxItems: 1 description: | @@ -127,6 +133,8 @@ required: - compatible - reg - interrupts + - resets + - reset-names - mediatek,topckgen - power-domains - clocks @@ -144,6 +152,8 @@ examples: compatible = "mediatek,mt8195-audio"; reg = <0x10890000 0x10000>; interrupts = <GIC_SPI 822 IRQ_TYPE_LEVEL_HIGH 0>; + resets = <&watchdog 14>; + reset-names = "audiosys"; mediatek,topckgen = <&topckgen>; power-domains = <&spm 7>; //MT8195_POWER_DOMAIN_AUDIO memory-region = <&snd_dma_mem_reserved>; diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml index 0912d3e3fd8e..73b98b2f3543 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra186-dspk.yaml @@ -28,7 +28,9 @@ properties: oneOf: - const: nvidia,tegra186-dspk - items: - - const: nvidia,tegra194-dspk + - enum: + - nvidia,tegra234-dspk + - nvidia,tegra194-dspk - const: nvidia,tegra186-dspk reg: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml index 19eaacc3f12a..372043edd98f 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-admaif.yaml @@ -27,7 +27,9 @@ properties: - nvidia,tegra210-admaif - nvidia,tegra186-admaif - items: - - const: nvidia,tegra194-admaif + - enum: + - nvidia,tegra234-admaif + - nvidia,tegra194-admaif - const: nvidia,tegra186-admaif reg: diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml index c4ba12ea3611..8d8dc7fb3f0c 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-adx.yaml @@ -30,6 +30,7 @@ properties: - const: nvidia,tegra210-adx - items: - enum: + - nvidia,tegra234-adx - nvidia,tegra194-adx - nvidia,tegra186-adx - const: nvidia,tegra210-adx diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml index df81d208184a..4727f1e42c53 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-ahub.yaml @@ -26,6 +26,7 @@ properties: - enum: - nvidia,tegra210-ahub - nvidia,tegra186-ahub + - nvidia,tegra234-ahub - items: - const: nvidia,tegra194-ahub - const: nvidia,tegra186-ahub diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml index bb2111afe5a8..f9e4fc6e0c47 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-amx.yaml @@ -31,6 +31,9 @@ properties: - const: nvidia,tegra186-amx - const: nvidia,tegra210-amx - const: nvidia,tegra194-amx + - items: + - const: nvidia,tegra234-amx + - const: nvidia,tegra194-amx reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml index 62db982bb01d..bcb496d3ace5 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-dmic.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-dmic - items: - enum: + - nvidia,tegra234-dmic - nvidia,tegra194-dmic - nvidia,tegra186-dmic - const: nvidia,tegra210-dmic diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml index f954be636697..6188f561f878 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-i2s.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-i2s - items: - enum: + - nvidia,tegra234-i2s - nvidia,tegra194-i2s - nvidia,tegra186-i2s - const: nvidia,tegra210-i2s diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml index 428f3c851941..ee1e1d2da79a 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mixer.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-amixer - items: - enum: + - nvidia,tegra234-amixer - nvidia,tegra194-amixer - nvidia,tegra186-amixer - const: nvidia,tegra210-amixer diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml index e2f5a8591d8f..c9888c553e78 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-mvc.yaml @@ -31,6 +31,7 @@ properties: - const: nvidia,tegra210-mvc - items: - enum: + - nvidia,tegra234-mvc - nvidia,tegra194-mvc - nvidia,tegra186-mvc - const: nvidia,tegra210-mvc diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml index 41ad65173548..8579306fc56f 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra210-sfc.yaml @@ -28,6 +28,7 @@ properties: - const: nvidia,tegra210-sfc - items: - enum: + - nvidia,tegra234-sfc - nvidia,tegra194-sfc - nvidia,tegra186-sfc - const: nvidia,tegra210-sfc diff --git a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml index 2c913aa44fee..12c31b4b99e1 100644 --- a/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml +++ b/Documentation/devicetree/bindings/sound/nvidia,tegra30-hda.yaml @@ -23,6 +23,7 @@ properties: - const: nvidia,tegra30-hda - items: - enum: + - nvidia,tegra234-hda - nvidia,tegra194-hda - nvidia,tegra186-hda - nvidia,tegra210-hda @@ -41,9 +42,11 @@ properties: maxItems: 1 clocks: + minItems: 2 maxItems: 3 clock-names: + minItems: 2 items: - const: hda - const: hda2hdmi diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml index 1e23c0e20bc1..2c81efb5fa37 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-cpu.yaml @@ -22,35 +22,41 @@ properties: - qcom,lpass-cpu - qcom,apq8016-lpass-cpu - qcom,sc7180-lpass-cpu + - qcom,sc7280-lpass-cpu reg: - maxItems: 2 + minItems: 2 + maxItems: 6 description: LPAIF core registers reg-names: - maxItems: 2 + minItems: 2 + maxItems: 6 clocks: minItems: 3 - maxItems: 6 + maxItems: 7 clock-names: minItems: 3 - maxItems: 6 + maxItems: 7 interrupts: - maxItems: 2 + minItems: 2 + maxItems: 4 description: LPAIF DMA buffer interrupt interrupt-names: - maxItems: 2 + minItems: 2 + maxItems: 4 qcom,adsp: $ref: /schemas/types.yaml#/definitions/phandle description: Phandle for the audio DSP node iommus: - maxItems: 2 + minItems: 2 + maxItems: 3 description: Phandle to apps_smmu node with sid mask power-domains: @@ -69,7 +75,7 @@ patternProperties: "^dai-link@[0-9a-f]$": type: object description: | - LPASS CPU dai node for each I2S device. Bindings of each node + LPASS CPU dai node for each I2S device or Soundwire device. Bindings of each node depends on the specific driver providing the functionality and properties. properties: @@ -174,6 +180,59 @@ allOf: - iommus - power-domains + - if: + properties: + compatible: + contains: + const: qcom,sc7280-lpass-cpu + + then: + properties: + clock-names: + oneOf: + - items: #for I2S + - const: aon_cc_audio_hm_h + - const: core_cc_sysnoc_mport_core + - const: core_cc_ext_if1_ibit + - items: #for Soundwire + - const: aon_cc_audio_hm_h + - const: audio_cc_codec_mem0 + - const: audio_cc_codec_mem1 + - const: audio_cc_codec_mem2 + - items: #for HDMI + - const: aon_cc_audio_hm_h + + reg-names: + anyOf: + - items: #for I2S + - const: lpass-lpaif + - items: #for I2S and HDMI + - const: lpass-hdmiif + - const: lpass-lpaif + - items: #for I2S, soundwire and HDMI + - const: lpass-hdmiif + - const: lpass-lpaif + - const: lpass-rxtx-cdc-dma-lpm + - const: lpass-rxtx-lpaif + - const: lpass-va-lpaif + - const: lpass-va-cdc-dma-lpm + interrupt-names: + anyOf: + - items: #for I2S + - const: lpass-irq-lpaif + - items: #for I2S and HDMI + - const: lpass-irq-lpaif + - const: lpass-irq-hdmi + - items: #for I2S, soundwire and HDMI + - const: lpass-irq-lpaif + - const: lpass-irq-hdmi + - const: lpass-irq-vaif + - const: lpass-irq-rxtxif + + required: + - iommus + - power-domains + examples: - | #include <dt-bindings/sound/sc7180-lpass.h> diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml index bc762b39c68a..6127df5836c2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-rx-macro.yaml @@ -39,6 +39,14 @@ properties: items: - const: mclk + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + required: - compatible - reg diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml index 74f53864e7a7..3f0f99cb18ca 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-tx-macro.yaml @@ -39,6 +39,14 @@ properties: items: - const: mclk + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + qcom,dmic-sample-rate: description: dmic sample rate $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml index 99f2c3687fbd..9868a5ebe27e 100644 --- a/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,lpass-va-macro.yaml @@ -37,6 +37,14 @@ properties: items: - const: fsgen + power-domains: + maxItems: 2 + + power-domain-names: + items: + - const: macro + - const: dcodec + qcom,dmic-sample-rate: description: dmic sample rate $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml index 4bfda04b4608..4ecd4080bb96 100644 --- a/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,sm8250.yaml @@ -69,19 +69,23 @@ patternProperties: description: Holds subnode which indicates cpu dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 platform: description: Holds subnode which indicates platform dai. type: object properties: - sound-dai: true + sound-dai: + maxItems: 1 codec: description: Holds subnode which indicates codec dai. type: object properties: - sound-dai: true + sound-dai: + minItems: 1 + maxItems: 4 required: - link-name diff --git a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml index cb74ce40c2e6..7bf1a5fffcd2 100644 --- a/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml +++ b/Documentation/devicetree/bindings/sound/qcom,wcd938x.yaml @@ -23,6 +23,10 @@ properties: description: GPIO spec for reset line to use maxItems: 1 + us-euro-gpios: + description: GPIO spec for swapping gnd and mic segments + maxItems: 1 + vdd-buck-supply: description: A reference to the 1.8V buck supply diff --git a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml index d65c0ed5060c..ca5b8987b749 100644 --- a/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml +++ b/Documentation/devicetree/bindings/sound/realtek,rt5682s.yaml @@ -21,6 +21,7 @@ properties: description: I2C address of the device. interrupts: + maxItems: 1 description: The CODEC's interrupt output. realtek,dmic1-data-pin: @@ -94,7 +95,7 @@ required: examples: - | - #include <dt-bindings/gpio/tegra-gpio.h> + #include <dt-bindings/gpio/gpio.h> #include <dt-bindings/interrupt-controller/irq.h> i2c { @@ -104,10 +105,9 @@ examples: codec@1a { compatible = "realtek,rt5682s"; reg = <0x1a>; - interrupt-parent = <&gpio>; - interrupts = <TEGRA_GPIO(U, 6) IRQ_TYPE_LEVEL_HIGH>; + interrupts = <6 IRQ_TYPE_LEVEL_HIGH>; realtek,ldo1-en-gpios = - <&gpio TEGRA_GPIO(R, 2) GPIO_ACTIVE_HIGH>; + <&gpio 2 GPIO_ACTIVE_HIGH>; realtek,dmic1-data-pin = <1>; realtek,dmic1-clk-pin = <1>; realtek,jd-src = <1>; diff --git a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml index c2930d65728e..e17c0245f77a 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rsnd.yaml @@ -123,9 +123,7 @@ properties: $ref: audio-graph-port.yaml# unevaluatedProperties: false -# use patternProperties to avoid naming "xxx,yyy" issue -patternProperties: - "^rcar_sound,dvc$": + rcar_sound,dvc: description: DVC subnode. type: object patternProperties: @@ -141,7 +139,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,mix$": + rcar_sound,mix: description: MIX subnode. type: object patternProperties: @@ -150,7 +148,7 @@ patternProperties: # no properties additionalProperties: false - "^rcar_sound,ctu$": + rcar_sound,ctu: description: CTU subnode. type: object patternProperties: @@ -159,7 +157,7 @@ patternProperties: # no properties additionalProperties: false - "^rcar_sound,src$": + rcar_sound,src: description: SRC subnode. type: object patternProperties: @@ -182,7 +180,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,ssiu$": + rcar_sound,ssiu: description: SSIU subnode. type: object patternProperties: @@ -202,7 +200,7 @@ patternProperties: - dma-names additionalProperties: false - "^rcar_sound,ssi$": + rcar_sound,ssi: description: SSI subnode. type: object patternProperties: @@ -239,7 +237,7 @@ patternProperties: additionalProperties: false # For DAI base - "^rcar_sound,dai$": + rcar_sound,dai: description: DAI subnode. type: object patternProperties: diff --git a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml index 414ff8035a4e..7e8d252f7bca 100644 --- a/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml +++ b/Documentation/devicetree/bindings/sound/renesas,rz-ssi.yaml @@ -4,7 +4,7 @@ $id: http://devicetree.org/schemas/sound/renesas,rz-ssi.yaml# $schema: http://devicetree.org/meta-schemas/core.yaml# -title: Renesas RZ/G2L ASoC Sound Serial Interface (SSIF-2) +title: Renesas RZ/{G2L,V2L} ASoC Sound Serial Interface (SSIF-2) maintainers: - Biju Das <biju.das.jz@bp.renesas.com> @@ -14,6 +14,7 @@ properties: items: - enum: - renesas,r9a07g044-ssi # RZ/G2{L,LC} + - renesas,r9a07g054-ssi # RZ/V2L - const: renesas,rz-ssi reg: diff --git a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml index 5fff586dc802..97f83eeaf091 100644 --- a/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,aries-wm8994.yaml @@ -27,17 +27,20 @@ properties: sound-dai: minItems: 2 maxItems: 2 - $ref: /schemas/types.yaml#/definitions/phandle-array description: | phandles to the I2S controller and bluetooth codec, in that order + required: + - sound-dai codec: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array + maxItems: 1 description: phandle to the WM8994 CODEC + required: + - sound-dai samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array diff --git a/Documentation/devicetree/bindings/sound/samsung,arndale.yaml b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml new file mode 100644 index 000000000000..cea2bf3544f0 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,arndale.yaml @@ -0,0 +1,45 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,arndale.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Insignal Arndale boards audio complex + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + enum: + - samsung,arndale-alc5631 + - samsung,arndale-rt5631 + - samsung,arndale-wm1811 + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,audio-cpu: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - samsung,audio-codec + - samsung,audio-cpu + +additionalProperties: false + +examples: + - | + sound { + compatible = "samsung,arndale-rt5631"; + samsung,audio-cpu = <&i2s0>; + samsung,audio-codec = <&rt5631>; + }; diff --git a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml index 095775c598fa..ec50bcb4af5f 100644 --- a/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,midas-audio.yaml @@ -21,7 +21,6 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: phandle to the I2S controller required: @@ -31,7 +30,6 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array maxItems: 1 description: phandle to the WM1811 CODEC required: diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml index e8122bc87362..db2513f3e168 100644 --- a/Documentation/devicetree/bindings/sound/samsung,odroid.yaml +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.yaml @@ -37,18 +37,15 @@ properties: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array description: phandles to the I2S controllers codec: type: object properties: sound-dai: - $ref: /schemas/types.yaml#/definitions/phandle-array - description: | - List of phandles to the CODEC nodes, - first entry must be corresponding to the MAX98090 CODEC and - the second entry must be the phandle of the HDMI IP block node. + items: + - description: phandle of the MAX98090 CODEC + - description: phandle of the HDMI IP block node samsung,audio-routing: $ref: /schemas/types.yaml#/definitions/non-unique-string-array diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt b/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt deleted file mode 100644 index 4686646fb122..000000000000 --- a/Documentation/devicetree/bindings/sound/samsung,smdk-wm8994.txt +++ /dev/null @@ -1,14 +0,0 @@ -Samsung SMDK audio complex - -Required properties: -- compatible : "samsung,smdk-wm8994" -- samsung,i2s-controller: The phandle of the Samsung I2S0 controller -- samsung,audio-codec: The phandle of the WM8994 audio codec -Example: - -sound { - compatible = "samsung,smdk-wm8994"; - - samsung,i2s-controller = <&i2s0>; - samsung,audio-codec = <&wm8994>; -}; diff --git a/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml new file mode 100644 index 000000000000..cb51af90435e --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,smdk5250.yaml @@ -0,0 +1,38 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,smdk5250.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung SMDK5250 audio complex with WM8994 codec + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + const: samsung,smdk-wm8994 + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + + samsung,i2s-controller: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - samsung,audio-codec + - samsung,i2s-controller + +additionalProperties: false + +examples: + - | + sound { + compatible = "samsung,smdk-wm8994"; + samsung,i2s-controller = <&i2s0>; + samsung,audio-codec = <&wm8994>; + }; diff --git a/Documentation/devicetree/bindings/sound/samsung,snow.yaml b/Documentation/devicetree/bindings/sound/samsung,snow.yaml new file mode 100644 index 000000000000..0c3b3302b842 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,snow.yaml @@ -0,0 +1,74 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,snow.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Google Snow audio complex with MAX9809x codec + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + enum: + - google,snow-audio-max98090 + - google,snow-audio-max98091 + - google,snow-audio-max98095 + + codec: + type: object + properties: + sound-dai: + description: List of phandles to the CODEC and HDMI IP nodes. + items: + - description: Phandle to the MAX98090, MAX98091 or MAX98095 CODEC. + - description: Phandle to the HDMI IP block node. + required: + - sound-dai + + cpu: + type: object + properties: + sound-dai: + description: Phandle to the Samsung I2S controller. + maxItems: 1 + required: + - sound-dai + + samsung,audio-codec: + description: Phandle to the audio codec. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + samsung,i2s-controller: + description: Phandle to the Samsung I2S controller. + $ref: /schemas/types.yaml#/definitions/phandle + deprecated: true + + samsung,model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - codec + - cpu + +additionalProperties: false + +examples: + - | + sound { + compatible = "google,snow-audio-max98095"; + samsung,model = "Snow-I2S-MAX98095"; + + cpu { + sound-dai = <&i2s0 0>; + }; + + codec { + sound-dai = <&max98095 0>, <&hdmi>; + }; + }; diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt b/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt deleted file mode 100644 index f5ccc12ddc00..000000000000 --- a/Documentation/devicetree/bindings/sound/samsung,tm2-audio.txt +++ /dev/null @@ -1,42 +0,0 @@ -Samsung Exynos5433 TM2(E) audio complex with WM5110 codec - -Required properties: - - - compatible : "samsung,tm2-audio" - - model : the user-visible name of this sound complex - - audio-codec : the first entry should be phandle of the wm5110 audio - codec node, as described in ../mfd/arizona.txt; - the second entry should be phandle of the HDMI - transmitter node - - i2s-controller : the list of phandle and argument tuples pointing to - I2S controllers, the first entry should be I2S0 and - the second one I2S1 - - audio-amplifier : the phandle of the MAX98504 amplifier - - samsung,audio-routing : 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 for sources and sinks are the - WM5110's and MAX98504's pins and the jacks on the - board: HP, SPK, Main Mic, Sub Mic, Third Mic, - Headset Mic - - mic-bias-gpios : GPIO pin that enables the Main Mic bias regulator - - -Example: - -sound { - compatible = "samsung,tm2-audio"; - audio-codec = <&wm5110>, <&hdmi>; - i2s-controller = <&i2s0 0>, <&i2s1 0>; - audio-amplifier = <&max98504>; - mic-bias-gpios = <&gpr3 2 0>; - model = "wm5110"; - samsung,audio-routing = - "HP", "HPOUT1L", - "HP", "HPOUT1R", - "SPK", "SPKOUT", - "SPKOUT", "HPOUT2L", - "SPKOUT", "HPOUT2R", - "Main Mic", "MICBIAS2", - "IN1R", "Main Mic"; -}; diff --git a/Documentation/devicetree/bindings/sound/samsung,tm2.yaml b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml new file mode 100644 index 000000000000..74712d6f3ef4 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/samsung,tm2.yaml @@ -0,0 +1,80 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/samsung,tm2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos5433 TM2(E) audio complex with WM5110 codec + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + - Sylwester Nawrocki <s.nawrocki@samsung.com> + +properties: + compatible: + const: samsung,tm2-audio + + audio-amplifier: + description: Phandle to the MAX98504 amplifier. + $ref: /schemas/types.yaml#/definitions/phandle + + audio-codec: + description: Phandles to the codecs. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: Phandle to the WM5110 audio codec. + - description: Phandle to the HDMI transmitter node. + + samsung,audio-routing: + description: | + 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 for sources and sinks are the + WM5110's and MAX98504's pins and the jacks on the board: HP, SPK, Main + Mic, Sub Mic, Third Mic, Headset Mic. + $ref: /schemas/types.yaml#/definitions/non-unique-string-array + + i2s-controller: + description: Phandles to the I2S controllers. + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - description: Phandle to I2S0. + - description: Phandle to I2S1. + + mic-bias-gpios: + description: GPIO pin that enables the Main Mic bias regulator. + + model: + description: The user-visible name of this sound complex. + $ref: /schemas/types.yaml#/definitions/string + +required: + - compatible + - audio-amplifier + - audio-codec + - samsung,audio-routing + - i2s-controller + - mic-bias-gpios + - model + +additionalProperties: false + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + + sound { + compatible = "samsung,tm2-audio"; + audio-codec = <&wm5110>, <&hdmi>; + i2s-controller = <&i2s0 0>, <&i2s1 0>; + audio-amplifier = <&max98504>; + mic-bias-gpios = <&gpr3 2 GPIO_ACTIVE_HIGH>; + model = "wm5110"; + samsung,audio-routing = "HP", "HPOUT1L", + "HP", "HPOUT1R", + "SPK", "SPKOUT", + "SPKOUT", "HPOUT2L", + "SPKOUT", "HPOUT2R", + "RCV", "HPOUT3L", + "RCV", "HPOUT3R"; + }; diff --git a/Documentation/devicetree/bindings/sound/simple-card.yaml b/Documentation/devicetree/bindings/sound/simple-card.yaml index 45fd9fd9eb54..b261d49b9ddb 100644 --- a/Documentation/devicetree/bindings/sound/simple-card.yaml +++ b/Documentation/devicetree/bindings/sound/simple-card.yaml @@ -48,6 +48,15 @@ definitions: It is useful for some aCPUs with fixed clocks. $ref: /schemas/types.yaml#/definitions/flag + system-clock-fixed: + description: | + Specifies that the clock frequency should not be modified. + Implied when system-clock-frequency is specified, but can be used when + a clock is mapped to the device whose frequency cannot or should not be + changed. When mclk-fs is also specified, this restricts the device to a + single fixed sampling rate. + $ref: /schemas/types.yaml#/definitions/flag + mclk-fs: description: | Multiplication factor between stream rate and codec mclk. @@ -134,6 +143,8 @@ definitions: $ref: "#/definitions/system-clock-frequency" system-clock-direction-out: $ref: "#/definitions/system-clock-direction-out" + system-clock-fixed: + $ref: "#/definitions/system-clock-fixed" required: - sound-dai @@ -156,45 +167,45 @@ properties: description: User specified audio sound card name. $ref: /schemas/types.yaml#/definitions/string -# use patternProperties to avoid naming "xxx,yyy" issue -patternProperties: - "^simple-audio-card,widgets$": + simple-audio-card,widgets: $ref: "#/definitions/widgets" - "^simple-audio-card,routing$": + simple-audio-card,routing: $ref: "#/definitions/routing" - "^simple-audio-card,cpu(@[0-9a-f]+)?": - $ref: "#/definitions/dai" - "^simple-audio-card,codec(@[0-9a-f]+)?": - $ref: "#/definitions/dai" # common properties - "^simple-audio-card,frame-master$": + simple-audio-card,frame-master: $ref: "#/definitions/frame-master" - "^simple-audio-card,bitclock-master$": + simple-audio-card,bitclock-master: $ref: "#/definitions/bitclock-master" - "^simple-audio-card,frame-inversion$": + simple-audio-card,frame-inversion: $ref: "#/definitions/frame-inversion" - "^simple-audio-card,bitclock-inversion$": + simple-audio-card,bitclock-inversion: $ref: "#/definitions/bitclock-inversion" - "^simple-audio-card,format$": + simple-audio-card,format: $ref: "#/definitions/format" - "^simple-audio-card,mclk-fs$": + simple-audio-card,mclk-fs: $ref: "#/definitions/mclk-fs" - "^simple-audio-card,aux-devs$": + simple-audio-card,aux-devs: $ref: "#/definitions/aux-devs" - "^simple-audio-card,convert-rate$": + simple-audio-card,convert-rate: $ref: "#/definitions/convert-rate" - "^simple-audio-card,convert-channels$": + simple-audio-card,convert-channels: $ref: "#/definitions/convert-channels" - "^simple-audio-card,prefix$": + simple-audio-card,prefix: $ref: "#/definitions/prefix" - "^simple-audio-card,pin-switches$": + simple-audio-card,pin-switches: $ref: "#/definitions/pin-switches" - "^simple-audio-card,hp-det-gpio$": + simple-audio-card,hp-det-gpio: maxItems: 1 - "^simple-audio-card,mic-det-gpio$": + simple-audio-card,mic-det-gpio: maxItems: 1 +patternProperties: + "^simple-audio-card,cpu(@[0-9a-f]+)?$": + $ref: "#/definitions/dai" + "^simple-audio-card,codec(@[0-9a-f]+)?$": + $ref: "#/definitions/dai" + "^simple-audio-card,dai-link(@[0-9a-f]+)?$": description: | Container for dai-link level properties and the CPU and CODEC sub-nodes. diff --git a/Documentation/devicetree/bindings/sound/snow.txt b/Documentation/devicetree/bindings/sound/snow.txt deleted file mode 100644 index 80fd9a87bb3f..000000000000 --- a/Documentation/devicetree/bindings/sound/snow.txt +++ /dev/null @@ -1,31 +0,0 @@ -Audio Binding for Snow boards - -Required properties: -- compatible : Can be one of the following, - "google,snow-audio-max98090" or - "google,snow-audio-max98091" or - "google,snow-audio-max98095" -- samsung,i2s-controller (deprecated): The phandle of the Samsung I2S controller -- samsung,audio-codec (deprecated): The phandle of the audio codec - -Required sub-nodes: - - - 'cpu' subnode with a 'sound-dai' property containing the phandle of the I2S - controller - - 'codec' subnode with a 'sound-dai' property containing list of phandles - to the CODEC nodes, first entry must be the phandle of the MAX98090, - MAX98091 or MAX98095 CODEC (exact device type is indicated by the compatible - string) and the second entry must be the phandle of the HDMI IP block node - -Optional: -- samsung,model: The name of the sound-card - -Example: - -sound { - compatible = "google,snow-audio-max98095"; - - samsung,model = "Snow-I2S-MAX98095"; - samsung,i2s-controller = <&i2s0>; - samsung,audio-codec = <&max98095>; -}; diff --git a/Documentation/devicetree/bindings/sound/sound-dai.yaml b/Documentation/devicetree/bindings/sound/sound-dai.yaml new file mode 100644 index 000000000000..61c6f7abc4e7 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/sound-dai.yaml @@ -0,0 +1,20 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/sound-dai.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Digital Audio Interface consumer Device Tree Bindings + +maintainers: + - Rob Herring <robh@kernel.org> + +select: true + +properties: + sound-dai: + $ref: /schemas/types.yaml#/definitions/phandle-array + description: A phandle plus args to digital audio interface provider(s) + +additionalProperties: true +... diff --git a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml index 1538d11ce9a8..b3dbcba33e41 100644 --- a/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml +++ b/Documentation/devicetree/bindings/sound/st,stm32-sai.yaml @@ -102,9 +102,11 @@ patternProperties: By default SAI sub-block is in asynchronous mode. Must contain the phandle and index of the SAI sub-block providing the synchronization. - allOf: - - $ref: /schemas/types.yaml#/definitions/phandle-array - - maxItems: 1 + $ref: /schemas/types.yaml#/definitions/phandle-array + items: + - items: + - description: phandle of the SAI sub-block + - description: index of the SAI sub-block st,iec60958: description: @@ -113,8 +115,7 @@ patternProperties: By default, custom protocol is assumed, meaning that protocol is configured according to protocol defined in related DAI link node, such as i2s, left justified, right justified, dsp and pdm protocols. - allOf: - - $ref: /schemas/types.yaml#/definitions/flag + $ref: /schemas/types.yaml#/definitions/flag "#clock-cells": description: Configure the SAI device as master clock provider. diff --git a/Documentation/devicetree/bindings/sound/tas5805m.yaml b/Documentation/devicetree/bindings/sound/tas5805m.yaml new file mode 100644 index 000000000000..3aade02d8a96 --- /dev/null +++ b/Documentation/devicetree/bindings/sound/tas5805m.yaml @@ -0,0 +1,56 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/sound/tas5805m.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: TAS5805M audio amplifier + +maintainers: + - Daniel Beer <daniel.beer@igorinstitute.com> + +description: | + The TAS5805M is a class D audio amplifier with a built-in DSP. + +properties: + compatible: + enum: + - ti,tas5805m + + reg: + maxItems: 1 + description: | + I2C address of the amplifier. See the datasheet for possible values. + + pvdd-supply: + description: | + Regulator for audio power supply (PVDD in the datasheet). + + pdn-gpios: + description: | + Power-down control GPIO (PDN pin in the datasheet). + + ti,dsp-config-name: + description: | + The name of the DSP configuration that should be loaded for this + instance. Configuration blobs are sequences of register writes + generated from TI's PPC3 tool. + $ref: /schemas/types.yaml#/definitions/string + +examples: + - | + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + tas5805m: tas5805m@2c { + reg = <0x2c>; + compatible = "ti,tas5805m"; + + pvdd-supply = <&audiopwr>; + pdn-gpios = <&tlmm 160 0>; + + ti,dsp-config-name = "mono_pbtl_48khz"; + }; + }; + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml index d77c8283526d..2ad17b361db0 100644 --- a/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml +++ b/Documentation/devicetree/bindings/sound/tlv320adcx140.yaml @@ -176,13 +176,12 @@ patternProperties: 4 - Drive weak low and active high 5 - Drive Hi-Z and active high - allOf: - - $ref: /schemas/types.yaml#/definitions/uint32-array - - minItems: 2 - maxItems: 2 - items: - maximum: 15 - default: [2, 2] + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 2 + maxItems: 2 + items: + maximum: 15 + default: [2, 2] required: - compatible diff --git a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt index e372303697dc..bbad98d5b986 100644 --- a/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt +++ b/Documentation/devicetree/bindings/sound/tlv320aic31xx.txt @@ -58,7 +58,7 @@ The pins can be used in referring sound node's audio-routing property. Example: #include <dt-bindings/gpio/gpio.h> -#include <dt-bindings/sound/tlv320aic31xx-micbias.h> +#include <dt-bindings/sound/tlv320aic31xx.h> tlv320aic31xx: tlv320aic31xx@18 { compatible = "ti,tlv320aic311x"; diff --git a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt index b93a2b3e029d..51ddbc509382 100644 --- a/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt +++ b/Documentation/devicetree/bindings/soundwire/qcom,sdw.txt @@ -22,7 +22,19 @@ board specific bus parameters. - interrupts: Usage: required Value type: <prop-encoded-array> - Definition: should specify the SoundWire Controller IRQ + Definition: should specify the SoundWire Controller core and optional + wake IRQ + +- interrupt-names: + Usage: Optional + Value type: boolean + Value type: <stringlist> + Definition: should be "core" for core and "wakeup" for wake interrupt. + +- wakeup-source: + Usage: Optional + Value type: boolean + Definition: should specify if SoundWire Controller is wake up capable. - clock-names: Usage: required diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml new file mode 100644 index 000000000000..818130b11bb9 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mt65xx.yaml @@ -0,0 +1,107 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mediatek,spi-mt65xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI Bus controller for MediaTek ARM SoCs + +maintainers: + - Leilk Liu <leilk.liu@mediatek.com> + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + oneOf: + - items: + - enum: + - mediatek,mt7629-spi + - const: mediatek,mt7622-spi + - items: + - enum: + - mediatek,mt8516-spi + - const: mediatek,mt2712-spi + - items: + - enum: + - mediatek,mt6779-spi + - mediatek,mt8186-spi + - mediatek,mt8192-spi + - mediatek,mt8195-spi + - const: mediatek,mt6765-spi + - items: + - enum: + - mediatek,mt7986-spi-ipm + - const: mediatek,spi-ipm + - items: + - enum: + - mediatek,mt2701-spi + - mediatek,mt2712-spi + - mediatek,mt6589-spi + - mediatek,mt6765-spi + - mediatek,mt6893-spi + - mediatek,mt7622-spi + - mediatek,mt8135-spi + - mediatek,mt8173-spi + - mediatek,mt8183-spi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + items: + - description: clock used for the parent clock + - description: clock used for the muxes clock + - description: clock used for the clock gate + + clock-names: + items: + - const: parent-clk + - const: sel-clk + - const: spi-clk + + mediatek,pad-select: + $ref: /schemas/types.yaml#/definitions/uint32-array + minItems: 1 + maxItems: 4 + items: + enum: [0, 1, 2, 3] + description: + specify which pins group(ck/mi/mo/cs) spi controller used. + This is an array. + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + - '#address-cells' + - '#size-cells' + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8173-clk.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi@1100a000 { + compatible = "mediatek,mt8173-spi"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x1100a000 0x1000>; + interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>; + clocks = <&topckgen CLK_TOP_SYSPLL3_D2>, + <&topckgen CLK_TOP_SPI_SEL>, + <&pericfg CLK_PERI_SPI0>; + clock-names = "parent-clk", "sel-clk", "spi-clk"; + cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; + mediatek,pad-select = <1>, <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml index 4e4694e3d539..41e60fe4b09f 100644 --- a/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-mtk-nor.yaml @@ -18,7 +18,7 @@ description: | capability of this controller. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: @@ -30,6 +30,7 @@ properties: - mediatek,mt7622-nor - mediatek,mt7623-nor - mediatek,mt7629-nor + - mediatek,mt8186-nor - mediatek,mt8192-nor - mediatek,mt8195-nor - enum: @@ -49,6 +50,8 @@ properties: - description: clock used for controller - description: clock used for nor dma bus. this depends on hardware design, so this is optional. + - description: clock used for controller axi slave bus. + this depends on hardware design, so it is optional. clock-names: minItems: 2 @@ -56,6 +59,7 @@ properties: - const: spi - const: sf - const: axi + - const: axi_s required: - compatible diff --git a/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml new file mode 100644 index 000000000000..7977799a8ee1 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mediatek,spi-slave-mt27xx.yaml @@ -0,0 +1,58 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mediatek,spi-slave-mt27xx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: SPI Slave controller for MediaTek ARM SoCs + +maintainers: + - Leilk Liu <leilk.liu@mediatek.com> + +allOf: + - $ref: "/schemas/spi/spi-controller.yaml#" + +properties: + compatible: + enum: + - mediatek,mt2712-spi-slave + - mediatek,mt8195-spi-slave + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: spi + +required: + - compatible + - reg + - interrupts + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt2712-clk.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi@10013000 { + compatible = "mediatek,mt2712-spi-slave"; + reg = <0x10013000 0x100>; + interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_LOW>; + clocks = <&infracfg CLK_INFRA_AO_SPI1>; + clock-names = "spi"; + assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>; + assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>; + }; diff --git a/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml new file mode 100644 index 000000000000..ece261b8e963 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/microchip,mpfs-spi.yaml @@ -0,0 +1,52 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/microchip,mpfs-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS {Q,}SPI Controller Device Tree Bindings + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +allOf: + - $ref: spi-controller.yaml# + +properties: + compatible: + enum: + - microchip,mpfs-spi + - microchip,mpfs-qspi + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + clock-names: + maxItems: 1 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +unevaluatedProperties: false + +examples: + - | + #include "dt-bindings/clock/microchip,mpfs-clock.h" + spi@20108000 { + compatible = "microchip,mpfs-spi"; + reg = <0x20108000 0x1000>; + clocks = <&clkcfg CLK_SPI0>; + interrupt-parent = <&plic>; + interrupts = <54>; + spi-max-frequency = <25000000>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml new file mode 100644 index 000000000000..9202c44b4478 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/mxicy,mx25f0a-spi.yaml @@ -0,0 +1,65 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/mxicy,mx25f0a-spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Macronix SPI controller device tree bindings + +maintainers: + - Miquel Raynal <miquel.raynal@bootlin.com> + +allOf: + - $ref: "spi-controller.yaml#" + +properties: + compatible: + const: mxicy,mx25f0a-spi + + reg: + minItems: 2 + maxItems: 2 + + reg-names: + items: + - const: regs + - const: dirmap + + interrupts: + maxItems: 1 + + clocks: + minItems: 3 + maxItems: 3 + + clock-names: + items: + - const: send_clk + - const: send_dly_clk + - const: ps_clk + + nand-ecc-engine: + description: NAND ECC engine used by the SPI controller in order to perform + on-the-fly correction when using a SPI-NAND memory. + $ref: /schemas/types.yaml#/definitions/phandle + +required: + - compatible + - reg + - reg-names + - clocks + - clock-names + +unevaluatedProperties: false + +examples: + - | + spi@43c30000 { + compatible = "mxicy,mx25f0a-spi"; + reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>; + reg-names = "regs", "dirmap"; + clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>; + clock-names = "send_clk", "send_dly_clk", "ps_clk"; + #address-cells = <1>; + #size-cells = <0>; + }; diff --git a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml index 35a8045b2c70..0296edd1de22 100644 --- a/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml +++ b/Documentation/devicetree/bindings/spi/nvidia,tegra210-quad.yaml @@ -19,6 +19,7 @@ properties: - nvidia,tegra210-qspi - nvidia,tegra186-qspi - nvidia,tegra194-qspi + - nvidia,tegra234-qspi reg: maxItems: 1 @@ -106,7 +107,7 @@ examples: dma-names = "rx", "tx"; flash@0 { - compatible = "spi-nor"; + compatible = "jedec,spi-nor"; reg = <0>; spi-max-frequency = <104000000>; spi-tx-bus-width = <2>; diff --git a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml index 055524fe8327..5a60fba14bba 100644 --- a/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml +++ b/Documentation/devicetree/bindings/spi/qcom,spi-qcom-qspi.yaml @@ -16,7 +16,7 @@ description: The QSPI controller allows SPI protocol communication in single, as NOR flash. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml index 76e6d9e52fc7..2c3c6bd6ec45 100644 --- a/Documentation/devicetree/bindings/spi/renesas,rspi.yaml +++ b/Documentation/devicetree/bindings/spi/renesas,rspi.yaml @@ -22,7 +22,8 @@ properties: - renesas,rspi-r7s72100 # RZ/A1H - renesas,rspi-r7s9210 # RZ/A2 - renesas,r9a07g044-rspi # RZ/G2{L,LC} - - const: renesas,rspi-rz # RZ/A and RZ/G2{L,LC} + - renesas,r9a07g054-rspi # RZ/V2L + - const: renesas,rspi-rz - items: - enum: @@ -124,6 +125,7 @@ allOf: enum: - renesas,qspi - renesas,r9a07g044-rspi + - renesas,r9a07g054-rspi then: required: - resets diff --git a/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml new file mode 100644 index 000000000000..f0db3fb3d688 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/samsung,spi-peripheral-props.yaml @@ -0,0 +1,33 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/samsung,spi-peripheral-props.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Peripheral-specific properties for Samsung S3C/S5P/Exynos SoC SPI controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: + See spi-peripheral-props.yaml for more info. + +properties: + controller-data: + type: object + additionalProperties: false + + properties: + samsung,spi-feedback-delay: + description: | + The sampling phase shift to be applied on the miso line (to account + for any lag in the miso line). Valid values: + - 0: No phase shift. + - 1: 90 degree phase shift sampling. + - 2: 180 degree phase shift sampling. + - 3: 270 degree phase shift sampling. + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [0, 1, 2, 3] + default: 0 + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/samsung,spi.yaml b/Documentation/devicetree/bindings/spi/samsung,spi.yaml new file mode 100644 index 000000000000..bf9a76d931d2 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/samsung,spi.yaml @@ -0,0 +1,188 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/samsung,spi.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung S3C/S5P/Exynos SoC SPI controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: + All the SPI controller nodes should be represented in the aliases node using + the following format 'spi{n}' where n is a unique number for the alias. + +properties: + compatible: + oneOf: + - enum: + - samsung,s3c2443-spi # for S3C2443, S3C2416 and S3C2450 + - samsung,s3c6410-spi + - samsung,s5pv210-spi # for S5PV210 and S5PC110 + - samsung,exynos5433-spi + - tesla,fsd-spi + - const: samsung,exynos7-spi + deprecated: true + + clocks: + minItems: 2 + maxItems: 3 + + clock-names: + minItems: 2 + maxItems: 3 + + cs-gpios: true + + dmas: + minItems: 2 + maxItems: 2 + + dma-names: + items: + - const: tx + - const: rx + + interrupts: + maxItems: 1 + + no-cs-readback: + description: + The CS line is disconnected, therefore the device should not operate + based on CS signalling. + type: boolean + + num-cs: + minimum: 1 + maximum: 4 + default: 1 + + samsung,spi-src-clk: + description: + If the spi controller includes a internal clock mux to select the clock + source for the spi bus clock, this property can be used to indicate the + clock to be used for driving the spi bus clock. If not specified, the + clock number 0 is used as default. + $ref: /schemas/types.yaml#/definitions/uint32 + default: 0 + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - dmas + - dma-names + - interrupts + - reg + +allOf: + - $ref: spi-controller.yaml# + - if: + properties: + compatible: + contains: + const: samsung,exynos5433-spi + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: spi + - enum: + - spi_busclk0 + - spi_busclk1 + - spi_busclk2 + - spi_busclk3 + - const: spi_ioclk + else: + properties: + clocks: + minItems: 2 + maxItems: 2 + clock-names: + items: + - const: spi + - enum: + - spi_busclk0 + - spi_busclk1 + - spi_busclk2 + - spi_busclk3 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5433.h> + #include <dt-bindings/clock/samsung,s2mps11.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/gpio/gpio.h> + + spi@14d30000 { + compatible = "samsung,exynos5433-spi"; + reg = <0x14d30000 0x100>; + interrupts = <GIC_SPI 433 IRQ_TYPE_LEVEL_HIGH>; + dmas = <&pdma0 11>, <&pdma0 10>; + dma-names = "tx", "rx"; + #address-cells = <1>; + #size-cells = <0>; + clocks = <&cmu_peric CLK_PCLK_SPI1>, + <&cmu_peric CLK_SCLK_SPI1>, + <&cmu_peric CLK_SCLK_IOCLK_SPI1>; + clock-names = "spi", + "spi_busclk0", + "spi_ioclk"; + samsung,spi-src-clk = <0>; + pinctrl-names = "default"; + pinctrl-0 = <&spi1_bus>; + num-cs = <1>; + + cs-gpios = <&gpd6 3 GPIO_ACTIVE_HIGH>; + + audio-codec@0 { + compatible = "wlf,wm5110"; + reg = <0x0>; + spi-max-frequency = <20000000>; + interrupt-parent = <&gpa0>; + interrupts = <4 IRQ_TYPE_NONE>; + clocks = <&pmu_system_controller 0>, + <&s2mps13_osc S2MPS11_CLK_BT>; + clock-names = "mclk1", "mclk2"; + + gpio-controller; + #gpio-cells = <2>; + interrupt-controller; + #interrupt-cells = <2>; + + wlf,micd-detect-debounce = <300>; + wlf,micd-bias-start-time = <0x1>; + wlf,micd-rate = <0x7>; + wlf,micd-dbtime = <0x2>; + wlf,micd-force-micbias; + wlf,micd-configs = <0x0 1 0>; + wlf,hpdet-channel = <1>; + wlf,gpsw = <0x1>; + wlf,inmode = <2 0 2 0>; + + wlf,reset = <&gpc0 7 GPIO_ACTIVE_HIGH>; + wlf,ldoena = <&gpf0 0 GPIO_ACTIVE_HIGH>; + + /* core supplies */ + AVDD-supply = <&ldo18_reg>; + DBVDD1-supply = <&ldo18_reg>; + CPVDD-supply = <&ldo18_reg>; + DBVDD2-supply = <&ldo18_reg>; + DBVDD3-supply = <&ldo18_reg>; + SPKVDDL-supply = <&ldo18_reg>; + SPKVDDR-supply = <&ldo18_reg>; + + controller-data { + samsung,spi-feedback-delay = <0>; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/spi/spi-controller.yaml b/Documentation/devicetree/bindings/spi/spi-controller.yaml index 36b72518f565..ebb4d5f1cf4f 100644 --- a/Documentation/devicetree/bindings/spi/spi-controller.yaml +++ b/Documentation/devicetree/bindings/spi/spi-controller.yaml @@ -93,9 +93,7 @@ properties: patternProperties: "^.*@[0-9a-f]+$": type: object - - allOf: - - $ref: spi-peripheral-props.yaml + $ref: spi-peripheral-props.yaml required: - compatible @@ -139,4 +137,11 @@ examples: spi-max-frequency = <100000>; reg = <1>; }; + + flash@2 { + compatible = "jedec,spi-nor"; + spi-max-frequency = <50000000>; + reg = <2>, <3>; + stacked-memories = /bits/ 64 <0x10000000 0x10000000>; + }; }; diff --git a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt b/Documentation/devicetree/bindings/spi/spi-mt65xx.txt deleted file mode 100644 index 2a24969159cc..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-mt65xx.txt +++ /dev/null @@ -1,68 +0,0 @@ -Binding for MTK SPI controller - -Required properties: -- compatible: should be one of the following. - - mediatek,mt2701-spi: for mt2701 platforms - - mediatek,mt2712-spi: for mt2712 platforms - - mediatek,mt6589-spi: for mt6589 platforms - - mediatek,mt6765-spi: for mt6765 platforms - - mediatek,mt7622-spi: for mt7622 platforms - - "mediatek,mt7629-spi", "mediatek,mt7622-spi": for mt7629 platforms - - mediatek,mt8135-spi: for mt8135 platforms - - mediatek,mt8173-spi: for mt8173 platforms - - mediatek,mt8183-spi: for mt8183 platforms - - mediatek,mt6893-spi: for mt6893 platforms - - "mediatek,mt8192-spi", "mediatek,mt6765-spi": for mt8192 platforms - - "mediatek,mt8195-spi", "mediatek,mt6765-spi": for mt8195 platforms - - "mediatek,mt8516-spi", "mediatek,mt2712-spi": for mt8516 platforms - - "mediatek,mt6779-spi", "mediatek,mt6765-spi": for mt6779 platforms - -- #address-cells: should be 1. - -- #size-cells: should be 0. - -- reg: Address and length of the register set for the device - -- interrupts: Should contain spi interrupt - -- clocks: phandles to input clocks. - The first should be one of the following. It's PLL. - - <&clk26m>: specify parent clock 26MHZ. - - <&topckgen CLK_TOP_SYSPLL3_D2>: specify parent clock 109MHZ. - It's the default one. - - <&topckgen CLK_TOP_SYSPLL4_D2>: specify parent clock 78MHZ. - - <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ. - - <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ. - The second should be <&topckgen CLK_TOP_SPI_SEL>. It's clock mux. - The third is <&pericfg CLK_PERI_SPI0>. It's clock gate. - -- clock-names: shall be "parent-clk" for the parent clock, "sel-clk" for the - muxes clock, and "spi-clk" for the clock gate. - -Optional properties: --cs-gpios: see spi-bus.txt. - -- mediatek,pad-select: specify which pins group(ck/mi/mo/cs) spi - controller used. This is an array, the element value should be 0~3, - only required for MT8173. - 0: specify GPIO69,70,71,72 for spi pins. - 1: specify GPIO102,103,104,105 for spi pins. - 2: specify GPIO128,129,130,131 for spi pins. - 3: specify GPIO5,6,7,8 for spi pins. - -Example: - -- SoC Specific Portion: -spi: spi@1100a000 { - compatible = "mediatek,mt8173-spi"; - #address-cells = <1>; - #size-cells = <0>; - reg = <0 0x1100a000 0 0x1000>; - interrupts = <GIC_SPI 110 IRQ_TYPE_LEVEL_LOW>; - clocks = <&topckgen CLK_TOP_SYSPLL3_D2>, - <&topckgen CLK_TOP_SPI_SEL>, - <&pericfg CLK_PERI_SPI0>; - clock-names = "parent-clk", "sel-clk", "spi-clk"; - cs-gpios = <&pio 105 GPIO_ACTIVE_LOW>, <&pio 72 GPIO_ACTIVE_LOW>; - mediatek,pad-select = <1>, <0>; -}; diff --git a/Documentation/devicetree/bindings/spi/spi-mxic.txt b/Documentation/devicetree/bindings/spi/spi-mxic.txt deleted file mode 100644 index 529f2dab2648..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-mxic.txt +++ /dev/null @@ -1,34 +0,0 @@ -Macronix SPI controller Device Tree Bindings --------------------------------------------- - -Required properties: -- compatible: should be "mxicy,mx25f0a-spi" -- #address-cells: should be 1 -- #size-cells: should be 0 -- reg: should contain 2 entries, one for the registers and one for the direct - mapping area -- reg-names: should contain "regs" and "dirmap" -- interrupts: interrupt line connected to the SPI controller -- clock-names: should contain "ps_clk", "send_clk" and "send_dly_clk" -- clocks: should contain 3 entries for the "ps_clk", "send_clk" and - "send_dly_clk" clocks - -Example: - - spi@43c30000 { - compatible = "mxicy,mx25f0a-spi"; - reg = <0x43c30000 0x10000>, <0xa0000000 0x20000000>; - reg-names = "regs", "dirmap"; - clocks = <&clkwizard 0>, <&clkwizard 1>, <&clkc 18>; - clock-names = "send_clk", "send_dly_clk", "ps_clk"; - #address-cells = <1>; - #size-cells = <0>; - - flash@0 { - compatible = "jedec,spi-nor"; - reg = <0>; - spi-max-frequency = <25000000>; - spi-tx-bus-width = <4>; - spi-rx-bus-width = <4>; - }; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml index 283815d59e85..1b552c298277 100644 --- a/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml +++ b/Documentation/devicetree/bindings/spi/spi-nxp-fspi.yaml @@ -7,7 +7,8 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: NXP Flex Serial Peripheral Interface (FSPI) maintainers: - - Kuldeep Singh <kuldeep.singh@nxp.com> + - Han Xu <han.xu@nxp.com> + - Kuldeep Singh <singh.kuldeep87k@gmail.com> allOf: - $ref: "spi-controller.yaml#" diff --git a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml index 5dd209206e88..5e32928c4fc3 100644 --- a/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml +++ b/Documentation/devicetree/bindings/spi/spi-peripheral-props.yaml @@ -23,8 +23,9 @@ properties: minItems: 1 maxItems: 256 items: - minimum: 0 - maximum: 256 + items: + - minimum: 0 + maximum: 256 description: Chip select used by the device. @@ -82,8 +83,34 @@ properties: description: Delay, in microseconds, after a write transfer. + stacked-memories: + description: Several SPI memories can be wired in stacked mode. + This basically means that either a device features several chip + selects, or that different devices must be seen as a single + bigger chip. This basically doubles (or more) the total address + space with only a single additional wire, while still needing + to repeat the commands when crossing a chip boundary. The size of + each chip should be provided as members of the array. + $ref: /schemas/types.yaml#/definitions/uint64-array + minItems: 2 + maxItems: 4 + + parallel-memories: + description: Several SPI memories can be wired in parallel mode. + The devices are physically on a different buses but will always + act synchronously as each data word is spread across the + different memories (eg. even bits are stored in one memory, odd + bits in the other). This basically doubles the address space and + the throughput while greatly complexifying the wiring because as + many busses as devices must be wired. The size of each chip should + be provided as members of the array. + $ref: /schemas/types.yaml#/definitions/uint64-array + minItems: 2 + maxItems: 4 + # The controller specific properties go here. allOf: - $ref: cdns,qspi-nor-peripheral-props.yaml# + - $ref: samsung,spi-peripheral-props.yaml# additionalProperties: true diff --git a/Documentation/devicetree/bindings/spi/spi-pl022.yaml b/Documentation/devicetree/bindings/spi/spi-pl022.yaml index 6d633728fc2b..bda45ff3d294 100644 --- a/Documentation/devicetree/bindings/spi/spi-pl022.yaml +++ b/Documentation/devicetree/bindings/spi/spi-pl022.yaml @@ -38,9 +38,7 @@ properties: clock-names: items: - - enum: - - SSPCLK - - sspclk + - const: sspclk - const: apb_pclk pl022,autosuspend-delay: diff --git a/Documentation/devicetree/bindings/spi/spi-samsung.txt b/Documentation/devicetree/bindings/spi/spi-samsung.txt deleted file mode 100644 index 49028a4f5df1..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-samsung.txt +++ /dev/null @@ -1,122 +0,0 @@ -* Samsung SPI Controller - -The Samsung SPI controller is used to interface with various devices such as flash -and display controllers using the SPI communication interface. - -Required SoC Specific Properties: - -- compatible: should be one of the following. - - samsung,s3c2443-spi: for s3c2443, s3c2416 and s3c2450 platforms - - samsung,s3c6410-spi: for s3c6410 platforms - - samsung,s5pv210-spi: for s5pv210 and s5pc110 platforms - - samsung,exynos5433-spi: for exynos5433 compatible controllers - - samsung,exynos7-spi: for exynos7 platforms <DEPRECATED> - -- reg: physical base address of the controller and length of memory mapped - region. - -- interrupts: The interrupt number to the cpu. The interrupt specifier format - depends on the interrupt controller. - -- dmas : Two or more DMA channel specifiers following the convention outlined - in bindings/dma/dma.txt - -- dma-names: Names for the dma channels. There must be at least one channel - named "tx" for transmit and named "rx" for receive. - -- clocks: specifies the clock IDs provided to the SPI controller; they are - required for interacting with the controller itself, for synchronizing the bus - and as I/O clock (the latter is required by exynos5433 and exynos7). - -- clock-names: string names of the clocks in the 'clocks' property; for all the - the devices the names must be "spi", "spi_busclkN" (where N is determined by - "samsung,spi-src-clk"), while Exynos5433 should specify a third clock - "spi_ioclk" for the I/O clock. - -Required Board Specific Properties: - -- #address-cells: should be 1. -- #size-cells: should be 0. - -Optional Board Specific Properties: - -- samsung,spi-src-clk: If the spi controller includes a internal clock mux to - select the clock source for the spi bus clock, this property can be used to - indicate the clock to be used for driving the spi bus clock. If not specified, - the clock number 0 is used as default. - -- num-cs: Specifies the number of chip select lines supported. If - not specified, the default number of chip select lines is set to 1. - -- cs-gpios: should specify GPIOs used for chipselects (see spi-bus.txt) - -- no-cs-readback: the CS line is disconnected, therefore the device should not - operate based on CS signalling. - -SPI Controller specific data in SPI slave nodes: - -- The spi slave nodes should provide the following information which is required - by the spi controller. - - - samsung,spi-feedback-delay: The sampling phase shift to be applied on the - miso line (to account for any lag in the miso line). The following are the - valid values. - - - 0: No phase shift. - - 1: 90 degree phase shift sampling. - - 2: 180 degree phase shift sampling. - - 3: 270 degree phase shift sampling. - -Aliases: - -- All the SPI controller nodes should be represented in the aliases node using - the following format 'spi{n}' where n is a unique number for the alias. - - -Example: - -- SoC Specific Portion: - - spi_0: spi@12d20000 { - compatible = "samsung,exynos4210-spi"; - reg = <0x12d20000 0x100>; - interrupts = <0 66 0>; - dmas = <&pdma0 5 - &pdma0 4>; - dma-names = "tx", "rx"; - #address-cells = <1>; - #size-cells = <0>; - }; - -- Board Specific Portion: - - spi_0: spi@12d20000 { - #address-cells = <1>; - #size-cells = <0>; - pinctrl-names = "default"; - pinctrl-0 = <&spi0_bus>; - cs-gpios = <&gpa2 5 0>; - - w25q80bw@0 { - #address-cells = <1>; - #size-cells = <1>; - compatible = "w25x80"; - reg = <0>; - spi-max-frequency = <10000>; - - controller-data { - samsung,spi-feedback-delay = <0>; - }; - - partition@0 { - label = "U-Boot"; - reg = <0x0 0x40000>; - read-only; - }; - - partition@40000 { - label = "Kernel"; - reg = <0x40000 0xc0000>; - }; - }; - }; diff --git a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt b/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt deleted file mode 100644 index 9192724540fd..000000000000 --- a/Documentation/devicetree/bindings/spi/spi-slave-mt27xx.txt +++ /dev/null @@ -1,33 +0,0 @@ -Binding for MTK SPI Slave controller - -Required properties: -- compatible: should be one of the following. - - mediatek,mt2712-spi-slave: for mt2712 platforms - - mediatek,mt8195-spi-slave: for mt8195 platforms -- reg: Address and length of the register set for the device. -- interrupts: Should contain spi interrupt. -- clocks: phandles to input clocks. - It's clock gate, and should be <&infracfg CLK_INFRA_AO_SPI1>. -- clock-names: should be "spi" for the clock gate. - -Optional properties: -- assigned-clocks: it's mux clock, should be <&topckgen CLK_TOP_SPISLV_SEL>. -- assigned-clock-parents: parent of mux clock. - It's PLL, and should be one of the following. - - <&topckgen CLK_TOP_UNIVPLL1_D2>: specify parent clock 312MHZ. - It's the default one. - - <&topckgen CLK_TOP_UNIVPLL1_D4>: specify parent clock 156MHZ. - - <&topckgen CLK_TOP_UNIVPLL2_D4>: specify parent clock 104MHZ. - - <&topckgen CLK_TOP_UNIVPLL1_D8>: specify parent clock 78MHZ. - -Example: -- SoC Specific Portion: -spis1: spi@10013000 { - compatible = "mediatek,mt2712-spi-slave"; - reg = <0 0x10013000 0 0x100>; - interrupts = <GIC_SPI 283 IRQ_TYPE_LEVEL_LOW>; - clocks = <&infracfg CLK_INFRA_AO_SPI1>; - clock-names = "spi"; - assigned-clocks = <&topckgen CLK_TOP_SPISLV_SEL>; - assigned-clock-parents = <&topckgen CLK_TOP_UNIVPLL1_D2>; -}; diff --git a/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml new file mode 100644 index 000000000000..3a58cf0f1ec8 --- /dev/null +++ b/Documentation/devicetree/bindings/spi/spi-sunplus-sp7021.yaml @@ -0,0 +1,78 @@ +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause) +# Copyright (C) Sunplus Co., Ltd. 2021 +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/spi/spi-sunplus-sp7021.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Sunplus sp7021 SPI controller + +allOf: + - $ref: "spi-controller.yaml" + +maintainers: + - Li-hao Kuo <lhjeff911@gmail.com> + +properties: + compatible: + enum: + - sunplus,sp7021-spi + + reg: + items: + - description: the SPI master registers + - description: the SPI slave registers + + reg-names: + items: + - const: master + - const: slave + + interrupt-names: + items: + - const: dma_w + - const: master_risc + - const: slave_risc + + interrupts: + minItems: 3 + + clocks: + maxItems: 1 + + resets: + maxItems: 1 + +required: + - compatible + - reg + - reg-names + - interrupts + - interrupt-names + - clocks + - resets + - pinctrl-names + - pinctrl-0 + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + spi@9C002D80 { + compatible = "sunplus,sp7021-spi"; + reg = <0x9C002D80 0x80>, <0x9C002E00 0x80>; + reg-names = "master", "slave"; + interrupt-parent = <&intc>; + interrupt-names = "dma_w", + "master_risc", + "slave_risc"; + interrupts = <144 IRQ_TYPE_LEVEL_HIGH>, + <146 IRQ_TYPE_LEVEL_HIGH>, + <145 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clkc 0x32>; + resets = <&rstc 0x22>; + pinctrl-names = "default"; + pinctrl-0 = <&pins_spi0>; + }; +... diff --git a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml index fe014020da69..a3ab1a1f1eb4 100644 --- a/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml +++ b/Documentation/devicetree/bindings/spi/sprd,spi-adi.yaml @@ -44,7 +44,7 @@ description: | compatibility. allOf: - - $ref: /spi/spi-controller.yaml# + - $ref: /schemas/spi/spi-controller.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml new file mode 100644 index 000000000000..105725a127ab --- /dev/null +++ b/Documentation/devicetree/bindings/staging/net/wireless/silabs,wfx.yaml @@ -0,0 +1,137 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +# Copyright (c) 2020, Silicon Laboratories, Inc. +%YAML 1.2 +--- + +$id: http://devicetree.org/schemas/staging/net/wireless/silabs,wfx.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Silicon Labs WFxxx devicetree bindings + +maintainers: + - Jérôme Pouiller <jerome.pouiller@silabs.com> + +description: > + Support for the Wifi chip WFxxx from Silicon Labs. Currently, the only device + from the WFxxx series is the WF200 described here: + https://www.silabs.com/documents/public/data-sheets/wf200-datasheet.pdf + + The WF200 can be connected via SPI or via SDIO. + + For SDIO: + + Declaring the WFxxx chip in device tree is mandatory (usually, the VID/PID is + sufficient for the SDIO devices). + + It is recommended to declare a mmc-pwrseq on SDIO host above WFx. Without + it, you may encounter issues during reboot. The mmc-pwrseq should be + compatible with mmc-pwrseq-simple. Please consult + Documentation/devicetree/bindings/mmc/mmc-pwrseq-simple.yaml for more + information. + + For SPI: + + In add of the properties below, please consult + Documentation/devicetree/bindings/spi/spi-controller.yaml for optional SPI + related properties. + +properties: + compatible: + items: + - enum: + - silabs,brd4001a # WGM160P Evaluation Board + - silabs,brd8022a # WF200 Evaluation Board + - silabs,brd8023a # WFM200 Evaluation Board + - const: silabs,wf200 # Chip alone without antenna + + reg: + description: + When used on SDIO bus, <reg> must be set to 1. When used on SPI bus, it is + the chip select address of the device as defined in the SPI devices + bindings. + maxItems: 1 + + spi-max-frequency: true + + interrupts: + description: The interrupt line. Should be IRQ_TYPE_EDGE_RISING. When SPI is + used, this property is required. When SDIO is used, the "in-band" + interrupt provided by the SDIO bus is used unless an interrupt is defined + in the Device Tree. + maxItems: 1 + + reset-gpios: + description: (SPI only) Phandle of gpio that will be used to reset chip + during probe. Without this property, you may encounter issues with warm + boot. + + For SDIO, the reset gpio should declared using a mmc-pwrseq. + maxItems: 1 + + wakeup-gpios: + description: Phandle of gpio that will be used to wake-up chip. Without this + property, driver will disable most of power saving features. + maxItems: 1 + + silabs,antenna-config-file: + $ref: /schemas/types.yaml#/definitions/string + description: Use an alternative file for antenna configuration (aka + "Platform Data Set" in Silabs jargon). Default depends of "compatible" + string. For "silabs,wf200", the default is 'wf200.pds'. + + local-mac-address: true + + mac-address: true + +additionalProperties: false + +required: + - compatible + - reg + +examples: + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + spi { + #address-cells = <1>; + #size-cells = <0>; + + wifi@0 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_irq &wfx_gpios>; + reg = <0>; + interrupts-extended = <&gpio 16 IRQ_TYPE_EDGE_RISING>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + spi-max-frequency = <42000000>; + }; + }; + + - | + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interrupt-controller/irq.h> + + wfx_pwrseq: wfx_pwrseq { + compatible = "mmc-pwrseq-simple"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_reset>; + reset-gpios = <&gpio 13 GPIO_ACTIVE_LOW>; + }; + + mmc { + mmc-pwrseq = <&wfx_pwrseq>; + #address-cells = <1>; + #size-cells = <0>; + + wifi@1 { + compatible = "silabs,brd8022a", "silabs,wf200"; + pinctrl-names = "default"; + pinctrl-0 = <&wfx_wakeup>; + reg = <1>; + wakeup-gpios = <&gpio 12 GPIO_ACTIVE_HIGH>; + }; + }; +... diff --git a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt b/Documentation/devicetree/bindings/thermal/exynos-thermal.txt deleted file mode 100644 index 33004ce7e5df..000000000000 --- a/Documentation/devicetree/bindings/thermal/exynos-thermal.txt +++ /dev/null @@ -1,106 +0,0 @@ -* Exynos Thermal Management Unit (TMU) - -** Required properties: - -- compatible : One of the following: - "samsung,exynos3250-tmu" - "samsung,exynos4412-tmu" - "samsung,exynos4210-tmu" - "samsung,exynos5250-tmu" - "samsung,exynos5260-tmu" - "samsung,exynos5420-tmu" for TMU channel 0, 1 on Exynos5420 - "samsung,exynos5420-tmu-ext-triminfo" for TMU channels 2, 3 and 4 - Exynos5420 (Must pass triminfo base and triminfo clock) - "samsung,exynos5433-tmu" - "samsung,exynos7-tmu" -- reg : Address range of the thermal registers. For soc's which has multiple - instances of TMU and some registers are shared across all TMU's like - interrupt related then 2 set of register has to supplied. First set - belongs to register set of TMU instance and second set belongs to - registers shared with the TMU instance. - - NOTE: On Exynos5420, the TRIMINFO register is misplaced for TMU - channels 2, 3 and 4 - Use "samsung,exynos5420-tmu-ext-triminfo" in cases, there is a misplaced - register, also provide clock to access that base. - - TRIMINFO at 0x1006c000 contains data for TMU channel 3 - TRIMINFO at 0x100a0000 contains data for TMU channel 4 - TRIMINFO at 0x10068000 contains data for TMU channel 2 - -- interrupts : Should contain interrupt for thermal system -- clocks : The main clocks for TMU device - -- 1. operational clock for TMU channel - -- 2. optional clock to access the shared registers of TMU channel - -- 3. optional special clock for functional operation -- clock-names : Thermal system clock name - -- "tmu_apbif" operational clock for current TMU channel - -- "tmu_triminfo_apbif" clock to access the shared triminfo register - for current TMU channel - -- "tmu_sclk" clock for functional operation of the current TMU - channel - -The Exynos TMU supports generating interrupts when reaching given -temperature thresholds. Number of supported thermal trip points depends -on the SoC (only first trip points defined in DT will be configured): - - most of SoC: 4 - - samsung,exynos5433-tmu: 8 - - samsung,exynos7-tmu: 8 - -** Optional properties: - -- vtmu-supply: This entry is optional and provides the regulator node supplying - voltage to TMU. If needed this entry can be placed inside - board/platform specific dts file. - -Example 1): - - tmu@100c0000 { - compatible = "samsung,exynos4412-tmu"; - interrupt-parent = <&combiner>; - reg = <0x100C0000 0x100>; - interrupts = <2 4>; - clocks = <&clock 383>; - clock-names = "tmu_apbif"; - vtmu-supply = <&tmu_regulator_node>; - #thermal-sensor-cells = <0>; - }; - -Example 2): (In case of Exynos5420 "with misplaced TRIMINFO register") - tmu_cpu2: tmu@10068000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x10068000 0x100>, <0x1006c000 0x4>; - interrupts = <0 184 0>; - clocks = <&clock 318>, <&clock 318>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - - tmu_cpu3: tmu@1006c000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x1006c000 0x100>, <0x100a0000 0x4>; - interrupts = <0 185 0>; - clocks = <&clock 318>, <&clock 319>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - - tmu_gpu: tmu@100a0000 { - compatible = "samsung,exynos5420-tmu-ext-triminfo"; - reg = <0x100a0000 0x100>, <0x10068000 0x4>; - interrupts = <0 215 0>; - clocks = <&clock 319>, <&clock 318>; - clock-names = "tmu_apbif", "tmu_triminfo_apbif"; - #thermal-sensor-cells = <0>; - }; - -Note: For multi-instance tmu each instance should have an alias correctly -numbered in "aliases" node. - -Example: - -aliases { - tmuctrl0 = &tmuctrl_0; - tmuctrl1 = &tmuctrl_1; - tmuctrl2 = &tmuctrl_2; -}; diff --git a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml index 289e9a845600..a9b7388ca9ac 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-lmh.yaml @@ -19,6 +19,7 @@ properties: compatible: enum: - qcom,sdm845-lmh + - qcom,sm8150-lmh reg: items: diff --git a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml index d3b9e9b600a2..b6406bcc683f 100644 --- a/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml +++ b/Documentation/devicetree/bindings/thermal/qcom-tsens.yaml @@ -43,6 +43,7 @@ properties: - description: v2 of TSENS items: - enum: + - qcom,msm8953-tsens - qcom,msm8996-tsens - qcom,msm8998-tsens - qcom,sc7180-tsens diff --git a/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml new file mode 100644 index 000000000000..17129f75d962 --- /dev/null +++ b/Documentation/devicetree/bindings/thermal/samsung,exynos-thermal.yaml @@ -0,0 +1,184 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/thermal/samsung,exynos-thermal.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC Thermal Management Unit (TMU) + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +description: | + For multi-instance tmu each instance should have an alias correctly numbered + in "aliases" node. + +properties: + compatible: + enum: + - samsung,exynos3250-tmu + - samsung,exynos4412-tmu + - samsung,exynos4210-tmu + - samsung,exynos5250-tmu + - samsung,exynos5260-tmu + # For TMU channel 0, 1 on Exynos5420: + - samsung,exynos5420-tmu + # For TMU channels 2, 3 and 4 of Exynos5420: + - samsung,exynos5420-tmu-ext-triminfo + - samsung,exynos5433-tmu + - samsung,exynos7-tmu + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + maxItems: 3 + + interrupts: + description: | + The Exynos TMU supports generating interrupts when reaching given + temperature thresholds. Number of supported thermal trip points depends + on the SoC (only first trip points defined in DT will be configured):: + - most of SoC: 4 + - samsung,exynos5433-tmu: 8 + - samsung,exynos7-tmu: 8 + maxItems: 1 + + reg: + items: + - description: TMU instance registers. + - description: | + Shared TMU registers. + + Note:: On Exynos5420, the TRIMINFO register is misplaced for TMU + channels 2, 3 and 4 Use "samsung,exynos5420-tmu-ext-triminfo" in + cases, there is a misplaced register, also provide clock to access + that base. + TRIMINFO at 0x1006c000 contains data for TMU channel 3 + TRIMINFO at 0x100a0000 contains data for TMU channel 4 + TRIMINFO at 0x10068000 contains data for TMU channel 2 + minItems: 1 + + '#thermal-sensor-cells': true + + vtmu-supply: + description: The regulator node supplying voltage to TMU. + +required: + - compatible + - clocks + - clock-names + - interrupts + - reg + +allOf: + - $ref: /schemas/thermal/thermal-sensor.yaml + - if: + properties: + compatible: + contains: + const: samsung,exynos5420-tmu-ext-triminfo + then: + properties: + clocks: + items: + - description: + Operational clock for TMU channel. + - description: + Optional clock to access the shared registers (e.g. TRIMINFO) of TMU + channel. + clock-names: + items: + - const: tmu_apbif + - const: tmu_triminfo_apbif + reg: + minItems: 2 + maxItems: 2 + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos5433-tmu + - samsung,exynos7-tmu + then: + properties: + clocks: + items: + - description: + Operational clock for TMU channel. + - description: + Optional special clock for functional operation of TMU channel. + clock-names: + items: + - const: tmu_apbif + - const: tmu_sclk + reg: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - samsung,exynos3250-tmu + - samsung,exynos4412-tmu + - samsung,exynos4210-tmu + - samsung,exynos5250-tmu + - samsung,exynos5260-tmu + - samsung,exynos5420-tmu + then: + properties: + clocks: + minItems: 1 + maxItems: 1 + reg: + minItems: 1 + maxItems: 1 + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos4.h> + + tmu@100c0000 { + compatible = "samsung,exynos4412-tmu"; + reg = <0x100C0000 0x100>; + interrupt-parent = <&combiner>; + interrupts = <2 4>; + #thermal-sensor-cells = <0>; + clocks = <&clock CLK_TMU_APBIF>; + clock-names = "tmu_apbif"; + vtmu-supply = <&ldo10_reg>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tmu@10068000 { + compatible = "samsung,exynos5420-tmu-ext-triminfo"; + reg = <0x10068000 0x100>, <0x1006c000 0x4>; + interrupts = <GIC_SPI 184 IRQ_TYPE_LEVEL_HIGH>; + #thermal-sensor-cells = <0>; + clocks = <&clock 318>, <&clock 318>; /* CLK_TMU */ + clock-names = "tmu_apbif", "tmu_triminfo_apbif"; + vtmu-supply = <&ldo7_reg>; + }; + + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + tmu@10060000 { + compatible = "samsung,exynos5433-tmu"; + reg = <0x10060000 0x200>; + interrupts = <GIC_SPI 95 IRQ_TYPE_LEVEL_HIGH>; + #thermal-sensor-cells = <0>; + clocks = <&cmu_peris 3>, /* CLK_PCLK_TMU0_APBIF */ + <&cmu_peris 35>; /* CLK_SCLK_TMU0 */ + clock-names = "tmu_apbif", "tmu_sclk"; + vtmu-supply = <&ldo3_reg>; + }; diff --git a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml index f004779ba9b3..850a9841b110 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-cooling-devices.yaml @@ -66,9 +66,9 @@ examples: compatible = "qcom,kryo385"; reg = <0x0 0x0>; enable-method = "psci"; - cpu-idle-states = <&LITTLE_CPU_SLEEP_0 - &LITTLE_CPU_SLEEP_1 - &CLUSTER_SLEEP_0>; + cpu-idle-states = <&LITTLE_CPU_SLEEP_0>, + <&LITTLE_CPU_SLEEP_1>, + <&CLUSTER_SLEEP_0>; capacity-dmips-mhz = <607>; dynamic-power-coefficient = <100>; qcom,freq-domain = <&cpufreq_hw 0>; diff --git a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml index 6278ccf16f3f..cc938d7ad1f3 100644 --- a/Documentation/devicetree/bindings/thermal/thermal-idle.yaml +++ b/Documentation/devicetree/bindings/thermal/thermal-idle.yaml @@ -37,8 +37,8 @@ properties: exit-latency-us: description: | - The exit latency constraint in microsecond for the injected idle state - for the device. It is the latency constraint to apply when selecting an + The exit latency constraint in microsecond for the injected idle state + for the device. It is the latency constraint to apply when selecting an idle state from among all the present ones. required: @@ -65,7 +65,7 @@ examples: capacity-dmips-mhz = <1024>; dynamic-power-coefficient = <436>; #cooling-cells = <2>; /* min followed by max */ - cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>; thermal-idle { #cooling-cells = <2>; duration-us = <10000>; @@ -81,7 +81,7 @@ examples: capacity-dmips-mhz = <1024>; dynamic-power-coefficient = <436>; #cooling-cells = <2>; /* min followed by max */ - cpu-idle-states = <&CPU_SLEEP &CLUSTER_SLEEP>; + cpu-idle-states = <&CPU_SLEEP>, <&CLUSTER_SLEEP>; thermal-idle { #cooling-cells = <2>; duration-us = <10000>; diff --git a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt b/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt deleted file mode 100644 index 4c9ea5989e35..000000000000 --- a/Documentation/devicetree/bindings/timer/andestech,atcpit100-timer.txt +++ /dev/null @@ -1,33 +0,0 @@ -Andestech ATCPIT100 timer ------------------------------------------------------------------- -ATCPIT100 is a generic IP block from Andes Technology, embedded in -Andestech AE3XX platforms and other designs. - -This timer is a set of compact multi-function timers, which can be -used as pulse width modulators (PWM) as well as simple timers. - -It supports up to 4 PIT channels. Each PIT channel is a -multi-function timer and provide the following usage scenarios: -One 32-bit timer -Two 16-bit timers -Four 8-bit timers -One 16-bit PWM -One 16-bit timer and one 8-bit PWM -Two 8-bit timer and one 8-bit PWM - -Required properties: -- compatible : Should be "andestech,atcpit100" -- reg : Address and length of the register set -- interrupts : Reference to the timer interrupt -- clocks : a clock to provide the tick rate for "andestech,atcpit100" -- clock-names : should be "PCLK" for the peripheral clock source. - -Examples: - -timer0: timer@f0400000 { - compatible = "andestech,atcpit100"; - reg = <0xf0400000 0x1000>; - interrupts = <2>; - clocks = <&apb>; - clock-names = "PCLK"; -}; diff --git a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt deleted file mode 100644 index 7cf4a24601eb..000000000000 --- a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.txt +++ /dev/null @@ -1,26 +0,0 @@ -* ARMv7M System Timer - -ARMv7-M includes a system timer, known as SysTick. Current driver only -implements the clocksource feature. - -Required properties: -- compatible : Should be "arm,armv7m-systick" -- reg : The address range of the timer - -Required clocking property, have to be one of: -- clocks : The input clock of the timer -- clock-frequency : The rate in HZ in input of the ARM SysTick - -Examples: - -systick: timer@e000e010 { - compatible = "arm,armv7m-systick"; - reg = <0xe000e010 0x10>; - clocks = <&clk_systick>; -}; - -systick: timer@e000e010 { - compatible = "arm,armv7m-systick"; - reg = <0xe000e010 0x10>; - clock-frequency = <90000000>; -}; diff --git a/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml new file mode 100644 index 000000000000..2bcade5d8ac6 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/arm,armv7m-systick.yaml @@ -0,0 +1,54 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/arm,armv7m-systick.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: ARMv7M System Timer + +maintainers: + - Alexandre Torgue <alexandre.torgue@foss.st.com> + - Fabrice Gasnier <fabrice.gasnier@foss.st.com> + +description: ARMv7-M includes a system timer, known as SysTick. + +properties: + compatible: + const: arm,armv7m-systick + + reg: + maxItems: 1 + + clocks: + maxItems: 1 + + clock-frequency: true + +oneOf: + - required: + - clocks + - required: + - clock-frequency + +required: + - compatible + - reg + +additionalProperties: false + +examples: + - | + timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clocks = <&clk_systick>; + }; + + - | + timer@e000e010 { + compatible = "arm,armv7m-systick"; + reg = <0xe000e010 0x10>; + clock-frequency = <90000000>; + }; + +... diff --git a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml index 7fb37eae9da7..d541cf2067bc 100644 --- a/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml +++ b/Documentation/devicetree/bindings/timer/ingenic,tcu.yaml @@ -152,6 +152,7 @@ patternProperties: - enum: - ingenic,jz4740-pwm - ingenic,jz4725b-pwm + - ingenic,x1000-pwm - items: - enum: - ingenic,jz4760-pwm diff --git a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt index e5c57d6e0186..fbd76a8e023b 100644 --- a/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt +++ b/Documentation/devicetree/bindings/timer/mediatek,mtk-timer.txt @@ -12,6 +12,7 @@ Required properties: For those SoCs that use GPT * "mediatek,mt2701-timer" for MT2701 compatible timers (GPT) * "mediatek,mt6580-timer" for MT6580 compatible timers (GPT) + * "mediatek,mt6582-timer" for MT6582 compatible timers (GPT) * "mediatek,mt6589-timer" for MT6589 compatible timers (GPT) * "mediatek,mt7623-timer" for MT7623 compatible timers (GPT) * "mediatek,mt8127-timer" for MT8127 compatible timers (GPT) diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt deleted file mode 100644 index ac3a5e887455..000000000000 --- a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.txt +++ /dev/null @@ -1,21 +0,0 @@ -Nuvoton NPCM7xx timer - -Nuvoton NPCM7xx have three timer modules, each timer module provides five 24-bit -timer counters. - -Required properties: -- compatible : "nuvoton,npcm750-timer" for Poleg NPCM750, or - "nuvoton,wpcm450-timer" for Hermon WPCM450. -- reg : Offset and length of the register set for the device. -- interrupts : Contain the timer interrupt of timer 0. -- clocks : phandle of timer reference clock (usually a 25 MHz clock). - -Example: - -timer@f0008000 { - compatible = "nuvoton,npcm750-timer"; - interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; - reg = <0xf0008000 0x50>; - clocks = <&clk NPCM7XX_CLK_TIMER>; -}; - diff --git a/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml new file mode 100644 index 000000000000..0cbc26a72151 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nuvoton,npcm7xx-timer.yaml @@ -0,0 +1,46 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/timer/nuvoton,npcm7xx-timer.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Nuvoton NPCM7xx timer + +maintainers: + - Jonathan Neuschäfer <j.neuschaefer@gmx.net> + +properties: + compatible: + enum: + - nuvoton,wpcm450-timer # for Hermon WPCM450 + - nuvoton,npcm750-timer # for Poleg NPCM750 + + reg: + maxItems: 1 + + interrupts: + items: + - description: The timer interrupt of timer 0 + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/clock/nuvoton,npcm7xx-clock.h> + timer@f0008000 { + compatible = "nuvoton,npcm750-timer"; + interrupts = <GIC_SPI 32 IRQ_TYPE_LEVEL_HIGH>; + reg = <0xf0008000 0x50>; + clocks = <&clk NPCM7XX_CLK_TIMER>; + }; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml new file mode 100644 index 000000000000..b78209cd0f28 --- /dev/null +++ b/Documentation/devicetree/bindings/timer/nvidia,tegra-timer.yaml @@ -0,0 +1,150 @@ +# SPDX-License-Identifier: GPL-2.0-only +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/timer/nvidia,tegra-timer.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: NVIDIA Tegra timer + +maintainers: + - Stephen Warren <swarren@nvidia.com> + +allOf: + - if: + properties: + compatible: + contains: + const: nvidia,tegra210-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 14 individual interrupts + minItems: 1 + maxItems: 14 + description: > + A list of 14 interrupts; one per each timer channels 0 through 13 + + - if: + properties: + compatible: + oneOf: + - items: + - enum: + - nvidia,tegra114-timer + - nvidia,tegra124-timer + - nvidia,tegra132-timer + - const: nvidia,tegra30-timer + - items: + - const: nvidia,tegra30-timer + - const: nvidia,tegra20-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 6 individual interrupts + minItems: 1 + maxItems: 6 + description: > + A list of 6 interrupts; one per each of timer channels 1 through 5, + and one for the shared interrupt for the remaining channels. + + - if: + properties: + compatible: + const: nvidia,tegra20-timer + then: + properties: + interrupts: + # Either a single combined interrupt or up to 4 individual interrupts + minItems: 1 + maxItems: 4 + description: | + A list of 4 interrupts; one per timer channel. + +properties: + compatible: + oneOf: + - const: nvidia,tegra210-timer + description: > + The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit + timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived + from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock + (TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic, + or watchdog interrupts. + - items: + - enum: + - nvidia,tegra114-timer + - nvidia,tegra124-timer + - nvidia,tegra132-timer + - const: nvidia,tegra30-timer + - items: + - const: nvidia,tegra30-timer + - const: nvidia,tegra20-timer + description: > + The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free + running counter, and 5 watchdog modules. The first two channels may also + trigger a legacy watchdog reset. + - const: nvidia,tegra20-timer + description: > + The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free + running counter. The first two channels may also trigger a watchdog reset. + + reg: + maxItems: 1 + + interrupts: true + + clocks: + maxItems: 1 + + clock-names: + items: + - const: timer + + +required: + - compatible + - reg + - interrupts + - clocks + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + timer@60005000 { + compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; + reg = <0x60005000 0x400>; + interrupts = <0 0 IRQ_TYPE_LEVEL_HIGH>, + <0 1 IRQ_TYPE_LEVEL_HIGH>, + <0 41 IRQ_TYPE_LEVEL_HIGH>, + <0 42 IRQ_TYPE_LEVEL_HIGH>, + <0 121 IRQ_TYPE_LEVEL_HIGH>, + <0 122 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car 214>; + }; + - | + #include <dt-bindings/clock/tegra210-car.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + #include <dt-bindings/interrupt-controller/irq.h> + + timer@60005000 { + compatible = "nvidia,tegra210-timer"; + reg = <0x60005000 0x400>; + interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>, + <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&tegra_car TEGRA210_CLK_TIMER>; + clock-names = "timer"; + }; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt deleted file mode 100644 index 4a864bd10d3d..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra20-timer.txt +++ /dev/null @@ -1,24 +0,0 @@ -NVIDIA Tegra20 timer - -The Tegra20 timer provides four 29-bit timer channels and a single 32-bit free -running counter. The first two channels may also trigger a watchdog reset. - -Required properties: - -- compatible : should be "nvidia,tegra20-timer". -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 4 interrupts; one per timer channel. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -Example: - -timer { - compatible = "nvidia,tegra20-timer"; - reg = <0x60005000 0x60>; - interrupts = <0 0 0x04 - 0 1 0x04 - 0 41 0x04 - 0 42 0x04>; - clocks = <&tegra_car 132>; -}; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt deleted file mode 100644 index 032cda96fe0d..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra210-timer.txt +++ /dev/null @@ -1,36 +0,0 @@ -NVIDIA Tegra210 timer - -The Tegra210 timer provides fourteen 29-bit timer counters and one 32-bit -timestamp counter. The TMRs run at either a fixed 1 MHz clock rate derived -from the oscillator clock (TMR0-TMR9) or directly at the oscillator clock -(TMR10-TMR13). Each TMR can be programmed to generate one-shot, periodic, -or watchdog interrupts. - -Required properties: -- compatible : "nvidia,tegra210-timer". -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 14 interrupts; one per each timer channels 0 through - 13. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -timer@60005000 { - compatible = "nvidia,tegra210-timer"; - reg = <0x0 0x60005000 0x0 0x400>; - interrupts = <GIC_SPI 156 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 41 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 42 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 153 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 154 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 155 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 176 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 178 IRQ_TYPE_LEVEL_HIGH>, - <GIC_SPI 179 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&tegra_car TEGRA210_CLK_TIMER>; - clock-names = "timer"; -}; diff --git a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt b/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt deleted file mode 100644 index 1761f53ee36f..000000000000 --- a/Documentation/devicetree/bindings/timer/nvidia,tegra30-timer.txt +++ /dev/null @@ -1,28 +0,0 @@ -NVIDIA Tegra30 timer - -The Tegra30 timer provides ten 29-bit timer channels, a single 32-bit free -running counter, and 5 watchdog modules. The first two channels may also -trigger a legacy watchdog reset. - -Required properties: - -- compatible : For Tegra30, must contain "nvidia,tegra30-timer". Otherwise, - must contain '"nvidia,<chip>-timer", "nvidia,tegra30-timer"' where - <chip> is tegra124 or tegra132. -- reg : Specifies base physical address and size of the registers. -- interrupts : A list of 6 interrupts; one per each of timer channels 1 - through 5, and one for the shared interrupt for the remaining channels. -- clocks : Must contain one entry, for the module clock. - See ../clocks/clock-bindings.txt for details. - -timer { - compatible = "nvidia,tegra30-timer", "nvidia,tegra20-timer"; - reg = <0x60005000 0x400>; - interrupts = <0 0 0x04 - 0 1 0x04 - 0 41 0x04 - 0 42 0x04 - 0 121 0x04 - 0 122 0x04>; - clocks = <&tegra_car 214>; -}; diff --git a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml index 7fa7f977b44c..c399a019dde7 100644 --- a/Documentation/devicetree/bindings/timer/renesas,ostm.yaml +++ b/Documentation/devicetree/bindings/timer/renesas,ostm.yaml @@ -24,6 +24,7 @@ properties: - renesas,r7s72100-ostm # RZ/A1H - renesas,r7s9210-ostm # RZ/A2M - renesas,r9a07g044-ostm # RZ/G2{L,LC} + - renesas,r9a07g054-ostm # RZ/V2L - const: renesas,ostm # Generic reg: @@ -54,6 +55,7 @@ if: contains: enum: - renesas,r9a07g044-ostm + - renesas,r9a07g054-ostm then: required: - resets diff --git a/Documentation/devicetree/bindings/timer/sifive,clint.yaml b/Documentation/devicetree/bindings/timer/sifive,clint.yaml index 8d5f4687add9..e64f46339079 100644 --- a/Documentation/devicetree/bindings/timer/sifive,clint.yaml +++ b/Documentation/devicetree/bindings/timer/sifive,clint.yaml @@ -44,6 +44,7 @@ properties: interrupts-extended: minItems: 1 + maxItems: 4095 additionalProperties: false @@ -56,10 +57,10 @@ examples: - | timer@2000000 { compatible = "sifive,fu540-c000-clint", "sifive,clint0"; - interrupts-extended = <&cpu1intc 3 &cpu1intc 7 - &cpu2intc 3 &cpu2intc 7 - &cpu3intc 3 &cpu3intc 7 - &cpu4intc 3 &cpu4intc 7>; + interrupts-extended = <&cpu1intc 3>, <&cpu1intc 7>, + <&cpu2intc 3>, <&cpu2intc 7>, + <&cpu3intc 3>, <&cpu3intc 7>, + <&cpu4intc 3>, <&cpu4intc 7>; reg = <0x2000000 0x10000>; }; ... diff --git a/Documentation/devicetree/bindings/trivial-devices.yaml b/Documentation/devicetree/bindings/trivial-devices.yaml index 091792ba993e..550a2e5c9e05 100644 --- a/Documentation/devicetree/bindings/trivial-devices.yaml +++ b/Documentation/devicetree/bindings/trivial-devices.yaml @@ -77,7 +77,7 @@ properties: - delta,ahe50dc-fan # Delta Electronics DPS-650-AB power supply - delta,dps650ab - # Delta Electronics DPS920AB 920W 54V Power Supply + # Delta Electronics DPS920AB 920W 54V Power Supply - delta,dps920ab # 1/4 Brick DC/DC Regulated Power Module - delta,q54sj108a2 @@ -123,13 +123,13 @@ properties: - ibm,cffps2 # Infineon IR36021 digital POL buck controller - infineon,ir36021 - # Infineon IR38060 Voltage Regulator + # Infineon IR38060 Voltage Regulator - infineon,ir38060 # Infineon IR38064 Voltage Regulator - infineon,ir38064 - # Infineon IR38164 Voltage Regulator + # Infineon IR38164 Voltage Regulator - infineon,ir38164 - # Infineon IR38263 Voltage Regulator + # Infineon IR38263 Voltage Regulator - infineon,ir38263 # Infineon SLB9635 (Soft-) I2C TPM (old protocol, max 100khz) - infineon,slb9635tt @@ -137,10 +137,20 @@ properties: - infineon,slb9645tt # Infineon TLV493D-A1B6 I2C 3D Magnetic Sensor - infineon,tlv493d-a1b6 + # Infineon Multi-phase Digital VR Controller xdpe11280 + - infineon,xdpe11280 # Infineon Multi-phase Digital VR Controller xdpe12254 - infineon,xdpe12254 # Infineon Multi-phase Digital VR Controller xdpe12284 - infineon,xdpe12284 + # Injoinic IP5108 2.0A Power Bank IC with I2C + - injoinic,ip5108 + # Injoinic IP5109 2.1A Power Bank IC with I2C + - injoinic,ip5109 + # Injoinic IP5207 1.2A Power Bank IC with I2C + - injoinic,ip5207 + # Injoinic IP5209 2.4A Power Bank IC with I2C + - injoinic,ip5209 # Inspur Power System power supply unit version 1 - inspur,ipsps1 # Intersil ISL29028 Ambient Light and Proximity Sensor @@ -157,6 +167,8 @@ properties: - maxim,ds1803-050 # 100 kOhm digital potentiometer with I2C interface - maxim,ds1803-100 + # 10 kOhm digital potentiometer with I2C interface + - maxim,ds3502 # Low-Power, 4-/12-Channel, 2-Wire Serial, 12-Bit ADCs - maxim,max1237 # Temperature Sensor, I2C interface @@ -283,6 +295,8 @@ properties: - renesas,isl29501 # S524AD0XF1 (128K/256K-bit Serial EEPROM for Low Power) - samsung,24ad0xd1 + # Samsung Exynos SoC SATA PHY I2C device + - samsung,exynos-sataphy-i2c # Sensirion low power multi-pixel gas sensor with I2C interface - sensirion,sgpc3 # Sensirion multi-pixel gas sensor with I2C interface @@ -337,6 +351,7 @@ properties: # Thermometer with SPI interface - ti,tmp121 - ti,tmp122 + - ti,tmp125 # Digital Temperature Sensor - ti,tmp275 # TI DC-DC converter on PMBus @@ -354,6 +369,8 @@ properties: - ti,tps544c25 # Winbond/Nuvoton H/W Monitor - winbond,w83793 + # Vicor Corporation Digital Supervisor + - vicor,pli1209bc # i2c trusted platform module (TPM) - winbond,wpct301 diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt b/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt deleted file mode 100644 index 02347b017abd..000000000000 --- a/Documentation/devicetree/bindings/ufs/cdns,ufshc.txt +++ /dev/null @@ -1,32 +0,0 @@ -* Cadence Universal Flash Storage (UFS) Controller - -UFS nodes are defined to describe on-chip UFS host controllers. -Each UFS controller instance should have its own node. -Please see the ufshcd-pltfrm.txt for a list of all available properties. - -Required properties: -- compatible : Compatible list, contains one of the following controllers: - "cdns,ufshc" - Generic CDNS HCI, - "cdns,ufshc-m31-16nm" - CDNS UFS HC + M31 16nm PHY - complemented with the JEDEC version: - "jedec,ufs-2.0" - -- reg : Address and length of the UFS register set. -- interrupts : One interrupt mapping. -- freq-table-hz : Clock frequency table. - See the ufshcd-pltfrm.txt for details. -- clocks : List of phandle and clock specifier pairs. -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "core_clk" is mandatory. - Depending on a type of a PHY, - the "phy_clk" clock can also be added, if needed. - -Example: - ufs@fd030000 { - compatible = "cdns,ufshc", "jedec,ufs-2.0"; - reg = <0xfd030000 0x10000>; - interrupts = <0 1 IRQ_TYPE_LEVEL_HIGH>; - freq-table-hz = <0 0>, <0 0>; - clocks = <&ufs_core_clk>, <&ufs_phy_clk>; - clock-names = "core_clk", "phy_clk"; - }; diff --git a/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml new file mode 100644 index 000000000000..d227dea368be --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/cdns,ufshc.yaml @@ -0,0 +1,68 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/cdns,ufshc.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Cadence Universal Flash Storage (UFS) Controller + +maintainers: + - Jan Kotas <jank@cadence.com> + +# Select only our matches, not all jedec,ufs-2.0 +select: + properties: + compatible: + contains: + enum: + - cdns,ufshc + - cdns,ufshc-m31-16nm + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + items: + - enum: + - cdns,ufshc + # CDNS UFS HC + M31 16nm PHY + - cdns,ufshc-m31-16nm + - const: jedec,ufs-2.0 + + clocks: + minItems: 1 + maxItems: 3 + + clock-names: + minItems: 1 + items: + - const: core_clk + - const: phy_clk + - const: ref_clk + + reg: + maxItems: 1 + +required: + - compatible + - clocks + - clock-names + - reg + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/arm-gic.h> + + ufs@fd030000 { + compatible = "cdns,ufshc", "jedec,ufs-2.0"; + reg = <0xfd030000 0x10000>; + interrupts = <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH>; + freq-table-hz = <0 0>, <0 0>; + clocks = <&ufs_core_clk>, <&ufs_phy_clk>; + clock-names = "core_clk", "phy_clk"; + }; diff --git a/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml b/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml new file mode 100644 index 000000000000..4432bfa0cbc7 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/hisilicon,ufs.yaml @@ -0,0 +1,90 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/hisilicon,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: HiSilicon Universal Flash Storage (UFS) Controller + +maintainers: + - Li Wei <liwei213@huawei.com> + +# Select only our matches, not all jedec,ufs +select: + properties: + compatible: + contains: + enum: + - hisilicon,hi3660-ufs + - hisilicon,hi3670-ufs + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + oneOf: + - items: + - const: hisilicon,hi3660-ufs + - const: jedec,ufs-1.1 + - items: + - enum: + - hisilicon,hi3670-ufs + - const: jedec,ufs-2.1 + + clocks: + minItems: 2 + maxItems: 2 + + clock-names: + items: + - const: ref_clk + - const: phy_clk + + reg: + items: + - description: UFS register address space + - description: UFS SYS CTRL register address space + + resets: + maxItems: 1 + + reset-names: + items: + - const: rst + +required: + - compatible + - reg + - resets + - reset-names + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/hi3670-clock.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@ff3c0000 { + compatible = "hisilicon,hi3670-ufs", "jedec,ufs-2.1"; + reg = <0x0 0xff3c0000 0x0 0x1000>, + <0x0 0xff3e0000 0x0 0x1000>; + interrupt-parent = <&gic>; + interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&crg_ctrl HI3670_CLK_GATE_UFSIO_REF>, + <&crg_ctrl HI3670_CLK_GATE_UFS_SUBSYS>; + clock-names = "ref_clk", "phy_clk"; + freq-table-hz = <0 0>, + <0 0>; + + resets = <&crg_rst 0x84 12>; + reset-names = "rst"; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml new file mode 100644 index 000000000000..32fd535a514a --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/mediatek,ufs.yaml @@ -0,0 +1,67 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/mediatek,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Mediatek Universal Flash Storage (UFS) Controller + +maintainers: + - Stanley Chu <stanley.chu@mediatek.com> + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + enum: + - mediatek,mt8183-ufshci + - mediatek,mt8192-ufshci + + clocks: + maxItems: 1 + + clock-names: + items: + - const: ufs + + phys: + maxItems: 1 + + reg: + maxItems: 1 + + vcc-supply: true + +required: + - compatible + - clocks + - clock-names + - phys + - reg + - vcc-supply + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/mt8183-clk.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@ff3c0000 { + compatible = "mediatek,mt8183-ufshci"; + reg = <0 0x11270000 0 0x2300>; + interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; + phys = <&ufsphy>; + + clocks = <&infracfg_ao CLK_INFRA_UFS>; + clock-names = "ufs"; + freq-table-hz = <0 0>; + + vcc-supply = <&mt_pmic_vemc_ldo_reg>; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml new file mode 100644 index 000000000000..dcd32c10205a --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/qcom,ufs.yaml @@ -0,0 +1,244 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/qcom,ufs.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Qualcomm Universal Flash Storage (UFS) Controller + +maintainers: + - Bjorn Andersson <bjorn.andersson@linaro.org> + - Andy Gross <agross@kernel.org> + +# Select only our matches, not all jedec,ufs-2.0 +select: + properties: + compatible: + contains: + const: qcom,ufshc + required: + - compatible + +properties: + compatible: + items: + - enum: + - qcom,msm8994-ufshc + - qcom,msm8996-ufshc + - qcom,msm8998-ufshc + - qcom,sdm845-ufshc + - qcom,sm6350-ufshc + - qcom,sm8150-ufshc + - qcom,sm8250-ufshc + - qcom,sm8350-ufshc + - qcom,sm8450-ufshc + - const: qcom,ufshc + - const: jedec,ufs-2.0 + + clocks: + minItems: 8 + maxItems: 11 + + clock-names: + minItems: 8 + maxItems: 11 + + interconnects: + minItems: 2 + maxItems: 2 + + interconnect-names: + items: + - const: ufs-ddr + - const: cpu-ufs + + iommus: + minItems: 1 + maxItems: 2 + + phys: + maxItems: 1 + + phy-names: + items: + - const: ufsphy + + power-domains: + maxItems: 1 + + reg: + minItems: 1 + maxItems: 2 + + resets: + maxItems: 1 + + '#reset-cells': + const: 1 + + reset-names: + items: + - const: rst + + reset-gpios: + maxItems: 1 + description: + GPIO connected to the RESET pin of the UFS memory device. + +required: + - compatible + - reg + +allOf: + - $ref: ufs-common.yaml + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8998-ufshc + - qcom,sm8250-ufshc + - qcom,sm8350-ufshc + - qcom,sm8450-ufshc + then: + properties: + clocks: + minItems: 8 + maxItems: 8 + clock-names: + items: + - const: core_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + - const: rx_lane1_sync_clk + reg: + minItems: 1 + maxItems: 1 + + - if: + properties: + compatible: + contains: + enum: + - qcom,sdm845-ufshc + - qcom,sm6350-ufshc + - qcom,sm8150-ufshc + then: + properties: + clocks: + minItems: 9 + maxItems: 9 + clock-names: + items: + - const: core_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + - const: rx_lane1_sync_clk + - const: ice_core_clk + reg: + minItems: 2 + maxItems: 2 + + - if: + properties: + compatible: + contains: + enum: + - qcom,msm8996-ufshc + then: + properties: + clocks: + minItems: 11 + maxItems: 11 + clock-names: + items: + - const: core_clk_src + - const: core_clk + - const: bus_clk + - const: bus_aggr_clk + - const: iface_clk + - const: core_clk_unipro_src + - const: core_clk_unipro + - const: core_clk_ice + - const: ref_clk + - const: tx_lane0_sync_clk + - const: rx_lane0_sync_clk + reg: + minItems: 1 + maxItems: 1 + + # TODO: define clock bindings for qcom,msm8994-ufshc + +unevaluatedProperties: false + +examples: + - | + #include <dt-bindings/clock/qcom,gcc-sm8450.h> + #include <dt-bindings/clock/qcom,rpmh.h> + #include <dt-bindings/gpio/gpio.h> + #include <dt-bindings/interconnect/qcom,sm8450.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + soc { + #address-cells = <2>; + #size-cells = <2>; + + ufs@1d84000 { + compatible = "qcom,sm8450-ufshc", "qcom,ufshc", + "jedec,ufs-2.0"; + reg = <0 0x01d84000 0 0x3000>; + interrupts = <GIC_SPI 265 IRQ_TYPE_LEVEL_HIGH>; + phys = <&ufs_mem_phy_lanes>; + phy-names = "ufsphy"; + lanes-per-direction = <2>; + #reset-cells = <1>; + resets = <&gcc GCC_UFS_PHY_BCR>; + reset-names = "rst"; + reset-gpios = <&tlmm 210 GPIO_ACTIVE_LOW>; + + vcc-supply = <&vreg_l7b_2p5>; + vcc-max-microamp = <1100000>; + vccq-supply = <&vreg_l9b_1p2>; + vccq-max-microamp = <1200000>; + + power-domains = <&gcc UFS_PHY_GDSC>; + iommus = <&apps_smmu 0xe0 0x0>; + interconnects = <&aggre1_noc MASTER_UFS_MEM &mc_virt SLAVE_EBI1>, + <&gem_noc MASTER_APPSS_PROC &config_noc SLAVE_UFS_MEM_CFG>; + interconnect-names = "ufs-ddr", "cpu-ufs"; + + clock-names = "core_clk", + "bus_aggr_clk", + "iface_clk", + "core_clk_unipro", + "ref_clk", + "tx_lane0_sync_clk", + "rx_lane0_sync_clk", + "rx_lane1_sync_clk"; + clocks = <&gcc GCC_UFS_PHY_AXI_CLK>, + <&gcc GCC_AGGRE_UFS_PHY_AXI_CLK>, + <&gcc GCC_UFS_PHY_AHB_CLK>, + <&gcc GCC_UFS_PHY_UNIPRO_CORE_CLK>, + <&rpmhcc RPMH_CXO_CLK>, + <&gcc GCC_UFS_PHY_TX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_RX_SYMBOL_0_CLK>, + <&gcc GCC_UFS_PHY_RX_SYMBOL_1_CLK>; + freq-table-hz = <75000000 300000000>, + <0 0>, + <0 0>, + <75000000 300000000>, + <75000000 300000000>, + <0 0>, + <0 0>, + <0 0>; + }; + }; diff --git a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml index 95ac1c18334d..c949eb617313 100644 --- a/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/samsung,exynos-ufs.yaml @@ -11,12 +11,11 @@ maintainers: description: | Each Samsung UFS host controller instance should have its own node. - This binding define Samsung specific binding other then what is used - in the common ufshcd bindings - [1] Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt -properties: +allOf: + - $ref: ufs-common.yaml +properties: compatible: enum: - samsung,exynos7-ufs @@ -47,9 +46,6 @@ properties: - const: core_clk - const: sclk_unipro_main - interrupts: - maxItems: 1 - phys: maxItems: 1 @@ -67,13 +63,12 @@ properties: required: - compatible - reg - - interrupts - phys - phy-names - clocks - clock-names -additionalProperties: false +unevaluatedProperties: false examples: - | diff --git a/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml b/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml new file mode 100644 index 000000000000..671a70d95138 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/snps,tc-dwc-g210.yaml @@ -0,0 +1,51 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/snps,tc-dwc-g210.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Synopsys DesignWare Universal Flash Storage (UFS) Controller + +maintainers: + - Li Wei <liwei213@huawei.com> + +# Select only our matches, not all jedec,ufs +select: + properties: + compatible: + contains: + enum: + - snps,dwc-ufshcd-1.40a + required: + - compatible + +allOf: + - $ref: ufs-common.yaml + +properties: + compatible: + items: + - enum: + - snps,g210-tc-6.00-20bit + - snps,g210-tc-6.00-40bit + - const: snps,dwc-ufshcd-1.40a + - const: jedec,ufs-2.0 + + reg: + maxItems: 1 + +required: + - compatible + - reg + +unevaluatedProperties: false + +examples: + - | + ufs@d0000000 { + compatible = "snps,g210-tc-6.00-40bit", + "snps,dwc-ufshcd-1.40a", + "jedec,ufs-2.0"; + reg = <0xd0000000 0x10000>; + interrupts = <24>; + }; diff --git a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt b/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt deleted file mode 100644 index 71c0777960e9..000000000000 --- a/Documentation/devicetree/bindings/ufs/tc-dwc-g210-pltfrm.txt +++ /dev/null @@ -1,26 +0,0 @@ -* Universal Flash Storage (UFS) DesignWare Host Controller - -DWC_UFS nodes are defined to describe on-chip UFS host controllers and MPHY. -Each UFS controller instance should have its own node. - -Required properties: -- compatible : compatible list must contain the PHY type & version: - "snps,g210-tc-6.00-20bit" - "snps,g210-tc-6.00-40bit" - complemented with the Controller IP version: - "snps,dwc-ufshcd-1.40a" - complemented with the JEDEC version: - "jedec,ufs-1.1" - "jedec,ufs-2.0" - -- reg : <registers mapping> -- interrupts : <interrupt mapping for UFS host controller IRQ> - -Example for a setup using a 1.40a DWC Controller with a 6.00 G210 40-bit TC: - dwc-ufs@d0000000 { - compatible = "snps,g210-tc-6.00-40bit", - "snps,dwc-ufshcd-1.40a", - "jedec,ufs-2.0"; - reg = < 0xd0000000 0x10000 >; - interrupts = < 24 >; - }; diff --git a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml index 4d13e6bc1c50..c5eca7735f76 100644 --- a/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml +++ b/Documentation/devicetree/bindings/ufs/ti,j721e-ufs.yaml @@ -47,11 +47,10 @@ required: patternProperties: "^ufs@[0-9a-f]+$": - type: object + $ref: cdns,ufshc.yaml description: | - Cadence UFS controller node must be the child node. Refer - Documentation/devicetree/bindings/ufs/cdns,ufshc.txt for binding - documentation of child node + Cadence UFS controller node must be the child node. + unevaluatedProperties: false additionalProperties: false diff --git a/Documentation/devicetree/bindings/ufs/ufs-common.yaml b/Documentation/devicetree/bindings/ufs/ufs-common.yaml new file mode 100644 index 000000000000..47a4e9e1a775 --- /dev/null +++ b/Documentation/devicetree/bindings/ufs/ufs-common.yaml @@ -0,0 +1,82 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/ufs/ufs-common.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Common properties for Universal Flash Storage (UFS) Host Controllers + +maintainers: + - Alim Akhtar <alim.akhtar@samsung.com> + - Avri Altman <avri.altman@wdc.com> + +properties: + clocks: true + + clock-names: true + + freq-table-hz: + items: + items: + - description: Minimum frequency for given clock in Hz + - description: Maximum frequency for given clock in Hz + description: | + Array of <min max> operating frequencies in Hz stored in the same order + as the clocks property. If this property is not defined or a value in the + array is "0" then it is assumed that the frequency is set by the parent + clock or a fixed rate clock source. + + interrupts: + maxItems: 1 + + lanes-per-direction: + $ref: /schemas/types.yaml#/definitions/uint32 + enum: [1, 2] + default: 2 + description: + Number of lanes available per direction. Note that it is assume same + number of lanes is used both directions at once. + + vdd-hba-supply: + description: + Phandle to UFS host controller supply regulator node. + + vcc-supply: + description: + Phandle to VCC supply regulator node. + + vccq-supply: + description: + Phandle to VCCQ supply regulator node. + + vccq2-supply: + description: + Phandle to VCCQ2 supply regulator node. + + vcc-supply-1p8: + type: boolean + description: + For embedded UFS devices, valid VCC range is 1.7-1.95V or 2.7-3.6V. This + boolean property when set, specifies to use low voltage range of + 1.7-1.95V. Note for external UFS cards this property is invalid and valid + VCC range is always 2.7-3.6V. + + vcc-max-microamp: + description: + Specifies max. load that can be drawn from VCC supply. + + vccq-max-microamp: + description: + Specifies max. load that can be drawn from VCCQ supply. + + vccq2-max-microamp: + description: + Specifies max. load that can be drawn from VCCQ2 supply. + +dependencies: + freq-table-hz: [ 'clocks' ] + +required: + - interrupts + +additionalProperties: true diff --git a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt b/Documentation/devicetree/bindings/ufs/ufs-hisi.txt deleted file mode 100644 index 0b83df1a5418..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-hisi.txt +++ /dev/null @@ -1,42 +0,0 @@ -* Hisilicon Universal Flash Storage (UFS) Host Controller - -UFS nodes are defined to describe on-chip UFS hardware macro. -Each UFS Host Controller should have its own node. - -Required properties: -- compatible : compatible list, contains one of the following - - "hisilicon,hi3660-ufs", "jedec,ufs-1.1" for hisi ufs - host controller present on Hi3660 chipset. - "hisilicon,hi3670-ufs", "jedec,ufs-2.1" for hisi ufs - host controller present on Hi3670 chipset. -- reg : should contain UFS register address space & UFS SYS CTRL register address, -- interrupts : interrupt number -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ref_clk", "phy_clk" is optional -- freq-table-hz : Array of <min max> operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. -- resets : describe reset node register -- reset-names : reset node register, the "rst" corresponds to reset the whole UFS IP. - -Example: - - ufs: ufs@ff3b0000 { - compatible = "hisilicon,hi3660-ufs", "jedec,ufs-1.1"; - /* 0: HCI standard */ - /* 1: UFS SYS CTRL */ - reg = <0x0 0xff3b0000 0x0 0x1000>, - <0x0 0xff3b1000 0x0 0x1000>; - interrupt-parent = <&gic>; - interrupts = <GIC_SPI 278 IRQ_TYPE_LEVEL_HIGH>; - clocks = <&crg_ctrl HI3660_CLK_GATE_UFSIO_REF>, - <&crg_ctrl HI3660_CLK_GATE_UFSPHY_CFG>; - clock-names = "ref_clk", "phy_clk"; - freq-table-hz = <0 0>, <0 0>; - /* offset: 0x84; bit: 12 */ - resets = <&crg_rst 0x84 12>; - reset-names = "rst"; - }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt b/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt deleted file mode 100644 index 63a953b672d2..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-mediatek.txt +++ /dev/null @@ -1,45 +0,0 @@ -* Mediatek Universal Flash Storage (UFS) Host Controller - -UFS nodes are defined to describe on-chip UFS hardware macro. -Each UFS Host Controller should have its own node. - -To bind UFS PHY with UFS host controller, the controller node should -contain a phandle reference to UFS M-PHY node. - -Required properties for UFS nodes: -- compatible : Compatible list, contains the following controller: - "mediatek,mt8183-ufshci" for MediaTek UFS host controller - present on MT8183 chipsets. - "mediatek,mt8192-ufshci" for MediaTek UFS host controller - present on MT8192 chipsets. -- reg : Address and length of the UFS register set. -- phys : phandle to m-phy. -- clocks : List of phandle and clock specifier pairs. -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ufs" is mandatory. - "ufs": ufshci core control clock. -- freq-table-hz : Array of <min max> operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. -- vcc-supply : phandle to VCC supply regulator node. - -Example: - - ufsphy: phy@11fa0000 { - ... - }; - - ufshci@11270000 { - compatible = "mediatek,mt8183-ufshci"; - reg = <0 0x11270000 0 0x2300>; - interrupts = <GIC_SPI 104 IRQ_TYPE_LEVEL_LOW>; - phys = <&ufsphy>; - - clocks = <&infracfg_ao INFRACFG_AO_UFS_CG>; - clock-names = "ufs"; - freq-table-hz = <0 0>; - - vcc-supply = <&mt_pmic_vemc_ldo_reg>; - }; diff --git a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt b/Documentation/devicetree/bindings/ufs/ufs-qcom.txt deleted file mode 100644 index fd59f93e9556..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufs-qcom.txt +++ /dev/null @@ -1,63 +0,0 @@ -* Qualcomm Technologies Inc Universal Flash Storage (UFS) PHY - -UFSPHY nodes are defined to describe on-chip UFS PHY hardware macro. -Each UFS PHY node should have its own node. - -To bind UFS PHY with UFS host controller, the controller node should -contain a phandle reference to UFS PHY node. - -Required properties: -- compatible : compatible list, contains one of the following - - "qcom,ufs-phy-qmp-20nm" for 20nm ufs phy, - "qcom,ufs-phy-qmp-14nm" for legacy 14nm ufs phy, - "qcom,msm8996-ufs-phy-qmp-14nm" for 14nm ufs phy - present on MSM8996 chipset. -- reg : should contain PHY register address space (mandatory), -- reg-names : indicates various resources passed to driver (via reg proptery) by name. - Required "reg-names" is "phy_mem". -- #phy-cells : This property shall be set to 0 -- vdda-phy-supply : phandle to main PHY supply for analog domain -- vdda-pll-supply : phandle to PHY PLL and Power-Gen block power supply -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. "ref_clk_src", "ref_clk", - "tx_iface_clk" & "rx_iface_clk" are mandatory but - "ref_clk_parent" is optional - -Optional properties: -- vdda-phy-max-microamp : specifies max. load that can be drawn from phy supply -- vdda-pll-max-microamp : specifies max. load that can be drawn from pll supply -- vddp-ref-clk-supply : phandle to UFS device ref_clk pad power supply -- vddp-ref-clk-max-microamp : specifies max. load that can be drawn from this supply -- resets : specifies the PHY reset in the UFS controller - -Example: - - ufsphy1: ufsphy@fc597000 { - compatible = "qcom,ufs-phy-qmp-20nm"; - reg = <0xfc597000 0x800>; - reg-names = "phy_mem"; - #phy-cells = <0>; - vdda-phy-supply = <&pma8084_l4>; - vdda-pll-supply = <&pma8084_l12>; - vdda-phy-max-microamp = <50000>; - vdda-pll-max-microamp = <1000>; - clock-names = "ref_clk_src", - "ref_clk_parent", - "ref_clk", - "tx_iface_clk", - "rx_iface_clk"; - clocks = <&clock_rpm clk_ln_bb_clk>, - <&clock_gcc clk_pcie_1_phy_ldo >, - <&clock_gcc clk_ufs_phy_ldo>, - <&clock_gcc clk_gcc_ufs_tx_cfg_clk>, - <&clock_gcc clk_gcc_ufs_rx_cfg_clk>; - resets = <&ufshc 0>; - }; - - ufshc: ufshc@fc598000 { - #reset-cells = <1>; - ... - phys = <&ufsphy1>; - phy-names = "ufsphy"; - }; diff --git a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt b/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt deleted file mode 100644 index d0fee78e6203..000000000000 --- a/Documentation/devicetree/bindings/ufs/ufshcd-pltfrm.txt +++ /dev/null @@ -1,90 +0,0 @@ -* Universal Flash Storage (UFS) Host Controller - -UFSHC nodes are defined to describe on-chip UFS host controllers. -Each UFS controller instance should have its own node. - -Required properties: -- compatible : must contain "jedec,ufs-1.1" or "jedec,ufs-2.0" - - For Qualcomm SoCs must contain, as below, an - SoC-specific compatible along with "qcom,ufshc" and - the appropriate jedec string: - "qcom,msm8994-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,msm8996-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,msm8998-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sdm845-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8150-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8250-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8350-ufshc", "qcom,ufshc", "jedec,ufs-2.0" - "qcom,sm8450-ufshc", "qcom,ufshc", "jedec,ufs-2.0" -- interrupts : <interrupt mapping for UFS host controller IRQ> -- reg : <registers mapping> - -Optional properties: -- phys : phandle to UFS PHY node -- phy-names : the string "ufsphy" when is found in a node, along - with "phys" attribute, provides phandle to UFS PHY node -- vdd-hba-supply : phandle to UFS host controller supply regulator node -- vcc-supply : phandle to VCC supply regulator node -- vccq-supply : phandle to VCCQ supply regulator node -- vccq2-supply : phandle to VCCQ2 supply regulator node -- vcc-supply-1p8 : For embedded UFS devices, valid VCC range is 1.7-1.95V - or 2.7-3.6V. This boolean property when set, specifies - to use low voltage range of 1.7-1.95V. Note for external - UFS cards this property is invalid and valid VCC range is - always 2.7-3.6V. -- vcc-max-microamp : specifies max. load that can be drawn from vcc supply -- vccq-max-microamp : specifies max. load that can be drawn from vccq supply -- vccq2-max-microamp : specifies max. load that can be drawn from vccq2 supply - -- clocks : List of phandle and clock specifier pairs -- clock-names : List of clock input name strings sorted in the same - order as the clocks property. - "ref_clk" indicates reference clock frequency. - UFS host supplies reference clock to UFS device and UFS device - specification allows host to provide one of the 4 frequencies (19.2 MHz, - 26 MHz, 38.4 MHz, 52MHz) for reference clock. This "ref_clk" entry is - parsed and used to update the reference clock setting in device. - Defaults to 26 MHz(as per specification) if not specified by host. -- freq-table-hz : Array of <min max> operating frequencies stored in the same - order as the clocks property. If this property is not - defined or a value in the array is "0" then it is assumed - that the frequency is set by the parent clock or a - fixed rate clock source. --lanes-per-direction : number of lanes available per direction - either 1 or 2. - Note that it is assume same number of lanes is used both - directions at once. If not specified, default is 2 lanes per direction. -- #reset-cells : Must be <1> for Qualcomm UFS controllers that expose - PHY reset from the UFS controller. -- resets : reset node register -- reset-names : describe reset node register, the "rst" corresponds to reset the whole UFS IP. -- reset-gpios : A phandle and gpio specifier denoting the GPIO connected - to the RESET pin of the UFS memory device. - -Note: If above properties are not defined it can be assumed that the supply -regulators or clocks are always on. - -Example: - ufshc@fc598000 { - compatible = "jedec,ufs-1.1"; - reg = <0xfc598000 0x800>; - interrupts = <0 28 0>; - - vdd-hba-supply = <&xxx_reg0>; - vcc-supply = <&xxx_reg1>; - vcc-supply-1p8; - vccq-supply = <&xxx_reg2>; - vccq2-supply = <&xxx_reg3>; - vcc-max-microamp = 500000; - vccq-max-microamp = 200000; - vccq2-max-microamp = 200000; - - clocks = <&core 0>, <&ref 0>, <&phy 0>, <&iface 0>; - clock-names = "core_clk", "ref_clk", "phy_clk", "iface_clk"; - freq-table-hz = <100000000 200000000>, <0 0>, <0 0>, <0 0>; - resets = <&reset 0 1>; - reset-names = "rst"; - phys = <&ufsphy1>; - phy-names = "ufsphy"; - #reset-cells = <1>; - }; diff --git a/Documentation/devicetree/bindings/usb/dwc2.yaml b/Documentation/devicetree/bindings/usb/dwc2.yaml index f00867ebc147..4cebce682d16 100644 --- a/Documentation/devicetree/bindings/usb/dwc2.yaml +++ b/Documentation/devicetree/bindings/usb/dwc2.yaml @@ -41,6 +41,7 @@ properties: - amlogic,meson8b-usb - amlogic,meson-gxbb-usb - amlogic,meson-g12a-usb + - intel,socfpga-agilex-hsotg - const: snps,dwc2 - const: amcc,dwc-otg - const: apm,apm82181-dwc-otg @@ -53,6 +54,7 @@ properties: - const: st,stm32mp15-hsotg - const: snps,dwc2 - const: samsung,s3c6400-hsotg + - const: intel,socfpga-agilex-hsotg reg: maxItems: 1 @@ -67,6 +69,13 @@ properties: items: - const: otg + disable-over-current: + type: boolean + description: whether to disable detection of over-current condition. + + iommus: + maxItems: 1 + resets: items: - description: common reset diff --git a/Documentation/devicetree/bindings/usb/dwc3-cavium.txt b/Documentation/devicetree/bindings/usb/dwc3-cavium.txt index 710b782ccf65..171df79360ff 100644 --- a/Documentation/devicetree/bindings/usb/dwc3-cavium.txt +++ b/Documentation/devicetree/bindings/usb/dwc3-cavium.txt @@ -20,7 +20,7 @@ Example device node: refclk-type-hs = "dlmc_ref_clk0"; power = <0x00000002 0x00000002 0x00000001>; xhci@1690000000000 { - compatible = "cavium,octeon-7130-xhci", "synopsys,dwc3"; + compatible = "cavium,octeon-7130-xhci", "snps,dwc3"; reg = <0x00016900 0x00000000 0x00000010 0x00000000>; interrupt-parent = <0x00000010>; interrupts = <0x00000009 0x00000004>; diff --git a/Documentation/devicetree/bindings/usb/exynos-usb.txt b/Documentation/devicetree/bindings/usb/exynos-usb.txt deleted file mode 100644 index f7ae79825d7d..000000000000 --- a/Documentation/devicetree/bindings/usb/exynos-usb.txt +++ /dev/null @@ -1,115 +0,0 @@ -Samsung Exynos SoC USB controller - -The USB devices interface with USB controllers on Exynos SOCs. -The device node has following properties. - -EHCI -Required properties: - - compatible: should be "samsung,exynos4210-ehci" for USB 2.0 - EHCI controller in host mode. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - clocks: from common clock binding: handle to usb clock. - - clock-names: from common clock binding: Shall be "usbhost". - - phys: from the *Generic PHY* bindings; array specifying phy(s) used - by the root port. - - phy-names: from the *Generic PHY* bindings; array of the names for - each phy for the root ports, must be a subset of the following: - "host", "hsic0", "hsic1". - -Optional properties: - - samsung,vbus-gpio: if present, specifies the GPIO that - needs to be pulled up for the bus to be powered. - -Example: - - usb@12110000 { - compatible = "samsung,exynos4210-ehci"; - reg = <0x12110000 0x100>; - interrupts = <0 71 0>; - samsung,vbus-gpio = <&gpx2 6 1 3 3>; - - clocks = <&clock 285>; - clock-names = "usbhost"; - - phys = <&usb2phy 1>; - phy-names = "host"; - }; - -OHCI -Required properties: - - compatible: should be "samsung,exynos4210-ohci" for USB 2.0 - OHCI companion controller in host mode. - - reg: physical base address of the controller and length of memory mapped - region. - - interrupts: interrupt number to the cpu. - - clocks: from common clock binding: handle to usb clock. - - clock-names: from common clock binding: Shall be "usbhost". - - phys: from the *Generic PHY* bindings; array specifying phy(s) used - by the root port. - - phy-names: from the *Generic PHY* bindings; array of the names for - each phy for the root ports, must be a subset of the following: - "host", "hsic0", "hsic1". - -Example: - usb@12120000 { - compatible = "samsung,exynos4210-ohci"; - reg = <0x12120000 0x100>; - interrupts = <0 71 0>; - - clocks = <&clock 285>; - clock-names = "usbhost"; - - phys = <&usb2phy 1>; - phy-names = "host"; - }; - -DWC3 -Required properties: - - compatible: should be one of the following - - "samsung,exynos5250-dwusb3": for USB 3.0 DWC3 controller on - Exynos5250/5420. - "samsung,exynos5433-dwusb3": for USB 3.0 DWC3 controller on - Exynos5433. - "samsung,exynos7-dwusb3": for USB 3.0 DWC3 controller on Exynos7. - - #address-cells, #size-cells : should be '1' if the device has sub-nodes - with 'reg' property. - - ranges: allows valid 1:1 translation between child's address space and - parent's address space - - clocks: Clock IDs array as required by the controller. - - clock-names: Names of clocks corresponding to IDs in the clock property. - Following clock names shall be provided for different - compatibles: - - samsung,exynos5250-dwusb3: "usbdrd30", - - samsung,exynos5433-dwusb3: "aclk", "susp_clk", "pipe_pclk", - "phyclk", - - samsung,exynos7-dwusb3: "usbdrd30", "usbdrd30_susp_clk", - "usbdrd30_axius_clk" - - vdd10-supply: 1.0V powr supply - - vdd33-supply: 3.0V/3.3V power supply - -Sub-nodes: -The dwc3 core should be added as subnode to Exynos dwc3 glue. -- dwc3 : - The binding details of dwc3 can be found in: - Documentation/devicetree/bindings/usb/snps,dwc3.yaml - -Example: - usb@12000000 { - compatible = "samsung,exynos5250-dwusb3"; - clocks = <&clock 286>; - clock-names = "usbdrd30"; - #address-cells = <1>; - #size-cells = <1>; - ranges; - vdd10-supply = <&ldo11_reg>; - vdd33-supply = <&ldo9_reg>; - - dwc3 { - compatible = "synopsys,dwc3"; - reg = <0x12000000 0x10000>; - interrupts = <0 72 0>; - usb-phy = <&usb2_phy &usb3_phy>; - }; - }; diff --git a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml index 974032b1fda0..01ab0f922ae8 100644 --- a/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/fsl,imx8mp-dwc3.yaml @@ -15,9 +15,9 @@ properties: const: fsl,imx8mp-dwc3 reg: - maxItems: 1 - description: Address and length of the register set for the wrapper of - dwc3 core on the SOC. + items: + - description: Address and length of the register set for HSIO Block Control + - description: Address and length of the register set for the wrapper of dwc3 core on the SOC. "#address-cells": enum: [ 1, 2 ] @@ -49,6 +49,28 @@ properties: - const: hsio - const: suspend + fsl,permanently-attached: + type: boolean + description: + Indicates if the device atached to a downstream port is + permanently attached. + + fsl,disable-port-power-control: + type: boolean + description: + Indicates whether the host controller implementation includes port + power control. Defines Bit 3 in capability register (HCCPARAMS). + + fsl,over-current-active-low: + type: boolean + description: + Over current signal polarity is active low. + + fsl,power-active-low: + type: boolean + description: + Power pad (PWR) polarity is active low. + # Required child node: patternProperties: @@ -74,7 +96,8 @@ examples: #include <dt-bindings/interrupt-controller/arm-gic.h> usb3_0: usb@32f10100 { compatible = "fsl,imx8mp-dwc3"; - reg = <0x32f10100 0x8>; + reg = <0x32f10100 0x8>, + <0x381f0000 0x20>; clocks = <&clk IMX8MP_CLK_HSIO_ROOT>, <&clk IMX8MP_CLK_USB_ROOT>; clock-names = "hsio", "suspend"; diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml index 11f7bacd4e2b..084d7135b2d9 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtk-xhci.yaml @@ -30,6 +30,7 @@ properties: - mediatek,mt7629-xhci - mediatek,mt8173-xhci - mediatek,mt8183-xhci + - mediatek,mt8186-xhci - mediatek,mt8192-xhci - mediatek,mt8195-xhci - const: mediatek,mtk-xhci @@ -146,7 +147,11 @@ properties: 2 - used by mt2712 etc, revision 2 following IPM rule; 101 - used by mt8183, specific 1.01; 102 - used by mt8192, specific 1.02; - enum: [1, 2, 101, 102] + 103 - used by mt8195, IP0, specific 1.03; + 104 - used by mt8195, IP1, specific 1.04; + 105 - used by mt8195, IP2, specific 1.05; + 106 - used by mt8195, IP3, specific 1.06; + enum: [1, 2, 101, 102, 103, 104, 105, 106] mediatek,u3p-dis-msk: $ref: /schemas/types.yaml#/definitions/uint32 diff --git a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml index 77db1233516e..df766f8de872 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,mtu3.yaml @@ -132,7 +132,7 @@ properties: default: host connector: - $ref: /connector/usb-connector.yaml# + $ref: /schemas/connector/usb-connector.yaml# description: Connector for dual role switch, especially for "gpio-usb-b-connector" type: object @@ -191,7 +191,7 @@ properties: patternProperties: "^usb@[0-9a-f]+$": type: object - $ref: /usb/mediatek,mtk-xhci.yaml# + $ref: /schemas/usb/mediatek,mtk-xhci.yaml# description: The xhci should be added as subnode to mtu3 as shown in the following example if the host mode is enabled. diff --git a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml index 03d62d60ce5f..11a33f9b1f17 100644 --- a/Documentation/devicetree/bindings/usb/mediatek,musb.yaml +++ b/Documentation/devicetree/bindings/usb/mediatek,musb.yaml @@ -63,7 +63,7 @@ properties: maxItems: 1 connector: - $ref: /connector/usb-connector.yaml# + $ref: /schemas/connector/usb-connector.yaml# description: Connector for dual role switch type: object diff --git a/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml new file mode 100644 index 000000000000..48c458c65848 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/microchip,mpfs-musb.yaml @@ -0,0 +1,59 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/microchip,mpfs-musb.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Microchip MPFS USB Controller Device Tree Bindings + +allOf: + - $ref: usb-drd.yaml# + +maintainers: + - Conor Dooley <conor.dooley@microchip.com> + +properties: + compatible: + enum: + - microchip,mpfs-musb + + dr_mode: true + + reg: + maxItems: 1 + + interrupts: + minItems: 2 + maxItems: 2 + + interrupt-names: + items: + - const: dma + - const: mc + + clocks: + maxItems: 1 + +required: + - compatible + - reg + - interrupts + - interrupt-names + - clocks + +additionalProperties: false + +examples: + - | + #include "dt-bindings/clock/microchip,mpfs-clock.h" + usb@20201000 { + compatible = "microchip,mpfs-musb"; + reg = <0x20201000 0x1000>; + clocks = <&clkcfg CLK_USB>; + interrupt-parent = <&plic>; + interrupts = <86>, <87>; + interrupt-names = "dma", "mc"; + dr_mode = "host"; + }; + +... diff --git a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml index a39c76b89484..fd6e7c81426e 100644 --- a/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml +++ b/Documentation/devicetree/bindings/usb/nvidia,tegra-xudc.yaml @@ -83,7 +83,7 @@ properties: - const: ss nvidia,xusb-padctl: - $ref: /schemas/types.yaml#/definitions/phandle-array + $ref: /schemas/types.yaml#/definitions/phandle description: phandle to the XUSB pad controller that is used to configure the USB pads used by the XUDC controller. diff --git a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml index 2d23a4ff702f..ce252db2aab3 100644 --- a/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/qcom,dwc3.yaml @@ -16,6 +16,7 @@ properties: - qcom,ipq4019-dwc3 - qcom,ipq6018-dwc3 - qcom,ipq8064-dwc3 + - qcom,msm8953-dwc3 - qcom,msm8996-dwc3 - qcom,msm8998-dwc3 - qcom,sc7180-dwc3 diff --git a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml index 012fe80a7611..0bb841b28003 100644 --- a/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml +++ b/Documentation/devicetree/bindings/usb/renesas,usbhs.yaml @@ -20,6 +20,7 @@ properties: - enum: - renesas,usbhs-r7s9210 # RZ/A2 - renesas,usbhs-r9a07g044 # RZ/G2{L,LC} + - renesas,usbhs-r9a07g054 # RZ/V2L - const: renesas,rza2-usbhs - items: @@ -116,7 +117,9 @@ allOf: properties: compatible: contains: - const: renesas,usbhs-r9a07g044 + enum: + - renesas,usbhs-r9a07g044 + - renesas,usbhs-r9a07g054 then: properties: interrupts: diff --git a/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml new file mode 100644 index 000000000000..65a93f7738d5 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/richtek,rt1719.yaml @@ -0,0 +1,85 @@ +# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause +%YAML 1.2 +--- +$id: "http://devicetree.org/schemas/usb/richtek,rt1719.yaml#" +$schema: "http://devicetree.org/meta-schemas/core.yaml#" + +title: Richtek RT1719 sink-only Type-C PD controller bindings + +maintainers: + - ChiYuan Huang <cy_huang@richtek.com> + +description: | + The RT1719 is a sink-only USB Type-C contoller that complies with the latest + USB Type-C and PD standards. It does the USB Type-C detection including attach + and orientation. It integrates the physical layer of the USB BMC power + delivery protocol to allow up to 100W of power. The BMC PD block enables full + support for alternative interfaces of the Type-C specification. + +properties: + compatible: + enum: + - richtek,rt1719 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + wakeup-source: + description: enable IRQ remote wakeup, see power/wakeup-source.txt + type: boolean + + connector: + type: object + $ref: ../connector/usb-connector.yaml# + description: + Properties for usb c connector. + +additionalProperties: false + +required: + - compatible + - reg + - connector + - interrupts + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + i2c0 { + #address-cells = <1>; + #size-cells = <0>; + + rt1719@43 { + compatible = "richtek,rt1719"; + reg = <0x43>; + interrupts-extended = <&gpio26 2 IRQ_TYPE_LEVEL_LOW>; + wakeup-source; + + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + + ports { + #address-cells = <1>; + #size-cells = <0>; + + port@0 { + reg = <0>; + endpoint { + remote-endpoint = <&usb_hs>; + }; + }; + port@1 { + reg = <1>; + endpoint { + remote-endpoint = <&usb_ss>; + }; + }; + }; + }; + }; + }; +... diff --git a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml index 04077f2d7faf..b3798d94d2fd 100644 --- a/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/rockchip,dwc3.yaml @@ -30,6 +30,7 @@ select: enum: - rockchip,rk3328-dwc3 - rockchip,rk3399-dwc3 + - rockchip,rk3568-dwc3 required: - compatible @@ -39,6 +40,7 @@ properties: - enum: - rockchip,rk3328-dwc3 - rockchip,rk3399-dwc3 + - rockchip,rk3568-dwc3 - const: snps,dwc3 reg: diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml new file mode 100644 index 000000000000..22b91a27d776 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-dwc3.yaml @@ -0,0 +1,129 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/samsung,exynos-dwc3.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 3.0 DWC3 Controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - samsung,exynos5250-dwusb3 + - samsung,exynos5433-dwusb3 + - samsung,exynos7-dwusb3 + + '#address-cells': + const: 1 + + clocks: + minItems: 1 + maxItems: 4 + + clock-names: + minItems: 1 + maxItems: 4 + + ranges: true + + '#size-cells': + const: 1 + + vdd10-supply: + description: 1.0V power supply + + vdd33-supply: + description: 3.0V/3.3V power supply + +patternProperties: + "^usb@[0-9a-f]+$": + $ref: snps,dwc3.yaml# + description: Required child node + +required: + - compatible + - '#address-cells' + - clocks + - clock-names + - ranges + - '#size-cells' + - vdd10-supply + - vdd33-supply + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos5250-dwusb3 + then: + properties: + clocks: + minItems: 1 + maxItems: 1 + clock-names: + items: + - const: usbdrd30 + + - if: + properties: + compatible: + contains: + const: samsung,exynos54333-dwusb3 + then: + properties: + clocks: + minItems: 4 + maxItems: 4 + clock-names: + items: + - const: aclk + - const: susp_clk + - const: pipe_pclk + - const: phyclk + + - if: + properties: + compatible: + contains: + const: samsung,exynos7-dwusb3 + then: + properties: + clocks: + minItems: 3 + maxItems: 3 + clock-names: + items: + - const: usbdrd30 + - const: usbdrd30_susp_clk + - const: usbdrd30_axius_clk + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb { + compatible = "samsung,exynos5250-dwusb3"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + clocks = <&clock CLK_USBD300>; + clock-names = "usbdrd30"; + vdd33-supply = <&ldo9_reg>; + vdd10-supply = <&ldo11_reg>; + + usb@12000000 { + compatible = "snps,dwc3"; + reg = <0x12000000 0x10000>; + interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; + phys = <&usbdrd_phy0 0>, <&usbdrd_phy0 1>; + phy-names = "usb2-phy", "usb3-phy"; + snps,dis_u3_susphy_quirk; + }; + }; diff --git a/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml new file mode 100644 index 000000000000..fbf07d6e707a --- /dev/null +++ b/Documentation/devicetree/bindings/usb/samsung,exynos-usb2.yaml @@ -0,0 +1,117 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/samsung,exynos-usb2.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: Samsung Exynos SoC USB 2.0 EHCI/OHCI Controller + +maintainers: + - Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com> + +properties: + compatible: + enum: + - samsung,exynos4210-ehci + - samsung,exynos4210-ohci + + '#address-cells': + const: 1 + + clocks: + maxItems: 1 + + clock-names: + items: + - const: usbhost + + interrupts: + maxItems: 1 + + phys: + minItems: 1 + maxItems: 3 + + phy-names: + items: + enum: [host, hsic0, hsic1] + minItems: 1 + maxItems: 3 + + reg: + maxItems: 1 + + samsung,vbus-gpio: + description: + Only for controller in EHCI mode, if present, specifies the GPIO that + needs to be pulled up for the bus to be powered. + + '#size-cells': + const: 0 + +patternProperties: + "^.*@[0-9a-f]{1,2}$": + description: The hard wired USB devices + type: object + $ref: /usb/usb-device.yaml + +required: + - compatible + - clocks + - clock-names + - interrupts + - phys + - phy-names + +allOf: + - if: + properties: + compatible: + contains: + const: samsung,exynos4210-ohci + then: + properties: + samsung,vbus-gpio: false + +additionalProperties: false + +examples: + - | + #include <dt-bindings/clock/exynos5420.h> + #include <dt-bindings/interrupt-controller/arm-gic.h> + + usb@12110000 { + compatible = "samsung,exynos4210-ehci"; + reg = <0x12110000 0x100>; + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_USBH20>; + clock-names = "usbhost"; + phys = <&usb2_phy 0>; + phy-names = "host"; + + #address-cells = <1>; + #size-cells = <0>; + + hub@1 { + compatible = "usb0424,9514"; + reg = <1>; + #address-cells = <1>; + #size-cells = <0>; + + usbether@1 { + compatible = "usb0424,ec00"; + reg = <1>; + local-mac-address = [00 00 00 00 00 00]; + }; + }; + }; + + usb@12120000 { + compatible = "samsung,exynos4210-ohci"; + reg = <0x12120000 0x100>; + interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>; + clocks = <&clock CLK_USBH20>; + clock-names = "usbhost"; + phys = <&usb2_phy 0>; + phy-names = "host"; + }; diff --git a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml index d29ffcd27472..f4471f8bdbef 100644 --- a/Documentation/devicetree/bindings/usb/snps,dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/snps,dwc3.yaml @@ -263,8 +263,11 @@ properties: Value for REFCLKPER field of GUCTL register for reference clock period in nanoseconds, when the hardware set default does not match the actual clock. - minimum: 1 - maximum: 0x3ff + + This binding is deprecated. Instead, provide an appropriate reference clock. + minimum: 8 + maximum: 62 + deprecated: true snps,rx-thr-num-pkt-prd: description: @@ -332,6 +335,12 @@ properties: items: enum: [1, 4, 8, 16, 32, 64, 128, 256] + port: + $ref: /schemas/graph.yaml#/properties/port + description: + This port is used with the 'usb-role-switch' property to connect the + dwc3 to type C connector. + unevaluatedProperties: false required: diff --git a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml index ead1571e0e43..b5a8c9814dd3 100644 --- a/Documentation/devicetree/bindings/usb/st,stusb160x.yaml +++ b/Documentation/devicetree/bindings/usb/st,stusb160x.yaml @@ -32,9 +32,7 @@ properties: connector: type: object - - allOf: - - $ref: ../connector/usb-connector.yaml + $ref: /schemas/connector/usb-connector.yaml# properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml index a634774c537c..eedde385d299 100644 --- a/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml +++ b/Documentation/devicetree/bindings/usb/ti,j721e-usb.yaml @@ -7,7 +7,7 @@ $schema: "http://devicetree.org/meta-schemas/core.yaml#" title: Bindings for the TI wrapper module for the Cadence USBSS-DRD controller maintainers: - - Roger Quadros <rogerq@ti.com> + - Roger Quadros <rogerq@kernel.org> properties: compatible: diff --git a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml index f6e91a5fd8fe..c1f0194ad0d5 100644 --- a/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml +++ b/Documentation/devicetree/bindings/usb/ti,keystone-dwc3.yaml @@ -7,7 +7,7 @@ $schema: http://devicetree.org/meta-schemas/core.yaml# title: TI Keystone Soc USB Controller maintainers: - - Roger Quadros <rogerq@ti.com> + - Roger Quadros <rogerq@kernel.org> properties: compatible: @@ -92,7 +92,7 @@ examples: ranges; usb@2690000 { - compatible = "synopsys,dwc3"; + compatible = "snps,dwc3"; reg = <0x2690000 0x70000>; interrupts = <GIC_SPI 393 IRQ_TYPE_EDGE_RISING>; usb-phy = <&usb_phy>, <&usb_phy>; diff --git a/Documentation/devicetree/bindings/usb/usb-hcd.yaml b/Documentation/devicetree/bindings/usb/usb-hcd.yaml index 56853c17af66..1dc3d5d7b44f 100644 --- a/Documentation/devicetree/bindings/usb/usb-hcd.yaml +++ b/Documentation/devicetree/bindings/usb/usb-hcd.yaml @@ -33,7 +33,7 @@ patternProperties: "^.*@[0-9a-f]{1,2}$": description: The hard wired USB devices type: object - $ref: /usb/usb-device.yaml + $ref: /schemas/usb/usb-device.yaml additionalProperties: true diff --git a/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml new file mode 100644 index 000000000000..c2b2243c7892 --- /dev/null +++ b/Documentation/devicetree/bindings/usb/willsemi,wusb3801.yaml @@ -0,0 +1,75 @@ +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause) +%YAML 1.2 +--- +$id: http://devicetree.org/schemas/usb/willsemi,wusb3801.yaml# +$schema: http://devicetree.org/meta-schemas/core.yaml# + +title: WUSB3801 Type-C port controller DT bindings + +description: + The Will Semiconductor WUSB3801 is a USB Type-C port controller which + supports role and plug orientation detection using the CC pins. It is + compatible with the USB Type-C Cable and Connector Specification v1.2. + +maintainers: + - Samuel Holland <samuel@sholland.org> + +properties: + compatible: + enum: + - willsemi,wusb3801 + + reg: + maxItems: 1 + + interrupts: + maxItems: 1 + + connector: + type: object + $ref: ../connector/usb-connector.yaml# + description: + The managed USB Type-C connector. Since WUSB3801 does not support + Power Delivery, the node should have the "pd-disable" property. + + properties: + compatible: + const: usb-c-connector + + required: + - pd-disable + +required: + - compatible + - reg + - interrupts + - connector + +additionalProperties: false + +examples: + - | + #include <dt-bindings/interrupt-controller/irq.h> + + i2c { + #address-cells = <1>; + #size-cells = <0>; + + tcpc@60 { + compatible = "willsemi,wusb3801"; + reg = <0x60>; + interrupt-parent = <&gpio0>; + interrupts = <4 IRQ_TYPE_LEVEL_LOW>; + + connector { + compatible = "usb-c-connector"; + label = "USB-C"; + vbus-supply = <&otg_switch>; + power-role = "dual"; + try-power-role = "sink"; + data-role = "dual"; + typec-power-opmode = "default"; + pd-disable; + }; + }; + }; diff --git a/Documentation/devicetree/bindings/vendor-prefixes.yaml b/Documentation/devicetree/bindings/vendor-prefixes.yaml index 294093d45a23..01430973ecec 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.yaml +++ b/Documentation/devicetree/bindings/vendor-prefixes.yaml @@ -23,6 +23,8 @@ patternProperties: "^(simple-audio-card|st-plgpio|st-spics|ts),.*": true # Keep list in alphabetical order. + "^100ask,.*": + description: Baiwen.com (100ask). "^70mai,.*": description: 70mai Co., Ltd. "^8dev,.*": @@ -61,6 +63,8 @@ patternProperties: description: Aeroflex Gaisler AB "^aesop,.*": description: AESOP Embedded Forum + "^airoha,.*": + description: Airoha "^al,.*": description: Annapurna Labs "^alcatel,.*": @@ -277,12 +281,16 @@ patternProperties: description: Hangzhou C-SKY Microsystems Co., Ltd "^csq,.*": description: Shenzen Chuangsiqi Technology Co.,Ltd. + "^ctera,.*": + description: CTERA Networks Intl. "^cubietech,.*": description: Cubietech, Ltd. "^cui,.*": description: CUI Devices "^cypress,.*": description: Cypress Semiconductor Corporation + "^cyx,.*": + description: Shenzhen CYX Industrial Co., Ltd "^cznic,.*": description: CZ.NIC, z.s.p.o. "^dallas,.*": @@ -489,6 +497,8 @@ patternProperties: deprecated: true "^hannstar,.*": description: HannStar Display Corporation + "^haochuangyi,.*": + description: Shenzhen Haochuangyi Technology Co.,Ltd "^haoyu,.*": description: Haoyu Microelectronic Co. Ltd. "^hardkernel,.*": @@ -499,6 +509,9 @@ patternProperties: description: Himax Technologies, Inc. "^hirschmann,.*": description: Hirschmann Automation and Control GmbH + "^hisi,.*": + description: HiSilicon Limited (deprecated, use hisilicon) + deprecated: true "^hisilicon,.*": description: HiSilicon Limited. "^hit,.*": @@ -514,7 +527,9 @@ patternProperties: "^hoperun,.*": description: Jiangsu HopeRun Software Co., Ltd. "^hp,.*": - description: Hewlett Packard + description: Hewlett Packard Inc. + "^hpe,.*": + description: Hewlett Packard Enterprise "^hsg,.*": description: HannStar Display Co. "^holtek,.*": @@ -545,6 +560,8 @@ patternProperties: description: Ingenieurburo Fur Ic-Technologie (I/F/I) "^ilitek,.*": description: ILI Technology Corporation (ILITEK) + "^imagis,.*": + description: Imagis Technologies Co., Ltd. "^img,.*": description: Imagination Technologies Ltd. "^imi,.*": @@ -561,6 +578,8 @@ patternProperties: description: InfoVision Optoelectronics Kunshan Co. Ltd. "^ingenic,.*": description: Ingenic Semiconductor + "^injoinic,.*": + description: Injoinic Technology Corp. "^innolux,.*": description: Innolux Corporation "^inside-secure,.*": @@ -769,6 +788,8 @@ patternProperties: description: MiraMEMS Sensing Technology Co., Ltd. "^mitsubishi,.*": description: Mitsubishi Electric Corporation + "^miyoo,.*": + description: Miyoo "^mntre,.*": description: MNT Research GmbH "^modtronix,.*": @@ -802,6 +823,9 @@ patternProperties: description: Mundo Reader S.L. "^murata,.*": description: Murata Manufacturing Co., Ltd. + "^mxic,.*": + description: Macronix International Co., Ltd. + deprecated: true "^mxicy,.*": description: Macronix International Co., Ltd. "^myir,.*": @@ -854,6 +878,8 @@ patternProperties: description: NXP Semiconductors "^oceanic,.*": description: Oceanic Systems (UK) Ltd. + "^ocs,.*": + description: Orient Chip Technology Co., Ltd. "^oct,.*": description: Octavo Systems LLC "^okaya,.*": @@ -892,6 +918,8 @@ patternProperties: description: Ortus Technology Co., Ltd. "^osddisplays,.*": description: OSD Displays + "^osmc,.*": + description: Sam Nazarko Trading Ltd. (Open Source Media Centre) "^ouya,.*": description: Ouya Inc. "^overkiz,.*": @@ -1082,6 +1110,8 @@ patternProperties: description: Silicon Image "^silabs,.*": description: Silicon Laboratories + "^silan,.*": + description: Hangzhou Silan Microelectronics Co., Ltd. "^silead,.*": description: Silead Inc. "^silergy,.*": @@ -1181,6 +1211,9 @@ patternProperties: description: Synaptics Inc. "^synology,.*": description: Synology, Inc. + "^synopsys,.*": + description: Synopsys, Inc. (deprecated, use snps) + deprecated: true "^tbs,.*": description: TBS Technologies "^tbs-biometrics,.*": @@ -1205,6 +1238,8 @@ patternProperties: description: Shenzhen Techstar Electronics Co., Ltd. "^terasic,.*": description: Terasic Inc. + "^tesla,.*": + description: Tesla, Inc. "^tfc,.*": description: Three Five Corp "^thead,.*": @@ -1298,6 +1333,8 @@ patternProperties: description: Vertexcom Technologies, Inc. "^via,.*": description: VIA Technologies, Inc. + "^vicor,.*": + description: Vicor Corporation "^videostrong,.*": description: Videostrong Technology Co., Ltd. "^virtio,.*": @@ -1340,6 +1377,8 @@ patternProperties: description: Wi2Wi, Inc. "^wiligear,.*": description: Wiligear, Ltd. + "^willsemi,.*": + description: Will Semiconductor Ltd. "^winbond,.*": description: Winbond Electronics corp. "^wingtech,.*": @@ -1348,6 +1387,8 @@ patternProperties: description: WinLink Co., Ltd "^winstar,.*": description: Winstar Display Corp. + "^wirelesstag,.*": + description: Wireless Tag (qiming yunduan) "^wits,.*": description: Shenzhen Merrii Technology Co., Ltd. (WITS) "^wlf,.*": @@ -1360,6 +1401,8 @@ patternProperties: description: Wanchanglong Electronics Technology（SHENZHEN）Co.，Ltd. "^x-powers,.*": description: X-Powers + "^xen,.*": + description: Xen Hypervisor "^xes,.*": description: Extreme Engineering Solutions (X-ES) "^xiaomi,.*": diff --git a/Documentation/devicetree/bindings/virtio/mmio.yaml b/Documentation/devicetree/bindings/virtio/mmio.yaml index 4b7a0273181c..10c22b5bd16a 100644 --- a/Documentation/devicetree/bindings/virtio/mmio.yaml +++ b/Documentation/devicetree/bindings/virtio/mmio.yaml @@ -20,6 +20,8 @@ properties: reg: maxItems: 1 + dma-coherent: true + interrupts: maxItems: 1 diff --git a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml index fb603a20e396..4ca8a31359a5 100644 --- a/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/fsl-imx7ulp-wdt.yaml @@ -29,12 +29,6 @@ properties: clocks: maxItems: 1 - assigned-clocks: - maxItems: 1 - - assigned-clocks-parents: - maxItems: 1 - timeout-sec: true required: @@ -56,7 +50,7 @@ examples: interrupts = <GIC_SPI 55 IRQ_TYPE_LEVEL_HIGH>; clocks = <&pcc2 IMX7ULP_CLK_WDG1>; assigned-clocks = <&pcc2 IMX7ULP_CLK_WDG1>; - assigned-clocks-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; + assigned-clock-parents = <&scg1 IMX7ULP_CLK_FIRC_BUS_CLK>; timeout-sec = <40>; }; diff --git a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt index 0114871f887a..a97418c74f6b 100644 --- a/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt +++ b/Documentation/devicetree/bindings/watchdog/mtk-wdt.txt @@ -8,6 +8,7 @@ Required properties: - compatible should contain: "mediatek,mt2701-wdt", "mediatek,mt6589-wdt": for MT2701 "mediatek,mt2712-wdt": for MT2712 + "mediatek,mt6582-wdt", "mediatek,mt6589-wdt": for MT6582 "mediatek,mt6589-wdt": for MT6589 "mediatek,mt6797-wdt", "mediatek,mt6589-wdt": for MT6797 "mediatek,mt7622-wdt", "mediatek,mt6589-wdt": for MT7622 diff --git a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml index 91a98ccd4226..d060438e1402 100644 --- a/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml +++ b/Documentation/devicetree/bindings/watchdog/renesas,wdt.yaml @@ -55,6 +55,11 @@ properties: - renesas,r8a779a0-wdt # R-Car V3U - const: renesas,rcar-gen3-wdt # R-Car Gen3 and RZ/G2 + - items: + - enum: + - renesas,r8a779f0-wdt # R-Car S4-8 + - const: renesas,rcar-gen4-wdt # R-Car Gen4 + reg: maxItems: 1 diff --git a/Documentation/devicetree/bindings/writing-schema.rst b/Documentation/devicetree/bindings/writing-schema.rst index ea21c72aeb37..95ecf55559e5 100644 --- a/Documentation/devicetree/bindings/writing-schema.rst +++ b/Documentation/devicetree/bindings/writing-schema.rst @@ -118,22 +118,15 @@ The DT schema project must be installed in order to validate the DT schema binding documents and validate DTS files using the DT schema. The DT schema project can be installed with pip:: - pip3 install git+https://github.com/devicetree-org/dt-schema.git@master + pip3 install dtschema -Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be -installed. Ensure they are in your PATH (~/.local/bin by default). - -dtc must also be built with YAML output support enabled. This requires that -libyaml and its headers be installed on the host system. For some distributions -that involves installing the development package, such as: - -Debian:: +Note that 'dtschema' installation requires 'swig' and Python development files +installed first. On Debian/Ubuntu systems:: - apt-get install libyaml-dev + apt install swig python3-dev -Fedora:: - - dnf -y install libyaml-devel +Several executables (dt-doc-validate, dt-mk-schema, dt-validate) will be +installed. Ensure they are in your PATH (~/.local/bin by default). Running checks ~~~~~~~~~~~~~~ @@ -157,13 +150,14 @@ It is possible to run both in a single command:: make dt_binding_check dtbs_check -It is also possible to run checks with a single schema file by setting the -``DT_SCHEMA_FILES`` variable to a specific schema file. +It is also possible to run checks with a subset of matching schema files by +setting the ``DT_SCHEMA_FILES`` variable to a specific schema file or pattern. :: - make dt_binding_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml - make dtbs_check DT_SCHEMA_FILES=Documentation/devicetree/bindings/trivial-devices.yaml + make dt_binding_check DT_SCHEMA_FILES=trivial-devices.yaml + make dt_binding_check DT_SCHEMA_FILES=/gpio/ + make dtbs_check DT_SCHEMA_FILES=trivial-devices.yaml json-schema Resources diff --git a/Documentation/devicetree/of_unittest.rst b/Documentation/devicetree/of_unittest.rst index 2afe41a37148..8864b52d1195 100644 --- a/Documentation/devicetree/of_unittest.rst +++ b/Documentation/devicetree/of_unittest.rst @@ -24,7 +24,28 @@ from the unflattened device tree data structure. This interface is used by most of the device drivers in various use cases. -2. Test-data +2. Verbose Output (EXPECT) +========================== + +If unittest detects a problem it will print a warning or error message to +the console. Unittest also triggers warning and error messages from other +kernel code as a result of intentionally bad unittest data. This has led +to confusion as to whether the triggered messages are an expected result +of a test or whether there is a real problem that is independent of unittest. + +'EXPECT \ : text' (begin) and 'EXPECT / : text' (end) messages have been +added to unittest to report that a warning or error is expected. The +begin is printed before triggering the warning or error, and the end is +printed after triggering the warning or error. + +The EXPECT messages result in very noisy console messages that are difficult +to read. The script scripts/dtc/of_unittest_expect was created to filter +this verbosity and highlight mismatches between triggered warnings and +errors vs expected warnings and errors. More information is available +from 'scripts/dtc/of_unittest_expect --help'. + + +3. Test-data ============ The Device Tree Source file (drivers/of/unittest-data/testcases.dts) contains @@ -56,7 +77,7 @@ The assembly file is compiled into an object file (testcases.dtb.o), and is linked into the kernel image. -2.1. Adding the test data +3.1. Adding the test data ------------------------- Un-flattened device tree structure: @@ -191,7 +212,7 @@ properties are updated to the live tree's node by calling the function update_node_properties(). -2.2. Removing the test data +3.2. Removing the test data --------------------------- Once the test case execution is complete, selftest_data_remove is called in diff --git a/Documentation/driver-api/cxl/memory-devices.rst b/Documentation/driver-api/cxl/memory-devices.rst index 3b8f41395f6b..db476bb170b6 100644 --- a/Documentation/driver-api/cxl/memory-devices.rst +++ b/Documentation/driver-api/cxl/memory-devices.rst @@ -14,6 +14,303 @@ that optionally define a device's contribution to an interleaved address range across multiple devices underneath a host-bridge or interleaved across host-bridges. +CXL Bus: Theory of Operation +============================ +Similar to how a RAID driver takes disk objects and assembles them into a new +logical device, the CXL subsystem is tasked to take PCIe and ACPI objects and +assemble them into a CXL.mem decode topology. The need for runtime configuration +of the CXL.mem topology is also similar to RAID in that different environments +with the same hardware configuration may decide to assemble the topology in +contrasting ways. One may choose performance (RAID0) striping memory across +multiple Host Bridges and endpoints while another may opt for fault tolerance +and disable any striping in the CXL.mem topology. + +Platform firmware enumerates a menu of interleave options at the "CXL root port" +(Linux term for the top of the CXL decode topology). From there, PCIe topology +dictates which endpoints can participate in which Host Bridge decode regimes. +Each PCIe Switch in the path between the root and an endpoint introduces a point +at which the interleave can be split. For example platform firmware may say at a +given range only decodes to 1 one Host Bridge, but that Host Bridge may in turn +interleave cycles across multiple Root Ports. An intervening Switch between a +port and an endpoint may interleave cycles across multiple Downstream Switch +Ports, etc. + +Here is a sample listing of a CXL topology defined by 'cxl_test'. The 'cxl_test' +module generates an emulated CXL topology of 2 Host Bridges each with 2 Root +Ports. Each of those Root Ports are connected to 2-way switches with endpoints +connected to those downstream ports for a total of 8 endpoints:: + + # cxl list -BEMPu -b cxl_test + { + "bus":"root3", + "provider":"cxl_test", + "ports:root3":[ + { + "port":"port5", + "host":"cxl_host_bridge.1", + "ports:port5":[ + { + "port":"port8", + "host":"cxl_switch_uport.1", + "endpoints:port8":[ + { + "endpoint":"endpoint9", + "host":"mem2", + "memdev":{ + "memdev":"mem2", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x1", + "numa_node":1, + "host":"cxl_mem.1" + } + }, + { + "endpoint":"endpoint15", + "host":"mem6", + "memdev":{ + "memdev":"mem6", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x5", + "numa_node":1, + "host":"cxl_mem.5" + } + } + ] + }, + { + "port":"port12", + "host":"cxl_switch_uport.3", + "endpoints:port12":[ + { + "endpoint":"endpoint17", + "host":"mem8", + "memdev":{ + "memdev":"mem8", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x7", + "numa_node":1, + "host":"cxl_mem.7" + } + }, + { + "endpoint":"endpoint13", + "host":"mem4", + "memdev":{ + "memdev":"mem4", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x3", + "numa_node":1, + "host":"cxl_mem.3" + } + } + ] + } + ] + }, + { + "port":"port4", + "host":"cxl_host_bridge.0", + "ports:port4":[ + { + "port":"port6", + "host":"cxl_switch_uport.0", + "endpoints:port6":[ + { + "endpoint":"endpoint7", + "host":"mem1", + "memdev":{ + "memdev":"mem1", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0", + "numa_node":0, + "host":"cxl_mem.0" + } + }, + { + "endpoint":"endpoint14", + "host":"mem5", + "memdev":{ + "memdev":"mem5", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x4", + "numa_node":0, + "host":"cxl_mem.4" + } + } + ] + }, + { + "port":"port10", + "host":"cxl_switch_uport.2", + "endpoints:port10":[ + { + "endpoint":"endpoint16", + "host":"mem7", + "memdev":{ + "memdev":"mem7", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x6", + "numa_node":0, + "host":"cxl_mem.6" + } + }, + { + "endpoint":"endpoint11", + "host":"mem3", + "memdev":{ + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + } + ] + } + ] + } + ] + } + +In that listing each "root", "port", and "endpoint" object correspond a kernel +'struct cxl_port' object. A 'cxl_port' is a device that can decode CXL.mem to +its descendants. So "root" claims non-PCIe enumerable platform decode ranges and +decodes them to "ports", "ports" decode to "endpoints", and "endpoints" +represent the decode from SPA (System Physical Address) to DPA (Device Physical +Address). + +Continuing the RAID analogy, disks have both topology metadata and on device +metadata that determine RAID set assembly. CXL Port topology and CXL Port link +status is metadata for CXL.mem set assembly. The CXL Port topology is enumerated +by the arrival of a CXL.mem device. I.e. unless and until the PCIe core attaches +the cxl_pci driver to a CXL Memory Expander there is no role for CXL Port +objects. Conversely for hot-unplug / removal scenarios, there is no need for +the Linux PCI core to tear down switch-level CXL resources because the endpoint +->remove() event cleans up the port data that was established to support that +Memory Expander. + +The port metadata and potential decode schemes that a give memory device may +participate can be determined via a command like:: + + # cxl list -BDMu -d root -m mem3 + { + "bus":"root3", + "provider":"cxl_test", + "decoders:root3":[ + { + "decoder":"decoder3.1", + "resource":"0x8030000000", + "size":"512.00 MiB (536.87 MB)", + "volatile_capable":true, + "nr_targets":2 + }, + { + "decoder":"decoder3.3", + "resource":"0x8060000000", + "size":"512.00 MiB (536.87 MB)", + "pmem_capable":true, + "nr_targets":2 + }, + { + "decoder":"decoder3.0", + "resource":"0x8020000000", + "size":"256.00 MiB (268.44 MB)", + "volatile_capable":true, + "nr_targets":1 + }, + { + "decoder":"decoder3.2", + "resource":"0x8050000000", + "size":"256.00 MiB (268.44 MB)", + "pmem_capable":true, + "nr_targets":1 + } + ], + "memdevs:root3":[ + { + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + ] + } + +...which queries the CXL topology to ask "given CXL Memory Expander with a kernel +device name of 'mem3' which platform level decode ranges may this device +participate". A given expander can participate in multiple CXL.mem interleave +sets simultaneously depending on how many decoder resource it has. In this +example mem3 can participate in one or more of a PMEM interleave that spans to +Host Bridges, a PMEM interleave that targets a single Host Bridge, a Volatile +memory interleave that spans 2 Host Bridges, and a Volatile memory interleave +that only targets a single Host Bridge. + +Conversely the memory devices that can participate in a given platform level +decode scheme can be determined via a command like the following:: + + # cxl list -MDu -d 3.2 + [ + { + "memdevs":[ + { + "memdev":"mem1", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0", + "numa_node":0, + "host":"cxl_mem.0" + }, + { + "memdev":"mem5", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x4", + "numa_node":0, + "host":"cxl_mem.4" + }, + { + "memdev":"mem7", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x6", + "numa_node":0, + "host":"cxl_mem.6" + }, + { + "memdev":"mem3", + "pmem_size":"256.00 MiB (268.44 MB)", + "ram_size":"256.00 MiB (268.44 MB)", + "serial":"0x2", + "numa_node":0, + "host":"cxl_mem.2" + } + ] + }, + { + "root decoders":[ + { + "decoder":"decoder3.2", + "resource":"0x8050000000", + "size":"256.00 MiB (268.44 MB)", + "pmem_capable":true, + "nr_targets":1 + } + ] + } + ] + +...where the naming scheme for decoders is "decoder<port_id>.<instance_id>". + Driver Infrastructure ===================== @@ -28,6 +325,14 @@ CXL Memory Device .. kernel-doc:: drivers/cxl/pci.c :internal: +.. kernel-doc:: drivers/cxl/mem.c + :doc: cxl mem + +CXL Port +-------- +.. kernel-doc:: drivers/cxl/port.c + :doc: cxl port + CXL Core -------- .. kernel-doc:: drivers/cxl/cxl.h @@ -36,10 +341,16 @@ CXL Core .. kernel-doc:: drivers/cxl/cxl.h :internal: -.. kernel-doc:: drivers/cxl/core/bus.c +.. kernel-doc:: drivers/cxl/core/port.c :doc: cxl core -.. kernel-doc:: drivers/cxl/core/bus.c +.. kernel-doc:: drivers/cxl/core/port.c + :identifiers: + +.. kernel-doc:: drivers/cxl/core/pci.c + :doc: cxl core pci + +.. kernel-doc:: drivers/cxl/core/pci.c :identifiers: .. kernel-doc:: drivers/cxl/core/pmem.c diff --git a/Documentation/driver-api/device-io.rst b/Documentation/driver-api/device-io.rst index e9f04b1815d1..4d2baac0311c 100644 --- a/Documentation/driver-api/device-io.rst +++ b/Documentation/driver-api/device-io.rst @@ -502,6 +502,15 @@ pcim_iomap() Not using these wrappers may make drivers unusable on certain platforms with stricter rules for mapping I/O memory. +Generalizing Access to System and I/O Memory +============================================ + +.. kernel-doc:: include/linux/iosys-map.h + :doc: overview + +.. kernel-doc:: include/linux/iosys-map.h + :internal: + Public Functions Provided ========================= diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index 2cd7db82d9fe..55006678394a 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -128,15 +128,6 @@ Kernel Functions and Structures Reference .. kernel-doc:: include/linux/dma-buf.h :internal: -Buffer Mapping Helpers -~~~~~~~~~~~~~~~~~~~~~~ - -.. kernel-doc:: include/linux/dma-buf-map.h - :doc: overview - -.. kernel-doc:: include/linux/dma-buf-map.h - :internal: - Reservation Objects ------------------- diff --git a/Documentation/driver-api/driver-model/devres.rst b/Documentation/driver-api/driver-model/devres.rst index 148e19381b79..5018403fe82f 100644 --- a/Documentation/driver-api/driver-model/devres.rst +++ b/Documentation/driver-api/driver-model/devres.rst @@ -368,6 +368,7 @@ MUX devm_mux_chip_alloc() devm_mux_chip_register() devm_mux_control_get() + devm_mux_state_get() NET devm_alloc_etherdev() diff --git a/Documentation/driver-api/gpio/board.rst b/Documentation/driver-api/gpio/board.rst index 191fa867826a..4e3adf31c8d1 100644 --- a/Documentation/driver-api/gpio/board.rst +++ b/Documentation/driver-api/gpio/board.rst @@ -71,14 +71,14 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:: Device (FOO) { Name (_CRS, ResourceTemplate () { - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {15} // red - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {16} // green - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {17} // blue - GpioIo (Exclusive, ..., IoRestrictionOutputOnly, - "\\_SB.GPI0") {1} // power + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 15 } // red + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 16 } // green + GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 17 } // blue + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly, + "\\_SB.GPI0", 0, ResourceConsumer) { 1 } // power }) Name (_DSD, Package () { @@ -92,10 +92,7 @@ with the help of _DSD (Device Specific Data), introduced in ACPI 5.1:: ^FOO, 2, 0, 1, } }, - Package () { - "power-gpios", - Package () {^FOO, 3, 0, 0}, - }, + Package () { "power-gpios", Package () { ^FOO, 3, 0, 0 } }, } }) } diff --git a/Documentation/driver-api/index.rst b/Documentation/driver-api/index.rst index c57c609ad2eb..a7b0223e2886 100644 --- a/Documentation/driver-api/index.rst +++ b/Documentation/driver-api/index.rst @@ -103,6 +103,7 @@ available subsections can be seen below. sync_file vfio-mediated-device vfio + vfio-pci-device-specific-driver-acceptance xilinx/index xillybus zorro diff --git a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst index f0961672e6a3..4e87bdbc7ae4 100644 --- a/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst +++ b/Documentation/driver-api/media/drivers/davinci-vpbe-devel.rst @@ -7,22 +7,22 @@ File partitioning ----------------- V4L2 display device driver - drivers/media/platform/davinci/vpbe_display.c - drivers/media/platform/davinci/vpbe_display.h + drivers/media/platform/ti/davinci/vpbe_display.c + drivers/media/platform/ti/davinci/vpbe_display.h VPBE display controller - drivers/media/platform/davinci/vpbe.c - drivers/media/platform/davinci/vpbe.h + drivers/media/platform/ti/davinci/vpbe.c + drivers/media/platform/ti/davinci/vpbe.h VPBE venc sub device driver - drivers/media/platform/davinci/vpbe_venc.c - drivers/media/platform/davinci/vpbe_venc.h - drivers/media/platform/davinci/vpbe_venc_regs.h + drivers/media/platform/ti/davinci/vpbe_venc.c + drivers/media/platform/ti/davinci/vpbe_venc.h + drivers/media/platform/ti/davinci/vpbe_venc_regs.h VPBE osd driver - drivers/media/platform/davinci/vpbe_osd.c - drivers/media/platform/davinci/vpbe_osd.h - drivers/media/platform/davinci/vpbe_osd_regs.h + drivers/media/platform/ti/davinci/vpbe_osd.c + drivers/media/platform/ti/davinci/vpbe_osd.h + drivers/media/platform/ti/davinci/vpbe_osd_regs.h To be done ---------- diff --git a/Documentation/driver-api/media/drivers/fimc-devel.rst b/Documentation/driver-api/media/drivers/fimc-devel.rst index 956e3a9901f8..4c6b7c8be19f 100644 --- a/Documentation/driver-api/media/drivers/fimc-devel.rst +++ b/Documentation/driver-api/media/drivers/fimc-devel.rst @@ -12,22 +12,22 @@ Files partitioning - media device driver - drivers/media/platform/exynos4-is/media-dev.[ch] + drivers/media/platform/samsung/exynos4-is/media-dev.[ch] - camera capture video device driver - drivers/media/platform/exynos4-is/fimc-capture.c + drivers/media/platform/samsung/exynos4-is/fimc-capture.c - MIPI-CSI2 receiver subdev - drivers/media/platform/exynos4-is/mipi-csis.[ch] + drivers/media/platform/samsung/exynos4-is/mipi-csis.[ch] - video post-processor (mem-to-mem) - drivers/media/platform/exynos4-is/fimc-core.c + drivers/media/platform/samsung/exynos4-is/fimc-core.c - common files - drivers/media/platform/exynos4-is/fimc-core.h - drivers/media/platform/exynos4-is/fimc-reg.h - drivers/media/platform/exynos4-is/regs-fimc.h + drivers/media/platform/samsung/exynos4-is/fimc-core.h + drivers/media/platform/samsung/exynos4-is/fimc-reg.h + drivers/media/platform/samsung/exynos4-is/regs-fimc.h diff --git a/Documentation/driver-api/media/v4l2-event.rst b/Documentation/driver-api/media/v4l2-event.rst index 5b8254eba7da..52d4fbc5d819 100644 --- a/Documentation/driver-api/media/v4l2-event.rst +++ b/Documentation/driver-api/media/v4l2-event.rst @@ -167,7 +167,7 @@ The first event type in the class is reserved for future use, so the first available event type is 'class base + 1'. An example on how the V4L2 events may be used can be found in the OMAP -3 ISP driver (``drivers/media/platform/omap3isp``). +3 ISP driver (``drivers/media/platform/ti/omap3isp``). A subdev can directly send an event to the :c:type:`v4l2_device` notify function with ``V4L2_DEVICE_NOTIFY_EVENT``. This allows the bridge to map diff --git a/Documentation/driver-api/mtd/index.rst b/Documentation/driver-api/mtd/index.rst index 436ba5a851d7..6a4278f409d7 100644 --- a/Documentation/driver-api/mtd/index.rst +++ b/Documentation/driver-api/mtd/index.rst @@ -7,6 +7,6 @@ Memory Technology Device (MTD) .. toctree:: :maxdepth: 1 - intel-spi + spi-intel nand_ecc spi-nor diff --git a/Documentation/driver-api/mtd/intel-spi.rst b/Documentation/driver-api/mtd/spi-intel.rst index 0465f6879262..df854f20ead1 100644 --- a/Documentation/driver-api/mtd/intel-spi.rst +++ b/Documentation/driver-api/mtd/spi-intel.rst @@ -1,5 +1,5 @@ ============================== -Upgrading BIOS using intel-spi +Upgrading BIOS using spi-intel ============================== Many Intel CPUs like Baytrail and Braswell include SPI serial flash host @@ -11,12 +11,12 @@ avoid accidental (or on purpose) overwrite of the content. Not all manufacturers protect the SPI serial flash, mainly because it allows upgrading the BIOS image directly from an OS. -The intel-spi driver makes it possible to read and write the SPI serial +The spi-intel driver makes it possible to read and write the SPI serial flash, if certain protection bits are not set and locked. If it finds any of them set, the whole MTD device is made read-only to prevent partial overwrites. By default the driver exposes SPI serial flash contents as read-only but it can be changed from kernel command line, -passing "intel-spi.writeable=1". +passing "spi_intel.writeable=1". Please keep in mind that overwriting the BIOS image on SPI serial flash might render the machine unbootable and requires special equipment like @@ -32,7 +32,7 @@ Linux. serial flash. Distros like Debian and Fedora have this prepackaged with name "mtd-utils". - 3) Add "intel-spi.writeable=1" to the kernel command line and reboot + 3) Add "spi_intel.writeable=1" to the kernel command line and reboot the board (you can also reload the driver passing "writeable=1" as module parameter to modprobe). diff --git a/Documentation/driver-api/nvdimm/nvdimm.rst b/Documentation/driver-api/nvdimm/nvdimm.rst index 1d8302b89bd4..be8587a558e1 100644 --- a/Documentation/driver-api/nvdimm/nvdimm.rst +++ b/Documentation/driver-api/nvdimm/nvdimm.rst @@ -14,10 +14,8 @@ Version 13 Overview Supporting Documents Git Trees - LIBNVDIMM PMEM and BLK - Why BLK? - PMEM vs BLK - BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX + LIBNVDIMM PMEM + PMEM-REGIONs, Atomic Sectors, and DAX Example NVDIMM Platform LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API LIBNDCTL: Context @@ -53,19 +51,12 @@ PMEM: block device composed of PMEM is capable of DAX. A PMEM address range may span an interleave of several DIMMs. -BLK: - A set of one or more programmable memory mapped apertures provided - by a DIMM to access its media. This indirection precludes the - performance benefit of interleaving, but enables DIMM-bounded failure - modes. - DPA: DIMM Physical Address, is a DIMM-relative offset. With one DIMM in the system there would be a 1:1 system-physical-address:DPA association. Once more DIMMs are added a memory controller interleave must be decoded to determine the DPA associated with a given - system-physical-address. BLK capacity always has a 1:1 relationship - with a single-DIMM's DPA range. + system-physical-address. DAX: File system extensions to bypass the page cache and block layer to @@ -84,30 +75,30 @@ BTT: Block Translation Table: Persistent memory is byte addressable. Existing software may have an expectation that the power-fail-atomicity of writes is at least one sector, 512 bytes. The BTT is an indirection - table with atomic update semantics to front a PMEM/BLK block device + table with atomic update semantics to front a PMEM block device driver and present arbitrary atomic sector sizes. LABEL: Metadata stored on a DIMM device that partitions and identifies - (persistently names) storage between PMEM and BLK. It also partitions - BLK storage to host BTTs with different parameters per BLK-partition. - Note that traditional partition tables, GPT/MBR, are layered on top of a - BLK or PMEM device. + (persistently names) capacity allocated to different PMEM namespaces. It + also indicates whether an address abstraction like a BTT is applied to + the namepsace. Note that traditional partition tables, GPT/MBR, are + layered on top of a PMEM namespace, or an address abstraction like BTT + if present, but partition support is deprecated going forward. Overview ======== -The LIBNVDIMM subsystem provides support for three types of NVDIMMs, namely, -PMEM, BLK, and NVDIMM devices that can simultaneously support both PMEM -and BLK mode access. These three modes of operation are described by -the "NVDIMM Firmware Interface Table" (NFIT) in ACPI 6. While the LIBNVDIMM -implementation is generic and supports pre-NFIT platforms, it was guided -by the superset of capabilities need to support this ACPI 6 definition -for NVDIMM resources. The bulk of the kernel implementation is in place -to handle the case where DPA accessible via PMEM is aliased with DPA -accessible via BLK. When that occurs a LABEL is needed to reserve DPA -for exclusive access via one mode a time. +The LIBNVDIMM subsystem provides support for PMEM described by platform +firmware or a device driver. On ACPI based systems the platform firmware +conveys persistent memory resource via the ACPI NFIT "NVDIMM Firmware +Interface Table" in ACPI 6. While the LIBNVDIMM subsystem implementation +is generic and supports pre-NFIT platforms, it was guided by the +superset of capabilities need to support this ACPI 6 definition for +NVDIMM resources. The original implementation supported the +block-window-aperture capability described in the NFIT, but that support +has since been abandoned and never shipped in a product. Supporting Documents -------------------- @@ -125,107 +116,38 @@ Git Trees --------- LIBNVDIMM: - https://git.kernel.org/cgit/linux/kernel/git/djbw/nvdimm.git + https://git.kernel.org/cgit/linux/kernel/git/nvdimm/nvdimm.git LIBNDCTL: https://github.com/pmem/ndctl.git -PMEM: - https://github.com/01org/prd -LIBNVDIMM PMEM and BLK -====================== +LIBNVDIMM PMEM +============== Prior to the arrival of the NFIT, non-volatile memory was described to a system in various ad-hoc ways. Usually only the bare minimum was provided, namely, a single system-physical-address range where writes are expected to be durable after a system power loss. Now, the NFIT specification standardizes not only the description of PMEM, but also -BLK and platform message-passing entry points for control and -configuration. - -For each NVDIMM access method (PMEM, BLK), LIBNVDIMM provides a block -device driver: - - 1. PMEM (nd_pmem.ko): Drives a system-physical-address range. This - range is contiguous in system memory and may be interleaved (hardware - memory controller striped) across multiple DIMMs. When interleaved the - platform may optionally provide details of which DIMMs are participating - in the interleave. - - Note that while LIBNVDIMM describes system-physical-address ranges that may - alias with BLK access as ND_NAMESPACE_PMEM ranges and those without - alias as ND_NAMESPACE_IO ranges, to the nd_pmem driver there is no - distinction. The different device-types are an implementation detail - that userspace can exploit to implement policies like "only interface - with address ranges from certain DIMMs". It is worth noting that when - aliasing is present and a DIMM lacks a label, then no block device can - be created by default as userspace needs to do at least one allocation - of DPA to the PMEM range. In contrast ND_NAMESPACE_IO ranges, once - registered, can be immediately attached to nd_pmem. - - 2. BLK (nd_blk.ko): This driver performs I/O using a set of platform - defined apertures. A set of apertures will access just one DIMM. - Multiple windows (apertures) allow multiple concurrent accesses, much like - tagged-command-queuing, and would likely be used by different threads or - different CPUs. - - The NFIT specification defines a standard format for a BLK-aperture, but - the spec also allows for vendor specific layouts, and non-NFIT BLK - implementations may have other designs for BLK I/O. For this reason - "nd_blk" calls back into platform-specific code to perform the I/O. - - One such implementation is defined in the "Driver Writer's Guide" and "DSM - Interface Example". - - -Why BLK? -======== +platform message-passing entry points for control and configuration. + +PMEM (nd_pmem.ko): Drives a system-physical-address range. This range is +contiguous in system memory and may be interleaved (hardware memory controller +striped) across multiple DIMMs. When interleaved the platform may optionally +provide details of which DIMMs are participating in the interleave. + +It is worth noting that when the labeling capability is detected (a EFI +namespace label index block is found), then no block device is created +by default as userspace needs to do at least one allocation of DPA to +the PMEM range. In contrast ND_NAMESPACE_IO ranges, once registered, +can be immediately attached to nd_pmem. This latter mode is called +label-less or "legacy". + +PMEM-REGIONs, Atomic Sectors, and DAX +------------------------------------- -While PMEM provides direct byte-addressable CPU-load/store access to -NVDIMM storage, it does not provide the best system RAS (recovery, -availability, and serviceability) model. An access to a corrupted -system-physical-address address causes a CPU exception while an access -to a corrupted address through an BLK-aperture causes that block window -to raise an error status in a register. The latter is more aligned with -the standard error model that host-bus-adapter attached disks present. - -Also, if an administrator ever wants to replace a memory it is easier to -service a system at DIMM module boundaries. Compare this to PMEM where -data could be interleaved in an opaque hardware specific manner across -several DIMMs. - -PMEM vs BLK ------------ - -BLK-apertures solve these RAS problems, but their presence is also the -major contributing factor to the complexity of the ND subsystem. They -complicate the implementation because PMEM and BLK alias in DPA space. -Any given DIMM's DPA-range may contribute to one or more -system-physical-address sets of interleaved DIMMs, *and* may also be -accessed in its entirety through its BLK-aperture. Accessing a DPA -through a system-physical-address while simultaneously accessing the -same DPA through a BLK-aperture has undefined results. For this reason, -DIMMs with this dual interface configuration include a DSM function to -store/retrieve a LABEL. The LABEL effectively partitions the DPA-space -into exclusive system-physical-address and BLK-aperture accessible -regions. For simplicity a DIMM is allowed a PMEM "region" per each -interleave set in which it is a member. The remaining DPA space can be -carved into an arbitrary number of BLK devices with discontiguous -extents. - -BLK-REGIONs, PMEM-REGIONs, Atomic Sectors, and DAX -^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ - -One of the few -reasons to allow multiple BLK namespaces per REGION is so that each -BLK-namespace can be configured with a BTT with unique atomic sector -sizes. While a PMEM device can host a BTT the LABEL specification does -not provide for a sector size to be specified for a PMEM namespace. - -This is due to the expectation that the primary usage model for PMEM is -via DAX, and the BTT is incompatible with DAX. However, for the cases -where an application or filesystem still needs atomic sector update -guarantees it can register a BTT on a PMEM device or partition. See +For the cases where an application or filesystem still needs atomic sector +update guarantees it can register a BTT on a PMEM device or partition. See LIBNVDIMM/NDCTL: Block Translation Table "btt" @@ -236,51 +158,40 @@ For the remainder of this document the following diagram will be referenced for any example sysfs layouts:: - (a) (b) DIMM BLK-REGION + (a) (b) DIMM +-------------------+--------+--------+--------+ - +------+ | pm0.0 | blk2.0 | pm1.0 | blk2.1 | 0 region2 + +------+ | pm0.0 | free | pm1.0 | free | 0 | imc0 +--+- - - region0- - - +--------+ +--------+ - +--+---+ | pm0.0 | blk3.0 | pm1.0 | blk3.1 | 1 region3 + +--+---+ | pm0.0 | free | pm1.0 | free | 1 | +-------------------+--------v v--------+ +--+---+ | | | cpu0 | region1 +--+---+ | | | +----------------------------^ ^--------+ - +--+---+ | blk4.0 | pm1.0 | blk4.0 | 2 region4 + +--+---+ | free | pm1.0 | free | 2 | imc1 +--+----------------------------| +--------+ - +------+ | blk5.0 | pm1.0 | blk5.0 | 3 region5 + +------+ | free | pm1.0 | free | 3 +----------------------------+--------+--------+ In this platform we have four DIMMs and two memory controllers in one -socket. Each unique interface (BLK or PMEM) to DPA space is identified -by a region device with a dynamically assigned id (REGION0 - REGION5). +socket. Each PMEM interleave set is identified by a region device with +a dynamically assigned id. 1. The first portion of DIMM0 and DIMM1 are interleaved as REGION0. A single PMEM namespace is created in the REGION0-SPA-range that spans most of DIMM0 and DIMM1 with a user-specified name of "pm0.0". Some of that - interleaved system-physical-address range is reclaimed as BLK-aperture - accessed space starting at DPA-offset (a) into each DIMM. In that - reclaimed space we create two BLK-aperture "namespaces" from REGION2 and - REGION3 where "blk2.0" and "blk3.0" are just human readable names that - could be set to any user-desired name in the LABEL. + interleaved system-physical-address range is left free for + another PMEM namespace to be defined. 2. In the last portion of DIMM0 and DIMM1 we have an interleaved system-physical-address range, REGION1, that spans those two DIMMs as well as DIMM2 and DIMM3. Some of REGION1 is allocated to a PMEM namespace - named "pm1.0", the rest is reclaimed in 4 BLK-aperture namespaces (for - each DIMM in the interleave set), "blk2.1", "blk3.1", "blk4.0", and - "blk5.0". - - 3. The portion of DIMM2 and DIMM3 that do not participate in the REGION1 - interleaved system-physical-address range (i.e. the DPA address past - offset (b) are also included in the "blk4.0" and "blk5.0" namespaces. - Note, that this example shows that BLK-aperture namespaces don't need to - be contiguous in DPA-space. + named "pm1.0". This bus is provided by the kernel under the device /sys/devices/platform/nfit_test.0 when the nfit_test.ko module from - tools/testing/nvdimm is loaded. This not only test LIBNVDIMM but the - acpi_nfit.ko driver as well. + tools/testing/nvdimm is loaded. This module is a unit test for + LIBNVDIMM and the acpi_nfit.ko driver. LIBNVDIMM Kernel Device Model and LIBNDCTL Userspace API @@ -469,17 +380,14 @@ identified by an "nfit_handle" a 32-bit value where: LIBNVDIMM/LIBNDCTL: Region -------------------------- -A generic REGION device is registered for each PMEM range or BLK-aperture -set. Per the example there are 6 regions: 2 PMEM and 4 BLK-aperture -sets on the "nfit_test.0" bus. The primary role of regions are to be a -container of "mappings". A mapping is a tuple of <DIMM, -DPA-start-offset, length>. +A generic REGION device is registered for each PMEM interleave-set / +range. Per the example there are 2 PMEM regions on the "nfit_test.0" +bus. The primary role of regions are to be a container of "mappings". A +mapping is a tuple of <DIMM, DPA-start-offset, length>. -LIBNVDIMM provides a built-in driver for these REGION devices. This driver -is responsible for reconciling the aliased DPA mappings across all -regions, parsing the LABEL, if present, and then emitting NAMESPACE -devices with the resolved/exclusive DPA-boundaries for the nd_pmem or -nd_blk device driver to consume. +LIBNVDIMM provides a built-in driver for REGION devices. This driver +is responsible for all parsing LABELs, if present, and then emitting NAMESPACE +devices for the nd_pmem driver to consume. In addition to the generic attributes of "mapping"s, "interleave_ways" and "size" the REGION device also exports some convenience attributes. @@ -493,8 +401,6 @@ LIBNVDIMM: region:: struct nd_region *nvdimm_pmem_region_create(struct nvdimm_bus *nvdimm_bus, struct nd_region_desc *ndr_desc); - struct nd_region *nvdimm_blk_region_create(struct nvdimm_bus *nvdimm_bus, - struct nd_region_desc *ndr_desc); :: @@ -527,8 +433,9 @@ LIBNDCTL: region enumeration example ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Sample region retrieval routines based on NFIT-unique data like -"spa_index" (interleave set id) for PMEM and "nfit_handle" (dimm id) for -BLK:: +"spa_index" (interleave set id). + +:: static struct ndctl_region *get_pmem_region_by_spa_index(struct ndctl_bus *bus, unsigned int spa_index) @@ -544,139 +451,23 @@ BLK:: return NULL; } - static struct ndctl_region *get_blk_region_by_dimm_handle(struct ndctl_bus *bus, - unsigned int handle) - { - struct ndctl_region *region; - - ndctl_region_foreach(bus, region) { - struct ndctl_mapping *map; - - if (ndctl_region_get_type(region) != ND_DEVICE_REGION_BLOCK) - continue; - ndctl_mapping_foreach(region, map) { - struct ndctl_dimm *dimm = ndctl_mapping_get_dimm(map); - - if (ndctl_dimm_get_handle(dimm) == handle) - return region; - } - } - return NULL; - } - - -Why Not Encode the Region Type into the Region Name? ----------------------------------------------------- - -At first glance it seems since NFIT defines just PMEM and BLK interface -types that we should simply name REGION devices with something derived -from those type names. However, the ND subsystem explicitly keeps the -REGION name generic and expects userspace to always consider the -region-attributes for four reasons: - - 1. There are already more than two REGION and "namespace" types. For - PMEM there are two subtypes. As mentioned previously we have PMEM where - the constituent DIMM devices are known and anonymous PMEM. For BLK - regions the NFIT specification already anticipates vendor specific - implementations. The exact distinction of what a region contains is in - the region-attributes not the region-name or the region-devtype. - - 2. A region with zero child-namespaces is a possible configuration. For - example, the NFIT allows for a DCR to be published without a - corresponding BLK-aperture. This equates to a DIMM that can only accept - control/configuration messages, but no i/o through a descendant block - device. Again, this "type" is advertised in the attributes ('mappings' - == 0) and the name does not tell you much. - - 3. What if a third major interface type arises in the future? Outside - of vendor specific implementations, it's not difficult to envision a - third class of interface type beyond BLK and PMEM. With a generic name - for the REGION level of the device-hierarchy old userspace - implementations can still make sense of new kernel advertised - region-types. Userspace can always rely on the generic region - attributes like "mappings", "size", etc and the expected child devices - named "namespace". This generic format of the device-model hierarchy - allows the LIBNVDIMM and LIBNDCTL implementations to be more uniform and - future-proof. - - 4. There are more robust mechanisms for determining the major type of a - region than a device name. See the next section, How Do I Determine the - Major Type of a Region? - -How Do I Determine the Major Type of a Region? ----------------------------------------------- - -Outside of the blanket recommendation of "use libndctl", or simply -looking at the kernel header (/usr/include/linux/ndctl.h) to decode the -"nstype" integer attribute, here are some other options. - -1. module alias lookup -^^^^^^^^^^^^^^^^^^^^^^ - - The whole point of region/namespace device type differentiation is to - decide which block-device driver will attach to a given LIBNVDIMM namespace. - One can simply use the modalias to lookup the resulting module. It's - important to note that this method is robust in the presence of a - vendor-specific driver down the road. If a vendor-specific - implementation wants to supplant the standard nd_blk driver it can with - minimal impact to the rest of LIBNVDIMM. - - In fact, a vendor may also want to have a vendor-specific region-driver - (outside of nd_region). For example, if a vendor defined its own LABEL - format it would need its own region driver to parse that LABEL and emit - the resulting namespaces. The output from module resolution is more - accurate than a region-name or region-devtype. - -2. udev -^^^^^^^ - - The kernel "devtype" is registered in the udev database:: - - # udevadm info --path=/devices/platform/nfit_test.0/ndbus0/region0 - P: /devices/platform/nfit_test.0/ndbus0/region0 - E: DEVPATH=/devices/platform/nfit_test.0/ndbus0/region0 - E: DEVTYPE=nd_pmem - E: MODALIAS=nd:t2 - E: SUBSYSTEM=nd - - # udevadm info --path=/devices/platform/nfit_test.0/ndbus0/region4 - P: /devices/platform/nfit_test.0/ndbus0/region4 - E: DEVPATH=/devices/platform/nfit_test.0/ndbus0/region4 - E: DEVTYPE=nd_blk - E: MODALIAS=nd:t3 - E: SUBSYSTEM=nd - - ...and is available as a region attribute, but keep in mind that the - "devtype" does not indicate sub-type variations and scripts should - really be understanding the other attributes. - -3. type specific attributes -^^^^^^^^^^^^^^^^^^^^^^^^^^^ - - As it currently stands a BLK-aperture region will never have a - "nfit/spa_index" attribute, but neither will a non-NFIT PMEM region. A - BLK region with a "mappings" value of 0 is, as mentioned above, a DIMM - that does not allow I/O. A PMEM region with a "mappings" value of zero - is a simple system-physical-address range. - LIBNVDIMM/LIBNDCTL: Namespace ----------------------------- -A REGION, after resolving DPA aliasing and LABEL specified boundaries, -surfaces one or more "namespace" devices. The arrival of a "namespace" -device currently triggers either the nd_blk or nd_pmem driver to load -and register a disk/block device. +A REGION, after resolving DPA aliasing and LABEL specified boundaries, surfaces +one or more "namespace" devices. The arrival of a "namespace" device currently +triggers the nd_pmem driver to load and register a disk/block device. LIBNVDIMM: namespace ^^^^^^^^^^^^^^^^^^^^ -Here is a sample layout from the three major types of NAMESPACE where -namespace0.0 represents DIMM-info-backed PMEM (note that it has a 'uuid' -attribute), namespace2.0 represents a BLK namespace (note it has a -'sector_size' attribute) that, and namespace6.0 represents an anonymous -PMEM namespace (note that has no 'uuid' attribute due to not support a -LABEL):: +Here is a sample layout from the 2 major types of NAMESPACE where namespace0.0 +represents DIMM-info-backed PMEM (note that it has a 'uuid' attribute), and +namespace1.0 represents an anonymous PMEM namespace (note that has no 'uuid' +attribute due to not support a LABEL) + +:: /sys/devices/platform/nfit_test.0/ndbus0/region0/namespace0.0 |-- alt_name @@ -691,20 +482,7 @@ LABEL):: |-- type |-- uevent `-- uuid - /sys/devices/platform/nfit_test.0/ndbus0/region2/namespace2.0 - |-- alt_name - |-- devtype - |-- dpa_extents - |-- force_raw - |-- modalias - |-- numa_node - |-- sector_size - |-- size - |-- subsystem -> ../../../../../../bus/nd - |-- type - |-- uevent - `-- uuid - /sys/devices/platform/nfit_test.1/ndbus1/region6/namespace6.0 + /sys/devices/platform/nfit_test.1/ndbus1/region1/namespace1.0 |-- block | `-- pmem0 |-- devtype @@ -786,9 +564,9 @@ Why the Term "namespace"? LIBNVDIMM/LIBNDCTL: Block Translation Table "btt" ------------------------------------------------- -A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a stacked -block device driver that fronts either the whole block device or a -partition of a block device emitted by either a PMEM or BLK NAMESPACE. +A BTT (design document: https://pmem.io/2014/09/23/btt.html) is a +personality driver for a namespace that fronts entire namespace as an +'address abstraction'. LIBNVDIMM: btt layout ^^^^^^^^^^^^^^^^^^^^^ @@ -815,7 +593,9 @@ LIBNDCTL: btt creation example Similar to namespaces an idle BTT device is automatically created per region. Each time this "seed" btt device is configured and enabled a new seed is created. Creating a BTT configuration involves two steps of -finding and idle BTT and assigning it to consume a PMEM or BLK namespace:: +finding and idle BTT and assigning it to consume a namespace. + +:: static struct ndctl_btt *get_idle_btt(struct ndctl_region *region) { @@ -863,25 +643,15 @@ For the given example above, here is the view of the objects as seen by the LIBNDCTL API:: +---+ - |CTX| +---------+ +--------------+ +---------------+ - +-+-+ +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | - | | +---------+ +--------------+ +---------------+ - +-------+ | | +---------+ +--------------+ +---------------+ - | DIMM0 <-+ | +-> REGION1 +---> NAMESPACE1.0 +--> PMEM6 "pm1.0" | - +-------+ | | | +---------+ +--------------+ +---------------+ + |CTX| + +-+-+ + | + +-------+ | + | DIMM0 <-+ | +---------+ +--------------+ +---------------+ + +-------+ | | +-> REGION0 +---> NAMESPACE0.0 +--> PMEM8 "pm0.0" | | DIMM1 <-+ +-v--+ | +---------+ +--------------+ +---------------+ - +-------+ +-+BUS0+---> REGION2 +-+-> NAMESPACE2.0 +--> ND6 "blk2.0" | - | DIMM2 <-+ +----+ | +---------+ | +--------------+ +----------------------+ - +-------+ | | +-> NAMESPACE2.1 +--> ND5 "blk2.1" | BTT2 | - | DIMM3 <-+ | +--------------+ +----------------------+ - +-------+ | +---------+ +--------------+ +---------------+ - +-> REGION3 +-+-> NAMESPACE3.0 +--> ND4 "blk3.0" | - | +---------+ | +--------------+ +----------------------+ - | +-> NAMESPACE3.1 +--> ND3 "blk3.1" | BTT1 | - | +--------------+ +----------------------+ - | +---------+ +--------------+ +---------------+ - +-> REGION4 +---> NAMESPACE4.0 +--> ND2 "blk4.0" | - | +---------+ +--------------+ +---------------+ - | +---------+ +--------------+ +----------------------+ - +-> REGION5 +---> NAMESPACE5.0 +--> ND1 "blk5.0" | BTT0 | - +---------+ +--------------+ +---------------+------+ + +-------+ +-+BUS0+-| +---------+ +--------------+ +----------------------+ + | DIMM2 <-+ +----+ +-> REGION1 +---> NAMESPACE1.0 +--> PMEM6 "pm1.0" | BTT1 | + +-------+ | | +---------+ +--------------+ +---------------+------+ + | DIMM3 <-+ + +-------+ diff --git a/Documentation/driver-api/nvmem.rst b/Documentation/driver-api/nvmem.rst index 287e86819640..e3366322d46c 100644 --- a/Documentation/driver-api/nvmem.rst +++ b/Documentation/driver-api/nvmem.rst @@ -26,9 +26,7 @@ was a rather big abstraction leak. This framework aims at solve these problems. It also introduces DT representation for consumer devices to go get the data they require (MAC -Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. This -framework is based on regmap, so that most of the abstraction available in -regmap can be reused, across multiple types of buses. +Addresses, SoC/Revision ID, part numbers, and so on) from the NVMEMs. NVMEM Providers +++++++++++++++ @@ -45,23 +43,21 @@ nvmem_device pointer. nvmem_unregister(nvmem) is used to unregister a previously registered provider. -For example, a simple qfprom case:: +For example, a simple nvram case:: - static struct nvmem_config econfig = { - .name = "qfprom", - .owner = THIS_MODULE, - }; - - static int qfprom_probe(struct platform_device *pdev) + static int brcm_nvram_probe(struct platform_device *pdev) { + struct nvmem_config config = { + .name = "brcm-nvram", + .reg_read = brcm_nvram_read, + }; ... - econfig.dev = &pdev->dev; - nvmem = nvmem_register(&econfig); - ... - } + config.dev = &pdev->dev; + config.priv = priv; + config.size = resource_size(res); -It is mandatory that the NVMEM provider has a regmap associated with its -struct device. Failure to do would return error code from nvmem_register(). + devm_nvmem_register(&config); + } Users of board files can define and register nvmem cells using the nvmem_cell_table struct:: diff --git a/Documentation/driver-api/serial/driver.rst b/Documentation/driver-api/serial/driver.rst index 31bd4e16fb1f..06ec04ba086f 100644 --- a/Documentation/driver-api/serial/driver.rst +++ b/Documentation/driver-api/serial/driver.rst @@ -311,7 +311,7 @@ hardware. This call must not sleep set_ldisc(port,termios) - Notifier for discipline change. See Documentation/driver-api/serial/tty.rst. + Notifier for discipline change. See Documentation/tty/tty_ldisc.rst. Locking: caller holds tty_port->mutex diff --git a/Documentation/driver-api/thermal/index.rst b/Documentation/driver-api/thermal/index.rst index 4cb0b9b6bfb8..030306ffa408 100644 --- a/Documentation/driver-api/thermal/index.rst +++ b/Documentation/driver-api/thermal/index.rst @@ -17,3 +17,4 @@ Thermal intel_powerclamp nouveau_thermal x86_pkg_temperature_thermal + intel_dptf diff --git a/Documentation/driver-api/thermal/intel_dptf.rst b/Documentation/driver-api/thermal/intel_dptf.rst new file mode 100644 index 000000000000..96668dca753a --- /dev/null +++ b/Documentation/driver-api/thermal/intel_dptf.rst @@ -0,0 +1,272 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=============================================================== +Intel(R) Dynamic Platform and Thermal Framework Sysfs Interface +=============================================================== + +:Copyright: |copy| 2022 Intel Corporation + +:Author: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com> + +Introduction +------------ + +Intel(R) Dynamic Platform and Thermal Framework (DPTF) is a platform +level hardware/software solution for power and thermal management. + +As a container for multiple power/thermal technologies, DPTF provides +a coordinated approach for different policies to effect the hardware +state of a system. + +Since it is a platform level framework, this has several components. +Some parts of the technology is implemented in the firmware and uses +ACPI and PCI devices to expose various features for monitoring and +control. Linux has a set of kernel drivers exposing hardware interface +to user space. This allows user space thermal solutions like +"Linux Thermal Daemon" to read platform specific thermal and power +tables to deliver adequate performance while keeping the system under +thermal limits. + +DPTF ACPI Drivers interface +---------------------------- + +:file:`/sys/bus/platform/devices/<N>/uuids`, where <N> +=INT3400|INTC1040|INTC1041|INTC10A0 + +``available_uuids`` (RO) + A set of UUIDs strings presenting available policies + which should be notified to the firmware when the + user space can support those policies. + + UUID strings: + + "42A441D6-AE6A-462b-A84B-4A8CE79027D3" : Passive 1 + + "3A95C389-E4B8-4629-A526-C52C88626BAE" : Active + + "97C68AE7-15FA-499c-B8C9-5DA81D606E0A" : Critical + + "63BE270F-1C11-48FD-A6F7-3AF253FF3E2D" : Adaptive performance + + "5349962F-71E6-431D-9AE8-0A635B710AEE" : Emergency call + + "9E04115A-AE87-4D1C-9500-0F3E340BFE75" : Passive 2 + + "F5A35014-C209-46A4-993A-EB56DE7530A1" : Power Boss + + "6ED722A7-9240-48A5-B479-31EEF723D7CF" : Virtual Sensor + + "16CAF1B7-DD38-40ED-B1C1-1B8A1913D531" : Cooling mode + + "BE84BABF-C4D4-403D-B495-3128FD44dAC1" : HDC + +``current_uuid`` (RW) + User space can write strings from available UUIDs, one at a + time. + +:file:`/sys/bus/platform/devices/<N>/`, where <N> +=INT3400|INTC1040|INTC1041|INTC10A0 + +``imok`` (WO) + User space daemon write 1 to respond to firmware event + for sending keep alive notification. User space receives + THERMAL_EVENT_KEEP_ALIVE kobject uevent notification when + firmware calls for user space to respond with imok ACPI + method. + +``odvp*`` (RO) + Firmware thermal status variable values. Thermal tables + calls for different processing based on these variable + values. + +``data_vault`` (RO) + Binary thermal table. Refer to + https:/github.com/intel/thermal_daemon for decoding + thermal table. + + +ACPI Thermal Relationship table interface +------------------------------------------ + +:file:`/dev/acpi_thermal_rel` + + This device provides IOCTL interface to read standard ACPI + thermal relationship tables via ACPI methods _TRT and _ART. + These IOCTLs are defined in + drivers/thermal/intel/int340x_thermal/acpi_thermal_rel.h + + IOCTLs: + + ACPI_THERMAL_GET_TRT_LEN: Get length of TRT table + + ACPI_THERMAL_GET_ART_LEN: Get length of ART table + + ACPI_THERMAL_GET_TRT_COUNT: Number of records in TRT table + + ACPI_THERMAL_GET_ART_COUNT: Number of records in ART table + + ACPI_THERMAL_GET_TRT: Read binary TRT table, length to read is + provided via argument to ioctl(). + + ACPI_THERMAL_GET_ART: Read binary ART table, length to read is + provided via argument to ioctl(). + +DPTF ACPI Sensor drivers +------------------------- + +DPTF Sensor drivers are presented as standard thermal sysfs thermal_zone. + + +DPTF ACPI Cooling drivers +-------------------------- + +DPTF cooling drivers are presented as standard thermal sysfs cooling_device. + + +DPTF Processor thermal PCI Driver interface +-------------------------------------------- + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/power_limits/` + +Refer to Documentation/power/powercap/powercap.rst for powercap +ABI. + +``power_limit_0_max_uw`` (RO) + Maximum powercap sysfs constraint_0_power_limit_uw for Intel RAPL + +``power_limit_0_step_uw`` (RO) + Power limit increment/decrements for Intel RAPL constraint 0 power limit + +``power_limit_0_min_uw`` (RO) + Minimum powercap sysfs constraint_0_power_limit_uw for Intel RAPL + +``power_limit_0_tmin_us`` (RO) + Minimum powercap sysfs constraint_0_time_window_us for Intel RAPL + +``power_limit_0_tmax_us`` (RO) + Maximum powercap sysfs constraint_0_time_window_us for Intel RAPL + +``power_limit_1_max_uw`` (RO) + Maximum powercap sysfs constraint_1_power_limit_uw for Intel RAPL + +``power_limit_1_step_uw`` (RO) + Power limit increment/decrements for Intel RAPL constraint 1 power limit + +``power_limit_1_min_uw`` (RO) + Minimum powercap sysfs constraint_1_power_limit_uw for Intel RAPL + +``power_limit_1_tmin_us`` (RO) + Minimum powercap sysfs constraint_1_time_window_us for Intel RAPL + +``power_limit_1_tmax_us`` (RO) + Maximum powercap sysfs constraint_1_time_window_us for Intel RAPL + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/` + +``tcc_offset_degree_celsius`` (RW) + TCC offset from the critical temperature where hardware will throttle + CPU. + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/workload_request` + +``workload_available_types`` (RO) + Available workload types. User space can specify one of the workload type + it is currently executing via workload_type. For example: idle, bursty, + sustained etc. + +``workload_type`` (RW) + User space can specify any one of the available workload type using + this interface. + +DPTF Processor thermal RFIM interface +-------------------------------------------- + +RFIM interface allows adjustment of FIVR (Fully Integrated Voltage Regulator) +and DDR (Double Data Rate)frequencies to avoid RF interference with WiFi and 5G. + +Switching voltage regulators (VR) generate radiated EMI or RFI at the +fundamental frequency and its harmonics. Some harmonics may interfere +with very sensitive wireless receivers such as Wi-Fi and cellular that +are integrated into host systems like notebook PCs. One of mitigation +methods is requesting SOC integrated VR (IVR) switching frequency to a +small % and shift away the switching noise harmonic interference from +radio channels. OEM or ODMs can use the driver to control SOC IVR +operation within the range where it does not impact IVR performance. + +DRAM devices of DDR IO interface and their power plane can generate EMI +at the data rates. Similar to IVR control mechanism, Intel offers a +mechanism by which DDR data rates can be changed if several conditions +are met: there is strong RFI interference because of DDR; CPU power +management has no other restriction in changing DDR data rates; +PC ODMs enable this feature (real time DDR RFI Mitigation referred to as +DDR-RFIM) for Wi-Fi from BIOS. + + +FIVR attributes + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/fivr/` + +``vco_ref_code_lo`` (RW) + The VCO reference code is an 11-bit field and controls the FIVR + switching frequency. This is the 3-bit LSB field. + +``vco_ref_code_hi`` (RW) + The VCO reference code is an 11-bit field and controls the FIVR + switching frequency. This is the 8-bit MSB field. + +``spread_spectrum_pct`` (RW) + Set the FIVR spread spectrum clocking percentage + +``spread_spectrum_clk_enable`` (RW) + Enable/disable of the FIVR spread spectrum clocking feature + +``rfi_vco_ref_code`` (RW) + This field is a read only status register which reflects the + current FIVR switching frequency + +``fivr_fffc_rev`` (RW) + This field indicated the revision of the FIVR HW. + + +DVFS attributes + +:file:`/sys/bus/pci/devices/0000\:00\:04.0/dvfs/` + +``rfi_restriction_run_busy`` (RW) + Request the restriction of specific DDR data rate and set this + value 1. Self reset to 0 after operation. + +``rfi_restriction_err_code`` (RW) + 0 :Request is accepted, 1:Feature disabled, + 2: the request restricts more points than it is allowed + +``rfi_restriction_data_rate_Delta`` (RW) + Restricted DDR data rate for RFI protection: Lower Limit + +``rfi_restriction_data_rate_Base`` (RW) + Restricted DDR data rate for RFI protection: Upper Limit + +``ddr_data_rate_point_0`` (RO) + DDR data rate selection 1st point + +``ddr_data_rate_point_1`` (RO) + DDR data rate selection 2nd point + +``ddr_data_rate_point_2`` (RO) + DDR data rate selection 3rd point + +``ddr_data_rate_point_3`` (RO) + DDR data rate selection 4th point + +``rfi_disable (RW)`` + Disable DDR rate change feature + +DPTF Power supply and Battery Interface +---------------------------------------- + +Refer to Documentation/ABI/testing/sysfs-platform-dptf + +DPTF Fan Control +---------------------------------------- + +Refer to Documentation/admin-guide/acpi/fan_performance_states.rst diff --git a/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst b/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst new file mode 100644 index 000000000000..b7b99b876b50 --- /dev/null +++ b/Documentation/driver-api/vfio-pci-device-specific-driver-acceptance.rst @@ -0,0 +1,35 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Acceptance criteria for vfio-pci device specific driver variants +================================================================ + +Overview +-------- +The vfio-pci driver exists as a device agnostic driver using the +system IOMMU and relying on the robustness of platform fault +handling to provide isolated device access to userspace. While the +vfio-pci driver does include some device specific support, further +extensions for yet more advanced device specific features are not +sustainable. The vfio-pci driver has therefore split out +vfio-pci-core as a library that may be reused to implement features +requiring device specific knowledge, ex. saving and loading device +state for the purposes of supporting migration. + +In support of such features, it's expected that some device specific +variants may interact with parent devices (ex. SR-IOV PF in support of +a user assigned VF) or other extensions that may not be otherwise +accessible via the vfio-pci base driver. Authors of such drivers +should be diligent not to create exploitable interfaces via these +interactions or allow unchecked userspace data to have an effect +beyond the scope of the assigned device. + +New driver submissions are therefore requested to have approval via +sign-off/ack/review/etc for any interactions with parent drivers. +Additionally, drivers should make an attempt to provide sufficient +documentation for reviewers to understand the device specific +extensions, for example in the case of migration data, how is the +device state composed and consumed, which portions are not otherwise +available to the user via vfio-pci, what safeguards exist to validate +the data, etc. To that extent, authors should additionally expect to +require reviews from at least one of the listed reviewers, in addition +to the overall vfio maintainer. diff --git a/Documentation/features/core/cBPF-JIT/arch-support.txt b/Documentation/features/core/cBPF-JIT/arch-support.txt index e59b5215402d..77bd6974dd6d 100644 --- a/Documentation/features/core/cBPF-JIT/arch-support.txt +++ b/Documentation/features/core/cBPF-JIT/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/core/eBPF-JIT/arch-support.txt b/Documentation/features/core/eBPF-JIT/arch-support.txt index dcbd8679f514..d5ab547b2be6 100644 --- a/Documentation/features/core/eBPF-JIT/arch-support.txt +++ b/Documentation/features/core/eBPF-JIT/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/core/generic-idle-thread/arch-support.txt b/Documentation/features/core/generic-idle-thread/arch-support.txt index 4efcba7b5239..ddb3762ca7f5 100644 --- a/Documentation/features/core/generic-idle-thread/arch-support.txt +++ b/Documentation/features/core/generic-idle-thread/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | ok | diff --git a/Documentation/features/core/jump-labels/arch-support.txt b/Documentation/features/core/jump-labels/arch-support.txt index 0c801d1bd2da..d5380ef68713 100644 --- a/Documentation/features/core/jump-labels/arch-support.txt +++ b/Documentation/features/core/jump-labels/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/core/thread-info-in-task/arch-support.txt b/Documentation/features/core/thread-info-in-task/arch-support.txt index bc74d8beea72..0654ba3a42ff 100644 --- a/Documentation/features/core/thread-info-in-task/arch-support.txt +++ b/Documentation/features/core/thread-info-in-task/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/core/tracehook/arch-support.txt b/Documentation/features/core/tracehook/arch-support.txt index af34308fce7f..8e95dc0c7b90 100644 --- a/Documentation/features/core/tracehook/arch-support.txt +++ b/Documentation/features/core/tracehook/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | ok | diff --git a/Documentation/features/debug/KASAN/arch-support.txt b/Documentation/features/debug/KASAN/arch-support.txt index c244ac7eee26..407ca1d91242 100644 --- a/Documentation/features/debug/KASAN/arch-support.txt +++ b/Documentation/features/debug/KASAN/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt index fa83403b4aec..83eafe1a7f68 100644 --- a/Documentation/features/debug/debug-vm-pgtable/arch-support.txt +++ b/Documentation/features/debug/debug-vm-pgtable/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/gcov-profile-all/arch-support.txt b/Documentation/features/debug/gcov-profile-all/arch-support.txt index b39c1a5de3f3..49e0dda11227 100644 --- a/Documentation/features/debug/gcov-profile-all/arch-support.txt +++ b/Documentation/features/debug/gcov-profile-all/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kcov/arch-support.txt b/Documentation/features/debug/kcov/arch-support.txt index 7e44013cc320..3d34b724ddae 100644 --- a/Documentation/features/debug/kcov/arch-support.txt +++ b/Documentation/features/debug/kcov/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kgdb/arch-support.txt b/Documentation/features/debug/kgdb/arch-support.txt index 2cb0576f9180..7aa073d908c5 100644 --- a/Documentation/features/debug/kgdb/arch-support.txt +++ b/Documentation/features/debug/kgdb/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | ok | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kmemleak/arch-support.txt b/Documentation/features/debug/kmemleak/arch-support.txt index e9ac415f8aec..5c784ff9768a 100644 --- a/Documentation/features/debug/kmemleak/arch-support.txt +++ b/Documentation/features/debug/kmemleak/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt index 96156e8802a7..a1f6e98c6b1f 100644 --- a/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt +++ b/Documentation/features/debug/kprobes-on-ftrace/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kprobes/arch-support.txt b/Documentation/features/debug/kprobes/arch-support.txt index ee95ed61909a..e7e7015175e7 100644 --- a/Documentation/features/debug/kprobes/arch-support.txt +++ b/Documentation/features/debug/kprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/kretprobes/arch-support.txt b/Documentation/features/debug/kretprobes/arch-support.txt index 612cb97d47b8..838eb53a6fa5 100644 --- a/Documentation/features/debug/kretprobes/arch-support.txt +++ b/Documentation/features/debug/kretprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/debug/optprobes/arch-support.txt b/Documentation/features/debug/optprobes/arch-support.txt index d6ff141a6122..6358b00b1723 100644 --- a/Documentation/features/debug/optprobes/arch-support.txt +++ b/Documentation/features/debug/optprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/stackprotector/arch-support.txt b/Documentation/features/debug/stackprotector/arch-support.txt index ad4de22a71ab..f6cdf781305f 100644 --- a/Documentation/features/debug/stackprotector/arch-support.txt +++ b/Documentation/features/debug/stackprotector/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/uprobes/arch-support.txt b/Documentation/features/debug/uprobes/arch-support.txt index 8bd5548a4485..0b871e797d24 100644 --- a/Documentation/features/debug/uprobes/arch-support.txt +++ b/Documentation/features/debug/uprobes/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/debug/user-ret-profiler/arch-support.txt b/Documentation/features/debug/user-ret-profiler/arch-support.txt index 2a3fe812a5fa..a2feda7adff1 100644 --- a/Documentation/features/debug/user-ret-profiler/arch-support.txt +++ b/Documentation/features/debug/user-ret-profiler/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/io/dma-contiguous/arch-support.txt b/Documentation/features/io/dma-contiguous/arch-support.txt index bece89586efa..9b407f26d45e 100644 --- a/Documentation/features/io/dma-contiguous/arch-support.txt +++ b/Documentation/features/io/dma-contiguous/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/locking/cmpxchg-local/arch-support.txt b/Documentation/features/locking/cmpxchg-local/arch-support.txt index 52bdda004f5c..090520b0e02d 100644 --- a/Documentation/features/locking/cmpxchg-local/arch-support.txt +++ b/Documentation/features/locking/cmpxchg-local/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/locking/lockdep/arch-support.txt b/Documentation/features/locking/lockdep/arch-support.txt index a8cd163c8b7e..6d840b103537 100644 --- a/Documentation/features/locking/lockdep/arch-support.txt +++ b/Documentation/features/locking/lockdep/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/locking/queued-rwlocks/arch-support.txt b/Documentation/features/locking/queued-rwlocks/arch-support.txt index 8c85949752b3..de586be05d64 100644 --- a/Documentation/features/locking/queued-rwlocks/arch-support.txt +++ b/Documentation/features/locking/queued-rwlocks/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/locking/queued-spinlocks/arch-support.txt b/Documentation/features/locking/queued-spinlocks/arch-support.txt index 5f4e1b3841af..29d0c8b7b1c5 100644 --- a/Documentation/features/locking/queued-spinlocks/arch-support.txt +++ b/Documentation/features/locking/queued-spinlocks/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/perf/kprobes-event/arch-support.txt b/Documentation/features/perf/kprobes-event/arch-support.txt index 78f3fe080f0e..881a8a50e41e 100644 --- a/Documentation/features/perf/kprobes-event/arch-support.txt +++ b/Documentation/features/perf/kprobes-event/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | ok | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/perf/perf-regs/arch-support.txt b/Documentation/features/perf/perf-regs/arch-support.txt index 5bf3b1854a1f..7639a796a8e1 100644 --- a/Documentation/features/perf/perf-regs/arch-support.txt +++ b/Documentation/features/perf/perf-regs/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/perf/perf-stackdump/arch-support.txt b/Documentation/features/perf/perf-stackdump/arch-support.txt index d88659bb4fc1..df1a4c679a45 100644 --- a/Documentation/features/perf/perf-stackdump/arch-support.txt +++ b/Documentation/features/perf/perf-stackdump/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/sched/membarrier-sync-core/arch-support.txt b/Documentation/features/sched/membarrier-sync-core/arch-support.txt index 883d33b265d6..51b7afc937f1 100644 --- a/Documentation/features/sched/membarrier-sync-core/arch-support.txt +++ b/Documentation/features/sched/membarrier-sync-core/arch-support.txt @@ -40,7 +40,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/sched/numa-balancing/arch-support.txt b/Documentation/features/sched/numa-balancing/arch-support.txt index 9affb7c2c500..d0e308135434 100644 --- a/Documentation/features/sched/numa-balancing/arch-support.txt +++ b/Documentation/features/sched/numa-balancing/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | TODO | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | .. | diff --git a/Documentation/features/seccomp/seccomp-filter/arch-support.txt b/Documentation/features/seccomp/seccomp-filter/arch-support.txt index 26eec58ab819..05613c5ff560 100644 --- a/Documentation/features/seccomp/seccomp-filter/arch-support.txt +++ b/Documentation/features/seccomp/seccomp-filter/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/time/arch-tick-broadcast/arch-support.txt b/Documentation/features/time/arch-tick-broadcast/arch-support.txt index 8dcaab070c7b..b4c96ebab7e3 100644 --- a/Documentation/features/time/arch-tick-broadcast/arch-support.txt +++ b/Documentation/features/time/arch-tick-broadcast/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/time/clockevents/arch-support.txt b/Documentation/features/time/clockevents/arch-support.txt index 9a81cb03b1fd..3f6976052e2a 100644 --- a/Documentation/features/time/clockevents/arch-support.txt +++ b/Documentation/features/time/clockevents/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | ok | | mips: | ok | - | nds32: | ok | | nios2: | ok | | openrisc: | ok | | parisc: | TODO | diff --git a/Documentation/features/time/context-tracking/arch-support.txt b/Documentation/features/time/context-tracking/arch-support.txt index 4ed116c2ec39..bb1c1801553e 100644 --- a/Documentation/features/time/context-tracking/arch-support.txt +++ b/Documentation/features/time/context-tracking/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/time/irq-time-acct/arch-support.txt b/Documentation/features/time/irq-time-acct/arch-support.txt index bc30c15557c7..3cea25b80c8c 100644 --- a/Documentation/features/time/irq-time-acct/arch-support.txt +++ b/Documentation/features/time/irq-time-acct/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | .. | diff --git a/Documentation/features/time/virt-cpuacct/arch-support.txt b/Documentation/features/time/virt-cpuacct/arch-support.txt index 050de43bbbb9..5163a60a1c1e 100644 --- a/Documentation/features/time/virt-cpuacct/arch-support.txt +++ b/Documentation/features/time/virt-cpuacct/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/vm/ELF-ASLR/arch-support.txt b/Documentation/features/vm/ELF-ASLR/arch-support.txt index 2949c99fbb2f..73ec761f1e27 100644 --- a/Documentation/features/vm/ELF-ASLR/arch-support.txt +++ b/Documentation/features/vm/ELF-ASLR/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | ok | diff --git a/Documentation/features/vm/PG_uncached/arch-support.txt b/Documentation/features/vm/PG_uncached/arch-support.txt index 6cde38458596..9066a90b38d9 100644 --- a/Documentation/features/vm/PG_uncached/arch-support.txt +++ b/Documentation/features/vm/PG_uncached/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/THP/arch-support.txt b/Documentation/features/vm/THP/arch-support.txt index 7dbd6967b37e..f717ab792e5a 100644 --- a/Documentation/features/vm/THP/arch-support.txt +++ b/Documentation/features/vm/THP/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | ok | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | diff --git a/Documentation/features/vm/TLB/arch-support.txt b/Documentation/features/vm/TLB/arch-support.txt index e1c3a4c4d107..6fa76a37f299 100644 --- a/Documentation/features/vm/TLB/arch-support.txt +++ b/Documentation/features/vm/TLB/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | .. | | microblaze: | .. | | mips: | TODO | - | nds32: | TODO | | nios2: | .. | | openrisc: | .. | | parisc: | TODO | diff --git a/Documentation/features/vm/huge-vmap/arch-support.txt b/Documentation/features/vm/huge-vmap/arch-support.txt index bc53905a0306..6e1792ee37fe 100644 --- a/Documentation/features/vm/huge-vmap/arch-support.txt +++ b/Documentation/features/vm/huge-vmap/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | TODO | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/ioremap_prot/arch-support.txt b/Documentation/features/vm/ioremap_prot/arch-support.txt index 9a0c8783b84d..a6dcbe5f47b6 100644 --- a/Documentation/features/vm/ioremap_prot/arch-support.txt +++ b/Documentation/features/vm/ioremap_prot/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/features/vm/pte_special/arch-support.txt b/Documentation/features/vm/pte_special/arch-support.txt index 40b969f3a6bb..376477749c42 100644 --- a/Documentation/features/vm/pte_special/arch-support.txt +++ b/Documentation/features/vm/pte_special/arch-support.txt @@ -17,7 +17,6 @@ | m68k: | TODO | | microblaze: | TODO | | mips: | ok | - | nds32: | TODO | | nios2: | TODO | | openrisc: | TODO | | parisc: | TODO | diff --git a/Documentation/filesystems/caching/netfs-api.rst b/Documentation/filesystems/caching/netfs-api.rst index f84e9ffdf0b4..5066113acad5 100644 --- a/Documentation/filesystems/caching/netfs-api.rst +++ b/Documentation/filesystems/caching/netfs-api.rst @@ -345,8 +345,9 @@ The following facilities are provided to manage this: To support this, the following functions are provided:: - int fscache_set_page_dirty(struct page *page, - struct fscache_cookie *cookie); + bool fscache_dirty_folio(struct address_space *mapping, + struct folio *folio, + struct fscache_cookie *cookie); void fscache_unpin_writeback(struct writeback_control *wbc, struct fscache_cookie *cookie); void fscache_clear_inode_writeback(struct fscache_cookie *cookie, @@ -354,7 +355,7 @@ To support this, the following functions are provided:: const void *aux); The *set* function is intended to be called from the filesystem's -``set_page_dirty`` address space operation. If ``I_PINNING_FSCACHE_WB`` is not +``dirty_folio`` address space operation. If ``I_PINNING_FSCACHE_WB`` is not set, it sets that flag and increments the use count on the cookie (the caller must already have called ``fscache_use_cookie()``). diff --git a/Documentation/filesystems/cifs/ksmbd.rst b/Documentation/filesystems/cifs/ksmbd.rst index b0d354fd8066..1af600db2e70 100644 --- a/Documentation/filesystems/cifs/ksmbd.rst +++ b/Documentation/filesystems/cifs/ksmbd.rst @@ -82,10 +82,10 @@ Signing Update Supported. Pre-authentication integrity Supported. SMB3 encryption(CCM, GCM) Supported. (CCM and GCM128 supported, GCM256 in progress) -SMB direct(RDMA) Partially Supported. SMB3 Multi-channel is - required to connect to Windows client. +SMB direct(RDMA) Supported. SMB3 Multi-channel Partially Supported. Planned to implement replay/retry mechanisms for future. +Receive Side Scaling mode Supported. SMB3.1.1 POSIX extension Supported. ACLs Partially Supported. only DACLs available, SACLs (auditing) is planned for the future. For diff --git a/Documentation/filesystems/dax.rst b/Documentation/filesystems/dax.rst index e3b30429d703..c04609d8ee24 100644 --- a/Documentation/filesystems/dax.rst +++ b/Documentation/filesystems/dax.rst @@ -23,11 +23,11 @@ on it as usual. The `DAX` code currently only supports files with a block size equal to your kernel's `PAGE_SIZE`, so you may need to specify a block size when creating the filesystem. -Currently 4 filesystems support `DAX`: ext2, ext4, xfs and virtiofs. +Currently 5 filesystems support `DAX`: ext2, ext4, xfs, virtiofs and erofs. Enabling `DAX` on them is different. -Enabling DAX on ext2 --------------------- +Enabling DAX on ext2 and erofs +------------------------------ When mounting the filesystem, use the ``-o dax`` option on the command line or add 'dax' to the options in ``/etc/fstab``. This works to enable `DAX` on all files diff --git a/Documentation/filesystems/erofs.rst b/Documentation/filesystems/erofs.rst index 7119aa213be7..bef6d3040ce4 100644 --- a/Documentation/filesystems/erofs.rst +++ b/Documentation/filesystems/erofs.rst @@ -40,7 +40,7 @@ Here is the main features of EROFS: Inode metadata size 32 bytes 64 bytes Max file size 4 GB 16 EB (also limited by max. vol size) Max uids/gids 65536 4294967296 - File change time no yes (64 + 32-bit timestamp) + Per-inode timestamp no yes (64 + 32-bit timestamp) Max hardlinks 65536 4294967296 Metadata reserved 4 bytes 14 bytes ===================== ============ ===================================== diff --git a/Documentation/filesystems/ext4/blocks.rst b/Documentation/filesystems/ext4/blocks.rst index bd722ecd92d6..b0f80ea87c90 100644 --- a/Documentation/filesystems/ext4/blocks.rst +++ b/Documentation/filesystems/ext4/blocks.rst @@ -39,7 +39,7 @@ For 32-bit filesystems, limits are as follows: - 4TiB - 8TiB - 16TiB - - 256PiB + - 256TiB * - Blocks Per Block Group - 8,192 - 16,384 diff --git a/Documentation/filesystems/fscrypt.rst b/Documentation/filesystems/fscrypt.rst index 4d5d50dca65c..6ccd5efb25b7 100644 --- a/Documentation/filesystems/fscrypt.rst +++ b/Documentation/filesystems/fscrypt.rst @@ -1047,8 +1047,8 @@ astute users may notice some differences in behavior: may be used to overwrite the source files but isn't guaranteed to be effective on all filesystems and storage devices. -- Direct I/O is not supported on encrypted files. Attempts to use - direct I/O on such files will fall back to buffered I/O. +- Direct I/O is supported on encrypted files only under some + circumstances. For details, see `Direct I/O support`_. - The fallocate operations FALLOC_FL_COLLAPSE_RANGE and FALLOC_FL_INSERT_RANGE are not supported on encrypted files and will @@ -1179,6 +1179,27 @@ Inline encryption doesn't affect the ciphertext or other aspects of the on-disk format, so users may freely switch back and forth between using "inlinecrypt" and not using "inlinecrypt". +Direct I/O support +================== + +For direct I/O on an encrypted file to work, the following conditions +must be met (in addition to the conditions for direct I/O on an +unencrypted file): + +* The file must be using inline encryption. Usually this means that + the filesystem must be mounted with ``-o inlinecrypt`` and inline + encryption hardware must be present. However, a software fallback + is also available. For details, see `Inline encryption support`_. + +* The I/O request must be fully aligned to the filesystem block size. + This means that the file position the I/O is targeting, the lengths + of all I/O segments, and the memory addresses of all I/O buffers + must be multiples of this value. Note that the filesystem block + size may be greater than the logical block size of the block device. + +If either of the above conditions is not met, then direct I/O on the +encrypted file will fall back to buffered I/O. + Implementation details ====================== diff --git a/Documentation/filesystems/fsverity.rst b/Documentation/filesystems/fsverity.rst index 1d831e3cbcb3..8cc536d08f51 100644 --- a/Documentation/filesystems/fsverity.rst +++ b/Documentation/filesystems/fsverity.rst @@ -549,7 +549,7 @@ Pagecache ~~~~~~~~~ For filesystems using Linux's pagecache, the ``->readpage()`` and -``->readpages()`` methods must be modified to verify pages before they +``->readahead()`` methods must be modified to verify pages before they are marked Uptodate. Merely hooking ``->read_iter()`` would be insufficient, since ``->read_iter()`` is not used for memory maps. @@ -611,7 +611,7 @@ workqueue, and then the workqueue work does the decryption or verification. Finally, pages where no decryption or verity error occurred are marked Uptodate, and the pages are unlocked. -Files on ext4 and f2fs may contain holes. Normally, ``->readpages()`` +Files on ext4 and f2fs may contain holes. Normally, ``->readahead()`` simply zeroes holes and sets the corresponding pages Uptodate; no bios are issued. To prevent this case from bypassing fs-verity, these filesystems use fsverity_verify_page() to verify hole pages. @@ -778,7 +778,7 @@ weren't already directly answered in other parts of this document. - To prevent bypassing verification, pages must not be marked Uptodate until they've been verified. Currently, each filesystem is responsible for marking pages Uptodate via - ``->readpages()``. Therefore, currently it's not possible for + ``->readahead()``. Therefore, currently it's not possible for the VFS to do the verification on its own. Changing this would require significant changes to the VFS and all filesystems. diff --git a/Documentation/filesystems/locking.rst b/Documentation/filesystems/locking.rst index 3f9b1497ebb8..c26d854275a0 100644 --- a/Documentation/filesystems/locking.rst +++ b/Documentation/filesystems/locking.rst @@ -239,10 +239,8 @@ prototypes:: int (*writepage)(struct page *page, struct writeback_control *wbc); int (*readpage)(struct file *, struct page *); int (*writepages)(struct address_space *, struct writeback_control *); - int (*set_page_dirty)(struct page *page); + bool (*dirty_folio)(struct address_space *, struct folio *folio); void (*readahead)(struct readahead_control *); - int (*readpages)(struct file *filp, struct address_space *mapping, - struct list_head *pages, unsigned nr_pages); int (*write_begin)(struct file *, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata); @@ -250,21 +248,21 @@ prototypes:: loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); - void (*invalidatepage) (struct page *, unsigned int, unsigned int); + void (*invalidate_folio) (struct folio *, size_t start, size_t len); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); int (*direct_IO)(struct kiocb *, struct iov_iter *iter); bool (*isolate_page) (struct page *, isolate_mode_t); int (*migratepage)(struct address_space *, struct page *, struct page *); void (*putback_page) (struct page *); - int (*launder_page)(struct page *); - int (*is_partially_uptodate)(struct page *, unsigned long, unsigned long); + int (*launder_folio)(struct folio *); + bool (*is_partially_uptodate)(struct folio *, size_t from, size_t count); int (*error_remove_page)(struct address_space *, struct page *); int (*swap_activate)(struct file *); int (*swap_deactivate)(struct file *); locking rules: - All except set_page_dirty and freepage may block + All except dirty_folio and freepage may block ====================== ======================== ========= =============== ops PageLocked(page) i_rwsem invalidate_lock @@ -272,20 +270,19 @@ ops PageLocked(page) i_rwsem invalidate_lock writepage: yes, unlocks (see below) readpage: yes, unlocks shared writepages: -set_page_dirty no +dirty_folio maybe readahead: yes, unlocks shared -readpages: no shared write_begin: locks the page exclusive write_end: yes, unlocks exclusive bmap: -invalidatepage: yes exclusive +invalidate_folio: yes exclusive releasepage: yes freepage: yes direct_IO: isolate_page: yes migratepage: yes (both) putback_page: yes -launder_page: yes +launder_folio: yes is_partially_uptodate: yes error_remove_page: yes swap_activate: no @@ -300,9 +297,6 @@ completion. ->readahead() unlocks the pages that I/O is attempted on like ->readpage(). -->readpages() populates the pagecache with the passed pages and starts -I/O against them. They come unlocked upon I/O completion. - ->writepage() is used for two purposes: for "memory cleansing" and for "sync". These are quite different operations and the behaviour may differ depending upon the mode. @@ -361,22 +355,22 @@ If nr_to_write is NULL, all dirty pages must be written. writepages should _only_ write pages which are present on mapping->io_pages. -->set_page_dirty() is called from various places in the kernel -when the target page is marked as needing writeback. It may be called -under spinlock (it cannot block) and is sometimes called with the page -not locked. +->dirty_folio() is called from various places in the kernel when +the target folio is marked as needing writeback. The folio cannot be +truncated because either the caller holds the folio lock, or the caller +has found the folio while holding the page table lock which will block +truncation. ->bmap() is currently used by legacy ioctl() (FIBMAP) provided by some filesystems and by the swapper. The latter will eventually go away. Please, keep it that way and don't breed new callers. -->invalidatepage() is called when the filesystem must attempt to drop +->invalidate_folio() is called when the filesystem must attempt to drop some or all of the buffers from the page when it is being truncated. It -returns zero on success. If ->invalidatepage is zero, the kernel uses -block_invalidatepage() instead. The filesystem must exclusively acquire -invalidate_lock before invalidating page cache in truncate / hole punch path -(and thus calling into ->invalidatepage) to block races between page cache -invalidation and page cache filling functions (fault, read, ...). +returns zero on success. The filesystem must exclusively acquire +invalidate_lock before invalidating page cache in truncate / hole punch +path (and thus calling into ->invalidate_folio) to block races between page +cache invalidation and page cache filling functions (fault, read, ...). ->releasepage() is called when the kernel is about to try to drop the buffers from the page in preparation for freeing it. It returns zero to @@ -386,9 +380,9 @@ the kernel assumes that the fs has no private interest in the buffers. ->freepage() is called when the kernel is done dropping the page from the page cache. -->launder_page() may be called prior to releasing a page if -it is still found to be dirty. It returns zero if the page was successfully -cleaned, or an error value if not. Note that in order to prevent the page +->launder_folio() may be called prior to releasing a folio if +it is still found to be dirty. It returns zero if the folio was successfully +cleaned, or an error value if not. Note that in order to prevent the folio getting mapped back in and redirtied, it needs to be kept locked across the entire operation. @@ -438,13 +432,13 @@ prototypes:: locking rules: ====================== ============= ================= ========= -ops inode->i_lock blocked_lock_lock may block +ops flc_lock blocked_lock_lock may block ====================== ============= ================= ========= -lm_notify: yes yes no +lm_notify: no yes no lm_grant: no no no lm_break: yes no no lm_change yes no no -lm_breaker_owns_lease: no no no +lm_breaker_owns_lease: yes no no ====================== ============= ================= ========= buffer_head diff --git a/Documentation/filesystems/netfs_library.rst b/Documentation/filesystems/netfs_library.rst index 136f8da3d0e2..69f00179fdfe 100644 --- a/Documentation/filesystems/netfs_library.rst +++ b/Documentation/filesystems/netfs_library.rst @@ -7,6 +7,8 @@ Network Filesystem Helper Library .. Contents: - Overview. + - Per-inode context. + - Inode context helper functions. - Buffered read helpers. - Read helper functions. - Read helper structures. @@ -28,6 +30,69 @@ Note that the library module doesn't link against local caching directly, so access must be provided by the netfs. +Per-Inode Context +================= + +The network filesystem helper library needs a place to store a bit of state for +its use on each netfs inode it is helping to manage. To this end, a context +structure is defined:: + + struct netfs_i_context { + const struct netfs_request_ops *ops; + struct fscache_cookie *cache; + }; + +A network filesystem that wants to use netfs lib must place one of these +directly after the VFS ``struct inode`` it allocates, usually as part of its +own struct. This can be done in a way similar to the following:: + + struct my_inode { + struct { + /* These must be contiguous */ + struct inode vfs_inode; + struct netfs_i_context netfs_ctx; + }; + ... + }; + +This allows netfslib to find its state by simple offset from the inode pointer, +thereby allowing the netfslib helper functions to be pointed to directly by the +VFS/VM operation tables. + +The structure contains the following fields: + + * ``ops`` + + The set of operations provided by the network filesystem to netfslib. + + * ``cache`` + + Local caching cookie, or NULL if no caching is enabled. This field does not + exist if fscache is disabled. + + +Inode Context Helper Functions +------------------------------ + +To help deal with the per-inode context, a number helper functions are +provided. Firstly, a function to perform basic initialisation on a context and +set the operations table pointer:: + + void netfs_i_context_init(struct inode *inode, + const struct netfs_request_ops *ops); + +then two functions to cast between the VFS inode structure and the netfs +context:: + + struct netfs_i_context *netfs_i_context(struct inode *inode); + struct inode *netfs_inode(struct netfs_i_context *ctx); + +and finally, a function to get the cache cookie pointer from the context +attached to an inode (or NULL if fscache is disabled):: + + struct fscache_cookie *netfs_i_cookie(struct inode *inode); + + Buffered Read Helpers ===================== @@ -70,38 +135,22 @@ Read Helper Functions Three read helpers are provided:: - void netfs_readahead(struct readahead_control *ractl, - const struct netfs_read_request_ops *ops, - void *netfs_priv); + void netfs_readahead(struct readahead_control *ractl); int netfs_readpage(struct file *file, - struct folio *folio, - const struct netfs_read_request_ops *ops, - void *netfs_priv); + struct page *page); int netfs_write_begin(struct file *file, struct address_space *mapping, loff_t pos, unsigned int len, unsigned int flags, struct folio **_folio, - void **_fsdata, - const struct netfs_read_request_ops *ops, - void *netfs_priv); - -Each corresponds to a VM operation, with the addition of a couple of parameters -for the use of the read helpers: - - * ``ops`` - - A table of operations through which the helpers can talk to the filesystem. + void **_fsdata); - * ``netfs_priv`` - - Filesystem private data (can be NULL). - -Both of these values will be stored into the read request structure. +Each corresponds to a VM address space operation. These operations use the +state in the per-inode context. -For ->readahead() and ->readpage(), the network filesystem should just jump -into the corresponding read helper; whereas for ->write_begin(), it may be a +For ->readahead() and ->readpage(), the network filesystem just point directly +at the corresponding read helper; whereas for ->write_begin(), it may be a little more complicated as the network filesystem might want to flush conflicting writes or track dirty data and needs to put the acquired folio if an error occurs after calling the helper. @@ -116,7 +165,7 @@ occurs, the request will get partially completed if sufficient data is read. Additionally, there is:: - * void netfs_subreq_terminated(struct netfs_read_subrequest *subreq, + * void netfs_subreq_terminated(struct netfs_io_subrequest *subreq, ssize_t transferred_or_error, bool was_async); @@ -132,7 +181,7 @@ Read Helper Structures The read helpers make use of a couple of structures to maintain the state of the read. The first is a structure that manages a read request as a whole:: - struct netfs_read_request { + struct netfs_io_request { struct inode *inode; struct address_space *mapping; struct netfs_cache_resources cache_resources; @@ -140,7 +189,7 @@ the read. The first is a structure that manages a read request as a whole:: loff_t start; size_t len; loff_t i_size; - const struct netfs_read_request_ops *netfs_ops; + const struct netfs_request_ops *netfs_ops; unsigned int debug_id; ... }; @@ -187,8 +236,8 @@ The above fields are the ones the netfs can use. They are: The second structure is used to manage individual slices of the overall read request:: - struct netfs_read_subrequest { - struct netfs_read_request *rreq; + struct netfs_io_subrequest { + struct netfs_io_request *rreq; loff_t start; size_t len; size_t transferred; @@ -244,32 +293,26 @@ Read Helper Operations The network filesystem must provide the read helpers with a table of operations through which it can issue requests and negotiate:: - struct netfs_read_request_ops { - void (*init_rreq)(struct netfs_read_request *rreq, struct file *file); - bool (*is_cache_enabled)(struct inode *inode); - int (*begin_cache_operation)(struct netfs_read_request *rreq); - void (*expand_readahead)(struct netfs_read_request *rreq); - bool (*clamp_length)(struct netfs_read_subrequest *subreq); - void (*issue_op)(struct netfs_read_subrequest *subreq); - bool (*is_still_valid)(struct netfs_read_request *rreq); + struct netfs_request_ops { + void (*init_request)(struct netfs_io_request *rreq, struct file *file); + int (*begin_cache_operation)(struct netfs_io_request *rreq); + void (*expand_readahead)(struct netfs_io_request *rreq); + bool (*clamp_length)(struct netfs_io_subrequest *subreq); + void (*issue_read)(struct netfs_io_subrequest *subreq); + bool (*is_still_valid)(struct netfs_io_request *rreq); int (*check_write_begin)(struct file *file, loff_t pos, unsigned len, struct folio *folio, void **_fsdata); - void (*done)(struct netfs_read_request *rreq); + void (*done)(struct netfs_io_request *rreq); void (*cleanup)(struct address_space *mapping, void *netfs_priv); }; The operations are as follows: - * ``init_rreq()`` + * ``init_request()`` [Optional] This is called to initialise the request structure. It is given the file for reference and can modify the ->netfs_priv value. - * ``is_cache_enabled()`` - - [Required] This is called by netfs_write_begin() to ask if the file is being - cached. It should return true if it is being cached and false otherwise. - * ``begin_cache_operation()`` [Optional] This is called to ask the network filesystem to call into the @@ -305,7 +348,7 @@ The operations are as follows: This should return 0 on success and an error code on error. - * ``issue_op()`` + * ``issue_read()`` [Required] The helpers use this to dispatch a subrequest to the server for reading. In the subrequest, ->start, ->len and ->transferred indicate what @@ -420,12 +463,12 @@ The network filesystem's ->begin_cache_operation() method is called to set up a cache and this must call into the cache to do the work. If using fscache, for example, the cache would call:: - int fscache_begin_read_operation(struct netfs_read_request *rreq, + int fscache_begin_read_operation(struct netfs_io_request *rreq, struct fscache_cookie *cookie); passing in the request pointer and the cookie corresponding to the file. -The netfs_read_request object contains a place for the cache to hang its +The netfs_io_request object contains a place for the cache to hang its state:: struct netfs_cache_resources { @@ -443,7 +486,7 @@ operation table looks like the following:: void (*expand_readahead)(struct netfs_cache_resources *cres, loff_t *_start, size_t *_len, loff_t i_size); - enum netfs_read_source (*prepare_read)(struct netfs_read_subrequest *subreq, + enum netfs_io_source (*prepare_read)(struct netfs_io_subrequest *subreq, loff_t i_size); int (*read)(struct netfs_cache_resources *cres, @@ -462,6 +505,10 @@ operation table looks like the following:: struct iov_iter *iter, netfs_io_terminated_t term_func, void *term_func_priv); + + int (*query_occupancy)(struct netfs_cache_resources *cres, + loff_t start, size_t len, size_t granularity, + loff_t *_data_start, size_t *_data_len); }; With a termination handler function pointer:: @@ -536,6 +583,18 @@ The methods defined in the table are: indicating whether the termination is definitely happening in the caller's context. + * ``query_occupancy()`` + + [Required] Called to find out where the next piece of data is within a + particular region of the cache. The start and length of the region to be + queried are passed in, along with the granularity to which the answer needs + to be aligned. The function passes back the start and length of the data, + if any, available within that region. Note that there may be a hole at the + front. + + It returns 0 if some data was found, -ENODATA if there was no usable data + within the region or -ENOBUFS if there is no caching on this file. + Note that these methods are passed a pointer to the cache resource structure, not the read request structure as they could be used in other situations where there isn't a read request structure as well, such as writing dirty data to the @@ -546,4 +605,5 @@ API Function Reference ====================== .. kernel-doc:: include/linux/netfs.h -.. kernel-doc:: fs/netfs/read_helper.c +.. kernel-doc:: fs/netfs/buffered_read.c +.. kernel-doc:: fs/netfs/io.c diff --git a/Documentation/filesystems/porting.rst b/Documentation/filesystems/porting.rst index bf19fd6b86e7..7c1583dbeb59 100644 --- a/Documentation/filesystems/porting.rst +++ b/Documentation/filesystems/porting.rst @@ -45,6 +45,12 @@ typically between calling iget_locked() and unlocking the inode. At some point that will become mandatory. +**mandatory** + +The foo_inode_info should always be allocated through alloc_inode_sb() rather +than kmem_cache_alloc() or kmalloc() related to set up the inode reclaim context +correctly. + --- **mandatory** diff --git a/Documentation/filesystems/vfs.rst b/Documentation/filesystems/vfs.rst index bf5c48066fac..794bd1a66bfb 100644 --- a/Documentation/filesystems/vfs.rst +++ b/Documentation/filesystems/vfs.rst @@ -658,7 +658,7 @@ pages, however the address_space has finer control of write sizes. The read process essentially only requires 'readpage'. The write process is more complicated and uses write_begin/write_end or -set_page_dirty to write data into the address_space, and writepage and +dirty_folio to write data into the address_space, and writepage and writepages to writeback data to storage. Adding and removing pages to/from an address_space is protected by the @@ -724,10 +724,8 @@ cache in your filesystem. The following members are defined: int (*writepage)(struct page *page, struct writeback_control *wbc); int (*readpage)(struct file *, struct page *); int (*writepages)(struct address_space *, struct writeback_control *); - int (*set_page_dirty)(struct page *page); + bool (*dirty_folio)(struct address_space *, struct folio *); void (*readahead)(struct readahead_control *); - int (*readpages)(struct file *filp, struct address_space *mapping, - struct list_head *pages, unsigned nr_pages); int (*write_begin)(struct file *, struct address_space *mapping, loff_t pos, unsigned len, unsigned flags, struct page **pagep, void **fsdata); @@ -735,7 +733,7 @@ cache in your filesystem. The following members are defined: loff_t pos, unsigned len, unsigned copied, struct page *page, void *fsdata); sector_t (*bmap)(struct address_space *, sector_t); - void (*invalidatepage) (struct page *, unsigned int, unsigned int); + void (*invalidate_folio) (struct folio *, size_t start, size_t len); int (*releasepage) (struct page *, int); void (*freepage)(struct page *); ssize_t (*direct_IO)(struct kiocb *, struct iov_iter *iter); @@ -745,10 +743,10 @@ cache in your filesystem. The following members are defined: int (*migratepage) (struct page *, struct page *); /* put migration-failed page back to right list */ void (*putback_page) (struct page *); - int (*launder_page) (struct page *); + int (*launder_folio) (struct folio *); - int (*is_partially_uptodate) (struct page *, unsigned long, - unsigned long); + bool (*is_partially_uptodate) (struct folio *, size_t from, + size_t count); void (*is_dirty_writeback) (struct page *, bool *, bool *); int (*error_remove_page) (struct mapping *mapping, struct page *page); int (*swap_activate)(struct file *); @@ -793,34 +791,29 @@ cache in your filesystem. The following members are defined: This will choose pages from the address space that are tagged as DIRTY and will pass them to ->writepage. -``set_page_dirty`` - called by the VM to set a page dirty. This is particularly - needed if an address space attaches private data to a page, and - that data needs to be updated when a page is dirtied. This is +``dirty_folio`` + called by the VM to mark a folio as dirty. This is particularly + needed if an address space attaches private data to a folio, and + that data needs to be updated when a folio is dirtied. This is called, for example, when a memory mapped page gets modified. - If defined, it should set the PageDirty flag, and the - PAGECACHE_TAG_DIRTY tag in the radix tree. + If defined, it should set the folio dirty flag, and the + PAGECACHE_TAG_DIRTY search mark in i_pages. ``readahead`` Called by the VM to read pages associated with the address_space object. The pages are consecutive in the page cache and are locked. The implementation should decrement the page refcount after starting I/O on each page. Usually the page will be - unlocked by the I/O completion handler. If the filesystem decides - to stop attempting I/O before reaching the end of the readahead - window, it can simply return. The caller will decrement the page - refcount and unlock the remaining pages for you. Set PageUptodate - if the I/O completes successfully. Setting PageError on any page - will be ignored; simply unlock the page if an I/O error occurs. - -``readpages`` - called by the VM to read pages associated with the address_space - object. This is essentially just a vector version of readpage. - Instead of just one page, several pages are requested. - readpages is only used for read-ahead, so read errors are - ignored. If anything goes wrong, feel free to give up. - This interface is deprecated and will be removed by the end of - 2020; implement readahead instead. + unlocked by the I/O completion handler. The set of pages are + divided into some sync pages followed by some async pages, + rac->ra->async_size gives the number of async pages. The + filesystem should attempt to read all sync pages but may decide + to stop once it reaches the async pages. If it does decide to + stop attempting I/O, it can simply return. The caller will + remove the remaining pages from the address space, unlock them + and decrement the page refcount. Set PageUptodate if the I/O + completes successfully. Setting PageError on any page will be + ignored; simply unlock the page if an I/O error occurs. ``write_begin`` Called by the generic buffered write code to ask the filesystem @@ -868,15 +861,15 @@ cache in your filesystem. The following members are defined: to find out where the blocks in the file are and uses those addresses directly. -``invalidatepage`` - If a page has PagePrivate set, then invalidatepage will be - called when part or all of the page is to be removed from the +``invalidate_folio`` + If a folio has private data, then invalidate_folio will be + called when part or all of the folio is to be removed from the address space. This generally corresponds to either a truncation, punch hole or a complete invalidation of the address space (in the latter case 'offset' will always be 0 and 'length' - will be PAGE_SIZE). Any private data associated with the page + will be folio_size()). Any private data associated with the page should be updated to reflect this truncation. If offset is 0 - and length is PAGE_SIZE, then the private data should be + and length is folio_size(), then the private data should be released, because the page must be able to be completely discarded. This may be done by calling the ->releasepage function, but in this case the release MUST succeed. @@ -930,16 +923,16 @@ cache in your filesystem. The following members are defined: ``putback_page`` Called by the VM when isolated page's migration fails. -``launder_page`` - Called before freeing a page - it writes back the dirty page. - To prevent redirtying the page, it is kept locked during the +``launder_folio`` + Called before freeing a folio - it writes back the dirty folio. + To prevent redirtying the folio, it is kept locked during the whole operation. ``is_partially_uptodate`` Called by the VM when reading a file through the pagecache when - the underlying blocksize != pagesize. If the required block is - up to date then the read can complete without needing the IO to - bring the whole page up to date. + the underlying blocksize is smaller than the size of the folio. + If the required block is up to date then the read can complete + without needing I/O to bring the whole page up to date. ``is_dirty_writeback`` Called by the VM when attempting to reclaim a page. The VM uses diff --git a/Documentation/firmware-guide/acpi/enumeration.rst b/Documentation/firmware-guide/acpi/enumeration.rst index 74b830b2fd59..47fb4d6d4557 100644 --- a/Documentation/firmware-guide/acpi/enumeration.rst +++ b/Documentation/firmware-guide/acpi/enumeration.rst @@ -19,16 +19,17 @@ possible we decided to do following: platform devices. - Devices behind real busses where there is a connector resource - are represented as struct spi_device or struct i2c_device - (standard UARTs are not busses so there is no struct uart_device). + are represented as struct spi_device or struct i2c_device. Note + that standard UARTs are not busses so there is no struct uart_device, + although some of them may be represented by sturct serdev_device. As both ACPI and Device Tree represent a tree of devices (and their resources) this implementation follows the Device Tree way as much as possible. -The ACPI implementation enumerates devices behind busses (platform, SPI and -I2C), creates the physical devices and binds them to their ACPI handle in -the ACPI namespace. +The ACPI implementation enumerates devices behind busses (platform, SPI, +I2C, and in some cases UART), creates the physical devices and binds them +to their ACPI handle in the ACPI namespace. This means that when ACPI_HANDLE(dev) returns non-NULL the device was enumerated from ACPI namespace. This handle can be used to extract other @@ -46,18 +47,16 @@ some minor changes. Adding ACPI support for an existing driver should be pretty straightforward. Here is the simplest example:: - #ifdef CONFIG_ACPI static const struct acpi_device_id mydrv_acpi_match[] = { /* ACPI IDs here */ { } }; MODULE_DEVICE_TABLE(acpi, mydrv_acpi_match); - #endif static struct platform_driver my_driver = { ... .driver = { - .acpi_match_table = ACPI_PTR(mydrv_acpi_match), + .acpi_match_table = mydrv_acpi_match, }, }; @@ -143,6 +142,45 @@ In robust cases the client unfortunately needs to call acpi_dma_request_slave_chan_by_index() directly and therefore choose the specific FixedDMA resource by its index. +Named Interrupts +================ + +Drivers enumerated via ACPI can have names to interrupts in the ACPI table +which can be used to get the IRQ number in the driver. + +The interrupt name can be listed in _DSD as 'interrupt-names'. The names +should be listed as an array of strings which will map to the Interrupt() +resource in the ACPI table corresponding to its index. + +The table below shows an example of its usage:: + + Device (DEV0) { + ... + Name (_CRS, ResourceTemplate() { + ... + Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive) { + 0x20, + 0x24 + } + }) + + Name (_DSD, Package () { + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { + Package () {"interrupt-names", + Package (2) {"default", "alert"}}, + } + ... + }) + } + +The interrupt name 'default' will correspond to 0x20 in Interrupt() +resource and 'alert' to 0x24. Note that only the Interrupt() resource +is mapped and not GpioInt() or similar. + +The driver can call the function - fwnode_irq_get_byname() with the fwnode +and interrupt name as arguments to get the corresponding IRQ number. + SPI serial bus support ====================== @@ -155,7 +193,7 @@ Here is what the ACPI namespace for a SPI slave might look like:: Device (EEP0) { Name (_ADR, 1) - Name (_CID, Package() { + Name (_CID, Package () { "ATML0025", "AT25", }) @@ -172,59 +210,51 @@ The SPI device drivers only need to add ACPI IDs in a similar way than with the platform device drivers. Below is an example where we add ACPI support to at25 SPI eeprom driver (this is meant for the above ACPI snippet):: - #ifdef CONFIG_ACPI static const struct acpi_device_id at25_acpi_match[] = { { "AT25", 0 }, - { }, + { } }; MODULE_DEVICE_TABLE(acpi, at25_acpi_match); - #endif static struct spi_driver at25_driver = { .driver = { ... - .acpi_match_table = ACPI_PTR(at25_acpi_match), + .acpi_match_table = at25_acpi_match, }, }; Note that this driver actually needs more information like page size of the -eeprom etc. but at the time writing this there is no standard way of -passing those. One idea is to return this in _DSM method like:: +eeprom, etc. This information can be passed via _DSD method like:: Device (EEP0) { ... - Method (_DSM, 4, NotSerialized) + Name (_DSD, Package () { - Store (Package (6) + ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), + Package () { - "byte-len", 1024, - "addr-mode", 2, - "page-size, 32 - }, Local0) - - // Check UUIDs etc. - - Return (Local0) - } - -Then the at25 SPI driver can get this configuration by calling _DSM on its -ACPI handle like:: - - struct acpi_buffer output = { ACPI_ALLOCATE_BUFFER, NULL }; - struct acpi_object_list input; - acpi_status status; + Package () { "size", 1024 }, + Package () { "pagesize", 32 }, + Package () { "address-width", 16 }, + } + }) + } - /* Fill in the input buffer */ +Then the at25 SPI driver can get this configuration by calling device property +APIs during ->probe() phase like:: - status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "_DSM", - &input, &output); - if (ACPI_FAILURE(status)) - /* Handle the error */ + err = device_property_read_u32(dev, "size", &size); + if (err) + ...error handling... - /* Extract the data here */ + err = device_property_read_u32(dev, "pagesize", &page_size); + if (err) + ...error handling... - kfree(output.pointer); + err = device_property_read_u32(dev, "address-width", &addr_width); + if (err) + ...error handling... I2C serial bus support ====================== @@ -237,26 +267,24 @@ registered. Below is an example of how to add ACPI support to the existing mpu3050 input driver:: - #ifdef CONFIG_ACPI static const struct acpi_device_id mpu3050_acpi_match[] = { { "MPU3050", 0 }, - { }, + { } }; MODULE_DEVICE_TABLE(acpi, mpu3050_acpi_match); - #endif static struct i2c_driver mpu3050_i2c_driver = { .driver = { .name = "mpu3050", - .owner = THIS_MODULE, .pm = &mpu3050_pm, .of_match_table = mpu3050_of_match, - .acpi_match_table = ACPI_PTR(mpu3050_acpi_match), + .acpi_match_table = mpu3050_acpi_match, }, .probe = mpu3050_probe, .remove = mpu3050_remove, .id_table = mpu3050_ids, }; + module_i2c_driver(mpu3050_i2c_driver); Reference to PWM device ======================= @@ -282,9 +310,9 @@ introduced, i.e.:: } } } - }) ... + } In the above example the PWM-based LED driver references to the PWM channel 0 of \_SB.PCI0.PWM device with initial period setting equal to 600 ms (note that @@ -306,26 +334,13 @@ For example:: { Name (SBUF, ResourceTemplate() { - ... // Used to power on/off the device - GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, - IoRestrictionOutputOnly, "\\_SB.PCI0.GPI0", - 0x00, ResourceConsumer,,) - { - // Pin List - 0x0055 - } + GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionOutputOnly, + "\\_SB.PCI0.GPI0", 0, ResourceConsumer) { 85 } // Interrupt for the device - GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, - 0x0000, "\\_SB.PCI0.GPI0", 0x00, ResourceConsumer,,) - { - // Pin list - 0x0058 - } - - ... - + GpioInt (Edge, ActiveHigh, ExclusiveAndWake, PullNone, 0, + "\\_SB.PCI0.GPI0", 0, ResourceConsumer) { 88 } } Return (SBUF) @@ -337,11 +352,12 @@ For example:: ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () {"power-gpios", Package() {^DEV, 0, 0, 0 }}, - Package () {"irq-gpios", Package() {^DEV, 1, 0, 0 }}, + Package () { "power-gpios", Package () { ^DEV, 0, 0, 0 } }, + Package () { "irq-gpios", Package () { ^DEV, 1, 0, 0 } }, } }) ... + } These GPIO numbers are controller relative and path "\\_SB.PCI0.GPI0" specifies the path to the controller. In order to use these GPIOs in Linux @@ -460,10 +476,10 @@ namespace link:: Device (TMP0) { Name (_HID, "PRP0001") - Name (_DSD, Package() { + Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package (2) { "compatible", "ti,tmp75" }, + Package () { "compatible", "ti,tmp75" }, } }) Method (_CRS, 0, Serialized) diff --git a/Documentation/firmware-guide/acpi/gpio-properties.rst b/Documentation/firmware-guide/acpi/gpio-properties.rst index df4b711053ee..eaec732cc77c 100644 --- a/Documentation/firmware-guide/acpi/gpio-properties.rst +++ b/Documentation/firmware-guide/acpi/gpio-properties.rst @@ -21,18 +21,18 @@ index, like the ASL example below shows:: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {15} + "\\_SB.GPO0", 0, ResourceConsumer) { 15 } GpioIo (Exclusive, PullUp, 0, 0, IoRestrictionOutputOnly, - "\\_SB.GPO0", 0, ResourceConsumer) {27, 31} + "\\_SB.GPO0", 0, ResourceConsumer) { 27, 31 } }) Name (_DSD, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () - { - Package () {"reset-gpios", Package() {^BTH, 1, 1, 0 }}, - Package () {"shutdown-gpios", Package() {^BTH, 0, 0, 0 }}, + { + Package () { "reset-gpios", Package () { ^BTH, 1, 1, 0 } }, + Package () { "shutdown-gpios", Package () { ^BTH, 0, 0, 0 } }, } }) } @@ -123,17 +123,17 @@ Example:: // _DSD Hierarchical Properties Extension UUID ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"), Package () { - Package () {"hog-gpio8", "G8PU"} + Package () { "hog-gpio8", "G8PU" } } }) Name (G8PU, Package () { ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"), Package () { - Package () {"gpio-hog", 1}, - Package () {"gpios", Package () {8, 0}}, - Package () {"output-high", 1}, - Package () {"line-name", "gpio8-pullup"}, + Package () { "gpio-hog", 1 }, + Package () { "gpios", Package () { 8, 0 } }, + Package () { "output-high", 1 }, + Package () { "line-name", "gpio8-pullup" }, } }) @@ -266,15 +266,17 @@ have a device like below:: Name (_CRS, ResourceTemplate () { GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {15} + "\\_SB.GPO0", 0, ResourceConsumer) { 15 } GpioIo (Exclusive, PullNone, 0, 0, IoRestrictionNone, - "\\_SB.GPO0", 0, ResourceConsumer) {27} + "\\_SB.GPO0", 0, ResourceConsumer) { 27 } }) } The driver might expect to get the right GPIO when it does:: desc = gpiod_get(dev, "reset", GPIOD_OUT_LOW); + if (IS_ERR(desc)) + ...error handling... but since there is no way to know the mapping between "reset" and the GpioIo() in _CRS desc will hold ERR_PTR(-ENOENT). diff --git a/Documentation/gpu/drm-internals.rst b/Documentation/gpu/drm-internals.rst index 607f78f0f189..38afed24a75c 100644 --- a/Documentation/gpu/drm-internals.rst +++ b/Documentation/gpu/drm-internals.rst @@ -75,6 +75,12 @@ 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. +Module Initialization +--------------------- + +.. kernel-doc:: include/drm/drm_module.h + :doc: overview + Managing Ownership of the Framebuffer Aperture ---------------------------------------------- diff --git a/Documentation/gpu/drm-kms-helpers.rst b/Documentation/gpu/drm-kms-helpers.rst index 5bb55ec1b9b5..c3ce91eecbc1 100644 --- a/Documentation/gpu/drm-kms-helpers.rst +++ b/Documentation/gpu/drm-kms-helpers.rst @@ -232,34 +232,34 @@ HDCP Helper Functions Reference Display Port Helper Functions Reference ======================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :doc: dp helpers -.. kernel-doc:: include/drm/drm_dp_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp.c :export: Display Port CEC Helper Functions Reference =========================================== -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :doc: dp cec helpers -.. kernel-doc:: drivers/gpu/drm/drm_dp_cec.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_cec.c :export: Display Port Dual Mode Adaptor Helper Functions Reference ========================================================= -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :doc: dp dual mode helpers -.. kernel-doc:: include/drm/drm_dp_dual_mode_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_dual_mode_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_dual_mode_helper.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_dual_mode_helper.c :export: Display Port MST Helpers @@ -268,19 +268,19 @@ Display Port MST Helpers Overview -------- -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: dp mst helper -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :doc: Branch device and port refcounting Functions Reference ------------------- -.. kernel-doc:: include/drm/drm_dp_mst_helper.h +.. kernel-doc:: include/drm/dp/drm_dp_mst_helper.h :internal: -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :export: Topology Lifetime Internals @@ -289,7 +289,7 @@ Topology Lifetime Internals These functions aren't exported to drivers, but are documented here to help make the MST topology helpers easier to understand -.. kernel-doc:: drivers/gpu/drm/drm_dp_mst_topology.c +.. kernel-doc:: drivers/gpu/drm/dp/drm_dp_mst_topology.c :functions: drm_dp_mst_topology_try_get_mstb drm_dp_mst_topology_get_mstb drm_dp_mst_topology_put_mstb drm_dp_mst_topology_try_get_port drm_dp_mst_topology_get_port diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst index d14bf1c35d7e..6f9c064fd323 100644 --- a/Documentation/gpu/drm-kms.rst +++ b/Documentation/gpu/drm-kms.rst @@ -423,12 +423,12 @@ Connector Functions Reference Writeback Connectors -------------------- -.. kernel-doc:: include/drm/drm_writeback.h - :internal: - .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :doc: overview +.. kernel-doc:: include/drm/drm_writeback.h + :internal: + .. kernel-doc:: drivers/gpu/drm/drm_writeback.c :export: diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst index e0538083a2c0..198bcc1affa1 100644 --- a/Documentation/gpu/drm-mm.rst +++ b/Documentation/gpu/drm-mm.rst @@ -8,7 +8,7 @@ the very dynamic nature of many of that data, managing graphics memory efficiently is thus crucial for the graphics stack and plays a central role in the DRM infrastructure. -The DRM core includes two memory managers, namely Translation Table Maps +The DRM core includes two memory managers, namely Translation Table Manager (TTM) and Graphics Execution Manager (GEM). TTM was the first DRM memory manager to be developed and tried to be a one-size-fits-them all solution. It provides a single userspace API to accommodate the need of diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index b7d801993bfa..bcaefc952764 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -539,6 +539,7 @@ GuC ABI .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_mmio_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_communication_ctb_abi.h .. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h +.. kernel-doc:: drivers/gpu/drm/i915/gt/uc/abi/guc_klvs_abi.h HuC --- diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index da138dd39883..127e76ee0b2d 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -222,7 +222,7 @@ Convert drivers to use drm_fbdev_generic_setup() Most drivers can use drm_fbdev_generic_setup(). Driver have to implement atomic modesetting and GEM vmap support. Historically, generic fbdev emulation expected the framebuffer in system memory or system-like memory. By employing -struct dma_buf_map, drivers with frambuffers in I/O memory can be supported +struct iosys_map, drivers with frambuffers in I/O memory can be supported as well. Contact: Maintainer of the driver you plan to convert @@ -234,13 +234,35 @@ Reimplement functions in drm_fbdev_fb_ops without fbdev A number of callback functions in drm_fbdev_fb_ops could benefit from being rewritten without dependencies on the fbdev module. Some of the -helpers could further benefit from using struct dma_buf_map instead of +helpers could further benefit from using struct iosys_map instead of raw pointers. Contact: Thomas Zimmermann <tzimmermann@suse.de>, Daniel Vetter Level: Advanced +Benchmark and optimize blitting and format-conversion function +-------------------------------------------------------------- + +Drawing to dispay memory quickly is crucial for many applications' +performance. + +On at least x86-64, sys_imageblit() is significantly slower than +cfb_imageblit(), even though both use the same blitting algorithm and +the latter is written for I/O memory. It turns out that cfb_imageblit() +uses movl instructions, while sys_imageblit apparently does not. This +seems to be a problem with gcc's optimizer. DRM's format-conversion +helpers might be subject to similar issues. + +Benchmark and optimize fbdev's sys_() helpers and DRM's format-conversion +helpers. In cases that can be further optimized, maybe implement a different +algorithm. For micro-optimizations, use movl/movq instructions explicitly. +That might possibly require architecture-specific helpers (e.g., storel() +storeq()). + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Intermediate drm_framebuffer_funcs and drm_mode_config_funcs.fb_create cleanup ----------------------------------------------------------------- @@ -300,30 +322,6 @@ Contact: Daniel Vetter, Noralf Tronnes Level: Advanced -Garbage collect fbdev scrolling acceleration --------------------------------------------- - -Scroll acceleration has been disabled in fbcon. Now it works as the old -SCROLL_REDRAW mode. A ton of code was removed in fbcon.c and the hook bmove was -removed from fbcon_ops. -Remaining tasks: - -- a bunch of the hooks in fbcon_ops could be removed or simplified by calling - directly instead of the function table (with a switch on p->rotate) - -- fb_copyarea is unused after this, and can be deleted from all drivers - -- after that, fb_copyarea can be deleted from fb_ops in include/linux/fb.h as - well as cfb_copyarea - -Note that not all acceleration code can be deleted, since clearing and cursor -support is still accelerated, which might be good candidates for further -deletion projects. - -Contact: Daniel Vetter - -Level: Intermediate - idr_init_base() --------------- @@ -434,19 +432,19 @@ Contact: Emil Velikov, respective driver maintainers Level: Intermediate -Use struct dma_buf_map throughout codebase ------------------------------------------- +Use struct iosys_map throughout codebase +---------------------------------------- -Pointers to shared device memory are stored in struct dma_buf_map. Each +Pointers to shared device memory are stored in struct iosys_map. Each instance knows whether it refers to system or I/O memory. Most of the DRM-wide -interface have been converted to use struct dma_buf_map, but implementations +interface have been converted to use struct iosys_map, but implementations often still use raw pointers. -The task is to use struct dma_buf_map where it makes sense. +The task is to use struct iosys_map where it makes sense. -* Memory managers should use struct dma_buf_map for dma-buf-imported buffers. -* TTM might benefit from using struct dma_buf_map internally. -* Framebuffer copying and blitting helpers should operate on struct dma_buf_map. +* Memory managers should use struct iosys_map for dma-buf-imported buffers. +* TTM might benefit from using struct iosys_map internally. +* Framebuffer copying and blitting helpers should operate on struct iosys_map. Contact: Thomas Zimmermann <tzimmermann@suse.de>, Christian König, Daniel Vetter @@ -467,6 +465,21 @@ Contact: Thomas Zimmermann <tzimmermann@suse.de> Level: Intermediate +Request memory regions in all drivers +------------------------------------- + +Go through all drivers and add code to request the memory regions that the +driver uses. This requires adding calls to request_mem_region(), +pci_request_region() or similar functions. Use helpers for managed cleanup +where possible. + +Drivers are pretty bad at doing this and there used to be conflicts among +DRM and fbdev drivers. Still, it's the correct thing to do. + +Contact: Thomas Zimmermann <tzimmermann@suse.de> + +Level: Starter + Core refactorings ================= @@ -484,8 +497,12 @@ This is a really varied tasks with lots of little bits and pieces: achieved by using an IPI to the local processor. * There's a massive confusion of different panic handlers. DRM fbdev emulation - helpers have one, but on top of that the fbcon code itself also has one. We - need to make sure that they stop fighting over each another. + helpers had their own (long removed), but on top of that the fbcon code itself + also has one. We need to make sure that they stop fighting over each other. + This is worked around by checking ``oops_in_progress`` at various entry points + into the DRM fbdev emulation helpers. A much cleaner approach here would be to + switch fbcon to the `threaded printk support + <https://lwn.net/Articles/800946/>`_. * ``drm_can_sleep()`` is a mess. It hides real bugs in normal operations and isn't a full solution for panic paths. We need to make sure that it only @@ -497,16 +514,15 @@ This is a really varied tasks with lots of little bits and pieces: even spinlocks (because NMI and hardirq can panic too). We need to either make sure to not call such paths, or trylock everything. Really tricky. -* For the above locking troubles reasons it's pretty much impossible to - attempt a synchronous modeset from panic handlers. The only thing we could - try to achive is an atomic ``set_base`` of the primary plane, and hope that - it shows up. Everything else probably needs to be delayed to some worker or - something else which happens later on. Otherwise it just kills the box - harder, prevent the panic from going out on e.g. netconsole. +* A clean solution would be an entirely separate panic output support in KMS, + bypassing the current fbcon support. See `[PATCH v2 0/3] drm: Add panic handling + <https://lore.kernel.org/dri-devel/20190311174218.51899-1-noralf@tronnes.org/>`_. -* There's also proposal for a simplied DRM console instead of the full-blown - fbcon and DRM fbdev emulation. Any kind of panic handling tricks should - obviously work for both console, in case we ever get kmslog merged. +* Encoding the actual oops and preceding dmesg in a QR might help with the + dread "important stuff scrolled away" problem. See `[RFC][PATCH] Oops messages + transfer using QR codes + <https://lore.kernel.org/lkml/1446217392-11981-1-git-send-email-alexandru.murtaza@intel.com/>`_ + for some example code that could be reused. Contact: Daniel Vetter diff --git a/Documentation/gpu/vgaarbiter.rst b/Documentation/gpu/vgaarbiter.rst index 339ed5fecd2e..bde3c0afb059 100644 --- a/Documentation/gpu/vgaarbiter.rst +++ b/Documentation/gpu/vgaarbiter.rst @@ -100,7 +100,7 @@ In-kernel interface .. kernel-doc:: include/linux/vgaarb.h :internal: -.. kernel-doc:: drivers/gpu/vga/vgaarb.c +.. kernel-doc:: drivers/pci/vgaarb.c :export: libpciaccess diff --git a/Documentation/gpu/vkms.rst b/Documentation/gpu/vkms.rst index 941f0e7e5eef..9c873c3912cc 100644 --- a/Documentation/gpu/vkms.rst +++ b/Documentation/gpu/vkms.rst @@ -124,8 +124,6 @@ Add Plane Features There's lots of plane features we could add support for: -- Multiple overlay planes. [Good to get started] - - Clearing primary plane: clear primary plane before plane composition (at the start) for correctness of pixel blend ops. It also guarantees alpha channel is cleared in the target buffer for stable crc. [Good to get started] diff --git a/Documentation/hwmon/aquacomputer_d5next.rst b/Documentation/hwmon/aquacomputer_d5next.rst index 1f4bb4ba2e4b..3373e27b707d 100644 --- a/Documentation/hwmon/aquacomputer_d5next.rst +++ b/Documentation/hwmon/aquacomputer_d5next.rst @@ -6,22 +6,21 @@ Kernel driver aquacomputer-d5next Supported devices: * Aquacomputer D5 Next watercooling pump +* Aquacomputer Farbwerk 360 RGB controller Author: Aleksa Savic Description ----------- -This driver exposes hardware sensors of the Aquacomputer D5 Next watercooling -pump, which communicates through a proprietary USB HID protocol. +This driver exposes hardware sensors of listed Aquacomputer devices, which +communicate through proprietary USB HID protocols. -Available sensors are pump and fan speed, power, voltage and current, as -well as coolant temperature. Also available through debugfs are the serial -number, firmware version and power-on count. - -Attaching a fan is optional and allows it to be controlled using temperature -curves directly from the pump. If it's not connected, the fan-related sensors -will report zeroes. +For the D5 Next pump, available sensors are pump and fan speed, power, voltage +and current, as well as coolant temperature. Also available through debugfs are +the serial number, firmware version and power-on count. Attaching a fan to it is +optional and allows it to be controlled using temperature curves directly from the +pump. If it's not connected, the fan-related sensors will report zeroes. The pump can be configured either through software or via its physical interface. Configuring the pump through this driver is not implemented, as it @@ -29,33 +28,31 @@ seems to require sending it a complete configuration. That includes addressable RGB LEDs, for which there is no standard sysfs interface. Thus, that task is better suited for userspace tools. +The Farbwerk 360 exposes four temperature sensors. Depending on the device, +not all sysfs and debugfs entries will be available. + Usage notes ----------- -The pump communicates via HID reports. The driver is loaded automatically by +The devices communicate via HID reports. The driver is loaded automatically by the kernel and supports hotswapping. Sysfs entries ------------- -============ ============================================= -temp1_input Coolant temperature (in millidegrees Celsius) -fan1_input Pump speed (in RPM) -fan2_input Fan speed (in RPM) -power1_input Pump power (in micro Watts) -power2_input Fan power (in micro Watts) -in0_input Pump voltage (in milli Volts) -in1_input Fan voltage (in milli Volts) -in2_input +5V rail voltage (in milli Volts) -curr1_input Pump current (in milli Amperes) -curr2_input Fan current (in milli Amperes) -============ ============================================= +================ ============================================= +temp[1-4]_input Temperature sensors (in millidegrees Celsius) +fan[1-2]_input Pump/fan speed (in RPM) +power[1-2]_input Pump/fan power (in micro Watts) +in[0-2]_input Pump/fan voltage (in milli Volts) +curr[1-2]_input Pump/fan current (in milli Amperes) +================ ============================================= Debugfs entries --------------- -================ =============================================== -serial_number Serial number of the pump +================ ================================================= +serial_number Serial number of the device firmware_version Version of installed firmware -power_cycles Count of how many times the pump was powered on -================ =============================================== +power_cycles Count of how many times the device was powered on +================ ================================================= diff --git a/Documentation/hwmon/asus_ec_sensors.rst b/Documentation/hwmon/asus_ec_sensors.rst new file mode 100644 index 000000000000..e7e8f1640f45 --- /dev/null +++ b/Documentation/hwmon/asus_ec_sensors.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver asus_ec_sensors +================================= + +Supported boards: + * PRIME X570-PRO, + * Pro WS X570-ACE, + * ROG CROSSHAIR VIII DARK HERO, + * ROG CROSSHAIR VIII HERO (WI-FI) + * ROG CROSSHAIR VIII FORMULA, + * ROG CROSSHAIR VIII HERO, + * ROG CROSSHAIR VIII IMPACT, + * ROG STRIX B550-E GAMING, + * ROG STRIX B550-I GAMING, + * ROG STRIX X570-E GAMING, + * ROG STRIX X570-F GAMING, + * ROG STRIX X570-I GAMING + +Authors: + - Eugene Shalygin <eugene.shalygin@gmail.com> + +Description: +------------ +ASUS mainboards publish hardware monitoring information via Super I/O +chip and the ACPI embedded controller (EC) registers. Some of the sensors +are only available via the EC. + +The driver is aware of and reads the following sensors: + +1. Chipset (PCH) temperature +2. CPU package temperature +3. Motherboard temperature +4. Readings from the T_Sensor header +5. VRM temperature +6. CPU_Opt fan RPM +7. VRM heatsink fan RPM +8. Chipset fan RPM +9. Readings from the "Water flow meter" header (RPM) +10. Readings from the "Water In" and "Water Out" temperature headers +11. CPU current +12. CPU core voltage + +Sensor values are read from EC registers, and to avoid race with the board +firmware the driver acquires ACPI mutex, the one used by the WMI when its +methods access the EC. + +Module Parameters +----------------- + * mutex_path: string + The driver holds path to the ACPI mutex for each board (actually, + the path is mostly identical for them). If ASUS changes this path + in a future BIOS update, this parameter can be used to override + the stored in the driver value until it gets updated. diff --git a/Documentation/hwmon/dell-smm-hwmon.rst b/Documentation/hwmon/dell-smm-hwmon.rst index beec88491171..d3323a96665d 100644 --- a/Documentation/hwmon/dell-smm-hwmon.rst +++ b/Documentation/hwmon/dell-smm-hwmon.rst @@ -165,3 +165,183 @@ obtain the same information and to control the fan status. The ioctl interface can be accessed from C programs or from shell using the i8kctl utility. See the source file of ``i8kutils`` for more information on how to use the ioctl interface. + +SMM Interface +------------- + +.. warning:: The SMM interface was reverse-engineered by trial-and-error + since Dell did not provide any Documentation, + please keep that in mind. + +The driver uses the SMM interface to send commands to the system BIOS. +This interface is normally used by Dell's 32-bit diagnostic program or +on newer notebook models by the buildin BIOS diagnostics. +The SMM is triggered by writing to the special ioports ``0xb2`` and ``0x84``, +and may cause short hangs when the BIOS code is taking too long to +execute. + +The SMM handler inside the system BIOS looks at the contents of the +``eax``, ``ebx``, ``ecx``, ``edx``, ``esi`` and ``edi`` registers. +Each register has a special purpose: + +=============== ================================== +Register Purpose +=============== ================================== +eax Holds the command code before SMM, + holds the first result after SMM. +ebx Holds the arguments. +ecx Unknown, set to 0. +edx Holds the second result after SMM. +esi Unknown, set to 0. +edi Unknown, set to 0. +=============== ================================== + +The SMM handler can signal a failure by either: + +- setting the lower sixteen bits of ``eax`` to ``0xffff`` +- not modifying ``eax`` at all +- setting the carry flag + +SMM command codes +----------------- + +=============== ======================= ================================================ +Command Code Command Name Description +=============== ======================= ================================================ +``0x0025`` Get Fn key status Returns the Fn key pressed after SMM: + + - 9th bit in ``eax`` indicates Volume up + - 10th bit in ``eax`` indicates Volume down + - both bits indicate Volume mute + +``0xa069`` Get power status Returns current power status after SMM: + + - 1st bit in ``eax`` indicates Battery connected + - 3th bit in ``eax`` indicates AC connected + +``0x00a3`` Get fan state Returns current fan state after SMM: + + - 1st byte in ``eax`` holds the current + fan state (0 - 2 or 3) + +``0x01a3`` Set fan state Sets the fan speed: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the desired + fan state (0 - 2 or 3) + +``0x02a3`` Get fan speed Returns the current fan speed in RPM: + + - 1st byte in ``ebx`` holds the fan number + - 1st word in ``eax`` holds the current + fan speed in RPM (after SMM) + +``0x03a3`` Get fan type Returns the fan type: + + - 1st byte in ``ebx`` holds the fan number + - 1st byte in ``eax`` holds the + fan type (after SMM): + + - 5th bit indicates docking fan + - 1 indicates Processor fan + - 2 indicates Motherboard fan + - 3 indicates Video fan + - 4 indicates Power supply fan + - 5 indicates Chipset fan + - 6 indicates other fan type + +``0x04a3`` Get nominal fan speed Returns the nominal RPM in each fan state: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the fan state + in question (0 - 2 or 3) + - 1st word in ``eax`` holds the nominal + fan speed in RPM (after SMM) + +``0x05a3`` Get fan speed tolerance Returns the speed tolerance for each fan state: + + - 1st byte in ``ebx`` holds the fan number + - 2nd byte in ``ebx`` holds the fan state + in question (0 - 2 or 3) + - 1st byte in ``eax`` returns the speed + tolerance + +``0x10a3`` Get sensor temperature Returns the measured temperature: + + - 1st byte in ``ebx`` holds the sensor number + - 1st byte in ``eax`` holds the measured + temperature (after SMM) + +``0x11a3`` Get sensor type Returns the sensor type: + + - 1st byte in ``ebx`` holds the sensor number + - 1st byte in ``eax`` holds the + temperature type (after SMM): + + - 1 indicates CPU sensor + - 2 indicates GPU sensor + - 3 indicates SODIMM sensor + - 4 indicates other sensor type + - 5 indicates Ambient sensor + - 6 indicates other sensor type + +``0xfea3`` Get SMM signature Returns Dell signature if interface + is supported (after SMM): + + - ``eax`` holds 1145651527 + (0x44494147 or "DIAG") + - ``edx`` holds 1145392204 + (0x44454c4c or "DELL") + +``0xffa3`` Get SMM signature Same as ``0xfea3``, check both. +=============== ======================= ================================================ + +There are additional commands for enabling (``0x31a3`` or ``0x35a3``) and +disabling (``0x30a3`` or ``0x34a3``) automatic fan speed control. +The commands are however causing severe sideeffects on many machines, so +they are not used by default. + +On several machines (Inspiron 3505, Precision 490, Vostro 1720, ...), the +fans supports a 4th "magic" state, which signals the BIOS that automatic +fan control should be enabled for a specific fan. +However there are also some machines who do support a 4th regular fan state too, +but in case of the "magic" state, the nominal RPM reported for this state is a +placeholder value, which however is not always detectable. + +Firmware Bugs +------------- + +The SMM calls can behave erratic on some machines: + +======================================================= ================= +Firmware Bug Affected Machines +======================================================= ================= +Reading of fan states return spurious errors. Precision 490 + +Reading of fan types causes erratic fan behaviour. Studio XPS 8000 + + Studio XPS 8100 + + Inspiron 580 + +Fan-related SMM calls take too long (about 500ms). Inspiron 7720 + + Vostro 3360 + + XPS 13 9333 + + XPS 15 L502X +======================================================= ================= + +In case you experience similar issues on your Dell machine, please +submit a bugreport on bugzilla to we can apply workarounds. + +Limitations +----------- + +The SMM calls can take too long to execute on some machines, causing +short hangs and/or audio glitches. +Also the fan state needs to be restored after suspend, as well as +the automatic mode settings. +When reading a temperature sensor, values above 127 degrees indicate +a BIOS read error or a deactivated sensor. diff --git a/Documentation/hwmon/index.rst b/Documentation/hwmon/index.rst index df20022c741f..863b76289159 100644 --- a/Documentation/hwmon/index.rst +++ b/Documentation/hwmon/index.rst @@ -43,6 +43,7 @@ Hardware Monitoring Kernel Drivers asb100 asc7621 aspeed-pwm-tacho + asus_ec_sensors asus_wmi_ec_sensors asus_wmi_sensors bcm54140 @@ -160,7 +161,10 @@ Hardware Monitoring Kernel Drivers pc87427 pcf8591 pim4328 + pli1209bc pm6764tr + peci-cputemp + peci-dimmtemp pmbus powr1220 pxe1610 @@ -185,6 +189,7 @@ Hardware Monitoring Kernel Drivers smsc47m1 sparx5-temp stpddc60 + sy7636a-hwmon tc654 tc74 thmc50 @@ -193,6 +198,7 @@ Hardware Monitoring Kernel Drivers tmp108 tmp401 tmp421 + tmp464 tmp513 tps23861 tps40422 diff --git a/Documentation/hwmon/lm70.rst b/Documentation/hwmon/lm70.rst index 6ddc5b67ccb5..11303a7e16a8 100644 --- a/Documentation/hwmon/lm70.rst +++ b/Documentation/hwmon/lm70.rst @@ -15,6 +15,10 @@ Supported chips: Information: https://www.ti.com/product/tmp122 + * Texas Instruments TMP125 + + Information: https://www.ti.com/product/tmp125 + * National Semiconductor LM71 Datasheet: https://www.ti.com/product/LM71 @@ -53,6 +57,9 @@ The LM74 and TMP121/TMP122/TMP123/TMP124 are very similar; main difference is The TMP122/TMP124 also feature configurable temperature thresholds. +The TMP125 is less accurate and provides 10-bit temperature data +with 0.25 degrees Celsius resolution. + The LM71 is also very similar; main difference is 14-bit temperature data (0.03125 degrees celsius resolution). diff --git a/Documentation/hwmon/max6639.rst b/Documentation/hwmon/max6639.rst index 3da54225f83c..c85d285a3489 100644 --- a/Documentation/hwmon/max6639.rst +++ b/Documentation/hwmon/max6639.rst @@ -9,7 +9,7 @@ Supported chips: Addresses scanned: I2C 0x2c, 0x2e, 0x2f - Datasheet: http://pdfserv.maxim-ic.com/en/ds/MAX6639.pdf + Datasheet: https://datasheets.maximintegrated.com/en/ds/MAX6639-MAX6639F.pdf Authors: - He Changqing <hechangqing@semptian.com> diff --git a/Documentation/hwmon/peci-cputemp.rst b/Documentation/hwmon/peci-cputemp.rst new file mode 100644 index 000000000000..fe0422248dc5 --- /dev/null +++ b/Documentation/hwmon/peci-cputemp.rst @@ -0,0 +1,90 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +Kernel driver peci-cputemp +========================== + +Supported chips: + One of Intel server CPUs listed below which is connected to a PECI bus. + * Intel Xeon E5/E7 v3 server processors + Intel Xeon E5-14xx v3 family + Intel Xeon E5-24xx v3 family + Intel Xeon E5-16xx v3 family + Intel Xeon E5-26xx v3 family + Intel Xeon E5-46xx v3 family + Intel Xeon E7-48xx v3 family + Intel Xeon E7-88xx v3 family + * Intel Xeon E5/E7 v4 server processors + Intel Xeon E5-16xx v4 family + Intel Xeon E5-26xx v4 family + Intel Xeon E5-46xx v4 family + Intel Xeon E7-48xx v4 family + Intel Xeon E7-88xx v4 family + * Intel Xeon Scalable server processors + Intel Xeon D family + Intel Xeon Bronze family + Intel Xeon Silver family + Intel Xeon Gold family + Intel Xeon Platinum family + + Datasheet: Available from http://www.intel.com/design/literature.htm + +Author: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> + +Description +----------- + +This driver implements a generic PECI hwmon feature which provides Digital +Thermal Sensor (DTS) thermal readings of the CPU package and CPU cores that are +accessible via the processor PECI interface. + +All temperature values are given in millidegree Celsius and will be measurable +only when the target CPU is powered on. + +Sysfs interface +------------------- + +======================= ======================================================= +temp1_label "Die" +temp1_input Provides current die temperature of the CPU package. +temp1_max Provides thermal control temperature of the CPU package + which is also known as Tcontrol. +temp1_crit Provides shutdown temperature of the CPU package which + is also known as the maximum processor junction + temperature, Tjmax or Tprochot. +temp1_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of + the CPU package. + +temp2_label "DTS" +temp2_input Provides current temperature of the CPU package scaled + to match DTS thermal profile. +temp2_max Provides thermal control temperature of the CPU package + which is also known as Tcontrol. +temp2_crit Provides shutdown temperature of the CPU package which + is also known as the maximum processor junction + temperature, Tjmax or Tprochot. +temp2_crit_hyst Provides the hysteresis value from Tcontrol to Tjmax of + the CPU package. + +temp3_label "Tcontrol" +temp3_input Provides current Tcontrol temperature of the CPU + package which is also known as Fan Temperature target. + Indicates the relative value from thermal monitor trip + temperature at which fans should be engaged. +temp3_crit Provides Tcontrol critical value of the CPU package + which is same to Tjmax. + +temp4_label "Tthrottle" +temp4_input Provides current Tthrottle temperature of the CPU + package. Used for throttling temperature. If this value + is allowed and lower than Tjmax - the throttle will + occur and reported at lower than Tjmax. + +temp5_label "Tjmax" +temp5_input Provides the maximum junction temperature, Tjmax of the + CPU package. + +temp[6-N]_label Provides string "Core X", where X is resolved core + number. +temp[6-N]_input Provides current temperature of each core. + +======================= ======================================================= diff --git a/Documentation/hwmon/peci-dimmtemp.rst b/Documentation/hwmon/peci-dimmtemp.rst new file mode 100644 index 000000000000..e562aed620de --- /dev/null +++ b/Documentation/hwmon/peci-dimmtemp.rst @@ -0,0 +1,57 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver peci-dimmtemp +=========================== + +Supported chips: + One of Intel server CPUs listed below which is connected to a PECI bus. + * Intel Xeon E5/E7 v3 server processors + Intel Xeon E5-14xx v3 family + Intel Xeon E5-24xx v3 family + Intel Xeon E5-16xx v3 family + Intel Xeon E5-26xx v3 family + Intel Xeon E5-46xx v3 family + Intel Xeon E7-48xx v3 family + Intel Xeon E7-88xx v3 family + * Intel Xeon E5/E7 v4 server processors + Intel Xeon E5-16xx v4 family + Intel Xeon E5-26xx v4 family + Intel Xeon E5-46xx v4 family + Intel Xeon E7-48xx v4 family + Intel Xeon E7-88xx v4 family + * Intel Xeon Scalable server processors + Intel Xeon D family + Intel Xeon Bronze family + Intel Xeon Silver family + Intel Xeon Gold family + Intel Xeon Platinum family + + Datasheet: Available from http://www.intel.com/design/literature.htm + +Author: Jae Hyun Yoo <jae.hyun.yoo@linux.intel.com> + +Description +----------- + +This driver implements a generic PECI hwmon feature which provides +Temperature sensor on DIMM readings that are accessible via the processor PECI interface. + +All temperature values are given in millidegree Celsius and will be measurable +only when the target CPU is powered on. + +Sysfs interface +------------------- + +======================= ======================================================= + +temp[N]_label Provides string "DIMM CI", where C is DIMM channel and + I is DIMM index of the populated DIMM. +temp[N]_input Provides current temperature of the populated DIMM. +temp[N]_max Provides thermal control temperature of the DIMM. +temp[N]_crit Provides shutdown temperature of the DIMM. + +======================= ======================================================= + +Note: + DIMM temperature attributes will appear when the client CPU's BIOS + completes memory training and testing. diff --git a/Documentation/hwmon/pli1209bc.rst b/Documentation/hwmon/pli1209bc.rst new file mode 100644 index 000000000000..ea5b3f68a515 --- /dev/null +++ b/Documentation/hwmon/pli1209bc.rst @@ -0,0 +1,75 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver pli1209bc +======================= + +Supported chips: + + * Digital Supervisor PLI1209BC + + Prefix: 'pli1209bc' + + Addresses scanned: 0x50 - 0x5F + + Datasheet: https://www.vicorpower.com/documents/datasheets/ds-PLI1209BCxyzz-VICOR.pdf + +Authors: + - Marcello Sylvester Bauer <sylv@sylv.io> + +Description +----------- + +The Vicor PLI1209BC is an isolated digital power system supervisor that provides +a communication interface between a host processor and one Bus Converter Module +(BCM). The PLI communicates with a system controller via a PMBus compatible +interface over an isolated UART interface. Through the PLI, the host processor +can configure, set protection limits, and monitor the BCM. + +Sysfs entries +------------- + +======================= ======================================================== +in1_label "vin2" +in1_input Input voltage. +in1_rated_min Minimum rated input voltage. +in1_rated_max Maximum rated input voltage. +in1_max Maximum input voltage. +in1_max_alarm Input voltage high alarm. +in1_crit Critical input voltage. +in1_crit_alarm Input voltage critical alarm. + +in2_label "vout2" +in2_input Output voltage. +in2_rated_min Minimum rated output voltage. +in2_rated_max Maximum rated output voltage. +in2_alarm Output voltage alarm + +curr1_label "iin2" +curr1_input Input current. +curr1_max Maximum input current. +curr1_max_alarm Maximum input current high alarm. +curr1_crit Critical input current. +curr1_crit_alarm Input current critical alarm. + +curr2_label "iout2" +curr2_input Output current. +curr2_crit Critical output current. +curr2_crit_alarm Output current critical alarm. +curr2_max Maximum output current. +curr2_max_alarm Output current high alarm. + +power1_label "pin2" +power1_input Input power. +power1_alarm Input power alarm. + +power2_label "pout2" +power2_input Output power. +power2_rated_max Maximum rated output power. + +temp1_input Die temperature. +temp1_alarm Die temperature alarm. +temp1_max Maximum die temperature. +temp1_max_alarm Die temperature high alarm. +temp1_crit Critical die temperature. +temp1_crit_alarm Die temperature critical alarm. +======================= ======================================================== diff --git a/Documentation/hwmon/sch5627.rst b/Documentation/hwmon/sch5627.rst index 187682e99114..ecb4fc84d045 100644 --- a/Documentation/hwmon/sch5627.rst +++ b/Documentation/hwmon/sch5627.rst @@ -20,6 +20,10 @@ Description SMSC SCH5627 Super I/O chips include complete hardware monitoring capabilities. They can monitor up to 5 voltages, 4 fans and 8 temperatures. +In addition, the SCH5627 exports data describing which temperature sensors +affect the speed of each fan. Setting pwmX_auto_channels_temp to 0 forces +the corresponding fan to full speed until another value is written. + The SMSC SCH5627 hardware monitoring part also contains an integrated watchdog. In order for this watchdog to function some motherboard specific initialization most be done by the BIOS, so if the watchdog is not enabled diff --git a/Documentation/hwmon/sy7636a-hwmon.rst b/Documentation/hwmon/sy7636a-hwmon.rst new file mode 100644 index 000000000000..c85db7b32941 --- /dev/null +++ b/Documentation/hwmon/sy7636a-hwmon.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0-or-later + +Kernel driver sy7636a-hwmon +=========================== + +Supported chips: + + * Silergy SY7636A PMIC + + +Description +----------- + +This driver adds hardware temperature reading support for +the Silergy SY7636A PMIC. + +The following sensors are supported + + * Temperature + - SoC on-die temperature in milli-degree C + +sysfs-Interface +--------------- + +temp0_input + - SoC on-die temperature (milli-degree C) diff --git a/Documentation/hwmon/sysfs-interface.rst b/Documentation/hwmon/sysfs-interface.rst index 85652a6aaa3e..209626fb2405 100644 --- a/Documentation/hwmon/sysfs-interface.rst +++ b/Documentation/hwmon/sysfs-interface.rst @@ -99,6 +99,10 @@ Global attributes `name` The chip name. +`label` + A descriptive label that allows to uniquely identify a device + within the system. + `update_interval` The interval at which the chip will update readings. diff --git a/Documentation/hwmon/tmp464.rst b/Documentation/hwmon/tmp464.rst new file mode 100644 index 000000000000..7596e7623d06 --- /dev/null +++ b/Documentation/hwmon/tmp464.rst @@ -0,0 +1,73 @@ +.. SPDX-License-Identifier: GPL-2.0 + +Kernel driver tmp464 +==================== + +Supported chips: + + * Texas Instruments TMP464 + + Prefix: 'tmp464' + + Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp464.html + + * Texas Instruments TMP468 + + Prefix: 'tmp468' + + Addresses scanned: I2C 0x48, 0x49, 0x4a and 0x4b + + Datasheet: http://focus.ti.com/docs/prod/folders/print/tmp468.html + +Authors: + + Agathe Porte <agathe.porte@nokia.com> + Guenter Roeck <linux@roeck-us.net> + +Description +----------- + +This driver implements support for Texas Instruments TMP464 and TMP468 +temperature sensor chips. TMP464 provides one local and four remote +sensors. TMP468 provides one local and eight remote sensors. +Temperature is measured in degrees Celsius. The chips are wired over +I2C/SMBus and specified over a temperature range of -40 to +125 degrees +Celsius. Resolution for both the local and remote channels is 0.0625 +degree C. + +The chips support only temperature measurements. The driver exports +temperature values, limits, and alarms via the following sysfs files: + +**temp[1-9]_input** + +**temp[1-9]_max** + +**temp[1-9]_max_hyst** + +**temp[1-9]_max_alarm** + +**temp[1-9]_crit** + +**temp[1-9]_crit_alarm** + +**temp[1-9]_crit_hyst** + +**temp[2-9]_offset** + +**temp[2-9]_fault** + +Each sensor can be individually disabled via Devicetree or from sysfs +via: + +**temp[1-9]_enable** + +If labels were specified in Devicetree, additional sysfs files will +be present: + +**temp[1-9]_label** + +The update interval is configurable with the following sysfs attribute. + +**update_interval** diff --git a/Documentation/hwmon/xdpe12284.rst b/Documentation/hwmon/xdpe12284.rst index 67d1f87808e5..a224dc74ad35 100644 --- a/Documentation/hwmon/xdpe12284.rst +++ b/Documentation/hwmon/xdpe12284.rst @@ -5,6 +5,10 @@ Kernel driver xdpe122 Supported chips: + * Infineon XDPE11280 + + Prefix: 'xdpe11280' + * Infineon XDPE12254 Prefix: 'xdpe12254' @@ -20,10 +24,10 @@ Authors: Description ----------- -This driver implements support for Infineon Multi-phase XDPE122 family -dual loop voltage regulators. -The family includes XDPE12284 and XDPE12254 devices. -The devices from this family complaint with: +This driver implements support for Infineon Multi-phase XDPE112 and XDPE122 +family dual loop voltage regulators. +These families include XDPE11280, XDPE12284 and XDPE12254 devices. +The devices from this family compliant with: - Intel VR13 and VR13HC rev 1.3, IMVP8 rev 1.2 and IMPVP9 rev 1.3 DC-DC converter specification. diff --git a/Documentation/i2c/busses/i2c-i801.rst b/Documentation/i2c/busses/i2c-i801.rst index 42bbdd6e7fd8..cad59170b2ad 100644 --- a/Documentation/i2c/busses/i2c-i801.rst +++ b/Documentation/i2c/busses/i2c-i801.rst @@ -45,6 +45,7 @@ Supported adapters: * Intel Jasper Lake (SOC) * Intel Emmitsburg (PCH) * Intel Alder Lake (PCH) + * Intel Raptor Lake (PCH) Datasheets: Publicly available at the Intel website diff --git a/Documentation/index.rst b/Documentation/index.rst index 2b4de3926858..1988c19d9daf 100644 --- a/Documentation/index.rst +++ b/Documentation/index.rst @@ -138,6 +138,7 @@ needed). scheduler/index mhi/index tty/index + peci/index Architecture-agnostic documentation ----------------------------------- @@ -166,6 +167,7 @@ to ReStructured Text format, or are simply too old. .. toctree:: :maxdepth: 2 + tools/index staging/index watch_queue diff --git a/Documentation/input/event-codes.rst b/Documentation/input/event-codes.rst index b24ae7d292cc..8741d390b184 100644 --- a/Documentation/input/event-codes.rst +++ b/Documentation/input/event-codes.rst @@ -137,7 +137,11 @@ A few EV_KEY codes have special meanings: code should be set to a value of 1. When the tool is no longer interacting with the input device, the BTN_TOOL_<name> code should be reset to 0. All trackpads, tablets, and touchscreens should use at least one BTN_TOOL_<name> - code when events are generated. + code when events are generated. Likewise all trackpads, tablets, and + touchscreens should export only one BTN_TOOL_<name> at a time. To not break + existing userspace, it is recommended to not switch tool in one EV_SYN frame + but first emitting the old BTN_TOOL_<name> at 0, then emit one SYN_REPORT + and then set the new BTN_TOOL_<name> at 1. * BTN_TOUCH: diff --git a/Documentation/kbuild/kbuild.rst b/Documentation/kbuild/kbuild.rst index 2d1fc03d346e..ef19b9c13523 100644 --- a/Documentation/kbuild/kbuild.rst +++ b/Documentation/kbuild/kbuild.rst @@ -77,6 +77,17 @@ HOSTLDLIBS ---------- Additional libraries to link against when building host programs. +.. _userkbuildflags: + +USERCFLAGS +---------- +Additional options used for $(CC) when compiling userprogs. + +USERLDFLAGS +----------- +Additional options used for $(LD) when linking userprogs. userprogs are linked +with CC, so $(USERLDFLAGS) should include "-Wl," prefix as applicable. + KBUILD_KCONFIG -------------- Set the top-level Kconfig file to the value of this environment diff --git a/Documentation/kbuild/llvm.rst b/Documentation/kbuild/llvm.rst index d32616891dcf..b854bb413164 100644 --- a/Documentation/kbuild/llvm.rst +++ b/Documentation/kbuild/llvm.rst @@ -49,17 +49,36 @@ example: :: LLVM Utilities -------------- -LLVM has substitutes for GNU binutils utilities. Kbuild supports ``LLVM=1`` -to enable them. :: - - make LLVM=1 - -They can be enabled individually. The full list of the parameters: :: +LLVM has substitutes for GNU binutils utilities. They can be enabled individually. +The full list of supported make variables:: make CC=clang LD=ld.lld AR=llvm-ar NM=llvm-nm STRIP=llvm-strip \ OBJCOPY=llvm-objcopy OBJDUMP=llvm-objdump READELF=llvm-readelf \ HOSTCC=clang HOSTCXX=clang++ HOSTAR=llvm-ar HOSTLD=ld.lld +To simplify the above command, Kbuild supports the ``LLVM`` variable:: + + make LLVM=1 + +If your LLVM tools are not available in your PATH, you can supply their +location using the LLVM variable with a trailing slash:: + + make LLVM=/path/to/llvm/ + +which will use ``/path/to/llvm/clang``, ``/path/to/llvm/ld.lld``, etc. + +If your LLVM tools have a version suffix and you want to test with that +explicit version rather than the unsuffixed executables like ``LLVM=1``, you +can pass the suffix using the ``LLVM`` variable:: + + make LLVM=-14 + +which will use ``clang-14``, ``ld.lld-14``, etc. + +``LLVM=0`` is not the same as omitting ``LLVM`` altogether, it will behave like +``LLVM=1``. If you only wish to use certain LLVM utilities, use their respective +make variables. + The integrated assembler is enabled by default. You can pass ``LLVM_IAS=0`` to disable it. diff --git a/Documentation/kbuild/makefiles.rst b/Documentation/kbuild/makefiles.rst index b008b90b92c9..11a296e52d68 100644 --- a/Documentation/kbuild/makefiles.rst +++ b/Documentation/kbuild/makefiles.rst @@ -982,6 +982,8 @@ The syntax is quite similar. The difference is to use "userprogs" instead of When linking bpfilter_umh, it will be passed the extra option -static. + From command line, :ref:`USERCFLAGS and USERLDFLAGS <userkbuildflags>` will also be used. + 5.4 When userspace programs are actually built ---------------------------------------------- diff --git a/Documentation/kernel-hacking/locking.rst b/Documentation/kernel-hacking/locking.rst index e6cd40663ea5..4cbd50edf277 100644 --- a/Documentation/kernel-hacking/locking.rst +++ b/Documentation/kernel-hacking/locking.rst @@ -295,7 +295,7 @@ Pete Zaitcev gives the following summary: - If you are in a process context (any syscall) and want to lock other process out, use a mutex. You can take a mutex and sleep - (``copy_from_user*(`` or ``kmalloc(x,GFP_KERNEL)``). + (``copy_from_user()`` or ``kmalloc(x,GFP_KERNEL)``). - Otherwise (== data can be touched in an interrupt), use spin_lock_irqsave() and diff --git a/Documentation/locking/locktypes.rst b/Documentation/locking/locktypes.rst index 4fd7b70fcde1..9933faad4771 100644 --- a/Documentation/locking/locktypes.rst +++ b/Documentation/locking/locktypes.rst @@ -211,9 +211,6 @@ raw_spinlock_t and spinlock_t raw_spinlock_t -------------- -raw_spinlock_t is a strict spinning lock implementation regardless of the -kernel configuration including PREEMPT_RT enabled kernels. - raw_spinlock_t is a strict spinning lock implementation in all kernels, including PREEMPT_RT kernels. Use raw_spinlock_t only in real critical core code, low-level interrupt handling and places where disabling @@ -247,7 +244,7 @@ based on rt_mutex which changes the semantics: Non-PREEMPT_RT kernels disable preemption to get this effect. PREEMPT_RT kernels use a per-CPU lock for serialization which keeps - preemption disabled. The lock disables softirq handlers and also + preemption enabled. The lock disables softirq handlers and also prevents reentrancy due to task preemption. PREEMPT_RT kernels preserve all other spinlock_t semantics: diff --git a/Documentation/maintainer/index.rst b/Documentation/maintainer/index.rst index f0a60435b124..3e03283c144e 100644 --- a/Documentation/maintainer/index.rst +++ b/Documentation/maintainer/index.rst @@ -12,6 +12,7 @@ additions to this manual. configure-git rebasing-and-merging pull-requests + messy-diffstat maintainer-entry-profile modifying-patches diff --git a/Documentation/maintainer/maintainer-entry-profile.rst b/Documentation/maintainer/maintainer-entry-profile.rst index 5d5cc3acdf85..93b2ae6c34a9 100644 --- a/Documentation/maintainer/maintainer-entry-profile.rst +++ b/Documentation/maintainer/maintainer-entry-profile.rst @@ -103,3 +103,4 @@ to do something different in the near future. ../nvdimm/maintainer-entry-profile ../riscv/patch-acceptance ../driver-api/media/maintainer-entry-profile + ../driver-api/vfio-pci-device-specific-driver-acceptance diff --git a/Documentation/maintainer/messy-diffstat.rst b/Documentation/maintainer/messy-diffstat.rst new file mode 100644 index 000000000000..c015f66d7621 --- /dev/null +++ b/Documentation/maintainer/messy-diffstat.rst @@ -0,0 +1,96 @@ +.. SPDX-License-Identifier: GPL-2.0 + +===================================== +Handling messy pull-request diffstats +===================================== + +Subsystem maintainers routinely use ``git request-pull`` as part of the +process of sending work upstream. Normally, the result includes a nice +diffstat that shows which files will be touched and how much of each will +be changed. Occasionally, though, a repository with a relatively +complicated development history will yield a massive diffstat containing a +great deal of unrelated work. The result looks ugly and obscures what the +pull request is actually doing. This document describes what is happening +and how to fix things up; it is derived from The Wisdom of Linus Torvalds, +found in Linus1_ and Linus2_. + +.. _Linus1: https://lore.kernel.org/lkml/CAHk-=wg3wXH2JNxkQi+eLZkpuxqV+wPiHhw_Jf7ViH33Sw7PHA@mail.gmail.com/ +.. _Linus2: https://lore.kernel.org/lkml/CAHk-=wgXbSa8yq8Dht8at+gxb_idnJ7X5qWZQWRBN4_CUPr=eQ@mail.gmail.com/ + +A Git development history proceeds as a series of commits. In a simplified +manner, mainline kernel development looks like this:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + +If one wants to see what has changed between two points, a command like +this will do the job:: + + $ git diff --stat --summary vN-rc2..vN-rc3 + +Here, there are two clear points in the history; Git will essentially +"subtract" the beginning point from the end point and display the resulting +differences. The requested operation is unambiguous and easy enough to +understand. + +When a subsystem maintainer creates a branch and commits changes to it, the +result in the simplest case is a history that looks like:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | + +-- c1 --- c2 --- ... --- cN + +If that maintainer now uses ``git diff`` to see what has changed between +the mainline branch (let's call it "linus") and cN, there are still two +clear endpoints, and the result is as expected. So a pull request +generated with ``git request-pull`` will also be as expected. But now +consider a slightly more complex development history:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | | + | +-- c1 --- c2 --- ... --- cN + | / + +-- x1 --- x2 --- x3 + +Our maintainer has created one branch at vN-rc1 and another at vN-rc2; the +two were then subsequently merged into c2. Now a pull request generated +for cN may end up being messy indeed, and developers often end up wondering +why. + +What is happening here is that there are no longer two clear end points for +the ``git diff`` operation to use. The development culminating in cN +started in two different places; to generate the diffstat, ``git diff`` +ends up having pick one of them and hoping for the best. If the diffstat +starts at vN-rc1, it may end up including all of the changes between there +and the second origin end point (vN-rc2), which is certainly not what our +maintainer had in mind. With all of that extra junk in the diffstat, it +may be impossible to tell what actually happened in the changes leading up +to cN. + +Maintainers often try to resolve this problem by, for example, rebasing the +branch or performing another merge with the linus branch, then recreating +the pull request. This approach tends not to lead to joy at the receiving +end of that pull request; rebasing and/or merging just before pushing +upstream is a well-known way to get a grumpy response. + +So what is to be done? The best response when confronted with this +situation is to indeed to do a merge with the branch you intend your work +to be pulled into, but to do it privately, as if it were the source of +shame. Create a new, throwaway branch and do the merge there:: + + ... vM --- vN-rc1 --- vN-rc2 --- vN-rc3 --- ... --- vN-rc7 --- vN + | | | + | +-- c1 --- c2 --- ... --- cN | + | / | | + +-- x1 --- x2 --- x3 +------------+-- TEMP + +The merge operation resolves all of the complications resulting from the +multiple beginning points, yielding a coherent result that contains only +the differences from the mainline branch. Now it will be possible to +generate a diffstat with the desired information:: + + $ git diff -C --stat --summary linus..TEMP + +Save the output from this command, then simply delete the TEMP branch; +definitely do not expose it to the outside world. Take the saved diffstat +output and edit it into the messy pull request, yielding a result that +shows what is really going on. That request can then be sent upstream. diff --git a/Documentation/networking/bonding.rst b/Documentation/networking/bonding.rst index ab98373535ea..525e6842dd33 100644 --- a/Documentation/networking/bonding.rst +++ b/Documentation/networking/bonding.rst @@ -313,6 +313,17 @@ arp_ip_target maximum number of targets that can be specified is 16. The default value is no IP addresses. +ns_ip6_target + + Specifies the IPv6 addresses to use as IPv6 monitoring peers when + arp_interval is > 0. These are the targets of the NS request + sent to determine the health of the link to the targets. + Specify these values in ffff:ffff::ffff:ffff format. Multiple IPv6 + addresses must be separated by a comma. At least one IPv6 + address must be given for NS/NA monitoring to function. The + maximum number of targets that can be specified is 16. The + default value is no IPv6 addresses. + arp_validate Specifies whether or not ARP probes and replies should be diff --git a/Documentation/networking/devlink/index.rst b/Documentation/networking/devlink/index.rst index 443123772f44..c17cdb079611 100644 --- a/Documentation/networking/devlink/index.rst +++ b/Documentation/networking/devlink/index.rst @@ -4,6 +4,22 @@ Linux Devlink Documentation devlink is an API to expose device information and resources not directly related to any device class, such as chip-wide/switch-ASIC-wide configuration. +Locking +------- + +Driver facing APIs are currently transitioning to allow more explicit +locking. Drivers can use the existing ``devlink_*`` set of APIs, or +new APIs prefixed by ``devl_*``. The older APIs handle all the locking +in devlink core, but don't allow registration of most sub-objects once +the main devlink object is itself registered. The newer ``devl_*`` APIs assume +the devlink instance lock is already held. Drivers can take the instance +lock by calling ``devl_lock()``. It is also held in most of the callbacks. +Eventually all callbacks will be invoked under the devlink instance lock, +refer to the use of the ``DEVLINK_NL_FLAG_NO_LOCK`` flag in devlink core +to find out which callbacks are not converted, yet. + +Drivers are encouraged to use the devlink instance lock for their own needs. + Interface documentation ----------------------- diff --git a/Documentation/networking/dsa/sja1105.rst b/Documentation/networking/dsa/sja1105.rst index 29b1bae0cf00..e0219c1452ab 100644 --- a/Documentation/networking/dsa/sja1105.rst +++ b/Documentation/networking/dsa/sja1105.rst @@ -293,6 +293,33 @@ of dropped frames, which is a sum of frames dropped due to timing violations, lack of destination ports and MTU enforcement checks). Byte-level counters are not available. +Limitations +=========== + +The SJA1105 switch family always performs VLAN processing. When configured as +VLAN-unaware, frames carry a different VLAN tag internally, depending on +whether the port is standalone or under a VLAN-unaware bridge. + +The virtual link keys are always fixed at {MAC DA, VLAN ID, VLAN PCP}, but the +driver asks for the VLAN ID and VLAN PCP when the port is under a VLAN-aware +bridge. Otherwise, it fills in the VLAN ID and PCP automatically, based on +whether the port is standalone or in a VLAN-unaware bridge, and accepts only +"VLAN-unaware" tc-flower keys (MAC DA). + +The existing tc-flower keys that are offloaded using virtual links are no +longer operational after one of the following happens: + +- port was standalone and joins a bridge (VLAN-aware or VLAN-unaware) +- port is part of a bridge whose VLAN awareness state changes +- port was part of a bridge and becomes standalone +- port was standalone, but another port joins a VLAN-aware bridge and this + changes the global VLAN awareness state of the bridge + +The driver cannot veto all these operations, and it cannot update/remove the +existing tc-flower filters either. So for proper operation, the tc-flower +filters should be installed only after the forwarding configuration of the port +has been made, and removed by user space before making any changes to it. + Device Tree bindings and board design ===================================== diff --git a/Documentation/networking/ethtool-netlink.rst b/Documentation/networking/ethtool-netlink.rst index 9d98e0511249..24d9be69065d 100644 --- a/Documentation/networking/ethtool-netlink.rst +++ b/Documentation/networking/ethtool-netlink.rst @@ -860,8 +860,17 @@ Kernel response contents: ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` u8 TCP header / data split + ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ==================================== ====== =========================== +``ETHTOOL_A_RINGS_TCP_DATA_SPLIT`` indicates whether the device is usable with +page-flipping TCP zero-copy receive (``getsockopt(TCP_ZEROCOPY_RECEIVE)``). +If enabled the device is configured to place frame headers and data into +separate buffers. The device configuration must make it possible to receive +full memory pages of data, for example because MTU is high enough or through +HW-GRO. + RINGS_SET ========= @@ -877,6 +886,7 @@ Request contents: ``ETHTOOL_A_RINGS_RX_JUMBO`` u32 size of RX jumbo ring ``ETHTOOL_A_RINGS_TX`` u32 size of TX ring ``ETHTOOL_A_RINGS_RX_BUF_LEN`` u32 size of buffers on the ring + ``ETHTOOL_A_RINGS_CQE_SIZE`` u32 Size of TX/RX CQE ==================================== ====== =========================== Kernel checks that requested ring sizes do not exceed limits reported by @@ -884,6 +894,15 @@ driver. Driver may impose additional constraints and may not suspport all attributes. +``ETHTOOL_A_RINGS_CQE_SIZE`` specifies the completion queue event size. +Completion queue events(CQE) are the events posted by NIC to indicate the +completion status of a packet when the packet is sent(like send success or +error) or received(like pointers to packet fragments). The CQE size parameter +enables to modify the CQE size other than default size if NIC supports it. +A bigger CQE can have more receive buffer pointers inturn NIC can transfer +a bigger frame from wire. Based on the NIC hardware, the overall completion +queue size can be adjusted in the driver if CQE size is modified. + CHANNELS_GET ============ diff --git a/Documentation/networking/index.rst b/Documentation/networking/index.rst index 58bc8cd367c6..72cf33579b78 100644 --- a/Documentation/networking/index.rst +++ b/Documentation/networking/index.rst @@ -1,12 +1,13 @@ Linux Networking Documentation ============================== +Refer to :ref:`netdev-FAQ` for a guide on netdev development process specifics. + Contents: .. toctree:: :maxdepth: 2 - netdev-FAQ af_xdp bareudp batman-adv @@ -96,6 +97,7 @@ Contents: sctp secid seg6-sysctl + smc-sysctl statistics strparser switchdev diff --git a/Documentation/networking/ip-sysctl.rst b/Documentation/networking/ip-sysctl.rst index 2572eecc3e86..b0024aa7b051 100644 --- a/Documentation/networking/ip-sysctl.rst +++ b/Documentation/networking/ip-sysctl.rst @@ -878,6 +878,29 @@ tcp_min_tso_segs - INTEGER Default: 2 +tcp_tso_rtt_log - INTEGER + Adjustment of TSO packet sizes based on min_rtt + + Starting from linux-5.18, TCP autosizing can be tweaked + for flows having small RTT. + + Old autosizing was splitting the pacing budget to send 1024 TSO + per second. + + tso_packet_size = sk->sk_pacing_rate / 1024; + + With the new mechanism, we increase this TSO sizing using: + + distance = min_rtt_usec / (2^tcp_tso_rtt_log) + tso_packet_size += gso_max_size >> distance; + + This means that flows between very close hosts can use bigger + TSO packets, reducing their cpu costs. + + If you want to use the old autosizing, set this sysctl to 0. + + Default: 9 (2^9 = 512 usec) + tcp_pacing_ss_ratio - INTEGER sk->sk_pacing_rate is set by TCP stack using a ratio applied to current rate. (current_rate = cwnd * mss / srtt) diff --git a/Documentation/networking/mctp.rst b/Documentation/networking/mctp.rst index 46f74bffce0f..c628cb5406d2 100644 --- a/Documentation/networking/mctp.rst +++ b/Documentation/networking/mctp.rst @@ -212,6 +212,54 @@ remote address is already known, or the message does not require a reply. Like the send calls, sockets will only receive responses to requests they have sent (TO=1) and may only respond (TO=0) to requests they have received. +``ioctl(SIOCMCTPALLOCTAG)`` and ``ioctl(SIOCMCTPDROPTAG)`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +These tags give applications more control over MCTP message tags, by allocating +(and dropping) tag values explicitly, rather than the kernel automatically +allocating a per-message tag at ``sendmsg()`` time. + +In general, you will only need to use these ioctls if your MCTP protocol does +not fit the usual request/response model. For example, if you need to persist +tags across multiple requests, or a request may generate more than one response. +In these cases, the ioctls allow you to decouple the tag allocation (and +release) from individual message send and receive operations. + +Both ioctls are passed a pointer to a ``struct mctp_ioc_tag_ctl``: + +.. code-block:: C + + struct mctp_ioc_tag_ctl { + mctp_eid_t peer_addr; + __u8 tag; + __u16 flags; + }; + +``SIOCMCTPALLOCTAG`` allocates a tag for a specific peer, which an application +can use in future ``sendmsg()`` calls. The application populates the +``peer_addr`` member with the remote EID. Other fields must be zero. + +On return, the ``tag`` member will be populated with the allocated tag value. +The allocated tag will have the following tag bits set: + + - ``MCTP_TAG_OWNER``: it only makes sense to allocate tags if you're the tag + owner + + - ``MCTP_TAG_PREALLOC``: to indicate to ``sendmsg()`` that this is a + preallocated tag. + + - ... and the actual tag value, within the least-significant three bits + (``MCTP_TAG_MASK``). Note that zero is a valid tag value. + +The tag value should be used as-is for the ``smctp_tag`` member of ``struct +sockaddr_mctp``. + +``SIOCMCTPDROPTAG`` releases a tag that has been previously allocated by a +``SIOCMCTPALLOCTAG`` ioctl. The ``peer_addr`` must be the same as used for the +allocation, and the ``tag`` value must match exactly the tag returned from the +allocation (including the ``MCTP_TAG_OWNER`` and ``MCTP_TAG_PREALLOC`` bits). +The ``flags`` field must be zero. + Kernel internals ================ diff --git a/Documentation/networking/page_pool.rst b/Documentation/networking/page_pool.rst index a147591ce203..5db8c263b0c6 100644 --- a/Documentation/networking/page_pool.rst +++ b/Documentation/networking/page_pool.rst @@ -105,6 +105,47 @@ a page will cause no race conditions is enough. Please note the caller must not use data area after running page_pool_put_page_bulk(), as this function overwrites it. +* page_pool_get_stats(): Retrieve statistics about the page_pool. This API + is only available if the kernel has been configured with + ``CONFIG_PAGE_POOL_STATS=y``. A pointer to a caller allocated ``struct + page_pool_stats`` structure is passed to this API which is filled in. The + caller can then report those stats to the user (perhaps via ethtool, + debugfs, etc.). See below for an example usage of this API. + +Stats API and structures +------------------------ +If the kernel is configured with ``CONFIG_PAGE_POOL_STATS=y``, the API +``page_pool_get_stats()`` and structures described below are available. It +takes a pointer to a ``struct page_pool`` and a pointer to a ``struct +page_pool_stats`` allocated by the caller. + +The API will fill in the provided ``struct page_pool_stats`` with +statistics about the page_pool. + +The stats structure has the following fields:: + + struct page_pool_stats { + struct page_pool_alloc_stats alloc_stats; + struct page_pool_recycle_stats recycle_stats; + }; + + +The ``struct page_pool_alloc_stats`` has the following fields: + * ``fast``: successful fast path allocations + * ``slow``: slow path order-0 allocations + * ``slow_high_order``: slow path high order allocations + * ``empty``: ptr ring is empty, so a slow path allocation was forced. + * ``refill``: an allocation which triggered a refill of the cache + * ``waive``: pages obtained from the ptr ring that cannot be added to + the cache due to a NUMA mismatch. + +The ``struct page_pool_recycle_stats`` has the following fields: + * ``cached``: recycling placed page in the page pool cache + * ``cache_full``: page pool cache was full + * ``ring``: page placed into the ptr ring + * ``ring_full``: page released from page pool because the ptr ring was full + * ``released_refcnt``: page released (and not recycled) because refcnt > 1 + Coding examples =============== @@ -157,6 +198,21 @@ NAPI poller } } +Stats +----- + +.. code-block:: c + + #ifdef CONFIG_PAGE_POOL_STATS + /* retrieve stats */ + struct page_pool_stats stats = { 0 }; + if (page_pool_get_stats(page_pool, &stats)) { + /* perhaps the driver reports statistics with ethool */ + ethtool_print_allocation_stats(&stats.alloc_stats); + ethtool_print_recycle_stats(&stats.recycle_stats); + } + #endif + Driver unload ------------- diff --git a/Documentation/networking/smc-sysctl.rst b/Documentation/networking/smc-sysctl.rst new file mode 100644 index 000000000000..0987fd1bc220 --- /dev/null +++ b/Documentation/networking/smc-sysctl.rst @@ -0,0 +1,23 @@ +.. SPDX-License-Identifier: GPL-2.0 + +========== +SMC Sysctl +========== + +/proc/sys/net/smc/* Variables +============================= + +autocorking_size - INTEGER + Setting SMC auto corking size: + SMC auto corking is like TCP auto corking from the application's + perspective of view. When applications do consecutive small + write()/sendmsg() system calls, we try to coalesce these small writes + as much as possible, to lower total amount of CDC and RDMA Write been + sent. + autocorking_size limits the maximum corked bytes that can be sent to + the under device in 1 single sending. If set to 0, the SMC auto corking + is disabled. + Applications can still use TCP_CORK for optimal behavior when they + know how/when to uncork their sockets. + + Default: 64K diff --git a/Documentation/networking/timestamping.rst b/Documentation/networking/timestamping.rst index f5809206eb93..be4eb1242057 100644 --- a/Documentation/networking/timestamping.rst +++ b/Documentation/networking/timestamping.rst @@ -668,7 +668,7 @@ timestamping: (through another RX timestamping FIFO). Deferral on RX is typically necessary when retrieving the timestamp needs a sleepable context. In that case, it is the responsibility of the DSA driver to call - ``netif_rx_ni()`` on the freshly timestamped skb. + ``netif_rx()`` on the freshly timestamped skb. 3.2.2 Ethernet PHYs ^^^^^^^^^^^^^^^^^^^ diff --git a/Documentation/peci/index.rst b/Documentation/peci/index.rst new file mode 100644 index 000000000000..989de10416e7 --- /dev/null +++ b/Documentation/peci/index.rst @@ -0,0 +1,16 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +==================== +Linux PECI Subsystem +==================== + +.. toctree:: + + peci + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/peci/peci.rst b/Documentation/peci/peci.rst new file mode 100644 index 000000000000..331b1ec00e22 --- /dev/null +++ b/Documentation/peci/peci.rst @@ -0,0 +1,51 @@ +.. SPDX-License-Identifier: GPL-2.0-only + +======== +Overview +======== + +The Platform Environment Control Interface (PECI) is a communication +interface between Intel processor and management controllers +(e.g. Baseboard Management Controller, BMC). +PECI provides services that allow the management controller to +configure, monitor and debug platform by accessing various registers. +It defines a dedicated command protocol, where the management +controller is acting as a PECI originator and the processor - as +a PECI responder. +PECI can be used in both single processor and multiple-processor based +systems. + +NOTE: +Intel PECI specification is not released as a dedicated document, +instead it is a part of External Design Specification (EDS) for given +Intel CPU. External Design Specifications are usually not publicly +available. + +PECI Wire +--------- + +PECI Wire interface uses a single wire for self-clocking and data +transfer. It does not require any additional control lines - the +physical layer is a self-clocked one-wire bus signal that begins each +bit with a driven, rising edge from an idle near zero volts. The +duration of the signal driven high allows to determine whether the bit +value is logic '0' or logic '1'. PECI Wire also includes variable data +rate established with every message. + +For PECI Wire, each processor package will utilize unique, fixed +addresses within a defined range and that address should +have a fixed relationship with the processor socket ID - if one of the +processors is removed, it does not affect addresses of remaining +processors. + +PECI subsystem internals +------------------------ + +.. kernel-doc:: include/linux/peci.h +.. kernel-doc:: drivers/peci/internal.h +.. kernel-doc:: drivers/peci/core.c +.. kernel-doc:: drivers/peci/request.c + +PECI CPU Driver API +------------------- +.. kernel-doc:: drivers/peci/cpu.c diff --git a/Documentation/power/energy-model.rst b/Documentation/power/energy-model.rst index 5ac62a7b4b7c..49549aab41b4 100644 --- a/Documentation/power/energy-model.rst +++ b/Documentation/power/energy-model.rst @@ -113,6 +113,16 @@ to: return warning/error, stop working or panic. See Section 3. for an example of driver implementing this callback, or Section 2.4 for further documentation on this API +Registration of EM using DT +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The EM can also be registered using OPP framework and information in DT +"operating-points-v2". Each OPP entry in DT can be extended with a property +"opp-microwatt" containing micro-Watts power value. This OPP DT property +allows a platform to register EM power values which are reflecting total power +(static + dynamic). These power values might be coming directly from +experiments and measurements. + Registration of 'simple' EM ~~~~~~~~~~~~~~~~~~~~~~~~~~~ diff --git a/Documentation/process/applying-patches.rst b/Documentation/process/applying-patches.rst index c2121c1e55d7..c269f5e1a0a3 100644 --- a/Documentation/process/applying-patches.rst +++ b/Documentation/process/applying-patches.rst @@ -249,6 +249,10 @@ The 5.x.y (-stable) and 5.x patches live at https://www.kernel.org/pub/linux/kernel/v5.x/ +The 5.x.y incremental patches live at + + https://www.kernel.org/pub/linux/kernel/v5.x/incr/ + The -rc patches are not stored on the webserver but are generated on demand from git tags such as @@ -308,12 +312,11 @@ versions. If no 5.x.y kernel is available, then the highest numbered 5.x kernel is the current stable kernel. -.. note:: +The -stable team provides normal as well as incremental patches. Below is +how to apply these patches. - The -stable team usually do make incremental patches available as well - as patches against the latest mainline release, but I only cover the - non-incremental ones below. The incremental ones can be found at - https://www.kernel.org/pub/linux/kernel/v5.x/incr/ +Normal patches +~~~~~~~~~~~~~~ These patches are not incremental, meaning that for example the 5.7.3 patch does not apply on top of the 5.7.2 kernel source, but rather on top @@ -331,6 +334,21 @@ Here's a small example:: $ cd .. $ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir +Incremental patches +~~~~~~~~~~~~~~~~~~~ + +Incremental patches are different: instead of being applied on top +of base 5.x kernel, they are applied on top of previous stable kernel +(5.x.y-1). + +Here's the example to apply these:: + + $ cd ~/linux-5.7.2 # change to the kernel source dir + $ patch -p1 < ../patch-5.7.2-3 # apply the new 5.7.3 patch + $ cd .. + $ mv linux-5.7.2 linux-5.7.3 # rename the kernel source dir + + The -rc kernels =============== diff --git a/Documentation/process/deprecated.rst b/Documentation/process/deprecated.rst index 388cb19f5dbb..a6e36d9c3d14 100644 --- a/Documentation/process/deprecated.rst +++ b/Documentation/process/deprecated.rst @@ -71,6 +71,9 @@ Instead, the 2-factor form of the allocator should be used:: foo = kmalloc_array(count, size, GFP_KERNEL); +Specifically, kmalloc() can be replaced with kmalloc_array(), and +kzalloc() can be replaced with kcalloc(). + If no 2-factor form is available, the saturate-on-overflow helpers should be used:: @@ -91,9 +94,20 @@ Instead, use the helper:: array usage and switch to a `flexible array member <#zero-length-and-one-element-arrays>`_ instead. -See array_size(), array3_size(), and struct_size(), -for more details as well as the related check_add_overflow() and -check_mul_overflow() family of functions. +For other calculations, please compose the use of the size_mul(), +size_add(), and size_sub() helpers. For example, in the case of:: + + foo = krealloc(current_size + chunk_size * (count - 3), GFP_KERNEL); + +Instead, use the helpers:: + + foo = krealloc(size_add(current_size, + size_mul(chunk_size, + size_sub(count, 3))), GFP_KERNEL); + +For more details, also see array3_size() and flex_array_size(), +as well as the related check_mul_overflow(), check_add_overflow(), +check_sub_overflow(), and check_shl_overflow() family of functions. simple_strtol(), simple_strtoll(), simple_strtoul(), simple_strtoull() ---------------------------------------------------------------------- diff --git a/Documentation/process/handling-regressions.rst b/Documentation/process/handling-regressions.rst new file mode 100644 index 000000000000..abb741b1aeee --- /dev/null +++ b/Documentation/process/handling-regressions.rst @@ -0,0 +1,746 @@ +.. SPDX-License-Identifier: (GPL-2.0+ OR CC-BY-4.0) +.. See the bottom of this file for additional redistribution information. + +Handling regressions +++++++++++++++++++++ + +*We don't cause regressions* -- this document describes what this "first rule of +Linux kernel development" means in practice for developers. It complements +Documentation/admin-guide/reporting-regressions.rst, which covers the topic from a +user's point of view; if you never read that text, go and at least skim over it +before continuing here. + +The important bits (aka "The TL;DR") +==================================== + +#. Ensure subscribers of the `regression mailing list <https://lore.kernel.org/regressions/>`_ + (regressions@lists.linux.dev) quickly become aware of any new regression + report: + + * When receiving a mailed report that did not CC the list, bring it into the + loop by immediately sending at least a brief "Reply-all" with the list + CCed. + + * Forward or bounce any reports submitted in bug trackers to the list. + +#. Make the Linux kernel regression tracking bot "regzbot" track the issue (this + is optional, but recommended): + + * For mailed reports, check if the reporter included a line like ``#regzbot + introduced v5.13..v5.14-rc1``. If not, send a reply (with the regressions + list in CC) containing a paragraph like the following, which tells regzbot + when the issue started to happen:: + + #regzbot ^introduced 1f2e3d4c5b6a + + * When forwarding reports from a bug tracker to the regressions list (see + above), include a paragraph like the following:: + + #regzbot introduced: v5.13..v5.14-rc1 + #regzbot from: Some N. Ice Human <some.human@example.com> + #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789 + +#. When submitting fixes for regressions, add "Link:" tags to the patch + description pointing to all places where the issue was reported, as + mandated by Documentation/process/submitting-patches.rst and + :ref:`Documentation/process/5.Posting.rst <development_posting>`. + +#. Try to fix regressions quickly once the culprit has been identified; fixes + for most regressions should be merged within two weeks, but some need to be + resolved within two or three days. + + +All the details on Linux kernel regressions relevant for developers +=================================================================== + + +The important basics in more detail +----------------------------------- + + +What to do when receiving regression reports +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ensure the Linux kernel's regression tracker and others subscribers of the +`regression mailing list <https://lore.kernel.org/regressions/>`_ +(regressions@lists.linux.dev) become aware of any newly reported regression: + + * When you receive a report by mail that did not CC the list, immediately bring + it into the loop by sending at least a brief "Reply-all" with the list CCed; + try to ensure it gets CCed again in case you reply to a reply that omitted + the list. + + * If a report submitted in a bug tracker hits your Inbox, forward or bounce it + to the list. Consider checking the list archives beforehand, if the reporter + already forwarded the report as instructed by + Documentation/admin-guide/reporting-issues.rst. + +When doing either, consider making the Linux kernel regression tracking bot +"regzbot" immediately start tracking the issue: + + * For mailed reports, check if the reporter included a "regzbot command" like + ``#regzbot introduced 1f2e3d4c5b6a``. If not, send a reply (with the + regressions list in CC) with a paragraph like the following::: + + #regzbot ^introduced: v5.13..v5.14-rc1 + + This tells regzbot the version range in which the issue started to happen; + you can specify a range using commit-ids as well or state a single commit-id + in case the reporter bisected the culprit. + + Note the caret (^) before the "introduced": it tells regzbot to treat the + parent mail (the one you reply to) as the initial report for the regression + you want to see tracked; that's important, as regzbot will later look out + for patches with "Link:" tags pointing to the report in the archives on + lore.kernel.org. + + * When forwarding a regressions reported to a bug tracker, include a paragraph + with these regzbot commands:: + + #regzbot introduced: 1f2e3d4c5b6a + #regzbot from: Some N. Ice Human <some.human@example.com> + #regzbot monitor: http://some.bugtracker.example.com/ticket?id=123456789 + + Regzbot will then automatically associate patches with the report that + contain "Link:" tags pointing to your mail or the mentioned ticket. + +What's important when fixing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You don't need to do anything special when submitting fixes for regression, just +remember to do what Documentation/process/submitting-patches.rst, +:ref:`Documentation/process/5.Posting.rst <development_posting>`, and +Documentation/process/stable-kernel-rules.rst already explain in more detail: + + * Point to all places where the issue was reported using "Link:" tags:: + + Link: https://lore.kernel.org/r/30th.anniversary.repost@klaava.Helsinki.FI/ + Link: https://bugzilla.kernel.org/show_bug.cgi?id=1234567890 + + * Add a "Fixes:" tag to specify the commit causing the regression. + + * If the culprit was merged in an earlier development cycle, explicitly mark + the fix for backporting using the ``Cc: stable@vger.kernel.org`` tag. + +All this is expected from you and important when it comes to regression, as +these tags are of great value for everyone (you included) that might be looking +into the issue weeks, months, or years later. These tags are also crucial for +tools and scripts used by other kernel developers or Linux distributions; one of +these tools is regzbot, which heavily relies on the "Link:" tags to associate +reports for regression with changes resolving them. + +Prioritize work on fixing regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +You should fix any reported regression as quickly as possible, to provide +affected users with a solution in a timely manner and prevent more users from +running into the issue; nevertheless developers need to take enough time and +care to ensure regression fixes do not cause additional damage. + +In the end though, developers should give their best to prevent users from +running into situations where a regression leaves them only three options: "run +a kernel with a regression that seriously impacts usage", "continue running an +outdated and thus potentially insecure kernel version for more than two weeks +after a regression's culprit was identified", and "downgrade to a still +supported kernel series that lack required features". + +How to realize this depends a lot on the situation. Here are a few rules of +thumb for you, in order or importance: + + * Prioritize work on handling regression reports and fixing regression over all + other Linux kernel work, unless the latter concerns acute security issues or + bugs causing data loss or damage. + + * Always consider reverting the culprit commits and reapplying them later + together with necessary fixes, as this might be the least dangerous and + quickest way to fix a regression. + + * Developers should handle regressions in all supported kernel series, but are + free to delegate the work to the stable team, if the issue probably at no + point in time occurred with mainline. + + * Try to resolve any regressions introduced in the current development before + its end. If you fear a fix might be too risky to apply only days before a new + mainline release, let Linus decide: submit the fix separately to him as soon + as possible with the explanation of the situation. He then can make a call + and postpone the release if necessary, for example if multiple such changes + show up in his inbox. + + * Address regressions in stable, longterm, or proper mainline releases with + more urgency than regressions in mainline pre-releases. That changes after + the release of the fifth pre-release, aka "-rc5": mainline then becomes as + important, to ensure all the improvements and fixes are ideally tested + together for at least one week before Linus releases a new mainline version. + + * Fix regressions within two or three days, if they are critical for some + reason -- for example, if the issue is likely to affect many users of the + kernel series in question on all or certain architectures. Note, this + includes mainline, as issues like compile errors otherwise might prevent many + testers or continuous integration systems from testing the series. + + * Aim to fix regressions within one week after the culprit was identified, if + the issue was introduced in either: + + * a recent stable/longterm release + + * the development cycle of the latest proper mainline release + + In the latter case (say Linux v5.14), try to address regressions even + quicker, if the stable series for the predecessor (v5.13) will be abandoned + soon or already was stamped "End-of-Life" (EOL) -- this usually happens about + three to four weeks after a new mainline release. + + * Try to fix all other regressions within two weeks after the culprit was + found. Two or three additional weeks are acceptable for performance + regressions and other issues which are annoying, but don't prevent anyone + from running Linux (unless it's an issue in the current development cycle, + as those should ideally be addressed before the release). A few weeks in + total are acceptable if a regression can only be fixed with a risky change + and at the same time is affecting only a few users; as much time is + also okay if the regression is already present in the second newest longterm + kernel series. + +Note: The aforementioned time frames for resolving regressions are meant to +include getting the fix tested, reviewed, and merged into mainline, ideally with +the fix being in linux-next at least briefly. This leads to delays you need to +account for. + +Subsystem maintainers are expected to assist in reaching those periods by doing +timely reviews and quick handling of accepted patches. They thus might have to +send git-pull requests earlier or more often than usual; depending on the fix, +it might even be acceptable to skip testing in linux-next. Especially fixes for +regressions in stable and longterm kernels need to be handled quickly, as fixes +need to be merged in mainline before they can be backported to older series. + + +More aspects regarding regressions developers should be aware of +---------------------------------------------------------------- + + +How to deal with changes where a risk of regression is known +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Evaluate how big the risk of regressions is, for example by performing a code +search in Linux distributions and Git forges. Also consider asking other +developers or projects likely to be affected to evaluate or even test the +proposed change; if problems surface, maybe some solution acceptable for all +can be found. + +If the risk of regressions in the end seems to be relatively small, go ahead +with the change, but let all involved parties know about the risk. Hence, make +sure your patch description makes this aspect obvious. Once the change is +merged, tell the Linux kernel's regression tracker and the regressions mailing +list about the risk, so everyone has the change on the radar in case reports +trickle in. Depending on the risk, you also might want to ask the subsystem +maintainer to mention the issue in his mainline pull request. + +What else is there to known about regressions? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check out Documentation/admin-guide/reporting-regressions.rst, it covers a lot +of other aspects you want might want to be aware of: + + * the purpose of the "no regressions rule" + + * what issues actually qualify as regression + + * who's in charge for finding the root cause of a regression + + * how to handle tricky situations, e.g. when a regression is caused by a + security fix or when fixing a regression might cause another one + +Whom to ask for advice when it comes to regressions +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Send a mail to the regressions mailing list (regressions@lists.linux.dev) while +CCing the Linux kernel's regression tracker (regressions@leemhuis.info); if the +issue might better be dealt with in private, feel free to omit the list. + + +More about regression tracking and regzbot +------------------------------------------ + + +Why the Linux kernel has a regression tracker, and why is regzbot used? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Rules like "no regressions" need someone to ensure they are followed, otherwise +they are broken either accidentally or on purpose. History has shown this to be +true for the Linux kernel as well. That's why Thorsten Leemhuis volunteered to +keep an eye on things as the Linux kernel's regression tracker, who's +occasionally helped by other people. Neither of them are paid to do this, +that's why regression tracking is done on a best effort basis. + +Earlier attempts to manually track regressions have shown it's an exhausting and +frustrating work, which is why they were abandoned after a while. To prevent +this from happening again, Thorsten developed regzbot to facilitate the work, +with the long term goal to automate regression tracking as much as possible for +everyone involved. + +How does regression tracking work with regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot watches for replies to reports of tracked regressions. Additionally, +it's looking out for posted or committed patches referencing such reports +with "Link:" tags; replies to such patch postings are tracked as well. +Combined this data provides good insights into the current state of the fixing +process. + +Regzbot tries to do its job with as little overhead as possible for both +reporters and developers. In fact, only reporters are burdened with an extra +duty: they need to tell regzbot about the regression report using the ``#regzbot +introduced`` command outlined above; if they don't do that, someone else can +take care of that using ``#regzbot ^introduced``. + +For developers there normally is no extra work involved, they just need to make +sure to do something that was expected long before regzbot came to light: add +"Link:" tags to the patch description pointing to all reports about the issue +fixed. + +Do I have to use regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~ + +It's in the interest of everyone if you do, as kernel maintainers like Linus +Torvalds partly rely on regzbot's tracking in their work -- for example when +deciding to release a new version or extend the development phase. For this they +need to be aware of all unfixed regression; to do that, Linus is known to look +into the weekly reports sent by regzbot. + +Do I have to tell regzbot about every regression I stumble upon? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Ideally yes: we are all humans and easily forget problems when something more +important unexpectedly comes up -- for example a bigger problem in the Linux +kernel or something in real life that's keeping us away from keyboards for a +while. Hence, it's best to tell regzbot about every regression, except when you +immediately write a fix and commit it to a tree regularly merged to the affected +kernel series. + +How to see which regressions regzbot tracks currently? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Check `regzbot's web-interface <https://linux-regtracking.leemhuis.info/regzbot/>`_ +for the latest info; alternatively, `search for the latest regression report +<https://lore.kernel.org/lkml/?q=%22Linux+regressions+report%22+f%3Aregzbot>`_, +which regzbot normally sends out once a week on Sunday evening (UTC), which is a +few hours before Linus usually publishes new (pre-)releases. + +What places is regzbot monitoring? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Regzbot is watching the most important Linux mailing lists as well as the git +repositories of linux-next, mainline, and stable/longterm. + +What kind of issues are supposed to be tracked by regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +The bot is meant to track regressions, hence please don't involve regzbot for +regular issues. But it's okay for the Linux kernel's regression tracker if you +use regzbot to track severe issues, like reports about hangs, corrupted data, +or internal errors (Panic, Oops, BUG(), warning, ...). + +Can I add regressions found by CI systems to regzbot's tracking? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +Feel free to do so, if the particular regression likely has impact on practical +use cases and thus might be noticed by users; hence, please don't involve +regzbot for theoretical regressions unlikely to show themselves in real world +usage. + +How to interact with regzbot? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +By using a 'regzbot command' in a direct or indirect reply to the mail with the +regression report. These commands need to be in their own paragraph (IOW: they +need to be separated from the rest of the mail using blank lines). + +One such command is ``#regzbot introduced <version or commit>``, which makes +regzbot consider your mail as a regressions report added to the tracking, as +already described above; ``#regzbot ^introduced <version or commit>`` is another +such command, which makes regzbot consider the parent mail as a report for a +regression which it starts to track. + +Once one of those two commands has been utilized, other regzbot commands can be +used in direct or indirect replies to the report. You can write them below one +of the `introduced` commands or in replies to the mail that used one of them +or itself is a reply to that mail: + + * Set or update the title:: + + #regzbot title: foo + + * Monitor a discussion or bugzilla.kernel.org ticket where additions aspects of + the issue or a fix are discussed -- for example the posting of a patch fixing + the regression:: + + #regzbot monitor: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/ + + Monitoring only works for lore.kernel.org and bugzilla.kernel.org; regzbot + will consider all messages in that thread or ticket as related to the fixing + process. + + * Point to a place with further details of interest, like a mailing list post + or a ticket in a bug tracker that are slightly related, but about a different + topic:: + + #regzbot link: https://bugzilla.kernel.org/show_bug.cgi?id=123456789 + + * Mark a regression as fixed by a commit that is heading upstream or already + landed:: + + #regzbot fixed-by: 1f2e3d4c5d + + * Mark a regression as a duplicate of another one already tracked by regzbot:: + + #regzbot dup-of: https://lore.kernel.org/all/30th.anniversary.repost@klaava.Helsinki.FI/ + + * Mark a regression as invalid:: + + #regzbot invalid: wasn't a regression, problem has always existed + +Is there more to tell about regzbot and its commands? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +More detailed and up-to-date information about the Linux +kernel's regression tracking bot can be found on its +`project page <https://gitlab.com/knurd42/regzbot>`_, which among others +contains a `getting started guide <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/getting_started.md>`_ +and `reference documentation <https://gitlab.com/knurd42/regzbot/-/blob/main/docs/reference.md>`_ +which both cover more details than the above section. + +Quotes from Linus about regression +---------------------------------- + +Find below a few real life examples of how Linus Torvalds expects regressions to +be handled: + + * From `2017-10-26 (1/2) + <https://lore.kernel.org/lkml/CA+55aFwiiQYJ+YoLKCXjN_beDVfu38mg=Ggg5LFOcqHE8Qi7Zw@mail.gmail.com/>`_:: + + If you break existing user space setups THAT IS A REGRESSION. + + It's not ok to say "but we'll fix the user space setup". + + Really. NOT OK. + + [...] + + The first rule is: + + - we don't cause regressions + + and the corollary is that when regressions *do* occur, we admit to + them and fix them, instead of blaming user space. + + The fact that you have apparently been denying the regression now for + three weeks means that I will revert, and I will stop pulling apparmor + requests until the people involved understand how kernel development + is done. + + * From `2017-10-26 (2/2) + <https://lore.kernel.org/lkml/CA+55aFxW7NMAMvYhkvz1UPbUTUJewRt6Yb51QAx5RtrWOwjebg@mail.gmail.com/>`_:: + + People should basically always feel like they can update their kernel + and simply not have to worry about it. + + I refuse to introduce "you can only update the kernel if you also + update that other program" kind of limitations. If the kernel used to + work for you, the rule is that it continues to work for you. + + There have been exceptions, but they are few and far between, and they + generally have some major and fundamental reasons for having happened, + that were basically entirely unavoidable, and people _tried_hard_ to + avoid them. Maybe we can't practically support the hardware any more + after it is decades old and nobody uses it with modern kernels any + more. Maybe there's a serious security issue with how we did things, + and people actually depended on that fundamentally broken model. Maybe + there was some fundamental other breakage that just _had_ to have a + flag day for very core and fundamental reasons. + + And notice that this is very much about *breaking* peoples environments. + + Behavioral changes happen, and maybe we don't even support some + feature any more. There's a number of fields in /proc/<pid>/stat that + are printed out as zeroes, simply because they don't even *exist* in + the kernel any more, or because showing them was a mistake (typically + an information leak). But the numbers got replaced by zeroes, so that + the code that used to parse the fields still works. The user might not + see everything they used to see, and so behavior is clearly different, + but things still _work_, even if they might no longer show sensitive + (or no longer relevant) information. + + But if something actually breaks, then the change must get fixed or + reverted. And it gets fixed in the *kernel*. Not by saying "well, fix + your user space then". It was a kernel change that exposed the + problem, it needs to be the kernel that corrects for it, because we + have a "upgrade in place" model. We don't have a "upgrade with new + user space". + + And I seriously will refuse to take code from people who do not + understand and honor this very simple rule. + + This rule is also not going to change. + + And yes, I realize that the kernel is "special" in this respect. I'm + proud of it. + + I have seen, and can point to, lots of projects that go "We need to + break that use case in order to make progress" or "you relied on + undocumented behavior, it sucks to be you" or "there's a better way to + do what you want to do, and you have to change to that new better + way", and I simply don't think that's acceptable outside of very early + alpha releases that have experimental users that know what they signed + up for. The kernel hasn't been in that situation for the last two + decades. + + We do API breakage _inside_ the kernel all the time. We will fix + internal problems by saying "you now need to do XYZ", but then it's + about internal kernel API's, and the people who do that then also + obviously have to fix up all the in-kernel users of that API. Nobody + can say "I now broke the API you used, and now _you_ need to fix it + up". Whoever broke something gets to fix it too. + + And we simply do not break user space. + + * From `2020-05-21 + <https://lore.kernel.org/all/CAHk-=wiVi7mSrsMP=fLXQrXK_UimybW=ziLOwSzFTtoXUacWVQ@mail.gmail.com/>`_:: + + The rules about regressions have never been about any kind of + documented behavior, or where the code lives. + + The rules about regressions are always about "breaks user workflow". + + Users are literally the _only_ thing that matters. + + No amount of "you shouldn't have used this" or "that behavior was + undefined, it's your own fault your app broke" or "that used to work + simply because of a kernel bug" is at all relevant. + + Now, reality is never entirely black-and-white. So we've had things + like "serious security issue" etc that just forces us to make changes + that may break user space. But even then the rule is that we don't + really have other options that would allow things to continue. + + And obviously, if users take years to even notice that something + broke, or if we have sane ways to work around the breakage that + doesn't make for too much trouble for users (ie "ok, there are a + handful of users, and they can use a kernel command line to work + around it" kind of things) we've also been a bit less strict. + + But no, "that was documented to be broken" (whether it's because the + code was in staging or because the man-page said something else) is + irrelevant. If staging code is so useful that people end up using it, + that means that it's basically regular kernel code with a flag saying + "please clean this up". + + The other side of the coin is that people who talk about "API + stability" are entirely wrong. API's don't matter either. You can make + any changes to an API you like - as long as nobody notices. + + Again, the regression rule is not about documentation, not about + API's, and not about the phase of the moon. + + It's entirely about "we caused problems for user space that used to work". + + * From `2017-11-05 + <https://lore.kernel.org/all/CA+55aFzUvbGjD8nQ-+3oiMBx14c_6zOj2n7KLN3UsJ-qsd4Dcw@mail.gmail.com/>`_:: + + And our regression rule has never been "behavior doesn't change". + That would mean that we could never make any changes at all. + + For example, we do things like add new error handling etc all the + time, which we then sometimes even add tests for in our kselftest + directory. + + So clearly behavior changes all the time and we don't consider that a + regression per se. + + The rule for a regression for the kernel is that some real user + workflow breaks. Not some test. Not a "look, I used to be able to do + X, now I can't". + + * From `2018-08-03 + <https://lore.kernel.org/all/CA+55aFwWZX=CXmWDTkDGb36kf12XmTehmQjbiMPCqCRG2hi9kw@mail.gmail.com/>`_:: + + YOU ARE MISSING THE #1 KERNEL RULE. + + We do not regress, and we do not regress exactly because your are 100% wrong. + + And the reason you state for your opinion is in fact exactly *WHY* you + are wrong. + + Your "good reasons" are pure and utter garbage. + + The whole point of "we do not regress" is so that people can upgrade + the kernel and never have to worry about it. + + > Kernel had a bug which has been fixed + + That is *ENTIRELY* immaterial. + + Guys, whether something was buggy or not DOES NOT MATTER. + + Why? + + Bugs happen. That's a fact of life. Arguing that "we had to break + something because we were fixing a bug" is completely insane. We fix + tens of bugs every single day, thinking that "fixing a bug" means that + we can break something is simply NOT TRUE. + + So bugs simply aren't even relevant to the discussion. They happen, + they get found, they get fixed, and it has nothing to do with "we + break users". + + Because the only thing that matters IS THE USER. + + How hard is that to understand? + + Anybody who uses "but it was buggy" as an argument is entirely missing + the point. As far as the USER was concerned, it wasn't buggy - it + worked for him/her. + + Maybe it worked *because* the user had taken the bug into account, + maybe it worked because the user didn't notice - again, it doesn't + matter. It worked for the user. + + Breaking a user workflow for a "bug" is absolutely the WORST reason + for breakage you can imagine. + + It's basically saying "I took something that worked, and I broke it, + but now it's better". Do you not see how f*cking insane that statement + is? + + And without users, your program is not a program, it's a pointless + piece of code that you might as well throw away. + + Seriously. This is *why* the #1 rule for kernel development is "we + don't break users". Because "I fixed a bug" is absolutely NOT AN + ARGUMENT if that bug fix broke a user setup. You actually introduced a + MUCH BIGGER bug by "fixing" something that the user clearly didn't + even care about. + + And dammit, we upgrade the kernel ALL THE TIME without upgrading any + other programs at all. It is absolutely required, because flag-days + and dependencies are horribly bad. + + And it is also required simply because I as a kernel developer do not + upgrade random other tools that I don't even care about as I develop + the kernel, and I want any of my users to feel safe doing the same + time. + + So no. Your rule is COMPLETELY wrong. If you cannot upgrade a kernel + without upgrading some other random binary, then we have a problem. + + * From `2021-06-05 + <https://lore.kernel.org/all/CAHk-=wiUVqHN76YUwhkjZzwTdjMMJf_zN4+u7vEJjmEGh3recw@mail.gmail.com/>`_:: + + THERE ARE NO VALID ARGUMENTS FOR REGRESSIONS. + + Honestly, security people need to understand that "not working" is not + a success case of security. It's a failure case. + + Yes, "not working" may be secure. But security in that case is *pointless*. + + * From `2011-05-06 (1/3) + <https://lore.kernel.org/all/BANLkTim9YvResB+PwRp7QTK-a5VNg2PvmQ@mail.gmail.com/>`_:: + + Binary compatibility is more important. + + And if binaries don't use the interface to parse the format (or just + parse it wrongly - see the fairly recent example of adding uuid's to + /proc/self/mountinfo), then it's a regression. + + And regressions get reverted, unless there are security issues or + similar that makes us go "Oh Gods, we really have to break things". + + I don't understand why this simple logic is so hard for some kernel + developers to understand. Reality matters. Your personal wishes matter + NOT AT ALL. + + If you made an interface that can be used without parsing the + interface description, then we're stuck with the interface. Theory + simply doesn't matter. + + You could help fix the tools, and try to avoid the compatibility + issues that way. There aren't that many of them. + + From `2011-05-06 (2/3) + <https://lore.kernel.org/all/BANLkTi=KVXjKR82sqsz4gwjr+E0vtqCmvA@mail.gmail.com/>`_:: + + it's clearly NOT an internal tracepoint. By definition. It's being + used by powertop. + + From `2011-05-06 (3/3) + <https://lore.kernel.org/all/BANLkTinazaXRdGovYL7rRVp+j6HbJ7pzhg@mail.gmail.com/>`_:: + + We have programs that use that ABI and thus it's a regression if they break. + + * From `2012-07-06 <https://lore.kernel.org/all/CA+55aFwnLJ+0sjx92EGREGTWOx84wwKaraSzpTNJwPVV8edw8g@mail.gmail.com/>`_:: + + > Now this got me wondering if Debian _unstable_ actually qualifies as a + > standard distro userspace. + + Oh, if the kernel breaks some standard user space, that counts. Tons + of people run Debian unstable + + * From `2019-09-15 + <https://lore.kernel.org/lkml/CAHk-=wiP4K8DRJWsCo=20hn_6054xBamGKF2kPgUzpB5aMaofA@mail.gmail.com/>`_:: + + One _particularly_ last-minute revert is the top-most commit (ignoring + the version change itself) done just before the release, and while + it's very annoying, it's perhaps also instructive. + + What's instructive about it is that I reverted a commit that wasn't + actually buggy. In fact, it was doing exactly what it set out to do, + and did it very well. In fact it did it _so_ well that the much + improved IO patterns it caused then ended up revealing a user-visible + regression due to a real bug in a completely unrelated area. + + The actual details of that regression are not the reason I point that + revert out as instructive, though. It's more that it's an instructive + example of what counts as a regression, and what the whole "no + regressions" kernel rule means. The reverted commit didn't change any + API's, and it didn't introduce any new bugs. But it ended up exposing + another problem, and as such caused a kernel upgrade to fail for a + user. So it got reverted. + + The point here being that we revert based on user-reported _behavior_, + not based on some "it changes the ABI" or "it caused a bug" concept. + The problem was really pre-existing, and it just didn't happen to + trigger before. The better IO patterns introduced by the change just + happened to expose an old bug, and people had grown to depend on the + previously benign behavior of that old issue. + + And never fear, we'll re-introduce the fix that improved on the IO + patterns once we've decided just how to handle the fact that we had a + bad interaction with an interface that people had then just happened + to rely on incidental behavior for before. It's just that we'll have + to hash through how to do that (there are no less than three different + patches by three different developers being discussed, and there might + be more coming...). In the meantime, I reverted the thing that exposed + the problem to users for this release, even if I hope it will be + re-introduced (perhaps even backported as a stable patch) once we have + consensus about the issue it exposed. + + Take-away from the whole thing: it's not about whether you change the + kernel-userspace ABI, or fix a bug, or about whether the old code + "should never have worked in the first place". It's about whether + something breaks existing users' workflow. + + Anyway, that was my little aside on the whole regression thing. Since + it's that "first rule of kernel programming", I felt it is perhaps + worth just bringing it up every once in a while + +.. + end-of-content +.. + This text is available under GPL-2.0+ or CC-BY-4.0, as stated at the top + of the file. If you want to distribute this text under CC-BY-4.0 only, + please use "The Linux kernel developers" for author attribution and link + this as source: + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/plain/Documentation/process/handling-regressions.rst +.. + Note: Only the content of this RST file as found in the Linux kernel sources + is available under CC-BY-4.0, as versions of this text that were processed + (for example by the kernel's build system) might contain content taken from + files which use a more restrictive license. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index 9f1b88492bb3..3587dae4d0ef 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -25,6 +25,7 @@ Below are the essential guides that every developer should read. code-of-conduct-interpretation development-process submitting-patches + handling-regressions programming-language coding-style maintainer-handbooks @@ -48,6 +49,7 @@ Other guides to the community that are of interest to most developers are: deprecated embargoed-hardware-issues maintainers + researcher-guidelines These are some overall technical guides that have been put here for now for lack of a better place. diff --git a/Documentation/process/maintainer-handbooks.rst b/Documentation/process/maintainer-handbooks.rst index 6af1abb0da48..d783060b4cc6 100644 --- a/Documentation/process/maintainer-handbooks.rst +++ b/Documentation/process/maintainer-handbooks.rst @@ -16,3 +16,4 @@ Contents: :maxdepth: 2 maintainer-tip + maintainer-netdev diff --git a/Documentation/networking/netdev-FAQ.rst b/Documentation/process/maintainer-netdev.rst index e26532f49760..c456b5225d66 100644 --- a/Documentation/networking/netdev-FAQ.rst +++ b/Documentation/process/maintainer-netdev.rst @@ -16,12 +16,10 @@ Note that some subsystems (e.g. wireless drivers) which have a high volume of traffic have their own specific mailing lists. The netdev list is managed (like many other Linux mailing lists) through -VGER (http://vger.kernel.org/) and archives can be found below: +VGER (http://vger.kernel.org/) with archives available at +https://lore.kernel.org/netdev/ -- http://marc.info/?l=linux-netdev -- http://www.spinics.net/lists/netdev/ - -Aside from subsystems like that mentioned above, all network-related +Aside from subsystems like those mentioned above, all network-related Linux development (i.e. RFC, review, comments, etc.) takes place on netdev. @@ -37,6 +35,17 @@ for the future release. You can find the trees here: - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git - https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next.git +How do I indicate which tree (net vs. net-next) my patch should be in? +---------------------------------------------------------------------- +To help maintainers and CI bots you should explicitly mark which tree +your patch is targeting. Assuming that you use git, use the prefix +flag:: + + git format-patch --subject-prefix='PATCH net-next' start..finish + +Use ``net`` instead of ``net-next`` (always lower case) in the above for +bug-fix ``net`` content. + How often do changes from these trees make it to the mainline Linus tree? ------------------------------------------------------------------------- To understand this, you need to know a bit of background information on @@ -61,8 +70,12 @@ relating to vX.Y An announcement indicating when ``net-next`` has been closed is usually sent to netdev, but knowing the above, you can predict that in advance. -IMPORTANT: Do not send new ``net-next`` content to netdev during the -period during which ``net-next`` tree is closed. +.. warning:: + Do not send new ``net-next`` content to netdev during the + period during which ``net-next`` tree is closed. + +RFC patches sent for review only are obviously welcome at any time +(use ``--subject-prefix='RFC net-next'`` with ``git format-patch``). Shortly after the two weeks have passed (and vX.Y-rc1 is released), the tree for ``net-next`` reopens to collect content for the next (vX.Y+1) @@ -90,41 +103,35 @@ Load the mainline (Linus) page here: and note the top of the "tags" section. If it is rc1, it is early in the dev cycle. If it was tagged rc7 a week ago, then a release is -probably imminent. +probably imminent. If the most recent tag is a final release tag +(without an ``-rcN`` suffix) - we are most likely in a merge window +and ``net-next`` is closed. -How do I indicate which tree (net vs. net-next) my patch should be in? ----------------------------------------------------------------------- -Firstly, think whether you have a bug fix or new "next-like" content. -Then once decided, assuming that you use git, use the prefix flag, i.e. -:: - - git format-patch --subject-prefix='PATCH net-next' start..finish - -Use ``net`` instead of ``net-next`` (always lower case) in the above for -bug-fix ``net`` content. If you don't use git, then note the only magic -in the above is just the subject text of the outgoing e-mail, and you -can manually change it yourself with whatever MUA you are comfortable -with. - -I sent a patch and I'm wondering what happened to it - how can I tell whether it got merged? --------------------------------------------------------------------------------------------- +How can I tell the status of a patch I've sent? +----------------------------------------------- Start by looking at the main patchworks queue for netdev: https://patchwork.kernel.org/project/netdevbpf/list/ The "State" field will tell you exactly where things are at with your -patch. +patch. Patches are indexed by the ``Message-ID`` header of the emails +which carried them so if you have trouble finding your patch append +the value of ``Message-ID`` to the URL above. -The above only says "Under Review". How can I find out more? -------------------------------------------------------------- +How long before my patch is accepted? +------------------------------------- Generally speaking, the patches get triaged quickly (in less than -48h). So be patient. Asking the maintainer for status updates on your +48h). But be patient, if your patch is active in patchwork (i.e. it's +listed on the project's patch list) the chances it was missed are close to zero. +Asking the maintainer for status updates on your patch is a good way to ensure your patch is ignored or pushed to the bottom of the priority list. -I submitted multiple versions of the patch series. Should I directly update patchwork for the previous versions of these patch series? --------------------------------------------------------------------------------------------------------------------------------------- -No, please don't interfere with the patch status on patchwork, leave +Should I directly update patchwork state of my own patches? +----------------------------------------------------------- +It may be tempting to help the maintainers and update the state of your +own patches when you post a new version or spot a bug. Please do not do that. +Interfering with the patch status on patchwork will only cause confusion. Leave it to the maintainer to figure out what is the most recent and current version that should be applied. If there is any doubt, the maintainer will reply and ask what should be done. @@ -135,6 +142,17 @@ No, please resend the entire patch series and make sure you do number your patches such that it is clear this is the latest and greatest set of patches that can be applied. +I have received review feedback, when should I post a revised version of the patches? +------------------------------------------------------------------------------------- +Allow at least 24 hours to pass between postings. This will ensure reviewers +from all geographical locations have a chance to chime in. Do not wait +too long (weeks) between postings either as it will make it harder for reviewers +to recall all the context. + +Make sure you address all the feedback in your new posting. Do not post a new +version of the code if the discussion about the previous version is still +ongoing, unless directly instructed by a reviewer. + I submitted multiple versions of a patch series and it looks like a version other than the last one has been accepted, what should I do? ---------------------------------------------------------------------------------------------------------------------------------------- There is no revert possible, once it is pushed out, it stays like that. @@ -165,10 +183,10 @@ it is requested that you make it look like this:: * another line of text */ -I am working in existing code that has the former comment style and not the latter. Should I submit new code in the former style or the latter? ------------------------------------------------------------------------------------------------------------------------------------------------ -Make it the latter style, so that eventually all code in the domain -of netdev is of this format. +I am working in existing code which uses non-standard formatting. Which formatting should I use? +------------------------------------------------------------------------------------------------ +Make your code follow the most recent guidelines, so that eventually all code +in the domain of netdev is in the preferred format. I found a bug that might have possible security implications or similar. Should I mail the main netdev maintainer off-list? --------------------------------------------------------------------------------------------------------------------------- @@ -180,11 +198,15 @@ as possible alternative mechanisms. What level of testing is expected before I submit my change? ------------------------------------------------------------ -If your changes are against ``net-next``, the expectation is that you -have tested by layering your changes on top of ``net-next``. Ideally -you will have done run-time testing specific to your change, but at a -minimum, your changes should survive an ``allyesconfig`` and an -``allmodconfig`` build without new warnings or failures. +At the very minimum your changes must survive an ``allyesconfig`` and an +``allmodconfig`` build with ``W=1`` set without new warnings or failures. + +Ideally you will have done run-time testing specific to your change, +and the patch series contains a set of kernel selftest for +``tools/testing/selftests/net`` or using the KUnit framework. + +You are expected to test your changes on top of the relevant networking +tree (``net`` or ``net-next``) and not e.g. a stable tree or ``linux-next``. How do I post corresponding changes to user space components? ------------------------------------------------------------- @@ -198,7 +220,7 @@ or the user space project is not reviewed on netdev include a link to a public repo where user space patches can be seen. In case user space tooling lives in a separate repository but is -reviewed on netdev (e.g. patches to `iproute2` tools) kernel and +reviewed on netdev (e.g. patches to ``iproute2`` tools) kernel and user space patches should form separate series (threads) when posted to the mailing list, e.g.:: @@ -231,18 +253,18 @@ traffic if we can help it. netdevsim is great, can I extend it for my out-of-tree tests? ------------------------------------------------------------- -No, `netdevsim` is a test vehicle solely for upstream tests. -(Please add your tests under tools/testing/selftests/.) +No, ``netdevsim`` is a test vehicle solely for upstream tests. +(Please add your tests under ``tools/testing/selftests/``.) -We also give no guarantees that `netdevsim` won't change in the future +We also give no guarantees that ``netdevsim`` won't change in the future in a way which would break what would normally be considered uAPI. Is netdevsim considered a "user" of an API? ------------------------------------------- Linux kernel has a long standing rule that no API should be added unless -it has a real, in-tree user. Mock-ups and tests based on `netdevsim` are -strongly encouraged when adding new APIs, but `netdevsim` in itself +it has a real, in-tree user. Mock-ups and tests based on ``netdevsim`` are +strongly encouraged when adding new APIs, but ``netdevsim`` in itself is **not** considered a use case/user. Any other tips to help ensure my net/net-next patch gets OK'd? diff --git a/Documentation/process/programming-language.rst b/Documentation/process/programming-language.rst index ec474a70a02f..5fc9160ca1fa 100644 --- a/Documentation/process/programming-language.rst +++ b/Documentation/process/programming-language.rst @@ -5,9 +5,9 @@ Programming Language The kernel is written in the C programming language [c-language]_. More precisely, the kernel is typically compiled with ``gcc`` [gcc]_ -under ``-std=gnu89`` [gcc-c-dialect-options]_: the GNU dialect of ISO C90 -(including some C99 features). ``clang`` [clang]_ is also supported, see -docs on :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. +under ``-std=gnu11`` [gcc-c-dialect-options]_: the GNU dialect of ISO C11. +``clang`` [clang]_ is also supported, see docs on +:ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. This dialect contains many extensions to the language [gnu-extensions]_, and many of them are used within the kernel as a matter of course. diff --git a/Documentation/process/researcher-guidelines.rst b/Documentation/process/researcher-guidelines.rst new file mode 100644 index 000000000000..afc944e0e898 --- /dev/null +++ b/Documentation/process/researcher-guidelines.rst @@ -0,0 +1,143 @@ +.. SPDX-License-Identifier: GPL-2.0 + +.. _researcher_guidelines: + +Researcher Guidelines ++++++++++++++++++++++ + +The Linux kernel community welcomes transparent research on the Linux +kernel, the activities involved in producing it, and any other byproducts +of its development. Linux benefits greatly from this kind of research, and +most aspects of Linux are driven by research in one form or another. + +The community greatly appreciates if researchers can share preliminary +findings before making their results public, especially if such research +involves security. Getting involved early helps both improve the quality +of research and ability for Linux to improve from it. In any case, +sharing open access copies of the published research with the community +is recommended. + +This document seeks to clarify what the Linux kernel community considers +acceptable and non-acceptable practices when conducting such research. At +the very least, such research and related activities should follow +standard research ethics rules. For more background on research ethics +generally, ethics in technology, and research of developer communities +in particular, see: + +* `History of Research Ethics <https://www.unlv.edu/research/ORI-HSR/history-ethics>`_ +* `IEEE Ethics <https://www.ieee.org/about/ethics/index.html>`_ +* `Developer and Researcher Views on the Ethics of Experiments on Open-Source Projects <https://arxiv.org/pdf/2112.13217.pdf>`_ + +The Linux kernel community expects that everyone interacting with the +project is participating in good faith to make Linux better. Research on +any publicly-available artifact (including, but not limited to source +code) produced by the Linux kernel community is welcome, though research +on developers must be distinctly opt-in. + +Passive research that is based entirely on publicly available sources, +including posts to public mailing lists and commits to public +repositories, is clearly permissible. Though, as with any research, +standard ethics must still be followed. + +Active research on developer behavior, however, must be done with the +explicit agreement of, and full disclosure to, the individual developers +involved. Developers cannot be interacted with/experimented on without +consent; this, too, is standard research ethics. + +To help clarify: sending patches to developers *is* interacting +with them, but they have already consented to receiving *good faith +contributions*. Sending intentionally flawed/vulnerable patches or +contributing misleading information to discussions is not consented +to. Such communication can be damaging to the developer (e.g. draining +time, effort, and morale) and damaging to the project by eroding +the entire developer community's trust in the contributor (and the +contributor's organization as a whole), undermining efforts to provide +constructive feedback to contributors, and putting end users at risk of +software flaws. + +Participation in the development of Linux itself by researchers, as +with anyone, is welcomed and encouraged. Research into Linux code is +a common practice, especially when it comes to developing or running +analysis tools that produce actionable results. + +When engaging with the developer community, sending a patch has +traditionally been the best way to make an impact. Linux already has +plenty of known bugs -- what's much more helpful is having vetted fixes. +Before contributing, carefully read the appropriate documentation: + +* Documentation/process/development-process.rst +* Documentation/process/submitting-patches.rst +* Documentation/admin-guide/reporting-issues.rst +* Documentation/admin-guide/security-bugs.rst + +Then send a patch (including a commit log with all the details listed +below) and follow up on any feedback from other developers. + +When sending patches produced from research, the commit logs should +contain at least the following details, so that developers have +appropriate context for understanding the contribution. Answer: + +* What is the specific problem that has been found? +* How could the problem be reached on a running system? +* What effect would encountering the problem have on the system? +* How was the problem found? Specifically include details about any + testing, static or dynamic analysis programs, and any other tools or + methods used to perform the work. +* Which version of Linux was the problem found on? Using the most recent + release or a recent linux-next branch is strongly preferred (see + Documentation/process/howto.rst). +* What was changed to fix the problem, and why it is believed to be correct? +* How was the change build tested and run-time tested? +* What prior commit does this change fix? This should go in a "Fixes:" + tag as the documentation describes. +* Who else has reviewed this patch? This should go in appropriate + "Reviewed-by:" tags; see below. + +For example:: + + From: Author <author@email> + Subject: [PATCH] drivers/foo_bar: Add missing kfree() + + The error path in foo_bar driver does not correctly free the allocated + struct foo_bar_info. This can happen if the attached foo_bar device + rejects the initialization packets sent during foo_bar_probe(). This + would result in a 64 byte slab memory leak once per device attach, + wasting memory resources over time. + + This flaw was found using an experimental static analysis tool we are + developing, LeakMagic[1], which reported the following warning when + analyzing the v5.15 kernel release: + + path/to/foo_bar.c:187: missing kfree() call? + + Add the missing kfree() to the error path. No other references to + this memory exist outside the probe function, so this is the only + place it can be freed. + + x86_64 and arm64 defconfig builds with CONFIG_FOO_BAR=y using GCC + 11.2 show no new warnings, and LeakMagic no longer warns about this + code path. As we don't have a FooBar device to test with, no runtime + testing was able to be performed. + + [1] https://url/to/leakmagic/details + + Reported-by: Researcher <researcher@email> + Fixes: aaaabbbbccccdddd ("Introduce support for FooBar") + Signed-off-by: Author <author@email> + Reviewed-by: Reviewer <reviewer@email> + +If you are a first time contributor it is recommended that the patch +itself be vetted by others privately before being posted to public lists. +(This is required if you have been explicitly told your patches need +more careful internal review.) These people are expected to have their +"Reviewed-by" tag included in the resulting patch. Finding another +developer familiar with Linux contribution, especially within your own +organization, and having them help with reviews before sending them to +the public mailing lists tends to significantly improve the quality of the +resulting patches, and there by reduces the burden on other developers. + +If no one can be found to internally review patches and you need +help finding such a person, or if you have any other questions +related to this document and the developer community's expectations, +please reach out to the private Technical Advisory Board mailing list: +<tech-board@lists.linux-foundation.org>. diff --git a/Documentation/process/stable-kernel-rules.rst b/Documentation/process/stable-kernel-rules.rst index 003c865e9c21..c61865e91f52 100644 --- a/Documentation/process/stable-kernel-rules.rst +++ b/Documentation/process/stable-kernel-rules.rst @@ -35,7 +35,9 @@ Rules on what kind of patches are accepted, and which ones are not, into the Procedure for submitting patches to the -stable tree ---------------------------------------------------- - - Security patches should not be handled (solely) by the -stable review +.. note:: + + Security patches should not be handled (solely) by the -stable review process but should follow the procedures in :ref:`Documentation/admin-guide/security-bugs.rst <securitybugs>`. @@ -81,8 +83,8 @@ it to be applied to. :ref:`option_2` and :ref:`option_3` are more useful if the patch isn't deemed worthy at the time it is applied to a public git tree (for instance, because it deserves more regression testing first). :ref:`option_3` is especially -useful if the patch needs some special handling to apply to an older kernel -(e.g., if API's have changed in the meantime). +useful if the original upstream patch needs to be backported (for example +the backport needs some special handling due to e.g. API changes). Note that for :ref:`option_3`, if the patch deviates from the original upstream patch (for example because it had to be backported) this must be very @@ -151,8 +153,17 @@ Review cycle - If the patch is rejected by a member of the committee, or linux-kernel members object to the patch, bringing up issues that the maintainers and members did not realize, the patch will be dropped from the queue. - - At the end of the review cycle, the ACKed patches will be added to the - latest -stable release, and a new -stable release will happen. + - The ACKed patches will be posted again as part of release candidate (-rc) + to be tested by developers and testers. + - Usually only one -rc release is made, however if there are any outstanding + issues, some patches may be modified or dropped or additional patches may + be queued. Additional -rc releases are then released and tested until no + issues are found. + - Responding to the -rc releases can be done on the mailing list by sending + a "Tested-by:" email with any testing information desired. The "Tested-by:" + tags will be collected and added to the release commit. + - At the end of the review cycle, the new -stable release will be released + containing all the queued and tested patches. - Security patches will be accepted into the -stable tree directly from the security kernel team, and not go through the normal review cycle. Contact the kernel security team for more details on this procedure. @@ -168,7 +179,16 @@ Trees - The finalized and tagged releases of all stable kernels can be found in separate branches per version at: - https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git + + - The release candidate of all stable kernel versions can be found at: + + https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git/ + + .. warning:: + The -stable-rc tree is a snapshot in time of the stable-queue tree and + will change frequently, hence will be rebased often. It should only be + used for testing purposes (e.g. to be consumed by CI systems). Review committee diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 31ea120ce531..fb496b2ebfd3 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -495,7 +495,8 @@ Using Reported-by:, Tested-by:, Reviewed-by:, Suggested-by: and Fixes: The Reported-by tag gives credit to people who find bugs and report them and it hopefully inspires them to help us again in the future. Please note that if the bug was reported in private, then ask for permission first before using the -Reported-by tag. +Reported-by tag. The tag is intended for bugs; please do not use it to credit +feature requests. A Tested-by: tag indicates that the patch has been successfully tested (in some environment) by the person named. This tag informs maintainers that diff --git a/Documentation/riscv/index.rst b/Documentation/riscv/index.rst index ea915c196048..e23b876ad6eb 100644 --- a/Documentation/riscv/index.rst +++ b/Documentation/riscv/index.rst @@ -7,7 +7,6 @@ RISC-V architecture boot-image-header vm-layout - pmu patch-acceptance features diff --git a/Documentation/riscv/pmu.rst b/Documentation/riscv/pmu.rst deleted file mode 100644 index acb216b99c26..000000000000 --- a/Documentation/riscv/pmu.rst +++ /dev/null @@ -1,255 +0,0 @@ -=================================== -Supporting PMUs on RISC-V platforms -=================================== - -Alan Kao <alankao@andestech.com>, Mar 2018 - -Introduction ------------- - -As of this writing, perf_event-related features mentioned in The RISC-V ISA -Privileged Version 1.10 are as follows: -(please check the manual for more details) - -* [m|s]counteren -* mcycle[h], cycle[h] -* minstret[h], instret[h] -* mhpeventx, mhpcounterx[h] - -With such function set only, porting perf would require a lot of work, due to -the lack of the following general architectural performance monitoring features: - -* Enabling/Disabling counters - Counters are just free-running all the time in our case. -* Interrupt caused by counter overflow - No such feature in the spec. -* Interrupt indicator - It is not possible to have many interrupt ports for all counters, so an - interrupt indicator is required for software to tell which counter has - just overflowed. -* Writing to counters - There will be an SBI to support this since the kernel cannot modify the - counters [1]. Alternatively, some vendor considers to implement - hardware-extension for M-S-U model machines to write counters directly. - -This document aims to provide developers a quick guide on supporting their -PMUs in the kernel. The following sections briefly explain perf' mechanism -and todos. - -You may check previous discussions here [1][2]. Also, it might be helpful -to check the appendix for related kernel structures. - - -1. Initialization ------------------ - -*riscv_pmu* is a global pointer of type *struct riscv_pmu*, which contains -various methods according to perf's internal convention and PMU-specific -parameters. One should declare such instance to represent the PMU. By default, -*riscv_pmu* points to a constant structure *riscv_base_pmu*, which has very -basic support to a baseline QEMU model. - -Then he/she can either assign the instance's pointer to *riscv_pmu* so that -the minimal and already-implemented logic can be leveraged, or invent his/her -own *riscv_init_platform_pmu* implementation. - -In other words, existing sources of *riscv_base_pmu* merely provide a -reference implementation. Developers can flexibly decide how many parts they -can leverage, and in the most extreme case, they can customize every function -according to their needs. - - -2. Event Initialization ------------------------ - -When a user launches a perf command to monitor some events, it is first -interpreted by the userspace perf tool into multiple *perf_event_open* -system calls, and then each of them calls to the body of *event_init* -member function that was assigned in the previous step. In *riscv_base_pmu*'s -case, it is *riscv_event_init*. - -The main purpose of this function is to translate the event provided by user -into bitmap, so that HW-related control registers or counters can directly be -manipulated. The translation is based on the mappings and methods provided in -*riscv_pmu*. - -Note that some features can be done in this stage as well: - -(1) interrupt setting, which is stated in the next section; -(2) privilege level setting (user space only, kernel space only, both); -(3) destructor setting. Normally it is sufficient to apply *riscv_destroy_event*; -(4) tweaks for non-sampling events, which will be utilized by functions such as - *perf_adjust_period*, usually something like the follows:: - - if (!is_sampling_event(event)) { - hwc->sample_period = x86_pmu.max_period; - hwc->last_period = hwc->sample_period; - local64_set(&hwc->period_left, hwc->sample_period); - } - -In the case of *riscv_base_pmu*, only (3) is provided for now. - - -3. Interrupt ------------- - -3.1. Interrupt Initialization - -This often occurs at the beginning of the *event_init* method. In common -practice, this should be a code segment like:: - - int x86_reserve_hardware(void) - { - int err = 0; - - if (!atomic_inc_not_zero(&pmc_refcount)) { - mutex_lock(&pmc_reserve_mutex); - if (atomic_read(&pmc_refcount) == 0) { - if (!reserve_pmc_hardware()) - err = -EBUSY; - else - reserve_ds_buffers(); - } - if (!err) - atomic_inc(&pmc_refcount); - mutex_unlock(&pmc_reserve_mutex); - } - - return err; - } - -And the magic is in *reserve_pmc_hardware*, which usually does atomic -operations to make implemented IRQ accessible from some global function pointer. -*release_pmc_hardware* serves the opposite purpose, and it is used in event -destructors mentioned in previous section. - -(Note: From the implementations in all the architectures, the *reserve/release* -pair are always IRQ settings, so the *pmc_hardware* seems somehow misleading. -It does NOT deal with the binding between an event and a physical counter, -which will be introduced in the next section.) - -3.2. IRQ Structure - -Basically, a IRQ runs the following pseudo code:: - - for each hardware counter that triggered this overflow - - get the event of this counter - - // following two steps are defined as *read()*, - // check the section Reading/Writing Counters for details. - count the delta value since previous interrupt - update the event->count (# event occurs) by adding delta, and - event->hw.period_left by subtracting delta - - if the event overflows - sample data - set the counter appropriately for the next overflow - - if the event overflows again - too frequently, throttle this event - fi - fi - - end for - -However as of this writing, none of the RISC-V implementations have designed an -interrupt for perf, so the details are to be completed in the future. - -4. Reading/Writing Counters ---------------------------- - -They seem symmetric but perf treats them quite differently. For reading, there -is a *read* interface in *struct pmu*, but it serves more than just reading. -According to the context, the *read* function not only reads the content of the -counter (event->count), but also updates the left period to the next interrupt -(event->hw.period_left). - -But the core of perf does not need direct write to counters. Writing counters -is hidden behind the abstraction of 1) *pmu->start*, literally start counting so one -has to set the counter to a good value for the next interrupt; 2) inside the IRQ -it should set the counter to the same resonable value. - -Reading is not a problem in RISC-V but writing would need some effort, since -counters are not allowed to be written by S-mode. - - -5. add()/del()/start()/stop() ------------------------------ - -Basic idea: add()/del() adds/deletes events to/from a PMU, and start()/stop() -starts/stop the counter of some event in the PMU. All of them take the same -arguments: *struct perf_event *event* and *int flag*. - -Consider perf as a state machine, then you will find that these functions serve -as the state transition process between those states. -Three states (event->hw.state) are defined: - -* PERF_HES_STOPPED: the counter is stopped -* PERF_HES_UPTODATE: the event->count is up-to-date -* PERF_HES_ARCH: arch-dependent usage ... we don't need this for now - -A normal flow of these state transitions are as follows: - -* A user launches a perf event, resulting in calling to *event_init*. -* When being context-switched in, *add* is called by the perf core, with a flag - PERF_EF_START, which means that the event should be started after it is added. - At this stage, a general event is bound to a physical counter, if any. - The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, because it is now - stopped, and the (software) event count does not need updating. - - - *start* is then called, and the counter is enabled. - With flag PERF_EF_RELOAD, it writes an appropriate value to the counter (check - previous section for detail). - Nothing is written if the flag does not contain PERF_EF_RELOAD. - The state now is reset to none, because it is neither stopped nor updated - (the counting already started) - -* When being context-switched out, *del* is called. It then checks out all the - events in the PMU and calls *stop* to update their counts. - - - *stop* is called by *del* - and the perf core with flag PERF_EF_UPDATE, and it often shares the same - subroutine as *read* with the same logic. - The state changes to PERF_HES_STOPPED and PERF_HES_UPTODATE, again. - - - Life cycle of these two pairs: *add* and *del* are called repeatedly as - tasks switch in-and-out; *start* and *stop* is also called when the perf core - needs a quick stop-and-start, for instance, when the interrupt period is being - adjusted. - -Current implementation is sufficient for now and can be easily extended to -features in the future. - -A. Related Structures ---------------------- - -* struct pmu: include/linux/perf_event.h -* struct riscv_pmu: arch/riscv/include/asm/perf_event.h - - Both structures are designed to be read-only. - - *struct pmu* defines some function pointer interfaces, and most of them take - *struct perf_event* as a main argument, dealing with perf events according to - perf's internal state machine (check kernel/events/core.c for details). - - *struct riscv_pmu* defines PMU-specific parameters. The naming follows the - convention of all other architectures. - -* struct perf_event: include/linux/perf_event.h -* struct hw_perf_event - - The generic structure that represents perf events, and the hardware-related - details. - -* struct riscv_hw_events: arch/riscv/include/asm/perf_event.h - - The structure that holds the status of events, has two fixed members: - the number of events and the array of the events. - -References ----------- - -[1] https://github.com/riscv/riscv-linux/pull/124 - -[2] https://groups.google.com/a/groups.riscv.org/forum/#!topic/sw-dev/f19TmCNP6yA diff --git a/Documentation/scheduler/index.rst b/Documentation/scheduler/index.rst index 88900aabdbf7..b430d856056a 100644 --- a/Documentation/scheduler/index.rst +++ b/Documentation/scheduler/index.rst @@ -14,9 +14,11 @@ Linux Scheduler sched-domains sched-capacity sched-energy + schedutil sched-nice-design sched-rt-group sched-stats + sched-debug text_files diff --git a/Documentation/scheduler/sched-debug.rst b/Documentation/scheduler/sched-debug.rst new file mode 100644 index 000000000000..4d3d24f2a439 --- /dev/null +++ b/Documentation/scheduler/sched-debug.rst @@ -0,0 +1,54 @@ +================= +Scheduler debugfs +================= + +Booting a kernel with CONFIG_SCHED_DEBUG=y will give access to +scheduler specific debug files under /sys/kernel/debug/sched. Some of +those files are described below. + +numa_balancing +============== + +`numa_balancing` directory is used to hold files to control NUMA +balancing feature. If the system overhead from the feature is too +high then the rate the kernel samples for NUMA hinting faults may be +controlled by the `scan_period_min_ms, scan_delay_ms, +scan_period_max_ms, scan_size_mb` files. + + +scan_period_min_ms, scan_delay_ms, scan_period_max_ms, scan_size_mb +------------------------------------------------------------------- + +Automatic NUMA balancing scans tasks address space and unmaps pages to +detect if pages are properly placed or if the data should be migrated to a +memory node local to where the task is running. Every "scan delay" the task +scans the next "scan size" number of pages in its address space. When the +end of the address space is reached the scanner restarts from the beginning. + +In combination, the "scan delay" and "scan size" determine the scan rate. +When "scan delay" decreases, the scan rate increases. The scan delay and +hence the scan rate of every task is adaptive and depends on historical +behaviour. If pages are properly placed then the scan delay increases, +otherwise the scan delay decreases. The "scan size" is not adaptive but +the higher the "scan size", the higher the scan rate. + +Higher scan rates incur higher system overhead as page faults must be +trapped and potentially data must be migrated. However, the higher the scan +rate, the more quickly a tasks memory is migrated to a local node if the +workload pattern changes and minimises performance impact due to remote +memory accesses. These files control the thresholds for scan delays and +the number of pages scanned. + +``scan_period_min_ms`` is the minimum time in milliseconds to scan a +tasks virtual memory. It effectively controls the maximum scanning +rate for each task. + +``scan_delay_ms`` is the starting "scan delay" used for a task when it +initially forks. + +``scan_period_max_ms`` is the maximum time in milliseconds to scan a +tasks virtual memory. It effectively controls the minimum scanning +rate for each task. + +``scan_size_mb`` is how many megabytes worth of pages are scanned for +a given scan. diff --git a/Documentation/scheduler/sched-domains.rst b/Documentation/scheduler/sched-domains.rst index 84dcdcd2911c..e57ad28301bd 100644 --- a/Documentation/scheduler/sched-domains.rst +++ b/Documentation/scheduler/sched-domains.rst @@ -37,10 +37,10 @@ rebalancing event for the current runqueue has arrived. The actual load balancing workhorse, run_rebalance_domains()->rebalance_domains(), is then run in softirq context (SCHED_SOFTIRQ). -The latter function takes two arguments: the current CPU and whether it was idle -at the time the scheduler_tick() happened and iterates over all sched domains -our CPU is on, starting from its base domain and going up the ->parent chain. -While doing that, it checks to see if the current domain has exhausted its +The latter function takes two arguments: the runqueue of current CPU and whether +the CPU was idle at the time the scheduler_tick() happened and iterates over all +sched domains our CPU is on, starting from its base domain and going up the ->parent +chain. While doing that, it checks to see if the current domain has exhausted its rebalance interval. If so, it runs load_balance() on that domain. It then checks the parent sched_domain (if it exists), and the parent of the parent and so forth. diff --git a/Documentation/scheduler/schedutil.txt b/Documentation/scheduler/schedutil.rst index 78f6b91e2291..32c7d69fc86c 100644 --- a/Documentation/scheduler/schedutil.txt +++ b/Documentation/scheduler/schedutil.rst @@ -1,11 +1,15 @@ +========= +Schedutil +========= +.. note:: -NOTE; all this assumes a linear relation between frequency and work capacity, -we know this is flawed, but it is the best workable approximation. + All this assumes a linear relation between frequency and work capacity, + we know this is flawed, but it is the best workable approximation. PELT (Per Entity Load Tracking) -------------------------------- +=============================== With PELT we track some metrics across the various scheduler entities, from individual tasks to task-group slices to CPU runqueues. As the basis for this @@ -38,8 +42,8 @@ while 'runnable' will increase to reflect the amount of contention. For more detail see: kernel/sched/pelt.c -Frequency- / CPU Invariance ---------------------------- +Frequency / CPU Invariance +========================== Because consuming the CPU for 50% at 1GHz is not the same as consuming the CPU for 50% at 2GHz, nor is running 50% on a LITTLE CPU the same as running 50% on @@ -47,7 +51,7 @@ a big CPU, we allow architectures to scale the time delta with two ratios, one Dynamic Voltage and Frequency Scaling (DVFS) ratio and one microarch ratio. For simple DVFS architectures (where software is in full control) we trivially -compute the ratio as: +compute the ratio as:: f_cur r_dvfs := ----- @@ -55,7 +59,7 @@ compute the ratio as: For more dynamic systems where the hardware is in control of DVFS we use hardware counters (Intel APERF/MPERF, ARMv8.4-AMU) to provide us this ratio. -For Intel specifically, we use: +For Intel specifically, we use:: APERF f_cur := ----- * P0 @@ -87,7 +91,7 @@ For more detail see: UTIL_EST / UTIL_EST_FASTUP --------------------------- +========================== Because periodic tasks have their averages decayed while they sleep, even though when running their expected utilization will be the same, they suffer a @@ -106,7 +110,7 @@ For more detail see: kernel/sched/fair.c:util_est_dequeue() UCLAMP ------- +====== It is possible to set effective u_min and u_max clamps on each CFS or RT task; the runqueue keeps an max aggregate of these clamps for all running tasks. @@ -115,7 +119,7 @@ For more detail see: include/uapi/linux/sched/types.h Schedutil / DVFS ----------------- +================ Every time the scheduler load tracking is updated (task wakeup, task migration, time progression) we call out to schedutil to update the hardware @@ -123,7 +127,7 @@ DVFS state. The basis is the CPU runqueue's 'running' metric, which per the above it is the frequency invariant utilization estimate of the CPU. From this we compute -a desired frequency like: +a desired frequency like:: max( running, util_est ); if UTIL_EST u_cfs := { running; otherwise @@ -135,7 +139,7 @@ a desired frequency like: f_des := min( f_max, 1.25 u * f_max ) -XXX IO-wait; when the update is due to a task wakeup from IO-completion we +XXX IO-wait: when the update is due to a task wakeup from IO-completion we boost 'u' above. This frequency is then used to select a P-state/OPP or directly munged into a @@ -153,7 +157,7 @@ For more information see: kernel/sched/cpufreq_schedutil.c NOTES ------ +===== - On low-load scenarios, where DVFS is most relevant, the 'running' numbers will closely reflect utilization. diff --git a/Documentation/scsi/libsas.rst b/Documentation/scsi/libsas.rst index 6589dfefbc02..305a253d5c3b 100644 --- a/Documentation/scsi/libsas.rst +++ b/Documentation/scsi/libsas.rst @@ -207,7 +207,6 @@ Management Functions (TMFs) described in SAM:: /* Task Management Functions. Must be called from process context. */ int (*lldd_abort_task)(struct sas_task *); int (*lldd_abort_task_set)(struct domain_device *, u8 *lun); - int (*lldd_clear_aca)(struct domain_device *, u8 *lun); int (*lldd_clear_task_set)(struct domain_device *, u8 *lun); int (*lldd_I_T_nexus_reset)(struct domain_device *); int (*lldd_lu_reset)(struct domain_device *, u8 *lun); @@ -262,7 +261,6 @@ can look like this (called last thing from probe()) my_ha->sas_ha.lldd_abort_task = my_abort_task; my_ha->sas_ha.lldd_abort_task_set = my_abort_task_set; - my_ha->sas_ha.lldd_clear_aca = my_clear_aca; my_ha->sas_ha.lldd_clear_task_set = my_clear_task_set; my_ha->sas_ha.lldd_I_T_nexus_reset= NULL; (2) my_ha->sas_ha.lldd_lu_reset = my_lu_reset; diff --git a/Documentation/scsi/scsi_eh.rst b/Documentation/scsi/scsi_eh.rst index 7d78c2475615..885395dc1f15 100644 --- a/Documentation/scsi/scsi_eh.rst +++ b/Documentation/scsi/scsi_eh.rst @@ -95,19 +95,18 @@ function - BLK_EH_RESET_TIMER This indicates that more time is required to finish the - command. Timer is restarted. This action is counted as a - retry and only allowed scmd->allowed + 1(!) times. Once the - limit is reached, action for BLK_EH_DONE is taken instead. + command. Timer is restarted. - BLK_EH_DONE eh_timed_out() callback did not handle the command. Step #2 is taken. - 2. scsi_abort_command() is invoked to schedule an asynchrous abort. - Asynchronous abort are not invoked for commands which the - SCSI_EH_ABORT_SCHEDULED flag is set (this indicates that the command - already had been aborted once, and this is a retry which failed), - or when the EH deadline is expired. In these case Step #3 is taken. + 2. scsi_abort_command() is invoked to schedule an asynchronous abort which may + issue a retry scmd->allowed + 1 times. Asynchronous aborts are not invoked + for commands for which the SCSI_EH_ABORT_SCHEDULED flag is set (this + indicates that the command already had been aborted once, and this is a + retry which failed), when retries are exceeded, or when the EH deadline is + expired. In these cases Step #3 is taken. 3. scsi_eh_scmd_add(scmd, SCSI_EH_CANCEL_CMD) is invoked for the command. See [1-4] for more information. diff --git a/Documentation/scsi/ufs.rst b/Documentation/scsi/ufs.rst index a920c0a5a1f6..fbac745b783c 100644 --- a/Documentation/scsi/ufs.rst +++ b/Documentation/scsi/ufs.rst @@ -10,8 +10,8 @@ Universal Flash Storage 1. Overview 2. UFS Architecture Overview 2.1 Application Layer - 2.2 UFS Transport Protocol(UTP) layer - 2.3 UFS Interconnect(UIC) Layer + 2.2 UFS Transport Protocol (UTP) layer + 2.3 UFS Interconnect (UIC) Layer 3. UFSHCD Overview 3.1 UFS controller initialization 3.2 UTP Transfer requests @@ -22,15 +22,15 @@ Universal Flash Storage 1. Overview =========== -Universal Flash Storage(UFS) is a storage specification for flash devices. -It is aimed to provide a universal storage interface for both -embedded and removable flash memory based storage in mobile +Universal Flash Storage (UFS) is a storage specification for flash devices. +It aims to provide a universal storage interface for both +embedded and removable flash memory-based storage in mobile devices such as smart phones and tablet computers. The specification is defined by JEDEC Solid State Technology Association. UFS is based -on MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the +on the MIPI M-PHY physical layer standard. UFS uses MIPI M-PHY as the physical layer and MIPI Unipro as the link layer. -The main goals of UFS is to provide: +The main goals of UFS are to provide: * Optimized performance: @@ -53,17 +53,17 @@ The main goals of UFS is to provide: UFS has a layered communication architecture which is based on SCSI SAM-5 architectural model. -UFS communication architecture consists of following layers, +UFS communication architecture consists of the following layers. 2.1 Application Layer --------------------- - The Application layer is composed of UFS command set layer(UCS), + The Application layer is composed of the UFS command set layer (UCS), Task Manager and Device manager. The UFS interface is designed to be protocol agnostic, however SCSI has been selected as a baseline - protocol for versions 1.0 and 1.1 of UFS protocol layer. + protocol for versions 1.0 and 1.1 of the UFS protocol layer. - UFS supports subset of SCSI commands defined by SPC-4 and SBC-3. + UFS supports a subset of SCSI commands defined by SPC-4 and SBC-3. * UCS: It handles SCSI commands supported by UFS specification. @@ -78,10 +78,10 @@ UFS communication architecture consists of following layers, requests which are used to modify and retrieve configuration information of the device. -2.2 UFS Transport Protocol(UTP) layer -------------------------------------- +2.2 UFS Transport Protocol (UTP) layer +-------------------------------------- - UTP layer provides services for + The UTP layer provides services for the higher layers through Service Access Points. UTP defines 3 service access points for higher layers. @@ -89,19 +89,19 @@ UFS communication architecture consists of following layers, manager for device level operations. These device level operations are done through query requests. * UTP_CMD_SAP: Command service access point is exposed to UFS command - set layer(UCS) to transport commands. + set layer (UCS) to transport commands. * UTP_TM_SAP: Task management service access point is exposed to task manager to transport task management functions. - UTP transports messages through UFS protocol information unit(UPIU). + UTP transports messages through UFS protocol information unit (UPIU). -2.3 UFS Interconnect(UIC) Layer -------------------------------- +2.3 UFS Interconnect (UIC) Layer +-------------------------------- - UIC is the lowest layer of UFS layered architecture. It handles - connection between UFS host and UFS device. UIC consists of + UIC is the lowest layer of the UFS layered architecture. It handles + the connection between UFS host and UFS device. UIC consists of MIPI UniPro and MIPI M-PHY. UIC provides 2 service access points - to upper layer, + to upper layer: * UIC_SAP: To transport UPIU between UFS host and UFS device. * UIO_SAP: To issue commands to Unipro layers. @@ -110,25 +110,25 @@ UFS communication architecture consists of following layers, 3. UFSHCD Overview ================== -The UFS host controller driver is based on Linux SCSI Framework. -UFSHCD is a low level device driver which acts as an interface between -SCSI Midlayer and PCIe based UFS host controllers. +The UFS host controller driver is based on the Linux SCSI Framework. +UFSHCD is a low-level device driver which acts as an interface between +the SCSI Midlayer and PCIe-based UFS host controllers. -The current UFSHCD implementation supports following functionality, +The current UFSHCD implementation supports the following functionality: 3.1 UFS controller initialization --------------------------------- - The initialization module brings UFS host controller to active state - and prepares the controller to transfer commands/response between + The initialization module brings the UFS host controller to active state + and prepares the controller to transfer commands/responses between UFSHCD and UFS device. 3.2 UTP Transfer requests ------------------------- Transfer request handling module of UFSHCD receives SCSI commands - from SCSI Midlayer, forms UPIUs and issues the UPIUs to UFS Host - controller. Also, the module decodes, responses received from UFS + from the SCSI Midlayer, forms UPIUs and issues the UPIUs to the UFS Host + controller. Also, the module decodes responses received from the UFS host controller in the form of UPIUs and intimates the SCSI Midlayer of the status of the command. @@ -136,19 +136,19 @@ The current UFSHCD implementation supports following functionality, ---------------------- Error handling module handles Host controller fatal errors, - Device fatal errors and UIC interconnect layer related errors. + Device fatal errors and UIC interconnect layer-related errors. 3.4 SCSI Error handling ----------------------- This is done through UFSHCD SCSI error handling routines registered - with SCSI Midlayer. Examples of some of the error handling commands - issues by SCSI Midlayer are Abort task, Lun reset and host reset. + with the SCSI Midlayer. Examples of some of the error handling commands + issues by the SCSI Midlayer are Abort task, LUN reset and host reset. UFSHCD Routines to perform these tasks are registered with SCSI Midlayer through .eh_abort_handler, .eh_device_reset_handler and .eh_host_reset_handler. -In this version of UFSHCD Query requests and power management +In this version of UFSHCD, Query requests and power management functionality are not implemented. 4. BSG Support @@ -182,14 +182,14 @@ If you wish to read or write a descriptor, use the appropriate xferp of sg_io_v4. The userspace tool that interacts with the ufs-bsg endpoint and uses its -upiu-based protocol is available at: +UPIU-based protocol is available at: https://github.com/westerndigitalcorporation/ufs-tool For more detailed information about the tool and its supported features, please see the tool's README. -UFS Specifications can be found at: +UFS specifications can be found at: - UFS - http://www.jedec.org/sites/default/files/docs/JESD220.pdf - UFSHCI - http://www.jedec.org/sites/default/files/docs/JESD223.pdf diff --git a/Documentation/security/SCTP.rst b/Documentation/security/SCTP.rst index d5fd6ccc3dcb..b73eb764a001 100644 --- a/Documentation/security/SCTP.rst +++ b/Documentation/security/SCTP.rst @@ -15,10 +15,7 @@ For security module support, three SCTP specific hooks have been implemented:: security_sctp_assoc_request() security_sctp_bind_connect() security_sctp_sk_clone() - -Also the following security hook has been utilised:: - - security_inet_conn_established() + security_sctp_assoc_established() The usage of these hooks are described below with the SELinux implementation described in the `SCTP SELinux Support`_ chapter. @@ -122,11 +119,12 @@ calls **sctp_peeloff**\(3). @newsk - pointer to new sock structure. -security_inet_conn_established() -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ -Called when a COOKIE ACK is received:: +security_sctp_assoc_established() +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +Called when a COOKIE ACK is received, and the peer secid will be +saved into ``@asoc->peer_secid`` for client:: - @sk - pointer to sock structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of the COOKIE ACK packet. @@ -134,7 +132,7 @@ Security Hooks used for Association Establishment ------------------------------------------------- The following diagram shows the use of ``security_sctp_bind_connect()``, -``security_sctp_assoc_request()``, ``security_inet_conn_established()`` when +``security_sctp_assoc_request()``, ``security_sctp_assoc_established()`` when establishing an association. :: @@ -172,7 +170,7 @@ establishing an association. <------------------------------------------- COOKIE ACK | | sctp_sf_do_5_1E_ca | - Call security_inet_conn_established() | + Call security_sctp_assoc_established() | to set the peer label. | | | | If SCTP_SOCKET_TCP or peeled off @@ -198,7 +196,7 @@ hooks with the SELinux specifics expanded below:: security_sctp_assoc_request() security_sctp_bind_connect() security_sctp_sk_clone() - security_inet_conn_established() + security_sctp_assoc_established() security_sctp_assoc_request() @@ -271,12 +269,12 @@ sockets sid and peer sid to that contained in the ``@asoc sid`` and @newsk - pointer to new sock structure. -security_inet_conn_established() -~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +security_sctp_assoc_established() +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Called when a COOKIE ACK is received where it sets the connection's peer sid to that in ``@skb``:: - @sk - pointer to sock structure. + @asoc - pointer to sctp association structure. @skb - pointer to skbuff of the COOKIE ACK packet. diff --git a/Documentation/security/keys/trusted-encrypted.rst b/Documentation/security/keys/trusted-encrypted.rst index 80d5a5af62a1..f614dad7de12 100644 --- a/Documentation/security/keys/trusted-encrypted.rst +++ b/Documentation/security/keys/trusted-encrypted.rst @@ -107,12 +107,13 @@ Encrypted Keys -------------- Encrypted keys do not depend on a trust source, and are faster, as they use AES -for encryption/decryption. New keys are created from kernel-generated random -numbers, and are encrypted/decrypted using a specified ‘master’ key. The -‘master’ key can either be a trusted-key or user-key type. The main disadvantage -of encrypted keys is that if they are not rooted in a trusted key, they are only -as secure as the user key encrypting them. The master user key should therefore -be loaded in as secure a way as possible, preferably early in boot. +for encryption/decryption. New keys are created either from kernel-generated +random numbers or user-provided decrypted data, and are encrypted/decrypted +using a specified ‘master’ key. The ‘master’ key can either be a trusted-key or +user-key type. The main disadvantage of encrypted keys is that if they are not +rooted in a trusted key, they are only as secure as the user key encrypting +them. The master user key should therefore be loaded in as secure a way as +possible, preferably early in boot. Usage @@ -199,6 +200,8 @@ Usage:: keyctl add encrypted name "new [format] key-type:master-key-name keylen" ring + keyctl add encrypted name "new [format] key-type:master-key-name keylen + decrypted-data" ring keyctl add encrypted name "load hex_blob" ring keyctl update keyid "update key-type:master-key-name" @@ -303,6 +306,16 @@ Load an encrypted key "evm" from saved blob:: 82dbbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0 24717c64 5972dcb82ab2dde83376d82b2e3c09ffc +Instantiate an encrypted key "evm" using user-provided decrypted data:: + + $ keyctl add encrypted evm "new default user:kmk 32 `cat evm_decrypted_data.blob`" @u + 794890253 + + $ keyctl print 794890253 + default user:kmk 32 2375725ad57798846a9bbd240de8906f006e66c03af53b1b382d + bbc55be2a44616e4959430436dc4f2a7a9659aa60bb4652aeb2120f149ed197c564e0247 + 17c64 5972dcb82ab2dde83376d82b2e3c09ffc + Other uses for trusted and encrypted keys, such as for disk and file encryption are anticipated. In particular the new format 'ecryptfs' has been defined in order to use encrypted keys to mount an eCryptfs filesystem. More details diff --git a/Documentation/sound/designs/control-names.rst b/Documentation/sound/designs/control-names.rst index 7fedd0f33cd9..765ff9b5b7d9 100644 --- a/Documentation/sound/designs/control-names.rst +++ b/Documentation/sound/designs/control-names.rst @@ -34,7 +34,7 @@ CHANNEL Front front left/right channels Surround rear left/right in 4.0/5.1 surround CLFE C/LFE channels -Center center cannel +Center center channel LFE LFE channel Side side left/right for 7.1 surround ============ ================================================== diff --git a/Documentation/sound/hd-audio/models.rst b/Documentation/sound/hd-audio/models.rst index d25335993e55..9b52f50a6854 100644 --- a/Documentation/sound/hd-audio/models.rst +++ b/Documentation/sound/hd-audio/models.rst @@ -261,6 +261,10 @@ alc-sense-combo huawei-mbx-stereo Enable initialization verbs for Huawei MBX stereo speakers; might be risky, try this at your own risk +alc298-samsung-headphone + Samsung laptops with ALC298 +alc256-samsung-headphone + Samsung laptops with ALC256 ALC66x/67x/892 ============== diff --git a/Documentation/sphinx/kernel_abi.py b/Documentation/sphinx/kernel_abi.py index 4392b3cb4020..b5feb5b1d905 100644 --- a/Documentation/sphinx/kernel_abi.py +++ b/Documentation/sphinx/kernel_abi.py @@ -128,6 +128,7 @@ class KernelCmd(Directive): return out def nestedParse(self, lines, fname): + env = self.state.document.settings.env content = ViewList() node = nodes.section() @@ -137,7 +138,7 @@ class KernelCmd(Directive): code_block += "\n " + l lines = code_block + "\n\n" - line_regex = re.compile("^#define LINENO (\S+)\#([0-9]+)$") + line_regex = re.compile("^\.\. LINENO (\S+)\#([0-9]+)$") ln = 0 n = 0 f = fname @@ -154,6 +155,9 @@ class KernelCmd(Directive): self.do_parse(content, node) content = ViewList() + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(f)) + f = new_f # sphinx counts lines from 0 diff --git a/Documentation/sphinx/kernel_feat.py b/Documentation/sphinx/kernel_feat.py index 8138d69a6987..27b701ed3681 100644 --- a/Documentation/sphinx/kernel_feat.py +++ b/Documentation/sphinx/kernel_feat.py @@ -33,6 +33,7 @@ u""" import codecs import os +import re import subprocess import sys @@ -82,7 +83,7 @@ class KernelFeat(Directive): env = doc.settings.env cwd = path.dirname(doc.current_source) - cmd = "get_feat.pl rest --dir " + cmd = "get_feat.pl rest --enable-fname --dir " cmd += self.arguments[0] if len(self.arguments) > 1: @@ -102,7 +103,22 @@ class KernelFeat(Directive): shell_env["srctree"] = srctree lines = self.runCmd(cmd, shell=True, cwd=cwd, env=shell_env) - nodeList = self.nestedParse(lines, fname) + + line_regex = re.compile("^\.\. FILE (\S+)$") + + out_lines = "" + + for line in lines.split("\n"): + match = line_regex.search(line) + if match: + fname = match.group(1) + + # Add the file to Sphinx build dependencies + env.note_dependency(os.path.abspath(fname)) + else: + out_lines += line + "\n" + + nodeList = self.nestedParse(out_lines, fname) return nodeList def runCmd(self, cmd, **kwargs): diff --git a/Documentation/sphinx/kernel_include.py b/Documentation/sphinx/kernel_include.py index f523aa68a36b..abe768088377 100755 --- a/Documentation/sphinx/kernel_include.py +++ b/Documentation/sphinx/kernel_include.py @@ -59,6 +59,7 @@ class KernelInclude(Include): u"""KernelInclude (``kernel-include``) directive""" def run(self): + env = self.state.document.settings.env path = os.path.realpath( os.path.expandvars(self.arguments[0])) @@ -70,6 +71,8 @@ class KernelInclude(Include): self.arguments[0] = path + env.note_dependency(os.path.abspath(path)) + #return super(KernelInclude, self).run() # won't work, see HINTs in _run() return self._run() diff --git a/Documentation/sphinx/kerneldoc-preamble.sty b/Documentation/sphinx/kerneldoc-preamble.sty new file mode 100644 index 000000000000..9d0204dc38be --- /dev/null +++ b/Documentation/sphinx/kerneldoc-preamble.sty @@ -0,0 +1,226 @@ +% -*- coding: utf-8 -*- +% SPDX-License-Identifier: GPL-2.0 +% +% LaTeX preamble for "make latexdocs" or "make pdfdocs" including: +% - TOC width settings +% - Setting of tabulary (\tymin) +% - Headheight setting for fancyhdr +% - Fontfamily settings for CJK (Chinese, Japanese, and Korean) translations +% +% Note on the suffix of .sty: +% This is not implemented as a LaTeX style file, but as a file containing +% plain LaTeX code to be included into preamble. +% ".sty" is chosen because ".tex" would cause the build scripts to confuse +% this file with a LaTeX main file. +% +% Copyright (C) 2022 Akira Yokosawa + +% Custom width parameters for TOC +% - Redefine low-level commands defined in report.cls. +% - Indent of 2 chars is preserved for ease of comparison. +% Summary of changes from default params: +% Width of page number (\@pnumwidth): 1.55em -> 2.7em +% Width of chapter number: 1.5em -> 1.8em +% Indent of section number: 1.5em -> 1.8em +% Width of section number: 2.6em -> 3.2em +% Indent of sebsection number: 4.1em -> 5em +% Width of subsection number: 3.5em -> 4.3em +% +% These params can have 4 digit page counts, 2 digit chapter counts, +% section counts of 4 digits + 1 period (e.g., 18.10), and subsection counts +% of 5 digits + 2 periods (e.g., 18.7.13). +\makeatletter +%% Redefine \@pnumwidth (page number width) +\renewcommand*\@pnumwidth{2.7em} +%% Redefine \l@chapter (chapter list entry) +\renewcommand*\l@chapter[2]{% + \ifnum \c@tocdepth >\m@ne + \addpenalty{-\@highpenalty}% + \vskip 1.0em \@plus\p@ + \setlength\@tempdima{1.8em}% + \begingroup + \parindent \z@ \rightskip \@pnumwidth + \parfillskip -\@pnumwidth + \leavevmode \bfseries + \advance\leftskip\@tempdima + \hskip -\leftskip + #1\nobreak\hfil + \nobreak\hb@xt@\@pnumwidth{\hss #2% + \kern-\p@\kern\p@}\par + \penalty\@highpenalty + \endgroup + \fi} +%% Redefine \l@section and \l@subsection +\renewcommand*\l@section{\@dottedtocline{1}{1.8em}{3.2em}} +\renewcommand*\l@subsection{\@dottedtocline{2}{5em}{4.3em}} +\makeatother +%% Sphinx < 1.8 doesn't have \sphinxtableofcontentshook +\providecommand{\sphinxtableofcontentshook}{} +%% Undefine it for compatibility with Sphinx 1.7.9 +\renewcommand{\sphinxtableofcontentshook}{} % Empty the hook + +% Prevent column squeezing of tabulary. \tymin is set by Sphinx as: +% \setlength{\tymin}{3\fontcharwd\font`0 } +% , which is too short. +\setlength{\tymin}{20em} + +% Adjust \headheight for fancyhdr +\addtolength{\headheight}{1.6pt} +\addtolength{\topmargin}{-1.6pt} + +% Translations have Asian (CJK) characters which are only displayed if +% xeCJK is used +\IfFontExistsTF{Noto Sans CJK SC}{ + % Load xeCJK when CJK font is available + \usepackage{xeCJK} + % Noto CJK fonts don't provide slant shape. [AutoFakeSlant] permits + % its emulation. + % Select KR variant at the beginning of each document so that quotation + % and apostorph symbols of half-width is used in TOC of Latin documents. + \IfFontExistsTF{Noto Serif CJK KR}{ + \setCJKmainfont{Noto Serif CJK KR}[AutoFakeSlant] + }{ + \setCJKmainfont{Noto Sans CJK KR}[AutoFakeSlant] + } + \setCJKsansfont{Noto Sans CJK KR}[AutoFakeSlant] + \setCJKmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant] + % Teach xeCJK of half-width symbols + \xeCJKDeclareCharClass{HalfLeft}{`“,`‘} + \xeCJKDeclareCharClass{HalfRight}{`â€,`’} + % CJK Language-specific font choices + %% for Simplified Chinese + \IfFontExistsTF{Noto Serif CJK SC}{ + \newCJKfontfamily[SCmain]\scmain{Noto Serif CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCserif]\scserif{Noto Serif CJK SC}[AutoFakeSlant] + }{ + \newCJKfontfamily[SCmain]\scmain{Noto Sans CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCserif]\scserif{Noto Sans CJK SC}[AutoFakeSlant] + } + \newCJKfontfamily[SCsans]\scsans{Noto Sans CJK SC}[AutoFakeSlant] + \newCJKfontfamily[SCmono]\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant] + %% for Traditional Chinese + \IfFontExistsTF{Noto Serif CJK TC}{ + \newCJKfontfamily[TCmain]\tcmain{Noto Serif CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCserif]\tcserif{Noto Serif CJK TC}[AutoFakeSlant] + }{ + \newCJKfontfamily[TCmain]\tcmain{Noto Sans CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCserif]\tcserif{Noto Sans CJK TC}[AutoFakeSlant] + } + \newCJKfontfamily[TCsans]\tcsans{Noto Sans CJK TC}[AutoFakeSlant] + \newCJKfontfamily[TCmono]\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant] + %% for Korean + \IfFontExistsTF{Noto Serif CJK KR}{ + \newCJKfontfamily[KRmain]\krmain{Noto Serif CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRserif]\krserif{Noto Serif CJK KR}[AutoFakeSlant] + }{ + \newCJKfontfamily[KRmain]\krmain{Noto Sans CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRserif]\krserif{Noto Sans CJK KR}[AutoFakeSlant] + } + \newCJKfontfamily[KRsans]\krsans{Noto Sans CJK KR}[AutoFakeSlant] + \newCJKfontfamily[KRmono]\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant] + %% for Japanese + \IfFontExistsTF{Noto Serif CJK JP}{ + \newCJKfontfamily[JPmain]\jpmain{Noto Serif CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPserif]\jpserif{Noto Serif CJK JP}[AutoFakeSlant] + }{ + \newCJKfontfamily[JPmain]\jpmain{Noto Sans CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPserif]\jpserif{Noto Sans CJK JP}[AutoFakeSlant] + } + \newCJKfontfamily[JPsans]\jpsans{Noto Sans CJK JP}[AutoFakeSlant] + \newCJKfontfamily[JPmono]\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant] + % Dummy commands for Sphinx < 2.3 (no 'extrapackages' support) + \providecommand{\onehalfspacing}{} + \providecommand{\singlespacing}{} + % Define custom macros to on/off CJK + %% One and half spacing for CJK contents + \newcommand{\kerneldocCJKon}{\makexeCJKactive\onehalfspacing} + \newcommand{\kerneldocCJKoff}{\makexeCJKinactive\singlespacing} + % Define custom macros for switching CJK font setting + %% for Simplified Chinese + \newcommand{\kerneldocBeginSC}{% + \begingroup% + \scmain% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% Full-width in SC + \xeCJKDeclareCharClass{FullRight}{`â€,`’}% Full-width in SC + \renewcommand{\CJKrmdefault}{SCserif}% + \renewcommand{\CJKsfdefault}{SCsans}% + \renewcommand{\CJKttdefault}{SCmono}% + \xeCJKsetup{CJKspace = false}% gobble white spaces by ' ' + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndSC}{\endgroup} + %% for Traditional Chinese + \newcommand{\kerneldocBeginTC}{% + \begingroup% + \tcmain% + \xeCJKDeclareCharClass{FullLeft}{`“,`‘}% Full-width in TC + \xeCJKDeclareCharClass{FullRight}{`â€,`’}% Full-width in TC + \renewcommand{\CJKrmdefault}{TCserif}% + \renewcommand{\CJKsfdefault}{TCsans}% + \renewcommand{\CJKttdefault}{TCmono}% + \xeCJKsetup{CJKspace = false}% gobble white spaces by ' ' + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK TC}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndTC}{\endgroup} + %% for Korean + \newcommand{\kerneldocBeginKR}{% + \begingroup% + \krmain% + \renewcommand{\CJKrmdefault}{KRserif}% + \renewcommand{\CJKsfdefault}{KRsans}% + \renewcommand{\CJKttdefault}{KRmono}% + % \xeCJKsetup{CJKspace = true} % true by default + % For CJK ascii-art alignment (still misaligned for Hangul) + \setmonofont{Noto Sans Mono CJK KR}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndKR}{\endgroup} + %% for Japanese + \newcommand{\kerneldocBeginJP}{% + \begingroup% + \jpmain% + \renewcommand{\CJKrmdefault}{JPserif}% + \renewcommand{\CJKsfdefault}{JPsans}% + \renewcommand{\CJKttdefault}{JPmono}% + \xeCJKsetup{CJKspace = false}% gobble white space by ' ' + % For CJK ascii-art alignment + \setmonofont{Noto Sans Mono CJK JP}[AutoFakeSlant]% + } + \newcommand{\kerneldocEndJP}{\endgroup} + + % Single spacing in literal blocks + \fvset{baselinestretch=1} + % To customize \sphinxtableofcontents + \usepackage{etoolbox} + % Inactivate CJK after tableofcontents + \apptocmd{\sphinxtableofcontents}{\kerneldocCJKoff}{}{} + \xeCJKsetup{CJKspace = true}% For inter-phrase space of Korean TOC +}{ % No CJK font found + % Custom macros to on/off CJK and switch CJK fonts (Dummy) + \newcommand{\kerneldocCJKon}{} + \newcommand{\kerneldocCJKoff}{} + %% By defining \kerneldocBegin(SC|TC|KR|JP) as commands with an argument + %% and ignore the argument (#1) in their definitions, whole contents of + %% CJK chapters can be ignored. + \newcommand{\kerneldocBeginSC}[1]{% + %% Put a note on missing CJK fonts in place of zh_CN translation. + \begin{sphinxadmonition}{note}{Note on missing fonts:} + Translations of Simplified Chinese (zh\_CN), Traditional Chinese + (zh\_TW), Korean (ko\_KR), and Japanese (ja\_JP) were skipped + due to the lack of suitable font families. + + If you want them, please install ``Noto Sans CJK'' font families + by following instructions from + \sphinxcode{./scripts/sphinx-pre-install}. + Having optional ``Noto Serif CJK'' font families will improve + the looks of those translations. + \end{sphinxadmonition}} + \newcommand{\kerneldocEndSC}{} + \newcommand{\kerneldocBeginTC}[1]{} + \newcommand{\kerneldocEndTC}{} + \newcommand{\kerneldocBeginKR}[1]{} + \newcommand{\kerneldocEndKR}{} + \newcommand{\kerneldocBeginJP}[1]{} + \newcommand{\kerneldocEndJP}{} +} diff --git a/Documentation/sphinx/kerneldoc.py b/Documentation/sphinx/kerneldoc.py index 8189c33b9dda..9395892c7ba3 100644 --- a/Documentation/sphinx/kerneldoc.py +++ b/Documentation/sphinx/kerneldoc.py @@ -130,7 +130,7 @@ class KernelDocDirective(Directive): result = ViewList() lineoffset = 0; - line_regex = re.compile("^#define LINENO ([0-9]+)$") + line_regex = re.compile("^\.\. LINENO ([0-9]+)$") for line in lines: match = line_regex.search(line) if match: diff --git a/Documentation/sphinx/kfigure.py b/Documentation/sphinx/kfigure.py index 3c78828330be..cefdbb7e7523 100644 --- a/Documentation/sphinx/kfigure.py +++ b/Documentation/sphinx/kfigure.py @@ -31,10 +31,13 @@ u""" * ``dot(1)``: Graphviz (https://www.graphviz.org). If Graphviz is not available, the DOT language is inserted as literal-block. + For conversion to PDF, ``rsvg-convert(1)`` of librsvg + (https://gitlab.gnome.org/GNOME/librsvg) is used when available. * SVG to PDF: To generate PDF, you need at least one of this tools: - ``convert(1)``: ImageMagick (https://www.imagemagick.org) + - ``inkscape(1)``: Inkscape (https://inkscape.org/) List of customizations: @@ -49,6 +52,7 @@ import os from os import path import subprocess from hashlib import sha1 +import re from docutils import nodes from docutils.statemachine import ViewList from docutils.parsers.rst import directives @@ -109,10 +113,20 @@ def pass_handle(self, node): # pylint: disable=W0613 # Graphviz's dot(1) support dot_cmd = None +# dot(1) -Tpdf should be used +dot_Tpdf = False # ImageMagick' convert(1) support convert_cmd = None +# librsvg's rsvg-convert(1) support +rsvg_convert_cmd = None + +# Inkscape's inkscape(1) support +inkscape_cmd = None +# Inkscape prior to 1.0 uses different command options +inkscape_ver_one = False + def setup(app): # check toolchain first @@ -160,23 +174,62 @@ def setupTools(app): This function is called once, when the builder is initiated. """ - global dot_cmd, convert_cmd # pylint: disable=W0603 + global dot_cmd, dot_Tpdf, convert_cmd, rsvg_convert_cmd # pylint: disable=W0603 + global inkscape_cmd, inkscape_ver_one # pylint: disable=W0603 kernellog.verbose(app, "kfigure: check installed tools ...") dot_cmd = which('dot') convert_cmd = which('convert') + rsvg_convert_cmd = which('rsvg-convert') + inkscape_cmd = which('inkscape') if dot_cmd: kernellog.verbose(app, "use dot(1) from: " + dot_cmd) + + try: + dot_Thelp_list = subprocess.check_output([dot_cmd, '-Thelp'], + stderr=subprocess.STDOUT) + except subprocess.CalledProcessError as err: + dot_Thelp_list = err.output + pass + + dot_Tpdf_ptn = b'pdf' + dot_Tpdf = re.search(dot_Tpdf_ptn, dot_Thelp_list) else: kernellog.warn(app, "dot(1) not found, for better output quality install " "graphviz from https://www.graphviz.org") - if convert_cmd: - kernellog.verbose(app, "use convert(1) from: " + convert_cmd) + if inkscape_cmd: + kernellog.verbose(app, "use inkscape(1) from: " + inkscape_cmd) + inkscape_ver = subprocess.check_output([inkscape_cmd, '--version'], + stderr=subprocess.DEVNULL) + ver_one_ptn = b'Inkscape 1' + inkscape_ver_one = re.search(ver_one_ptn, inkscape_ver) + convert_cmd = None + rsvg_convert_cmd = None + dot_Tpdf = False + else: - kernellog.warn(app, - "convert(1) not found, for SVG to PDF conversion install " - "ImageMagick (https://www.imagemagick.org)") + if convert_cmd: + kernellog.verbose(app, "use convert(1) from: " + convert_cmd) + else: + kernellog.verbose(app, + "Neither inkscape(1) nor convert(1) found.\n" + "For SVG to PDF conversion, " + "install either Inkscape (https://inkscape.org/) (preferred) or\n" + "ImageMagick (https://www.imagemagick.org)") + + if rsvg_convert_cmd: + kernellog.verbose(app, "use rsvg-convert(1) from: " + rsvg_convert_cmd) + kernellog.verbose(app, "use 'dot -Tsvg' and rsvg-convert(1) for DOT -> PDF conversion") + dot_Tpdf = False + else: + kernellog.verbose(app, + "rsvg-convert(1) not found.\n" + " SVG rendering of convert(1) is done by ImageMagick-native renderer.") + if dot_Tpdf: + kernellog.verbose(app, "use 'dot -Tpdf' for DOT -> PDF conversion") + else: + kernellog.verbose(app, "use 'dot -Tsvg' and convert(1) for DOT -> PDF conversion") # integrate conversion tools @@ -242,9 +295,11 @@ def convert_image(img_node, translator, src_fname=None): elif in_ext == '.svg': if translator.builder.format == 'latex': - if convert_cmd is None: - kernellog.verbose(app, - "no SVG to PDF conversion available / include SVG raw.") + if not inkscape_cmd and convert_cmd is None: + kernellog.warn(app, + "no SVG to PDF conversion available / include SVG raw." + "\nIncluding large raw SVGs can cause xelatex error." + "\nInstall Inkscape (preferred) or ImageMagick.") img_node.replace_self(file2literal(src_fname)) else: dst_fname = path.join(translator.builder.outdir, fname + '.pdf') @@ -266,7 +321,14 @@ def convert_image(img_node, translator, src_fname=None): if in_ext == '.dot': kernellog.verbose(app, 'convert DOT to: {out}/' + _name) - ok = dot2format(app, src_fname, dst_fname) + if translator.builder.format == 'latex' and not dot_Tpdf: + svg_fname = path.join(translator.builder.outdir, fname + '.svg') + ok1 = dot2format(app, src_fname, svg_fname) + ok2 = svg2pdf_by_rsvg(app, svg_fname, dst_fname) + ok = ok1 and ok2 + + else: + ok = dot2format(app, src_fname, dst_fname) elif in_ext == '.svg': kernellog.verbose(app, 'convert SVG to: {out}/' + _name) @@ -303,22 +365,70 @@ def dot2format(app, dot_fname, out_fname): return bool(exit_code == 0) def svg2pdf(app, svg_fname, pdf_fname): - """Converts SVG to PDF with ``convert(1)`` command. + """Converts SVG to PDF with ``inkscape(1)`` or ``convert(1)`` command. - Uses ``convert(1)`` from ImageMagick (https://www.imagemagick.org) for - conversion. Returns ``True`` on success and ``False`` if an error occurred. + Uses ``inkscape(1)`` from Inkscape (https://inkscape.org/) or ``convert(1)`` + from ImageMagick (https://www.imagemagick.org) for conversion. + Returns ``True`` on success and ``False`` if an error occurred. * ``svg_fname`` pathname of the input SVG file with extension (``.svg``) * ``pdf_name`` pathname of the output PDF file with extension (``.pdf``) """ cmd = [convert_cmd, svg_fname, pdf_fname] - # use stdout and stderr from parent - exit_code = subprocess.call(cmd) + cmd_name = 'convert(1)' + + if inkscape_cmd: + cmd_name = 'inkscape(1)' + if inkscape_ver_one: + cmd = [inkscape_cmd, '-o', pdf_fname, svg_fname] + else: + cmd = [inkscape_cmd, '-z', '--export-pdf=%s' % pdf_fname, svg_fname] + + try: + warning_msg = subprocess.check_output(cmd, stderr=subprocess.STDOUT) + exit_code = 0 + except subprocess.CalledProcessError as err: + warning_msg = err.output + exit_code = err.returncode + pass + if exit_code != 0: kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + if warning_msg: + kernellog.warn(app, "Warning msg from %s: %s" + % (cmd_name, str(warning_msg, 'utf-8'))) + elif warning_msg: + kernellog.verbose(app, "Warning msg from %s (likely harmless):\n%s" + % (cmd_name, str(warning_msg, 'utf-8'))) + return bool(exit_code == 0) +def svg2pdf_by_rsvg(app, svg_fname, pdf_fname): + """Convert SVG to PDF with ``rsvg-convert(1)`` command. + + * ``svg_fname`` pathname of input SVG file, including extension ``.svg`` + * ``pdf_fname`` pathname of output PDF file, including extension ``.pdf`` + + Input SVG file should be the one generated by ``dot2format()``. + SVG -> PDF conversion is done by ``rsvg-convert(1)``. + + If ``rsvg-convert(1)`` is unavailable, fall back to ``svg2pdf()``. + + """ + + if rsvg_convert_cmd is None: + ok = svg2pdf(app, svg_fname, pdf_fname) + else: + cmd = [rsvg_convert_cmd, '--format=pdf', '-o', pdf_fname, svg_fname] + # use stdout and stderr from parent + exit_code = subprocess.call(cmd) + if exit_code != 0: + kernellog.warn(app, "Error #%d when calling: %s" % (exit_code, " ".join(cmd))) + ok = bool(exit_code == 0) + + return ok + # image handling # --------------------- diff --git a/Documentation/sphinx/requirements.txt b/Documentation/sphinx/requirements.txt index 9a35f50798a6..2c573541ab71 100644 --- a/Documentation/sphinx/requirements.txt +++ b/Documentation/sphinx/requirements.txt @@ -1,2 +1,4 @@ +# jinja2>=3.1 is not compatible with Sphinx<4.0 +jinja2<3.1 sphinx_rtd_theme Sphinx==2.4.4 diff --git a/Documentation/spi/pxa2xx.rst b/Documentation/spi/pxa2xx.rst index 6347580826be..716f65d87d04 100644 --- a/Documentation/spi/pxa2xx.rst +++ b/Documentation/spi/pxa2xx.rst @@ -101,7 +101,6 @@ device. All fields are optional. u8 rx_threshold; u8 dma_burst_size; u32 timeout; - int gpio_cs; }; The "pxa2xx_spi_chip.tx_threshold" and "pxa2xx_spi_chip.rx_threshold" fields are @@ -146,7 +145,6 @@ field. Below is a sample configuration using the PXA255 NSSP. .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .gpio_cs = 2, /* Use external chip select */ }; static struct pxa2xx_spi_chip cs8405a_chip_info = { @@ -154,7 +152,6 @@ field. Below is a sample configuration using the PXA255 NSSP. .rx_threshold = 8, /* SSP hardward FIFO threshold */ .dma_burst_size = 8, /* Byte wide transfers used so 8 byte bursts */ .timeout = 235, /* See Intel documentation */ - .gpio_cs = 3, /* Use external chip select */ }; static struct spi_board_info streetracer_spi_board_info[] __initdata = { diff --git a/Documentation/staging/remoteproc.rst b/Documentation/staging/remoteproc.rst index 9cccd3dd6a4b..348ee7e508ac 100644 --- a/Documentation/staging/remoteproc.rst +++ b/Documentation/staging/remoteproc.rst @@ -49,13 +49,14 @@ might also consider using dev_archdata for this). :: - void rproc_shutdown(struct rproc *rproc) + int rproc_shutdown(struct rproc *rproc) Power off a remote processor (previously booted with rproc_boot()). In case @rproc is still being used by an additional user(s), then this function will just decrement the power refcount and exit, without really powering off the device. +Returns 0 on success, and an appropriate error value otherwise. Every call to rproc_boot() must (eventually) be accompanied by a call to rproc_shutdown(). Calling rproc_shutdown() redundantly is a bug. diff --git a/Documentation/tools/index.rst b/Documentation/tools/index.rst new file mode 100644 index 000000000000..0bb1e61bdcc0 --- /dev/null +++ b/Documentation/tools/index.rst @@ -0,0 +1,20 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============ +Kernel tools +============ + +This book covers user-space tools that are shipped with the kernel source; +more additions are needed here: + +.. toctree:: + :maxdepth: 1 + + rtla/index + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/tools/rtla/common_hist_options.rst b/Documentation/tools/rtla/common_hist_options.rst index 0266cd08a6c9..df53ff835bfb 100644 --- a/Documentation/tools/rtla/common_hist_options.rst +++ b/Documentation/tools/rtla/common_hist_options.rst @@ -2,7 +2,7 @@ Set the histogram bucket size (default *1*). -**-e**, **--entries** *N* +**-E**, **--entries** *N* Set the number of entries of the histogram (default 256). diff --git a/Documentation/tools/rtla/common_options.rst b/Documentation/tools/rtla/common_options.rst index 721790ad984e..af76df6205d4 100644 --- a/Documentation/tools/rtla/common_options.rst +++ b/Documentation/tools/rtla/common_options.rst @@ -14,6 +14,25 @@ Save the stopped trace to [*file|osnoise_trace.txt*]. +**-e**, **--event** *sys:event* + + Enable an event in the trace (**-t**) session. The argument can be a specific event, e.g., **-e** *sched:sched_switch*, or all events of a system group, e.g., **-e** *sched*. Multiple **-e** are allowed. It is only active when **-t** or **-a** are set. + +**--filter** *<filter>* + + Filter the previous **-e** *sys:event* event with *<filter>*. For further information about event filtering see https://www.kernel.org/doc/html/latest/trace/events.html#event-filtering. + +**--trigger** *<trigger>* + Enable a trace event trigger to the previous **-e** *sys:event*. + If the *hist:* trigger is activated, the output histogram will be automatically saved to a file named *system_event_hist.txt*. + For example, the command: + + rtla <command> <mode> -t -e osnoise:irq_noise --trigger="hist:key=desc,duration/1000:sort=desc,duration/1000:vals=hitcount" + + Will automatically save the content of the histogram associated to *osnoise:irq_noise* event in *osnoise_irq_noise_hist.txt*. + + For further information about event trigger see https://www.kernel.org/doc/html/latest/trace/events.html#event-triggers. + **-P**, **--priority** *o:prio|r:prio|f:prio|d:runtime:period* Set scheduling parameters to the osnoise tracer threads, the format to set the priority are: diff --git a/Documentation/tools/rtla/common_osnoise_description.rst b/Documentation/tools/rtla/common_osnoise_description.rst index 8973c5df888f..d5d61615b967 100644 --- a/Documentation/tools/rtla/common_osnoise_description.rst +++ b/Documentation/tools/rtla/common_osnoise_description.rst @@ -1,7 +1,7 @@ The **rtla osnoise** tool is an interface for the *osnoise* tracer. The *osnoise* tracer dispatches a kernel thread per-cpu. These threads read the time in a loop while with preemption, softirq and IRQs enabled, thus -allowing all the sources of operating systme noise during its execution. +allowing all the sources of operating system noise during its execution. The *osnoise*'s tracer threads take note of the delta between each time read, along with an interference counter of all sources of interference. At the end of each period, the *osnoise* tracer displays a summary of diff --git a/Documentation/tools/rtla/common_osnoise_options.rst b/Documentation/tools/rtla/common_osnoise_options.rst index d556883e4e26..f792ca58c211 100644 --- a/Documentation/tools/rtla/common_osnoise_options.rst +++ b/Documentation/tools/rtla/common_osnoise_options.rst @@ -1,3 +1,8 @@ +**-a**, **--auto** *us* + + Set the automatic trace mode. This mode sets some commonly used options + while debugging the system. It is equivalent to use **-s** *us* **-T 1 -t**. + **-p**, **--period** *us* Set the *osnoise* tracer period in microseconds. @@ -15,3 +20,8 @@ Stop the trace if the total sample is higher than the argument in microseconds. If **-T** is set, it will also save the trace to the output. + +**-T**, **--threshold** *us* + + Specify the minimum delta between two time reads to be considered noise. + The default threshold is *5 us*. diff --git a/Documentation/tools/rtla/common_timerlat_options.rst b/Documentation/tools/rtla/common_timerlat_options.rst index e9c1bfd55d48..bacdea6de7a3 100644 --- a/Documentation/tools/rtla/common_timerlat_options.rst +++ b/Documentation/tools/rtla/common_timerlat_options.rst @@ -1,3 +1,10 @@ +**-a**, **--auto** *us* + + Set the automatic trace mode. This mode sets some commonly used options + while debugging the system. It is equivalent to use **-T** *us* **-s** *us* + **-t**. By default, *timerlat* tracer uses FIFO:95 for *timerlat* threads, + thus equilavent to **-P** *f:95*. + **-p**, **--period** *us* Set the *timerlat* tracer period in microseconds. @@ -14,3 +21,8 @@ Save the stack trace at the *IRQ* if a *Thread* latency is higher than the argument in us. + +**--dma-latency** *us* + Set the /dev/cpu_dma_latency to *us*, aiming to bound exit from idle latencies. + *cyclictest* sets this value to *0* by default, use **--dma-latency** *0* to have + similar results. diff --git a/Documentation/tools/rtla/index.rst b/Documentation/tools/rtla/index.rst new file mode 100644 index 000000000000..840f0bf3e803 --- /dev/null +++ b/Documentation/tools/rtla/index.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================ +The realtime Linux analysis tool +================================ + +RTLA provides a set of tools for the analysis of the kernel's realtime +behavior on specific hardware. + +.. toctree:: + :maxdepth: 1 + + rtla + rtla-osnoise + rtla-osnoise-hist + rtla-osnoise-top + rtla-timerlat + rtla-timerlat-hist + rtla-timerlat-top + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/tools/rtla/rtla-osnoise-hist.rst b/Documentation/tools/rtla/rtla-osnoise-hist.rst index 52298ddd8701..f2e79d22c4c4 100644 --- a/Documentation/tools/rtla/rtla-osnoise-hist.rst +++ b/Documentation/tools/rtla/rtla-osnoise-hist.rst @@ -36,7 +36,7 @@ default). The reason for reducing the runtime is to avoid starving the **rtla** tool. The tool is also set to run for *one minute*. The output histogram is set to group outputs in buckets of *10us* and *25* entries:: - [root@f34 ~/]# rtla osnoise hist -P F:1 -c 0-11 -r 900000 -d 1M -b 10 -e 25 + [root@f34 ~/]# rtla osnoise hist -P F:1 -c 0-11 -r 900000 -d 1M -b 10 -E 25 # RTLA osnoise histogram # Time unit is microseconds (us) # Duration: 0 00:01:00 diff --git a/Documentation/trace/fprobe.rst b/Documentation/trace/fprobe.rst new file mode 100644 index 000000000000..b64bec1ce144 --- /dev/null +++ b/Documentation/trace/fprobe.rst @@ -0,0 +1,174 @@ +.. SPDX-License-Identifier: GPL-2.0 + +================================== +Fprobe - Function entry/exit probe +================================== + +.. Author: Masami Hiramatsu <mhiramat@kernel.org> + +Introduction +============ + +Fprobe is a function entry/exit probe mechanism based on ftrace. +Instead of using ftrace full feature, if you only want to attach callbacks +on function entry and exit, similar to the kprobes and kretprobes, you can +use fprobe. Compared with kprobes and kretprobes, fprobe gives faster +instrumentation for multiple functions with single handler. This document +describes how to use fprobe. + +The usage of fprobe +=================== + +The fprobe is a wrapper of ftrace (+ kretprobe-like return callback) to +attach callbacks to multiple function entry and exit. User needs to set up +the `struct fprobe` and pass it to `register_fprobe()`. + +Typically, `fprobe` data structure is initialized with the `entry_handler` +and/or `exit_handler` as below. + +.. code-block:: c + + struct fprobe fp = { + .entry_handler = my_entry_callback, + .exit_handler = my_exit_callback, + }; + +To enable the fprobe, call one of register_fprobe(), register_fprobe_ips(), and +register_fprobe_syms(). These functions register the fprobe with different types +of parameters. + +The register_fprobe() enables a fprobe by function-name filters. +E.g. this enables @fp on "func*()" function except "func2()".:: + + register_fprobe(&fp, "func*", "func2"); + +The register_fprobe_ips() enables a fprobe by ftrace-location addresses. +E.g. + +.. code-block:: c + + unsigned long ips[] = { 0x.... }; + + register_fprobe_ips(&fp, ips, ARRAY_SIZE(ips)); + +And the register_fprobe_syms() enables a fprobe by symbol names. +E.g. + +.. code-block:: c + + char syms[] = {"func1", "func2", "func3"}; + + register_fprobe_syms(&fp, syms, ARRAY_SIZE(syms)); + +To disable (remove from functions) this fprobe, call:: + + unregister_fprobe(&fp); + +You can temporally (soft) disable the fprobe by:: + + disable_fprobe(&fp); + +and resume by:: + + enable_fprobe(&fp); + +The above is defined by including the header:: + + #include <linux/fprobe.h> + +Same as ftrace, the registered callbacks will start being called some time +after the register_fprobe() is called and before it returns. See +:file:`Documentation/trace/ftrace.rst`. + +Also, the unregister_fprobe() will guarantee that the both enter and exit +handlers are no longer being called by functions after unregister_fprobe() +returns as same as unregister_ftrace_function(). + +The fprobe entry/exit handler +============================= + +The prototype of the entry/exit callback function is as follows: + +.. code-block:: c + + void callback_func(struct fprobe *fp, unsigned long entry_ip, struct pt_regs *regs); + +Note that both entry and exit callbacks have same ptototype. The @entry_ip is +saved at function entry and passed to exit handler. + +@fp + This is the address of `fprobe` data structure related to this handler. + You can embed the `fprobe` to your data structure and get it by + container_of() macro from @fp. The @fp must not be NULL. + +@entry_ip + This is the ftrace address of the traced function (both entry and exit). + Note that this may not be the actual entry address of the function but + the address where the ftrace is instrumented. + +@regs + This is the `pt_regs` data structure at the entry and exit. Note that + the instruction pointer of @regs may be different from the @entry_ip + in the entry_handler. If you need traced instruction pointer, you need + to use @entry_ip. On the other hand, in the exit_handler, the instruction + pointer of @regs is set to the currect return address. + +Share the callbacks with kprobes +================================ + +Since the recursion safeness of the fprobe (and ftrace) is a bit different +from the kprobes, this may cause an issue if user wants to run the same +code from the fprobe and the kprobes. + +Kprobes has per-cpu 'current_kprobe' variable which protects the kprobe +handler from recursion in all cases. On the other hand, fprobe uses +only ftrace_test_recursion_trylock(). This allows interrupt context to +call another (or same) fprobe while the fprobe user handler is running. + +This is not a matter if the common callback code has its own recursion +detection, or it can handle the recursion in the different contexts +(normal/interrupt/NMI.) +But if it relies on the 'current_kprobe' recursion lock, it has to check +kprobe_running() and use kprobe_busy_*() APIs. + +Fprobe has FPROBE_FL_KPROBE_SHARED flag to do this. If your common callback +code will be shared with kprobes, please set FPROBE_FL_KPROBE_SHARED +*before* registering the fprobe, like: + +.. code-block:: c + + fprobe.flags = FPROBE_FL_KPROBE_SHARED; + + register_fprobe(&fprobe, "func*", NULL); + +This will protect your common callback from the nested call. + +The missed counter +================== + +The `fprobe` data structure has `fprobe::nmissed` counter field as same as +kprobes. +This counter counts up when; + + - fprobe fails to take ftrace_recursion lock. This usually means that a function + which is traced by other ftrace users is called from the entry_handler. + + - fprobe fails to setup the function exit because of the shortage of rethook + (the shadow stack for hooking the function return.) + +The `fprobe::nmissed` field counts up in both cases. Therefore, the former +skips both of entry and exit callback and the latter skips the exit +callback, but in both case the counter will increase by 1. + +Note that if you set the FTRACE_OPS_FL_RECURSION and/or FTRACE_OPS_FL_RCU to +`fprobe::ops::flags` (ftrace_ops::flags) when registering the fprobe, this +counter may not work correctly, because ftrace skips the fprobe function which +increase the counter. + + +Functions and structures +======================== + +.. kernel-doc:: include/linux/fprobe.h +.. kernel-doc:: kernel/trace/fprobe.c + diff --git a/Documentation/trace/index.rst b/Documentation/trace/index.rst index 3769b9b7aed8..f9b7bcb5a630 100644 --- a/Documentation/trace/index.rst +++ b/Documentation/trace/index.rst @@ -9,6 +9,7 @@ Linux Tracing Technologies tracepoint-analysis ftrace ftrace-uses + fprobe kprobes kprobetrace uprobetracer @@ -30,3 +31,4 @@ Linux Tracing Technologies stm sys-t coresight/index + user_events diff --git a/Documentation/trace/osnoise-tracer.rst b/Documentation/trace/osnoise-tracer.rst index b648cb9bf1f0..963def9f97c6 100644 --- a/Documentation/trace/osnoise-tracer.rst +++ b/Documentation/trace/osnoise-tracer.rst @@ -51,7 +51,7 @@ 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:: +It is possible to follow the trace by reading the trace file:: [root@f32 tracing]# cat trace # tracer: osnoise @@ -108,7 +108,7 @@ The tracer has a set of options inside the osnoise directory, they are: 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. + be used, which is currently 5 us. Additional Tracing ------------------ diff --git a/Documentation/trace/user_events.rst b/Documentation/trace/user_events.rst new file mode 100644 index 000000000000..bddedabaca80 --- /dev/null +++ b/Documentation/trace/user_events.rst @@ -0,0 +1,216 @@ +========================================= +user_events: User-based Event Tracing +========================================= + +:Author: Beau Belgrave + +Overview +-------- +User based trace events allow user processes to create events and trace data +that can be viewed via existing tools, such as ftrace, perf and eBPF. +To enable this feature, build your kernel with CONFIG_USER_EVENTS=y. + +Programs can view status of the events via +/sys/kernel/debug/tracing/user_events_status and can both register and write +data out via /sys/kernel/debug/tracing/user_events_data. + +Programs can also use /sys/kernel/debug/tracing/dynamic_events to register and +delete user based events via the u: prefix. The format of the command to +dynamic_events is the same as the ioctl with the u: prefix applied. + +Typically programs will register a set of events that they wish to expose to +tools that can read trace_events (such as ftrace and perf). The registration +process gives back two ints to the program for each event. The first int is the +status index. This index describes which byte in the +/sys/kernel/debug/tracing/user_events_status file represents this event. The +second int is the write index. This index describes the data when a write() or +writev() is called on the /sys/kernel/debug/tracing/user_events_data file. + +The structures referenced in this document are contained with the +/include/uap/linux/user_events.h file in the source tree. + +**NOTE:** *Both user_events_status and user_events_data are under the tracefs +filesystem and may be mounted at different paths than above.* + +Registering +----------- +Registering within a user process is done via ioctl() out to the +/sys/kernel/debug/tracing/user_events_data file. The command to issue is +DIAG_IOCSREG. + +This command takes a struct user_reg as an argument:: + + struct user_reg { + u32 size; + u64 name_args; + u32 status_index; + u32 write_index; + }; + +The struct user_reg requires two inputs, the first is the size of the structure +to ensure forward and backward compatibility. The second is the command string +to issue for registering. Upon success two outputs are set, the status index +and the write index. + +User based events show up under tracefs like any other event under the +subsystem named "user_events". This means tools that wish to attach to the +events need to use /sys/kernel/debug/tracing/events/user_events/[name]/enable +or perf record -e user_events:[name] when attaching/recording. + +**NOTE:** *The write_index returned is only valid for the FD that was used* + +Command Format +^^^^^^^^^^^^^^ +The command string format is as follows:: + + name[:FLAG1[,FLAG2...]] [Field1[;Field2...]] + +Supported Flags +^^^^^^^^^^^^^^^ +**BPF_ITER** - EBPF programs attached to this event will get the raw iovec +struct instead of any data copies for max performance. + +Field Format +^^^^^^^^^^^^ +:: + + type name [size] + +Basic types are supported (__data_loc, u32, u64, int, char, char[20], etc). +User programs are encouraged to use clearly sized types like u32. + +**NOTE:** *Long is not supported since size can vary between user and kernel.* + +The size is only valid for types that start with a struct prefix. +This allows user programs to describe custom structs out to tools, if required. + +For example, a struct in C that looks like this:: + + struct mytype { + char data[20]; + }; + +Would be represented by the following field:: + + struct mytype myname 20 + +Deleting +----------- +Deleting an event from within a user process is done via ioctl() out to the +/sys/kernel/debug/tracing/user_events_data file. The command to issue is +DIAG_IOCSDEL. + +This command only requires a single string specifying the event to delete by +its name. Delete will only succeed if there are no references left to the +event (in both user and kernel space). User programs should use a separate file +to request deletes than the one used for registration due to this. + +Status +------ +When tools attach/record user based events the status of the event is updated +in realtime. This allows user programs to only incur the cost of the write() or +writev() calls when something is actively attached to the event. + +User programs call mmap() on /sys/kernel/debug/tracing/user_events_status to +check the status for each event that is registered. The byte to check in the +file is given back after the register ioctl() via user_reg.status_index. +Currently the size of user_events_status is a single page, however, custom +kernel configurations can change this size to allow more user based events. In +all cases the size of the file is a multiple of a page size. + +For example, if the register ioctl() gives back a status_index of 3 you would +check byte 3 of the returned mmap data to see if anything is attached to that +event. + +Administrators can easily check the status of all registered events by reading +the user_events_status file directly via a terminal. The output is as follows:: + + Byte:Name [# Comments] + ... + + Active: ActiveCount + Busy: BusyCount + Max: MaxCount + +For example, on a system that has a single event the output looks like this:: + + 1:test + + Active: 1 + Busy: 0 + Max: 4096 + +If a user enables the user event via ftrace, the output would change to this:: + + 1:test # Used by ftrace + + Active: 1 + Busy: 1 + Max: 4096 + +**NOTE:** *A status index of 0 will never be returned. This allows user +programs to have an index that can be used on error cases.* + +Status Bits +^^^^^^^^^^^ +The byte being checked will be non-zero if anything is attached. Programs can +check specific bits in the byte to see what mechanism has been attached. + +The following values are defined to aid in checking what has been attached: + +**EVENT_STATUS_FTRACE** - Bit set if ftrace has been attached (Bit 0). + +**EVENT_STATUS_PERF** - Bit set if perf/eBPF has been attached (Bit 1). + +Writing Data +------------ +After registering an event the same fd that was used to register can be used +to write an entry for that event. The write_index returned must be at the start +of the data, then the remaining data is treated as the payload of the event. + +For example, if write_index returned was 1 and I wanted to write out an int +payload of the event. Then the data would have to be 8 bytes (2 ints) in size, +with the first 4 bytes being equal to 1 and the last 4 bytes being equal to the +value I want as the payload. + +In memory this would look like this:: + + int index; + int payload; + +User programs might have well known structs that they wish to use to emit out +as payloads. In those cases writev() can be used, with the first vector being +the index and the following vector(s) being the actual event payload. + +For example, if I have a struct like this:: + + struct payload { + int src; + int dst; + int flags; + }; + +It's advised for user programs to do the following:: + + struct iovec io[2]; + struct payload e; + + io[0].iov_base = &write_index; + io[0].iov_len = sizeof(write_index); + io[1].iov_base = &e; + io[1].iov_len = sizeof(e); + + writev(fd, (const struct iovec*)io, 2); + +**NOTE:** *The write_index is not emitted out into the trace being recorded.* + +EBPF +---- +EBPF programs that attach to a user-based event tracepoint are given a pointer +to a struct user_bpf_context. The bpf context contains the data type (which can +be a user or kernel buffer, or can be a pointer to the iovec) and the data +length that was emitted (minus the write_index). + +Example Code +------------ +See sample code in samples/user_events. diff --git a/Documentation/translations/conf.py b/Documentation/translations/conf.py deleted file mode 100644 index 92cdbba74229..000000000000 --- a/Documentation/translations/conf.py +++ /dev/null @@ -1,12 +0,0 @@ -# -*- coding: utf-8 -*- -# SPDX-License-Identifier: GPL-2.0 - -# -- Additinal options for LaTeX output ---------------------------------- -# font config for ascii-art alignment - -latex_elements['preamble'] += ''' - \\IfFontExistsTF{Noto Sans CJK SC}{ - % For CJK ascii-art alignment - \\setmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant] - }{} -''' diff --git a/Documentation/translations/it_IT/process/programming-language.rst b/Documentation/translations/it_IT/process/programming-language.rst index 41db2598ce11..c1a9b481a6f9 100644 --- a/Documentation/translations/it_IT/process/programming-language.rst +++ b/Documentation/translations/it_IT/process/programming-language.rst @@ -10,8 +10,8 @@ Linguaggio di programmazione Il kernel è scritto nel linguaggio di programmazione C [it-c-language]_. Più precisamente, il kernel viene compilato con ``gcc`` [it-gcc]_ usando -l'opzione ``-std=gnu89`` [it-gcc-c-dialect-options]_: il dialetto GNU -dello standard ISO C90 (con l'aggiunta di alcune funzionalità da C99). +l'opzione ``-std=gnu11`` [it-gcc-c-dialect-options]_: il dialetto GNU +dello standard ISO C11. Linux supporta anche ``clang`` [it-clang]_, leggete la documentazione :ref:`Building Linux with Clang/LLVM <kbuild_llvm>`. diff --git a/Documentation/translations/ja_JP/index.rst b/Documentation/translations/ja_JP/index.rst index 88d4d98eed15..20738c931d02 100644 --- a/Documentation/translations/ja_JP/index.rst +++ b/Documentation/translations/ja_JP/index.rst @@ -3,7 +3,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginJP + \kerneldocBeginJP{ Japanese translations ===================== @@ -15,4 +15,4 @@ Japanese translations .. raw:: latex - \kerneldocEndJP + }\kerneldocEndJP diff --git a/Documentation/translations/ko_KR/index.rst b/Documentation/translations/ko_KR/index.rst index f636b482fb4c..4add6b2fe1f2 100644 --- a/Documentation/translations/ko_KR/index.rst +++ b/Documentation/translations/ko_KR/index.rst @@ -3,7 +3,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginKR + \kerneldocBeginKR{ í•œêµì–´ ë²ˆì— =========== @@ -26,5 +26,4 @@ .. raw:: latex - \normalsize - \kerneldocEndKR + }\kerneldocEndKR diff --git a/Documentation/translations/zh_CN/accounting/delay-accounting.rst b/Documentation/translations/zh_CN/accounting/delay-accounting.rst index 67d5606e5401..f1849411018e 100644 --- a/Documentation/translations/zh_CN/accounting/delay-accounting.rst +++ b/Documentation/translations/zh_CN/accounting/delay-accounting.rst @@ -17,6 +17,8 @@ a) ç‰å¾…一个CPU（任务为å¯è¿è¡Œï¼‰ b) 完æˆç”±è¯¥ä»»åŠ¡å‘èµ·çš„å—I/OåŒæ¥è¯·æ±‚ c) 页é¢äº¤æ¢ d) 内å˜å›žæ”¶ +e) 页缓å˜æŠ–动 +f) 直接规整 并将这些统计信æ¯é€šè¿‡taskstats接å£æ供给用户空间。 @@ -37,10 +39,10 @@ d) 内å˜å›žæ”¶ å‘用户æ€è¿”回一个通用数æ®ç»“构，对应æ¯pid或æ¯tgid的统计信æ¯ã€‚延时计数功能填写 该数æ®ç»“构的特定å—æ®µã€‚è§ - include/linux/taskstats.h + include/uapi/linux/taskstats.h å…¶æ述了延时计数相关å—段。系统通常以计数器形å¼è¿”回 CPUã€åŒæ¥å— I/Oã€äº¤æ¢ã€å†…å˜ -回收ç‰çš„累积延时。 +回收ã€é¡µç¼“å˜æŠ–动ã€ç›´æŽ¥è§„æ•´ç‰çš„累积延时。 å–任务æŸè®¡æ•°å™¨ä¸¤ä¸ªè¿žç»è¯»æ•°çš„差值，将得到任务在该时间间隔内ç‰å¾…对应资æºçš„总延时。 @@ -72,40 +74,36 @@ kernel.task_delayacct进行开关。注æ„，åªæœ‰åœ¨å¯ç”¨å»¶æ—¶è®¡æ•°åŽå¯åŠ getdelayså‘½ä»¤çš„ä¸€èˆ¬æ ¼å¼:: - getdelays [-t tgid] [-p pid] [-c cmd...] + getdelays [-dilv] [-t tgid] [-p pid] 获å–pid为10的任务从系统å¯åŠ¨åŽçš„延时信æ¯:: - # ./getdelays -p 10 + # ./getdelays -d -p 10 （输出信æ¯å’Œä¸‹ä¾‹ç›¸ä¼¼ï¼‰ 获å–所有tgid为5的任务从系统å¯åŠ¨åŽçš„总延时信æ¯:: - # ./getdelays -t 5 - - - CPU count real total virtual total delay total - 7876 92005750 100000000 24001500 - IO count delay total - 0 0 - SWAP count delay total - 0 0 - RECLAIM count delay total - 0 0 - -获å–指定简å•å‘½ä»¤è¿è¡Œæ—¶çš„延时信æ¯:: - - # ./getdelays -c ls / - - bin data1 data3 data5 dev home media opt root srv sys usr - boot data2 data4 data6 etc lib mnt proc sbin subdomain tmp var - - - CPU count real total virtual total delay total - 6 4000250 4000000 0 - IO count delay total - 0 0 - SWAP count delay total - 0 0 - RECLAIM count delay total - 0 0 + # ./getdelays -d -t 5 + print delayacct stats ON + TGID 5 + + + CPU count real total virtual total delay total delay average + 8 7000000 6872122 3382277 0.423ms + IO count delay total delay average + 0 0 0ms + SWAP count delay total delay average + 0 0 0ms + RECLAIM count delay total delay average + 0 0 0ms + THRASHING count delay total delay average + 0 0 0ms + COMPACT count delay total delay average + 0 0 0ms + +获å–pid为1çš„IO计数，它åªå’Œ-p一起使用:: + # ./getdelays -i -p 1 + printing IO accounting + linuxrc: read=65536, write=0, cancelled_write=0 + +上é¢çš„命令与-v一起使用，å¯ä»¥èŽ·å–更多调试信æ¯ã€‚ diff --git a/Documentation/translations/zh_CN/admin-guide/index.rst b/Documentation/translations/zh_CN/admin-guide/index.rst index 548e57f4b3f1..be535ffaf4b0 100644 --- a/Documentation/translations/zh_CN/admin-guide/index.rst +++ b/Documentation/translations/zh_CN/admin-guide/index.rst @@ -20,15 +20,15 @@ Linux å†…æ ¸ç”¨æˆ·å’Œç®¡ç†å‘˜æŒ‡å— Todolist: - kernel-parameters - devices - sysctl/index +* kernel-parameters +* devices +* sysctl/index 本节介ç»CPUæ¼æ´žåŠå…¶ç¼“解措施。 Todolist: - hw-vuln/index +* hw-vuln/index 下é¢çš„一组文档，针对的是试图跟踪问题和bug的用户。 @@ -44,18 +44,18 @@ Todolist: Todolist: - reporting-bugs - ramoops - dynamic-debug-howto - kdump/index - perf/index +* reporting-bugs +* ramoops +* dynamic-debug-howto +* kdump/index +* perf/index 这是应用程åºå¼€å‘äººå‘˜æ„Ÿå…´è¶£çš„ç« èŠ‚çš„å¼€å§‹ã€‚å¯ä»¥åœ¨è¿™é‡Œæ‰¾åˆ°æ¶µç›–å†…æ ¸ABIå„个 æ–¹é¢çš„文档。 Todolist: - sysfs-rules +* sysfs-rules 本手册的其余部分包括å„ç§æŒ‡å—，介ç»å¦‚ä½•æ ¹æ®æ‚¨çš„喜好é…ç½®å†…æ ¸çš„ç‰¹å®šè¡Œä¸ºã€‚ @@ -69,61 +69,61 @@ Todolist: lockup-watchdogs unicode sysrq + mm/index Todolist: - acpi/index - aoe/index - auxdisplay/index - bcache - binderfs - binfmt-misc - blockdev/index - bootconfig - braille-console - btmrvl - cgroup-v1/index - cgroup-v2 - cifs/index - dell_rbu - device-mapper/index - edid - efi-stub - ext4 - nfs/index - gpio/index - highuid - hw_random - initrd - iostats - java - jfs - kernel-per-CPU-kthreads - laptops/index - lcd-panel-cgram - ldm - LSM/index - md - media/index - mm/index - module-signing - mono - namespaces/index - numastat - parport - perf-security - pm/index - pnp - rapidio - ras - rtc - serial-console - svga - thunderbolt - ufs - vga-softcursor - video-output - xfs +* acpi/index +* aoe/index +* auxdisplay/index +* bcache +* binderfs +* binfmt-misc +* blockdev/index +* bootconfig +* braille-console +* btmrvl +* cgroup-v1/index +* cgroup-v2 +* cifs/index +* dell_rbu +* device-mapper/index +* edid +* efi-stub +* ext4 +* nfs/index +* gpio/index +* highuid +* hw_random +* initrd +* iostats +* java +* jfs +* kernel-per-CPU-kthreads +* laptops/index +* lcd-panel-cgram +* ldm +* LSM/index +* md +* media/index +* module-signing +* mono +* namespaces/index +* numastat +* parport +* perf-security +* pm/index +* pnp +* rapidio +* ras +* rtc +* serial-console +* svga +* thunderbolt +* ufs +* vga-softcursor +* video-output +* xfs .. only:: subproject and html diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst new file mode 100644 index 000000000000..0c8276109fc0 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/index.rst @@ -0,0 +1,28 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +============ +监测数æ®è®¿é—® +============ + +:doc:`DAMON </vm/damon/index>` å…许轻é‡çº§çš„æ•°æ®è®¿é—®ç›‘测。使用DAMON， +用户å¯ä»¥åˆ†æžä»–们系统的内å˜è®¿é—®æ¨¡å¼ï¼Œå¹¶ä¼˜åŒ–它们。 + +.. toctree:: + :maxdepth: 2 + + start + usage + reclaim + + + + diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst new file mode 100644 index 000000000000..9e541578f38d --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/reclaim.rst @@ -0,0 +1,232 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/reclaim.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +=============== +基于DAMON的回收 +=============== + +基于DAMON的回收（DAMON_RECLAIM）是一个é™æ€çš„å†…æ ¸æ¨¡å—，旨在用于轻度内å˜åŽ‹åŠ›ä¸‹çš„主动和轻 +é‡çº§çš„回收。它的目的ä¸æ˜¯å–代基于LRU列表的页é¢å›žæ”¶ï¼Œè€Œæ˜¯æœ‰é€‰æ‹©åœ°ç”¨äºŽä¸åŒç¨‹åº¦çš„内å˜åŽ‹åŠ›å’Œè¦ +求。 + +哪些地方需è¦ä¸»åŠ¨å›žæ”¶ï¼Ÿ +====================== + +在一般的内å˜è¶…é‡ä½¿ç”¨ï¼ˆover-committed systems，虚拟化相关术è¯ï¼‰çš„系统上，主动回收冷页 +有助于节çœå†…å˜å’Œå‡å°‘延迟高峰，这些延迟是由直接回收进程或kswapdçš„CPU消耗引起的，åŒæ—¶åªäº§ +生最å°çš„æ€§èƒ½ä¸‹é™ [1]_ [2]_ 。 + +基于空闲页报告 [3]_ 的内å˜è¿‡åº¦æ‰¿è¯ºçš„虚拟化系统就是很好的例åã€‚åœ¨è¿™æ ·çš„ç³»ç»Ÿä¸ï¼Œå®¢æˆ·æœº +å‘主机报告他们的空闲内å˜ï¼Œè€Œä¸»æœºåˆ™å°†æŠ¥å‘Šçš„内å˜é‡æ–°åˆ†é…ç»™å…¶ä»–å®¢æˆ·ã€‚å› æ¤ï¼Œç³»ç»Ÿçš„内å˜å¾—到了充 +分的利用。然而，客户å¯èƒ½ä¸é‚£ä¹ˆèŠ‚çœå†…å˜ï¼Œä¸»è¦æ˜¯å› ä¸ºä¸€äº›å†…æ ¸å系统和用户空间应用程åºè¢«è®¾è®¡ä¸º +使用尽å¯èƒ½å¤šçš„内å˜ã€‚然åŽï¼Œå®¢æˆ·æœºå¯èƒ½åªå‘主机报告少é‡çš„内å˜æ˜¯ç©ºé—²çš„，导致系统的内å˜åˆ©ç”¨çŽ‡ä¸‹é™ã€‚ +在客户ä¸è¿è¡Œä¸»åŠ¨å›žæ”¶å¯ä»¥ç¼“解这个问题。 + +它是如何工作的？ +================ + +DAMON_RECLAIM找到在特定时间内没有被访问的内å˜åŒºåŸŸå¹¶åˆ†é¡µã€‚为了é¿å…它在分页æ“作ä¸æ¶ˆè€—过多 +çš„CPU，å¯ä»¥é…置一个速度é™åˆ¶ã€‚在这个速度é™åˆ¶ä¸‹ï¼Œå®ƒé¦–先分页出那些没有被访问过的内å˜åŒºåŸŸã€‚ç³» +统管ç†å‘˜è¿˜å¯ä»¥é…置在什么情况下这个方案应该自动激活和åœç”¨ä¸‰ä¸ªå†…å˜åŽ‹åŠ›æ°´ä½ã€‚ + +接å£: 模å—å‚æ•° +============== + +è¦ä½¿ç”¨è¿™ä¸ªåŠŸèƒ½ï¼Œä½ 首先è¦ç¡®ä¿ä½ 的系统è¿è¡Œåœ¨ä¸€ä¸ªä»¥ ``CONFIG_DAMON_RECLAIM=y`` 构建的内 +æ ¸ä¸Šã€‚ + +为了让系统管ç†å‘˜å¯ç”¨æˆ–ç¦ç”¨å®ƒï¼Œå¹¶ä¸ºç»™å®šçš„系统进行调整，DAMON_RECLAIM利用了模å—å‚数。也就 +æ˜¯è¯´ï¼Œä½ å¯ä»¥æŠŠ ``damon_reclaim.<parameter>=<value>`` æ”¾åœ¨å†…æ ¸å¯åŠ¨å‘½ä»¤è¡Œä¸Šï¼Œæˆ–者把 +适当的值写入 ``/sys/modules/damon_reclaim/parameters/<parameter>`` 文件。 + +注æ„，除 ``å¯ç”¨`` 外的å‚数值åªåœ¨DAMON_RECLAIMå¯åŠ¨æ—¶åº”ç”¨ã€‚å› æ¤ï¼Œå¦‚æžœä½ æƒ³åœ¨è¿è¡Œæ—¶åº”用新 +çš„å‚数值，而DAMON_RECLAIMå·²ç»è¢«å¯ç”¨ï¼Œä½ 应该通过 ``å¯ç”¨`` çš„å‚数文件ç¦ç”¨å’Œé‡æ–°å¯ç”¨å®ƒã€‚ +在é‡æ–°å¯ç”¨ä¹‹å‰ï¼Œåº”将新的å‚数值写入适当的å‚数值ä¸ã€‚ + +下é¢æ˜¯æ¯ä¸ªå‚æ•°çš„æ述。 + +enable +------ + +å¯ç”¨æˆ–ç¦ç”¨DAMON_RECLAIM。 + +ä½ å¯ä»¥é€šè¿‡æŠŠè¿™ä¸ªå‚数的值设置为 ``Y`` æ¥å¯ç”¨DAMON_RCLAIM，把它设置为 ``N`` å¯ä»¥ç¦ç”¨ +DAMON_RECLAIM。注æ„，由于基于水ä½çš„激活æ¡ä»¶ï¼ŒDAMON_RECLAIMä¸èƒ½è¿›è¡ŒçœŸæ£çš„监测和回收。 +这一点请å‚考下é¢å…³äºŽæ°´ä½å‚æ•°çš„æ述。 + +min_age +------- + +识别冷内å˜åŒºåŸŸçš„时间阈值，å•ä½æ˜¯å¾®ç§’。 + +如果一个内å˜åŒºåŸŸåœ¨è¿™ä¸ªæ—¶é—´æˆ–更长的时间内没有被访问，DAMON_RECLAIM会将该区域识别为冷的， +并回收它。 + +默认为120秒。 + +quota_ms +-------- + +回收的时间é™åˆ¶ï¼Œä»¥æ¯«ç§’为å•ä½ã€‚ + +DAMON_RECLAIM 试图在一个时间窗å£ï¼ˆquota_reset_interval_ms）内åªä½¿ç”¨åˆ°è¿™ä¸ªæ—¶é—´ï¼Œä»¥ +å°è¯•å›žæ”¶å†·é¡µã€‚è¿™å¯ä»¥ç”¨æ¥é™åˆ¶DAMON_RECLAIMçš„CPU消耗。如果该值为零，则该é™åˆ¶è¢«ç¦ç”¨ã€‚ + +默认为10ms。 + +quota_sz +-------- + +回收的内å˜å¤§å°é™åˆ¶ï¼Œå•ä½ä¸ºå—节。 + +DAMON_RECLAIM 收å–在一个时间窗å£ï¼ˆquota_reset_interval_ms）内试图回收的内å˜é‡ï¼Œå¹¶ +使其ä¸è¶…过这个é™åˆ¶ã€‚è¿™å¯ä»¥ç”¨æ¥é™åˆ¶CPUå’ŒIO的消耗。如果该值为零，则é™åˆ¶è¢«ç¦ç”¨ã€‚ + +默认情况下是128 MiB。 + +quota_reset_interval_ms +----------------------- + +时间/大å°é…é¢æ”¶å–é‡ç½®é—´éš”，å•ä½ä¸ºæ¯«ç§’。 + +时间（quota_ms）和大å°ï¼ˆquota_sz）的é…é¢çš„ç›®æ ‡é‡ç½®é—´éš”。也就是说，DAMON_RECLAIM在 +å°è¯•å›žæ”¶â€˜ä¸â€™è¶…过quota_ms毫秒或quota_szå—节的内å˜ã€‚ + +默认为1秒。 + +wmarks_interval +--------------- + +当DAMON_RECLAIM被å¯ç”¨ä½†ç”±äºŽå…¶æ°´ä½è§„则而ä¸æ´»è·ƒæ—¶ï¼Œåœ¨æ£€æŸ¥æ°´ä½ä¹‹å‰çš„最å°ç‰å¾…时间。 + +wmarks_high +----------- + +高水ä½çš„å¯ç”¨å†…å˜çŽ‡ï¼ˆæ¯åƒå—节）。 + +如果系统的å¯ç”¨å†…å˜ï¼ˆä»¥æ¯åƒå—节为å•ä½ï¼‰é«˜äºŽè¿™ä¸ªæ•°å€¼ï¼ŒDAMON_RECLAIM就会å˜å¾—ä¸æ´»è·ƒï¼Œæ‰€ä»¥ +它什么也ä¸åšï¼Œåªæ˜¯å®šæœŸæ£€æŸ¥æ°´ä½ã€‚ + +wmarks_mid +---------- + +ä¸é—´æ°´ä½çš„å¯ç”¨å†…å˜çŽ‡ï¼ˆæ¯åƒå—节）。 + +如果系统的空闲内å˜ï¼ˆä»¥æ¯åƒå—节为å•ä½ï¼‰åœ¨è¿™ä¸ªå’Œä½Žæ°´ä½çº¿ä¹‹é—´ï¼ŒDAMON_RECLAIM就会被激活， +å› æ¤å¼€å§‹ç›‘测和回收。 + +wmarks_low +---------- + +低水ä½çš„å¯ç”¨å†…å˜çŽ‡ï¼ˆæ¯åƒå—节）。 + +如果系统的空闲内å˜ï¼ˆä»¥æ¯åƒå—节为å•ä½ï¼‰ä½ŽäºŽè¿™ä¸ªæ•°å€¼ï¼ŒDAMON_RECLAIM就会å˜å¾—ä¸æ´»è·ƒï¼Œæ‰€ä»¥ +它除了定期检查水ä½å¤–什么都ä¸åšã€‚在这ç§æƒ…况下，系统会退回到基于LRU列表的页é¢ç²’度回收逻辑。 + +sample_interval +--------------- + +ç›‘æµ‹çš„é‡‡æ ·é—´éš”ï¼Œå•ä½æ˜¯å¾®ç§’。 + +DAMON用于监测冷内å˜çš„é‡‡æ ·é—´éš”ã€‚æ›´å¤šç»†èŠ‚è¯·å‚考DAMON文档 (:doc:`usage`) 。 + +aggr_interval +------------- + +监测的èšé›†é—´éš”，å•ä½æ˜¯å¾®ç§’。 + +DAMON对冷内å˜ç›‘测的èšé›†é—´éš”。更多细节请å‚考DAMON文档 (:doc:`usage`)。 + +min_nr_regions +-------------- + +监测区域的最å°æ•°é‡ã€‚ + +DAMON用于冷内å˜ç›‘测的最å°ç›‘测区域数。这å¯ä»¥ç”¨æ¥è®¾ç½®ç›‘测质é‡çš„下é™ã€‚但是，设 +置的太高å¯èƒ½ä¼šå¯¼è‡´ç›‘æµ‹å¼€é”€çš„å¢žåŠ ã€‚æ›´å¤šç»†èŠ‚è¯·å‚考DAMON文档 (:doc:`usage`) 。 + +max_nr_regions +-------------- + +监测区域的最大数é‡ã€‚ + +DAMON用于冷内å˜ç›‘测的最大监测区域数。这å¯ä»¥ç”¨æ¥è®¾ç½®ç›‘测开销的上é™å€¼ã€‚但是， +设置得太低å¯èƒ½ä¼šå¯¼è‡´ç›‘测质é‡ä¸å¥½ã€‚更多细节请å‚考DAMON文档 (:doc:`usage`) 。 + +monitor_region_start +-------------------- + +ç›®æ ‡å†…å˜åŒºåŸŸçš„物ç†åœ°å€èµ·ç‚¹ã€‚ + +DAMON_RECLAIM将对其进行工作的内å˜åŒºåŸŸçš„起始物ç†åœ°å€ã€‚也就是说，DAMON_RECLAIM +将在这个区域ä¸æ‰¾åˆ°å†·çš„内å˜åŒºåŸŸå¹¶è¿›è¡Œå›žæ”¶ã€‚默认情况下，该区域使用最大系统内å˜åŒºã€‚ + +monitor_region_end +------------------ + +ç›®æ ‡å†…å˜åŒºåŸŸçš„结æŸç‰©ç†åœ°å€ã€‚ + +DAMON_RECLAIM将对其进行工作的内å˜åŒºåŸŸçš„末端物ç†åœ°å€ã€‚也就是说，DAMON_RECLAIMå°† +在这个区域内找到冷的内å˜åŒºåŸŸå¹¶è¿›è¡Œå›žæ”¶ã€‚默认情况下，该区域使用最大系统内å˜åŒºã€‚ + +kdamond_pid +----------- + +DAMON线程的PID。 + +如果DAMON_RECLAIM被å¯ç”¨ï¼Œè¿™å°†æˆä¸ºå·¥ä½œçº¿ç¨‹çš„PID。å¦åˆ™ï¼Œä¸º-1。 + +nr_reclaim_tried_regions +------------------------ + +试图通过DAMON_RECLAIM回收的内å˜åŒºåŸŸçš„æ•°é‡ã€‚ + +bytes_reclaim_tried_regions +--------------------------- + +试图通过DAMON_RECLAIM回收的内å˜åŒºåŸŸçš„总å—节数。 + +nr_reclaimed_regions +-------------------- + +通过DAMON_RECLAIMæˆåŠŸå›žæ”¶çš„内å˜åŒºåŸŸçš„æ•°é‡ã€‚ + +bytes_reclaimed_regions +----------------------- + +通过DAMON_RECLAIMæˆåŠŸå›žæ”¶çš„内å˜åŒºåŸŸçš„总å—节数。 + +nr_quota_exceeds +---------------- + +超过时间/空间é…é¢é™åˆ¶çš„次数。 + +例å +==== + +下é¢çš„è¿è¡Œç¤ºä¾‹å‘½ä»¤ä½¿DAMON_RECLAIM找到30秒或更长时间没有访问的内å˜åŒºåŸŸå¹¶â€œå›žæ”¶â€ï¼Ÿ +为了é¿å…DAMON_RECLAIM在分页æ“作ä¸æ¶ˆè€—过多的CPU时间，回收被é™åˆ¶åœ¨æ¯ç§’1GiB以内。 +它还è¦æ±‚DAMON_RECLAIM在系统的å¯ç”¨å†…å˜çŽ‡è¶…过50%æ—¶ä¸åšä»»ä½•äº‹æƒ…，但如果它低于40%æ—¶ +就开始真æ£çš„工作。如果DAMON_RECLAIM没有å–å¾—è¿›å±•ï¼Œå› æ¤ç©ºé—²å†…å˜çŽ‡ä½ŽäºŽ20%，它会è¦æ±‚ +DAMON_RECLAIMå†æ¬¡ä»€ä¹ˆéƒ½ä¸åšï¼Œè¿™æ ·æˆ‘们就å¯ä»¥é€€å›žåˆ°åŸºäºŽLRU列表的页é¢ç²’度回收了:: + + # cd /sys/modules/damon_reclaim/parameters + # echo 30000000 > min_age + # echo $((1 * 1024 * 1024 * 1024)) > quota_sz + # echo 1000 > quota_reset_interval_ms + # echo 500 > wmarks_high + # echo 400 > wmarks_mid + # echo 200 > wmarks_low + # echo Y > enabled + +.. [1] https://research.google/pubs/pub48551/ +.. [2] https://lwn.net/Articles/787611/ +.. [3] https://www.kernel.org/doc/html/latest/vm/free_page_reporting.html diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst new file mode 100644 index 000000000000..67d1b49481dc --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/start.rst @@ -0,0 +1,132 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/start.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +======== +å…¥é—¨æŒ‡å— +======== + +本文通过演示DAMON的默认用户空间工具，简è¦åœ°ä»‹ç»äº†å¦‚何使用DAMON。请注æ„ï¼Œä¸ºäº†ç®€æ´ +èµ·è§ï¼Œæœ¬æ–‡æ¡£åªæ述了它的部分功能。更多细节请å‚考该工具的使用文档。 +`doc <https://github.com/awslabs/damo/blob/next/USAGE.md>`_ . + + +å‰ææ¡ä»¶ +======== + +å†…æ ¸ +---- + +é¦–å…ˆï¼Œä½ è¦ç¡®ä¿ä½ 当å‰ç³»ç»Ÿä¸è·‘çš„å†…æ ¸æž„å»ºæ—¶é€‰å®šäº†è¿™ä¸ªåŠŸèƒ½é€‰é¡¹ ``CONFIG_DAMON_*=y``. + + +用户空间工具 +------------ + +在演示ä¸ï¼Œæˆ‘们将使用DAMON的默认用户空间工具，称为DAMON Operator（DAMO）。它å¯ä»¥åœ¨ +https://github.com/awslabs/damo找到。下é¢çš„例åå‡è®¾DAMOåœ¨ä½ çš„$PATH上。当然，但 +这并ä¸æ˜¯å¼ºåˆ¶æ€§çš„。 + +å› ä¸ºDAMO使用的是DAMONçš„debugfs接å£(详情请å‚考 :doc:`usage` ä¸çš„使用方法) ä½ åº”è¯¥ +ç¡®ä¿debugfs被挂载。手动挂载它，如下所示:: + + # mount -t debugfs none /sys/kernel/debug/ + +æˆ–è€…åœ¨ä½ çš„ ``/etc/fstab`` 文件ä¸æ·»åŠ ä»¥ä¸‹ä¸€è¡Œï¼Œè¿™æ ·ä½ çš„ç³»ç»Ÿå°±å¯ä»¥åœ¨å¯åŠ¨æ—¶è‡ªåŠ¨æŒ‚è½½ +debugfs了:: + + debugfs /sys/kernel/debug debugfs defaults 0 0 + + +记录数æ®è®¿é—®æ¨¡å¼ +================ + +下é¢çš„命令记录了一个程åºçš„内å˜è®¿é—®æ¨¡å¼ï¼Œå¹¶å°†ç›‘测结果ä¿å˜åˆ°æ–‡ä»¶ä¸ã€‚ :: + + $ git clone https://github.com/sjp38/masim + $ cd masim; make; ./masim ./configs/zigzag.cfg & + $ sudo damo record -o damon.data $(pidof masim) + +命令的å‰ä¸¤è¡Œä¸‹è½½äº†ä¸€ä¸ªäººå·¥å†…å˜è®¿é—®ç”Ÿæˆå™¨ç¨‹åºå¹¶åœ¨åŽå°è¿è¡Œã€‚生æˆå™¨å°†é‡å¤åœ°é€ä¸€è®¿é—®ä¸¤ä¸ª +100 MiB大å°çš„内å˜åŒºåŸŸã€‚ä½ å¯ä»¥ç”¨ä½ 的真实工作负载æ¥ä»£æ›¿å®ƒã€‚最åŽä¸€è¡Œè¦æ±‚ ``damo`` å°† +访问模å¼è®°å½•åœ¨ ``damon.data`` 文件ä¸ã€‚ + + +将记录的模å¼å¯è§†åŒ– +================== + +ä½ å¯ä»¥åœ¨heatmapä¸ç›´è§‚地看到这ç§æ¨¡å¼ï¼Œæ˜¾ç¤ºå“ªä¸ªå†…å˜åŒºåŸŸï¼ˆX轴）何时被访问（Y轴）以åŠè®¿ +问的频率（数å—）。:: + + $ sudo damo report heats --heatmap stdout + 22222222222222222222222222222222222222211111111111111111111111111111111111111100 + 44444444444444444444444444444444444444434444444444444444444444444444444444443200 + 44444444444444444444444444444444444444433444444444444444444444444444444444444200 + 33333333333333333333333333333333333333344555555555555555555555555555555555555200 + 33333333333333333333333333333333333344444444444444444444444444444444444444444200 + 22222222222222222222222222222222222223355555555555555555555555555555555555555200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + 33333333333333333333333333333333333333355555555555555555555555555555555555555200 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 88888888888888888888888888888888888888600000000000000000000000000000000000000000 + 33333333333333333333333333333333333333444444444444444444444444444444444444443200 + 00000000000000000000000000000000000000288888888888888888888888888888888888888400 + [...] + # access_frequency: 0 1 2 3 4 5 6 7 8 9 + # x-axis: space (139728247021568-139728453431248: 196.848 MiB) + # y-axis: time (15256597248362-15326899978162: 1 m 10.303 s) + # resolution: 80x40 (2.461 MiB and 1.758 s for each character) + +ä½ ä¹Ÿå¯ä»¥ç›´è§‚地看到工作集的大å°åˆ†å¸ƒï¼ŒæŒ‰å¤§å°æŽ’åºã€‚:: + + $ sudo damo report wss --range 0 101 10 + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 0 B | | + 10 95.328 MiB |**************************** | + 20 95.332 MiB |**************************** | + 30 95.340 MiB |**************************** | + 40 95.387 MiB |**************************** | + 50 95.387 MiB |**************************** | + 60 95.398 MiB |**************************** | + 70 95.398 MiB |**************************** | + 80 95.504 MiB |**************************** | + 90 190.703 MiB |********************************************************* | + 100 196.875 MiB |***********************************************************| + +在上述命令ä¸ä½¿ç”¨ ``--sortby`` 选项，å¯ä»¥æ˜¾ç¤ºå·¥ä½œé›†çš„大å°æ˜¯å¦‚何按时间顺åºå˜åŒ–的。:: + + $ sudo damo report wss --range 0 101 10 --sortby time + # <percentile> <wss> + # target_id 18446632103789443072 + # avr: 107.708 MiB + 0 3.051 MiB | | + 10 190.703 MiB |***********************************************************| + 20 95.336 MiB |***************************** | + 30 95.328 MiB |***************************** | + 40 95.387 MiB |***************************** | + 50 95.332 MiB |***************************** | + 60 95.320 MiB |***************************** | + 70 95.398 MiB |***************************** | + 80 95.398 MiB |***************************** | + 90 95.340 MiB |***************************** | + 100 95.398 MiB |***************************** | + + +æ•°æ®è®¿é—®æ¨¡å¼æ„ŸçŸ¥çš„内å˜ç®¡ç† +========================== + +以下三个命令使æ¯ä¸€ä¸ªå¤§å°>=4K的内å˜åŒºåŸŸåœ¨ä½ 的工作负载ä¸æ²¡æœ‰è¢«è®¿é—®>=60秒，就会被æ¢æŽ‰ã€‚ :: + + $ echo "#min-size max-size min-acc max-acc min-age max-age action" > test_scheme + $ echo "4K max 0 0 60s max pageout" >> test_scheme + $ damo schemes -c test_scheme <pid of your workload> diff --git a/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst new file mode 100644 index 000000000000..5d7533347216 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/damon/usage.rst @@ -0,0 +1,286 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/damon/usage.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +======== +详细用法 +======== + +DAMON 为ä¸åŒçš„用户æ供了下é¢ä¸‰ç§æŽ¥å£ã€‚ + +- *DAMON用户空间工具。* + `è¿™ <https://github.com/awslabs/damo>`_ 为有这特æƒçš„人， 如系统管ç†å‘˜ï¼Œå¸Œæœ›æœ‰ä¸€ä¸ªåˆšå¥½ + å¯ä»¥å·¥ä½œçš„人性化界é¢ã€‚ + 使用它，用户å¯ä»¥ä»¥äººæ€§åŒ–çš„æ–¹å¼ä½¿ç”¨DAMON的主è¦åŠŸèƒ½ã€‚ä¸è¿‡ï¼Œå®ƒå¯èƒ½ä¸ä¼šä¸ºç‰¹æ®Šæƒ…况进行高度调整。 + 它åŒæ—¶æ”¯æŒè™šæ‹Ÿå’Œç‰©ç†åœ°å€ç©ºé—´çš„监测。更多细节，请å‚考它的 `使用文档 + <https://github.com/awslabs/damo/blob/next/USAGE.md>`_。 +- *debugfs接å£ã€‚* + :ref:`è¿™ <debugfs_interface>` 是为那些希望更高级的使用DAMON的特æƒç”¨æˆ·ç©ºé—´ç¨‹åºå‘˜å‡†å¤‡çš„。 + 使用它，用户å¯ä»¥é€šè¿‡è¯»å–和写入特殊的debugfs文件æ¥ä½¿ç”¨DAMON的主è¦åŠŸèƒ½ã€‚å› æ¤ï¼Œä½ å¯ä»¥ç¼–写和使 + ç”¨ä½ ä¸ªæ€§åŒ–çš„DAMON debugfs包装程åºï¼Œä»£æ›¿ä½ 读/写debugfs文件。 `DAMON用户空间工具 + <https://github.com/awslabs/damo>`_ 就是这ç§ç¨‹åºçš„一个例å 它åŒæ—¶æ”¯æŒè™šæ‹Ÿå’Œç‰©ç†åœ°å€ + 空间的监测。注æ„，这个界é¢åªæ供简å•çš„监测结果 :ref:`统计 <damos_stats>`。对于详细的监测 + 结果，DAMONæ供了一个:ref:`跟踪点 <tracepoint>`。 + +- *å†…æ ¸ç©ºé—´ç¼–ç¨‹æŽ¥å£ã€‚* + :doc:`This </vm/damon/api>` è¿™æ˜¯ä¸ºå†…æ ¸ç©ºé—´ç¨‹åºå‘˜å‡†å¤‡çš„。使用它，用户å¯ä»¥é€šè¿‡ä¸ºä½ 编写内 + æ ¸ç©ºé—´çš„DAMON应用程åºï¼Œæœ€çµæ´»æœ‰æ•ˆåœ°åˆ©ç”¨DAMONçš„æ¯ä¸€ä¸ªåŠŸèƒ½ã€‚ä½ ç”šè‡³å¯ä»¥ä¸ºå„ç§åœ°å€ç©ºé—´æ‰©å±•DAMON。 + 详细情况请å‚è€ƒæŽ¥å£ :doc:`文件 </vm/damon/api>`。 + + +debugfsæŽ¥å£ +=========== + +DAMON导出了八个文件, ``attrs``, ``target_ids``, ``init_regions``, +``schemes``, ``monitor_on``, ``kdamond_pid``, ``mk_contexts`` å’Œ +``rm_contexts`` under its debugfs directory, ``<debugfs>/damon/``. + + +属性 +---- + +用户å¯ä»¥é€šè¿‡è¯»å–和写入 ``attrs`` 文件获得和设置 ``é‡‡æ ·é—´éš”`` 〠``èšé›†é—´éš”`` 〠``区域更新间隔`` +以åŠç›‘æµ‹ç›®æ ‡åŒºåŸŸçš„æœ€å°/最大数é‡ã€‚è¦è¯¦ç»†äº†è§£ç›‘测属性，请å‚考 `:doc:/vm/damon/design` 。例如， +下é¢çš„命令将这些值设置为5msã€100msã€1000msã€10å’Œ1000，然åŽå†æ¬¡æ£€æŸ¥:: + + # cd <debugfs>/damon + # echo 5000 100000 1000000 10 1000 > attrs + # cat attrs + 5000 100000 1000000 10 1000 + + +ç›®æ ‡ID +------ + +一些类型的地å€ç©ºé—´æ”¯æŒå¤šä¸ªç›‘æµ‹ç›®æ ‡ã€‚ä¾‹å¦‚ï¼Œè™šæ‹Ÿå†…å˜åœ°å€ç©ºé—´çš„监测å¯ä»¥æœ‰å¤šä¸ªè¿›ç¨‹ä½œä¸ºç›‘æµ‹ç›®æ ‡ã€‚ç”¨æˆ· +å¯ä»¥é€šè¿‡å†™å…¥ç›®æ ‡çš„相关id值æ¥è®¾ç½®ç›®æ ‡ï¼Œå¹¶é€šè¿‡è¯»å– ``target_ids`` 文件æ¥èŽ·å¾—当å‰ç›®æ ‡çš„id。在监 +测虚拟地å€ç©ºé—´çš„æƒ…å†µä¸‹ï¼Œè¿™äº›å€¼åº”è¯¥æ˜¯ç›‘æµ‹ç›®æ ‡è¿›ç¨‹çš„pid。例如，下é¢çš„命令将pid为42å’Œ4242的进程设 +ä¸ºç›‘æµ‹ç›®æ ‡ï¼Œå¹¶å†æ¬¡æ£€æŸ¥:: + + # cd <debugfs>/damon + # echo 42 4242 > target_ids + # cat target_ids + 42 4242 + +用户还å¯ä»¥é€šè¿‡åœ¨æ–‡ä»¶ä¸å†™å…¥ä¸€ä¸ªç‰¹æ®Šçš„å…³é”®å— "paddr\n" æ¥ç›‘测系统的物ç†å†…å˜åœ°å€ç©ºé—´ã€‚å› ä¸ºç‰©ç†åœ° +å€ç©ºé—´ç›‘测ä¸æ”¯æŒå¤šä¸ªç›®æ ‡ï¼Œè¯»å–文件会显示一个å‡å€¼ï¼Œå³ ``42`` ，如下图所示:: + + # cd <debugfs>/damon + # echo paddr > target_ids + # cat target_ids + 42 + +请注æ„ï¼Œè®¾ç½®ç›®æ ‡ID并ä¸å¯åŠ¨ç›‘测。 + + +åˆå§‹ç›‘æµ‹ç›®æ ‡åŒºåŸŸ +---------------- + +在虚拟地å€ç©ºé—´ç›‘测的情况下，DAMONè‡ªåŠ¨è®¾ç½®å’Œæ›´æ–°ç›‘æµ‹çš„ç›®æ ‡åŒºåŸŸï¼Œè¿™æ ·å°±å¯ä»¥è¦†ç›–ç›®æ ‡è¿›ç¨‹çš„æ•´ä¸ª +内å˜æ˜ 射。然而，用户å¯èƒ½å¸Œæœ›å°†ç›‘测区域é™åˆ¶åœ¨ç‰¹å®šçš„地å€èŒƒå›´å†…ï¼Œå¦‚å †ã€æ ˆæˆ–ç‰¹å®šçš„æ–‡ä»¶æ˜ å°„åŒºåŸŸã€‚ +或者，一些用户å¯ä»¥çŸ¥é“他们工作负载的åˆå§‹è®¿é—®æ¨¡å¼ï¼Œå› æ¤å¸Œæœ›ä¸ºâ€œè‡ªé€‚应区域调整â€è®¾ç½®æœ€ä½³åˆå§‹åŒºåŸŸã€‚ + +相比之下，DAMON在物ç†å†…å˜ç›‘测的情况下ä¸ä¼šè‡ªåŠ¨è®¾ç½®å’Œæ›´æ–°ç›‘æµ‹ç›®æ ‡åŒºåŸŸã€‚å› æ¤ï¼Œç”¨æˆ·åº”该自己设置 +ç›‘æµ‹ç›®æ ‡åŒºåŸŸã€‚ + +在这ç§æƒ…况下，用户å¯ä»¥é€šè¿‡åœ¨ ``init_regions`` 文件ä¸å†™å…¥é€‚当的值，明确地设置他们想è¦çš„åˆ +å§‹ç›‘æµ‹ç›®æ ‡åŒºåŸŸã€‚è¾“å…¥çš„æ¯ä¸€è¡Œåº”代表一个区域，形å¼å¦‚下:: + + <target idx> <start address> <end address> + +ç›®æ ‡idx应该是 ``target_ids`` 文件ä¸ç›®æ ‡çš„索引，从 ``0`` 开始，区域应该按照地å€é¡ºåºä¼ 递。 +例如，下é¢çš„å‘½ä»¤å°†è®¾ç½®å‡ ä¸ªåœ°å€èŒƒå›´ï¼Œ ``1-100`` å’Œ ``100-200`` 作为pid 42çš„åˆå§‹ç›‘æµ‹ç›®æ ‡ +区域，这是 ``target_ids`` ä¸çš„第一个（索引 ``0`` ），å¦å¤–å‡ ä¸ªåœ°å€èŒƒå›´ï¼Œ ``20-40`` å’Œ +``50-100`` 作为pid 4242的地å€ï¼Œè¿™æ˜¯ ``target_ids`` ä¸çš„第二个（索引 ``1`` ）:: + + # cd <debugfs>/damon + # cat target_ids + 42 4242 + # echo "0 1 100 + 0 100 200 + 1 20 40 + 1 50 100" > init_regions + +请注æ„，这åªæ˜¯è®¾ç½®äº†åˆå§‹çš„ç›‘æµ‹ç›®æ ‡åŒºåŸŸã€‚åœ¨è™šæ‹Ÿå†…å˜ç›‘测的情况下，DAMON会在一个 ``区域更新间隔`` +åŽè‡ªåŠ¨æ›´æ–°åŒºåŸŸçš„è¾¹ç•Œã€‚å› æ¤ï¼Œåœ¨è¿™ç§æƒ…况下，如果用户ä¸å¸Œæœ›æ›´æ–°çš„è¯ï¼Œåº”该把 ``区域的更新间隔`` 设 +置得足够大。 + + +方案 +---- + +对于通常的基于DAMONçš„æ•°æ®è®¿é—®æ„ŸçŸ¥çš„内å˜ç®¡ç†ä¼˜åŒ–，用户åªæ˜¯å¸Œæœ›ç³»ç»Ÿå¯¹ç‰¹å®šè®¿é—®æ¨¡å¼çš„内å˜åŒºåŸŸåº”用内 +å˜ç®¡ç†æ“作。DAMON从用户那里接收这ç§å½¢å¼åŒ–çš„æ“ä½œæ–¹æ¡ˆï¼Œå¹¶å°†è¿™äº›æ–¹æ¡ˆåº”ç”¨åˆ°ç›®æ ‡è¿›ç¨‹ä¸ã€‚ + +用户å¯ä»¥é€šè¿‡è¯»å–和写入 ``scheme`` debugfs文件æ¥èŽ·å¾—和设置这些方案。读å–该文件还å¯ä»¥æ˜¾ç¤ºæ¯ä¸ª +方案的统计数æ®ã€‚在文件ä¸ï¼Œæ¯ä¸€ä¸ªæ–¹æ¡ˆéƒ½åº”该在æ¯ä¸€è¡Œä¸ä»¥ä¸‹åˆ—å½¢å¼è¡¨ç¤ºå‡ºæ¥:: + + <target access pattern> <action> <quota> <watermarks> + +ä½ å¯ä»¥é€šè¿‡ç®€å•åœ°åœ¨æ–‡ä»¶ä¸å†™å…¥ä¸€ä¸ªç©ºå—符串æ¥ç¦ç”¨æ–¹æ¡ˆã€‚ + +ç›®æ ‡è®¿é—®æ¨¡å¼ +~~~~~~~~~~~~ + +``<ç›®æ ‡è®¿é—®æ¨¡å¼>`` 是由三个范围构æˆçš„，形å¼å¦‚下:: + + min-size max-size min-acc max-acc min-age max-age + +具体æ¥è¯´ï¼ŒåŒºåŸŸå¤§å°çš„å—节数（ `min-size` å’Œ `max-size` ），访问频率的æ¯èšåˆåŒºé—´çš„监测访问次 +数（ `min-acc` å’Œ `max-acc` ），区域年龄的èšåˆåŒºé—´æ•°ï¼ˆ `min-age` å’Œ `max-age` ）都被指定。 +请注æ„，这些范围是å°é—区间。 + +动作 +~~~~ + +``<action>`` 是一个预定义的内å˜ç®¡ç†åŠ¨ä½œçš„整数，DAMONå°†åº”ç”¨äºŽå…·æœ‰ç›®æ ‡è®¿é—®æ¨¡å¼çš„åŒºåŸŸã€‚æ”¯æŒ +çš„æ•°å—和它们的å«ä¹‰å¦‚下:: + + - 0: Call ``madvise()`` for the region with ``MADV_WILLNEED`` + - 1: Call ``madvise()`` for the region with ``MADV_COLD`` + - 2: Call ``madvise()`` for the region with ``MADV_PAGEOUT`` + - 3: Call ``madvise()`` for the region with ``MADV_HUGEPAGE`` + - 4: Call ``madvise()`` for the region with ``MADV_NOHUGEPAGE`` + - 5: Do nothing but count the statistics + +é…é¢ +~~~~ + +æ¯ä¸ª ``动作`` 的最佳 ``ç›®æ ‡è®¿é—®æ¨¡å¼`` å–决于工作负载，所以ä¸å®¹æ˜“找到。更糟糕的是，将æŸä¸ª +动作的方案设置得过于激进会导致严é‡çš„开销。为了é¿å…è¿™ç§å¼€é”€ï¼Œç”¨æˆ·å¯ä»¥é€šè¿‡ä¸‹é¢è¡¨æ ¼ä¸çš„ ``<quota>`` +æ¥é™åˆ¶æ–¹æ¡ˆçš„时间和大å°é…é¢:: + + <ms> <sz> <reset interval> <priority weights> + +这使得DAMON在 ``<reset interval>`` 毫秒内，尽é‡åªç”¨ ``<ms>`` 毫秒的时间对 ``ç›®æ ‡è®¿ +问模å¼`` 的内å˜åŒºåŸŸåº”用动作，并在 ``<reset interval>`` 内åªå¯¹æœ€å¤š<sz>å—节的内å˜åŒºåŸŸåº” +用动作。将 ``<ms>`` å’Œ ``<sz>`` 都设置为零，å¯ä»¥ç¦ç”¨é…é¢é™åˆ¶ã€‚ + +当预计超过é…é¢é™åˆ¶æ—¶ï¼ŒDAMONä¼šæ ¹æ® ``ç›®æ ‡è®¿é—®æ¨¡å¼`` 的大å°ã€è®¿é—®é¢‘率和年龄，对å‘çŽ°çš„å†…å˜ +区域进行优先排åºã€‚为了实现个性化的优先级，用户å¯ä»¥åœ¨ ``<优先级æƒé‡>`` ä¸è®¾ç½®è¿™ä¸‰ä¸ªå±žæ€§çš„ +æƒé‡ï¼Œå…·ä½“å½¢å¼å¦‚下:: + + <size weight> <access frequency weight> <age weight> + +æ°´ä½ +~~~~ + +有些方案需è¦æ ¹æ®ç³»ç»Ÿç‰¹å®šæŒ‡æ ‡çš„当å‰å€¼æ¥è¿è¡Œï¼Œå¦‚自由内å˜æ¯”率。对于这ç§æƒ…况，用户å¯ä»¥ä¸ºè¯¥æ¡ +件指定水ä½ã€‚:: + + <metric> <check interval> <high mark> <middle mark> <low mark> + +``<metric>`` 是一个预定义的整数，用于è¦æ£€æŸ¥çš„度é‡ã€‚支æŒçš„æ•°å—和它们的å«ä¹‰å¦‚下。 + + - 0: å¿½è§†æ°´ä½ + - 1: 系统空闲内å˜çŽ‡ (åƒåˆ†æ¯”) + +æ¯éš” ``<检查间隔>`` 微秒检查一次公制的值。 + +如果该值高于 ``<é«˜æ ‡>`` 或低于 ``<ä½Žæ ‡>`` ，该方案被åœç”¨ã€‚如果该值低于 ``<ä¸æ ‡>`` ， +该方案将被激活。 + +ç»Ÿè®¡æ•°æ® +~~~~~~~~ + +它还统计æ¯ä¸ªæ–¹æ¡ˆè¢«å°è¯•åº”用的区域的总数é‡å’Œå—节数，æ¯ä¸ªæ–¹æ¡ˆè¢«æˆåŠŸåº”用的区域的两个数é‡ï¼Œä»¥ +åŠè¶…过é…é¢é™åˆ¶çš„总数é‡ã€‚这些统计数æ®å¯ç”¨äºŽåœ¨çº¿åˆ†æžæˆ–调整方案。 + +统计数æ®å¯ä»¥é€šè¿‡è¯»å–方案文件æ¥æ˜¾ç¤ºã€‚读å–è¯¥æ–‡ä»¶å°†æ˜¾ç¤ºä½ åœ¨æ¯ä¸€è¡Œä¸è¾“入的æ¯ä¸ª ``方案`` ， +统计的五个数å—å°†è¢«åŠ åœ¨æ¯ä¸€è¡Œçš„末尾。 + +例å +~~~~ + +下é¢çš„命令应用了一个方案：â€å¦‚果一个大å°ä¸º[4KiB, 8KiB]的内å˜åŒºåŸŸåœ¨[10, 20]çš„èšåˆæ—¶é—´ +间隔内显示出æ¯ä¸€ä¸ªèšåˆæ—¶é—´é—´éš”[0, 5]的访问é‡ï¼Œè¯·åˆ†é¡µå‡ºè¯¥åŒºåŸŸã€‚对于分页，æ¯ç§’最多åªèƒ½ä½¿ +用10ms，而且æ¯ç§’分页ä¸èƒ½è¶…过1GiB。在这一é™åˆ¶ä¸‹ï¼Œé¦–先分页出具有较长年龄的内å˜åŒºåŸŸã€‚å¦å¤–， +æ¯5秒钟检查一次系统的å¯ç”¨å†…å˜çŽ‡ï¼Œå½“å¯ç”¨å†…å˜çŽ‡ä½ŽäºŽ50%时开始监测和分页，但如果å¯ç”¨å†…å˜çŽ‡ +大于60%，或低于30%，则åœæ¢ç›‘测“:: + + # cd <debugfs>/damon + # scheme="4096 8192 0 5 10 20 2" # target access pattern and action + # scheme+=" 10 $((1024*1024*1024)) 1000" # quotas + # scheme+=" 0 0 100" # prioritization weights + # scheme+=" 1 5000000 600 500 300" # watermarks + # echo "$scheme" > schemes + + +开关 +---- + +除éžä½ 明确地å¯åŠ¨ç›‘测，å¦åˆ™å¦‚上所述的文件设置ä¸ä¼šäº§ç”Ÿæ•ˆæžœã€‚ä½ å¯ä»¥é€šè¿‡å†™å…¥å’Œè¯»å– ``monitor_on`` +文件æ¥å¯åŠ¨ã€åœæ¢å’Œæ£€æŸ¥ç›‘测的当å‰çŠ¶æ€ã€‚写入 ``on`` 该文件å¯ä»¥å¯åŠ¨å¯¹æœ‰å±žæ€§çš„ç›®æ ‡çš„ç›‘æµ‹ã€‚å†™å…¥ +``off`` 该文件则åœæ¢è¿™äº›ç›®æ ‡ã€‚如果æ¯ä¸ªç›®æ ‡è¿›ç¨‹è¢«ç»ˆæ¢ï¼ŒDAMON也会åœæ¢ã€‚下é¢çš„示例命令开å¯ã€å…³ +é—和检查DAMON的状æ€:: + + # cd <debugfs>/damon + # echo on > monitor_on + # echo off > monitor_on + # cat monitor_on + off + +请注æ„，当监测开å¯æ—¶ï¼Œä½ ä¸èƒ½å†™åˆ°ä¸Šè¿°çš„debugfsæ–‡ä»¶ã€‚å¦‚æžœä½ åœ¨DAMONè¿è¡Œæ—¶å†™åˆ°è¿™äº›æ–‡ä»¶ï¼Œå°†ä¼šè¿” +回一个错误代ç ，如 ``-EBUSY`` 。 + + +监测线程PID +----------- + +DAMON通过一个å«åškdamondçš„å†…æ ¸çº¿ç¨‹æ¥è¿›è¡Œè¯·æ±‚ç›‘æµ‹ã€‚ä½ å¯ä»¥é€šè¿‡è¯»å– ``kdamond_pid`` 文件获 +得该线程的 ``pid`` 。当监测被 ``å…³é—`` 时，读å–该文件ä¸ä¼šè¿”回任何信æ¯:: + + # cd <debugfs>/damon + # cat monitor_on + off + # cat kdamond_pid + none + # echo on > monitor_on + # cat kdamond_pid + 18594 + + +使用多个监测线程 +---------------- + +æ¯ä¸ªç›‘测上下文都会创建一个 ``kdamond`` çº¿ç¨‹ã€‚ä½ å¯ä»¥ä½¿ç”¨ ``mk_contexts`` å’Œ ``rm_contexts`` +文件为多个 ``kdamond`` 需è¦çš„ç”¨ä¾‹åˆ›å»ºå’Œåˆ é™¤ç›‘æµ‹ä¸Šä¸‹æ–‡ã€‚ + +将新上下文的å称写入 ``mk_contexts`` 文件，在 ``DAMON debugfs`` 目录上创建一个该å称的目录。 +该目录将有该上下文的 ``DAMON debugfs`` 文件:: + + # cd <debugfs>/damon + # ls foo + # ls: cannot access 'foo': No such file or directory + # echo foo > mk_contexts + # ls foo + # attrs init_regions kdamond_pid schemes target_ids + +如果ä¸å†éœ€è¦ä¸Šä¸‹æ–‡ï¼Œä½ å¯ä»¥é€šè¿‡æŠŠä¸Šä¸‹æ–‡çš„åå—放到 ``rm_contexts`` 文件ä¸æ¥åˆ 除它和相应的目录:: + + # echo foo > rm_contexts + # ls foo + # ls: cannot access 'foo': No such file or directory + +注æ„， ``mk_contexts`` 〠``rm_contexts`` å’Œ ``monitor_on`` 文件åªåœ¨æ ¹ç›®å½•ä¸‹ã€‚ + + +监测结果的监测点 +================ + +DAMON通过一个tracepoint ``damon:damon_aggregated`` æ供监测结果. 当监测开å¯æ—¶ï¼Œä½ å¯ +以记录追踪点事件，并使用追踪点支æŒå·¥å…·å¦‚perf显示结果。比如说:: + + # echo on > monitor_on + # perf record -e damon:damon_aggregated & + # sleep 5 + # kill 9 $(pidof perf) + # echo off > monitor_on + # perf script diff --git a/Documentation/translations/zh_CN/admin-guide/mm/index.rst b/Documentation/translations/zh_CN/admin-guide/mm/index.rst new file mode 100644 index 000000000000..702271c5b683 --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/index.rst @@ -0,0 +1,49 @@ +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/index.rst + +:翻译: + + å¾é‘« xu xin <xu.xin16@zte.com.cn> + + +======== +内å˜ç®¡ç† +======== + +Linux内å˜ç®¡ç†å系统，顾åæ€ä¹‰ï¼Œæ˜¯è´Ÿè´£ç³»ç»Ÿä¸çš„内å˜ç®¡ç†ã€‚它包括了虚拟内å˜ä¸Žè¯·æ±‚ +åˆ†é¡µçš„å®žçŽ°ï¼Œå†…æ ¸å†…éƒ¨ç»“æž„å’Œç”¨æˆ·ç©ºé—´ç¨‹åºçš„内å˜åˆ†é…ã€å°†æ–‡ä»¶æ˜ 射到进程地å€ç©ºé—´ä»¥ +åŠè®¸å¤šå…¶ä»–很酷的事情。 + +Linux内å˜ç®¡ç†æ˜¯ä¸€ä¸ªå…·æœ‰è®¸å¤šå¯é…置设置的å¤æ‚系统, 且这些设置ä¸çš„大多数都å¯ä»¥é€š +过 ``/proc`` 文件系统获得，并且å¯ä»¥ä½¿ç”¨ ``sysctl`` 进行查询和调整。这些API接 +å£è¢«æ述在Documentation/admin-guide/sysctl/vm.rst文件和 `man 5 proc`_ ä¸ã€‚ + +.. _man 5 proc: http://man7.org/linux/man-pages/man5/proc.5.html + +Linux内å˜ç®¡ç†æœ‰å®ƒè‡ªå·±çš„术è¯ï¼Œå¦‚æžœä½ è¿˜ä¸ç†Ÿæ‚‰å®ƒï¼Œè¯·è€ƒè™‘阅读下é¢å‚考： +:ref:`Documentation/admin-guide/mm/concepts.rst <mm_concepts>`. + +在æ¤ç›®å½•ä¸‹ï¼Œæˆ‘们详细æ述了如何与Linux内å˜ç®¡ç†ä¸çš„å„ç§æœºåˆ¶äº¤äº’。 + +.. toctree:: + :maxdepth: 1 + + damon/index + ksm + +Todolist: +* concepts +* cma_debugfs +* hugetlbpage +* idle_page_tracking +* memory-hotplug +* nommu-mmap +* numa_memory_policy +* numaperf +* pagemap +* soft-dirty +* swap_numa +* transhuge +* userfaultfd +* zswap diff --git a/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst new file mode 100644 index 000000000000..4829156ef1ae --- /dev/null +++ b/Documentation/translations/zh_CN/admin-guide/mm/ksm.rst @@ -0,0 +1,148 @@ +.. include:: ../../disclaimer-zh_CN.rst + +:Original: Documentation/admin-guide/mm/ksm.rst + +:翻译: + + å¾é‘« xu xin <xu.xin16@zte.com.cn> + + +============ +å†…æ ¸åŒé¡µåˆå¹¶ +============ + + +概述 +==== + +KSM是一ç§èƒ½èŠ‚çœå†…å˜çš„æ•°æ®åŽ»é‡åŠŸèƒ½ï¼Œç”±CONFIG_KSM=yå¯ç”¨ï¼Œå¹¶åœ¨2.6.32版本时被添 +åŠ åˆ°Linuxå†…æ ¸ã€‚è¯¦è§ ``mm/ksm.c`` 的实现，以åŠhttp://lwn.net/Articles/306704 +å’Œhttps://lwn.net/Articles/330589 + +KSM最åˆç›®çš„是为了与KVM（å³è‘—åçš„å†…æ ¸å…±äº«å†…å˜ï¼‰ä¸€èµ·ä½¿ç”¨è€Œå¼€å‘的，通过共享虚拟机 +之间的公共数æ®ï¼Œå°†æ›´å¤šè™šæ‹Ÿæœºæ”¾å…¥ç‰©ç†å†…å˜ã€‚但它对于任何会生æˆå¤šä¸ªç›¸åŒæ•°æ®å®žä¾‹çš„ +应用程åºéƒ½æ˜¯å¾ˆæœ‰ç”¨çš„。 + +KSM的守护进程ksmd会定期扫æ那些已注册的用户内å˜åŒºåŸŸï¼ŒæŸ¥æ‰¾å†…容相åŒçš„页é¢ï¼Œè¿™äº› +页é¢å¯ä»¥è¢«å•ä¸ªå†™ä¿æŠ¤é¡µé¢æ›¿æ¢ï¼ˆå¦‚果进程以åŽæƒ³è¦æ›´æ–°å…¶å†…容，将自动å¤åˆ¶ï¼‰ã€‚使用： +引用:`sysfs intraface <ksm_sysfs>` 接å£æ¥é…ç½®KSM守护程åºåœ¨å•ä¸ªè¿‡ç¨‹ä¸æ‰€æ‰«æ的页 +数以åŠä¸¤ä¸ªè¿‡ç¨‹ä¹‹é—´çš„间隔时间。 + +KSMåªåˆå¹¶åŒ¿å（ç§æœ‰ï¼‰é¡µé¢ï¼Œä»Žä¸åˆå¹¶é¡µç¼“å˜ï¼ˆæ–‡ä»¶ï¼‰é¡µé¢ã€‚KSMçš„åˆå¹¶é¡µé¢æœ€åˆåªèƒ½è¢« +é”å®šåœ¨å†…æ ¸å†…å˜ä¸ï¼Œä½†çŽ°åœ¨å¯ä»¥å°±åƒå…¶ä»–用户页é¢ä¸€æ ·è¢«æ¢å‡ºï¼ˆä½†å½“它们被交æ¢å›žæ¥æ—¶å…± +äº«ä¼šè¢«ç ´å: ksmdå¿…é¡»é‡æ–°å‘现它们的身份并å†æ¬¡åˆå¹¶ï¼‰ã€‚ + +以madvise控制KSM +================ + +KSM仅在特定的地å€ç©ºé—´åŒºåŸŸæ—¶è¿è¡Œï¼Œå³åº”用程åºé€šè¿‡ä½¿ç”¨å¦‚下所示的madvise(2)系统调 +用æ¥è¯·æ±‚æŸå—地å€æˆä¸ºå¯èƒ½çš„åˆå¹¶å€™é€‰è€…的地å€ç©ºé—´:: + + int madvise(addr, length, MADV_MERGEABLE) + +应用程åºå½“然也å¯ä»¥é€šè¿‡è°ƒç”¨:: + + int madvise(addr, length, MADV_UNMERGEABLE) + +æ¥å–消该请求，并æ¢å¤ä¸ºéžå…±äº«é¡µé¢ï¼šæ¤æ—¶KSM将去除åˆå¹¶åœ¨è¯¥èŒƒå›´å†…的任何åˆå¹¶é¡µã€‚注æ„： +这个去除åˆå¹¶çš„调用å¯èƒ½çªç„¶éœ€è¦çš„内å˜é‡è¶…过实际å¯ç”¨çš„内å˜é‡-那么å¯èƒ½ä¼šå‡ºçŽ°EAGAIN +失败，但更å¯èƒ½ä¼šå”¤é†’OOM killer。 + +如果KSM未被é…置到æ£åœ¨è¿è¡Œçš„å†…æ ¸ä¸ï¼Œåˆ™madvise MADV_MERGEABLE å’Œ MADV_UNMERGEABLE +的调用åªä¼šä»¥EINVAL 失败。如果æ£åœ¨è¿è¡Œçš„å†…æ ¸æ˜¯ç”¨CONFIG_KSM=yæ–¹å¼æž„建的，那么这些 +调用通常会æˆåŠŸï¼šå³ä½¿KSM守护程åºå½“å‰æ²¡æœ‰è¿è¡Œï¼ŒMADV_MERGEABLE ä»ç„¶ä¼šåœ¨KSMå®ˆæŠ¤ç¨‹åº +å¯åŠ¨æ—¶æ³¨å†ŒèŒƒå›´ï¼Œå³ä½¿è¯¥èŒƒå›´ä¸èƒ½åŒ…å«KSM实际å¯ä»¥åˆå¹¶çš„任何页é¢ï¼Œå³ä½¿MADV_UNMERGEABLE +åº”ç”¨äºŽä»Žæœªæ ‡è®°ä¸ºMADV_MERGEABLE的范围。 + +如果一å—内å˜åŒºåŸŸå¿…须被拆分为至少一个新的MADV_MERGEABLE区域或MADV_UNMERGEABLE区域， +当该进程将超过 ``vm.max_map_count`` 的设定，则madviseå¯èƒ½è¿”回ENOMEM。（请å‚阅文档 +Documentation/admin-guide/sysctl/vm.rst）。 + +与其他madviseè°ƒç”¨ä¸€æ ·ï¼Œå®ƒä»¬åœ¨ç”¨æˆ·åœ°å€ç©ºé—´çš„æ˜ å°„åŒºåŸŸä¸Šä½¿ç”¨ï¼šå¦‚æžœæŒ‡å®šçš„èŒƒå›´åŒ…å«æœª +æ˜ å°„çš„é—´éš™ï¼ˆå°½ç®¡åœ¨ä¸é—´çš„æ˜ å°„åŒºåŸŸå·¥ä½œï¼‰ï¼Œå®ƒä»¬å°†æŠ¥å‘ŠENOMEM，如果没有足够的内å˜ç”¨äºŽ +内部结构，则å¯èƒ½ä¼šå› EAGAIN而失败。 + +KSM守护进程sysfsæŽ¥å£ +==================== + +KSM守护进程å¯ä»¥ç”±``/sys/kernel/mm/ksm/`` ä¸çš„sysfs文件控制，所有人都å¯ä»¥è¯»å–，但 +åªèƒ½ç”±root用户写入。å„接å£è§£é‡Šå¦‚下： + + +pages_to_scan + ksmd进程进入ç¡çœ å‰è¦æ‰«æ的页数。 + 例如， ``echo 100 > /sys/kernel/mm/ksm/pages_to_scan`` + + 默认值：100（该值被选择用于演示目的） + +sleep_millisecs + ksmd在下次扫æå‰åº”ä¼‘çœ å¤šå°‘æ¯«ç§’ + 例如， ``echo 20 > /sys/kernel/mm/ksm/sleep_millisecs`` + + 默认值：20（该值被选择用于演示目的） + +merge_across_nodes + 指定是å¦å¯ä»¥åˆå¹¶æ¥è‡ªä¸åŒNUMA节点的页é¢ã€‚当设置为0时，ksmä»…åˆå¹¶åœ¨ç‰©ç†ä¸Šä½ + 于åŒä¸€NUMA节点的内å˜åŒºåŸŸä¸çš„页é¢ã€‚è¿™é™ä½Žäº†è®¿é—®å…±äº«é¡µé¢çš„延迟。在有明显的 + NUMAè·ç¦»ä¸Šï¼Œå…·æœ‰æ›´å¤šèŠ‚点的系统å¯èƒ½å—益于设置该值为0时的更低延迟。而对于 + 需è¦å¯¹å†…å˜ä½¿ç”¨é‡æœ€å°åŒ–的较å°ç³»ç»Ÿæ¥è¯´ï¼Œè®¾ç½®è¯¥å€¼ä¸º1（默认设置）则å¯èƒ½ä¼šå— + 益于更大共享页é¢ã€‚在决定使用哪ç§è®¾ç½®ä¹‹å‰ï¼Œæ‚¨å¯èƒ½å¸Œæœ›æ¯”较系统在æ¯ç§è®¾ç½®ä¸‹ + 的性能。 ``merge_across_nodes`` 仅当系统ä¸æ²¡æœ‰ksm共享页é¢æ—¶ï¼Œæ‰èƒ½è¢«æ›´æ”¹è®¾ + 置：首先将接å£`run` 设置为2从而对页进行去åˆå¹¶ï¼Œç„¶åŽåœ¨ä¿®æ”¹ + ``merge_across_nodes`` åŽå†å°†â€˜run’åˆè®¾ç½®ä¸º1ï¼Œä»¥æ ¹æ®æ–°è®¾ç½®æ¥é‡æ–°åˆå¹¶ã€‚ + + 默认值：1（如早期的å‘å¸ƒç‰ˆæœ¬ä¸€æ ·åˆå¹¶è·¨ç«™ç‚¹ï¼‰ + +run + * 设置为0å¯åœæ¢ksmdè¿è¡Œï¼Œä½†ä¿ç•™åˆå¹¶é¡µé¢ï¼Œ + * 设置为1å¯è¿è¡Œksmd，例如， ``echo 1 > /sys/kernel/mm/ksm/run`` ， + * 设置为2å¯åœæ¢ksmdè¿è¡Œï¼Œå¹¶ä¸”对所有目å‰å·²åˆå¹¶çš„页进行去åˆå¹¶ï¼Œä½†ä¿ç•™å¯åˆå¹¶ + 区域以供下次è¿è¡Œã€‚ + + 默认值：0（必须设置为1æ‰èƒ½æ¿€æ´»KSM，除éžç¦ç”¨äº†CONFIG_SYSFS） + +use_zero_pages + 指定是å¦åº”当特殊处ç†ç©ºé¡µï¼ˆå³é‚£äº›ä»…å«zero的已分é…页）。当该值设置为1时， + ç©ºé¡µä¸Žå†…æ ¸é›¶é¡µåˆå¹¶ï¼Œè€Œä¸æ˜¯åƒé€šå¸¸æƒ…å†µä¸‹é‚£æ ·ç©ºé¡µè‡ªèº«å½¼æ¤åˆå¹¶ã€‚è¿™å¯ä»¥æ ¹æ® + 工作负载的ä¸åŒï¼Œåœ¨å…·æœ‰ç€è‰²é›¶é¡µçš„架构上å¯ä»¥æ高性能。å¯ç”¨æ¤è®¾ç½®æ—¶åº”å°å¿ƒï¼Œ + å› ä¸ºå®ƒå¯èƒ½ä¼šé™ä½ŽæŸäº›å·¥ä½œè´Ÿè½½çš„KSM性能，比如，当待åˆå¹¶çš„候选页é¢çš„æ ¡éªŒå’Œ + 与空页é¢çš„æ ¡éªŒå’Œæ°å¥½åŒ¹é…的时候。æ¤è®¾ç½®å¯éšæ—¶æ›´æ”¹ï¼Œä»…对那些更改åŽå†åˆå¹¶ + 的页é¢æœ‰æ•ˆã€‚ + + 默认值：0（如åŒæ—©æœŸç‰ˆæœ¬çš„KSMæ£å¸¸è¡¨çŽ°ï¼‰ + +max_page_sharing + å•ä¸ªKSM页é¢å…许的最大共享站点数。这将强制执行é‡å¤æ•°æ®æ¶ˆé™¤é™åˆ¶ï¼Œä»¥é¿å…涉 + åŠé历共享KSM页é¢çš„è™šæ‹Ÿæ˜ å°„çš„è™šæ‹Ÿå†…å˜æ“作的高延迟。最å°å€¼ä¸º2ï¼Œå› ä¸ºæ–°åˆ› + 建的KSM页é¢å°†è‡³å°‘有两个共享者。该值越高，KSMåˆå¹¶å†…å˜çš„é€Ÿåº¦è¶Šå¿«ï¼ŒåŽ»é‡ + å› å也越高，但是对于任何给定的KSM页é¢ï¼Œè™šæ‹Ÿæ˜ 射的最å情况é历的速度也会 + 越慢。å‡æ…¢äº†è¿™ç§é历速度就æ„味ç€åœ¨äº¤æ¢ã€åŽ‹ç¼©ã€NUMA平衡和页é¢è¿ç§»æœŸé—´ï¼Œ + æŸäº›è™šæ‹Ÿå†…å˜æ“作将有更高的延迟，从而é™ä½Žè¿™äº›è™šæ‹Ÿå†…å˜æ“作调用者的å“应能力。 + 其他任务如果ä¸æ¶‰åŠæ‰§è¡Œè™šæ‹Ÿæ˜ å°„é历的VMæ“作，其任务调度延迟ä¸å—æ¤å‚æ•°çš„å½± + å“ï¼Œå› ä¸ºè¿™äº›é历本身是调度å‹å¥½çš„。 + +stable_node_chains_prune_millisecs + 指定KSM检查特定页é¢çš„元数æ®çš„频率（å³é‚£äº›è¾¾åˆ°è¿‡æ—¶ä¿¡æ¯æ•°æ®åŽ»é‡é™åˆ¶æ ‡å‡†çš„ + 页é¢ï¼‰å•ä½æ˜¯æ¯«ç§’。较å°çš„毫秒值将以更低的延迟æ¥é‡Šæ”¾KSM元数æ®ï¼Œä½†å®ƒä»¬å°†ä½¿ + ksmd在扫æ期间使用更多CPU。如果还没有一个KSM页é¢è¾¾åˆ° ``max_page_sharing`` + æ ‡å‡†ï¼Œé‚£å°±æ²¡æœ‰ä»€ä¹ˆç”¨ã€‚ + +KSM与MADV_MERGEABLE的工作有效性体现于 ``/sys/kernel/mm/ksm/`` 路径下的接å£ï¼š + +pages_shared + 表示多少共享页æ£åœ¨è¢«ä½¿ç”¨ +pages_sharing + 表示还有多少站点æ£åœ¨å…±äº«è¿™äº›å…±äº«é¡µï¼Œå³èŠ‚çœäº†å¤šå°‘ +pages_unshared + 表示有多少页是唯一的，但被åå¤æ£€æŸ¥ä»¥è¿›è¡Œåˆå¹¶ +pages_volatile + è¡¨ç¤ºæœ‰å¤šå°‘é¡µå› å˜åŒ–å¤ªå¿«è€Œæ— æ³•æ”¾åœ¨treeä¸ +full_scans + 表示所有å¯åˆå¹¶åŒºåŸŸå·²æ‰«æ多少次 +stable_node_chains + 达到 ``max_page_sharing`` é™åˆ¶çš„KSM页数 +stable_node_dups + é‡å¤çš„KSM页数 + +比值 ``pages_sharing/pages_shared`` 的最大值å—é™åˆ¶äºŽ ``max_page_sharing`` +的设定。è¦æƒ³å¢žåŠ 该比值，则相应地è¦å¢žåŠ ``max_page_sharing`` 的值。 diff --git a/Documentation/translations/zh_CN/core-api/index.rst b/Documentation/translations/zh_CN/core-api/index.rst index d10191c45cf1..26d9913fc8b6 100644 --- a/Documentation/translations/zh_CN/core-api/index.rst +++ b/Documentation/translations/zh_CN/core-api/index.rst @@ -42,6 +42,7 @@ kref assoc_array xarray + rbtree Todolist: @@ -49,7 +50,6 @@ Todolist: idr circular-buffers - rbtree generic-radix-tree packing bus-virt-phys-mapping diff --git a/Documentation/translations/zh_CN/core-api/rbtree.rst b/Documentation/translations/zh_CN/core-api/rbtree.rst new file mode 100644 index 000000000000..a3e1555cb974 --- /dev/null +++ b/Documentation/translations/zh_CN/core-api/rbtree.rst @@ -0,0 +1,391 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/core-api/rbtree.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +========================= +Linuxä¸çš„çº¢é»‘æ ‘ï¼ˆrbtree） +========================= + + +:日期: 2007å¹´1月18æ—¥ +:作者: Rob Landley <rob@landley.net> + +ä½•ä¸ºçº¢é»‘æ ‘ï¼Œå®ƒä»¬æœ‰ä»€ä¹ˆç”¨ï¼Ÿ +-------------------------- + +çº¢é»‘æ ‘æ˜¯ä¸€ç§è‡ªå¹³è¡¡äºŒå‰æœç´¢æ ‘，被用æ¥å˜å‚¨å¯æŽ’åºçš„é”®/值数æ®å¯¹ã€‚è¿™ä¸ŽåŸºæ•°æ ‘ï¼ˆè¢«ç”¨æ¥é«˜æ•ˆ +å˜å‚¨ç¨€ç–æ•°ç»„ï¼Œå› æ¤ä½¿ç”¨é•¿æ•´åž‹ä¸‹æ ‡æ¥æ’å…¥/访问/åˆ é™¤ç»“ç‚¹ï¼‰å’Œå“ˆå¸Œè¡¨ï¼ˆæ²¡æœ‰ä¿æŒæŽ’åºå› è€Œæ— æ³• +容易地按åºé历，åŒæ—¶å¿…须调节其大å°å’Œå“ˆå¸Œå‡½æ•°ï¼Œç„¶è€Œçº¢é»‘æ ‘å¯ä»¥ä¼˜é›…地伸缩以便å˜å‚¨ä»»æ„ +æ•°é‡çš„键）ä¸åŒã€‚ + +çº¢é»‘æ ‘å’ŒAVLæ ‘ç±»ä¼¼ï¼Œä½†åœ¨æ’å…¥å’Œåˆ é™¤æ—¶æ供了更快的实时有界的最å情况性能（分别最多两次 +旋转和三次旋转，æ¥å¹³è¡¡æ ‘），查询时间轻微å˜æ…¢ï¼ˆä½†æ—¶é—´å¤æ‚度ä»ç„¶æ˜¯O(log n)）。 + +引用Linuxæ¯å‘¨æ–°é—»ï¼ˆLinux Weekly News）： + + å†…æ ¸ä¸æœ‰å¤šå¤„çº¢é»‘æ ‘çš„ä½¿ç”¨æ¡ˆä¾‹ã€‚æœ€åŽæœŸé™è°ƒåº¦å™¨å’Œå®Œå…¨å…¬å¹³æŽ’队（CFQ）I/O调度器利用 + çº¢é»‘æ ‘è·Ÿè¸ªè¯·æ±‚ï¼›æ•°æ®åŒ…CD/DVD驱动程åºä¹Ÿæ˜¯å¦‚æ¤ã€‚高精度时钟代ç ä½¿ç”¨ä¸€é¢—çº¢é»‘æ ‘ç»„ç»‡ + 未完æˆçš„定时器请求。ext3æ–‡ä»¶ç³»ç»Ÿç”¨çº¢é»‘æ ‘è·Ÿè¸ªç›®å½•é¡¹ã€‚è™šæ‹Ÿå†…å˜åŒºåŸŸï¼ˆVMAs）ã€epoll + 文件æ述符ã€å¯†ç å¦å¯†é’¥å’Œåœ¨â€œåˆ†å±‚令牌桶â€è°ƒåº¦å™¨ä¸çš„网络数æ®åŒ…éƒ½ç”±çº¢é»‘æ ‘è·Ÿè¸ªã€‚ + +本文档涵盖了对Linuxçº¢é»‘æ ‘å®žçŽ°çš„ä½¿ç”¨æ–¹æ³•ã€‚æ›´å¤šå…³äºŽçº¢é»‘æ ‘çš„æ€§è´¨å’Œå®žçŽ°çš„ä¿¡æ¯ï¼Œå‚è§ï¼š + + Linuxæ¯å‘¨æ–°é—»å…³äºŽçº¢é»‘æ ‘çš„æ–‡ç« + https://lwn.net/Articles/184495/ + + ç»´åŸºç™¾ç§‘çº¢é»‘æ ‘è¯æ¡ + https://en.wikipedia.org/wiki/Red-black_tree + +çº¢é»‘æ ‘çš„Linux实现 +----------------- + +Linuxçš„çº¢é»‘æ ‘å®žçŽ°åœ¨æ–‡ä»¶â€œlib/rbtree.câ€ä¸ã€‚è¦ä½¿ç”¨å®ƒï¼Œéœ€è¦â€œ#include <linux/rbtree.h>â€ã€‚ + +Linuxçš„çº¢é»‘æ ‘å®žçŽ°å¯¹é€Ÿåº¦è¿›è¡Œäº†ä¼˜åŒ–ï¼Œå› æ¤æ¯”ä¼ ç»Ÿçš„å®žçŽ°å°‘ä¸€ä¸ªé—´æŽ¥å±‚ï¼ˆæœ‰æ›´å¥½çš„ç¼“å˜å±€éƒ¨æ€§ï¼‰ã€‚ +æ¯ä¸ªrb_node结构体的实例嵌入在它管ç†çš„æ•°æ®ç»“æž„ä¸ï¼Œå› æ¤ä¸éœ€è¦é 指针æ¥åˆ†ç¦»rb_node和它 +管ç†çš„æ•°æ®ç»“æž„ã€‚ç”¨æˆ·åº”è¯¥ç¼–å†™ä»–ä»¬è‡ªå·±çš„æ ‘æœç´¢å’Œæ’入函数，æ¥è°ƒç”¨å·²æä¾›çš„çº¢é»‘æ ‘å‡½æ•°ï¼Œ +而ä¸æ˜¯ä½¿ç”¨ä¸€ä¸ªæ¯”è¾ƒå›žè°ƒå‡½æ•°æŒ‡é’ˆã€‚åŠ é”代ç ä¹Ÿç•™ç»™çº¢é»‘æ ‘çš„ç”¨æˆ·ç¼–å†™ã€‚ + +åˆ›å»ºä¸€é¢—çº¢é»‘æ ‘ +-------------- + +çº¢é»‘æ ‘ä¸çš„æ•°æ®ç»“点是包å«rb_node结构体æˆå‘˜çš„结构体:: + + struct mytype { + struct rb_node node; + char *keystring; + }; + +当处ç†ä¸€ä¸ªæŒ‡å‘内嵌rb_node结构体的指针时，包ä½rb_node的结构体å¯ç”¨æ ‡å‡†çš„container_of() +å®è®¿é—®ã€‚æ¤å¤–，个体æˆå‘˜å¯ç›´æŽ¥ç”¨rb_entry(node, type, member)访问。 + +æ¯é¢—çº¢é»‘æ ‘çš„æ ¹æ˜¯ä¸€ä¸ªrb_rootæ•°æ®ç»“构，它由以下方å¼åˆå§‹åŒ–为空: + + struct rb_root mytree = RB_ROOT; + +åœ¨ä¸€é¢—çº¢é»‘æ ‘ä¸æœç´¢å€¼ +-------------------- + +ä¸ºä½ çš„æ ‘å†™ä¸€ä¸ªæœç´¢å‡½æ•°æ˜¯ç›¸å½“简å•çš„ï¼šä»Žæ ‘æ ¹å¼€å§‹ï¼Œæ¯”è¾ƒæ¯ä¸ªå€¼ï¼Œç„¶åŽæ ¹æ®éœ€è¦ç»§ç»å‰å¾€å·¦è¾¹æˆ– +å³è¾¹çš„分支。 + +示例:: + + struct mytype *my_search(struct rb_root *root, char *string) + { + struct rb_node *node = root->rb_node; + + while (node) { + struct mytype *data = container_of(node, struct mytype, node); + int result; + + result = strcmp(string, data->keystring); + + if (result < 0) + node = node->rb_left; + else if (result > 0) + node = node->rb_right; + else + return data; + } + return NULL; + } + +åœ¨ä¸€é¢—çº¢é»‘æ ‘ä¸æ’å…¥æ•°æ® +---------------------- + +åœ¨æ ‘ä¸æ’入数æ®çš„æ¥éª¤åŒ…括：首先æœç´¢æ’入新结点的ä½ç½®ï¼Œç„¶åŽæ’å…¥ç»“ç‚¹å¹¶å¯¹æ ‘å†å¹³è¡¡ +（"recoloring"）。 + +æ’入的æœç´¢å’Œä¸Šæ–‡çš„æœç´¢ä¸åŒï¼Œå®ƒè¦æ‰¾åˆ°å«æŽ¥æ–°ç»“点的ä½ç½®ã€‚新结点也需è¦ä¸€ä¸ªæŒ‡å‘它的父节点 +的链接，以达到å†å¹³è¡¡çš„目的。 + +示例:: + + int my_insert(struct rb_root *root, struct mytype *data) + { + struct rb_node **new = &(root->rb_node), *parent = NULL; + + /* Figure out where to put new node */ + while (*new) { + struct mytype *this = container_of(*new, struct mytype, node); + int result = strcmp(data->keystring, this->keystring); + + parent = *new; + if (result < 0) + new = &((*new)->rb_left); + else if (result > 0) + new = &((*new)->rb_right); + else + return FALSE; + } + + /* Add new node and rebalance tree. */ + rb_link_node(&data->node, parent, new); + rb_insert_color(&data->node, root); + + return TRUE; + } + +åœ¨ä¸€é¢—çº¢é»‘æ ‘ä¸åˆ 除或替æ¢å·²ç»å˜åœ¨çš„æ•°æ® +-------------------------------------- + +è‹¥è¦ä»Žæ ‘ä¸åˆ 除一个已ç»å˜åœ¨çš„结点，调用:: + + void rb_erase(struct rb_node *victim, struct rb_root *tree); + +示例:: + + struct mytype *data = mysearch(&mytree, "walrus"); + + if (data) { + rb_erase(&data->node, &mytree); + myfree(data); + } + +è‹¥è¦ç”¨ä¸€ä¸ªæ–°ç»“点替æ¢æ ‘ä¸ä¸€ä¸ªå·²ç»å˜åœ¨çš„键值相åŒçš„结点，调用:: + + void rb_replace_node(struct rb_node *old, struct rb_node *new, + struct rb_root *tree); + +通过这ç§æ–¹å¼æ›¿æ¢ç»“点ä¸ä¼šå¯¹æ ‘åšé‡æŽ’åºï¼šå¦‚果新结点的键值和旧结点ä¸åŒï¼Œçº¢é»‘æ ‘å¯èƒ½è¢« +ç ´å。 + +（按排åºçš„顺åºï¼‰é历å˜å‚¨åœ¨çº¢é»‘æ ‘ä¸çš„å…ƒç´ +---------------------------------------- + +我们æ供了四个函数，用于以排åºçš„æ–¹å¼éåŽ†ä¸€é¢—çº¢é»‘æ ‘çš„å†…å®¹ã€‚è¿™äº›å‡½æ•°å¯ä»¥åœ¨ä»»æ„çº¢é»‘æ ‘ +上工作，并且ä¸éœ€è¦è¢«ä¿®æ”¹æˆ–包装（除éžåŠ é”的目的）:: + + struct rb_node *rb_first(struct rb_root *tree); + struct rb_node *rb_last(struct rb_root *tree); + struct rb_node *rb_next(struct rb_node *node); + struct rb_node *rb_prev(struct rb_node *node); + +è¦å¼€å§‹è¿ä»£ï¼Œéœ€è¦ä½¿ç”¨ä¸€ä¸ªæŒ‡å‘æ ‘æ ¹çš„æŒ‡é’ˆè°ƒç”¨rb_first()或rb_last()ï¼Œå®ƒå°†è¿”å›žä¸€ä¸ªæŒ‡å‘ +æ ‘ä¸ç¬¬ä¸€ä¸ªæˆ–最åŽä¸€ä¸ªå…ƒç´ 所包å«çš„节点结构的指针。è¦ç»§ç»çš„è¯ï¼Œå¯ä»¥åœ¨å½“å‰ç»“点上调用 +rb_next()或rb_prev()æ¥èŽ·å–下一个或上一个结点。当没有剩余的结点时，将返回NULL。 + +è¿ä»£å™¨å‡½æ•°è¿”回一个指å‘被嵌入的rb_node结构体的指针，由æ¤ï¼ŒåŒ…ä½rb_node的结构体å¯ç”¨ +æ ‡å‡†çš„container_of()å®è®¿é—®ã€‚æ¤å¤–，个体æˆå‘˜å¯ç›´æŽ¥ç”¨rb_entry(node, type, member) +访问。 + +示例:: + + struct rb_node *node; + for (node = rb_first(&mytree); node; node = rb_next(node)) + printk("key=%s\n", rb_entry(node, struct mytype, node)->keystring); + +带缓å˜çš„çº¢é»‘æ ‘ +-------------- + +计算最左边（最å°çš„）结点是二å‰æœç´¢æ ‘的一个相当常è§çš„任务，例如用于éåŽ†ï¼Œæˆ–ç”¨æˆ·æ ¹æ® +他们自己的逻辑ä¾èµ–一个特定的顺åºã€‚为æ¤ï¼Œç”¨æˆ·å¯ä»¥ä½¿ç”¨'struct rb_root_cached'æ¥ä¼˜åŒ– +时间å¤æ‚度为O(logN)çš„rb_first()的调用，以简å•åœ°èŽ·å–指针，é¿å…äº†æ½œåœ¨çš„æ˜‚è´µçš„æ ‘è¿ä»£ã€‚ +维护æ“作的é¢å¤–è¿è¡Œæ—¶é—´å¼€é”€å¯å¿½ç•¥ï¼Œä¸è¿‡å†…å˜å 用较大。 + +å’Œrb_root结构体类似，带缓å˜çš„çº¢é»‘æ ‘ç”±ä»¥ä¸‹æ–¹å¼åˆå§‹åŒ–为空:: + + struct rb_root_cached mytree = RB_ROOT_CACHED; + +带缓å˜çš„çº¢é»‘æ ‘åªæ˜¯ä¸€ä¸ªå¸¸è§„çš„rb_rootï¼ŒåŠ ä¸Šä¸€ä¸ªé¢å¤–的指针æ¥ç¼“å˜æœ€å·¦è¾¹çš„节点。这使得 +rb_root_cachedå¯ä»¥å˜åœ¨äºŽrb_rootå˜åœ¨çš„任何地方，并且åªéœ€å¢žåŠ å‡ ä¸ªæŽ¥å£æ¥æ”¯æŒå¸¦ç¼“å˜çš„ +æ ‘:: + + struct rb_node *rb_first_cached(struct rb_root_cached *tree); + void rb_insert_color_cached(struct rb_node *, struct rb_root_cached *, bool); + void rb_erase_cached(struct rb_node *node, struct rb_root_cached *); + +æ“ä½œå’Œåˆ é™¤ä¹Ÿæœ‰å¯¹åº”çš„å¸¦ç¼“å˜çš„æ ‘çš„è°ƒç”¨:: + + void rb_insert_augmented_cached(struct rb_node *node, struct rb_root_cached *, + bool, struct rb_augment_callbacks *); + void rb_erase_augmented_cached(struct rb_node *, struct rb_root_cached *, + struct rb_augment_callbacks *); + + +å¯¹å¢žå¼ºåž‹çº¢é»‘æ ‘çš„æ”¯æŒ +-------------------- + +å¢žå¼ºåž‹çº¢é»‘æ ‘æ˜¯ä¸€ç§åœ¨æ¯ä¸ªç»“点里å˜å‚¨äº†â€œä¸€äº›â€é™„åŠ æ•°æ®çš„çº¢é»‘æ ‘ï¼Œå…¶ä¸ç»“点Nçš„é™„åŠ æ•°æ® +必须是以Nä¸ºæ ¹çš„åæ ‘ä¸æ‰€æœ‰ç»“ç‚¹çš„å†…å®¹çš„å‡½æ•°ã€‚å®ƒæ˜¯å»ºç«‹åœ¨çº¢é»‘æ ‘åŸºç¡€è®¾æ–½ä¹‹ä¸Šçš„å¯é€‰ç‰¹æ€§ã€‚ +想è¦ä½¿ç”¨è¿™ä¸ªç‰¹æ€§çš„çº¢é»‘æ ‘ç”¨æˆ·ï¼Œæ’å…¥å’Œåˆ é™¤ç»“ç‚¹æ—¶å¿…é¡»è°ƒç”¨å¢žå¼ºåž‹æŽ¥å£å¹¶æ供增强型回调函数。 + +å®žçŽ°å¢žå¼ºåž‹çº¢é»‘æ ‘æ“作的C文件必须包å«<linux/rbtree_augmented.h>而ä¸æ˜¯<linux/rbtree.h>。 +注æ„，linux/rbtree_augmented.hæš´éœ²äº†ä¸€äº›çº¢é»‘æ ‘å®žçŽ°çš„ç»†èŠ‚è€Œä½ ä¸åº”ä¾èµ–它们，请åšæŒ +使用文档记录的API，并且ä¸è¦åœ¨å¤´æ–‡ä»¶ä¸åŒ…å«<linux/rbtree_augmented.h>，以最å°åŒ–ä½ çš„ +用户æ„外地ä¾èµ–这些实现细节的å¯èƒ½ã€‚ + +æ’入时，用户必须更新通往被æ’入节点的路径上的增强信æ¯ï¼Œç„¶åŽåƒå¾€å¸¸ä¸€æ ·è°ƒç”¨rb_link_node()， +然åŽæ˜¯rb_augment_inserted()而ä¸æ˜¯å¹³æ—¶çš„rb_insert_color()调用。如果 +rb_augment_inserted()å†å¹³è¡¡äº†çº¢é»‘æ ‘ï¼Œå®ƒå°†å›žè°ƒè‡³ä¸€ä¸ªç”¨æˆ·æ供的函数æ¥æ›´æ–°å—å½±å“çš„ +åæ ‘ä¸Šçš„å¢žå¼ºä¿¡æ¯ã€‚ + +åˆ é™¤ä¸€ä¸ªç»“ç‚¹æ—¶ï¼Œç”¨æˆ·å¿…é¡»è°ƒç”¨rb_erase_augmented()而ä¸æ˜¯rb_erase()。 +rb_erase_augmented()回调至一个用户æ供的函数æ¥æ›´æ–°å—å½±å“çš„åæ ‘ä¸Šçš„å¢žå¼ºä¿¡æ¯ã€‚ + +在两ç§æƒ…况下，回调都是通过rb_augment_callbacks结构体æ供的。必须定义3个回调： + +- ä¸€ä¸ªä¼ æ’回调，它更新一个给定结点和它的祖先们的增强数æ®ï¼Œç›´åˆ°ä¸€ä¸ªç»™å®šçš„åœæ¢ç‚¹ + （如果是NULLï¼Œå°†æ›´æ–°ä¸€è·¯æ›´æ–°åˆ°æ ‘æ ¹ï¼‰ã€‚ + +- 一个å¤åˆ¶å›žè°ƒï¼Œå®ƒå°†ä¸€é¢—给定åæ ‘çš„å¢žå¼ºæ•°æ®å¤åˆ¶åˆ°ä¸€ä¸ªæ–°æŒ‡å®šçš„åæ ‘æ ‘æ ¹ã€‚ + +- ä¸€ä¸ªæ ‘æ—‹è½¬å›žè°ƒï¼Œå®ƒå°†ä¸€é¢—ç»™å®šçš„åæ ‘çš„å¢žå¼ºå€¼å¤åˆ¶åˆ°æ–°æŒ‡å®šçš„åæ ‘æ ‘æ ¹ä¸Šï¼Œå¹¶é‡æ–°è®¡ç®— + å…ˆå‰çš„åæ ‘æ ‘æ ¹çš„å¢žå¼ºå€¼ã€‚ + +rb_erase_augmented()编译åŽçš„代ç å¯èƒ½ä¼šå†…è”ä¼ æ’ã€å¤åˆ¶å›žè°ƒï¼Œè¿™å°†å¯¼è‡´å‡½æ•°ä½“积更大， +å› æ¤æ¯ä¸ªå¢žå¼ºåž‹çº¢é»‘æ ‘çš„ç”¨æˆ·åº”è¯¥åªæœ‰ä¸€ä¸ªrb_erase_augmented()的调用点，以é™åˆ¶ç¼–è¯‘åŽ +的代ç 大å°ã€‚ + + +使用示例 +^^^^^^^^ + +åŒºé—´æ ‘æ˜¯å¢žå¼ºåž‹çº¢é»‘æ ‘çš„ä¸€ä¸ªä¾‹å。å‚考Cormen，Leiserson，Rivestå’ŒStein写的 +ã€Šç®—æ³•å¯¼è®ºã€‹ã€‚åŒºé—´æ ‘çš„æ›´å¤šç»†èŠ‚ï¼š + +ç»å…¸çš„çº¢é»‘æ ‘åªæœ‰ä¸€ä¸ªé”®ï¼Œå®ƒä¸èƒ½ç›´æŽ¥ç”¨æ¥å˜å‚¨åƒ[lo:hi]è¿™æ ·çš„åŒºé—´èŒƒå›´ï¼Œä¹Ÿä¸èƒ½å¿«é€ŸæŸ¥æ‰¾ +与新的lo:hié‡å 的部分，或者查找是å¦æœ‰ä¸Žæ–°çš„lo:hi完全匹é…的部分。 + +ç„¶è€Œï¼Œçº¢é»‘æ ‘å¯ä»¥è¢«å¢žå¼ºï¼Œä»¥ä¸€ç§ç»“构化的方å¼æ¥å˜å‚¨è¿™ç§åŒºé—´èŒƒå›´ï¼Œä»Žè€Œä½¿é«˜æ•ˆçš„查找和 +精确匹é…æˆä¸ºå¯èƒ½ã€‚ + +这个å˜å‚¨åœ¨æ¯ä¸ªèŠ‚点ä¸çš„“é¢å¤–ä¿¡æ¯â€æ˜¯å…¶æ‰€æœ‰åŽä»£ç»“点ä¸çš„最大hi（max_hiï¼‰å€¼ã€‚è¿™ä¸ªä¿¡æ¯ +å¯ä»¥ä¿æŒåœ¨æ¯ä¸ªç»“点上，åªéœ€æŸ¥çœ‹ä¸€ä¸‹è¯¥ç»“点和它的直系å结点们。这将被用于时间å¤æ‚度 +为O(log n)的最低匹é…查找（所有å¯èƒ½çš„匹é…ä¸æœ€ä½Žçš„起始地å€ï¼‰ï¼Œå°±åƒè¿™æ ·:: + + struct interval_tree_node * + interval_tree_first_match(struct rb_root *root, + unsigned long start, unsigned long last) + { + struct interval_tree_node *node; + + if (!root->rb_node) + return NULL; + node = rb_entry(root->rb_node, struct interval_tree_node, rb); + + while (true) { + if (node->rb.rb_left) { + struct interval_tree_node *left = + rb_entry(node->rb.rb_left, + struct interval_tree_node, rb); + if (left->__subtree_last >= start) { + /* + * Some nodes in left subtree satisfy Cond2. + * Iterate to find the leftmost such node N. + * If it also satisfies Cond1, that's the match + * we are looking for. Otherwise, there is no + * matching interval as nodes to the right of N + * can't satisfy Cond1 either. + */ + node = left; + continue; + } + } + if (node->start <= last) { /* Cond1 */ + if (node->last >= start) /* Cond2 */ + return node; /* node is leftmost match */ + if (node->rb.rb_right) { + node = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb); + if (node->__subtree_last >= start) + continue; + } + } + return NULL; /* No match */ + } + } + +æ’å…¥/åˆ é™¤æ˜¯é€šè¿‡ä»¥ä¸‹å¢žå¼ºåž‹å›žè°ƒæ¥å®šä¹‰çš„:: + + static inline unsigned long + compute_subtree_last(struct interval_tree_node *node) + { + unsigned long max = node->last, subtree_last; + if (node->rb.rb_left) { + subtree_last = rb_entry(node->rb.rb_left, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + if (node->rb.rb_right) { + subtree_last = rb_entry(node->rb.rb_right, + struct interval_tree_node, rb)->__subtree_last; + if (max < subtree_last) + max = subtree_last; + } + return max; + } + + static void augment_propagate(struct rb_node *rb, struct rb_node *stop) + { + while (rb != stop) { + struct interval_tree_node *node = + rb_entry(rb, struct interval_tree_node, rb); + unsigned long subtree_last = compute_subtree_last(node); + if (node->__subtree_last == subtree_last) + break; + node->__subtree_last = subtree_last; + rb = rb_parent(&node->rb); + } + } + + static void augment_copy(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + } + + static void augment_rotate(struct rb_node *rb_old, struct rb_node *rb_new) + { + struct interval_tree_node *old = + rb_entry(rb_old, struct interval_tree_node, rb); + struct interval_tree_node *new = + rb_entry(rb_new, struct interval_tree_node, rb); + + new->__subtree_last = old->__subtree_last; + old->__subtree_last = compute_subtree_last(old); + } + + static const struct rb_augment_callbacks augment_callbacks = { + augment_propagate, augment_copy, augment_rotate + }; + + void interval_tree_insert(struct interval_tree_node *node, + struct rb_root *root) + { + struct rb_node **link = &root->rb_node, *rb_parent = NULL; + unsigned long start = node->start, last = node->last; + struct interval_tree_node *parent; + + while (*link) { + rb_parent = *link; + parent = rb_entry(rb_parent, struct interval_tree_node, rb); + if (parent->__subtree_last < last) + parent->__subtree_last = last; + if (start < parent->start) + link = &parent->rb.rb_left; + else + link = &parent->rb.rb_right; + } + + node->__subtree_last = last; + rb_link_node(&node->rb, rb_parent, link); + rb_insert_augmented(&node->rb, root, &augment_callbacks); + } + + void interval_tree_remove(struct interval_tree_node *node, + struct rb_root *root) + { + rb_erase_augmented(&node->rb, root, &augment_callbacks); + } diff --git a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst index 87a36044f828..2ca92042767b 100644 --- a/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst +++ b/Documentation/translations/zh_CN/cpu-freq/cpu-drivers.rst @@ -84,6 +84,8 @@ CPUfreqæ ¸å¿ƒå±‚æ³¨å†Œä¸€ä¸ªcpufreq_driver结构体。 .resume - 一个指å‘per-policyæ¢å¤å‡½æ•°çš„指针，该函数在关ä¸æ–且在调节器å†ä¸€æ¬¡å¯åŠ¨å‰è¢« 调用。 + .ready - 一个指å‘per-policy准备函数的指针，该函数在ç–略完全åˆå§‹åŒ–之åŽè¢«è°ƒç”¨ã€‚ + .attr - 一个指å‘NULL结尾的"struct freq_attr"列表的指针，该列表å…许导出值到 sysfs。 diff --git a/Documentation/translations/zh_CN/devicetree/index.rst b/Documentation/translations/zh_CN/devicetree/index.rst new file mode 100644 index 000000000000..23d0b6fccd58 --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/index.rst @@ -0,0 +1,50 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +============================= +Open Firmware å’Œ Devicetree +============================= + +è¯¥æ–‡æ¡£æ˜¯æ•´ä¸ªè®¾å¤‡æ ‘æ–‡æ¡£çš„æ€»ç›®å½•ï¼Œæ ‡é¢˜ä¸å¤šæ˜¯ä¸šå†…默认的术è¯ï¼Œåˆè§å°±ç¿»è¯‘æˆä¸æ–‡ï¼Œ +æ™¦æ¶©éš¾æ‡‚ï¼Œå› æ¤å°½é‡ä¿ç•™ï¼ŒåŽé¢ç¿»è¯‘å…¶å文档时，å¯èƒ½ä¼šæ ¹æ®è¯å¢ƒï¼Œçµæ´»åœ°ç¿»è¯‘为ä¸æ–‡ã€‚ + +å†…æ ¸Devicetree的使用 +======================= +.. toctree:: + :maxdepth: 1 + + usage-model + of_unittest + +Todolist: + +* kernel-api + +Devicetree Overlays +=================== +.. toctree:: + :maxdepth: 1 + +Todolist: + +* changesets +* dynamic-resolution-notes +* overlay-notes + +Devicetree Bindings +=================== +.. toctree:: + :maxdepth: 1 + +Todolist: + +* bindings/index diff --git a/Documentation/translations/zh_CN/devicetree/of_unittest.rst b/Documentation/translations/zh_CN/devicetree/of_unittest.rst new file mode 100644 index 000000000000..abd94e771ef8 --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/of_unittest.rst @@ -0,0 +1,189 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/of_unittest.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +================================= +Open Firmware Devicetree å•å…ƒæµ‹è¯• +================================= + +作者: Gaurav Minocha <gaurav.minocha.os@gmail.com> + +1. 概述 +======= + +本文档解释了执行 OF å•å…ƒæµ‹è¯•æ‰€éœ€çš„测试数æ®æ˜¯å¦‚何动æ€åœ°é™„åŠ åˆ°å®žæ—¶æ ‘ä¸Šçš„ï¼Œä¸Žæœºå™¨çš„æž¶æž„æ— å…³ã€‚ + +建议在继ç»è¯»ä¸‹åŽ»ä¹‹å‰ï¼Œå…ˆé˜…读以下文件。 + +(1) Documentation/devicetree/usage-model.rst +(2) http://www.devicetree.org/Device_Tree_Usage + +OF Selftest被设计用æ¥æµ‹è¯•æ供给设备驱动开å‘者的接å£ï¼ˆinclude/linux/of.h），以从未æ‰å¹³ +åŒ–çš„è®¾å¤‡æ ‘æ•°æ®ç»“æž„ä¸èŽ·å–设备信æ¯ç‰ã€‚这个接å£è¢«å¤§å¤šæ•°è®¾å¤‡é©±åŠ¨åœ¨å„ç§ä½¿ç”¨æƒ…况下使用。 + + +2. æµ‹è¯•æ•°æ® +=========== + +è®¾å¤‡æ ‘æºæ–‡ä»¶ï¼ˆdrivers/of/unittest-data/testcases.dts）包å«æ‰§è¡Œdrivers/of/unittest.c +ä¸è‡ªåŠ¨åŒ–å•å…ƒæµ‹è¯•æ‰€éœ€çš„测试数æ®ã€‚ç›®å‰ï¼Œä»¥ä¸‹è®¾å¤‡æ ‘æºåŒ…å«æ–‡ä»¶ï¼ˆ.dtsi）被包å«åœ¨testcases.dtä¸:: + + drivers/of/unittest-data/tests-interrupts.dtsi + drivers/of/unittest-data/tests-platform.dtsi + drivers/of/unittest-data/tests-phandle.dtsi + drivers/of/unittest-data/tests-match.dtsi + +å½“å†…æ ¸åœ¨å¯ç”¨OF_SELFTEST的情况下被构建时，那么下é¢çš„make规则:: + + $(obj)/%.dtb: $(src)/%.dts FORCE + $(call if_changed_dep, dtc) + +用于将DTæºæ–‡ä»¶ï¼ˆtestcases.dts）编译æˆäºŒè¿›åˆ¶blob（testcases.dtb），也被称为æ‰å¹³åŒ–çš„DT。 + +之åŽï¼Œä½¿ç”¨ä»¥ä¸‹è§„则将上述二进制blob包装æˆä¸€ä¸ªæ±‡ç¼–文件（testcases.dtb.S）:: + + $(obj)/%.dtb.S: $(obj)/%.dtb + $(call cmd, dt_S_dtb) + +汇编文件被编译æˆä¸€ä¸ªå¯¹è±¡æ–‡ä»¶ï¼ˆtestcases.dtb.oï¼‰ï¼Œå¹¶è¢«é“¾æŽ¥åˆ°å†…æ ¸é•œåƒä¸ã€‚ + + +2.1. æ·»åŠ æµ‹è¯•æ•°æ® +----------------- + +未æ‰å¹³åŒ–çš„è®¾å¤‡æ ‘ç»“æž„ä½“: + +未æ‰å¹³åŒ–çš„è®¾å¤‡æ ‘ç”±è¿žæŽ¥çš„è®¾å¤‡èŠ‚ç‚¹ç»„æˆï¼Œå…¶æ ‘状结构形å¼å¦‚下所述:: + + // following struct members are used to construct the tree + struct device_node { + ... + struct device_node *parent; + struct device_node *child; + struct device_node *sibling; + ... + }; + +图1æ述了一个机器的未æ‰å¹³åŒ–è®¾å¤‡æ ‘çš„é€šç”¨ç»“æž„ï¼Œåªè€ƒè™‘了å节点和åŒçº§æŒ‡é’ˆã€‚å˜åœ¨å¦ä¸€ä¸ªæŒ‡é’ˆï¼Œ +``*parent`` ，用于åå‘éåŽ†è¯¥æ ‘ã€‚å› æ¤ï¼Œåœ¨ä¸€ä¸ªç‰¹å®šçš„层次上，å节点和所有的兄弟å§å¦¹èŠ‚点将 +有一个指å‘å…±åŒèŠ‚点的父指针（例如，child1ã€sibling2ã€sibling3ã€sibling4çš„çˆ¶æŒ‡é’ˆæŒ‡å‘ +æ ¹èŠ‚ç‚¹ï¼‰:: + + root ('/') + | + child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | + | | | null + | | | + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + | | | null + | | | + null null child131 -> null + | + null + +Figure 1: 未æ‰å¹³åŒ–çš„è®¾å¤‡æ ‘çš„é€šç”¨ç»“æž„ + + +在执行OFå•å…ƒæµ‹è¯•ä¹‹å‰ï¼Œéœ€è¦å°†æµ‹è¯•æ•°æ®é™„åŠ åˆ°æœºå™¨çš„è®¾å¤‡æ ‘ä¸Šï¼ˆå¦‚æžœå˜åœ¨ï¼‰ã€‚å› æ¤ï¼Œå½“调用 +selftest_data_add()时，首先会读å–é€šè¿‡ä»¥ä¸‹å†…æ ¸ç¬¦å·é“¾æŽ¥åˆ°å†…æ ¸é•œåƒä¸çš„æ‰å¹³åŒ–è®¾å¤‡æ ‘ +æ•°æ®:: + + __dtb_testcases_begin - address marking the start of test data blob + __dtb_testcases_end - address marking the end of test data blob + +其次，它调用of_fdt_unflatten_tree()æ¥è§£é™¤æ‰å¹³åŒ–çš„blob。最åŽï¼Œå¦‚æžœæœºå™¨çš„è®¾å¤‡æ ‘ +（å³å®žæ—¶æ ‘）是å˜åœ¨çš„，那么它将未æ‰å¹³åŒ–的测试数æ®æ ‘é™„åŠ åˆ°å®žæ—¶æ ‘ä¸Šï¼Œå¦åˆ™å®ƒå°†è‡ªå·±ä½œä¸º +å®žæ—¶è®¾å¤‡æ ‘é™„åŠ ã€‚ + +attach_node_and_children()使用of_attach_node()å°†èŠ‚ç‚¹é™„åŠ åˆ°å®žæ—¶æ ‘ä¸Šï¼Œå¦‚ä¸‹æ‰€ +述。为了解释这一点，图2ä¸æ述的测试数æ®æ ‘è¢«é™„åŠ åˆ°å›¾1ä¸æè¿°çš„å®žæ—¶æ ‘ä¸Š:: + + root ('/') + | + testcase-data + | + test-child0 -> test-sibling1 -> test-sibling2 -> test-sibling3 -> null + | | | | + test-child01 null null null + + +Figure 2: 将测试数æ®æ ‘é™„åœ¨å®žæ—¶æ ‘ä¸Šçš„ä¾‹å。 + +æ ¹æ®ä¸Šé¢çš„æ–¹æ¡ˆï¼Œå®žæ—¶æ ‘å·²ç»å˜åœ¨ï¼Œæ‰€ä»¥ä¸éœ€è¦é™„åŠ æ ¹('/')节点。所有其他节点都是通过在 +æ¯ä¸ªèŠ‚点上调用of_attach_node()æ¥é™„åŠ çš„ã€‚ + +在函数of_attach_node()ä¸ï¼Œæ–°çš„èŠ‚ç‚¹è¢«é™„åœ¨å®žæ—¶æ ‘ä¸ç»™å®šçš„父节点的å节点上。但是，如 +果父节点已ç»æœ‰äº†ä¸€ä¸ªå©å，那么新节点就会å–代当å‰çš„å©å，并将其å˜æˆå…¶å…„弟å§å¦¹ã€‚å› æ¤ï¼Œ +当测试案例的数æ®èŠ‚点被连接到上é¢çš„å®žæ—¶æ ‘ï¼ˆå›¾1）时，最终的结构如图3所示:: + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + (...) | | | null + | | child31 -> sibling32 -> null + | | | | + | | null null + | | + | child21 -> sibling22 -> sibling23 -> null + | | | | + | null null null + | + child11 -> sibling12 -> sibling13 -> sibling14 -> null + | | | | + null null | null + | + child131 -> null + | + null + ----------------------------------------------------------------------- + + root ('/') + | + testcase-data -> child1 -> sibling2 -> sibling3 -> sibling4 -> null + | | | | | + | (...) (...) (...) null + | + test-sibling3 -> test-sibling2 -> test-sibling1 -> test-child0 -> null + | | | | + null null null test-child01 + + +Figure 3: é™„åŠ æµ‹è¯•æ¡ˆä¾‹æ•°æ®åŽçš„å®žæ—¶è®¾å¤‡æ ‘ç»“æž„ã€‚ + + +èªæ˜Žçš„读者会注æ„到，与先å‰çš„结构相比，test-child0节点æˆä¸ºæœ€åŽä¸€ä¸ªå…„弟å§å¦¹ï¼ˆå›¾2）。 +在连接了第一个test-child0节点之åŽï¼Œåˆè¿žæŽ¥äº†test-sibling1节点，该节点推动å节点 +（å³test-child0）æˆä¸ºå…„弟å§å¦¹ï¼Œå¹¶ä½¿è‡ªå·±æˆä¸ºå节点，如上所述。 + +如果å‘现一个é‡å¤çš„节点（å³å¦‚果一个具有相åŒfull_name属性的节点已ç»å˜åœ¨äºŽå®žæ—¶æ ‘ä¸ï¼‰ï¼Œ +那么该节点ä¸ä¼šè¢«é™„åŠ ï¼Œè€Œæ˜¯é€šè¿‡è°ƒç”¨å‡½æ•°update_node_properties()将其属性更新到活 +æ ‘çš„èŠ‚ç‚¹ä¸ã€‚ + + +2.2. åˆ é™¤æµ‹è¯•æ•°æ® +----------------- + +一旦测试用例执行完，selftest_data_remove被调用，以移除最åˆè¿žæŽ¥çš„设备节点（首先是 +å¶å节点被分离，然åŽå‘上移动父节点被移除，最åŽæ˜¯æ•´ä¸ªæ ‘）。selftest_data_remove() +调用detach_node_and_children()，使用of_detach_node()å°†èŠ‚ç‚¹ä»Žå®žæ—¶è®¾å¤‡æ ‘ä¸Šåˆ†ç¦»ã€‚ + +为了分离一个节点，of_detach_node()è¦ä¹ˆå°†ç»™å®šèŠ‚点的父节点的å节点指针更新为其åŒçº§èŠ‚ +点，è¦ä¹ˆæ ¹æ®æƒ…况将å‰ä¸€ä¸ªåŒçº§èŠ‚点附在给定节点的åŒçº§èŠ‚ç‚¹ä¸Šã€‚å°±è¿™æ ·å§ã€‚ :) diff --git a/Documentation/translations/zh_CN/devicetree/usage-model.rst b/Documentation/translations/zh_CN/devicetree/usage-model.rst new file mode 100644 index 000000000000..318a3c6a0114 --- /dev/null +++ b/Documentation/translations/zh_CN/devicetree/usage-model.rst @@ -0,0 +1,330 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/Devicetree/usage-model.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +=================== +Linux å’Œ Devicetree +=================== + +Linuxå¯¹è®¾å¤‡æ ‘æ•°æ®çš„使用模型 + +:作者: Grant Likely <grant.likely@secretlab.ca> + +è¿™ç¯‡æ–‡ç« æ述了Linuxå¦‚ä½•ä½¿ç”¨è®¾å¤‡æ ‘ã€‚å…³äºŽè®¾å¤‡æ ‘æ•°æ®æ ¼å¼çš„概述å¯ä»¥åœ¨ +devicetree.org\ [1]_ çš„è®¾å¤‡æ ‘ä½¿ç”¨é¡µé¢ä¸Šæ‰¾åˆ°ã€‚ + +.. [1] https://www.devicetree.org/specifications/ + +"Open Firmware Device Tree"，或简称为Devicetree（DT），是一ç§ç”¨äºŽæ述硬 +件的数æ®ç»“æž„å’Œè¯è¨€ã€‚更确切地说，它是一ç§æ“作系统å¯è¯»çš„硬件æè¿°ï¼Œè¿™æ ·æ“ä½œç³»ç»Ÿå°±ä¸ +需è¦å¯¹æœºå™¨çš„细节进行硬编ç 。 + +从结构上看，DTæ˜¯ä¸€æ£µæ ‘ï¼Œæˆ–è€…è¯´æ˜¯å¸¦æœ‰å‘½åèŠ‚ç‚¹çš„æ— çŽ¯å›¾ï¼ŒèŠ‚ç‚¹å¯ä»¥æœ‰ä»»æ„æ•°é‡çš„命å +属性æ¥å°è£…ä»»æ„çš„æ•°æ®ã€‚还å˜åœ¨ä¸€ç§æœºåˆ¶ï¼Œå¯ä»¥åœ¨è‡ªç„¶çš„æ ‘çŠ¶ç»“æž„ä¹‹å¤–åˆ›å»ºä»Žä¸€ä¸ªèŠ‚ç‚¹åˆ° +å¦ä¸€ä¸ªèŠ‚点的任æ„链接。 + +从概念上讲，一套通用的使用惯例，称为 "bindings"（åŽæ–‡è¯‘ä¸ºç»‘å®šï¼‰ï¼Œè¢«å®šä¹‰ä¸ºæ•°æ® +åº”è¯¥å¦‚ä½•å‡ºçŽ°åœ¨æ ‘ä¸ï¼Œä»¥æ述典型的硬件特性，包括数æ®æ€»çº¿ã€ä¸æ–线ã€GPIO连接和外围 +设备。 + +å°½å¯èƒ½ä½¿ç”¨çŽ°æœ‰çš„绑定æ¥æ述硬件，以最大é™åº¦åœ°åˆ©ç”¨çŽ°æœ‰çš„支æŒä»£ç ，但由于属性和节 +点å称是简å•çš„文本å—符串，通过定义新的节点和属性æ¥æ‰©å±•çŽ°æœ‰çš„绑定或创建新的绑定 +很容易。然而，è¦è¦æƒ•çš„是，在创建一个新的绑定之å‰ï¼Œæœ€å¥½å…ˆå¯¹å·²ç»å˜åœ¨çš„东西åšä¸€äº› +功课。目å‰æœ‰ä¸¤ç§ä¸åŒçš„ã€ä¸å…¼å®¹çš„i2cæ€»çº¿çš„ç»‘å®šï¼Œè¿™æ˜¯å› ä¸ºåœ¨åˆ›å»ºæ–°çš„ç»‘å®šæ—¶æ²¡æœ‰äº‹å…ˆ +调查i2c设备在现有系统ä¸æ˜¯å¦‚何被枚举的。 + +1. åŽ†å² +------- +DT最åˆæ˜¯ç”±Open Firmware创建的，作为将数æ®ä»ŽOpen Firmwareä¼ é€’ç»™å®¢æˆ·ç¨‹åº +ï¼ˆå¦‚ä¼ é€’ç»™æ“作系统）的通信方法的一部分。æ“ä½œç³»ç»Ÿä½¿ç”¨è®¾å¤‡æ ‘åœ¨è¿è¡Œæ—¶æŽ¢æµ‹ç¡¬ä»¶çš„æ‹“ +扑结构，从而在没有硬编ç ä¿¡æ¯çš„情况下支æŒå¤§å¤šæ•°å¯ç”¨çš„硬件（å‡è®¾æ‰€æœ‰è®¾å¤‡çš„驱动程 +åºéƒ½å¯ç”¨ï¼‰ã€‚ + +由于Open Firmware通常在PowerPCå’ŒSPARCå¹³å°ä¸Šä½¿ç”¨ï¼Œé•¿æœŸä»¥æ¥ï¼Œå¯¹è¿™äº›æž¶æž„çš„ +Linux支æŒä¸€ç›´ä½¿ç”¨è®¾å¤‡æ ‘。 + +2005年，当PowerPC Linux开始大规模清ç†å¹¶åˆå¹¶32ä½å’Œ64ä½æ”¯æŒæ—¶ï¼Œå†³å®šåœ¨æ‰€æœ‰ +Powerpcå¹³å°ä¸Šè¦æ±‚DT支æŒï¼Œæ— 论它们是å¦ä½¿ç”¨Open Firmware。为了åšåˆ°è¿™ä¸€ç‚¹ï¼Œ +我们创建了一个å«åšæ‰å¹³åŒ–è®¾å¤‡æ ‘ï¼ˆFDT）的DT表示法，它å¯ä»¥ä½œä¸ºä¸€ä¸ªäºŒè¿›åˆ¶çš„blob +ä¼ é€’ç»™å†…æ ¸ï¼Œè€Œä¸éœ€è¦çœŸæ£çš„Open Firmware实现。U-Bootã€kexecå’Œå…¶ä»–å¼•å¯¼ç¨‹åº +被修改，以支æŒä¼ é€’è®¾å¤‡æ ‘äºŒè¿›åˆ¶ï¼ˆdtb）和在引导时修改dtb。DTä¹Ÿè¢«æ·»åŠ åˆ°PowerPC +引导包装器（arch/powerpc/boot/\*）ä¸ï¼Œè¿™æ ·dtbå°±å¯ä»¥è¢«åŒ…è£¹åœ¨å†…æ ¸é•œåƒä¸ï¼Œä»¥ +支æŒå¼•å¯¼çŽ°æœ‰çš„éžDT察觉的固件。 + +一段时间åŽï¼ŒFDT基础架构被普åŠåˆ°äº†æ‰€æœ‰çš„架构ä¸ã€‚åœ¨å†™è¿™ç¯‡æ–‡ç« çš„æ—¶å€™ï¼Œ6个主线架 +构（armã€microblazeã€mipsã€powerpcã€sparcå’Œx86）和1个éžä¸»çº¿æž¶æž„（ios） +有æŸç§ç¨‹åº¦çš„DT支æŒã€‚ + +1. æ•°æ®æ¨¡åž‹ +----------- +å¦‚æžœä½ è¿˜æ²¡æœ‰è¯»è¿‡è®¾å¤‡æ ‘ç”¨æ³•\ [1]_页，那么现在就去读å§ã€‚没关系，我ç‰ç€.... + +2.1 高层次视角 +-------------- +最é‡è¦çš„是è¦æ˜Žç™½ï¼ŒDTåªæ˜¯ä¸€ä¸ªæ述硬件的数æ®ç»“构。它没有什么神奇之处，也ä¸ä¼šç¥ž +奇地让所有的硬件é…置问题消失。它所åšçš„是æ供一ç§è¯è¨€ï¼Œå°†ç¡¬ä»¶é…置与Linuxå†…æ ¸ +（或任何其他æ“作系统）ä¸çš„æ¿å¡å’Œè®¾å¤‡é©±åŠ¨æ”¯æŒè§£è€¦ã€‚使用它å¯ä»¥ä½¿æ¿å¡å’Œè®¾å¤‡æ”¯æŒ +å˜æˆæ•°æ®é©±åŠ¨ï¼›æ ¹æ®ä¼ é€’åˆ°å†…æ ¸çš„æ•°æ®åšå‡ºè®¾ç½®å†³å®šï¼Œè€Œä¸æ˜¯æ ¹æ®æ¯å°æœºå™¨çš„硬编ç 选 +择。 + +ç†æƒ³æƒ…况下，数æ®é©±åŠ¨çš„å¹³å°è®¾ç½®åº”该导致更少的代ç é‡å¤ï¼Œå¹¶ä½¿å…¶æ›´å®¹æ˜“ç”¨ä¸€ä¸ªå†…æ ¸ +é•œåƒæ”¯æŒå„ç§ç¡¬ä»¶ã€‚ + +Linux使用DTæ•°æ®æœ‰ä¸‰ä¸ªä¸»è¦ç›®çš„: + +1) å¹³å°è¯†åˆ«ã€‚ +2) è¿è¡Œæ—¶é…ç½®ï¼Œä»¥åŠ +3) 设备数é‡ã€‚ + +2.2 å¹³å°è¯†åˆ« +------------ +é¦–å…ˆï¼Œå†…æ ¸å°†ä½¿ç”¨DTä¸çš„æ•°æ®æ¥è¯†åˆ«ç‰¹å®šçš„机器。在一个ç†æƒ³çš„世界里，具体的平å°å¯¹ +å†…æ ¸æ¥è¯´å¹¶ä¸é‡è¦ï¼Œå› 为所有的平å°ç»†èŠ‚éƒ½ä¼šè¢«è®¾å¤‡æ ‘ä»¥ä¸€è‡´å’Œå¯é çš„æ–¹å¼å®Œç¾Žæ述。 +但是，硬件并ä¸å®Œç¾Žï¼Œæ‰€ä»¥å†…æ ¸å¿…é¡»åœ¨æ—©æœŸå¯åŠ¨æ—¶è¯†åˆ«æœºå™¨ï¼Œä»¥ä¾¿æœ‰æœºä¼šè¿è¡Œç‰¹å®šäºŽæœº +器的修å¤ç¨‹åºã€‚ + +在大多数情况下，机器的身份是ä¸ç›¸å…³çš„ï¼Œè€Œå†…æ ¸å°†æ ¹æ®æœºå™¨çš„æ ¸å¿ƒCPU或SoCæ¥é€‰æ‹© +设置代ç 。例如，在ARM上，arch/arm/kernel/setup.cä¸çš„setup_arch()将调 +用arch/arm/kernel/devtree.cä¸çš„setup_machine_fdt()，它通过 +machine_desc表æœç´¢å¹¶é€‰æ‹©ä¸Žè®¾å¤‡æ ‘æ•°æ®æœ€åŒ¹é…çš„machine_descã€‚å®ƒé€šè¿‡æŸ¥çœ‹æ ¹ +è®¾å¤‡æ ‘èŠ‚ç‚¹ä¸çš„'compatible'属性，并将其与struct machine_descä¸çš„ +dt_compatåˆ—è¡¨ï¼ˆå¦‚æžœä½ å¥½å¥‡ï¼Œè¯¥åˆ—è¡¨å®šä¹‰åœ¨arch/arm/include/asm/mach/arch.h +ä¸ï¼‰è¿›è¡Œæ¯”较，从而确定最佳匹é…。 + +“compatible†属性包å«ä¸€ä¸ªæŽ’åºçš„å—符串列表，以机器的确切å称开始，åŽé¢æ˜¯ +一个å¯é€‰çš„与之兼容的æ¿å列表，从最兼容到最ä¸å…¼å®¹æŽ’åºã€‚例如，TI BeagleBoard +和它的åŽç»§è€…BeagleBoard xMæ¿çš„æ ¹å…¼å®¹å±žæ€§å¯èƒ½çœ‹èµ·æ¥åˆ†åˆ«ä¸º:: + + compatible = "ti,omap3-beagleboard", "ti,omap3450", "ti,omap3"; + compatible = "ti,omap3-beagleboard-xm", "ti,omap3450", "ti,omap3"; + +å…¶ä¸ "ti,map3-beagleboard-xm "指定了确切的型å·ï¼Œå®ƒè¿˜å£°ç§°å®ƒä¸ŽOMAP 3450 SoC +以åŠä¸€èˆ¬çš„OMP3系列SoCå…¼å®¹ã€‚ä½ ä¼šæ³¨æ„到，该列表从最具体的（确切的æ¿å）到最 +ä¸å…·ä½“的（SoC系列）进行排åºã€‚ + +èªæ˜Žçš„读者å¯èƒ½ä¼šæŒ‡å‡ºï¼ŒBeagle xM也å¯ä»¥å£°ç§°ä¸ŽåŽŸBeagleæ¿å…¼å®¹ã€‚然而，我们应 +该当心在æ¿çº§ä¸Šè¿™æ ·åšï¼Œå› 为通常情况下，å³ä½¿åœ¨åŒä¸€äº§å“系列ä¸ï¼Œæ¯å—æ¿éƒ½æœ‰å¾ˆé«˜ +çš„å˜åŒ–，而且当一å—æ¿å£°ç§°ä¸Žå¦ä¸€å—æ¿å…¼å®¹æ—¶ï¼Œå¾ˆéš¾ç¡®å®šåˆ°åº•æ˜¯ä»€ä¹ˆæ„æ€ã€‚对于高层 +æ¥è¯´ï¼Œæœ€å¥½æ˜¯è°¨æ…Žè¡Œäº‹ï¼Œä¸è¦å£°ç§°ä¸€å—æ¿å与å¦ä¸€å—æ¿å兼容。值得注æ„的例外是， +当一å—æ¿å是å¦ä¸€å—æ¿å的载体时，例如CPU模å—连接到一个载体æ¿ä¸Šã€‚ + +关于兼容值还有一个注æ„事项。在兼容属性ä¸ä½¿ç”¨çš„任何å—符串都必须有文件说明它 +表示什么。在Documentation/devicetree/bindingsä¸æ·»åŠ 兼容å—符串的文档。 + +åŒæ ·åœ¨ARM上，对于æ¯ä¸ªmachine_descï¼Œå†…æ ¸ä¼šæŸ¥çœ‹æ˜¯å¦æœ‰ä»»ä½•dt_compatåˆ—è¡¨æ¡ +目出现在兼容属性ä¸ã€‚如果有，那么该机器_desc就是驱动该机器的候选者。在æœç´¢ +了整个machine_descs表之åŽï¼Œsetup_machine_fdt()æ ¹æ®æ¯ä¸ªmachine_desc +在兼容属性ä¸åŒ¹é…çš„æ¡ç›®ï¼Œè¿”回 “最兼容†的machine_descã€‚å¦‚æžœæ²¡æœ‰æ‰¾åˆ°åŒ¹é… +çš„machine_desc，那么它将返回NULL。 + +这个方案背åŽçš„åŽŸå› æ˜¯è§‚å¯Ÿåˆ°ï¼Œåœ¨å¤§å¤šæ•°æƒ…å†µä¸‹ï¼Œå¦‚æžœå®ƒä»¬éƒ½ä½¿ç”¨ç›¸åŒçš„SoCæˆ–ç›¸åŒ +系列的SoC，一个机器_descå¯ä»¥æ”¯æŒå¤§é‡çš„电路æ¿ã€‚然而，ä¸å¯é¿å…地会有一些例 +外情况，å³ç‰¹å®šçš„æ¿å需è¦ç‰¹æ®Šçš„设置代ç ，这在一般情况下是没有用的。特殊情况 +å¯ä»¥é€šè¿‡åœ¨é€šç”¨è®¾ç½®ä»£ç ä¸æ˜Žç¡®æ£€æŸ¥æœ‰é—®é¢˜çš„æ¿åæ¥å¤„ç†ï¼Œä½†å¦‚æžœè¶…è¿‡å‡ ä¸ªæƒ…å†µä¸‹ï¼Œ +è¿™æ ·åšå¾ˆå¿«å°±ä¼šå˜å¾—很难看和/æˆ–æ— æ³•ç»´æŠ¤ã€‚ + +相å，兼容列表å…许通用机器_desc通过在dt_compat列表ä¸æŒ‡å®šâ€œä¸å¤ªå…¼å®¹â€çš„值 +æ¥æ供对广泛的通用æ¿çš„支æŒã€‚在上é¢çš„例åä¸ï¼Œé€šç”¨æ¿æ”¯æŒå¯ä»¥å£°ç§°ä¸Žâ€œti,ompa3†+或“ti,ompa3450â€å…¼å®¹ã€‚如果在最åˆçš„beagleboard上å‘现了一个bug，需è¦åœ¨ +早期å¯åŠ¨æ—¶ä½¿ç”¨ç‰¹æ®Šçš„å˜é€šä»£ç ，那么å¯ä»¥æ·»åŠ 一个新的machine_desc，实现å˜é€šï¼Œ +并且åªåœ¨â€œti,omap3-beagleboardâ€ä¸ŠåŒ¹é…。 + +PowerPC使用了一个ç¨å¾®ä¸åŒçš„方案，它从æ¯ä¸ªæœºå™¨_descä¸è°ƒç”¨.probe()é’©å， +并使用第一个返回TRUEçš„é’©å。然而，这ç§æ–¹æ³•æ²¡æœ‰è€ƒè™‘到兼容列表的优先级，对于 +新的架构支æŒå¯èƒ½åº”该é¿å…。 + +2.3 è¿è¡Œæ—¶é…ç½® +-------------- +在大多数情况下，DT是将数æ®ä»Žå›ºä»¶ä¼ é€’ç»™å†…æ ¸çš„å”¯ä¸€æ–¹æ³•ï¼Œæ‰€ä»¥ä¹Ÿè¢«ç”¨æ¥ä¼ 递è¿è¡Œ +时和é…置数æ®ï¼Œå¦‚å†…æ ¸å‚æ•°å—符串和initrdé•œåƒçš„ä½ç½®ã€‚ + +这些数æ®å¤§éƒ¨åˆ†éƒ½åŒ…å«åœ¨/chosen节点ä¸ï¼Œå½“å¯åŠ¨Linux时，它看起æ¥å°±åƒè¿™æ ·:: + + chosen { + bootargs = "console=ttyS0,115200 loglevel=8"; + initrd-start = <0xc8000000>; + initrd-end = <0xc8200000>; + }; + +bootargs属性包å«å†…æ ¸å‚数，initrd-\*属性定义initrd blob的地å€å’Œå¤§å°ã€‚注 +æ„initrd-end是initrdæ˜ åƒåŽçš„第一个地å€ï¼Œæ‰€ä»¥è¿™ä¸Žç»“构体资æºçš„通常è¯ä¹‰ä¸ä¸€ +致。选择的节点也å¯ä»¥é€‰æ‹©åŒ…å«ä»»æ„æ•°é‡çš„é¢å¤–属性，用于平å°ç‰¹å®šçš„é…置数æ®ã€‚ + +在早期å¯åŠ¨è¿‡ç¨‹ä¸ï¼Œæž¶æž„设置代ç 通过ä¸åŒçš„辅助回调函数多次调用 +of_scan_flat_dt()æ¥è§£æžè®¾å¤‡æ ‘æ•°æ®ï¼Œç„¶åŽè¿›è¡Œåˆ†é¡µè®¾ç½®ã€‚of_scan_flat_dt() +代ç 扫æè®¾å¤‡æ ‘ï¼Œå¹¶ä½¿ç”¨è¾…åŠ©å‡½æ•°æ¥æå–早期å¯åŠ¨æœŸé—´æ‰€éœ€çš„ä¿¡æ¯ã€‚通常情况下， +early_init_dt_scan_chosen()辅助函数用于解æžæ‰€é€‰èŠ‚ç‚¹ï¼ŒåŒ…æ‹¬å†…æ ¸å‚数， +early_init_dt_scan_root()用于åˆå§‹åŒ–DT地å€ç©ºé—´æ¨¡åž‹ï¼Œearly_init_dt_scan_memory() +用于确定å¯ç”¨RAM的大å°å’Œä½ç½®ã€‚ + +在ARM上，函数setup_machine_fdt()负责在选择支æŒæ¿åçš„æ£ç¡®machine_desc +åŽï¼Œå¯¹è®¾å¤‡æ ‘进行早期扫æ。 + +2.4 è®¾å¤‡æ•°é‡ +------------ +在电路æ¿è¢«è¯†åˆ«åŽï¼Œåœ¨æ—©æœŸé…置数æ®è¢«è§£æžåŽï¼Œå†…æ ¸åˆå§‹åŒ–å¯ä»¥ä»¥æ£å¸¸æ–¹å¼è¿›è¡Œã€‚在 +这个过程ä¸çš„æŸä¸ªæ—¶åˆ»ï¼Œunflatten_device_tree()被调用以将数æ®è½¬æ¢æˆæ›´æœ‰ +效的è¿è¡Œæ—¶è¡¨ç¤ºã€‚这也是调用机器特定设置钩å的时候，比如ARM上的machine_desc +.init_early()ã€.init_irq()å’Œ.init_machine()é’©å。本节的其余部分使用 +了ARM实现的例å，但所有架构在使用DT时都会åšå‡ 乎相åŒçš„事情。 + +从å称上å¯ä»¥çŒœåˆ°ï¼Œ.init_early()用于在å¯åŠ¨è¿‡ç¨‹æ—©æœŸéœ€è¦æ‰§è¡Œçš„任何机器特定设 +置，而.init_irq()则用于设置ä¸æ–处ç†ã€‚使用DT并ä¸ä¼šå®žè´¨æ€§åœ°æ”¹å˜è¿™ä¸¤ä¸ªå‡½æ•°çš„ +行为。如果æ供了DT，那么.init_early()å’Œ.init_irq()都能调用任何一个DT查 +询函数（of_* in include/linux/of*.h），以获得关于平å°çš„é¢å¤–æ•°æ®ã€‚ + +DT上下文ä¸æœ€æœ‰è¶£çš„é’©å是.init_machine()，它主è¦è´Ÿè´£å°†å¹³å°çš„æ•°æ®å¡«å……到 +Linux设备模型ä¸ã€‚历å²ä¸Šï¼Œè¿™åœ¨åµŒå…¥å¼å¹³å°ä¸Šæ˜¯é€šè¿‡åœ¨æ¿å¡support .c文件ä¸å®š +义一组é™æ€æ—¶é’Ÿç»“æž„ã€platform_devices和其他数æ®ï¼Œå¹¶åœ¨.init_machine()ä¸ +大é‡æ³¨å†Œæ¥å®žçŽ°çš„。当使用DT时，就ä¸ç”¨ä¸ºæ¯ä¸ªå¹³å°çš„é™æ€è®¾å¤‡è¿›è¡Œç¡¬ç¼–ç ，å¯ä»¥é€šè¿‡ +解æžDT获得设备列表，并动æ€åˆ†é…设备结构体。 + +最简å•çš„情况是，.init_machine()åªè´Ÿè´£æ³¨å†Œä¸€ä¸ªplatform_devices。 +platform_device是Linux使用的一个概念，用于ä¸èƒ½è¢«ç¡¬ä»¶æ£€æµ‹åˆ°çš„内å˜æˆ–I/Oæ˜ +射的设备，以åŠâ€œå¤åˆâ€æˆ– “虚拟â€è®¾å¤‡ï¼ˆåŽé¢ä¼šè¯¦ç»†ä»‹ç»ï¼‰ã€‚虽然DT没有“平å°è®¾å¤‡â€çš„ +术è¯ï¼Œä½†å¹³å°è®¾å¤‡å¤§è‡´å¯¹åº”äºŽæ ‘æ ¹çš„è®¾å¤‡èŠ‚ç‚¹å’Œç®€å•å†…å˜æ˜ 射总线节点的å节点。 + +现在是举例说明的好时机。下é¢æ˜¯NVIDIA Tegraæ¿çš„è®¾å¤‡æ ‘çš„ä¸€éƒ¨åˆ†:: + + /{ + compatible = "nvidia,harmony", "nvidia,tegra20"; + #address-cells = <1>; + #size-cells = <1>; + interrupt-parent = <&intc>; + + chosen { }; + aliases { }; + + memory { + device_type = "memory"; + reg = <0x00000000 0x40000000>; + }; + + soc { + compatible = "nvidia,tegra20-soc", "simple-bus"; + #address-cells = <1>; + #size-cells = <1>; + ranges; + + intc: interrupt-controller@50041000 { + compatible = "nvidia,tegra20-gic"; + interrupt-controller; + #interrupt-cells = <1>; + reg = <0x50041000 0x1000>, < 0x50040100 0x0100 >; + }; + + serial@70006300 { + compatible = "nvidia,tegra20-uart"; + reg = <0x70006300 0x100>; + interrupts = <122>; + }; + + i2s1: i2s@70002800 { + compatible = "nvidia,tegra20-i2s"; + reg = <0x70002800 0x100>; + interrupts = <77>; + codec = <&wm8903>; + }; + + i2c@7000c000 { + compatible = "nvidia,tegra20-i2c"; + #address-cells = <1>; + #size-cells = <0>; + reg = <0x7000c000 0x100>; + interrupts = <70>; + + wm8903: codec@1a { + compatible = "wlf,wm8903"; + reg = <0x1a>; + interrupts = <347>; + }; + }; + }; + + sound { + compatible = "nvidia,harmony-sound"; + i2s-controller = <&i2s1>; + i2s-codec = <&wm8903>; + }; + }; + +在.init_machine()时，Tegraæ¿æ”¯æŒä»£ç 将需è¦æŸ¥çœ‹è¿™ä¸ªDT，并决定为哪些节点 +创建platform_devicesã€‚ç„¶è€Œï¼Œçœ‹ä¸€ä¸‹è¿™ä¸ªæ ‘ï¼Œå¹¶ä¸èƒ½ç«‹å³çœ‹å‡ºæ¯ä¸ªèŠ‚点代表什么 +类型的设备，甚至ä¸èƒ½çœ‹å‡ºä¸€ä¸ªèŠ‚点是å¦ä»£è¡¨ä¸€ä¸ªè®¾å¤‡ã€‚/chosenã€/aliaseså’Œ +/memory节点是信æ¯èŠ‚点，并ä¸æ述设备（尽管å¯ä»¥è¯´å†…å˜å¯ä»¥è¢«è®¤ä¸ºæ˜¯ä¸€ä¸ªè®¾å¤‡ï¼‰ã€‚ +/soc节点的å节点是内å˜æ˜ 射的设备，但是codec@1a是一个i2c设备，而sound节 +点代表的ä¸æ˜¯ä¸€ä¸ªè®¾å¤‡ï¼Œè€Œæ˜¯å…¶ä»–设备是如何连接在一起以创建音频å系统的。我知 +é“æ¯ä¸ªè®¾å¤‡æ˜¯ä»€ä¹ˆï¼Œå› 为我熟悉电路æ¿çš„è®¾è®¡ï¼Œä½†æ˜¯å†…æ ¸æ€Žä¹ˆçŸ¥é“æ¯ä¸ªèŠ‚点该怎么åšï¼Ÿ + +诀çªåœ¨äºŽï¼Œå†…æ ¸ä»Žæ ‘çš„æ ¹éƒ¨å¼€å§‹ï¼Œå¯»æ‰¾å…·æœ‰â€œå…¼å®¹â€å±žæ€§çš„节点。首先，一般认为任何 +具有“兼容â€å±žæ€§çš„节点都代表æŸç§è®¾å¤‡ï¼›å…¶æ¬¡ï¼Œå¯ä»¥è®¤ä¸ºæ ‘æ ¹çš„ä»»ä½•èŠ‚ç‚¹è¦ä¹ˆç›´æŽ¥è¿ž +接到处ç†å™¨æ€»çº¿ä¸Šï¼Œè¦ä¹ˆæ˜¯æ— 法用其他方å¼æè¿°çš„æ‚项系统设备。对于这些节点ä¸çš„ +æ¯ä¸€ä¸ªï¼ŒLinux都会分é…和注册一个platform_device，它åˆå¯èƒ½è¢«ç»‘定到一个 +platform_driver。 + +为什么为这些节点使用platform_device是一个安全的å‡è®¾ï¼Ÿå—¯ï¼Œå°±Linux对设备 +的建模方å¼è€Œè¨€ï¼Œå‡ 乎所有的总线类型都å‡å®šå…¶è®¾å¤‡æ˜¯æ€»çº¿æŽ§åˆ¶å™¨çš„å©åã€‚ä¾‹å¦‚ï¼Œæ¯ +个i2c_client是i2c_master的一个å节点。æ¯ä¸ªspi_device都是SPI总线的一 +个å节点。类似的还有USBã€PCIã€MDIOç‰ã€‚åŒæ ·çš„层次结构也出现在DTä¸ï¼ŒI2C设 +备节点åªä½œä¸ºI2C总线节点的å节点出现。åŒç†ï¼ŒSPIã€MDIOã€USBç‰ç‰ã€‚唯一ä¸éœ€ +è¦ç‰¹å®šç±»åž‹çš„父设备的设备是platform_devices（和amba_devices，但åŽé¢ä¼š +详细介ç»ï¼‰ï¼Œå®ƒä»¬å°†æ„‰å¿«åœ°è¿è¡Œåœ¨Linux/sys/devicesæ ‘çš„åº•éƒ¨ã€‚å› æ¤ï¼Œå¦‚果一个 +DT节点ä½äºŽæ ‘çš„æ ¹éƒ¨ï¼Œé‚£ä¹ˆå®ƒçœŸçš„å¯èƒ½æœ€å¥½æ³¨å†Œä¸ºplatform_device。 + +Linuxæ¿æ”¯æŒä»£ç 调用of_platform_populate(NULL, NULL, NULL, NULL)æ¥ +å¯åŠ¨æ ‘æ ¹çš„è®¾å¤‡å‘现。å‚数都是NULLï¼Œå› ä¸ºå½“ä»Žæ ‘çš„æ ¹éƒ¨å¼€å§‹æ—¶ï¼Œä¸éœ€è¦æ供一个起 +始节点（第一个NULL），一个父结构设备（最åŽä¸€ä¸ªNULLï¼‰ï¼Œè€Œä¸”æˆ‘ä»¬æ²¡æœ‰ä½¿ç”¨åŒ¹é… +表（尚未）。对于åªéœ€è¦æ³¨å†Œè®¾å¤‡çš„æ¿å，除了of_platform_populate()的调用， +.init_machine()å¯ä»¥å®Œå…¨ä¸ºç©ºã€‚ + +在Tegra的例åä¸ï¼Œè¿™è¯´æ˜Žäº†/socå’Œ/sound节点，但是SoC节点的å节点呢？它们 +ä¸åº”该也被注册为平å°è®¾å¤‡å—？对于Linux DT支æŒï¼Œä¸€èˆ¬çš„行为是å设备在驱动 +.probe()æ—¶è¢«çˆ¶è®¾å¤‡é©±åŠ¨æ³¨å†Œã€‚å› æ¤ï¼Œä¸€ä¸ªi2c总线设备驱动程åºå°†ä¸ºæ¯ä¸ªå节点 +注册一个i2c_client，一个SPI总线驱动程åºå°†æ³¨å†Œå…¶spi_deviceå节点，其他 +总线类型也是如æ¤ã€‚æ ¹æ®è¯¥æ¨¡åž‹ï¼Œå¯ä»¥ç¼–写一个与SoC节点绑定的驱动程åºï¼Œå¹¶ç®€å• +地为其æ¯ä¸ªå节点注册platform_device。æ¿å¡æ”¯æŒä»£ç 将分é…和注册一个SoC设 +备，一个（ç†è®ºä¸Šçš„）SoC设备驱动程åºå¯ä»¥ç»‘定到SoC设备，并在其.probe()é’© +ä¸ä¸º/soc/interruptcontrollerã€/soc/serialã€/soc/i2så’Œ/soc/i2c注 +册platform_devices。很简å•ï¼Œå¯¹å—？ + +实际上，事实è¯æ˜Žï¼Œå°†ä¸€äº›platform_deviceçš„å设备注册为更多的platform_device +是一ç§å¸¸è§çš„模å¼ï¼Œè®¾å¤‡æ ‘支æŒä»£ç åæ˜ äº†è¿™ä¸€ç‚¹ï¼Œå¹¶ä½¿ä¸Šè¿°ä¾‹å更简å•ã€‚ +of_platform_populate()的第二个å‚数是一个of_device_id表，任何与该表 +ä¸çš„æ¡ç›®ç›¸åŒ¹é…的节点也将获得其å节点的注册。在Tegra的例åä¸ï¼Œä»£ç å¯ä»¥æ˜¯ +è¿™æ ·çš„:: + + static void __init harmony_init_machine(void) + { + /* ... */ + of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); + } + +“simple-busâ€åœ¨Devicetree规范ä¸è¢«å®šä¹‰ä¸ºä¸€ä¸ªå±žæ€§ï¼Œæ„味ç€ä¸€ä¸ªç®€å•çš„内å˜æ˜ å°„ +的总线，所以of_platform_populate()代ç å¯ä»¥è¢«å†™æˆåªæ˜¯å‡è®¾ç®€å•æ€»çº¿å…¼å®¹çš„节 +点将总是被é历。然而，我们把它作为一个å‚æ•°ä¼ å…¥ï¼Œä»¥ä¾¿ç”µè·¯æ¿æ”¯æŒä»£ç å¯ä»¥éšæ—¶è¦† +盖默认行为。 + +[需è¦æ·»åŠ å…³äºŽæ·»åŠ i2c/spi/etcå设备的讨论] 。 + +附录A：AMBA设备 +--------------- + +ARM Primecell是连接到ARM AMBA总线的æŸç§è®¾å¤‡ï¼Œå®ƒåŒ…括对硬件检测和电æºç®¡ç† +的一些支æŒã€‚在Linuxä¸ï¼Œamba_deviceå’Œamba_bus_type结构体被用æ¥è¡¨ç¤º +Primecell设备。然而，棘手的一点是，AMBA总线上的所有设备并éžéƒ½æ˜¯Primecell， +而且对于Linuxæ¥è¯´ï¼Œå…¸åž‹çš„情况是amba_deviceå’Œplatform_deviceå®žä¾‹éƒ½æ˜¯åŒ +一总线段的åŒä¹‰è¯ã€‚ + +当使用DT时，这给of_platform_populate()带æ¥äº†é—®é¢˜ï¼Œå› 为它必须决定是å¦å°† +æ¯ä¸ªèŠ‚点注册为platform_device或amba_device。ä¸å¹¸çš„是，这使设备创建模型 +å˜å¾—有点å¤æ‚，但解决方案原æ¥å¹¶ä¸æ˜¯å¤ªå…·æœ‰ä¾µç•¥æ€§ã€‚如果一个节点与“arm,amba-primecell†+兼容，那么of_platform_populate()将把它注册为amba_device而ä¸æ˜¯ +platform_device。 diff --git a/Documentation/translations/zh_CN/index.rst b/Documentation/translations/zh_CN/index.rst index 46e14ec9963d..88d8df957a78 100644 --- a/Documentation/translations/zh_CN/index.rst +++ b/Documentation/translations/zh_CN/index.rst @@ -5,7 +5,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginSC + \kerneldocBeginSC{ .. _linux_doc_zh: @@ -56,10 +56,14 @@ TODOList: 下列文档æè¿°äº†å†…æ ¸éœ€è¦çš„å¹³å°å›ºä»¶ç›¸å…³ä¿¡æ¯ã€‚ +.. toctree:: + :maxdepth: 2 + + devicetree/index + TODOList: * firmware-guide/index -* devicetree/index 应用程åºå¼€å‘人员文档 -------------------- @@ -104,14 +108,17 @@ TODOList: :maxdepth: 2 core-api/index + accounting/index cpu-freq/index iio/index + infiniband/index + power/index + virt/index sound/index filesystems/index - virt/index - infiniband/index - accounting/index scheduler/index + vm/index + peci/index TODOList: @@ -129,7 +136,6 @@ TODOList: * netlabel/index * networking/index * pcmcia/index -* power/index * target/index * timers/index * spi/index @@ -140,7 +146,6 @@ TODOList: * gpu/index * security/index * crypto/index -* vm/index * bpf/index * usb/index * PCI/index @@ -198,4 +203,4 @@ TODOList: .. raw:: latex - \kerneldocEndSC + }\kerneldocEndSC diff --git a/Documentation/translations/zh_CN/peci/index.rst b/Documentation/translations/zh_CN/peci/index.rst new file mode 100644 index 000000000000..4f6694c828fa --- /dev/null +++ b/Documentation/translations/zh_CN/peci/index.rst @@ -0,0 +1,26 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/peci/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +================= +Linux PECI å系统 +================= + +.. toctree:: + + + peci + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/peci/peci.rst b/Documentation/translations/zh_CN/peci/peci.rst new file mode 100644 index 000000000000..a3b4f99b994c --- /dev/null +++ b/Documentation/translations/zh_CN/peci/peci.rst @@ -0,0 +1,54 @@ +.. SPDX-License-Identifier: GPL-2.0-only +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/peci/peci.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +==== +概述 +==== + +å¹³å°çŽ¯å¢ƒæŽ§åˆ¶æŽ¥å£ï¼ˆPECI）是英特尔处ç†å™¨å’Œç®¡ç†æŽ§åˆ¶å™¨ï¼ˆå¦‚底æ¿ç®¡ç†æŽ§åˆ¶å™¨ï¼ŒBMC） +之间的一个通信接å£ã€‚PECIæ供的æœåŠ¡å…许管ç†æŽ§åˆ¶å™¨é€šè¿‡è®¿é—®å„ç§å¯„å˜å™¨æ¥é…ç½®ã€ç›‘ +控和调试平å°ã€‚它定义了一个专门的命令å议，管ç†æŽ§åˆ¶å™¨ä½œä¸ºPECIçš„å‘起者，处ç†å™¨ +作为PECIçš„å“应者。PECIå¯ä»¥ç”¨äºŽåŸºäºŽå•å¤„ç†å™¨å’Œå¤šå¤„ç†å™¨çš„系统ä¸ã€‚ + +注æ„：英特尔PECI规范没有作为专门的文件å‘布，而是作为英特尔CPU的外部设计规范 +（EDS）的一部分。外部设计规范通常是ä¸å…¬å¼€çš„。 + +PECI 线 +--------- + +PECI线接å£ä½¿ç”¨å•çº¿è¿›è¡Œè‡ªé”和数æ®ä¼ 输。它ä¸éœ€è¦ä»»ä½•é¢å¤–的控制线--物ç†å±‚是一个 +自é”çš„å•çº¿æ€»çº¿ä¿¡å·ï¼Œæ¯ä¸€ä¸ªæ¯”特都从接近零ä¼çš„空闲状æ€å¼€å§‹é©±åŠ¨ã€ä¸Šå‡è¾¹ç¼˜ã€‚驱动高 +电平信å·çš„æŒç»æ—¶é—´å¯ä»¥ç¡®å®šä½å€¼æ˜¯é€»è¾‘ “0†还是逻辑 “1â€ã€‚PECI线还包括与æ¯ä¸ªä¿¡ +æ¯å»ºç«‹çš„å¯å˜æ•°æ®é€ŸçŽ‡ã€‚ + +对于PECI线，æ¯ä¸ªå¤„ç†å™¨åŒ…将在一个定义的范围内利用唯一的ã€å›ºå®šçš„地å€ï¼Œè¯¥åœ°å€åº” +该与处ç†å™¨æ’座ID有固定的关系--如果其ä¸ä¸€ä¸ªå¤„ç†å™¨è¢«ç§»é™¤ï¼Œå®ƒä¸ä¼šå½±å“其余处ç†å™¨ +的地å€ã€‚ + +PECIå系统代ç 内嵌文档 +------------------------ + +该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: + +include/linux/peci.h + +drivers/peci/internal.h + +drivers/peci/core.c + +drivers/peci/request.c + +PECI CPU 驱动 API +------------------- + +该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: + +drivers/peci/cpu.c diff --git a/Documentation/translations/zh_CN/power/energy-model.rst b/Documentation/translations/zh_CN/power/energy-model.rst new file mode 100644 index 000000000000..c7da1b6aefee --- /dev/null +++ b/Documentation/translations/zh_CN/power/energy-model.rst @@ -0,0 +1,190 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/energy-model.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +============ +设备能é‡æ¨¡åž‹ +============ + +1. 概述 +------- + +能é‡æ¨¡åž‹ï¼ˆEM）框架是一ç§é©±åŠ¨ç¨‹åºä¸Žå†…æ ¸å系统之间的接å£ã€‚å…¶ä¸é©±åŠ¨ç¨‹åºäº†è§£ä¸åŒ +æ€§èƒ½å±‚çº§çš„è®¾å¤‡æ‰€æ¶ˆè€—çš„åŠŸçŽ‡ï¼Œè€Œå†…æ ¸å系统愿æ„使用该信æ¯åšå‡ºèƒ½é‡æ„ŸçŸ¥å†³ç–。 + +设备所消耗的功率的信æ¯æ¥æºåœ¨ä¸åŒçš„å¹³å°ä¸Šå¯èƒ½æœ‰å¾ˆå¤§çš„ä¸åŒã€‚这些功率æˆæœ¬åœ¨æŸäº› +情况下å¯ä»¥ä½¿ç”¨è®¾å¤‡æ ‘æ•°æ®æ¥ä¼°ç®—。在其它情况下，固件会更清楚。或者，用户空间å¯èƒ½ +是最清楚的。以æ¤ç±»æŽ¨ã€‚为了é¿å…æ¯ä¸€ä¸ªå®¢æˆ·ç«¯å系统对æ¯ä¸€ç§å¯èƒ½çš„ä¿¡æ¯æºè‡ªå·±é‡æ–° +实现支æŒï¼ŒEMæ¡†æž¶ä½œä¸ºä¸€ä¸ªæŠ½è±¡å±‚ä»‹å…¥ï¼Œå®ƒåœ¨å†…æ ¸ä¸å¯¹åŠŸçŽ‡æˆæœ¬è¡¨çš„æ ¼å¼è¿›è¡Œæ ‡å‡†åŒ–， +å› æ¤èƒ½å¤Ÿé¿å…多余的工作。 + +功率值å¯ä»¥ç”¨æ¯«ç“¦æˆ–“抽象刻度â€è¡¨ç¤ºã€‚多个å系统å¯èƒ½ä½¿ç”¨EM，由系统集æˆå•†æ¥æ£€æŸ¥ +功率值刻度类型的è¦æ±‚是å¦æ»¡è¶³ã€‚å¯ä»¥åœ¨èƒ½é‡æ„ŸçŸ¥è°ƒåº¦å™¨çš„文档ä¸æ‰¾åˆ°ä¸€ä¸ªä¾‹å +Documentation/scheduler/sched-energy.rst。对于一些å系统，比如çƒèƒ½æˆ– +powercap，用“抽象刻度â€æ述功率值å¯èƒ½ä¼šå¯¼è‡´é—®é¢˜ã€‚这些å系统对过去使用的功率的 +ä¼°ç®—å€¼æ›´æ„Ÿå…´è¶£ï¼Œå› æ¤å¯èƒ½éœ€è¦çœŸå®žçš„毫瓦。这些è¦æ±‚的一个例åå¯ä»¥åœ¨æ™ºèƒ½åŠŸçŽ‡åˆ†é… +Documentation/driver-api/thermal/power_allocator.rst文档ä¸æ‰¾åˆ°ã€‚ + +å†…æ ¸å系统å¯èƒ½ï¼ˆåŸºäºŽEMå†…éƒ¨æ ‡å¿—ä½ï¼‰å®žçŽ°äº†å¯¹EM注册设备是å¦å…·æœ‰ä¸ä¸€è‡´åˆ»åº¦çš„自动 +检查。è¦è®°ä½çš„é‡è¦äº‹æƒ…是，当功率值以“抽象刻度â€è¡¨ç¤ºæ—¶ï¼Œä»Žä¸æŽ¨å¯¼ä»¥æ¯«ç„¦è€³ä¸ºå•ä½ +的真实能é‡æ¶ˆè€—是ä¸å¯èƒ½çš„。 + +下图æ述了一个驱动的例å（这里是针对Arm的，但该方法适用于任何体系结构），它 +å‘EM框架æ供了功率æˆæœ¬ï¼Œæ„Ÿå…´è¶£çš„客户端å¯ä»Žä¸è¯»å–æ•°æ®:: + + +---------------+ +-----------------+ +---------------+ + | Thermal (IPA) | | Scheduler (EAS) | | Other | + +---------------+ +-----------------+ +---------------+ + | | em_cpu_energy() | + | | em_cpu_get() | + +---------+ | +---------+ + | | | + v v v + +---------------------+ + | Energy Model | + | Framework | + +---------------------+ + ^ ^ ^ + | | | em_dev_register_perf_domain() + +----------+ | +---------+ + | | | + +---------------+ +---------------+ +--------------+ + | cpufreq-dt | | arm_scmi | | Other | + +---------------+ +---------------+ +--------------+ + ^ ^ ^ + | | | + +--------------+ +---------------+ +--------------+ + | Device Tree | | Firmware | | ? | + +--------------+ +---------------+ +--------------+ + +对于CPU设备，EM框架管ç†ç€ç³»ç»Ÿä¸æ¯ä¸ªâ€œæ€§èƒ½åŸŸâ€çš„功率æˆæœ¬è¡¨ã€‚一个性能域是一组 +性能一起伸缩的CPU。性能域通常与CPUFreqç–略具有1对1æ˜ å°„ã€‚ä¸€ä¸ªæ€§èƒ½åŸŸä¸çš„ +所有CPUè¦æ±‚具有相åŒçš„微架构。ä¸åŒæ€§èƒ½åŸŸä¸çš„CPUå¯ä»¥æœ‰ä¸åŒçš„微架构。 + + +2. æ ¸å¿ƒAPI +---------- + +2.1 é…置选项 +^^^^^^^^^^^^ + +必须使能CONFIG_ENERGY_MODELæ‰èƒ½ä½¿ç”¨EM框架。 + + +2.2 性能域的注册 +^^^^^^^^^^^^^^^^ + +“高级â€EM的注册 +~~~~~~~~~~~~~~~~ + +“高级â€EMå› å®ƒå…许驱动æ供更精确的功率模型而得å。它并ä¸å—é™äºŽæ¡†æž¶ä¸çš„一些已 +实现的数å¦å…¬å¼ï¼ˆå°±åƒâ€œç®€å•â€EMé‚£æ ·ï¼‰ã€‚å®ƒå¯ä»¥æ›´å¥½åœ°åæ˜ æ¯ä¸ªæ€§èƒ½çŠ¶æ€çš„实际功率 +测é‡ã€‚å› æ¤ï¼Œåœ¨EMé™æ€åŠŸçŽ‡ï¼ˆæ¼ç”µæµåŠŸçŽ‡ï¼‰æ˜¯é‡è¦çš„情况下，应该首选这ç§æ³¨å†Œæ–¹å¼ã€‚ + +驱动程åºåº”通过以下API将性能域注册到EM框架ä¸:: + + int em_dev_register_perf_domain(struct device *dev, unsigned int nr_states, + struct em_data_callback *cb, cpumask_t *cpus, bool milliwatts); + +驱动程åºå¿…é¡»æ供一个回调函数，为æ¯ä¸ªæ€§èƒ½çŠ¶æ€è¿”回<频率,功率>å…ƒç»„ã€‚é©±åŠ¨ç¨‹åº +æ供的回调函数å¯ä»¥è‡ªç”±åœ°ä»Žä»»ä½•ç›¸å…³ä½ç½®ï¼ˆDTã€å›ºä»¶......）以åŠä»¥ä»»ä½•è¢«è®¤ä¸ºæ˜¯ +å¿…è¦çš„æ–¹å¼èŽ·å–æ•°æ®ã€‚åªæœ‰å¯¹äºŽCPU设备，驱动程åºå¿…须使用cpumask指定性能域的CPU。 +对于CPU以外的其他设备，最åŽä¸€ä¸ªå‚数必须被设置为NULL。 + +最åŽä¸€ä¸ªå‚数“milliwattsâ€ï¼ˆæ¯«ç“¦ï¼‰è®¾ç½®æˆæ£ç¡®çš„值是很é‡è¦çš„，使用EMçš„å†…æ ¸ +å系统å¯èƒ½ä¼šä¾èµ–è¿™ä¸ªæ ‡å¿—æ¥æ£€æŸ¥æ‰€æœ‰çš„EM设备是å¦ä½¿ç”¨ç›¸åŒçš„刻度。如果有ä¸åŒçš„ +刻度，这些å系统å¯èƒ½å†³å®šï¼šè¿”回è¦å‘Š/错误，åœæ¢å·¥ä½œæˆ–崩溃（panic）。 + +关于实现这个回调函数的驱动程åºçš„例å，å‚è§ç¬¬3节。或者在第2.4节阅读这个API +的更多文档。 + + +“简å•â€EM的注册 +~~~~~~~~~~~~~~~~ + +“简å•â€EM是用框架的辅助函数cpufreq_register_em_with_opp()注册的。它实现了 +一个和以下数å¦å…¬å¼ç´§å¯†ç›¸å…³çš„功率模型:: + + Power = C * V^2 * f + +使用这ç§æ–¹æ³•æ³¨å†Œçš„EMå¯èƒ½æ— 法æ£ç¡®åæ˜ çœŸå®žè®¾å¤‡çš„ç‰©ç†ç‰¹æ€§ï¼Œä¾‹å¦‚当é™æ€åŠŸçŽ‡ +（æ¼ç”µæµåŠŸçŽ‡ï¼‰å¾ˆé‡è¦æ—¶ã€‚ + + +2.3 访问性能域 +^^^^^^^^^^^^^^ + +有两个API函数æ供对能é‡æ¨¡åž‹çš„访问。em_cpu_get()以CPU id为å‚数，em_pd_get() +以设备指针为å‚数。使用哪个接å£å–决于å系统，但对于CPU设备æ¥è¯´ï¼Œè¿™ä¸¤ä¸ªå‡½æ•°éƒ½è¿” +回相åŒçš„性能域。 + +对CPU的能é‡æ¨¡åž‹æ„Ÿå…´è¶£çš„å系统å¯ä»¥é€šè¿‡em_cpu_get() API检索它。在创建性能域时 +分é…一次能é‡æ¨¡åž‹è¡¨ï¼Œå®ƒä¿å˜åœ¨å†…å˜ä¸ä¸è¢«ä¿®æ”¹ã€‚ + +一个性能域所消耗的能é‡å¯ä»¥ä½¿ç”¨em_cpu_energy() APIæ¥ä¼°ç®—。该估算å‡å®šCPU设备 +使用的CPUfreq监管器是schedutil。当å‰è¯¥è®¡ç®—ä¸èƒ½æ供给其它类型的设备。 + +关于上述API的更多细节å¯ä»¥åœ¨ ``<linux/energy_model.h>`` 或第2.4节ä¸æ‰¾åˆ°ã€‚ + + +2.4 API的细节æè¿° +^^^^^^^^^^^^^^^^^ +å‚è§ include/linux/energy_model.h å’Œ kernel/power/energy_model.c çš„kernel doc。 + +3. 驱动示例 +----------- + +CPUFreq框架支æŒä¸“用的回调函数，用于为指定的CPU（们）注册EM： +cpufreq_driver::register_em()。这个回调必须为æ¯ä¸ªç‰¹å®šçš„驱动程åºæ£ç¡®å®žçŽ°ï¼Œ +å› ä¸ºæ¡†æž¶ä¼šåœ¨è®¾ç½®è¿‡ç¨‹ä¸é€‚时地调用它。本节æ供了一个简å•çš„例å，展示CPUFreq驱动 +在能é‡æ¨¡åž‹æ¡†æž¶ä¸ä½¿ç”¨ï¼ˆå‡çš„）“fooâ€å议注册性能域。该驱动实现了一个est_power() +函数æ供给EM框架:: + + -> drivers/cpufreq/foo_cpufreq.c + + 01 static int est_power(unsigned long *mW, unsigned long *KHz, + 02 struct device *dev) + 03 { + 04 long freq, power; + 05 + 06 /* 使用“fooâ€åè®®è®¾ç½®é¢‘çŽ‡ä¸Šé™ */ + 07 freq = foo_get_freq_ceil(dev, *KHz); + 08 if (freq < 0); + 09 return freq; + 10 + 11 /* 估算相关频率下设备的功率æˆæœ¬ */ + 12 power = foo_estimate_power(dev, freq); + 13 if (power < 0); + 14 return power; + 15 + 16 /* 将这些值返回给EM框架 */ + 17 *mW = power; + 18 *KHz = freq; + 19 + 20 return 0; + 21 } + 22 + 23 static void foo_cpufreq_register_em(struct cpufreq_policy *policy) + 24 { + 25 struct em_data_callback em_cb = EM_DATA_CB(est_power); + 26 struct device *cpu_dev; + 27 int nr_opp; + 28 + 29 cpu_dev = get_cpu_device(cpumask_first(policy->cpus)); + 30 + 31 /* 查找该ç–略支æŒçš„OPPæ•°é‡ */ + 32 nr_opp = foo_get_nr_opp(policy); + 33 + 34 /* 并注册新的性能域 */ + 35 em_dev_register_perf_domain(cpu_dev, nr_opp, &em_cb, policy->cpus, + 36 true); + 37 } + 38 + 39 static struct cpufreq_driver foo_cpufreq_driver = { + 40 .register_em = foo_cpufreq_register_em, + 41 }; diff --git a/Documentation/translations/zh_CN/power/index.rst b/Documentation/translations/zh_CN/power/index.rst new file mode 100644 index 000000000000..bc54983ba515 --- /dev/null +++ b/Documentation/translations/zh_CN/power/index.rst @@ -0,0 +1,56 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/index.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +======== +电æºç®¡ç† +======== + +.. toctree:: + :maxdepth: 1 + + energy-model + opp + +TODOList: + + * apm-acpi + * basic-pm-debugging + * charger-manager + * drivers-testing + * freezing-of-tasks + * pci + * pm_qos_interface + * power_supply_class + * runtime_pm + * s2ram + * suspend-and-cpuhotplug + * suspend-and-interrupts + * swsusp-and-swap-files + * swsusp-dmcrypt + * swsusp + * video + * tricks + + * userland-swsusp + + * powercap/powercap + * powercap/dtpm + + * regulator/consumer + * regulator/design + * regulator/machine + * regulator/overview + * regulator/regulator + +.. only:: subproject and html + + Indices + ======= + + * :ref:`genindex` diff --git a/Documentation/translations/zh_CN/power/opp.rst b/Documentation/translations/zh_CN/power/opp.rst new file mode 100644 index 000000000000..8d6e3f6f6202 --- /dev/null +++ b/Documentation/translations/zh_CN/power/opp.rst @@ -0,0 +1,341 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/power/opp.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +====================== +æ“作性能值（OPP）库 +====================== + +(C) 2009-2010 Nishanth Menon <nm@ti.com>, å¾·å·žä»ªå™¨å…¬å¸ + +.. 目录 + + 1. 简介 + 2. OPP链表åˆå§‹æ³¨å†Œ + 3. OPPæœç´¢å‡½æ•° + 4. OPPå¯ç”¨æ€§æŽ§åˆ¶å‡½æ•° + 5. OPPæ•°æ®æ£€ç´¢å‡½æ•° + 6. æ•°æ®ç»“æž„ + +1. 简介 +======= + +1.1 何为æ“作性能值（OPP）？ +------------------------------ + +当今å¤æ‚çš„å•ç‰‡ç³»ç»Ÿï¼ˆSoC）由多个å模å—组æˆï¼Œè¿™äº›å模å—会è”åˆå·¥ä½œã€‚在一个执行ä¸åŒç”¨ä¾‹ +çš„æ“作系统ä¸ï¼Œå¹¶ä¸æ˜¯SoCä¸çš„所有模å—都需è¦ä¸€ç›´ä»¥æœ€é«˜é¢‘率工作。为了促æˆè¿™ä¸€ç‚¹ï¼ŒSoCä¸ +çš„å模å—被分组为ä¸åŒåŸŸï¼Œå…许一些域以较低的电压和频率è¿è¡Œï¼Œè€Œå…¶å®ƒåŸŸåˆ™ä»¥è¾ƒé«˜çš„“电压/ +频率对â€è¿è¡Œã€‚ + +设备按域支æŒçš„由频率电压对组æˆçš„离散的元组的集åˆï¼Œè¢«ç§°ä¸ºæ“作性能值（组），或OPPs。 + +举例æ¥è¯´ï¼š + +让我们考虑一个支æŒä¸‹è¿°é¢‘率ã€ç”µåŽ‹å€¼çš„内å˜ä¿æŠ¤å•å…ƒï¼ˆMPU）设备： +{300MHz，最低电压为1V}, {800MHz，最低电压为1.2V}, {1GHz，最低电压为1.3V} + +我们能将它们表示为3个OPP，如下述{Hz, uV}元组（译注：频率的å•ä½æ˜¯èµ«å…¹ï¼Œç”µåŽ‹çš„å•ä½æ˜¯ +å¾®ä¼ï¼‰ã€‚ + +- {300000000, 1000000} +- {800000000, 1200000} +- {1000000000, 1300000} + +1.2 æ“作性能值库 +---------------- + +OPP库æ供了一组辅助函数æ¥ç»„织和查询OPPä¿¡æ¯ã€‚该库ä½äºŽdrivers/opp/目录下，其头文件 +ä½äºŽinclude/linux/pm_opp.hä¸ã€‚OPP库å¯ä»¥é€šè¿‡å¼€å¯CONFIG_PM_OPPæ¥å¯ç”¨ã€‚æŸäº›SoC， +如德州仪器的OMAP框架å…许在ä¸éœ€è¦cpufreq的情况下å¯é€‰åœ°åœ¨æŸä¸€OPP下å¯åŠ¨ã€‚ + +OPP库的典型用法如下:: + + （用户） -> 注册一个默认的OPPé›†åˆ -> （库） + （SoC框架） -> 在必è¦çš„情况下，对æŸäº›OPP进行修改 -> OPP layer + -> æœç´¢/检索信æ¯çš„查询 -> + +OPP层期望æ¯ä¸ªåŸŸç”±ä¸€ä¸ªå”¯ä¸€çš„设备指针æ¥è¡¨ç¤ºã€‚SoC框架在OPP层为æ¯ä¸ªè®¾å¤‡æ³¨å†Œäº†ä¸€ç»„åˆå§‹ +OPP。这个链表的长度被期望是一个最优化的å°æ•°å—，通常æ¯ä¸ªè®¾å¤‡å¤§çº¦5个。åˆå§‹é“¾è¡¨åŒ…å«äº† +一个OPP集åˆï¼Œè¿™ä¸ªé›†åˆè¢«æœŸæœ›èƒ½åœ¨ç³»ç»Ÿä¸å®‰å…¨ä½¿èƒ½ã€‚ + +关于OPPå¯ç”¨æ€§çš„说明 +^^^^^^^^^^^^^^^^^^^ + +éšç€ç³»ç»Ÿçš„è¿è¡Œï¼ŒSoC框架å¯èƒ½ä¼šåŸºäºŽå„ç§å¤–éƒ¨å› ç´ é€‰æ‹©è®©æŸäº›OPP在æ¯ä¸ªè®¾å¤‡ä¸Šå¯ç”¨æˆ–ä¸å¯ç”¨ï¼Œ +示例：温度管ç†æˆ–其它异常场景ä¸ï¼ŒSoC框架å¯èƒ½ä¼šé€‰æ‹©ç¦ç”¨ä¸€ä¸ªè¾ƒé«˜é¢‘率的OPPä»¥å®‰å…¨åœ°ç»§ç» +è¿è¡Œï¼Œç›´åˆ°è¯¥OPP被é‡æ–°å¯ç”¨ï¼ˆå¦‚æžœå¯èƒ½ï¼‰ã€‚ + +OPP库在它的实现ä¸è¾¾æˆäº†è¿™ä¸ªæ¦‚念。以下æ“作函数åªèƒ½å¯¹å¯ç”¨çš„OPP使用： +dev_pm_opp_find_freq_{ceil, floor}, dev_pm_opp_get_voltage, +dev_pm_opp_get_freq, dev_pm_opp_get_opp_count。 + +dev_pm_opp_find_freq_exact是用æ¥æŸ¥æ‰¾OPP指针的，该指针å¯è¢«ç”¨åœ¨dev_pm_opp_enable/ +disable函数，使一个OPP在被需è¦æ—¶å˜ä¸ºå¯ç”¨ã€‚ + +è¦å‘Šï¼šå¦‚果对一个设备调用dev_pm_opp_enable/disable函数，OPP库的用户应该使用 +dev_pm_opp_get_opp_countæ¥åˆ·æ–°OPPçš„å¯ç”¨æ€§è®¡æ•°ã€‚触å‘这些的具体机制，或者对有ä¾èµ–çš„ +å系统（比如cpufreq）的通知机制，都是由使用OPP库的SoC特定框架酌情处ç†çš„。在这些æ“作 +ä¸ï¼ŒåŒæ ·éœ€è¦æ³¨æ„刷新cpufreq表。 + +2. OPP链表åˆå§‹æ³¨å†Œ +================== +SoC的实现会è¿ä»£è°ƒç”¨dev_pm_opp_add函数æ¥å¢žåŠ æ¯ä¸ªè®¾å¤‡çš„OPP。预期SoC框架将以最优的 +æ–¹å¼æ³¨å†ŒOPPæ¡ç›® - 典型的数å—范围å°äºŽ5。通过注册OPP生æˆçš„OPP链表，在整个设备è¿è¡Œè¿‡ç¨‹ +ä¸ç”±OPP库维护。SoC框架éšåŽå¯ä»¥ä½¿ç”¨dev_pm_opp_enable / disable函数动æ€åœ° +控制OPPçš„å¯ç”¨æ€§ã€‚ + +dev_pm_opp_add + 为设备指针所指å‘çš„ç‰¹å®šåŸŸæ·»åŠ ä¸€ä¸ªæ–°çš„OPP。OPPæ˜¯ç”¨é¢‘çŽ‡å’Œç”µåŽ‹å®šä¹‰çš„ã€‚ä¸€æ—¦å®Œæˆ + æ·»åŠ ï¼ŒOPP被认为是å¯ç”¨çš„，å¯ä»¥ç”¨dev_pm_opp_enable/disable函数æ¥æŽ§åˆ¶å…¶å¯ç”¨æ€§ã€‚ + OPP库内部用dev_pm_opp结构体å˜å‚¨å¹¶ç®¡ç†è¿™äº›ä¿¡æ¯ã€‚这个函数å¯ä»¥è¢«SoCæ¡†æž¶æ ¹æ®SoC + 的使用环境的需求æ¥å®šä¹‰ä¸€ä¸ªæœ€ä¼˜é“¾è¡¨ã€‚ + + è¦å‘Šï¼š + ä¸è¦åœ¨ä¸æ–上下文使用这个函数。 + + 示例:: + + soc_pm_init() + { + /* åšä¸€äº›äº‹æƒ… */ + r = dev_pm_opp_add(mpu_dev, 1000000, 900000); + if (!r) { + pr_err("%s: unable to register mpu opp(%d)\n", r); + goto no_cpufreq; + } + /* åšä¸€äº›å’Œcpufreq相关的事情 */ + no_cpufreq: + /* åšå‰©ä½™çš„事情 */ + } + +3. OPPæœç´¢å‡½æ•° +============== +cpufreqç‰é«˜å±‚框架对频率进行æ“ä½œï¼Œä¸ºäº†å°†é¢‘çŽ‡æ˜ å°„åˆ°ç›¸åº”çš„OPP，OPP库æ供了便利的函数 +æ¥æœç´¢OPP库内部管ç†çš„OPP链表。这些æœç´¢å‡½æ•°å¦‚果找到匹é…çš„OPP，将返回指å‘该OPP的指针， +å¦åˆ™è¿”å›žé”™è¯¯ã€‚è¿™äº›é”™è¯¯é¢„è®¡ç”±æ ‡å‡†çš„é”™è¯¯æ£€æŸ¥ï¼Œå¦‚IS_ERR()æ¥å¤„ç†ï¼Œå¹¶ç”±è°ƒç”¨è€…采å–适当的 +行动。 + +这些函数的调用者应在使用完OPPåŽè°ƒç”¨dev_pm_opp_put()。å¦åˆ™ï¼ŒOPP的内å˜å°†æ°¸è¿œä¸ä¼š +被释放，并导致内å˜æ³„露。 + +dev_pm_opp_find_freq_exact + æ ¹æ® *精确的* 频率和å¯ç”¨æ€§æ¥æœç´¢OPP。这个函数对默认ä¸å¯ç”¨çš„OPP特别有用。 + 例å：在SoC框架检测到更高频率å¯ç”¨çš„情况下，它å¯ä»¥ä½¿ç”¨è¿™ä¸ªå‡½æ•°åœ¨è°ƒç”¨ + dev_pm_opp_enable之å‰æ‰¾åˆ°OPP:: + + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); + dev_pm_opp_put(opp); + /* ä¸è¦æ“作指针.. åªæ˜¯åšæœ‰æ•ˆæ€§æ£€æŸ¥.. */ + if (IS_ERR(opp)) { + pr_err("frequency not disabled!\n"); + /* 触å‘åˆé€‚çš„æ“作.. */ + } else { + dev_pm_opp_enable(dev,1000000000); + } + + 注æ„： + 这是唯一一个å¯ä»¥æœç´¢ä¸å¯ç”¨OPP的函数。 + +dev_pm_opp_find_freq_floor + æœç´¢ä¸€ä¸ª *最多* æ供指定频率的å¯ç”¨OPP。这个函数在æœç´¢è¾ƒå°çš„匹é…或按频率 + 递å‡çš„顺åºæ“作OPPä¿¡æ¯æ—¶å¾ˆæœ‰ç”¨ã€‚ + 例å：è¦æ‰¾çš„一个设备的最高OPP:: + + freq = ULONG_MAX; + opp = dev_pm_opp_find_freq_floor(dev, &freq); + dev_pm_opp_put(opp); + +dev_pm_opp_find_freq_ceil + æœç´¢ä¸€ä¸ª *最少* æ供指定频率的å¯ç”¨OPP。这个函数在æœç´¢è¾ƒå¤§çš„匹é…或按频率 + 递增的顺åºæ“作OPPä¿¡æ¯æ—¶å¾ˆæœ‰ç”¨ã€‚ + 例1：找到一个设备最å°çš„OPP:: + + freq = 0; + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + dev_pm_opp_put(opp); + + 例: 一个SoCçš„cpufreq_driver->target的简易实现:: + + soc_cpufreq_target(..) + { + /* åšç–略检查ç‰æ“作 */ + /* 找到和请求最接近的频率 */ + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + dev_pm_opp_put(opp); + if (!IS_ERR(opp)) + soc_switch_to_freq_voltage(freq); + else + /* 当ä¸èƒ½æ»¡è¶³è¯·æ±‚时，è¦åšçš„事 */ + /* åšå…¶å®ƒäº‹ */ + } + +4. OPPå¯ç”¨æ€§æŽ§åˆ¶å‡½æ•° +==================== +在OPP库ä¸æ³¨å†Œçš„默认OPPé“¾è¡¨ä¹Ÿè®¸æ— æ³•æ»¡è¶³æ‰€æœ‰å¯èƒ½çš„场景。OPP库æ供了一套函数æ¥ä¿®æ”¹ +OPP链表ä¸çš„æŸä¸ªOPPçš„å¯ç”¨æ€§ã€‚这使得SoC框架能够精细地动æ€æŽ§åˆ¶å“ªä¸€ç»„OPP是å¯ç”¨äºŽæ“作 +的。设计这些函数的目的是在诸如考虑温度时 *暂时地* åˆ é™¤æŸä¸ªOPPï¼ˆä¾‹å¦‚ï¼Œåœ¨æ¸©åº¦ä¸‹é™ +之å‰ä¸è¦ä½¿ç”¨æŸOPP）。 + +è¦å‘Šï¼š + ä¸è¦åœ¨ä¸æ–上下文使用这些函数。 + +dev_pm_opp_enable + 使一个OPPå¯ç”¨äºŽæ“作。 + 例å：å‡è®¾1GHzçš„OPPåªæœ‰åœ¨SoC温度低于æŸä¸ªé˜ˆå€¼æ—¶æ‰å¯ç”¨ã€‚SoC框架的实现å¯èƒ½ + 会选择åšä»¥ä¸‹äº‹æƒ…:: + + if (cur_temp < temp_low_thresh) { + /* è‹¥1GHz未使能，则使能 */ + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, false); + dev_pm_opp_put(opp); + /* 仅仅是错误检查 */ + if (!IS_ERR(opp)) + ret = dev_pm_opp_enable(dev, 1000000000); + else + goto try_something_else; + } + +dev_pm_opp_disable + 使一个OPPä¸å¯ç”¨äºŽæ“作。 + 例å：å‡è®¾1GHzçš„OPPåªæœ‰åœ¨SoC温度高于æŸä¸ªé˜ˆå€¼æ—¶æ‰å¯ç”¨ã€‚SoC框架的实现å¯èƒ½ + 会选择åšä»¥ä¸‹äº‹æƒ…:: + + if (cur_temp > temp_high_thresh) { + /* è‹¥1GHzå·²ä½¿èƒ½ï¼Œåˆ™å…³é— */ + opp = dev_pm_opp_find_freq_exact(dev, 1000000000, true); + dev_pm_opp_put(opp); + /* 仅仅是错误检查 */ + if (!IS_ERR(opp)) + ret = dev_pm_opp_disable(dev, 1000000000); + else + goto try_something_else; + } + +5. OPPæ•°æ®æ£€ç´¢å‡½æ•° +================== +由于OPP库对OPPä¿¡æ¯è¿›è¡Œäº†æŠ½è±¡åŒ–处ç†ï¼Œå› æ¤éœ€è¦ä¸€ç»„函数æ¥ä»Ždev_pm_opp结构体ä¸æå– +ä¿¡æ¯ã€‚一旦使用æœç´¢å‡½æ•°æ£€ç´¢åˆ°ä¸€ä¸ªOPP指针，以下函数就å¯ä»¥è¢«SoC框架用æ¥æ£€ç´¢OPP层 +内部æè¿°çš„ä¿¡æ¯ã€‚ + +dev_pm_opp_get_voltage + 检索OPP指针æ述的电压。 + 例å: 当cpufreq切æ¢åˆ°åˆ°ä¸åŒé¢‘率时，SoC框架需è¦ç”¨ç¨³åŽ‹å™¨æ¡†æž¶å°†OPPæè¿° + 的电压设置到æ供电压的电æºç®¡ç†èŠ¯ç‰‡ä¸:: + + soc_switch_to_freq_voltage(freq) + { + /* åšä¸€äº›äº‹æƒ… */ + opp = dev_pm_opp_find_freq_ceil(dev, &freq); + v = dev_pm_opp_get_voltage(opp); + dev_pm_opp_put(opp); + if (v) + regulator_set_voltage(.., v); + /* åšå…¶å®ƒäº‹ */ + } + +dev_pm_opp_get_freq + 检索OPP指针æ述的频率。 + 例å：比方说，SoCæ¡†æž¶ä½¿ç”¨äº†å‡ ä¸ªè¾…åŠ©å‡½æ•°ï¼Œé€šè¿‡è¿™äº›å‡½æ•°ï¼Œæˆ‘ä»¬å¯ä»¥å°†OPP + æŒ‡é’ˆä¼ å…¥ï¼Œè€Œä¸æ˜¯ä¼ å…¥é¢å¤–çš„å‚数，用æ¥å¤„ç†ä¸€ç³»åˆ—æ•°æ®å‚æ•°:: + + soc_cpufreq_target(..) + { + /* åšä¸€äº›äº‹æƒ….. */ + max_freq = ULONG_MAX; + max_opp = dev_pm_opp_find_freq_floor(dev,&max_freq); + requested_opp = dev_pm_opp_find_freq_ceil(dev,&freq); + if (!IS_ERR(max_opp) && !IS_ERR(requested_opp)) + r = soc_test_validity(max_opp, requested_opp); + dev_pm_opp_put(max_opp); + dev_pm_opp_put(requested_opp); + /* åšå…¶å®ƒäº‹ */ + } + soc_test_validity(..) + { + if(dev_pm_opp_get_voltage(max_opp) < dev_pm_opp_get_voltage(requested_opp)) + return -EINVAL; + if(dev_pm_opp_get_freq(max_opp) < dev_pm_opp_get_freq(requested_opp)) + return -EINVAL; + /* åšä¸€äº›äº‹æƒ….. */ + } + +dev_pm_opp_get_opp_count + 检索æŸä¸ªè®¾å¤‡å¯ç”¨çš„OPPæ•°é‡ã€‚ + 例å：å‡è®¾SoCä¸çš„一个å处ç†å™¨éœ€è¦çŸ¥é“æŸä¸ªè¡¨ä¸çš„å¯ç”¨é¢‘率，主处ç†å™¨å¯ä»¥ + 按如下方å¼å‘出通知:: + + soc_notify_coproc_available_frequencies() + { + /* åšä¸€äº›äº‹æƒ… */ + num_available = dev_pm_opp_get_opp_count(dev); + speeds = kzalloc(sizeof(u32) * num_available, GFP_KERNEL); + /* 按å‡åºå¡«å……表 */ + freq = 0; + while (!IS_ERR(opp = dev_pm_opp_find_freq_ceil(dev, &freq))) { + speeds[i] = freq; + freq++; + i++; + dev_pm_opp_put(opp); + } + + soc_notify_coproc(AVAILABLE_FREQs, speeds, num_available); + /* åšå…¶å®ƒäº‹ */ + } + +6. æ•°æ®ç»“æž„ +=========== +通常，一个SoC包å«å¤šä¸ªå¯å˜ç”µåŽ‹åŸŸã€‚æ¯ä¸ªåŸŸç”±ä¸€ä¸ªè®¾å¤‡æŒ‡é’ˆæ述。和OPP之间的关系å¯ä»¥ +按以下方å¼æè¿°:: + + SoC + |- device 1 + | |- opp 1 (availability, freq, voltage) + | |- opp 2 .. + ... ... + | `- opp n .. + |- device 2 + ... + `- device m + +OPP库维护ç€ä¸€ä¸ªå†…部链表，SoC框架使用上文æè¿°çš„å„个函数æ¥å¡«å……和访问。然而，æè¿° +真实OPP和域的结构体是OPP库自身的内部组æˆï¼Œä»¥å…许åˆé€‚的抽象在ä¸åŒç³»ç»Ÿä¸å¾—到å¤ç”¨ã€‚ + +struct dev_pm_opp + OPP库的内部数æ®ç»“构，用于表示一个OPP。除了频率ã€ç”µåŽ‹ã€å¯ç”¨æ€§ä¿¡æ¯å¤–， + 它还包å«OPP库è¿è¡Œæ‰€éœ€çš„内部统计信æ¯ã€‚指å‘这个结构体的指针被æ供给 + 用户（比如SoC框架）使用，在与OPP层的交互ä¸ä½œä¸ºOPPçš„æ ‡è¯†ç¬¦ã€‚ + + è¦å‘Šï¼š + 结构体dev_pm_opp的指针ä¸åº”该由用户解æžæˆ–修改。一个实例的默认值由 + dev_pm_opp_add填充，但OPPçš„å¯ç”¨æ€§ç”±dev_pm_opp_enable/disable函数 + 修改。 + +struct device + 这用于å‘OPPå±‚æ ‡è¯†ä¸€ä¸ªåŸŸã€‚è®¾å¤‡çš„æ€§è´¨å’Œå®ƒçš„å®žçŽ°æ˜¯ç”±OPP库的用户决定的， + 如SoC框架。 + +总体æ¥è¯´ï¼Œä»¥ä¸€ä¸ªç®€åŒ–的视角看，对数æ®ç»“æž„çš„æ“作å¯ä»¥æ述为下é¢å„图:: + + åˆå§‹åŒ– / 修改: + +-----+ /- dev_pm_opp_enable + dev_pm_opp_add --> | opp | <------- + | +-----+ \- dev_pm_opp_disable + \-------> domain_info(device) + + æœç´¢å‡½æ•°: + /-- dev_pm_opp_find_freq_ceil ---\ +-----+ + domain_info<---- dev_pm_opp_find_freq_exact -----> | opp | + \-- dev_pm_opp_find_freq_floor ---/ +-----+ + + 检索函数: + +-----+ /- dev_pm_opp_get_voltage + | opp | <--- + +-----+ \- dev_pm_opp_get_freq + + domain_info <- dev_pm_opp_get_opp_count diff --git a/Documentation/translations/zh_CN/process/programming-language.rst b/Documentation/translations/zh_CN/process/programming-language.rst index 2a47a1d2ec20..fabdc338dbfb 100644 --- a/Documentation/translations/zh_CN/process/programming-language.rst +++ b/Documentation/translations/zh_CN/process/programming-language.rst @@ -9,8 +9,7 @@ ============ å†…æ ¸æ˜¯ç”¨Cè¯è¨€ :ref:`c-language <cn_c-language>` ç¼–å†™çš„ã€‚æ›´å‡†ç¡®åœ°è¯´ï¼Œå†…æ ¸é€šå¸¸æ˜¯ç”¨ :ref:`gcc <cn_gcc>` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C90çš„ GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <cn_gcc-c-dialect-options>` 下编译的：ISO C11çš„ GNU 方言 è¿™ç§æ–¹è¨€åŒ…å«å¯¹è¯è¨€ :ref:`gnu-extensions <cn_gnu-extensions>` çš„è®¸å¤šæ‰©å±•ï¼Œå½“ç„¶ï¼Œå®ƒä»¬è®¸å¤šéƒ½åœ¨å†…æ ¸ä¸ä½¿ç”¨ã€‚ diff --git a/Documentation/translations/zh_CN/riscv/index.rst b/Documentation/translations/zh_CN/riscv/index.rst index bbf5d7b3777a..614cde0c0997 100644 --- a/Documentation/translations/zh_CN/riscv/index.rst +++ b/Documentation/translations/zh_CN/riscv/index.rst @@ -18,6 +18,7 @@ RISC-V 体系结构 :maxdepth: 1 boot-image-header + vm-layout pmu patch-acceptance diff --git a/Documentation/translations/zh_CN/riscv/vm-layout.rst b/Documentation/translations/zh_CN/riscv/vm-layout.rst new file mode 100644 index 000000000000..585cb89317a3 --- /dev/null +++ b/Documentation/translations/zh_CN/riscv/vm-layout.rst @@ -0,0 +1,67 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/riscv/vm-layout.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +============================ +RISC-V Linux上的虚拟内å˜å¸ƒå±€ +============================ + +:作者: Alexandre Ghiti <alex@ghiti.fr> +:日期: 12 February 2021 + +这份文件æ述了RISC-V Linuxå†…æ ¸ä½¿ç”¨çš„è™šæ‹Ÿå†…å˜å¸ƒå±€ã€‚ + +32ä½ RISC-V Linux å†…æ ¸ +====================== + +RISC-V Linux Kernel SV32 +------------------------ + +TODO + +64ä½ RISC-V Linux å†…æ ¸ +====================== + +RISC-V特æƒæž¶æž„文档指出，64ä½åœ°å€ "必须使第63-48ä½å€¼éƒ½ç‰äºŽç¬¬47ä½ï¼Œå¦åˆ™å°†å‘生缺页异常。"：这将虚 +拟地å€ç©ºé—´åˆ†æˆä¸¤åŠï¼Œä¸é—´æœ‰ä¸€ä¸ªéžå¸¸å¤§çš„洞，下åŠéƒ¨åˆ†æ˜¯ç”¨æˆ·ç©ºé—´æ‰€åœ¨çš„地方，上åŠéƒ¨åˆ†æ˜¯RISC-V Linux +å†…æ ¸æ‰€åœ¨çš„åœ°æ–¹ã€‚ + +RISC-V Linux Kernel SV39 +------------------------ + +:: + + ======================================================================================================================== + å¼€å§‹åœ°å€ | å移 | 结æŸåœ°å€ | å¤§å° | 虚拟内å˜åŒºåŸŸæè¿° + ======================================================================================================================== + | | | | + 0000000000000000 | 0 | 0000003fffffffff | 256 GB | 用户空间虚拟内å˜ï¼Œæ¯ä¸ªå†…å˜ç®¡ç†å™¨ä¸åŒ + __________________|____________|__________________|_________|___________________________________________________________ + | | | | + 0000004000000000 | +256 GB | ffffffbfffffffff | ~16M TB | ... 巨大的ã€å‡ 乎64ä½å®½çš„ç›´åˆ°å†…æ ¸æ˜ å°„çš„-256GB地方 + | | | | 开始å移的éžç»å…¸è™šæ‹Ÿå†…å˜åœ°å€ç©ºæ´žã€‚ + | | | | + __________________|____________|__________________|_________|___________________________________________________________ + | + | å†…æ ¸ç©ºé—´çš„è™šæ‹Ÿå†…å˜ï¼Œåœ¨æ‰€æœ‰è¿›ç¨‹ä¹‹é—´å…±äº«: + ____________________________________________________________|___________________________________________________________ + | | | | + ffffffc6fee00000 | -228 GB | ffffffc6feffffff | 2 MB | fixmap + ffffffc6ff000000 | -228 GB | ffffffc6ffffffff | 16 MB | PCI io + ffffffc700000000 | -228 GB | ffffffc7ffffffff | 4 GB | vmemmap + ffffffc800000000 | -224 GB | ffffffd7ffffffff | 64 GB | vmalloc/ioremap space + ffffffd800000000 | -160 GB | fffffff6ffffffff | 124 GB | ç›´æŽ¥æ˜ å°„æ‰€æœ‰ç‰©ç†å†…å˜ + fffffff700000000 | -36 GB | fffffffeffffffff | 32 GB | kasan + __________________|____________|__________________|_________|____________________________________________________________ + | + | + ____________________________________________________________|____________________________________________________________ + | | | | + ffffffff00000000 | -4 GB | ffffffff7fffffff | 2 GB | modules, BPF + ffffffff80000000 | -2 GB | ffffffffffffffff | 2 GB | kernel + __________________|____________|__________________|_________|____________________________________________________________ diff --git a/Documentation/translations/zh_CN/scheduler/index.rst b/Documentation/translations/zh_CN/scheduler/index.rst index f8f8f35d53c7..12bf3bd02ccf 100644 --- a/Documentation/translations/zh_CN/scheduler/index.rst +++ b/Documentation/translations/zh_CN/scheduler/index.rst @@ -5,6 +5,7 @@ :翻译: å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> :æ ¡è¯‘: @@ -23,16 +24,14 @@ Linux调度器 sched-design-CFS sched-domains sched-capacity - + sched-energy + sched-nice-design + sched-stats TODOList: - sched-bwc sched-deadline - sched-energy - sched-nice-design sched-rt-group - sched-stats text_files diff --git a/Documentation/translations/zh_CN/scheduler/sched-energy.rst b/Documentation/translations/zh_CN/scheduler/sched-energy.rst new file mode 100644 index 000000000000..fdbf6cfeea93 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-energy.rst @@ -0,0 +1,351 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-energy.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +============ +能é‡æ„ŸçŸ¥è°ƒåº¦ +============ + +1. 简介 +------- + +能é‡æ„ŸçŸ¥è°ƒåº¦ï¼ˆEAS）使调度器有能力预测其决ç–对CPU所消耗的能é‡çš„å½±å“。EASä¾é +一个能é‡æ¨¡åž‹ï¼ˆEM）æ¥ä¸ºæ¯ä¸ªä»»åŠ¡é€‰æ‹©ä¸€ä¸ªèŠ‚能的CPU，åŒæ—¶æœ€å°åŒ–对åžå率的影å“。 +本文档致力于介ç»ä»‹ç»EAS是如何工作的，它背åŽçš„主è¦è®¾è®¡å†³ç–是什么，以åŠä½¿å…¶è¿è¡Œ +所需的æ¡ä»¶ç»†èŠ‚。 + +在进一æ¥é˜…读之å‰ï¼Œè¯·æ³¨æ„，在撰写本文时:: + + /!\ EASä¸æ”¯æŒå¯¹ç§°CPUæ‹“æ‰‘çš„å¹³å° /!\ + +EASåªåœ¨å¼‚æž„CPU拓扑结构（如Arm大å°æ ¸ï¼Œbig.LITTLE）上è¿è¡Œã€‚å› ä¸ºåœ¨è¿™ç§æƒ…况下， +通过调度æ¥èŠ‚约能é‡çš„潜力是最大的。 + +EAS实际使用的EMä¸æ˜¯ç”±è°ƒåº¦å™¨ç»´æŠ¤çš„，而是一个专门的框架。关于这个框架的细节和 +它æ供的内容，请å‚考其文档（è§Documentation/power/energy-model.rst）。 + + +2. èƒŒæ™¯å’Œæœ¯è¯ +------------- + +从一开始就说清楚定义: + - èƒ½é‡ = [焦耳] ï¼ˆæ¯”å¦‚ä¾›ç”µè®¾å¤‡ä¸Šçš„ç”µæ± æ供的资æºï¼‰ + - 功率 = 能é‡/时间 = [焦耳/秒] = [瓦特] + + EASçš„ç›®æ ‡æ˜¯æœ€å°åŒ–能é‡æ¶ˆè€—，åŒæ—¶ä»èƒ½å°†å·¥ä½œå®Œæˆã€‚也就是说，我们è¦æœ€å¤§åŒ–:: + + 性能 [指令数/秒] + ---------------- + 功率 [瓦特] + +它ç‰æ•ˆäºŽæœ€å°åŒ–:: + + èƒ½é‡ [焦耳] + ----------- + 指令数 + +åŒæ—¶ä»ç„¶èŽ·å¾—“良好â€çš„性能。当å‰è°ƒåº¦å™¨åªè€ƒè™‘æ€§èƒ½ç›®æ ‡ï¼Œå› æ¤è¯¥å¼å本质上是一个 +å¯é€‰çš„ä¼˜åŒ–ç›®æ ‡ï¼Œå®ƒåŒæ—¶è€ƒè™‘äº†ä¸¤ä¸ªç›®æ ‡ï¼šèƒ½é‡æ•ˆçŽ‡å’Œæ€§èƒ½ã€‚ + +引入EM的想法是为了让调度器评估其决ç–çš„å½±å“，而ä¸æ˜¯ç›²ç›®åœ°åº”用å¯èƒ½ä»…在部分 +å¹³å°æœ‰æ£é¢æ•ˆæžœçš„节能技术。åŒæ—¶ï¼ŒEM必须尽å¯èƒ½çš„简å•ï¼Œä»¥æœ€å°åŒ–调度器的时延 +å½±å“。 + +简而言之，EAS改å˜äº†CFS任务分é…ç»™CPUçš„æ–¹å¼ã€‚当调度器决定一个任务应该在哪里 +è¿è¡Œæ—¶ï¼ˆåœ¨å”¤é†’期间），EM被用æ¥åœ¨ä¸æŸå®³ç³»ç»ŸåžåçŽ‡çš„æƒ…å†µä¸‹ï¼Œä»Žå‡ ä¸ªè¾ƒå¥½çš„å€™é€‰ +CPUä¸æŒ‘选一个ç»é¢„测能é‡æ¶ˆè€—最优的CPU。EAS的预测ä¾èµ–于对平å°æ‹“æ‰‘ç»“æž„ç‰¹å®šå…ƒç´ +的了解，包括CPU的“算力â€ï¼Œä»¥åŠå®ƒä»¬å„自的能é‡æˆæœ¬ã€‚ + + +3. æ‹“æ‰‘ä¿¡æ¯ +----------- + +EAS（以åŠè°ƒåº¦å™¨çš„剩余部分）使用“算力â€çš„概念æ¥åŒºåˆ†ä¸åŒè®¡ç®—åžå率的CPU。一个 +CPU的“算力â€ä»£è¡¨äº†å®ƒåœ¨æœ€é«˜é¢‘率下è¿è¡Œæ—¶èƒ½å®Œæˆçš„工作é‡ï¼Œä¸”è¿™ä¸ªå€¼æ˜¯ç›¸å¯¹ç³»ç»Ÿä¸ +算力最大的CPU而言的。算力值被归一化为1024以内，并且å¯ä¸Žç”±å®žä½“负载跟踪 +（PELT）机制算出的利用率信å·åšå¯¹æ¯”。由于有算力值和利用率值，EAS能够估计一个 +任务/CPU有多大/有多忙，并在评估性能与能é‡æ—¶å°†å…¶è€ƒè™‘在内。CPU算力由特定体系 +结构实现的arch_scale_cpu_capacity()回调函数æ供。 + +EAS使用的其余平å°ä¿¡æ¯æ˜¯ç›´æŽ¥ä»Žèƒ½é‡æ¨¡åž‹ï¼ˆEM）框架ä¸è¯»å–的。一个平å°çš„EMæ˜¯ä¸€å¼ +表，表ä¸æ¯é¡¹ä»£è¡¨ç³»ç»Ÿä¸ä¸€ä¸ªâ€œæ€§èƒ½åŸŸâ€çš„功率æˆæœ¬ã€‚（若è¦äº†è§£æ›´å¤šå…³äºŽæ€§èƒ½åŸŸçš„细节， +è§Documentation/power/energy-model.rst） + +当调度域被建立或é‡æ–°å»ºç«‹æ—¶ï¼Œè°ƒåº¦å™¨ç®¡ç†å¯¹æ‹“扑代ç ä¸EM对象的引用。对于æ¯ä¸ªæ ¹åŸŸ +（rd），调度器维护一个与当å‰rd->span相交的所有性能域的å•å‘链表。链表ä¸çš„æ¯ä¸ª +节点都包å«ä¸€ä¸ªæŒ‡å‘EM框架所æ供的结构体em_perf_domain的指针。 + +é“¾è¡¨è¢«é™„åŠ åœ¨æ ¹åŸŸä¸Šï¼Œä»¥åº”å¯¹ç‹¬å çš„cpusetçš„é…置。由于独å çš„cpuset的边界ä¸ä¸€å®šä¸Ž +性能域的边界一致，ä¸åŒæ ¹åŸŸçš„链表å¯èƒ½åŒ…å«é‡å¤çš„å…ƒç´ ã€‚ + +示例1 + 让我们考虑一个有12个CPUçš„å¹³å°ï¼Œåˆ†æˆ3个性能域，（pd0，pd4å’Œpd8），按以下 + æ–¹å¼ç»„织:: + + CPUs: 0 1 2 3 4 5 6 7 8 9 10 11 + PDs: |--pd0--|--pd4--|---pd8---| + RDs: |----rd1----|-----rd2-----| + + 现在，考虑用户空间决定将系统分æˆä¸¤ä¸ªç‹¬å çš„cpusetsï¼Œå› æ¤åˆ›å»ºäº†ä¸¤ä¸ªç‹¬ç«‹çš„æ ¹åŸŸï¼Œ + æ¯ä¸ªæ ¹åŸŸåŒ…å«6个CPUã€‚è¿™ä¸¤ä¸ªæ ¹åŸŸåœ¨ä¸Šå›¾ä¸è¢«è¡¨ç¤ºä¸ºrd1å’Œrd2。由于pd4与rd1å’Œrd2 + 都有交集，它将åŒæ—¶å‡ºçŽ°äºŽé™„åŠ åœ¨è¿™ä¸¤ä¸ªæ ¹åŸŸçš„â€œ->pdâ€é“¾è¡¨ä¸: + + * rd1->pd: pd0 -> pd4 + * rd2->pd: pd4 -> pd8 + + 请注æ„，调度器将为pd4创建两个é‡å¤çš„链表节点（æ¯ä¸ªé“¾è¡¨ä¸å„一个）。然而这 + 两个节点æŒæœ‰æŒ‡å‘åŒä¸€ä¸ªEM框架的共享数æ®ç»“构的指针。 + +由于对这些链表的访问å¯èƒ½ä¸Žçƒæ’æ‹”åŠå…¶å®ƒäº‹ä»¶å¹¶å‘å‘ç”Ÿï¼Œå› æ¤å®ƒä»¬å—RCUé”ä¿æŠ¤ï¼Œå°±åƒ +被调度器æ“控的拓扑结构体ä¸å‰©ä¸‹å—æ®µä¸€æ ·ã€‚ + +EASåŒæ ·ç»´æŠ¤äº†ä¸€ä¸ªé™æ€é”®ï¼ˆsched_energy_presentï¼‰ï¼Œå½“è‡³å°‘æœ‰ä¸€ä¸ªæ ¹åŸŸæ»¡è¶³EAS +å¯åŠ¨çš„所有æ¡ä»¶æ—¶ï¼Œè¿™ä¸ªé”®å°±ä¼šè¢«å¯åŠ¨ã€‚在第6节ä¸æ€»ç»“了这些æ¡ä»¶ã€‚ + + +4. 能é‡æ„ŸçŸ¥ä»»åŠ¡æ”¾ç½® +------------------- + +EAS覆盖了CFS的任务唤醒平衡代ç 。在唤醒平衡时，它使用平å°çš„EMå’ŒPELTä¿¡å·æ¥é€‰æ‹©èŠ‚能 +çš„ç›®æ ‡CPU。当EAS被å¯ç”¨æ—¶ï¼Œselect_task_rq_fair()调用find_energy_efficient_cpu() +æ¥åšä»»åŠ¡æ”¾ç½®å†³å®šã€‚这个函数寻找在æ¯ä¸ªæ€§èƒ½åŸŸä¸å¯»æ‰¾å…·æœ‰æœ€é«˜å‰©ä½™ç®—力（CPU算力 - CPU +利用率）的CPUï¼Œå› ä¸ºå®ƒèƒ½è®©æˆ‘ä»¬ä¿æŒæœ€ä½Žçš„频率。然åŽï¼Œè¯¥å‡½æ•°æ£€æŸ¥å°†ä»»åŠ¡æ”¾åœ¨æ–°CPU相较 +ä¾ç„¶æ”¾åœ¨ä¹‹å‰æ´»åŠ¨çš„prev_cpu是å¦å¯ä»¥èŠ‚çœèƒ½é‡ã€‚ + +如果唤醒的任务被è¿ç§»ï¼Œfind_energy_efficient_cpu()使用compute_energy()æ¥ä¼°ç®— +系统将消耗多少能é‡ã€‚compute_energy()检查å„CPU当å‰çš„利用率情况，并å°è¯•è°ƒæ•´æ¥ +“模拟â€ä»»åŠ¡è¿ç§»ã€‚EM框架æ供了API em_pd_energy()计算æ¯ä¸ªæ€§èƒ½åŸŸåœ¨ç»™å®šçš„利用率æ¡ä»¶ +下的预期能é‡æ¶ˆè€—。 + +下é¢è¯¦ç»†ä»‹ç»ä¸€ä¸ªä¼˜åŒ–能é‡æ¶ˆè€—的任务放置决ç–的例å。 + +示例2 + 让我们考虑一个有两个独立性能域的（伪）平å°ï¼Œæ¯ä¸ªæ€§èƒ½åŸŸå«æœ‰2个CPU。CPU0å’ŒCPU1 + 是å°æ ¸ï¼ŒCPU2å’ŒCPU3æ˜¯å¤§æ ¸ã€‚ + + 调度器必须决定将任务P放在哪个CPU上，这个任务的util_avg = 200（平å‡åˆ©ç”¨çŽ‡ï¼‰ï¼Œ + prev_cpu = 0（上一次è¿è¡Œåœ¨CPU0）。 + + ç›®å‰CPU的利用率情况如下图所示。CPU 0-3çš„util_avg分别为400ã€100ã€600å’Œ500。 + æ¯ä¸ªæ€§èƒ½åŸŸæœ‰ä¸‰ä¸ªæ“作性能值（OPP）。与æ¯ä¸ªOPP相关的CPU算力和功率æˆæœ¬åˆ—åœ¨èƒ½é‡ + 模型表ä¸ã€‚Pçš„util_avg在图ä¸æ˜¾ç¤ºä¸º"PP":: + + CPU util. + 1024 - - - - - - - Energy Model + +-----------+-------------+ + | Little | Big | + 768 ============= +-----+-----+------+------+ + | Cap | Pwr | Cap | Pwr | + +-----+-----+------+------+ + 512 =========== - ##- - - - - | 170 | 50 | 512 | 400 | + ## ## | 341 | 150 | 768 | 800 | + 341 -PP - - - - ## ## | 512 | 300 | 1024 | 1700 | + PP ## ## +-----+-----+------+------+ + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + Current OPP: ===== Other OPP: - - - util_avg (100 each): ## + + + find_energy_efficient_cpu()将首先在两个性能域ä¸å¯»æ‰¾å…·æœ‰æœ€å¤§å‰©ä½™ç®—力的CPU。 + 在这个例åä¸æ˜¯CPU1å’ŒCPU3。然åŽï¼Œå®ƒå°†ä¼°ç®—，当P被放在它们ä¸çš„ä»»æ„一个时，系统的 + èƒ½è€—ï¼Œå¹¶æ£€æŸ¥è¿™æ ·åšæ˜¯å¦ä¼šæ¯”把P放在CPU0上节çœä¸€äº›èƒ½é‡ã€‚EASå‡å®šOPPséµå¾ªåˆ©ç”¨çŽ‡ + （这与CPUFreq监管器schedutil的行为一致。关于这个问题的更多细节，è§ç¬¬6节）。 + + **情况1. P被è¿ç§»åˆ°CPU1**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 200 / 341 * 150 = 88 + * CPU1: 300 / 341 * 150 = 131 + * CPU2: 600 / 768 * 800 = 625 + 512 - - - - - - - ##- - - - - * CPU3: 500 / 768 * 800 = 520 + ## ## => total_energy = 1364 + 341 =========== ## ## + PP ## ## + 170 -## - - PP- ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + + **情况2. P被è¿ç§»åˆ°CPU3**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 200 / 341 * 150 = 88 + * CPU1: 100 / 341 * 150 = 43 + PP * CPU2: 600 / 768 * 800 = 625 + 512 - - - - - - - ##- - -PP - * CPU3: 700 / 768 * 800 = 729 + ## ## => total_energy = 1485 + 341 =========== ## ## + ## ## + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + **情况3. Pä¾æ—§ç•™åœ¨prev_cpu/CPU0**:: + + 1024 - - - - - - - + + Energy calculation: + 768 ============= * CPU0: 400 / 512 * 300 = 234 + * CPU1: 100 / 512 * 300 = 58 + * CPU2: 600 / 768 * 800 = 625 + 512 =========== - ##- - - - - * CPU3: 500 / 768 * 800 = 520 + ## ## => total_energy = 1437 + 341 -PP - - - - ## ## + PP ## ## + 170 -## - - - - ## ## + ## ## ## ## + ------------ ------------- + CPU0 CPU1 CPU2 CPU3 + + 从这些计算结果æ¥çœ‹ï¼Œæƒ…况1的总能é‡æœ€ä½Žã€‚所以从节约能é‡çš„角度看，CPU1是最佳候选 + 者。 + +å¤§æ ¸é€šå¸¸æ¯”å°æ ¸æ›´è€—ç”µï¼Œå› æ¤ä¸»è¦åœ¨ä»»åŠ¡ä¸é€‚åˆåœ¨å°æ ¸è¿è¡Œæ—¶ä½¿ç”¨ã€‚然而，å°æ ¸å¹¶ä¸æ€»æ˜¯æ¯” +å¤§æ ¸èŠ‚èƒ½ã€‚ä¸¾ä¾‹æ¥è¯´ï¼Œå¯¹äºŽæŸäº›ç³»ç»Ÿï¼Œå°æ ¸çš„高OPPå¯èƒ½æ¯”å¤§æ ¸çš„ä½ŽOPP能é‡æ¶ˆè€—æ›´é«˜ã€‚å› æ¤ï¼Œ +如果å°æ ¸åœ¨æŸä¸€ç‰¹å®šæ—¶é—´ç‚¹åˆšå¥½æœ‰è¶³å¤Ÿçš„利用率，在æ¤åˆ»è¢«å”¤é†’çš„å°ä»»åŠ¡æ”¾åœ¨å¤§æ ¸æ‰§è¡Œå¯èƒ½ +会更节能，尽管它在å°æ ¸ä¸Šè¿è¡Œä¹Ÿæ˜¯åˆé€‚的。 + +å³ä½¿åœ¨å¤§æ ¸æ‰€æœ‰OPP都ä¸å¦‚å°æ ¸OPP节能的情况下，在æŸäº›ç‰¹å®šæ¡ä»¶ä¸‹ï¼Œä»¤å°ä»»åŠ¡è¿è¡Œåœ¨å¤§æ ¸ +上ä¾ç„¶å¯èƒ½èŠ‚能。事实上，将一个任务放在一个å°æ ¸ä¸Šå¯èƒ½å¯¼è‡´æ•´ä¸ªæ€§èƒ½åŸŸçš„OPPæ高，这将 +å¢žåŠ å·²ç»åœ¨è¯¥æ€§èƒ½åŸŸè¿è¡Œçš„任务的能é‡æˆæœ¬ã€‚å¦‚æžœå”¤é†’çš„ä»»åŠ¡è¢«æ”¾åœ¨ä¸€ä¸ªå¤§æ ¸ä¸Šï¼Œå®ƒçš„æ‰§è¡Œ +æˆæœ¬å¯èƒ½æ¯”放在å°æ ¸ä¸Šæ›´é«˜ï¼Œä½†è¿™ä¸ä¼šå½±å“å°æ ¸ä¸Šçš„其它任务，这些任务将继ç»ä»¥è¾ƒä½Žçš„OPP +è¿è¡Œã€‚å› æ¤ï¼Œå½“考虑CPU消耗的总能é‡æ—¶ï¼Œåœ¨å¤§æ ¸ä¸Šè¿è¡Œä¸€ä¸ªä»»åŠ¡çš„é¢å¤–æˆæœ¬å¯èƒ½å°äºŽä¸ºæ‰€æœ‰ +其它è¿è¡Œåœ¨å°æ ¸çš„任务æ高OPPçš„æˆæœ¬ã€‚ + +上é¢çš„例åå‡ ä¹Žä¸å¯èƒ½ä»¥ä¸€ç§é€šç”¨çš„æ–¹å¼å¾—到æ£ç¡®çš„结果；åŒæ—¶ï¼Œå¯¹äºŽæ‰€æœ‰å¹³å°ï¼Œåœ¨ä¸çŸ¥é“ +系统所有CPUæ¯ä¸ªä¸åŒOPPçš„è¿è¡Œæˆæœ¬æ—¶ï¼Œä¹Ÿæ— 法得到æ£ç¡®çš„结果。得益于基于EM的设计， +EAS应该能够æ£ç¡®å¤„ç†è¿™äº›é—®é¢˜è€Œä¸ä¼šå¼•å‘太多麻烦。然而，为了确ä¿å¯¹é«˜åˆ©ç”¨çŽ‡åœºæ™¯çš„ +åžåçŽ‡é€ æˆçš„å½±å“最å°åŒ–，EASåŒæ ·å®žçŽ°äº†å¦å¤–一ç§å«â€œè¿‡åº¦åˆ©ç”¨çŽ‡â€çš„机制。 + + +5. 过度利用率 +------------- + +从一般的角度æ¥çœ‹ï¼ŒEAS能æ供最大帮助的是那些涉åŠä½Žã€ä¸CPU利用率的使用场景。æ¯å½“CPU +密集型的长任务è¿è¡Œï¼Œå®ƒä»¬å°†éœ€è¦æ‰€æœ‰çš„å¯ç”¨CPU算力，调度器将没有什么办法æ¥èŠ‚çœèƒ½é‡åŒæ—¶ +åˆä¸æŸå®³åžå率。为了é¿å…EASæŸå®³æ€§èƒ½ï¼Œä¸€æ—¦CPU被使用的算力超过80%ï¼Œå®ƒå°†è¢«æ ‡è®°ä¸ºâ€œè¿‡åº¦ +利用â€ã€‚åªè¦æ ¹åŸŸä¸æ²¡æœ‰CPU是过度利用状æ€ï¼Œè´Ÿè½½å‡è¡¡è¢«ç¦ç”¨ï¼Œè€ŒEAS将覆盖唤醒平衡代ç 。 +EAS很å¯èƒ½å°†è´Ÿè½½æ”¾ç½®åœ¨ç³»ç»Ÿä¸èƒ½é‡æ•ˆçŽ‡æœ€é«˜çš„CPU而ä¸æ˜¯å…¶å®ƒCPU上，åªè¦ä¸æŸå®³åžå率。 +å› æ¤ï¼Œè´Ÿè½½å‡è¡¡å™¨è¢«ç¦ç”¨ä»¥é˜²æ¢å®ƒæ‰“ç ´EASå‘现的节能任务放置。当系统未处于过度利用状æ€æ—¶ï¼Œ +è¿™æ ·åšæ˜¯å®‰å…¨çš„ï¼Œå› ä¸ºä½ŽäºŽ80%的临界点æ„味ç€ï¼š + + a. 所有的CPU都有一些空闲时间，所以EAS使用的利用率信å·å¾ˆå¯èƒ½å‡†ç¡®åœ°ä»£è¡¨å„ç§ä»»åŠ¡ + 的“大å°â€ã€‚ + b. 所有任务，ä¸ç®¡å®ƒä»¬çš„nice值是多大，都应该被æ供了足够多的CPU算力。 + c. 既然有多余的算力，那么所有的任务都必须定期阻塞/ä¼‘çœ ï¼Œåœ¨å”¤é†’æ—¶è¿›è¡Œå¹³è¡¡å°±è¶³å¤Ÿ + 了。 + +åªè¦ä¸€ä¸ªCPU利用率超过80%的临界点，上述三个å‡è®¾ä¸è‡³å°‘有一个是ä¸æ£ç¡®çš„。在这ç§æƒ…况下， +æ•´ä¸ªæ ¹åŸŸçš„â€œè¿‡åº¦åˆ©ç”¨â€æ ‡å¿—被设置，EAS被ç¦ç”¨ï¼Œè´Ÿè½½å‡è¡¡å™¨è¢«é‡æ–°å¯ç”¨ã€‚é€šè¿‡è¿™æ ·åšï¼Œè°ƒåº¦å™¨ +åˆå›žåˆ°äº†åœ¨CPU密集的æ¡ä»¶ä¸‹åŸºäºŽè´Ÿè½½çš„算法åšè´Ÿè½½å‡è¡¡ã€‚这更好地尊é‡äº†ä»»åŠ¡çš„nice值。 + +由于过度利用率的概念在很大程度上ä¾èµ–于检测系统ä¸æ˜¯å¦æœ‰ä¸€äº›ç©ºé—²æ—¶é—´ï¼Œæ‰€ä»¥å¿…须考虑 +（比CFS）更高优先级的调度类（以åŠä¸æ–）“窃å–â€çš„CPU算力。åƒè¿™æ ·ï¼Œå¯¹è¿‡åº¦ä½¿ç”¨çŽ‡çš„检测 +ä¸ä»…è¦è€ƒè™‘CFS任务使用的算力，还需è¦è€ƒè™‘其它调度类和ä¸æ–。 + + +6. EASçš„ä¾èµ–å’Œè¦æ±‚ +------------------ + +能é‡æ„ŸçŸ¥è°ƒåº¦ä¾èµ–系统的CPU具有特定的硬件属性，以åŠå†…æ ¸ä¸çš„其它特性被å¯ç”¨ã€‚本节列出 +了这些ä¾èµ–，并对如何满足这些ä¾èµ–æ供了æ示。 + + +6.1 - éžå¯¹ç§°CPU拓扑 +^^^^^^^^^^^^^^^^^^^ + + +如简介所æ，目å‰åªæœ‰éžå¯¹ç§°CPU拓扑结构的平å°æ”¯æŒEAS。通过在è¿è¡Œæ—¶æŸ¥è¯¢ +SD_ASYM_CPUCAPACITY_FULLæ ‡å¿—ä½æ˜¯å¦åœ¨åˆ›å»ºè°ƒåº¦åŸŸæ—¶å·²è®¾ç½®æ¥æ£€æŸ¥è¿™ä¸€è¦æ±‚是å¦æ»¡è¶³ã€‚ + +å‚阅Documentation/scheduler/sched-capacity.rst以了解在sched_domain层次结构 +ä¸è®¾ç½®æ¤æ ‡å¿—ä½æ‰€éœ€æ»¡è¶³çš„è¦æ±‚。 + +请注æ„，EAS并éžä»Žæ ¹æœ¬ä¸Šä¸ŽSMPä¸å…¼å®¹ï¼Œä½†åœ¨SMPå¹³å°ä¸Šè¿˜æ²¡æœ‰è§‚察到明显的节能。这一 +é™åˆ¶å¯ä»¥åœ¨å°†æ¥è¿›è¡Œä¿®æ”¹ï¼Œå¦‚果被è¯æ˜Žä¸æ˜¯è¿™æ ·çš„è¯ã€‚ + + +6.2 - 当å‰çš„能é‡æ¨¡åž‹ +^^^^^^^^^^^^^^^^^^^^ + +EAS使用一个平å°çš„EMæ¥ä¼°ç®—调度决ç–对能é‡çš„å½±å“ã€‚å› æ¤ï¼Œä½ çš„å¹³å°å¿…é¡»å‘EM框架æä¾› +能é‡æˆæœ¬è¡¨ï¼Œä»¥å¯åŠ¨EAS。è¦åšåˆ°è¿™ä¸€ç‚¹ï¼Œè¯·å‚阅文档 +Documentation/power/energy-model.rstä¸çš„独立EM框架部分。 + +å¦è¯·æ³¨æ„，调度域需è¦åœ¨EM注册åŽé‡å»ºï¼Œä»¥ä¾¿å¯åŠ¨EAS。 + +EAS使用EM对能é‡ä½¿ç”¨çŽ‡è¿›è¡Œé¢„测决ç–ï¼Œå› æ¤å®ƒåœ¨æ£€æŸ¥ä»»åŠ¡æ”¾ç½®çš„å¯èƒ½é€‰é¡¹æ—¶æ›´åŠ æ³¨é‡ +差异。对于EASæ¥è¯´ï¼ŒEM的功率值是以毫瓦还是以“抽象刻度â€ä¸ºå•ä½è¡¨ç¤ºå¹¶ä¸é‡è¦ã€‚ + + + +6.3 - 能é‡æ¨¡åž‹å¤æ‚度 +^^^^^^^^^^^^^^^^^^^^ + +任务唤醒路径是时延æ•æ„Ÿçš„。当一个平å°çš„EM太å¤æ‚（太多CPUï¼Œå¤ªå¤šæ€§èƒ½åŸŸï¼Œå¤ªå¤šçŠ¶æ€ +ç‰ï¼‰ï¼Œåœ¨å”¤é†’路径ä¸ä½¿ç”¨å®ƒçš„æˆæœ¬å°±ä¼šå‡é«˜åˆ°ä¸å¯æŽ¥å—。能é‡æ„ŸçŸ¥å”¤é†’算法的å¤æ‚度为： + + C = Nd * (Nc + Ns) + +å…¶ä¸ï¼šNd是性能域的数é‡ï¼›Nc是CPUçš„æ•°é‡ï¼›Ns是OPP的总数（例如：对于两个性能域， +æ¯ä¸ªåŸŸæœ‰4个OPP，则Ns = 8）。 + +当调度域建立时，å¤æ‚æ€§æ£€æŸ¥æ˜¯åœ¨æ ¹åŸŸä¸Šè¿›è¡Œçš„ã€‚å¦‚æžœä¸€ä¸ªæ ¹åŸŸçš„å¤æ‚度Cæ°å¥½é«˜äºŽå®Œå…¨ +主观设定的EM_MAX_COMPLEXITY阈值（在本文写作时，是2048），则EASä¸ä¼šåœ¨æ¤æ ¹åŸŸ +å¯åŠ¨ã€‚ + +å¦‚æžœä½ çš„å¹³å°çš„能é‡æ¨¡åž‹çš„å¤æ‚度太高，EASæ— æ³•åœ¨è¿™ä¸ªæ ¹åŸŸä¸Šä½¿ç”¨ï¼Œä½†ä½ çœŸçš„æƒ³ç”¨ï¼Œ +é‚£ä¹ˆä½ å°±åªå‰©ä¸‹ä¸¤ä¸ªå¯èƒ½çš„选择： + + 1. å°†ä½ çš„ç³»ç»Ÿæ‹†åˆ†æˆåˆ†ç¦»çš„ã€è¾ƒå°çš„ã€ä½¿ç”¨ç‹¬å cpusetçš„æ ¹åŸŸï¼Œå¹¶åœ¨æ¯ä¸ªæ ¹åŸŸå±€éƒ¨ + å¯ç”¨EAS。这个方案的好处是开箱å³ç”¨ï¼Œä½†ç¼ºç‚¹æ˜¯æ— æ³•åœ¨æ ¹åŸŸä¹‹é—´å®žçŽ°è´Ÿè½½å‡è¡¡ï¼Œ + è¿™å¯èƒ½ä¼šå¯¼è‡´æ€»ä½“系统负载ä¸å‡è¡¡ã€‚ + 2. æ交补ä¸ä»¥é™ä½ŽEAS唤醒算法的å¤æ‚度，从而使其能够在åˆç†çš„时间内处ç†æ›´å¤§ + çš„EM。 + + +6.4 - Schedutil监管器 +^^^^^^^^^^^^^^^^^^^^^ + +EAS试图预测CPU在ä¸ä¹…çš„å°†æ¥ä¼šåœ¨å“ªä¸ªOPP下è¿è¡Œï¼Œä»¥ä¼°ç®—它们的能é‡æ¶ˆè€—。为了åšåˆ° +这一点，它å‡å®šCPUçš„OPPè·ŸéšCPU利用率å˜åŒ–而å˜åŒ–。 + +尽管在实践ä¸å¾ˆéš¾å¯¹è¿™ä¸€å‡è®¾çš„准确性æ供硬性ä¿è¯ï¼ˆå› 为，举例æ¥è¯´ç¡¬ä»¶å¯èƒ½ä¸ä¼šåš +它被è¦æ±‚åšçš„事情），相对于其他CPUFreq监管器，schedutil至少_请求_使用利用率 +ä¿¡å·è®¡ç®—çš„é¢‘çŽ‡ã€‚å› æ¤ï¼Œä¸ŽEAS一起使用的唯一åˆç†çš„监管器是schedutilï¼Œå› ä¸ºå®ƒæ˜¯ +唯一一个在频率请求和能é‡é¢„测之间æä¾›æŸç§ç¨‹åº¦çš„一致性的监管器。 + +ä¸æ”¯æŒå°†EAS与schedutil之外的任何其它监管器一起使用。 + + +6.5 刻度ä¸å˜æ€§ä½¿ç”¨çŽ‡ä¿¡å· +^^^^^^^^^^^^^^^^^^^^^^^^ + +为了对ä¸åŒçš„CPU和所有的性能状æ€åšå‡ºå‡†ç¡®çš„预测，EAS需è¦é¢‘率ä¸å˜çš„å’ŒCPUä¸å˜çš„ +PELTä¿¡å·ã€‚这些信å·å¯ä»¥é€šè¿‡æ¯ä¸ªä½“系结构定义的arch_scale{cpu,freq}_capacity() +回调函数获å–。 + +ä¸æ”¯æŒåœ¨æ²¡æœ‰å®žçŽ°è¿™ä¸¤ä¸ªå›žè°ƒå‡½æ•°çš„å¹³å°ä¸Šä½¿ç”¨EAS。 + + +6.6 多线程（SMT） +^^^^^^^^^^^^^^^^^ + +当å‰å®žçŽ°çš„EAS是ä¸æ„ŸçŸ¥SMTçš„ï¼Œå› æ¤æ— 法利用多线程硬件节约能é‡ã€‚EAS认为线程是独立的 +CPU，这实际上对性能和能é‡æ¶ˆè€—都是ä¸åˆ©çš„。 + +ä¸æ”¯æŒåœ¨SMT上使用EAS。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst b/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst new file mode 100644 index 000000000000..9107f0c0b979 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-nice-design.rst @@ -0,0 +1,99 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-nice-design.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +===================== +调度器nice值设计 +===================== + +本文档解释了新的Linux调度器ä¸ä¿®æ”¹å’Œç²¾ç®€åŽçš„nice级别的实现æ€è·¯ã€‚ + +Linuxçš„nice级别总是éžå¸¸è„†å¼±ï¼Œäººä»¬æŒç»ä¸æ–åœ°ç¼ ç€æˆ‘们，让nice +19的任务å 用 +æ›´å°‘çš„CPU时间。 + +ä¸å¹¸çš„是，在旧的调度器ä¸ï¼Œè¿™ä¸æ˜¯é‚£ä¹ˆå®¹æ˜“实现的（å¦åˆ™æˆ‘们早就åšåˆ°äº†ï¼‰ï¼Œå› 为对 +nice级别的支æŒåœ¨åŽ†å²ä¸Šæ˜¯ä¸Žæ—¶é—´ç‰‡é•¿åº¦è€¦åˆçš„，而时间片å•ä½æ˜¯ç”±HZæ»´ç”驱动的， +所以最å°çš„时间片是1/HZ。 + +在O(1)调度器ä¸ï¼ˆ2003年），我们改å˜äº†è´Ÿçš„nice级别，使它们比2.4å†…æ ¸æ›´å¼º +（人们对这一å˜åŒ–很满æ„），而且我们还故æ„æ ¡æ£äº†çº¿æ€§æ—¶é—´ç‰‡å‡†åˆ™ï¼Œä½¿å¾—nice +19 +的级别 _æ£å¥½_ 是1 jiffy。为了让大家更好地ç†è§£å®ƒï¼Œæ—¶é—´ç‰‡çš„å›¾ä¼šæ˜¯è¿™æ ·çš„ï¼ˆè´¨é‡ +ä¸ä½³çš„ASCII艺术æ醒ï¼ï¼‰:: + + + A + \ | [timeslice length] + \ | + \ | + \ | + \ | + \|___100msecs + |^ . _ + | ^ . _ + | ^ . _ + -*----------------------------------*-----> [nice level] + -20 | +19 + | + | + +å› æ¤ï¼Œå¦‚果有人真的想renice任务，相较线性规则，+19ä¼šç»™å‡ºæ›´å¤§çš„æ•ˆæžœï¼ˆæ”¹å˜ +ABIæ¥æ‰©å±•ä¼˜å…ˆçº§çš„解决方案在早期就被放弃了）。 + +è¿™ç§æ–¹æ³•åœ¨ä¸€å®šç¨‹åº¦ä¸Šå¥æ•ˆäº†ä¸€æ®µæ—¶é—´ï¼Œä½†åŽæ¥HZ=1000时，它导致1 jiffy为 +1ms，这æ„味ç€0.1%çš„CPU使用率，我们认为这有点过度。过度 _ä¸æ˜¯_ å› ä¸ºå®ƒè¡¨ç¤º +çš„CPU使用率过å°ï¼Œè€Œæ˜¯å› 为它引å‘了过于频ç¹ï¼ˆæ¯æ¯«ç§’1次）的é‡æ–°è°ƒåº¦ï¼ˆå› æ¤ä¼š +ç ´å缓å˜ï¼Œç‰ç‰ã€‚请记ä½ï¼Œç¡¬ä»¶æ›´å¼±ã€cacheæ›´å°æ˜¯å¾ˆä¹…以å‰çš„事了，当时人们在 +nice +19级别è¿è¡Œæ•°é‡é¢‡å¤šçš„应用程åºï¼‰ã€‚ + +å› æ¤ï¼Œå¯¹äºŽHZ=1000，我们将nice +19改为5æ¯«ç§’ï¼Œå› ä¸ºè¿™æ„Ÿè§‰åƒæ˜¯æ£ç¡®çš„æœ€å° +粒度——这相当于5%çš„CPU利用率。但nice +19çš„æ ¹æœ¬çš„HZæ•æ„Ÿå±žæ€§ä¾ç„¶ä¿æŒä¸å˜ï¼Œ +我们没有收到过关于nice +19在CPU利用率方é¢å¤ª _å¼±_ 的任何抱怨，我们åªæ”¶åˆ° +过它（ä¾ç„¶ï¼‰å¤ª _强_ 的抱怨 :-)。 + +总结一下：我们一直想让niceå„级别一致性更强，但在HZå’Œjiffiesçš„é™åˆ¶ä¸‹ï¼Œä»¥åŠ +nice级别与时间片ã€è°ƒåº¦ç²’度耦åˆæ˜¯ä»¤äººè®¨åŽŒçš„è®¾è®¡ï¼Œè¿™ä¸€ç›®æ ‡å¹¶ä¸çœŸæ£å¯è¡Œã€‚ + +第二个关于Linux nice级别支æŒçš„抱怨是（ä¸é‚£ä¹ˆé¢‘ç¹ï¼Œä½†ä»ç„¶å®šæœŸå‘生），它 +在原点周围的ä¸å¯¹ç§°æ€§ï¼ˆä½ å¯ä»¥åœ¨ä¸Šé¢çš„图片ä¸çœ‹åˆ°ï¼‰ï¼Œæˆ–者更准确地说：事实上 +nice级别的行为å–决于 _ç»å¯¹çš„_ nice级别，而nice应用程åºæŽ¥å£æœ¬èº«ä»Žæ ¹æœ¬ä¸Š +说是“相对â€çš„： + + int nice(int inc); + + asmlinkage long sys_nice(int increment) + +（第一个是glibc的应用程åºæŽ¥å£ï¼Œç¬¬äºŒä¸ªæ˜¯syscall的应用程åºæŽ¥å£ï¼‰ +注æ„，“incâ€æ˜¯ç›¸å¯¹å½“å‰nice级别而言的，类似bash的“niceâ€å‘½ä»¤ç‰å·¥å…·æ˜¯è¿™ä¸ª +相对性应用程åºæŽ¥å£çš„é•œåƒã€‚ + +在旧的调度器ä¸ï¼Œä¸¾ä¾‹æ¥è¯´ï¼Œå¦‚æžœä½ ä»¥nice +1å¯åŠ¨ä¸€ä¸ªä»»åŠ¡ï¼Œå¹¶ä»¥nice +2å¯åŠ¨ +å¦ä¸€ä¸ªä»»åŠ¡ï¼Œè¿™ä¸¤ä¸ªä»»åŠ¡çš„CPU分é…å°†å–决于父外壳程åºçš„nice级别——如果它是 +nice -10，那么CPU的分é…ä¸åŒäºŽ+5或+10。 + +第三个关于Linux nice级别支æŒçš„抱怨是，负数nice级别“ä¸å¤Ÿæœ‰åŠ›â€ï¼Œä»¥å¾ˆå¤šäºº +ä¸å¾—ä¸è¯‰è¯¸äºŽå®žæ—¶è°ƒåº¦ä¼˜å…ˆçº§æ¥è¿è¡ŒéŸ³é¢‘（和其它多媒体）应用程åºï¼Œæ¯”如 +SCHED_FIFOã€‚ä½†è¿™ä¹Ÿé€ æˆäº†å…¶å®ƒé—®é¢˜ï¼šSCHED_FIFO未被è¯æ˜Žæ˜¯å…于饥饿的，一个 +有问题的SCHED_FIFO应用程åºä¹Ÿä¼šé”ä½è¿è¡Œè‰¯å¥½çš„系统。 + +v2.6.23ç‰ˆå†…æ ¸çš„æ–°è°ƒåº¦å™¨è§£å†³äº†è¿™ä¸‰ç§ç±»åž‹çš„抱怨： + +为了解决第一个抱怨（nice级别ä¸å¤Ÿâ€œæœ‰åŠ›â€ï¼‰ï¼Œè°ƒåº¦å™¨ä¸Žâ€œæ—¶é—´ç‰‡â€ã€HZ的概念 +解耦（调度粒度被处ç†æˆä¸€ä¸ªå’Œniceçº§åˆ«ç‹¬ç«‹çš„æ¦‚å¿µï¼‰ï¼Œå› æ¤æœ‰å¯èƒ½å®žçŽ°æ›´å¥½ã€ +更一致的nice +19支æŒï¼šåœ¨æ–°çš„调度器ä¸ï¼Œnice +19的任务得到一个HZæ— å…³çš„ +1.5%CPU使用率，而ä¸æ˜¯æ—§ç‰ˆè°ƒåº¦å™¨ä¸3%-5%-9%çš„å¯å˜èŒƒå›´ã€‚ + +为了解决第二个抱怨（niceå„级别ä¸ä¸€è‡´ï¼‰ï¼Œæ–°è°ƒåº¦å™¨ä»¤è°ƒç”¨nice(1)对å„任务的 +CPU利用率有相åŒçš„å½±å“ï¼Œæ— è®ºå…¶ç»å¯¹nice级别如何。所以在新调度器上，è¿è¡Œä¸€ä¸ª +nice +10和一个nice +11的任务会与è¿è¡Œä¸€ä¸ªnice -5和一个nice -4的任务的 +CPU利用率分割是相åŒçš„（一个会得到55%çš„CPU，å¦ä¸€ä¸ªä¼šå¾—到45%）。这是为什么 +nice级别被改为“乘法â€ï¼ˆæˆ–æŒ‡æ•°ï¼‰â€”â€”è¿™æ ·çš„è¯ï¼Œä¸ç®¡ä½ 从哪个级别开始，“相对†+ç»“æžœå°†æ€»æ˜¯ä¸€æ ·çš„ã€‚ + +第三个抱怨（负数nice级别ä¸å¤Ÿâ€œæœ‰åŠ›â€ï¼Œå¹¶è¿«ä½¿éŸ³é¢‘应用程åºåœ¨æ›´å±é™©çš„ +SCHED_FIFO调度ç–略下è¿è¡Œï¼‰å‡ 乎被新的调度器自动解决了：更强的负数级别 +具有é‡æ–°æ ¡æ£nice级别动æ€èŒƒå›´çš„自动化副作用。 diff --git a/Documentation/translations/zh_CN/scheduler/sched-stats.rst b/Documentation/translations/zh_CN/scheduler/sched-stats.rst new file mode 100644 index 000000000000..1c68c3d1c283 --- /dev/null +++ b/Documentation/translations/zh_CN/scheduler/sched-stats.rst @@ -0,0 +1,156 @@ +.. SPDX-License-Identifier: GPL-2.0 +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/scheduler/sched-stats.rst + +:翻译: + + å”艺舟 Tang Yizhou <tangyeechou@gmail.com> + +============== +è°ƒåº¦å™¨ç»Ÿè®¡æ•°æ® +============== + +第15版schedstats去掉了sched_yield的一些计数器：yld_exp_empty，yld_act_empty +å’Œyld_both_empty。在其它方é¢å’Œç¬¬14版完全相åŒã€‚ + +第14版schedstats包括对sched_domains（译注：调度域）的支æŒï¼Œè¯¥ç‰¹æ€§è¿›å…¥å†…æ ¸ +主线2.6.20，ä¸è¿‡è¿™ä¸€ç‰ˆschedstats与2.6.13-2.6.19å†…æ ¸çš„ç‰ˆæœ¬12的统计数æ®æ˜¯å®Œå…¨ +相åŒçš„ï¼ˆå†…æ ¸æœªå‘布第13版）。有些计数器按æ¯ä¸ªè¿è¡Œé˜Ÿåˆ—统计是更有æ„义的，其它则 +按æ¯ä¸ªè°ƒåº¦åŸŸç»Ÿè®¡æ˜¯æ›´æœ‰æ„义的。注æ„，调度域（以åŠå®ƒä»¬çš„附属信æ¯ï¼‰ä»…åœ¨å¼€å¯ +CONFIG_SMP的机器上是相关的和å¯ç”¨çš„。 + +在第14版schedstatä¸ï¼Œæ¯ä¸ªè¢«åˆ—出的CPU至少会有一级域统计数æ®ï¼Œä¸”很å¯èƒ½æœ‰ä¸€ä¸ª +以上的域。在这个实现ä¸ï¼ŒåŸŸæ²¡æœ‰ç‰¹åˆ«çš„åå—，但是编å·æœ€é«˜çš„域通常在机器上所有的 +CPU上仲è£å¹³è¡¡ï¼Œè€Œdomain0是最紧密èšç„¦çš„域，有时仅在一对CPU之间进行平衡。æ¤æ—¶ï¼Œ +没有任何体系结构需è¦3层以上的域。域统计数æ®ä¸çš„第一个å—段是一个ä½å›¾ï¼Œè¡¨æ˜Žå“ªäº› +CPUå—该域的影å“。 + +这些å—段是计数器，而且åªèƒ½é€’增。使用这些å—段的程åºå°†éœ€è¦ä»ŽåŸºçº¿è§‚测开始，然åŽåœ¨ +åŽç»æ¯ä¸€ä¸ªè§‚测ä¸è®¡ç®—出计数器的å˜åŒ–。一个能以这ç§æ–¹å¼å¤„ç†å…¶ä¸å¾ˆå¤šå—段的perl脚本 +å¯è§ + + http://eaglet.pdxhosts.com/rick/linux/schedstat/ + +请注æ„ï¼Œä»»ä½•è¿™æ ·çš„è„šæœ¬éƒ½å¿…é¡»æ˜¯ç‰¹å®šäºŽç‰ˆæœ¬çš„ï¼Œæ”¹å˜ç‰ˆæœ¬çš„主è¦åŽŸå› æ˜¯è¾“å‡ºæ ¼å¼çš„å˜åŒ–。 +对于那些希望编写自己的脚本的人，å¯ä»¥å‚考这里æè¿°çš„å„个å—段。 + +CPUç»Ÿè®¡æ•°æ® +----------- +cpu<N> 1 2 3 4 5 6 7 8 9 + +第一个å—段是sched_yield()的统计数æ®ï¼š + + 1) sched_yield()被调用了#次 + +接下æ¥çš„三个是schedule()的统计数æ®ï¼š + + 2) 这个å—段是一个过时的数组过期计数，在O(1)调度器ä¸ä½¿ç”¨ã€‚为了ABI兼容性， + 我们ä¿ç•™äº†å®ƒï¼Œä½†å®ƒæ€»æ˜¯è¢«è®¾ç½®ä¸º0。 + 3) schedule()被调用了#次 + 4) 调用schedule()导致处ç†å™¨å˜ä¸ºç©ºé—²äº†#次 + +接下æ¥çš„两个是try_to_wake_up()的统计数æ®ï¼š + + 5) try_to_wake_up()被调用了#次 + 6) 调用try_to_wake_up()导致本地CPU被唤醒了#次 + +接下æ¥çš„三个统计数æ®æ述了调度延迟： + + 7) 本处ç†å™¨è¿è¡Œä»»åŠ¡çš„总时间，å•ä½æ˜¯jiffies + 8) 本处ç†å™¨ä»»åŠ¡ç‰å¾…è¿è¡Œçš„时间，å•ä½æ˜¯jiffies + 9) 本CPUè¿è¡Œäº†#个时间片 + +åŸŸç»Ÿè®¡æ•°æ® +---------- + +对于æ¯ä¸ªè¢«æè¿°çš„CPU，和它相关的æ¯ä¸€ä¸ªè°ƒåº¦åŸŸå‡ä¼šäº§ç”Ÿä¸‹é¢ä¸€è¡Œæ•°æ®ï¼ˆæ³¨æ„，如果 +CONFIG_SMP没有被定义，那么*没有*调度域被使用，这些行ä¸ä¼šå‡ºçŽ°åœ¨è¾“出ä¸ï¼‰ã€‚ + +domain<N> <cpumask> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 + +第一个å—段是一个ä½æŽ©ç ，表明该域在æ“作哪些CPU。 + +接下æ¥çš„24个å—段是load_balance()函数的å„个统计数æ®ï¼ŒæŒ‰ç©ºé—²ç±»åž‹åˆ†ç»„（空闲， +ç¹å¿™ï¼Œæ–°ç©ºé—²ï¼‰ï¼š + + + 1) 当CPU空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨äº†#次 + 2) 当CPU空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œä½†æ˜¯å‘çŽ°è´Ÿè½½æ— éœ€ + å‡è¡¡#次 + 3) 当CPU空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œè¯•å›¾è¿ç§»1个或更多 + 任务且失败了#次 + 4) 当CPU空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œå‘现ä¸å‡è¡¡ï¼ˆå¦‚果有） + #次 + 5) 当CPU空闲时，pull_task()在这个调度域ä¸è¢«è°ƒç”¨#次 + 6) 当CPUç©ºé—²æ—¶ï¼Œå°½ç®¡ç›®æ ‡ä»»åŠ¡æ˜¯çƒç¼“å˜çŠ¶æ€ï¼Œpull_task()ä¾ç„¶è¢«è°ƒç”¨#次 + 7) 当CPU空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œæœªèƒ½æ‰¾åˆ°æ›´ç¹å¿™çš„ + 队列#次 + 8) 当CPU空闲时，在调度域ä¸æ‰¾åˆ°äº†æ›´ç¹å¿™çš„队列，但未找到更ç¹å¿™çš„调度组 + #次 + 9) 当CPUç¹å¿™æ—¶ï¼Œload_balance()在这个调度域ä¸è¢«è°ƒç”¨äº†#次 + 10) 当CPUç¹å¿™æ—¶ï¼Œload_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œä½†æ˜¯å‘çŽ°è´Ÿè½½æ— éœ€ + å‡è¡¡#次 + 11) 当CPUç¹å¿™æ—¶ï¼Œload_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œè¯•å›¾è¿ç§»1个或更多 + 任务且失败了#次 + 12) 当CPUç¹å¿™æ—¶ï¼Œload_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œå‘现ä¸å‡è¡¡ï¼ˆå¦‚果有） + #次 + 13) 当CPUç¹å¿™æ—¶ï¼Œpull_task()在这个调度域ä¸è¢«è°ƒç”¨#次 + 14) 当CPUç¹å¿™æ—¶ï¼Œå°½ç®¡ç›®æ ‡ä»»åŠ¡æ˜¯çƒç¼“å˜çŠ¶æ€ï¼Œpull_task()ä¾ç„¶è¢«è°ƒç”¨#次 + 15) 当CPUç¹å¿™æ—¶ï¼Œload_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œæœªèƒ½æ‰¾åˆ°æ›´ç¹å¿™çš„ + 队列#次 + 16) 当CPUç¹å¿™æ—¶ï¼Œåœ¨è°ƒåº¦åŸŸä¸æ‰¾åˆ°äº†æ›´ç¹å¿™çš„队列，但未找到更ç¹å¿™çš„调度组 + #次 + 17) 当CPU新空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨äº†#次 + 18) 当CPU新空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œä½†æ˜¯å‘çŽ°è´Ÿè½½æ— éœ€ + å‡è¡¡#次 + 19) 当CPU新空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œè¯•å›¾è¿ç§»1个或更多 + 任务且失败了#次 + 20) 当CPU新空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œå‘现ä¸å‡è¡¡ï¼ˆå¦‚果有） + #次 + 21) 当CPU新空闲时，pull_task()在这个调度域ä¸è¢«è°ƒç”¨#次 + 22) 当CPUæ–°ç©ºé—²æ—¶ï¼Œå°½ç®¡ç›®æ ‡ä»»åŠ¡æ˜¯çƒç¼“å˜çŠ¶æ€ï¼Œpull_task()ä¾ç„¶è¢«è°ƒç”¨#次 + 23) 当CPU新空闲时，load_balance()在这个调度域ä¸è¢«è°ƒç”¨ï¼Œæœªèƒ½æ‰¾åˆ°æ›´ç¹å¿™çš„ + 队列#次 + 24) 当CPU新空闲时，在调度域ä¸æ‰¾åˆ°äº†æ›´ç¹å¿™çš„队列，但未找到更ç¹å¿™çš„调度组 + #次 + +接下æ¥çš„3个å—段是active_load_balance()函数的å„个统计数æ®ï¼š + + 25) active_load_balance()被调用了#次 + 26) active_load_balance()被调用，试图è¿ç§»1个或更多任务且失败了#次 + 27) active_load_balance()被调用，æˆåŠŸè¿ç§»äº†#次任务 + +接下æ¥çš„3个å—段是sched_balance_exec()函数的å„个统计数æ®ï¼š + + 28) sbe_cntä¸å†è¢«ä½¿ç”¨ + 29) sbe_balancedä¸å†è¢«ä½¿ç”¨ + 30) sbe_pushedä¸å†è¢«ä½¿ç”¨ + +接下æ¥çš„3个å—段是sched_balance_fork()函数的å„个统计数æ®ï¼š + + 31) sbf_cntä¸å†è¢«ä½¿ç”¨ + 32) sbf_balancedä¸å†è¢«ä½¿ç”¨ + 33) sbf_pushedä¸å†è¢«ä½¿ç”¨ + +接下æ¥çš„3个å—段是try_to_wake_up()函数的å„个统计数æ®ï¼š + + 34) 在这个调度域ä¸è°ƒç”¨try_to_wake_up()唤醒任务时，任务在调度域ä¸ä¸€ä¸ª + 和上次è¿è¡Œä¸åŒçš„æ–°CPU上è¿è¡Œäº†#次 + 35) 在这个调度域ä¸è°ƒç”¨try_to_wake_up()唤醒任务时，任务被è¿ç§»åˆ°å‘生唤醒 + çš„CPU次数为#ï¼Œå› ä¸ºè¯¥ä»»åŠ¡åœ¨åŽŸCPU是冷缓å˜çŠ¶æ€ + 36) 在这个调度域ä¸è°ƒç”¨try_to_wake_up()唤醒任务时，引å‘被动负载å‡è¡¡#次 + +/proc/<pid>/schedstat +--------------------- +schedstatsè¿˜æ·»åŠ äº†ä¸€ä¸ªæ–°çš„/proc/<pid>/schedstat文件，æ¥æ供一些进程级的 +相åŒä¿¡æ¯ã€‚这个文件ä¸ï¼Œæœ‰ä¸‰ä¸ªå—段与该进程相关： + + 1) 在CPU上è¿è¡ŒèŠ±è´¹çš„时间 + 2) 在è¿è¡Œé˜Ÿåˆ—上ç‰å¾…的时间 + 3) 在CPU上è¿è¡Œäº†#个时间片 + +å¯ä»¥å¾ˆå®¹æ˜“地编写一个程åºï¼Œåˆ©ç”¨è¿™äº›é¢å¤–çš„å—段æ¥æŠ¥å‘Šä¸€ä¸ªç‰¹å®šçš„进程或一组进程在 +调度器ç–ç•¥ä¸‹çš„è¡¨çŽ°å¦‚ä½•ã€‚è¿™æ ·çš„ç¨‹åºçš„一个简å•ç‰ˆæœ¬å¯åœ¨ä¸‹é¢çš„链接找到 + + http://eaglet.pdxhosts.com/rick/linux/schedstat/v12/latency.c diff --git a/Documentation/translations/zh_CN/vm/active_mm.rst b/Documentation/translations/zh_CN/vm/active_mm.rst new file mode 100644 index 000000000000..366609ea4f37 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/active_mm.rst @@ -0,0 +1,85 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/active_mm.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +========= +Active MM +========= + +这是一å°linux之父回å¤å¼€å‘者的一å°é‚®ä»¶ï¼Œæ‰€ä»¥ç¿»è¯‘时我尽é‡ä¿æŒé‚®ä»¶æ ¼å¼çš„完整。 + +:: + + List: linux-kernel + Subject: Re: active_mm + From: Linus Torvalds <torvalds () transmeta ! com> + Date: 1999-07-30 21:36:24 + + å› ä¸ºæˆ‘å¹¶ä¸ç»å¸¸å†™è§£é‡Šï¼Œæ‰€ä»¥å·²ç»æŠ„é€åˆ°linux-kernel邮件列表，而当我åšè¿™äº›ï¼Œ + 且更多的人在阅读它们时，我觉得棒æžäº†ã€‚ + + 1999å¹´7月30æ—¥ 星期五， David Mosberger 写é“： + > + > 是å¦æœ‰ä¸€ä¸ªç®€çŸçš„æ述，说明task_structä¸çš„ + > "mm" å’Œ "active_mm"应该如何使用？ (如果 + > 这个问题在邮件列表ä¸è®¨è®ºè¿‡ï¼Œæˆ‘表示æ‰æ„--我刚 + > 刚度å‡å›žæ¥ï¼Œæœ‰ä¸€æ®µæ—¶é—´æ²¡èƒ½å…³æ³¨linux-kernel了）。 + + 基本上，新的设定是： + + - 我们有“真实地å€ç©ºé—´â€å’Œâ€œåŒ¿å地å€ç©ºé—´â€ã€‚区别在于，匿å地å€ç©ºé—´æ ¹æœ¬ä¸å…³å¿ƒç”¨ + 户级页表，所以当我们åšä¸Šä¸‹æ–‡åˆ‡æ¢åˆ°åŒ¿å地å€ç©ºé—´æ—¶ï¼Œæˆ‘们åªæ˜¯è®©ä»¥å‰çš„地å€ç©ºé—´ + 处于活动状æ€ã€‚ + + 一个“匿å地å€ç©ºé—´â€çš„明显用途是任何ä¸éœ€è¦ä»»ä½•ç”¨æˆ·æ˜ 射的线程--æ‰€æœ‰çš„å†…æ ¸çº¿ + 程基本上都属于这一类，但å³ä½¿æ˜¯â€œçœŸæ£çš„â€çº¿ç¨‹ä¹Ÿå¯ä»¥æš‚æ—¶è¯´åœ¨ä¸€å®šæ—¶é—´å†…å®ƒä»¬ä¸ + 会对用户空间感兴趣，调度器ä¸å¦¨è¯•ç€é¿å…在切æ¢VM状æ€ä¸Šæµªè´¹æ—¶é—´ã€‚ç›®å‰åªæœ‰è€ + å¼çš„bdflush sync能åšåˆ°è¿™ä¸€ç‚¹ã€‚ + + - “tsk->mmâ€ æŒ‡å‘ â€œçœŸå®žåœ°å€ç©ºé—´â€ã€‚对于一个匿å进程æ¥è¯´ï¼Œtsk->mm将是NULL， + å…¶é€»è¾‘åŽŸå› æ˜¯åŒ¿åè¿›ç¨‹å®žé™…ä¸Šæ ¹æœ¬å°± “没有†真æ£çš„地å€ç©ºé—´ã€‚ + + - 然而，我们显然需è¦è·Ÿè¸ªæˆ‘ä»¬ä¸ºè¿™æ ·çš„åŒ¿å用户“å·ç”¨â€äº†å“ªä¸ªåœ°å€ç©ºé—´ã€‚为æ¤ï¼Œæˆ‘们 + 有 “tsk->active_mmâ€ï¼Œå®ƒæ˜¾ç¤ºäº†å½“å‰æ´»åŠ¨çš„地å€ç©ºé—´æ˜¯ä»€ä¹ˆã€‚ + + 规则是，对于一个有真实地å€ç©ºé—´çš„进程（å³tsk->mm是 non-NULL），active_mm + 显然必须与真实的mm相åŒã€‚ + + 对于一个匿å进程，tsk->mm == NULL，而tsk->active_mm是匿å进程è¿è¡Œæ—¶ + “借用â€çš„mm。当匿å进程被调度走时，借用的地å€ç©ºé—´è¢«è¿”回并清除。 + + 为了支æŒæ‰€æœ‰è¿™äº›ï¼Œâ€œstruct mm_structâ€çŽ°åœ¨æœ‰ä¸¤ä¸ªè®¡æ•°å™¨ï¼šä¸€ä¸ªæ˜¯ “mm_users†+ 计数器，å³æœ‰å¤šå°‘ “真æ£çš„地å€ç©ºé—´ç”¨æˆ·â€ï¼Œå¦ä¸€ä¸ªæ˜¯ “mm_countâ€è®¡æ•°å™¨ï¼Œå³ “lazy†+ 用户（å³åŒ¿å用户）的数é‡ï¼Œå¦‚果有任何真æ£çš„ç”¨æˆ·ï¼Œåˆ™åŠ 1。 + + 通常情况下，至少有一个真æ£çš„用户，但也å¯èƒ½æ˜¯çœŸæ£çš„用户在å¦ä¸€ä¸ªCPU上退出，而 + 一个lazy的用户ä»åœ¨æ´»åŠ¨ï¼Œæ‰€ä»¥ä½ å®žé™…ä¸Šå¾—åˆ°çš„æƒ…å†µæ˜¯ï¼Œä½ æœ‰ä¸€ä¸ªåœ°å€ç©ºé—´ **åª** + 被lazy的用户使用。这通常是一个çŸæš‚的生命周期状æ€ï¼Œå› 为一旦这个线程被安排给一 + 个真æ£çš„线程，这个 “僵尸†mmå°±ä¼šè¢«é‡Šæ”¾ï¼Œå› ä¸º “mm_countâ€å˜æˆäº†é›¶ã€‚ + + å¦å¤–，一个新的规则是，**没有人** å†æŠŠ “init_mm†作为一个真æ£çš„MM了。 + “init_mmâ€åº”该被认为åªæ˜¯ä¸€ä¸ª “没有其他上下文时的lazy上下文â€ï¼Œäº‹å®žä¸Šï¼Œå®ƒä¸» + è¦æ˜¯åœ¨å¯åŠ¨æ—¶ä½¿ç”¨ï¼Œå½“时还没有真æ£çš„VMè¢«åˆ›å»ºã€‚å› æ¤ï¼Œç”¨æ¥æ£€æŸ¥çš„代ç + + if (current->mm == &init_mm) + + 一般æ¥è¯´ï¼Œåº”该用 + + if (!current->mm) + + å–代上é¢çš„写法（这更有æ„义--测试基本上是 “我们是å¦æœ‰ä¸€ä¸ªç”¨æˆ·çŽ¯å¢ƒâ€ï¼Œå¹¶ä¸”通常 + 由缺页异常处ç†ç¨‹åºå’Œç±»ä¼¼çš„东西æ¥å®Œæˆï¼‰ã€‚ + + 总之，我刚æ‰åœ¨ftp.kernel.org上放了一个pre-patch-2.3.13-1ï¼Œå› ä¸ºå®ƒç¨å¾®æ”¹ + å˜äº†æŽ¥å£ä»¥é€‚é…alpha（è°ä¼šæƒ³åˆ°å‘¢ï¼Œä½†alpha体系结构上下文切æ¢ä»£ç 实际上最终是 + 最丑陋的之一--ä¸åƒå…¶ä»–架构的MM和寄å˜å™¨çŠ¶æ€æ˜¯åˆ†å¼€çš„，alphaçš„PALcode将两者 + 连接起æ¥ï¼Œä½ 需è¦åŒæ—¶åˆ‡æ¢ä¸¤è€…）。 + + (文档æ¥æº http://marc.info/?l=linux-kernel&m=93337278602211&w=2) diff --git a/Documentation/translations/zh_CN/vm/balance.rst b/Documentation/translations/zh_CN/vm/balance.rst new file mode 100644 index 000000000000..e98a47ef24a8 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/balance.rst @@ -0,0 +1,81 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/balance.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +======== +内å˜å¹³è¡¡ +======== + +2000å¹´1月开始，作者：Kanoj Sarcar <kanoj@sgi.com> + +对于 !__GFP_HIGH å’Œ !__GFP_KSWAPD_RECLAIM 以åŠéž __GFP_IO 的分é…，需è¦è¿›è¡Œ +内å˜å¹³è¡¡ã€‚ + +调用者é¿å…å›žæ”¶çš„ç¬¬ä¸€ä¸ªåŽŸå› æ˜¯è°ƒç”¨è€…ç”±äºŽæŒæœ‰è‡ªæ—‹é”或处于ä¸æ–环境ä¸è€Œæ— 法ç¡çœ 。第二个 +åŽŸå› å¯èƒ½æ˜¯ï¼Œè°ƒç”¨è€…æ„¿æ„在ä¸äº§ç”Ÿé¡µé¢å›žæ”¶å¼€é”€çš„情况下分é…失败。这å¯èƒ½å‘生在有0阶回退 +选项的机会主义高阶分é…请求ä¸ã€‚在这ç§æƒ…况下，调用者å¯èƒ½ä¹Ÿå¸Œæœ›é¿å…唤醒kswapd。 + +__GFP_IO分é…请求是为了防æ¢æ–‡ä»¶ç³»ç»Ÿæ»é”。 + +在没有éžç¡çœ 分é…请求的情况下，åšå¹³è¡¡ä¼¼ä¹Žæ˜¯æœ‰å®³çš„。页é¢å›žæ”¶å¯ä»¥è¢«æ‡’散地å¯åŠ¨ï¼Œä¹Ÿå°±æ˜¯ +说，åªæœ‰åœ¨éœ€è¦çš„时候（也就是区域的空闲内å˜ä¸º0），而ä¸æ˜¯è®©å®ƒæˆä¸ºä¸€ä¸ªä¸»åŠ¨çš„过程。 + +ä¹Ÿå°±æ˜¯è¯´ï¼Œå†…æ ¸åº”è¯¥å°è¯•ä»Žç›´æŽ¥æ˜ å°„æ± ä¸æ»¡è¶³å¯¹ç›´æŽ¥æ˜ 射页的请求，而ä¸æ˜¯å›žé€€åˆ°dmaæ± ä¸ï¼Œ +è¿™æ ·å°±å¯ä»¥ä¿æŒdmaæ± ä¸ºdma请求（ä¸ç®¡æ˜¯ä¸æ˜¯åŽŸåçš„ï¼‰æ‰€å¡«å……ã€‚ç±»ä¼¼çš„äº‰è®ºä¹Ÿé€‚ç”¨äºŽé«˜å†…å˜ +å’Œç›´æŽ¥æ˜ å°„çš„é¡µé¢ã€‚相å，如果有很多空闲的dma页，最好是通过从dmaæ± ä¸åˆ†é…一个æ¥æ»¡è¶³ +常规的内å˜è¯·æ±‚，而ä¸æ˜¯äº§ç”Ÿå¸¸è§„区域平衡的开销。 + +在2.2ä¸ï¼Œåªæœ‰å½“空闲页总数低于总内å˜çš„1/64时，æ‰ä¼šå¯åŠ¨å†…å˜å¹³è¡¡/页é¢å›žæ”¶ã€‚如果dma +和常规内å˜çš„比例åˆé€‚，å³ä½¿dma区完全空了，也很å¯èƒ½ä¸ä¼šè¿›è¡Œå¹³è¡¡ã€‚2.2å·²ç»åœ¨ä¸åŒå†…å˜ +大å°çš„生产机器上è¿è¡Œï¼Œå³ä½¿æœ‰è¿™ä¸ªé—®é¢˜å˜åœ¨ï¼Œä¼¼ä¹Žä¹Ÿåšå¾—ä¸é”™ã€‚在2.3ä¸ï¼Œç”±äºŽHIGHMEMçš„ +å˜åœ¨ï¼Œè¿™ä¸ªé—®é¢˜å˜å¾—æ›´åŠ ä¸¥é‡ã€‚ + +在2.3ä¸ï¼ŒåŒºåŸŸå¹³è¡¡å¯ä»¥ç”¨ä¸¤ç§æ–¹å¼ä¹‹ä¸€æ¥å®Œæˆï¼šæ ¹æ®åŒºåŸŸçš„大å°ï¼ˆå¯èƒ½æ˜¯ä½Žçº§åŒºåŸŸçš„大å°ï¼‰ï¼Œ +我们å¯ä»¥åœ¨åˆå§‹åŒ–阶段决定在平衡任何区域时应该争å–多少空闲页。好的方é¢æ˜¯ï¼Œåœ¨å¹³è¡¡çš„æ—¶ +候，我们ä¸éœ€è¦çœ‹ä½Žçº§åŒºçš„大å°ï¼Œåçš„æ–¹é¢æ˜¯ï¼Œæˆ‘们å¯èƒ½ä¼šå› 为忽略低级区å¯èƒ½è¾ƒä½Žçš„使用率 +而åšè¿‡äºŽé¢‘ç¹çš„平衡。å¦å¤–，åªè¦å¯¹åˆ†é…程åºç¨ä½œä¿®æ”¹ï¼Œå°±æœ‰å¯èƒ½å°†memclass()å®ç®€åŒ–为一 +个简å•çš„ç‰å¼ã€‚ + +å¦ä¸€ä¸ªå¯èƒ½çš„解决方案是，我们åªåœ¨ä¸€ä¸ªåŒº **å’Œ** 其所有低级区的空闲内å˜ä½ŽäºŽè¯¥åŒºåŠå…¶ +低级区总内å˜çš„1/64时进行平衡。这就解决了2.2的平衡问题，并尽å¯èƒ½åœ°ä¿æŒäº†ä¸Ž2.2行为 +的接近。å¦å¤–，平衡算法在å„ç§æž¶æž„上的工作方å¼ä¹Ÿæ˜¯ä¸€æ ·çš„，这些架构有ä¸åŒæ•°é‡å’Œç±»åž‹çš„ +内å˜åŒºã€‚如果我们想å˜å¾—更花哨一点，我们å¯ä»¥åœ¨æœªæ¥ä¸ºä¸åŒåŒºåŸŸçš„自由页é¢åˆ†é…ä¸åŒçš„æƒé‡ã€‚ + +请注æ„，如果普通区的大å°ä¸Ždma区相比是巨大的，那么在决定是å¦å¹³è¡¡æ™®é€šåŒºçš„时候，考虑 +空闲的dma页就å˜å¾—ä¸é‚£ä¹ˆé‡è¦äº†ã€‚那么第一个解决方案就å˜å¾—更有å¸å¼•åŠ›ã€‚ + +所附的补ä¸å®žçŽ°äº†ç¬¬äºŒä¸ªè§£å†³æ–¹æ¡ˆã€‚它还 “修å¤â€äº†ä¸¤ä¸ªé—®é¢˜ï¼šé¦–先，在低内å˜æ¡ä»¶ä¸‹ï¼Œkswapd +被唤醒，就åƒ2.2ä¸çš„éžç¡çœ 分é…。第二，HIGHMEM区也被平衡了，以便给replace_with_highmem() +一个争å–获得HIGHMEM页的机会，åŒæ—¶ç¡®ä¿HIGHMEM分é…ä¸ä¼šè½å›žæ™®é€šåŒºã€‚这也确ä¿äº†HIGHMEM +页ä¸ä¼šè¢«æ³„露（例如，在一个HIGHMEM页在交æ¢ç¼“å˜ä¸ä½†æ²¡æœ‰è¢«ä»»ä½•äººä½¿ç”¨çš„情况下）。 + +kswapd还需è¦çŸ¥é“它应该平衡哪些区。kswapd主è¦æ˜¯åœ¨æ— 法进行平衡的情况下需è¦çš„，å¯èƒ½ +æ˜¯å› ä¸ºæ‰€æœ‰çš„åˆ†é…请求都æ¥è‡ªä¸æ–上下文，而所有的进程上下文都在ç¡çœ 。对于2.3， +kswapd并ä¸çœŸæ£éœ€è¦å¹³è¡¡é«˜å†…å˜åŒºï¼Œå› 为ä¸æ–上下文并ä¸è¯·æ±‚高内å˜é¡µã€‚kswapd看zone +结构体ä¸çš„zone_wake_kswapdå—段æ¥å†³å®šä¸€ä¸ªåŒºæ˜¯å¦éœ€è¦å¹³è¡¡ã€‚ + +如果从进程内å˜å’Œshmä¸å·å–页é¢å¯ä»¥å‡è½»è¯¥é¡µé¢èŠ‚点ä¸ä»»ä½•åŒºçš„内å˜åŽ‹åŠ›ï¼Œè€Œè¯¥åŒºçš„内å˜åŽ‹åŠ› +å·²ç»ä½ŽäºŽå…¶æ°´ä½ï¼Œåˆ™ä¼šè¿›è¡Œå·å–。 + +watemark[WMARK_MIN/WMARK_LOW/WMARK_HIGH]/low_on_memory/zone_wake_kswapd： +这些是æ¯ä¸ªåŒºçš„å—段，用于确定一个区何时需è¦å¹³è¡¡ã€‚当页é¢æ•°ä½ŽäºŽæ°´ä½[WMARK_MIN]时， +hysteric çš„å—段low_on_memory被设置。这个å—段会一直被设置，直到空闲页数å˜æˆæ°´ä½ +[WMARK_HIGH]。当low_on_memory被设置时，页é¢åˆ†é…请求将å°è¯•é‡Šæ”¾è¯¥åŒºåŸŸçš„一些页é¢ï¼ˆå¦‚æžœ +请求ä¸è®¾ç½®äº†GFP_WAIT）。与æ¤ç›¸å的是，决定唤醒kswapd以释放一些区的页。这个决定ä¸æ˜¯åŸºäºŽ +hysteresis 的，而是当空闲页的数é‡ä½ŽäºŽwatermark[WMARK_LOW]时就会进行；在这ç§æƒ…况下， +zone_wake_kswapd也被设置。 + + +我所å¬åˆ°çš„（超棒的）想法： + +1. 动æ€ç»åŽ†åº”该影å“平衡：å¯ä»¥è·Ÿè¸ªä¸€ä¸ªåŒºçš„失败请求的数é‡ï¼Œå¹¶å馈到平衡方案ä¸ï¼ˆjalvo@mbay.net）。 + +2. 实现一个类似于replace_with_highmem()çš„replace_with_regular()，以ä¿ç•™dma页é¢ã€‚ + (lkd@tantalophile.demon.co.uk) diff --git a/Documentation/translations/zh_CN/vm/damon/api.rst b/Documentation/translations/zh_CN/vm/damon/api.rst new file mode 100644 index 000000000000..21143eea4ebe --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/api.rst @@ -0,0 +1,32 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/api.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +======= +APIå‚考 +======= + +å†…æ ¸ç©ºé—´çš„ç¨‹åºå¯ä»¥ä½¿ç”¨ä¸‹é¢çš„APIæ¥ä½¿ç”¨DAMONçš„æ¯ä¸ªåŠŸèƒ½ã€‚ä½ æ‰€éœ€è¦åšçš„就是引用 ``damon.h`` ， +它ä½äºŽæºä»£ç æ ‘çš„include/linux/。 + +结构体 +====== + +该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: + +include/linux/damon.h + + +函数 +==== + +该APIåœ¨ä»¥ä¸‹å†…æ ¸ä»£ç ä¸: + +mm/damon/core.c diff --git a/Documentation/translations/zh_CN/vm/damon/design.rst b/Documentation/translations/zh_CN/vm/damon/design.rst new file mode 100644 index 000000000000..05f66c02740a --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/design.rst @@ -0,0 +1,139 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/design.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +==== +设计 +==== + +å¯é…置的层 +========== + +DAMONæ供了数æ®è®¿é—®ç›‘控功能，åŒæ—¶ä½¿å…¶å‡†ç¡®æ€§å’Œå¼€é”€å¯æŽ§ã€‚基本的访问监控需è¦ä¾èµ–äºŽç›®æ ‡åœ°å€ç©ºé—´ +并为之优化的基元。å¦ä¸€æ–¹é¢ï¼Œä½œä¸ºDAMONçš„æ ¸å¿ƒï¼Œå‡†ç¡®æ€§å’Œå¼€é”€çš„æƒè¡¡æœºåˆ¶æ˜¯åœ¨çº¯é€»è¾‘空间ä¸ã€‚DAMON +将这两部分分离在ä¸åŒçš„层ä¸ï¼Œå¹¶å®šä¹‰äº†å®ƒçš„接å£ï¼Œä»¥å…许å„ç§ä½Žå±‚æ¬¡çš„åŸºå…ƒå®žçŽ°ä¸Žæ ¸å¿ƒé€»è¾‘çš„é…置。 + +由于这ç§åˆ†ç¦»çš„设计和å¯é…置的接å£ï¼Œç”¨æˆ·å¯ä»¥é€šè¿‡é…ç½®æ ¸å¿ƒé€»è¾‘å’Œé€‚å½“çš„ä½Žçº§åŸºå…ƒå®žçŽ°æ¥æ‰©å±•DAMONçš„ +任何地å€ç©ºé—´ã€‚如果没有æä¾›åˆé€‚的，用户å¯ä»¥è‡ªå·±å®žçŽ°åŸºå…ƒã€‚ + +例如，物ç†å†…å˜ã€è™šæ‹Ÿå†…å˜ã€äº¤æ¢ç©ºé—´ã€é‚£äº›ç‰¹å®šçš„进程ã€NUMA节点ã€æ–‡ä»¶å’Œæ”¯æŒçš„内å˜è®¾å¤‡å°†è¢«æ”¯æŒã€‚ +å¦å¤–，如果æŸäº›æž¶æž„或设备支æŒç‰¹æ®Šçš„优化访问检查基元，这些基元将很容易被é…置。 + + +特定地å€ç©ºé—´åŸºå…ƒçš„å‚考实现 +========================== + +基本访问监测的低级基元被定义为两部分。: + +1. 确定地å€ç©ºé—´çš„ç›‘æµ‹ç›®æ ‡åœ°å€èŒƒå›´ +2. ç›®æ ‡ç©ºé—´ä¸ç‰¹å®šåœ°å€èŒƒå›´çš„访问检查。 + +DAMONç›®å‰ä¸ºç‰©ç†å’Œè™šæ‹Ÿåœ°å€ç©ºé—´æ供了基元的实现。下é¢ä¸¤ä¸ªå°èŠ‚æ述了这些工作的方å¼ã€‚ + + +基于VMAçš„ç›®æ ‡åœ°å€èŒƒå›´æž„é€ +------------------------- + +这仅仅是针对虚拟地å€ç©ºé—´åŸºå…ƒçš„实现。对于物ç†åœ°å€ç©ºé—´ï¼Œåªæ˜¯è¦æ±‚ç”¨æˆ·æ‰‹åŠ¨è®¾ç½®ç›‘æŽ§ç›®æ ‡åœ°å€èŒƒå›´ã€‚ + +在进程的超级巨大的虚拟地å€ç©ºé—´ä¸ï¼Œåªæœ‰å°éƒ¨åˆ†è¢«æ˜ 射到物ç†å†…å˜å¹¶è¢«è®¿é—®ã€‚å› æ¤ï¼Œè·Ÿè¸ªæœªæ˜ 射的地 +å€åŒºåŸŸåªæ˜¯ä¸€ç§æµªè´¹ã€‚然而，由于DAMONå¯ä»¥ä½¿ç”¨è‡ªé€‚应区域调整机制æ¥å¤„ç†ä¸€å®šç¨‹åº¦çš„噪声，所以严 +æ ¼æ¥è¯´ï¼Œè·Ÿè¸ªæ¯ä¸€ä¸ªæ˜ 射并ä¸æ˜¯å¿…须的，但在æŸäº›æƒ…å†µä¸‹ç”šè‡³ä¼šäº§ç”Ÿå¾ˆé«˜çš„å¼€é”€ã€‚ä¹Ÿå°±æ˜¯è¯´ï¼Œç›‘æµ‹ç›®æ ‡ +å†…éƒ¨è¿‡äºŽå·¨å¤§çš„æœªæ˜ å°„åŒºåŸŸåº”è¯¥è¢«ç§»é™¤ï¼Œä»¥ä¸å 用自适应机制的时间。 + +å‡ºäºŽè¿™ä¸ªåŽŸå› ï¼Œè¿™ä¸ªå®žçŽ°å°†å¤æ‚çš„æ˜ å°„è½¬æ¢ä¸ºä¸‰ä¸ªä¸åŒçš„区域，覆盖地å€ç©ºé—´çš„æ¯ä¸ªæ˜ 射区域。这三个 +区域之间的两个空隙是给定地å€ç©ºé—´ä¸ä¸¤ä¸ªæœ€å¤§çš„æœªæ˜ å°„åŒºåŸŸã€‚è¿™ä¸¤ä¸ªæœ€å¤§çš„æœªæ˜ å°„åŒºåŸŸæ˜¯å †å’Œæœ€ä¸Šé¢ +çš„mmap()区域之间的间隙，以åŠåœ¨å¤§å¤šæ•°æƒ…况下最下é¢çš„mmap()åŒºåŸŸå’Œå †ä¹‹é—´çš„é—´éš™ã€‚å› ä¸ºè¿™äº›é—´éš™ +在通常的地å€ç©ºé—´ä¸æ˜¯å¼‚常巨大的，排除这些间隙就足以åšå‡ºåˆç†çš„æƒè¡¡ã€‚下é¢è¯¦ç»†è¯´æ˜Žäº†è¿™ä¸€ç‚¹:: + + <heap> + <BIG UNMAPPED REGION 1> + <uppermost mmap()-ed region> + (small mmap()-ed regions and munmap()-ed regions) + <lowermost mmap()-ed region> + <BIG UNMAPPED REGION 2> + <stack> + + +基于PTE访问ä½çš„访问检查 +----------------------- + +物ç†å’Œè™šæ‹Ÿåœ°å€ç©ºé—´çš„实现都使用PTE Accessed-bit进行基本访问检查。唯一的区别在于从地å€ä¸ +找到相关的PTE访问ä½çš„æ–¹å¼ã€‚虚拟地å€çš„实现是为该地å€çš„ç›®æ ‡ä»»åŠ¡æŸ¥æ‰¾é¡µè¡¨ï¼Œè€Œç‰©ç†åœ°å€çš„实现则 +是查找与该地å€æœ‰æ˜ 射关系的æ¯ä¸€ä¸ªé¡µè¡¨ã€‚通过这ç§æ–¹å¼ï¼Œå®žçŽ°è€…æ‰¾åˆ°å¹¶æ¸…é™¤ä¸‹ä¸€ä¸ªé‡‡æ ·ç›®æ ‡åœ°å€çš„ä½ï¼Œ +并检查该ä½æ˜¯å¦åœ¨ä¸€ä¸ªé‡‡æ ·å‘¨æœŸåŽå†æ¬¡è®¾ç½®ã€‚è¿™å¯èƒ½ä¼šå¹²æ‰°å…¶ä»–使用访问ä½çš„å†…æ ¸å系统，å³ç©ºé—²é¡µè·Ÿ +踪和回收逻辑。为了é¿å…è¿™ç§å¹²æ‰°ï¼ŒDAMON使其与空闲页é¢è·Ÿè¸ªç›¸äº’排斥，并使用 ``PG_idle`` å’Œ +``PG_young`` 页é¢æ ‡å¿—æ¥è§£å†³ä¸Žå›žæ”¶é€»è¾‘的冲çªï¼Œå°±åƒç©ºé—²é¡µé¢è·Ÿè¸ªé‚£æ ·ã€‚ + + +独立于地å€ç©ºé—´çš„æ ¸å¿ƒæœºåˆ¶ +======================== + +下é¢å››ä¸ªéƒ¨åˆ†åˆ†åˆ«æ述了DAMONçš„æ ¸å¿ƒæœºåˆ¶å’Œäº”ä¸ªç›‘æµ‹å±žæ€§ï¼Œå³ ``é‡‡æ ·é—´éš”`` 〠``èšé›†é—´éš”`` 〠+``区域更新间隔`` 〠``最å°åŒºåŸŸæ•°`` å’Œ ``最大区域数`` 。 + + +访问频率监测 +------------ + +DAMON的输出显示了在给定的时间内哪些页é¢çš„访问频率是多少。访问频率的分辨率是通过设置 +``é‡‡æ ·é—´éš”`` å’Œ ``èšé›†é—´éš”`` æ¥æŽ§åˆ¶çš„。详细地说，DAMON检查æ¯ä¸ª ``é‡‡æ ·é—´éš”`` å¯¹æ¯ +个页é¢çš„访问，并将结果汇总。æ¢å¥è¯è¯´ï¼Œè®¡ç®—æ¯ä¸ªé¡µé¢çš„访问次数。在æ¯ä¸ª ``èšåˆé—´éš”`` 过 +去åŽï¼ŒDAMON调用先å‰ç”±ç”¨æˆ·æ³¨å†Œçš„回调函数，以便用户å¯ä»¥é˜…读èšåˆçš„结果，然åŽå†æ¸…除这些结 +果。这å¯ä»¥ç”¨ä»¥ä¸‹ç®€å•çš„伪代ç æ¥æè¿°:: + + while monitoring_on: + for page in monitoring_target: + if accessed(page): + nr_accesses[page] += 1 + if time() % aggregation_interval == 0: + for callback in user_registered_callbacks: + callback(monitoring_target, nr_accesses) + for page in monitoring_target: + nr_accesses[page] = 0 + sleep(sampling interval) + +è¿™ç§æœºåˆ¶çš„监测开销将éšç€ç›®æ ‡å·¥ä½œè´Ÿè½½è§„模的增长而任æ„å¢žåŠ ã€‚ + + +åŸºäºŽåŒºåŸŸçš„æŠ½æ ·è°ƒæŸ¥ +------------------ + +为了é¿å…å¼€é”€çš„æ— é™åˆ¶å¢žåŠ ，DAMONå°†å‡å®šå…·æœ‰ç›¸åŒè®¿é—®é¢‘率的相邻页é¢å½’入一个区域。åªè¦ä¿æŒ +这个å‡è®¾ï¼ˆä¸€ä¸ªåŒºåŸŸå†…的页é¢å…·æœ‰ç›¸åŒçš„访问频率），该区域内就åªéœ€è¦æ£€æŸ¥ä¸€ä¸ªé¡µé¢ã€‚å› æ¤ï¼Œå¯¹ +于æ¯ä¸ª ``é‡‡æ ·é—´éš”`` ，DAMON在æ¯ä¸ªåŒºåŸŸä¸éšæœºæŒ‘选一个页é¢ï¼Œç‰å¾…一个 ``é‡‡æ ·é—´éš”`` ，检 +查该页é¢æ˜¯å¦åŒæ—¶è¢«è®¿é—®ï¼Œå¦‚æžœè¢«è®¿é—®åˆ™å¢žåŠ è¯¥åŒºåŸŸçš„è®¿é—®é¢‘çŽ‡ã€‚å› æ¤ï¼Œç›‘测开销是å¯ä»¥é€šè¿‡è®¾ç½® +区域的数é‡æ¥æŽ§åˆ¶çš„。DAMONå…许用户设置最å°å’Œæœ€å¤§çš„区域数é‡æ¥è¿›è¡Œæƒè¡¡ã€‚ + +然而，如果å‡è®¾æ²¡æœ‰å¾—到ä¿è¯ï¼Œè¿™ä¸ªæ–¹æ¡ˆå°±ä¸èƒ½ä¿æŒè¾“出的质é‡ã€‚ + + +适应性区域调整 +-------------- + +å³ä½¿æœ€åˆçš„ç›‘æµ‹ç›®æ ‡åŒºåŸŸè¢«å¾ˆå¥½åœ°æž„å»ºä»¥æ»¡è¶³å‡è®¾ï¼ˆåŒä¸€åŒºåŸŸå†…的页é¢å…·æœ‰ç›¸ä¼¼çš„访问频率），数 +æ®è®¿é—®æ¨¡å¼ä¹Ÿä¼šè¢«åŠ¨æ€åœ°æ”¹å˜ã€‚这将导致监测质é‡ä¸‹é™ã€‚为了尽å¯èƒ½åœ°ä¿æŒå‡è®¾ï¼ŒDAMONæ ¹æ®æ¯ä¸ª +区域的访问频率自适应地进行åˆå¹¶å’Œæ‹†åˆ†ã€‚ + +对于æ¯ä¸ª ``èšé›†åŒºé—´`` ，它比较相邻区域的访问频率，如果频率差异较å°ï¼Œå°±åˆå¹¶è¿™äº›åŒºåŸŸã€‚ +然åŽï¼Œåœ¨å®ƒæŠ¥å‘Šå¹¶æ¸…除æ¯ä¸ªåŒºåŸŸçš„èšåˆæŽ¥å…¥é¢‘率åŽï¼Œå¦‚果区域总数ä¸è¶…过用户指定的最大区域数， +它将æ¯ä¸ªåŒºåŸŸæ‹†åˆ†ä¸ºä¸¤ä¸ªæˆ–三个区域。 + +通过这ç§æ–¹å¼ï¼ŒDAMONæ供了其最佳的质é‡å’Œæœ€å°çš„开销，åŒæ—¶ä¿æŒäº†ç”¨æˆ·ä¸ºå…¶æƒè¡¡è®¾å®šçš„ç•Œé™ã€‚ + + +动æ€ç›®æ ‡ç©ºé—´æ›´æ–°å¤„ç† +-------------------- + +ç›‘æµ‹ç›®æ ‡åœ°å€èŒƒå›´å¯ä»¥åŠ¨æ€æ”¹å˜ã€‚例如，虚拟内å˜å¯ä»¥åŠ¨æ€åœ°è¢«æ˜ å°„å’Œè§£æ˜ å°„ã€‚ç‰©ç†å†…å˜å¯ä»¥è¢« +çƒæ’拔。 + +由于在æŸäº›æƒ…况下å˜åŒ–å¯èƒ½ç›¸å½“频ç¹ï¼ŒDAMON检查动æ€å†…å˜æ˜ å°„çš„å˜åŒ–，并仅在用户指定的时间 +间隔（ ``区域更新间隔`` ï¼‰å†…å°†å…¶åº”ç”¨äºŽæŠ½è±¡çš„ç›®æ ‡åŒºåŸŸã€‚ diff --git a/Documentation/translations/zh_CN/vm/damon/faq.rst b/Documentation/translations/zh_CN/vm/damon/faq.rst new file mode 100644 index 000000000000..07b4ac19407d --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/faq.rst @@ -0,0 +1,48 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/faq.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +======== +常è§é—®é¢˜ +======== + +为什么是一个新的å系统，而ä¸æ˜¯æ‰©å±•perf或其他用户空间工具？ +========================================================== + +é¦–å…ˆï¼Œå› ä¸ºå®ƒéœ€è¦å°½å¯èƒ½çš„è½»é‡çº§ï¼Œä»¥ä¾¿å¯ä»¥åœ¨çº¿ä½¿ç”¨ï¼Œæ‰€ä»¥åº”该é¿å…任何ä¸å¿…è¦çš„å¼€é”€ï¼Œå¦‚å†…æ ¸-用户 +空间的上下文切æ¢æˆæœ¬ã€‚第二，DAMONçš„ç›®æ ‡æ˜¯è¢«åŒ…æ‹¬å†…æ ¸åœ¨å†…çš„å…¶ä»–ç¨‹åºæ‰€ä½¿ç”¨ã€‚å› æ¤ï¼Œå¯¹ç‰¹å®šå·¥å…· +（如perf）的ä¾èµ–性是ä¸å¯å–的。这就是DAMONåœ¨å†…æ ¸ç©ºé—´å®žçŽ°çš„ä¸¤ä¸ªæœ€å¤§çš„åŽŸå› ã€‚ + + +“闲置页é¢è·Ÿè¸ªâ€ 或 “perf mem†å¯ä»¥æ›¿ä»£DAMONå—？ +============================================== + +闲置页跟踪是物ç†åœ°å€ç©ºé—´è®¿é—®æ£€æŸ¥çš„一个低层次的原始方法。“perf memâ€ä¹Ÿæ˜¯ç±»ä¼¼çš„，尽管它å¯ä»¥ +ä½¿ç”¨é‡‡æ ·æ¥å‡å°‘开销。å¦ä¸€æ–¹é¢ï¼ŒDAMON是一个更高层次的框架，用于监控å„ç§åœ°å€ç©ºé—´ã€‚它专注于内 +å˜ç®¡ç†ä¼˜åŒ–，并æä¾›å¤æ‚的精度/开销处ç†æœºåˆ¶ã€‚å› æ¤ï¼Œâ€œç©ºé—²é¡µé¢è·Ÿè¸ªâ€ å’Œ “perf mem†å¯ä»¥æä¾› +DAMON输出的一个å集，但ä¸èƒ½æ›¿ä»£DAMON。 + + +DAMON是å¦åªæ”¯æŒè™šæ‹Ÿå†…å˜ï¼Ÿ +========================= + +ä¸ï¼ŒDAMONçš„æ ¸å¿ƒæ˜¯ç‹¬ç«‹äºŽåœ°å€ç©ºé—´çš„。用户å¯ä»¥åœ¨DAMONæ ¸å¿ƒä¸Šå®žçŽ°å’Œé…置特定地å€ç©ºé—´çš„低级原始 +éƒ¨åˆ†ï¼ŒåŒ…æ‹¬ç›‘æµ‹ç›®æ ‡åŒºåŸŸçš„æž„é€ å’Œå®žé™…çš„è®¿é—®æ£€æŸ¥ã€‚é€šè¿‡è¿™ç§æ–¹å¼ï¼ŒDAMON用户å¯ä»¥ç”¨ä»»ä½•è®¿é—®æ£€æŸ¥æŠ€ +术æ¥ç›‘测任何地å€ç©ºé—´ã€‚ + +尽管如æ¤ï¼ŒDAMON默认为虚拟内å˜å’Œç‰©ç†å†…å˜æ供了基于vma/rmap跟踪和PTE访问ä½æ£€æŸ¥çš„地å€ç©ºé—´ +相关功能的实现，以供å‚考和方便使用。 + + +我å¯ä»¥ç®€å•åœ°ç›‘测页é¢çš„粒度å—？ +============================== + +æ˜¯çš„ï¼Œä½ å¯ä»¥é€šè¿‡è®¾ç½® ``min_nr_regions`` 属性高于工作集大å°é™¤ä»¥é¡µé¢å¤§å°çš„值æ¥å®žçŽ°ã€‚ +å› ä¸ºç›‘è§†ç›®æ ‡åŒºåŸŸçš„å¤§å°è¢«å¼ºåˆ¶ä¸º ``>=page size`` ，所以区域分割ä¸ä¼šäº§ç”Ÿä»»ä½•å½±å“。 diff --git a/Documentation/translations/zh_CN/vm/damon/index.rst b/Documentation/translations/zh_CN/vm/damon/index.rst new file mode 100644 index 000000000000..84d36d90c9b0 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/damon/index.rst @@ -0,0 +1,33 @@ +.. SPDX-License-Identifier: GPL-2.0 + +:Original: Documentation/vm/damon/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + + +========================== +DAMON:æ•°æ®è®¿é—®ç›‘视器 +========================== + +DAMON是Linuxå†…æ ¸çš„ä¸€ä¸ªæ•°æ®è®¿é—®ç›‘控框架å系统。DAMONçš„æ ¸å¿ƒæœºåˆ¶ä½¿å…¶æˆä¸º +ï¼ˆè¯¥æ ¸å¿ƒæœºåˆ¶è¯¦è§(Documentation/translations/zh_CN/vm/damon/design.rst)） + + - *准确度* （监测输出对DRAM级别的内å˜ç®¡ç†è¶³å¤Ÿæœ‰ç”¨ï¼›ä½†å¯èƒ½ä¸é€‚åˆCPU Cache级别）， + - *è½»é‡çº§* （监控开销低到å¯ä»¥åœ¨çº¿åº”ç”¨ï¼‰ï¼Œä»¥åŠ + - *å¯æ‰©å±•* ï¼ˆæ— è®ºç›®æ ‡å·¥ä½œè´Ÿè½½çš„å¤§å°ï¼Œå¼€é”€çš„上é™å€¼éƒ½åœ¨æ’定范围内）。 + +å› æ¤ï¼Œåˆ©ç”¨è¿™ä¸ªæ¡†æž¶ï¼Œå†…æ ¸çš„å†…å˜ç®¡ç†æœºåˆ¶å¯ä»¥åšå‡ºé«˜çº§å†³ç–。会导致高数æ®è®¿é—®ç›‘控开销的实 +验性内å˜ç®¡ç†ä¼˜åŒ–工作å¯ä»¥å†æ¬¡è¿›è¡Œã€‚åŒæ—¶ï¼Œåœ¨ç”¨æˆ·ç©ºé—´ï¼Œæœ‰ä¸€äº›ç‰¹æ®Šå·¥ä½œè´Ÿè½½çš„用户å¯ä»¥ç¼–写 +个性化的应用程åºï¼Œä»¥ä¾¿æ›´å¥½åœ°äº†è§£å’Œä¼˜åŒ–他们的工作负载和系统。 + +.. toctree:: + :maxdepth: 2 + + faq + design + api + diff --git a/Documentation/translations/zh_CN/vm/free_page_reporting.rst b/Documentation/translations/zh_CN/vm/free_page_reporting.rst new file mode 100644 index 000000000000..31d6c34b956b --- /dev/null +++ b/Documentation/translations/zh_CN/vm/free_page_reporting.rst @@ -0,0 +1,38 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/_free_page_reporting.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +========== +空闲页报告 +========== + +空闲页报告是一个API，设备å¯ä»¥é€šè¿‡å®ƒæ¥æ³¨å†ŒæŽ¥æ”¶ç³»ç»Ÿå½“å‰æœªä½¿ç”¨çš„页é¢åˆ—表。这在虚拟 +化的情况下是很有用的，客户机能够使用这些数æ®æ¥é€šçŸ¥ç®¡ç†å™¨å®ƒä¸å†ä½¿ç”¨å†…å˜ä¸çš„æŸäº›é¡µ +é¢ã€‚ + +对于驱动，通常是气çƒé©±åŠ¨è¦ä½¿ç”¨è¿™ä¸ªåŠŸèƒ½ï¼Œå®ƒå°†åˆ†é…å’Œåˆå§‹åŒ–一个page_reporting_dev_info +结构体。它è¦å¡«å……的结构体ä¸çš„å—段是用于处ç†æ•£ç‚¹åˆ—表的 "report" 函数指针。它还必 +é¡»ä¿è¯æ¯æ¬¡è°ƒç”¨è¯¥å‡½æ•°æ—¶èƒ½å¤„ç†è‡³å°‘相当于PAGE_REPORTING_CAPACITY的散点列表æ¡ç›®ã€‚ +å‡è®¾æ²¡æœ‰å…¶ä»–页é¢æŠ¥å‘Šè®¾å¤‡å·²ç»æ³¨å†Œï¼Œ 对page_reporting_register的调用将å‘报告框 +架注册页é¢æŠ¥å‘ŠæŽ¥å£ã€‚ + +一旦注册，页é¢æŠ¥å‘ŠAPI将开始å‘驱动报告æˆæ‰¹çš„页é¢ã€‚API将在接å£è¢«æ³¨å†ŒåŽ2秒开始报告 +页é¢ï¼Œå¹¶åœ¨ä»»ä½•è¶³å¤Ÿé«˜çš„页é¢è¢«é‡Šæ”¾ä¹‹åŽ2秒继ç»æŠ¥å‘Šã€‚ + +报告的页é¢å°†è¢«å˜å‚¨åœ¨ä¼ 递给报告函数的散列表ä¸ï¼Œæœ€åŽä¸€ä¸ªæ¡ç›®çš„结æŸä½è¢«è®¾ç½®åœ¨æ¡ç›® +nent-1ä¸ã€‚ 当页é¢è¢«æŠ¥å‘Šå‡½æ•°å¤„ç†æ—¶ï¼Œåˆ†é…å™¨å°†æ— æ³•è®¿é—®å®ƒä»¬ã€‚ä¸€æ—¦æŠ¥å‘Šå‡½æ•°å®Œæˆï¼Œè¿™äº› +页将被返回到它们所获得的自由区域。 + +在移除使用空闲页报告的驱动之å‰ï¼Œæœ‰å¿…è¦è°ƒç”¨page_reporting_unregister，以移除 +ç›®å‰è¢«ç©ºé—²é¡µæŠ¥å‘Šä½¿ç”¨çš„page_reporting_dev_infoç»“æž„ä½“ã€‚è¿™æ ·åšå°†é˜»æ¢è¿›ä¸€æ¥çš„报 +告通过该接å£å‘出。如果å¦ä¸€ä¸ªé©±åŠ¨æˆ–åŒä¸€é©±åŠ¨è¢«æ³¨å†Œï¼Œå®ƒå°±æœ‰å¯èƒ½æ¢å¤å‰ä¸€ä¸ªé©±åŠ¨åœ¨æŠ¥å‘Š +空闲页方é¢çš„工作。 + + +Alexander Duyck, 2019å¹´12月04æ—¥ diff --git a/Documentation/translations/zh_CN/vm/highmem.rst b/Documentation/translations/zh_CN/vm/highmem.rst new file mode 100644 index 000000000000..018838e58c3e --- /dev/null +++ b/Documentation/translations/zh_CN/vm/highmem.rst @@ -0,0 +1,128 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/highmem.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +========== +高内å˜å¤„ç† +========== + +作者: Peter Zijlstra <a.p.zijlstra@chello.nl> + +.. contents:: :local: + +高内å˜æ˜¯ä»€ä¹ˆï¼Ÿ +============== + +当物ç†å†…å˜çš„大å°æŽ¥è¿‘或超过虚拟内å˜çš„最大大å°æ—¶ï¼Œå°±ä¼šä½¿ç”¨é«˜å†…å˜ï¼ˆhighmem）。在这一点上，内 +æ ¸ä¸å¯èƒ½åœ¨ä»»ä½•æ—¶å€™éƒ½ä¿æŒæ‰€æœ‰å¯ç”¨çš„物ç†å†…å˜çš„æ˜ å°„ã€‚è¿™æ„味ç€å†…æ ¸éœ€è¦å¼€å§‹ä½¿ç”¨å®ƒæƒ³è®¿é—®çš„物ç†å†… +å˜çš„ä¸´æ—¶æ˜ å°„ã€‚ + +æ²¡æœ‰è¢«æ°¸ä¹…æ˜ å°„è¦†ç›–çš„é‚£éƒ¨åˆ†ï¼ˆç‰©ç†ï¼‰å†…å˜å°±æ˜¯æˆ‘们所说的 "高内å˜"。对于这个边界的确切ä½ç½®ï¼Œæœ‰ +å„ç§æž¶æž„上的é™åˆ¶ã€‚ + +例如，在i386架构ä¸ï¼Œæˆ‘ä»¬é€‰æ‹©å°†å†…æ ¸æ˜ å°„åˆ°æ¯ä¸ªè¿›ç¨‹çš„è™šæ‹Ÿç©ºé—´ï¼Œè¿™æ ·æˆ‘ä»¬å°±ä¸å¿…ä¸ºå†…æ ¸çš„è¿›å…¥/退 +出付出全部的TLB作废代价。这æ„味ç€å¯ç”¨çš„虚拟内å˜ç©ºé—´ï¼ˆi386上为4GiBï¼‰å¿…é¡»åœ¨ç”¨æˆ·å’Œå†…æ ¸ç©ºé—´ä¹‹ +间进行划分。 + +使用这ç§æ–¹æ³•çš„æž¶æž„çš„ä¼ ç»Ÿåˆ†é…æ–¹å¼æ˜¯3:1，3GiB用于用户空间，顶部的1GiBç”¨äºŽå†…æ ¸ç©ºé—´ã€‚:: + + +--------+ 0xffffffff + | Kernel | + +--------+ 0xc0000000 + | | + | User | + | | + +--------+ 0x00000000 + +è¿™æ„味ç€å†…æ ¸åœ¨ä»»ä½•æ—¶å€™æœ€å¤šå¯ä»¥æ˜ å°„1GiB的物ç†å†…å˜ï¼Œä½†æ˜¯ç”±äºŽæˆ‘们需è¦è™šæ‹Ÿåœ°å€ç©ºé—´æ¥åšå…¶ä»–事 +情--包括访问其余物ç†å†…å˜çš„ä¸´æ—¶æ˜ å°„--å®žé™…çš„ç›´æŽ¥æ˜ å°„é€šå¸¸ä¼šæ›´å°‘ï¼ˆé€šå¸¸åœ¨~896MiBå·¦å³ï¼‰ã€‚ + +其他有mmä¸Šä¸‹æ–‡æ ‡ç¾çš„TLB的架构å¯ä»¥æœ‰ç‹¬ç«‹çš„å†…æ ¸å’Œç”¨æˆ·æ˜ å°„ã€‚ç„¶è€Œï¼Œä¸€äº›ç¡¬ä»¶ï¼ˆå¦‚ä¸€äº›ARM）在使 +用mmä¸Šä¸‹æ–‡æ ‡ç¾æ—¶ï¼Œå…¶è™šæ‹Ÿç©ºé—´æœ‰é™ã€‚ + + +ä¸´æ—¶è™šæ‹Ÿæ˜ å°„ +============ + +å†…æ ¸åŒ…å«å‡ ç§åˆ›å»ºä¸´æ—¶æ˜ 射的方法。: + +* vmap(). è¿™å¯ä»¥ç”¨æ¥å°†å¤šä¸ªç‰©ç†é¡µé•¿æœŸæ˜ 射到一个连ç»çš„虚拟空间。它需è¦synchronization + æ¥è§£é™¤æ˜ 射。 + +* kmap(). è¿™å…许对å•ä¸ªé¡µé¢è¿›è¡ŒçŸæœŸæ˜ 射。它需è¦synchronization，但在一定程度上被摊销。 + 当以嵌套方å¼ä½¿ç”¨æ—¶ï¼Œå®ƒä¹Ÿå¾ˆå®¹æ˜“出现æ»é”ï¼Œå› æ¤ä¸å»ºè®®åœ¨æ–°ä»£ç ä¸ä½¿ç”¨å®ƒã€‚ + +* kmap_atomic(). è¿™å…许对å•ä¸ªé¡µé¢è¿›è¡Œéžå¸¸çŸçš„æ—¶é—´æ˜ å°„ã€‚ç”±äºŽæ˜ å°„è¢«é™åˆ¶åœ¨å‘布它的CPU上， + 它表现得很好，但å‘å¸ƒä»»åŠ¡å› æ¤è¢«è¦æ±‚留在该CPU上直到它完æˆï¼Œä»¥å…其他任务å–ä»£å®ƒçš„æ˜ å°„ã€‚ + + kmap_atomic() 也å¯ä»¥ç”±ä¸æ–ä¸Šä¸‹æ–‡ä½¿ç”¨ï¼Œå› ä¸ºå®ƒä¸ç¡çœ ，而且调用者å¯èƒ½åœ¨è°ƒç”¨kunmap_atomic() + 之åŽæ‰ç¡çœ 。 + + å¯ä»¥å‡è®¾k[un]map_atomic()ä¸ä¼šå¤±è´¥ã€‚ + + +使用kmap_atomic +=============== + +何时何地使用 kmap_atomic() 是很直接的。当代ç 想è¦è®¿é—®ä¸€ä¸ªå¯èƒ½ä»Žé«˜å†…å˜ï¼ˆè§__GFP_HIGHMEM） +分é…的页é¢çš„内容时，例如在页缓å˜ä¸çš„页é¢ï¼Œå°±ä¼šä½¿ç”¨å®ƒã€‚该API有两个函数，它们的使用方å¼ä¸Ž +下é¢ç±»ä¼¼:: + + /* 找到感兴趣的页é¢ã€‚ */ + struct page *page = find_get_page(mapping, offset); + + /* 获得对该页内容的访问æƒã€‚ */ + void *vaddr = kmap_atomic(page); + + /* 对该页的内容åšä¸€äº›å¤„ç†ã€‚ */ + memset(vaddr, 0, PAGE_SIZE); + + /* 解除该页é¢çš„æ˜ å°„ã€‚ */ + kunmap_atomic(vaddr); + +注æ„，kunmap_atomic()调用的是kmap_atomic()调用的结果而ä¸æ˜¯å‚数。 + +å¦‚æžœä½ éœ€è¦æ˜ 射两个页é¢ï¼Œå› ä¸ºä½ æƒ³ä»Žä¸€ä¸ªé¡µé¢å¤åˆ¶åˆ°å¦ä¸€ä¸ªé¡µé¢ï¼Œä½ 需è¦ä¿æŒkmap_atomic调用严 +æ ¼åµŒå¥—ï¼Œå¦‚:: + + vaddr1 = kmap_atomic(page1); + vaddr2 = kmap_atomic(page2); + + memcpy(vaddr1, vaddr2, PAGE_SIZE); + + kunmap_atomic(vaddr2); + kunmap_atomic(vaddr1); + + +ä¸´æ—¶æ˜ å°„çš„æˆæœ¬ +============== + +åˆ›å»ºä¸´æ—¶æ˜ å°„çš„ä»£ä»·å¯èƒ½ç›¸å½“高。体系架构必须æ“ä½œå†…æ ¸çš„é¡µè¡¨ã€æ•°æ®TLBå’Œ/或MMU的寄å˜å™¨ã€‚ + +如果CONFIG_HIGHMEMæ²¡æœ‰è¢«è®¾ç½®ï¼Œé‚£ä¹ˆå†…æ ¸ä¼šå°è¯•ç”¨ä¸€ç‚¹è®¡ç®—æ¥åˆ›å»ºæ˜ 射，将页é¢ç»“构地å€è½¬æ¢æˆ +指å‘页é¢å†…容的指针，而ä¸æ˜¯åŽ»æ£é¼“æ˜ å°„ã€‚åœ¨è¿™ç§æƒ…å†µä¸‹ï¼Œè§£æ˜ å°„æ“作å¯èƒ½æ˜¯ä¸€ä¸ªç©ºæ“作。 + +如果CONFIG_MMU没有被设置，那么就ä¸å¯èƒ½æœ‰ä¸´æ—¶æ˜ 射和高内å˜ã€‚在这ç§æƒ…况下，也将使用计算方法。 + + +i386 PAE +======== + +在æŸäº›æƒ…况下，i386 架构将å…è®¸ä½ åœ¨ 32 ä½æœºå™¨ä¸Šå®‰è£…多达 64GiB 的内å˜ã€‚但这有一些åŽæžœ: + +* Linux需è¦ä¸ºç³»ç»Ÿä¸çš„æ¯ä¸ªé¡µé¢å»ºç«‹ä¸€ä¸ªé¡µå¸§ç»“构，而且页帧需è¦é©»åœ¨æ°¸ä¹…æ˜ å°„ä¸ï¼Œè¿™æ„味ç€ï¼š + +* ä½ æœ€å¤šå¯ä»¥æœ‰896M/sizeof(struct page)页帧；由于页结构体是32å—节的，所以最终会有 + 112Gçš„é¡µï¼›ç„¶è€Œï¼Œå†…æ ¸éœ€è¦åœ¨å†…å˜ä¸å˜å‚¨æ›´å¤šçš„页帧...... + +* PAEä½¿ä½ çš„é¡µè¡¨å˜å¤§--这使系统å˜æ…¢ï¼Œå› 为更多的数æ®éœ€è¦åœ¨TLBå¡«å……ç‰æ–¹é¢è¢«è®¿é—®ã€‚一个好处 + 是，PAE有更多的PTEä½ï¼Œå¯ä»¥æä¾›åƒNXå’ŒPATè¿™æ ·çš„é«˜çº§åŠŸèƒ½ã€‚ + +ä¸€èˆ¬çš„å»ºè®®æ˜¯ï¼Œä½ ä¸è¦åœ¨32ä½æœºå™¨ä¸Šä½¿ç”¨è¶…过8GiB的空间--尽管更多的空间å¯èƒ½å¯¹ä½ å’Œä½ çš„å·¥ä½œ +é‡æœ‰ç”¨ï¼Œä½†ä½ å‡ ä¹Žæ˜¯é ä½ è‡ªå·±--ä¸è¦æŒ‡æœ›å†…æ ¸å¼€å‘者真的会很关心事情的进展情况。 diff --git a/Documentation/translations/zh_CN/vm/index.rst b/Documentation/translations/zh_CN/vm/index.rst new file mode 100644 index 000000000000..a1d2f0356cc1 --- /dev/null +++ b/Documentation/translations/zh_CN/vm/index.rst @@ -0,0 +1,53 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/index.rst + +:翻译: + + å¸å»¶è…¾ Yanteng Si <siyanteng@loongson.cn> + +:æ ¡è¯‘: + +================= +Linux内å˜ç®¡ç†æ–‡æ¡£ +================= + +这是一个关于Linux内å˜ç®¡ç†ï¼ˆmm）å系统内部的文档集，其ä¸æœ‰ä¸åŒå±‚次的细节，包括注释 +和邮件列表的回å¤ï¼Œç”¨äºŽé˜è¿°æ•°æ®ç»“æž„å’Œç®—æ³•çš„åŸºæœ¬æƒ…å†µã€‚å¦‚æžœä½ æ£åœ¨å¯»æ‰¾å…³äºŽç®€å•åˆ†é…内å˜çš„建 +议，请å‚阅(Documentation/translations/zh_CN/core-api/memory-allocation.rst)。 +对于控制和调整指å—，请å‚阅(Documentation/admin-guide/mm/index)。 +TODO:待引用文档集被翻译完毕åŽè¯·åŠæ—¶ä¿®æ”¹æ¤å¤„） + +.. toctree:: + :maxdepth: 1 + + active_mm + balance + damon/index + free_page_reporting + highmem + ksm + +TODOLIST: +* arch_pgtable_helpers +* free_page_reporting +* frontswap +* hmm +* hwpoison +* hugetlbfs_reserv +* memory-model +* mmu_notifier +* numa +* overcommit-accounting +* page_migration +* page_frags +* page_owner +* page_table_check +* remap_file_pages +* slub +* split_page_table_lock +* transhuge +* unevictable-lru +* vmalloced-kernel-stacks +* z3fold +* zsmalloc diff --git a/Documentation/translations/zh_CN/vm/ksm.rst b/Documentation/translations/zh_CN/vm/ksm.rst new file mode 100644 index 000000000000..83b0c73984da --- /dev/null +++ b/Documentation/translations/zh_CN/vm/ksm.rst @@ -0,0 +1,70 @@ +.. include:: ../disclaimer-zh_CN.rst + +:Original: Documentation/vm/ksm.rst + +:翻译: + + å¾é‘« xu xin <xu.xin16@zte.com.cn> + +============ +å†…æ ¸åŒé¡µåˆå¹¶ +============ + +KSM 是一ç§èŠ‚çœå†…å˜çš„æ•°æ®åŽ»é‡åŠŸèƒ½ï¼Œç”±CONFIG_KSM=yå¯ç”¨ï¼Œå¹¶åœ¨2.6.32ç‰ˆæœ¬æ—¶è¢«æ·»åŠ +到Linuxå†…æ ¸ã€‚è¯¦è§ ``mm/ksm.c`` 的实现，以åŠhttp://lwn.net/Articles/306704å’Œ +https://lwn.net/Articles/330589 + +KSM的用户空间的接å£åœ¨Documentation/translations/zh_CN/admin-guide/mm/ksm.rst +文档ä¸æœ‰æ述。 + +设计 +==== + +概述 +---- + +概述内容请è§mm/ksm.c文档ä¸çš„“DOC: Overview†+ +é€†æ˜ å°„ +------ +KSM维护ç€ç¨³å®šæ ‘ä¸çš„KSMé¡µçš„é€†æ˜ å°„ä¿¡æ¯ã€‚ + +当KSM页é¢çš„共享数å°äºŽ ``max_page_sharing`` 的虚拟内å˜åŒºåŸŸ(VMAs)时，则代表了 +KSMé¡µçš„ç¨³å®šæ ‘å…¶ä¸çš„节点指å‘了一个rmap_item结构体类型的列表。åŒæ—¶ï¼Œè¿™ä¸ªKSM页 +çš„ ``page->mapping`` 指å‘äº†è¯¥ç¨³å®šæ ‘èŠ‚ç‚¹ã€‚ + +如果共享数超过了阈值，KSMå°†ç»™ç¨³å®šæ ‘æ·»åŠ ç¬¬äºŒä¸ªç»´åº¦ã€‚ç¨³å®šæ ‘å°±å˜æˆé“¾æŽ¥ä¸€ä¸ªæˆ–多 +ä¸ªç¨³å®šæ ‘"副本"çš„"链"。æ¯ä¸ªå‰¯æœ¬éƒ½ä¿ç•™KSMé¡µçš„é€†æ˜ å°„ä¿¡æ¯ï¼Œå…¶ä¸ ``page->mapping`` +指å‘该"副本"。 + +æ¯ä¸ªé“¾ä»¥åŠé“¾æŽ¥åˆ°è¯¥é“¾ä¸çš„所有"副本"强制ä¸å˜çš„是，它们代表了相åŒçš„写ä¿æŠ¤å†…å˜ +内容，尽管任ä¸ä¸€ä¸ª"副本"是由åŒä¸€ç‰‡å†…å˜åŒºçš„ä¸åŒçš„KSMå¤åˆ¶é¡µæ‰€æŒ‡å‘的。 + +è¿™æ ·ä¸€æ¥ï¼Œç›¸æ¯”ä¸Žæ— é™çš„é€†æ˜ å°„é“¾è¡¨ï¼Œç¨³å®šæ ‘çš„æŸ¥æ‰¾è®¡ç®—å¤æ‚性ä¸å—å½±å“ã€‚ä½†åœ¨ç¨³å®šæ ‘ +本身ä¸ä¸èƒ½æœ‰é‡å¤çš„KSM页é¢å†…容ä»ç„¶æ˜¯å¼ºåˆ¶è¦æ±‚。 + +ç”± ``max_page_sharing`` 强制决定的数æ®åŽ»é‡é™åˆ¶æ˜¯å¿…è¦çš„，以æ¤æ¥é¿å…è™šæ‹Ÿå†…å˜ +rmap链表å˜å¾—过大。rmapçš„é历具有O(N)çš„å¤æ‚度，其ä¸N是共享页é¢çš„rmap_é¡¹ï¼ˆå³ +è™šæ‹Ÿæ˜ å°„ï¼‰çš„æ•°é‡ï¼Œè€Œè¿™ä¸ªå…±äº«é¡µé¢çš„节点数é‡åˆè¢« ``max_page_sharing`` 所é™åˆ¶ã€‚ +å› æ¤ï¼Œè¿™æœ‰æ•ˆåœ°å°†çº¿æ€§O(N)计算å¤æ‚度从rmapé历ä¸åˆ†æ•£åˆ°ä¸åŒçš„KSM页é¢ä¸Šã€‚ksmdè¿› +程在稳定节点"链"上的é历也是O(N)，但这个Næ˜¯ç¨³å®šæ ‘"副本"çš„æ•°é‡ï¼Œè€Œä¸æ˜¯rmap项 +çš„æ•°é‡ï¼Œå› æ¤å®ƒå¯¹ksmd性能没有显著影å“ã€‚å®žé™…ä¸Šï¼Œæœ€ä½³ç¨³å®šæ ‘"副本"的候选节点将 +ä¿ç•™åœ¨"副本"列表的开头。 + +``max_page_sharing`` 的值设置得高了会促使更快的内å˜åˆå¹¶ï¼ˆå› 为将有更少的稳定 +æ ‘å‰¯æœ¬æŽ’é˜Ÿè¿›å…¥ç¨³å®šèŠ‚ç‚¹chain->hlist）和更高的数æ®åŽ»é‡ç³»æ•°ï¼Œä½†ä»£ä»·æ˜¯åœ¨äº¤æ¢ã€åŽ‹ +缩ã€NUMA平衡和页é¢è¿ç§»è¿‡ç¨‹ä¸å¯èƒ½å¯¼è‡´KSM页的最大rmapé历速度较慢。 + +``stable_node_dups/stable_node_chains`` çš„æ¯”å€¼è¿˜å— ``max_page_sharing`` 调控 +çš„å½±å“，高比值å¯èƒ½æ„味ç€ç¨³å®šèŠ‚点dupä¸å˜åœ¨ç¢Žç‰‡ï¼Œè¿™å¯ä»¥é€šè¿‡åœ¨ksmdä¸å¼•å…¥ç¢Žç‰‡ç®— +法æ¥è§£å†³ï¼Œè¯¥ç®—法将rmap项从一个稳定节点dupé‡å®šä½åˆ°å¦ä¸€ä¸ªç¨³å®šèŠ‚点dup，以便释放 +那些仅包å«æžå°‘rmap项的稳定节点"dup"，但这å¯èƒ½ä¼šå¢žåŠ ksmd进程的CPUä½¿ç”¨çŽ‡ï¼Œå¹¶å¯ +能会å‡æ…¢åº”用程åºåœ¨KSM页é¢ä¸Šçš„åªè¯»è®¡ç®—。 + +KSM会定期扫æ稳定节点"链"ä¸é“¾æŽ¥çš„æ‰€æœ‰ç¨³å®šæ ‘"副本"ï¼Œä»¥ä¾¿åˆ å‡è¿‡æ—¶äº†çš„稳定节点。 +è¿™ç§æ‰«æ的频率由 ``stable_node_chains_prune_millisecs`` 这个sysfs 接å£å®šä¹‰ã€‚ + +å‚考 +==== +å†…æ ¸ä»£ç 请è§mm/ksm.c。 +涉åŠçš„函数(mm_slot ksm_scan stable_node rmap_item)。 diff --git a/Documentation/translations/zh_TW/index.rst b/Documentation/translations/zh_TW/index.rst index f56f78ba7860..e1ce9d8c06f8 100644 --- a/Documentation/translations/zh_TW/index.rst +++ b/Documentation/translations/zh_TW/index.rst @@ -5,7 +5,7 @@ \renewcommand\thesection* \renewcommand\thesubsection* \kerneldocCJKon - \kerneldocBeginTC + \kerneldocBeginTC{ .. _linux_doc_zh_tw: @@ -174,4 +174,4 @@ TODOList: .. raw:: latex - \kerneldocEndTC + }\kerneldocEndTC diff --git a/Documentation/translations/zh_TW/process/programming-language.rst b/Documentation/translations/zh_TW/process/programming-language.rst index 54e3699eadf8..144bdaf81a41 100644 --- a/Documentation/translations/zh_TW/process/programming-language.rst +++ b/Documentation/translations/zh_TW/process/programming-language.rst @@ -12,8 +12,7 @@ ============ å…§æ ¸æ˜¯ç”¨C語言 :ref:`c-language <tw_c-language>` ç·¨å¯«çš„ã€‚æ›´æº–ç¢ºåœ°èªªï¼Œå…§æ ¸é€šå¸¸æ˜¯ç”¨ :ref:`gcc <tw_gcc>` -在 ``-std=gnu89`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編è¯çš„：ISO C90çš„ GNU 方言（ -包括一些C99特性） +在 ``-std=gnu11`` :ref:`gcc-c-dialect-options <tw_gcc-c-dialect-options>` 下編è¯çš„：ISO C11çš„ GNU 方言 這種方言包å«å°èªžè¨€ :ref:`gnu-extensions <tw_gnu-extensions>` çš„è¨±å¤šæ“´å±•ï¼Œç•¶ç„¶ï¼Œå®ƒå€‘è¨±å¤šéƒ½åœ¨å…§æ ¸ä¸ä½¿ç”¨ã€‚ diff --git a/Documentation/usb/gadget-testing.rst b/Documentation/usb/gadget-testing.rst index cbbd948c626f..c6d034abce3a 100644 --- a/Documentation/usb/gadget-testing.rst +++ b/Documentation/usb/gadget-testing.rst @@ -726,7 +726,7 @@ The uac2 function provides these attributes in its function directory: ================ ==================================================== c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_sync capture synchronization type (async/adaptive) c_mute_present capture mute control enable @@ -734,17 +734,20 @@ The uac2 function provides these attributes in its function directory: c_volume_min capture volume control min value (in 1/256 dB) c_volume_max capture volume control max value (in 1/256 dB) c_volume_res capture volume control resolution (in 1/256 dB) + c_hs_bint capture bInterval for HS/SS (1-4: fixed, 0: auto) fb_max maximum extra bandwidth in async mode p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable p_volume_min playback volume control min value (in 1/256 dB) p_volume_max playback volume control max value (in 1/256 dB) p_volume_res playback volume control resolution (in 1/256 dB) + p_hs_bint playback bInterval for HS/SS (1-4: fixed, 0: auto) req_number the number of pre-allocated request for both capture and playback + function_name name of the interface ================ ==================================================== The attributes have sane default values. @@ -916,7 +919,7 @@ The uac1 function provides these attributes in its function directory: ================ ==================================================== c_chmask capture channel mask - c_srate capture sampling rate + c_srate list of capture sampling rates (comma-separated) c_ssize capture sample size (bytes) c_mute_present capture mute control enable c_volume_present capture volume control enable @@ -924,7 +927,7 @@ The uac1 function provides these attributes in its function directory: c_volume_max capture volume control max value (in 1/256 dB) c_volume_res capture volume control resolution (in 1/256 dB) p_chmask playback channel mask - p_srate playback sampling rate + p_srate list of playback sampling rates (comma-separated) p_ssize playback sample size (bytes) p_mute_present playback mute control enable p_volume_present playback volume control enable @@ -933,6 +936,7 @@ The uac1 function provides these attributes in its function directory: p_volume_res playback volume control resolution (in 1/256 dB) req_number the number of pre-allocated requests for both capture and playback + function_name name of the interface ================ ==================================================== The attributes have sane default values. diff --git a/Documentation/userspace-api/ioctl/ioctl-number.rst b/Documentation/userspace-api/ioctl/ioctl-number.rst index 687efcf245c1..fcab013e47c9 100644 --- a/Documentation/userspace-api/ioctl/ioctl-number.rst +++ b/Documentation/userspace-api/ioctl/ioctl-number.rst @@ -115,6 +115,7 @@ Code Seq# Include File Comments 'B' 00-1F linux/cciss_ioctl.h conflict! 'B' 00-0F include/linux/pmu.h conflict! 'B' C0-FF advanced bbus <mailto:maassen@uni-freiburg.de> +'B' 00-0F xen/xenbus_dev.h conflict! 'C' all linux/soundcard.h conflict! 'C' 01-2F linux/capi.h conflict! 'C' F0-FF drivers/net/wan/cosa.h conflict! @@ -134,6 +135,7 @@ Code Seq# Include File Comments 'F' 80-8F linux/arcfb.h conflict! 'F' DD video/sstfb.h conflict! 'G' 00-3F drivers/misc/sgi-gru/grulib.h conflict! +'G' 00-0F xen/gntalloc.h, xen/gntdev.h conflict! 'H' 00-7F linux/hiddev.h conflict! 'H' 00-0F linux/hidraw.h conflict! 'H' 01 linux/mei.h conflict! @@ -176,6 +178,7 @@ Code Seq# Include File Comments 'P' 60-6F sound/sscape_ioctl.h conflict! 'P' 00-0F drivers/usb/class/usblp.c conflict! 'P' 01-09 drivers/misc/pci_endpoint_test.c conflict! +'P' 00-0F xen/privcmd.h conflict! 'Q' all linux/soundcard.h 'R' 00-1F linux/random.h conflict! 'R' 01 linux/rfkill.h conflict! @@ -253,7 +256,7 @@ Code Seq# Include File Comments 'l' 00-3F linux/tcfs_fs.h transparent cryptographic file system <http://web.archive.org/web/%2A/http://mikonos.dia.unisa.it/tcfs> 'l' 40-7F linux/udf_fs_i.h in development: - <http://sourceforge.net/projects/linux-udf/> + <https://github.com/pali/udftools> 'm' 00-09 linux/mmtimer.h conflict! 'm' all linux/mtio.h conflict! 'm' all linux/soundcard.h conflict! @@ -372,6 +375,8 @@ Code Seq# Include File Comments <mailto:thomas@winischhofer.net> 0xF6 all LTTng Linux Trace Toolkit Next Generation <mailto:mathieu.desnoyers@efficios.com> +0xF8 all arch/x86/include/uapi/asm/amd_hsmp.h AMD HSMP EPYC system management interface driver + <mailto:nchatrad@amd.com> 0xFD all linux/dm-ioctl.h 0xFE all linux/isst_if.h ==== ===== ======================================================= ================================================================ diff --git a/Documentation/userspace-api/media/lirc.h.rst.exceptions b/Documentation/userspace-api/media/lirc.h.rst.exceptions index ec86e82d026d..913d17b49831 100644 --- a/Documentation/userspace-api/media/lirc.h.rst.exceptions +++ b/Documentation/userspace-api/media/lirc.h.rst.exceptions @@ -11,12 +11,14 @@ ignore define LIRC_SPACE ignore define LIRC_PULSE ignore define LIRC_FREQUENCY ignore define LIRC_TIMEOUT +ignore define LIRC_OVERFLOW ignore define LIRC_VALUE ignore define LIRC_MODE2 ignore define LIRC_IS_SPACE ignore define LIRC_IS_PULSE ignore define LIRC_IS_FREQUENCY ignore define LIRC_IS_TIMEOUT +ignore define LIRC_IS_OVERFLOW ignore define LIRC_MODE2SEND ignore define LIRC_SEND2MODE @@ -28,7 +30,6 @@ ignore define LIRC_CAN_REC ignore define LIRC_CAN_SEND_MASK ignore define LIRC_CAN_REC_MASK -ignore define LIRC_CAN_SET_REC_DUTY_CYCLE # Obsolete ioctls @@ -75,6 +76,7 @@ ignore define PULSE_MASK ignore define LIRC_MODE2_SPACE ignore define LIRC_MODE2_PULSE ignore define LIRC_MODE2_TIMEOUT +ignore define LIRC_MODE2_OVERFLOW ignore define LIRC_VALUE_MASK ignore define LIRC_MODE2_MASK diff --git a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst index 9a5e5f0aae11..d899331b943f 100644 --- a/Documentation/userspace-api/media/rc/lirc-dev-intro.rst +++ b/Documentation/userspace-api/media/rc/lirc-dev-intro.rst @@ -103,11 +103,11 @@ on the following table. ``LIRC_MODE2_PULSE`` - Signifies the presence of IR in microseconds. + Signifies the presence of IR in microseconds, also known as *flash*. ``LIRC_MODE2_SPACE`` - Signifies absence of IR in microseconds. + Signifies absence of IR in microseconds, also known as *gap*. ``LIRC_MODE2_FREQUENCY`` @@ -121,6 +121,13 @@ on the following table. to no IR being detected, this packet will be sent, with the number of microseconds with no IR. + ``LIRC_MODE2_OVERFLOW`` + + Signifies that the IR receiver encounter an overflow, and some IR + is missing. The IR data after this should be correct again. The + actual value is not important, but this is set to 0xffffff by the + kernel for compatibility with lircd. + .. _lirc-mode-pulse: ``LIRC_MODE_PULSE`` diff --git a/Documentation/userspace-api/media/rc/lirc-get-features.rst b/Documentation/userspace-api/media/rc/lirc-get-features.rst index 4bf25860f932..545137620ead 100644 --- a/Documentation/userspace-api/media/rc/lirc-get-features.rst +++ b/Documentation/userspace-api/media/rc/lirc-get-features.rst @@ -102,12 +102,6 @@ LIRC features The driver supports setting the receive carrier frequency using :ref:`ioctl LIRC_SET_REC_CARRIER <LIRC_SET_REC_CARRIER>`. -.. _LIRC-CAN-SET-REC-DUTY-CYCLE-RANGE: - -``LIRC_CAN_SET_REC_DUTY_CYCLE_RANGE`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-SET-REC-CARRIER-RANGE: ``LIRC_CAN_SET_REC_CARRIER_RANGE`` @@ -129,12 +123,6 @@ LIRC features The driver supports :ref:`ioctl LIRC_SET_REC_TIMEOUT <LIRC_SET_REC_TIMEOUT>`. -.. _LIRC-CAN-SET-REC-FILTER: - -``LIRC_CAN_SET_REC_FILTER`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-MEASURE-CARRIER: ``LIRC_CAN_MEASURE_CARRIER`` @@ -149,12 +137,6 @@ LIRC features The driver supports learning mode using :ref:`ioctl LIRC_SET_WIDEBAND_RECEIVER <LIRC_SET_WIDEBAND_RECEIVER>`. -.. _LIRC-CAN-NOTIFY-DECODE: - -``LIRC_CAN_NOTIFY_DECODE`` - - Unused. Kept just to avoid breaking uAPI. - .. _LIRC-CAN-SEND-RAW: ``LIRC_CAN_SEND_RAW`` diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst index cc080c4257d0..6541e4c32b26 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec-stateless.rst @@ -616,6 +616,12 @@ Stateless Codec Control ID * - ``V4L2_H264_DECODE_PARAM_FLAG_BOTTOM_FIELD`` - 0x00000004 - + * - ``V4L2_H264_DECODE_PARAM_FLAG_PFRAME`` + - 0x00000008 + - + * - ``V4L2_H264_DECODE_PARAM_FLAG_BFRAME`` + - 0x00000010 + - .. raw:: latex @@ -1692,7 +1698,12 @@ See section '7.3.1 Tx mode semantics' of the :ref:`vp9` specification for more d * - __u8 - ``reference_mode`` - Specifies the type of inter prediction to be used. See - :ref:`Reference Mode<vp9_reference_mode>` for more details. + :ref:`Reference Mode<vp9_reference_mode>` for more details. Note that + this is derived as part of the compressed header parsing process and + for this reason should have been part of + :c:type: `v4l2_ctrl_vp9_compressed_hdr` optional control. It is safe to + set this value to zero if the driver does not require compressed + headers. * - __u8 - ``reserved[7]`` - Applications and drivers must set this to zero. diff --git a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst index e141f0e4eec9..4cd7c541fc30 100644 --- a/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst +++ b/Documentation/userspace-api/media/v4l/ext-ctrls-codec.rst @@ -3166,11 +3166,11 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - :c:func:`v4l2_timeval_to_ns()` function to convert the struct :c:type:`timeval` in struct :c:type:`v4l2_buffer` to a __u64. * - __u8 - - ``rps`` - - The reference set for the reference frame - (V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_BEFORE, - V4L2_HEVC_DPB_ENTRY_RPS_ST_CURR_AFTER or - V4L2_HEVC_DPB_ENTRY_RPS_LT_CURR) + - ``flags`` + - Long term flag for the reference frame + (V4L2_HEVC_DPB_ENTRY_LONG_TERM_REFERENCE). The flag is set as + described in the ITU HEVC specification chapter "8.3.2 Decoding + process for reference picture set". * - __u8 - ``field_pic`` - Whether the reference is a field picture or a frame. @@ -3383,15 +3383,15 @@ enum v4l2_mpeg_video_hevc_size_of_length_field - * - __u8 - ``poc_st_curr_before[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocStCurrBefore as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the short term before references in DPB array. * - __u8 - ``poc_st_curr_after[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocStCurrAfter as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the short term after references in DPB array. * - __u8 - ``poc_lt_curr[V4L2_HEVC_DPB_ENTRIES_NUM_MAX]`` - PocLtCurr as described in section 8.3.2 "Decoding process for reference - picture set. + picture set": provides the index of the long term references in DPB array. * - __u64 - ``flags`` - See :ref:`Decode Parameters Flags <hevc_decode_params_flags>` diff --git a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst index 2f2133b4cd9c..cabfa34b7db5 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-reserved.rst @@ -233,19 +233,12 @@ please make a proposal on the linux-media mailing list. - ``V4L2_PIX_FMT_MT21C`` - 'MT21' - - Compressed two-planar YVU420 format used by Mediatek MT8173. - The compression is lossless. - It is an opaque intermediate format and the MDP hardware must be + - Compressed two-planar YVU420 format used by Mediatek MT8173, MT8192, + MT8195 and more. The compression is lossless. This format have + similitude with ``V4L2_PIX_FMT_MM21`` in term of alignment and tiling. + It remains an opaque intermediate format and the MDP hardware must be used to convert ``V4L2_PIX_FMT_MT21C`` to ``V4L2_PIX_FMT_NV12M``, ``V4L2_PIX_FMT_YUV420M`` or ``V4L2_PIX_FMT_YVU420``. - * .. _V4L2-PIX-FMT-MM21: - - - ``V4L2_PIX_FMT_MM21`` - - 'MM21' - - Non-compressed, tiled two-planar format used by Mediatek MT8183. - This is an opaque intermediate format and the MDP3 hardware can be - used to convert it to other formats. - .. raw:: latex \normalsize diff --git a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst index 48b0f787274c..30f51cd33f99 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-rgb.rst @@ -672,8 +672,8 @@ nomenclature that instead use the order of components as seen in a 24- or - ``V4L2_PIX_FMT_BGR24`` - 'BGR3' - - G\ :sub:`7-0` - B\ :sub:`7-0` + - G\ :sub:`7-0` - R\ :sub:`7-0` - * .. _V4L2-PIX-FMT-RGB24: diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst index 91942c4f0967..8ebd58c3588f 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-luma.rst @@ -75,8 +75,8 @@ are often referred to as greyscale formats. - ``V4L2_PIX_FMT_Y10P`` - 'Y10P' - - Y'\ :sub:`0`\ [7:0] - - Y'\ :sub:`1`\ [9:8] + - Y'\ :sub:`0`\ [9:2] + - Y'\ :sub:`1`\ [9:2] - Y'\ :sub:`2`\ [9:2] - Y'\ :sub:`3`\ [9:2] - Y'\ :sub:`3`\ [1:0] Y'\ :sub:`2`\ [1:0] Y'\ :sub:`1`\ [1:0] Y'\ :sub:`0`\ [1:0] diff --git a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst index 3a09d93d405b..8dff5906639b 100644 --- a/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst +++ b/Documentation/userspace-api/media/v4l/pixfmt-yuv-planar.rst @@ -76,7 +76,7 @@ All components are stored with the same number of bits per component. - 'NV21' - 8 - 4:2:0 - - Cr, Cr + - Cr, Cb - Yes - Linear * - V4L2_PIX_FMT_NV12M @@ -90,7 +90,7 @@ All components are stored with the same number of bits per component. - 'NM21' - 8 - 4:2:0 - - Cr, Cr + - Cr, Cb - No - Linear * - V4L2_PIX_FMT_NV12MT @@ -120,7 +120,7 @@ All components are stored with the same number of bits per component. - 'NV61' - 8 - 4:2:2 - - Cr, Cr + - Cr, Cb - Yes - Linear * - V4L2_PIX_FMT_NV16M @@ -134,7 +134,7 @@ All components are stored with the same number of bits per component. - 'NM61' - 8 - 4:2:2 - - Cr, Cr + - Cr, Cb - No - Linear * - V4L2_PIX_FMT_NV24 @@ -148,7 +148,7 @@ All components are stored with the same number of bits per component. - 'NV42' - 8 - 4:4:4 - - Cr, Cr + - Cr, Cb - Yes - Linear @@ -257,6 +257,9 @@ of the luma plane. .. _V4L2-PIX-FMT-NV12-4L4: .. _V4L2-PIX-FMT-NV12-16L16: .. _V4L2-PIX-FMT-NV12-32L32: +.. _V4L2-PIX-FMT-NV12M-8L128: +.. _V4L2-PIX-FMT-NV12M-10BE-8L128: +.. _V4L2-PIX-FMT-MM21: Tiled NV12 ---------- @@ -281,21 +284,47 @@ If the vertical resolution is an odd number of tiles, the last row of tiles is stored in linear order. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_4L4`` stores pixel in 4x4 tiles, and stores +``V4L2_PIX_FMT_NV12_4L4`` stores pixels in 4x4 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 4. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_16L16`` stores pixel in 16x16 tiles, and stores +``V4L2_PIX_FMT_NV12_16L16`` stores pixels in 16x16 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 16. The layouts of the luma and chroma planes are identical. -``V4L2_PIX_FMT_NV12_32L32`` stores pixel in 32x32 tiles, and stores +``V4L2_PIX_FMT_NV12_32L32`` stores pixels in 32x32 tiles, and stores tiles linearly in memory. The line stride and image height must be aligned to a multiple of 32. The layouts of the luma and chroma planes are identical. +``V4L2_PIX_FMT_NV12M_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +pixels in 2D 8x128 tiles, and stores tiles linearly in memory. +The image height must be aligned to a multiple of 128. +The layouts of the luma and chroma planes are identical. + +``V4L2_PIX_FMT_NV12M_10BE_8L128`` is similar to ``V4L2_PIX_FMT_NV12M`` but stores +10 bits pixels in 2D 8x128 tiles, and stores tiles linearly in memory. +the data is arranged in big endian order. +The image height must be aligned to a multiple of 128. +The layouts of the luma and chroma planes are identical. +Note the tile size is 8bytes multiplied by 128 bytes, +it means that the low bits and high bits of one pixel may be in different tiles. +The 10 bit pixels are packed, so 5 bytes contain 4 10-bit pixels layout like +this (for luma): +byte 0: Y0(bits 9-2) +byte 1: Y0(bits 1-0) Y1(bits 9-4) +byte 2: Y1(bits 3-0) Y2(bits 9-6) +byte 3: Y2(bits 5-0) Y3(bits 9-8) +byte 4: Y3(bits 7-0) + +``V4L2_PIX_FMT_MM21`` store luma pixel in 16x32 tiles, and chroma pixels +in 16x16 tiles. The line stride must be aligned to a multiple of 16 and the +image height must be aligned to a multiple of 32. The number of luma and chroma +tiles are identical, even though the tile size differ. The image is formed of +two non-contiguous planes. + .. _nv12mt: .. kernel-figure:: nv12mt.svg diff --git a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst index b38f661da733..1a55e3617ea8 100644 --- a/Documentation/userspace-api/media/v4l/v4l2grab.c.rst +++ b/Documentation/userspace-api/media/v4l/v4l2grab.c.rst @@ -134,7 +134,7 @@ file: media/v4l/v4l2grab.c tv.tv_usec = 0; r = select(fd + 1, &fds, NULL, NULL, &tv); - } while ((r == -1 && (errno = EINTR))); + } while ((r == -1 && (errno == EINTR))); if (r == -1) { perror("select"); return errno; diff --git a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst index 77e0747a6d28..e4b3d9beb9ab 100644 --- a/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst +++ b/Documentation/userspace-api/media/v4l/vidioc-qbuf.rst @@ -125,7 +125,7 @@ Applications call the ``VIDIOC_DQBUF`` ioctl to dequeue a filled queue. They just set the ``type``, ``memory`` and ``reserved`` fields of a struct :c:type:`v4l2_buffer` as above, when ``VIDIOC_DQBUF`` is called with a pointer to this structure the driver -fills the remaining fields or returns an error code. The driver may also +fills all remaining fields or returns an error code. The driver may also set ``V4L2_BUF_FLAG_ERROR`` in the ``flags`` field. It indicates a non-critical (recoverable) streaming error. In such case the application may continue as normal, but should be aware that data in the dequeued diff --git a/Documentation/virt/kvm/api.rst b/Documentation/virt/kvm/api.rst index bb8cfddbb22d..d13fa6600467 100644 --- a/Documentation/virt/kvm/api.rst +++ b/Documentation/virt/kvm/api.rst @@ -151,12 +151,6 @@ In order to create user controlled virtual machines on S390, check KVM_CAP_S390_UCONTROL and use the flag KVM_VM_S390_UCONTROL as privileged user (CAP_SYS_ADMIN). -To use hardware assisted virtualization on MIPS (VZ ASE) rather than -the default trap & emulate implementation (which changes the virtual -memory layout to fit in user mode), check KVM_CAP_MIPS_VZ and use the -flag KVM_VM_MIPS_VZ. - - On arm64, the physical address size for a VM (IPA Size limit) is limited to 40bits by default. The limit can be configured if the host supports the extension KVM_CAP_ARM_VM_IPA_SIZE. When supported, use @@ -417,7 +411,7 @@ kvm_run' (see below). ----------------- :Capability: basic -:Architectures: all except ARM, arm64 +:Architectures: all except arm64 :Type: vcpu ioctl :Parameters: struct kvm_regs (out) :Returns: 0 on success, -1 on error @@ -450,7 +444,7 @@ Reads the general purpose registers from the vcpu. ----------------- :Capability: basic -:Architectures: all except ARM, arm64 +:Architectures: all except arm64 :Type: vcpu ioctl :Parameters: struct kvm_regs (in) :Returns: 0 on success, -1 on error @@ -824,7 +818,7 @@ Writes the floating point state to the vcpu. ----------------------- :Capability: KVM_CAP_IRQCHIP, KVM_CAP_S390_IRQCHIP (s390) -:Architectures: x86, ARM, arm64, s390 +:Architectures: x86, arm64, s390 :Type: vm ioctl :Parameters: none :Returns: 0 on success, -1 on error @@ -833,7 +827,7 @@ Creates an interrupt controller model in the kernel. On x86, creates a virtual ioapic, a virtual PIC (two PICs, nested), and sets up future vcpus to have a local APIC. IRQ routing for GSIs 0-15 is set to both PIC and IOAPIC; GSI 16-23 only go to the IOAPIC. -On ARM/arm64, a GICv2 is created. Any other GIC versions require the usage of +On arm64, a GICv2 is created. Any other GIC versions require the usage of KVM_CREATE_DEVICE, which also supports creating a GICv2. Using KVM_CREATE_DEVICE is preferred over KVM_CREATE_IRQCHIP for GICv2. On s390, a dummy irq routing table is created. @@ -846,7 +840,7 @@ before KVM_CREATE_IRQCHIP can be used. ----------------- :Capability: KVM_CAP_IRQCHIP -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vm ioctl :Parameters: struct kvm_irq_level :Returns: 0 on success, -1 on error @@ -870,7 +864,7 @@ capability is present (or unless it is not using the in-kernel irqchip, of course). -ARM/arm64 can signal an interrupt either at the CPU level, or at the +arm64 can signal an interrupt either at the CPU level, or at the in-kernel irqchip (GIC), and for in-kernel irqchip can tell the GIC to use PPIs designated for specific cpus. The irq field is interpreted like this:: @@ -896,7 +890,7 @@ When KVM_CAP_ARM_IRQ_LINE_LAYOUT_2 is supported, the target vcpu is identified as (256 * vcpu2_index + vcpu_index). Otherwise, vcpu2_index must be zero. -Note that on arm/arm64, the KVM_CAP_IRQCHIP capability only conditions +Note that on arm64, the KVM_CAP_IRQCHIP capability only conditions injection of interrupts for the in-kernel irqchip. KVM_IRQ_LINE can always be used for a userspace interrupt controller. @@ -1087,7 +1081,7 @@ Other flags returned by ``KVM_GET_CLOCK`` are accepted but ignored. :Capability: KVM_CAP_VCPU_EVENTS :Extended by: KVM_CAP_INTR_SHADOW -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_event (out) :Returns: 0 on success, -1 on error @@ -1146,8 +1140,8 @@ The following bits are defined in the flags field: fields contain a valid state. This bit will be set whenever KVM_CAP_EXCEPTION_PAYLOAD is enabled. -ARM/ARM64: -^^^^^^^^^^ +ARM64: +^^^^^^ If the guest accesses a device that is being emulated by the host kernel in such a way that a real device would generate a physical SError, KVM may make @@ -1206,7 +1200,7 @@ directly to the virtual CPU). :Capability: KVM_CAP_VCPU_EVENTS :Extended by: KVM_CAP_INTR_SHADOW -:Architectures: x86, arm, arm64 +:Architectures: x86, arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_event (in) :Returns: 0 on success, -1 on error @@ -1241,8 +1235,8 @@ can be set in the flags field to signal that the exception_has_payload, exception_payload, and exception.pending fields contain a valid state and shall be written into the VCPU. -ARM/ARM64: -^^^^^^^^^^ +ARM64: +^^^^^^ User space may need to inject several types of events to the guest. @@ -1394,7 +1388,7 @@ documentation when it pops into existence). ------------------- :Capability: KVM_CAP_ENABLE_CAP -:Architectures: mips, ppc, s390 +:Architectures: mips, ppc, s390, x86 :Type: vcpu ioctl :Parameters: struct kvm_enable_cap (in) :Returns: 0 on success; -1 on error @@ -1449,7 +1443,7 @@ for vm-wide capabilities. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64, riscv +:Architectures: x86, s390, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (out) :Returns: 0 on success; -1 on error @@ -1467,7 +1461,7 @@ Possible values are: ========================== =============================================== KVM_MP_STATE_RUNNABLE the vcpu is currently running - [x86,arm/arm64,riscv] + [x86,arm64,riscv] KVM_MP_STATE_UNINITIALIZED the vcpu is an application processor (AP) which has not yet received an INIT signal [x86] KVM_MP_STATE_INIT_RECEIVED the vcpu has received an INIT signal, and is @@ -1476,7 +1470,7 @@ Possible values are: is waiting for an interrupt [x86] KVM_MP_STATE_SIPI_RECEIVED the vcpu has just received a SIPI (vector accessible via KVM_GET_VCPU_EVENTS) [x86] - KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm/arm64,riscv] + KVM_MP_STATE_STOPPED the vcpu is stopped [s390,arm64,riscv] KVM_MP_STATE_CHECK_STOP the vcpu is in a special error state [s390] KVM_MP_STATE_OPERATING the vcpu is operating (running or halted) [s390] @@ -1488,8 +1482,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64/riscv: -^^^^^^^^^^^^^^^^^^^^ +For arm64/riscv: +^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. @@ -1498,7 +1492,7 @@ KVM_MP_STATE_RUNNABLE which reflect if the vcpu is paused or not. --------------------- :Capability: KVM_CAP_MP_STATE -:Architectures: x86, s390, arm, arm64, riscv +:Architectures: x86, s390, arm64, riscv :Type: vcpu ioctl :Parameters: struct kvm_mp_state (in) :Returns: 0 on success; -1 on error @@ -1510,8 +1504,8 @@ On x86, this ioctl is only useful after KVM_CREATE_IRQCHIP. Without an in-kernel irqchip, the multiprocessing state must be maintained by userspace on these architectures. -For arm/arm64/riscv: -^^^^^^^^^^^^^^^^^^^^ +For arm64/riscv: +^^^^^^^^^^^^^^^^ The only states that are valid are KVM_MP_STATE_STOPPED and KVM_MP_STATE_RUNNABLE which reflect if the vcpu should be paused or not. @@ -1780,14 +1774,14 @@ The flags bitmap is defined as:: ------------------------ :Capability: KVM_CAP_IRQ_ROUTING -:Architectures: x86 s390 arm arm64 +:Architectures: x86 s390 arm64 :Type: vm ioctl :Parameters: struct kvm_irq_routing (in) :Returns: 0 on success, -1 on error Sets the GSI routing table entries, overwriting any previously set entries. -On arm/arm64, GSI routing has the following limitation: +On arm64, GSI routing has the following limitation: - GSI routing does not apply to KVM_IRQ_LINE but only to KVM_IRQFD. @@ -2855,7 +2849,7 @@ after pausing the vcpu, but before it is resumed. ------------------- :Capability: KVM_CAP_SIGNAL_MSI -:Architectures: x86 arm arm64 +:Architectures: x86 arm64 :Type: vm ioctl :Parameters: struct kvm_msi (in) :Returns: >0 on delivery, 0 if guest blocked the MSI, and -1 on error @@ -3043,7 +3037,7 @@ into the hash PTE second double word). -------------- :Capability: KVM_CAP_IRQFD -:Architectures: x86 s390 arm arm64 +:Architectures: x86 s390 arm64 :Type: vm ioctl :Parameters: struct kvm_irqfd (in) :Returns: 0 on success, -1 on error @@ -3069,7 +3063,7 @@ Note that closing the resamplefd is not sufficient to disable the irqfd. The KVM_IRQFD_FLAG_RESAMPLE is only necessary on assignment and need not be specified with KVM_IRQFD_FLAG_DEASSIGN. -On arm/arm64, gsi routing being supported, the following can happen: +On arm64, gsi routing being supported, the following can happen: - in case no routing entry is associated to this gsi, injection fails - in case the gsi is associated to an irqchip routing entry, @@ -3268,6 +3262,7 @@ number. :Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device, KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device (no set) :Type: device ioctl, vm ioctl, vcpu ioctl :Parameters: struct kvm_device_attr :Returns: 0 on success, -1 on error @@ -3302,7 +3297,8 @@ transferred is defined by the particular attribute. ------------------------ :Capability: KVM_CAP_DEVICE_CTRL, KVM_CAP_VM_ATTRIBUTES for vm device, - KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_VCPU_ATTRIBUTES for vcpu device + KVM_CAP_SYS_ATTRIBUTES for system (/dev/kvm) device :Type: device ioctl, vm ioctl, vcpu ioctl :Parameters: struct kvm_device_attr :Returns: 0 on success, -1 on error @@ -3323,7 +3319,7 @@ current state. "addr" is ignored. ---------------------- :Capability: basic -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vcpu ioctl :Parameters: struct kvm_vcpu_init (in) :Returns: 0 on success; -1 on error @@ -3421,7 +3417,7 @@ Possible features: ----------------------------- :Capability: basic -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vm ioctl :Parameters: struct kvm_vcpu_init (out) :Returns: 0 on success; -1 on error @@ -3450,7 +3446,7 @@ VCPU matching underlying host. --------------------- :Capability: basic -:Architectures: arm, arm64, mips +:Architectures: arm64, mips :Type: vcpu ioctl :Parameters: struct kvm_reg_list (in/out) :Returns: 0 on success; -1 on error @@ -3477,7 +3473,7 @@ KVM_GET_ONE_REG/KVM_SET_ONE_REG calls. ----------------------------------------- :Capability: KVM_CAP_ARM_SET_DEVICE_ADDR -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vm ioctl :Parameters: struct kvm_arm_device_address (in) :Returns: 0 on success, -1 on error @@ -3504,13 +3500,13 @@ can access emulated or directly exposed devices, which the host kernel needs to know about. The id field is an architecture specific identifier for a specific device. -ARM/arm64 divides the id field into two parts, a device id and an +arm64 divides the id field into two parts, a device id and an address type id specific to the individual device:: bits: | 63 ... 32 | 31 ... 16 | 15 ... 0 | field: | 0x00000000 | device id | addr type id | -ARM/arm64 currently only require this when using the in-kernel GIC +arm64 currently only require this when using the in-kernel GIC support for the hardware VGIC features, using KVM_ARM_DEVICE_VGIC_V2 as the device id. When setting the base address for the guest's mapping of the VGIC virtual CPU and distributor interface, the ioctl @@ -3681,15 +3677,17 @@ The fields in each entry are defined as follows: 4.89 KVM_S390_MEM_OP -------------------- -:Capability: KVM_CAP_S390_MEM_OP +:Capability: KVM_CAP_S390_MEM_OP, KVM_CAP_S390_PROTECTED, KVM_CAP_S390_MEM_OP_EXTENSION :Architectures: s390 -:Type: vcpu ioctl +:Type: vm ioctl, vcpu ioctl :Parameters: struct kvm_s390_mem_op (in) :Returns: = 0 on success, < 0 on generic error (e.g. -EFAULT or -ENOMEM), > 0 if an exception occurred while walking the page tables -Read or write data from/to the logical (virtual) memory of a VCPU. +Read or write data from/to the VM's memory. +The KVM_CAP_S390_MEM_OP_EXTENSION capability specifies what functionality is +supported. Parameters are specified via the following structure:: @@ -3699,33 +3697,99 @@ Parameters are specified via the following structure:: __u32 size; /* amount of bytes */ __u32 op; /* type of operation */ __u64 buf; /* buffer in userspace */ - __u8 ar; /* the access register number */ - __u8 reserved[31]; /* should be set to 0 */ + union { + struct { + __u8 ar; /* the access register number */ + __u8 key; /* access key, ignored if flag unset */ + }; + __u32 sida_offset; /* offset into the sida */ + __u8 reserved[32]; /* ignored */ + }; }; -The type of operation is specified in the "op" field. It is either -KVM_S390_MEMOP_LOGICAL_READ for reading from logical memory space or -KVM_S390_MEMOP_LOGICAL_WRITE for writing to logical memory space. The -KVM_S390_MEMOP_F_CHECK_ONLY flag can be set in the "flags" field to check -whether the corresponding memory access would create an access exception -(without touching the data in the memory at the destination). In case an -access exception occurred while walking the MMU tables of the guest, the -ioctl returns a positive error number to indicate the type of exception. -This exception is also raised directly at the corresponding VCPU if the -flag KVM_S390_MEMOP_F_INJECT_EXCEPTION is set in the "flags" field. - The start address of the memory region has to be specified in the "gaddr" field, and the length of the region in the "size" field (which must not be 0). The maximum value for "size" can be obtained by checking the KVM_CAP_S390_MEM_OP capability. "buf" is the buffer supplied by the userspace application where the read data should be written to for -KVM_S390_MEMOP_LOGICAL_READ, or where the data that should be written is -stored for a KVM_S390_MEMOP_LOGICAL_WRITE. When KVM_S390_MEMOP_F_CHECK_ONLY -is specified, "buf" is unused and can be NULL. "ar" designates the access -register number to be used; the valid range is 0..15. +a read access, or where the data that should be written is stored for +a write access. The "reserved" field is meant for future extensions. +Reserved and unused values are ignored. Future extension that add members must +introduce new flags. + +The type of operation is specified in the "op" field. Flags modifying +their behavior can be set in the "flags" field. Undefined flag bits must +be set to 0. + +Possible operations are: + * ``KVM_S390_MEMOP_LOGICAL_READ`` + * ``KVM_S390_MEMOP_LOGICAL_WRITE`` + * ``KVM_S390_MEMOP_ABSOLUTE_READ`` + * ``KVM_S390_MEMOP_ABSOLUTE_WRITE`` + * ``KVM_S390_MEMOP_SIDA_READ`` + * ``KVM_S390_MEMOP_SIDA_WRITE`` + +Logical read/write: +^^^^^^^^^^^^^^^^^^^ + +Access logical memory, i.e. translate the given guest address to an absolute +address given the state of the VCPU and use the absolute address as target of +the access. "ar" designates the access register number to be used; the valid +range is 0..15. +Logical accesses are permitted for the VCPU ioctl only. +Logical accesses are permitted for non-protected guests only. + +Supported flags: + * ``KVM_S390_MEMOP_F_CHECK_ONLY`` + * ``KVM_S390_MEMOP_F_INJECT_EXCEPTION`` + * ``KVM_S390_MEMOP_F_SKEY_PROTECTION`` + +The KVM_S390_MEMOP_F_CHECK_ONLY flag can be set to check whether the +corresponding memory access would cause an access exception; however, +no actual access to the data in memory at the destination is performed. +In this case, "buf" is unused and can be NULL. + +In case an access exception occurred during the access (or would occur +in case of KVM_S390_MEMOP_F_CHECK_ONLY), the ioctl returns a positive +error number indicating the type of exception. This exception is also +raised directly at the corresponding VCPU if the flag +KVM_S390_MEMOP_F_INJECT_EXCEPTION is set. + +If the KVM_S390_MEMOP_F_SKEY_PROTECTION flag is set, storage key +protection is also in effect and may cause exceptions if accesses are +prohibited given the access key designated by "key"; the valid range is 0..15. +KVM_S390_MEMOP_F_SKEY_PROTECTION is available if KVM_CAP_S390_MEM_OP_EXTENSION +is > 0. + +Absolute read/write: +^^^^^^^^^^^^^^^^^^^^ + +Access absolute memory. This operation is intended to be used with the +KVM_S390_MEMOP_F_SKEY_PROTECTION flag, to allow accessing memory and performing +the checks required for storage key protection as one operation (as opposed to +user space getting the storage keys, performing the checks, and accessing +memory thereafter, which could lead to a delay between check and access). +Absolute accesses are permitted for the VM ioctl if KVM_CAP_S390_MEM_OP_EXTENSION +is > 0. +Currently absolute accesses are not permitted for VCPU ioctls. +Absolute accesses are permitted for non-protected guests only. + +Supported flags: + * ``KVM_S390_MEMOP_F_CHECK_ONLY`` + * ``KVM_S390_MEMOP_F_SKEY_PROTECTION`` + +The semantics of the flags are as for logical accesses. -The "reserved" field is meant for future extensions. It is not used by -KVM with the currently defined set of flags. +SIDA read/write: +^^^^^^^^^^^^^^^^ + +Access the secure instruction data area which contains memory operands necessary +for instruction emulation for protected guests. +SIDA accesses are available if the KVM_CAP_S390_PROTECTED capability is available. +SIDA accesses are permitted for the VCPU ioctl only. +SIDA accesses are permitted for protected guests only. + +No flags are supported. 4.90 KVM_S390_GET_SKEYS ----------------------- @@ -4011,6 +4075,11 @@ x2APIC MSRs are always allowed, independent of the ``default_allow`` setting, and their behavior depends on the ``X2APIC_ENABLE`` bit of the APIC base register. +.. warning:: + MSR accesses coming from nested vmentry/vmexit are not filtered. + This includes both writes to individual VMCS fields and reads/writes + through the MSR lists pointed to by the VMCS. + If a bit is within one of the defined ranges, read and write accesses are guarded by the bitmap's value for the MSR index if the kind of access is included in the ``struct kvm_msr_filter_range`` flags. If no range @@ -4724,7 +4793,7 @@ to I/O ports. ------------------------------------ :Capability: KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 -:Architectures: x86, arm, arm64, mips +:Architectures: x86, arm64, mips :Type: vm ioctl :Parameters: struct kvm_clear_dirty_log (in) :Returns: 0 on success, -1 on error @@ -4836,7 +4905,7 @@ version has the following quirks: 4.119 KVM_ARM_VCPU_FINALIZE --------------------------- -:Architectures: arm, arm64 +:Architectures: arm64 :Type: vcpu ioctl :Parameters: int feature (in) :Returns: 0 on success, -1 on error @@ -5223,6 +5292,10 @@ type values: KVM_XEN_VCPU_ATTR_TYPE_VCPU_INFO Sets the guest physical address of the vcpu_info for a given vCPU. + As with the shared_info page for the VM, the corresponding page may be + dirtied at any time if event channel interrupt delivery is enabled, so + userspace should always assume that the page is dirty without relying + on dirty logging. KVM_XEN_VCPU_ATTR_TYPE_VCPU_TIME_INFO Sets the guest physical address of an additional pvclock structure @@ -5918,7 +5991,7 @@ should put the acknowledged interrupt vector into the 'epr' field. If exit_reason is KVM_EXIT_SYSTEM_EVENT then the vcpu has triggered a system-level event using some architecture specific mechanism (hypercall -or some special instruction). In case of ARM/ARM64, this is triggered using +or some special instruction). In case of ARM64, this is triggered using HVC instruction based PSCI call from the vcpu. The 'type' field describes the system-level event type. The 'flags' field describes architecture specific flags for the system-level event. @@ -5937,6 +6010,11 @@ Valid values for 'type' are: to ignore the request, or to gather VM memory core dump and/or reset/shutdown of the VM. +Valid flags are: + + - KVM_SYSTEM_EVENT_RESET_FLAG_PSCI_RESET2 (arm64 only) -- the guest issued + a SYSTEM_RESET2 call according to v1.1 of the PSCI specification. + :: /* KVM_EXIT_IOAPIC_EOI */ @@ -6011,7 +6089,7 @@ in send_page or recv a buffer to recv_page). __u64 fault_ipa; } arm_nisv; -Used on arm and arm64 systems. If a guest accesses memory not in a memslot, +Used on arm64 systems. If a guest accesses memory not in a memslot, KVM will typically return to userspace and ask it to do MMIO emulation on its behalf. However, for certain classes of instructions, no instruction decode (direction, length of memory access) is provided, and fetching and decoding @@ -6028,11 +6106,10 @@ did not fall within an I/O window. Userspace implementations can query for KVM_CAP_ARM_NISV_TO_USER, and enable this capability at VM creation. Once this is done, these types of errors will instead return to userspace with KVM_EXIT_ARM_NISV, with the valid bits from -the HSR (arm) and ESR_EL2 (arm64) in the esr_iss field, and the faulting IPA -in the fault_ipa field. Userspace can either fix up the access if it's -actually an I/O access by decoding the instruction from guest memory (if it's -very brave) and continue executing the guest, or it can decide to suspend, -dump, or restart the guest. +the ESR_EL2 in the esr_iss field, and the faulting IPA in the fault_ipa field. +Userspace can either fix up the access if it's actually an I/O access by +decoding the instruction from guest memory (if it's very brave) and continue +executing the guest, or it can decide to suspend, dump, or restart the guest. Note that KVM does not skip the faulting instruction as it does for KVM_EXIT_MMIO, but userspace has to emulate any change to the processing state @@ -6739,7 +6816,7 @@ and injected exceptions. 7.18 KVM_CAP_MANUAL_DIRTY_LOG_PROTECT2 -:Architectures: x86, arm, arm64, mips +:Architectures: x86, arm64, mips :Parameters: args[0] whether feature should be enabled or not Valid flags are:: @@ -6995,6 +7072,70 @@ indicated by the fd to the VM this is called on. This is intended to support intra-host migration of VMs between userspace VMMs, upgrading the VMM process without interrupting the guest. +7.30 KVM_CAP_PPC_AIL_MODE_3 +------------------------------- + +:Capability: KVM_CAP_PPC_AIL_MODE_3 +:Architectures: ppc +:Type: vm + +This capability indicates that the kernel supports the mode 3 setting for the +"Address Translation Mode on Interrupt" aka "Alternate Interrupt Location" +resource that is controlled with the H_SET_MODE hypercall. + +This capability allows a guest kernel to use a better-performance mode for +handling interrupts and system calls. + +7.31 KVM_CAP_DISABLE_QUIRKS2 +---------------------------- + +:Capability: KVM_CAP_DISABLE_QUIRKS2 +:Parameters: args[0] - set of KVM quirks to disable +:Architectures: x86 +:Type: vm + +This capability, if enabled, will cause KVM to disable some behavior +quirks. + +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +quirks that can be disabled in KVM. + +The argument to KVM_ENABLE_CAP for this capability is a bitmask of +quirks to disable, and must be a subset of the bitmask returned by +KVM_CHECK_EXTENSION. + +The valid bits in cap.args[0] are: + +=================================== ============================================ + KVM_X86_QUIRK_LINT0_REENABLED By default, the reset value for the LVT + LINT0 register is 0x700 (APIC_MODE_EXTINT). + When this quirk is disabled, the reset value + is 0x10000 (APIC_LVT_MASKED). + + KVM_X86_QUIRK_CD_NW_CLEARED By default, KVM clears CR0.CD and CR0.NW. + When this quirk is disabled, KVM does not + change the value of CR0.CD and CR0.NW. + + KVM_X86_QUIRK_LAPIC_MMIO_HOLE By default, the MMIO LAPIC interface is + available even when configured for x2APIC + mode. When this quirk is disabled, KVM + disables the MMIO LAPIC interface if the + LAPIC is in x2APIC mode. + + KVM_X86_QUIRK_OUT_7E_INC_RIP By default, KVM pre-increments %rip before + exiting to userspace for an OUT instruction + to port 0x7e. When this quirk is disabled, + KVM does not pre-increment %rip before + exiting to userspace. + + KVM_X86_QUIRK_MISC_ENABLE_NO_MWAIT When this quirk is disabled, KVM sets + CPUID.01H:ECX[bit 3] (MONITOR/MWAIT) if + IA32_MISC_ENABLE[bit 18] (MWAIT) is set. + Additionally, when this quirk is disabled, + KVM clears CPUID.01H:ECX[bit 3] if + IA32_MISC_ENABLE[bit 18] is cleared. +=================================== ============================================ + 8. Other capabilities. ====================== @@ -7122,7 +7263,7 @@ reserved. 8.9 KVM_CAP_ARM_USER_IRQ ------------------------ -:Architectures: arm, arm64 +:Architectures: arm64 This capability, if KVM_CHECK_EXTENSION indicates that it is available, means that if userspace creates a VM without an in-kernel interrupt controller, it @@ -7249,7 +7390,7 @@ HvFlushVirtualAddressList, HvFlushVirtualAddressListEx. 8.19 KVM_CAP_ARM_INJECT_SERROR_ESR ---------------------------------- -:Architectures: arm, arm64 +:Architectures: arm64 This capability indicates that userspace can specify (via the KVM_SET_VCPU_EVENTS ioctl) the syndrome value reported to the guest when it @@ -7559,3 +7700,71 @@ The argument to KVM_ENABLE_CAP is also a bitmask, and must be a subset of the result of KVM_CHECK_EXTENSION. KVM will forward to userspace the hypercalls whose corresponding bit is in the argument, and return ENOSYS for the others. + +8.35 KVM_CAP_PMU_CAPABILITY +--------------------------- + +:Capability KVM_CAP_PMU_CAPABILITY +:Architectures: x86 +:Type: vm +:Parameters: arg[0] is bitmask of PMU virtualization capabilities. +:Returns 0 on success, -EINVAL when arg[0] contains invalid bits + +This capability alters PMU virtualization in KVM. + +Calling KVM_CHECK_EXTENSION for this capability returns a bitmask of +PMU virtualization capabilities that can be adjusted on a VM. + +The argument to KVM_ENABLE_CAP is also a bitmask and selects specific +PMU virtualization capabilities to be applied to the VM. This can +only be invoked on a VM prior to the creation of VCPUs. + +At this time, KVM_PMU_CAP_DISABLE is the only capability. Setting +this capability will disable PMU virtualization for that VM. Usermode +should adjust CPUID leaf 0xA to reflect that the PMU is disabled. + +9. Known KVM API problems +========================= + +In some cases, KVM's API has some inconsistencies or common pitfalls +that userspace need to be aware of. This section details some of +these issues. + +Most of them are architecture specific, so the section is split by +architecture. + +9.1. x86 +-------- + +``KVM_GET_SUPPORTED_CPUID`` issues +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +In general, ``KVM_GET_SUPPORTED_CPUID`` is designed so that it is possible +to take its result and pass it directly to ``KVM_SET_CPUID2``. This section +documents some cases in which that requires some care. + +Local APIC features +~~~~~~~~~~~~~~~~~~~ + +CPU[EAX=1]:ECX[21] (X2APIC) is reported by ``KVM_GET_SUPPORTED_CPUID``, +but it can only be enabled if ``KVM_CREATE_IRQCHIP`` or +``KVM_ENABLE_CAP(KVM_CAP_IRQCHIP_SPLIT)`` are used to enable in-kernel emulation of +the local APIC. + +The same is true for the ``KVM_FEATURE_PV_UNHALT`` paravirtualized feature. + +CPU[EAX=1]:ECX[24] (TSC_DEADLINE) is not reported by ``KVM_GET_SUPPORTED_CPUID``. +It can be enabled if ``KVM_CAP_TSC_DEADLINE_TIMER`` is present and the kernel +has enabled in-kernel emulation of the local APIC. + +Obsolete ioctls and capabilities +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +KVM_CAP_DISABLE_QUIRKS does not let userspace know which quirks are actually +available. Use ``KVM_CHECK_EXTENSION(KVM_CAP_DISABLE_QUIRKS2)`` instead if +available. + +Ordering of KVM_GET_*/KVM_SET_* ioctls +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +TBD diff --git a/Documentation/virt/kvm/devices/vcpu.rst b/Documentation/virt/kvm/devices/vcpu.rst index 60a29972d3f1..716aa3edae14 100644 --- a/Documentation/virt/kvm/devices/vcpu.rst +++ b/Documentation/virt/kvm/devices/vcpu.rst @@ -70,7 +70,7 @@ irqchip. -ENODEV PMUv3 not supported or GIC not initialized -ENXIO PMUv3 not properly configured or in-kernel irqchip not configured as required prior to calling this attribute - -EBUSY PMUv3 already initialized + -EBUSY PMUv3 already initialized or a VCPU has already run -EINVAL Invalid filter range ======= ====================================================== @@ -104,11 +104,43 @@ hardware event. Filtering event 0x1E (CHAIN) has no effect either, as it isn't strictly speaking an event. Filtering the cycle counter is possible using event 0x11 (CPU_CYCLES). +1.4 ATTRIBUTE: KVM_ARM_VCPU_PMU_V3_SET_PMU +------------------------------------------ + +:Parameters: in kvm_device_attr.addr the address to an int representing the PMU + identifier. + +:Returns: + + ======= ==================================================== + -EBUSY PMUv3 already initialized, a VCPU has already run or + an event filter has already been set + -EFAULT Error accessing the PMU identifier + -ENXIO PMU not found + -ENODEV PMUv3 not supported or GIC not initialized + -ENOMEM Could not allocate memory + ======= ==================================================== + +Request that the VCPU uses the specified hardware PMU when creating guest events +for the purpose of PMU emulation. The PMU identifier can be read from the "type" +file for the desired PMU instance under /sys/devices (or, equivalent, +/sys/bus/even_source). This attribute is particularly useful on heterogeneous +systems where there are at least two CPU PMUs on the system. The PMU that is set +for one VCPU will be used by all the other VCPUs. It isn't possible to set a PMU +if a PMU event filter is already present. + +Note that KVM will not make any attempts to run the VCPU on the physical CPUs +associated with the PMU specified by this attribute. This is entirely left to +userspace. However, attempting to run the VCPU on a physical CPU not supported +by the PMU will fail and KVM_RUN will return with +exit_reason = KVM_EXIT_FAIL_ENTRY and populate the fail_entry struct by setting +hardare_entry_failure_reason field to KVM_EXIT_FAIL_ENTRY_CPU_UNSUPPORTED and +the cpu field to the processor id. 2. GROUP: KVM_ARM_VCPU_TIMER_CTRL ================================= -:Architectures: ARM, ARM64 +:Architectures: ARM64 2.1. ATTRIBUTES: KVM_ARM_VCPU_TIMER_IRQ_VTIMER, KVM_ARM_VCPU_TIMER_IRQ_PTIMER ----------------------------------------------------------------------------- diff --git a/Documentation/virt/kvm/index.rst b/Documentation/virt/kvm/index.rst index b6833c7bb474..e0a2c74e1043 100644 --- a/Documentation/virt/kvm/index.rst +++ b/Documentation/virt/kvm/index.rst @@ -8,25 +8,13 @@ KVM :maxdepth: 2 api - amd-memory-encryption - cpuid - halt-polling - hypercalls - locking - mmu - msr - nested-vmx - ppc-pv - s390-diag - s390-pv - s390-pv-boot - timekeeping - vcpu-requests - - review-checklist + devices/index arm/index + s390/index + ppc-pv + x86/index - devices/index - - running-nested-guests + locking + vcpu-requests + review-checklist diff --git a/Documentation/virt/kvm/locking.rst b/Documentation/virt/kvm/locking.rst index 5d27da356836..845a561629f1 100644 --- a/Documentation/virt/kvm/locking.rst +++ b/Documentation/virt/kvm/locking.rst @@ -210,32 +210,47 @@ time it will be set using the Dirty tracking mechanism described above. 3. Reference ------------ -:Name: kvm_lock +``kvm_lock`` +^^^^^^^^^^^^ + :Type: mutex :Arch: any :Protects: - vm_list -:Name: kvm_count_lock +``kvm_count_lock`` +^^^^^^^^^^^^^^^^^^ + :Type: raw_spinlock_t :Arch: any :Protects: - hardware virtualization enable/disable :Comment: 'raw' because hardware enabling/disabling must be atomic /wrt migration. -:Name: kvm_arch::tsc_write_lock -:Type: raw_spinlock +``kvm->mn_invalidate_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:Type: spinlock_t +:Arch: any +:Protects: mn_active_invalidate_count, mn_memslots_update_rcuwait + +``kvm_arch::tsc_write_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +:Type: raw_spinlock_t :Arch: x86 :Protects: - kvm_arch::{last_tsc_write,last_tsc_nsec,last_tsc_offset} - tsc offset in vmcb :Comment: 'raw' because updating the tsc offsets must not be preempted. -:Name: kvm->mmu_lock -:Type: spinlock_t +``kvm->mmu_lock`` +^^^^^^^^^^^^^^^^^ +:Type: spinlock_t or rwlock_t :Arch: any :Protects: -shadow page/shadow tlb entry :Comment: it is a spinlock since it is used in mmu notifier. -:Name: kvm->srcu +``kvm->srcu`` +^^^^^^^^^^^^^ :Type: srcu lock :Arch: any :Protects: - kvm->memslots @@ -246,10 +261,20 @@ time it will be set using the Dirty tracking mechanism described above. The srcu index can be stored in kvm_vcpu->srcu_idx per vcpu if it is needed by multiple functions. -:Name: blocked_vcpu_on_cpu_lock +``kvm->slots_arch_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^ +:Type: mutex +:Arch: any (only needed on x86 though) +:Protects: any arch-specific fields of memslots that have to be modified + in a ``kvm->srcu`` read-side critical section. +:Comment: must be held before reading the pointer to the current memslots, + until after all changes to the memslots are complete + +``wakeup_vcpus_on_cpu_lock`` +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ :Type: spinlock_t :Arch: x86 -:Protects: blocked_vcpu_on_cpu +:Protects: wakeup_vcpus_on_cpu :Comment: This is a per-CPU lock and it is used for VT-d posted-interrupts. When VT-d posted-interrupts is supported and the VM has assigned devices, we put the blocked vCPU on the list blocked_vcpu_on_cpu diff --git a/Documentation/virt/kvm/s390/index.rst b/Documentation/virt/kvm/s390/index.rst new file mode 100644 index 000000000000..605f488f0cc5 --- /dev/null +++ b/Documentation/virt/kvm/s390/index.rst @@ -0,0 +1,12 @@ +.. SPDX-License-Identifier: GPL-2.0 + +==================== +KVM for s390 systems +==================== + +.. toctree:: + :maxdepth: 2 + + s390-diag + s390-pv + s390-pv-boot diff --git a/Documentation/virt/kvm/s390-diag.rst b/Documentation/virt/kvm/s390/s390-diag.rst index ca85f030eb0b..ca85f030eb0b 100644 --- a/Documentation/virt/kvm/s390-diag.rst +++ b/Documentation/virt/kvm/s390/s390-diag.rst diff --git a/Documentation/virt/kvm/s390-pv-boot.rst b/Documentation/virt/kvm/s390/s390-pv-boot.rst index 73a6083cb5e7..73a6083cb5e7 100644 --- a/Documentation/virt/kvm/s390-pv-boot.rst +++ b/Documentation/virt/kvm/s390/s390-pv-boot.rst diff --git a/Documentation/virt/kvm/s390-pv.rst b/Documentation/virt/kvm/s390/s390-pv.rst index 8e41a3b63fa5..8e41a3b63fa5 100644 --- a/Documentation/virt/kvm/s390-pv.rst +++ b/Documentation/virt/kvm/s390/s390-pv.rst diff --git a/Documentation/virt/kvm/vcpu-requests.rst b/Documentation/virt/kvm/vcpu-requests.rst index ad2915ef7020..db43ee571f5a 100644 --- a/Documentation/virt/kvm/vcpu-requests.rst +++ b/Documentation/virt/kvm/vcpu-requests.rst @@ -112,11 +112,10 @@ KVM_REQ_TLB_FLUSH choose to use the common kvm_flush_remote_tlbs() implementation will need to handle this VCPU request. -KVM_REQ_MMU_RELOAD +KVM_REQ_VM_DEAD - When shadow page tables are used and memory slots are removed it's - necessary to inform each VCPU to completely refresh the tables. This - request is used for that. + This request informs all VCPUs that the VM is dead and unusable, e.g. due to + fatal error or because the VM's state has been intentionally destroyed. KVM_REQ_UNBLOCK @@ -136,6 +135,16 @@ KVM_REQ_UNHALT such as a pending signal, which does not indicate the VCPU's halt emulation should stop, and therefore does not make the request. +KVM_REQ_OUTSIDE_GUEST_MODE + + This "request" ensures the target vCPU has exited guest mode prior to the + sender of the request continuing on. No action needs be taken by the target, + and so no request is actually logged for the target. This request is similar + to a "kick", but unlike a kick it guarantees the vCPU has actually exited + guest mode. A kick only guarantees the vCPU will exit at some point in the + future, e.g. a previous kick may have started the process, but there's no + guarantee the to-be-kicked vCPU has fully exited guest mode. + KVM_REQUEST_MASK ---------------- diff --git a/Documentation/virt/kvm/amd-memory-encryption.rst b/Documentation/virt/kvm/x86/amd-memory-encryption.rst index 1c6847fff304..1c6847fff304 100644 --- a/Documentation/virt/kvm/amd-memory-encryption.rst +++ b/Documentation/virt/kvm/x86/amd-memory-encryption.rst diff --git a/Documentation/virt/kvm/cpuid.rst b/Documentation/virt/kvm/x86/cpuid.rst index bda3e3e737d7..bda3e3e737d7 100644 --- a/Documentation/virt/kvm/cpuid.rst +++ b/Documentation/virt/kvm/x86/cpuid.rst diff --git a/Documentation/virt/kvm/x86/errata.rst b/Documentation/virt/kvm/x86/errata.rst new file mode 100644 index 000000000000..806f049b6975 --- /dev/null +++ b/Documentation/virt/kvm/x86/errata.rst @@ -0,0 +1,39 @@ + +======================================= +Known limitations of CPU virtualization +======================================= + +Whenever perfect emulation of a CPU feature is impossible or too hard, KVM +has to choose between not implementing the feature at all or introducing +behavioral differences between virtual machines and bare metal systems. + +This file documents some of the known limitations that KVM has in +virtualizing CPU features. + +x86 +=== + +``KVM_GET_SUPPORTED_CPUID`` issues +---------------------------------- + +x87 features +~~~~~~~~~~~~ + +Unlike most other CPUID feature bits, CPUID[EAX=7,ECX=0]:EBX[6] +(FDP_EXCPTN_ONLY) and CPUID[EAX=7,ECX=0]:EBX]13] (ZERO_FCS_FDS) are +clear if the features are present and set if the features are not present. + +Clearing these bits in CPUID has no effect on the operation of the guest; +if these bits are set on hardware, the features will not be present on +any virtual machine that runs on that hardware. + +**Workaround:** It is recommended to always set these bits in guest CPUID. +Note however that any software (e.g ``WIN87EM.DLL``) expecting these features +to be present likely predates these CPUID feature bits, and therefore +doesn't know to check for them anyway. + +Nested virtualization features +------------------------------ + +TBD + diff --git a/Documentation/virt/kvm/halt-polling.rst b/Documentation/virt/kvm/x86/halt-polling.rst index 4922e4a15f18..4922e4a15f18 100644 --- a/Documentation/virt/kvm/halt-polling.rst +++ b/Documentation/virt/kvm/x86/halt-polling.rst diff --git a/Documentation/virt/kvm/hypercalls.rst b/Documentation/virt/kvm/x86/hypercalls.rst index e56fa8b9cfca..e56fa8b9cfca 100644 --- a/Documentation/virt/kvm/hypercalls.rst +++ b/Documentation/virt/kvm/x86/hypercalls.rst diff --git a/Documentation/virt/kvm/x86/index.rst b/Documentation/virt/kvm/x86/index.rst new file mode 100644 index 000000000000..7ff588826b9f --- /dev/null +++ b/Documentation/virt/kvm/x86/index.rst @@ -0,0 +1,19 @@ +.. SPDX-License-Identifier: GPL-2.0 + +=================== +KVM for x86 systems +=================== + +.. toctree:: + :maxdepth: 2 + + amd-memory-encryption + cpuid + errata + halt-polling + hypercalls + mmu + msr + nested-vmx + running-nested-guests + timekeeping diff --git a/Documentation/virt/kvm/mmu.rst b/Documentation/virt/kvm/x86/mmu.rst index 5b1ebad24c77..5b1ebad24c77 100644 --- a/Documentation/virt/kvm/mmu.rst +++ b/Documentation/virt/kvm/x86/mmu.rst diff --git a/Documentation/virt/kvm/msr.rst b/Documentation/virt/kvm/x86/msr.rst index 9315fc385fb0..9315fc385fb0 100644 --- a/Documentation/virt/kvm/msr.rst +++ b/Documentation/virt/kvm/x86/msr.rst diff --git a/Documentation/virt/kvm/nested-vmx.rst b/Documentation/virt/kvm/x86/nested-vmx.rst index ac2095d41f02..ac2095d41f02 100644 --- a/Documentation/virt/kvm/nested-vmx.rst +++ b/Documentation/virt/kvm/x86/nested-vmx.rst diff --git a/Documentation/virt/kvm/running-nested-guests.rst b/Documentation/virt/kvm/x86/running-nested-guests.rst index bd70c69468ae..bd70c69468ae 100644 --- a/Documentation/virt/kvm/running-nested-guests.rst +++ b/Documentation/virt/kvm/x86/running-nested-guests.rst diff --git a/Documentation/virt/kvm/timekeeping.rst b/Documentation/virt/kvm/x86/timekeeping.rst index 21ae7efa29ba..21ae7efa29ba 100644 --- a/Documentation/virt/kvm/timekeeping.rst +++ b/Documentation/virt/kvm/x86/timekeeping.rst diff --git a/Documentation/virt/uml/user_mode_linux_howto_v2.rst b/Documentation/virt/uml/user_mode_linux_howto_v2.rst index 2cafd3c3c6cb..863f67b72c05 100644 --- a/Documentation/virt/uml/user_mode_linux_howto_v2.rst +++ b/Documentation/virt/uml/user_mode_linux_howto_v2.rst @@ -664,7 +664,11 @@ one is input, the second one output. * The fd channel - use file descriptor numbers for input/output. Example: ``con1=fd:0,fd:1.`` -* The port channel - listen on TCP port number. Example: ``con1=port:4321`` +* The port channel - start a telnet server on TCP port number. Example: + ``con1=port:4321``. The host must have /usr/sbin/in.telnetd (usually part of + a telnetd package) and the port-helper from the UML utilities (see the + information for the xterm channel below). UML will not boot until a client + connects. * The pty and pts channels - use system pty/pts. @@ -1189,6 +1193,26 @@ E.g. ``os_close_file()`` is just a wrapper around ``close()`` which ensures that the userspace function close does not clash with similarly named function(s) in the kernel part. +Using UML as a Test Platform +============================ + +UML is an excellent test platform for device driver development. As +with most things UML, "some user assembly may be required". It is +up to the user to build their emulation environment. UML at present +provides only the kernel infrastructure. + +Part of this infrastructure is the ability to load and parse fdt +device tree blobs as used in Arm or Open Firmware platforms. These +are supplied as an optional extra argument to the kernel command +line:: + + dtb=filename + +The device tree is loaded and parsed at boottime and is accessible by +drivers which query it. At this moment in time this facility is +intended solely for development purposes. UML's own devices do not +query the device tree. + Security Considerations ----------------------- diff --git a/Documentation/vm/damon/design.rst b/Documentation/vm/damon/design.rst index 210f0f50efd8..0cff6fac6b7e 100644 --- a/Documentation/vm/damon/design.rst +++ b/Documentation/vm/damon/design.rst @@ -13,12 +13,13 @@ primitives that dependent on and optimized for the target address space. On the other hand, the accuracy and overhead tradeoff mechanism, which is the core of DAMON, is in the pure logic space. DAMON separates the two parts in different layers and defines its interface to allow various low level -primitives implementations configurable with the core logic. +primitives implementations configurable with the core logic. We call the low +level primitives implementations monitoring operations. Due to this separated design and the configurable interface, users can extend -DAMON for any address space by configuring the core logics with appropriate low -level primitive implementations. If appropriate one is not provided, users can -implement the primitives on their own. +DAMON for any address space by configuring the core logics with appropriate +monitoring operations. If appropriate one is not provided, users can implement +the operations on their own. For example, physical memory, virtual memory, swap space, those for specific processes, NUMA nodes, files, and backing memory devices would be supportable. @@ -26,25 +27,24 @@ Also, if some architectures or devices support special optimized access check primitives, those will be easily configurable. -Reference Implementations of Address Space Specific Primitives -============================================================== +Reference Implementations of Address Space Specific Monitoring Operations +========================================================================= -The low level primitives for the fundamental access monitoring are defined in -two parts: +The monitoring operations are defined in two parts: 1. Identification of the monitoring target address range for the address space. 2. Access check of specific address range in the target space. -DAMON currently provides the implementations of the primitives for the physical +DAMON currently provides the implementations of the operations for the physical and virtual address spaces. Below two subsections describe how those work. VMA-based Target Address Range Construction ------------------------------------------- -This is only for the virtual address space primitives implementation. That for -the physical address space simply asks users to manually set the monitoring -target address ranges. +This is only for the virtual address space monitoring operations +implementation. That for the physical address space simply asks users to +manually set the monitoring target address ranges. Only small parts in the super-huge virtual address space of the processes are mapped to the physical memory and accessed. Thus, tracking the unmapped @@ -84,9 +84,10 @@ table having a mapping to the address. In this way, the implementations find and clear the bit(s) for next sampling target address and checks whether the bit(s) set again after one sampling period. This could disturb other kernel subsystems using the Accessed bits, namely Idle page tracking and the reclaim -logic. To avoid such disturbances, DAMON makes it mutually exclusive with Idle -page tracking and uses ``PG_idle`` and ``PG_young`` page flags to solve the -conflict with the reclaim logic, as Idle page tracking does. +logic. DAMON does nothing to avoid disturbing Idle page tracking, so handling +the interference is the responsibility of sysadmins. However, it solves the +conflict with the reclaim logic using ``PG_idle`` and ``PG_young`` page flags, +as Idle page tracking does. Address Space Independent Core Mechanisms @@ -94,8 +95,8 @@ Address Space Independent Core Mechanisms Below four sections describe each of the DAMON core mechanisms and the five monitoring attributes, ``sampling interval``, ``aggregation interval``, -``regions update interval``, ``minimum number of regions``, and ``maximum -number of regions``. +``update interval``, ``minimum number of regions``, and ``maximum number of +regions``. Access Frequency Monitoring @@ -168,6 +169,8 @@ The monitoring target address range could dynamically changed. For example, virtual memory could be dynamically mapped and unmapped. Physical memory could be hot-plugged. -As the changes could be quite frequent in some cases, DAMON checks the dynamic -memory mapping changes and applies it to the abstracted target area only for -each of a user-specified time interval (``regions update interval``). +As the changes could be quite frequent in some cases, DAMON allows the +monitoring operations to check dynamic changes including memory mapping changes +and applies it to monitoring operations-related data structures such as the +abstracted monitoring target memory area only for each of a user-specified time +interval (``update interval``). diff --git a/Documentation/vm/damon/faq.rst b/Documentation/vm/damon/faq.rst index 11aea40eb328..dde7e2414ee6 100644 --- a/Documentation/vm/damon/faq.rst +++ b/Documentation/vm/damon/faq.rst @@ -31,7 +31,7 @@ Does DAMON support virtual memory only? ======================================= No. The core of the DAMON is address space independent. The address space -specific low level primitive parts including monitoring target regions +specific monitoring operations including monitoring target regions constructions and actual access checks can be implemented and configured on the DAMON core by the users. In this way, DAMON users can monitor any address space with any access check technique. diff --git a/Documentation/vm/hwpoison.rst b/Documentation/vm/hwpoison.rst index 89b5f7a52077..c742de1769d1 100644 --- a/Documentation/vm/hwpoison.rst +++ b/Documentation/vm/hwpoison.rst @@ -60,8 +60,6 @@ There are two (actually three) modes memory failure recovery can be in: vm.memory_failure_recovery sysctl set to zero: All memory failures cause a panic. Do not attempt recovery. - (on x86 this can be also affected by the tolerant level of the - MCE subsystem) early kill (can be controlled globally and per process) diff --git a/Documentation/vm/page_owner.rst b/Documentation/vm/page_owner.rst index 9837fc8147dd..65204d7f004f 100644 --- a/Documentation/vm/page_owner.rst +++ b/Documentation/vm/page_owner.rst @@ -26,9 +26,9 @@ fragmentation statistics can be obtained through gfp flag information of each page. It is already implemented and activated if page owner is enabled. Other usages are more than welcome. -page owner is disabled in default. So, if you'd like to use it, you need -to add "page_owner=on" into your boot cmdline. If the kernel is built -with page owner and page owner is disabled in runtime due to no enabling +page owner is disabled by default. So, if you'd like to use it, you need +to add "page_owner=on" to your boot cmdline. If the kernel is built +with page owner and page owner is disabled in runtime due to not enabling boot option, runtime overhead is marginal. If disabled in runtime, it doesn't require memory to store owner information, so there is no runtime memory overhead. And, page owner inserts just two unlikely branches into @@ -78,33 +78,85 @@ Usage 2) Enable page owner: add "page_owner=on" to boot cmdline. -3) Do the job what you want to debug +3) Do the job that you want to debug. 4) Analyze information from page owner:: cat /sys/kernel/debug/page_owner > page_owner_full.txt ./page_owner_sort page_owner_full.txt sorted_page_owner.txt - The general output of ``page_owner_full.txt`` is as follows: + The general output of ``page_owner_full.txt`` is as follows:: Page allocated via order XXX, ... PFN XXX ... - // Detailed stack + // Detailed stack Page allocated via order XXX, ... PFN XXX ... - // Detailed stack + // Detailed stack The ``page_owner_sort`` tool ignores ``PFN`` rows, puts the remaining rows in buf, uses regexp to extract the page order value, counts the times - and pages of buf, and finally sorts them according to the times. + and pages of buf, and finally sorts them according to the parameter(s). See the result about who allocated each page - in the ``sorted_page_owner.txt``. General output: + in the ``sorted_page_owner.txt``. General output:: XXX times, XXX pages: Page allocated via order XXX, ... - // Detailed stack + // Detailed stack By default, ``page_owner_sort`` is sorted according to the times of buf. - If you want to sort by the pages nums of buf, use the ``-m`` parameter. + If you want to sort by the page nums of buf, use the ``-m`` parameter. + The detailed parameters are: + + fundamental function: + + Sort: + -a Sort by memory allocation time. + -m Sort by total memory. + -p Sort by pid. + -P Sort by tgid. + -n Sort by task command name. + -r Sort by memory release time. + -s Sort by stack trace. + -t Sort by times (default). + + additional function: + + Cull: + --cull <rules> + Specify culling rules.Culling syntax is key[,key[,...]].Choose a + multi-letter key from the **STANDARD FORMAT SPECIFIERS** section. + + + <rules> is a single argument in the form of a comma-separated list, + which offers a way to specify individual culling rules. The recognized + keywords are described in the **STANDARD FORMAT SPECIFIERS** section below. + <rules> can be specified by the sequence of keys k1,k2, ..., as described in + the STANDARD SORT KEYS section below. Mixed use of abbreviated and + complete-form of keys is allowed. + + + Examples: + ./page_owner_sort <input> <output> --cull=stacktrace + ./page_owner_sort <input> <output> --cull=st,pid,name + ./page_owner_sort <input> <output> --cull=n,f + + Filter: + -f Filter out the information of blocks whose memory has been released. + + Select: + --pid <PID> Select by pid. + --tgid <TGID> Select by tgid. + --name <command> Select by task command name. + +STANDARD FORMAT SPECIFIERS +========================== + + KEY LONG DESCRIPTION + p pid process ID + tg tgid thread group ID + n name task command name + f free whether the page has been released or not + st stacktrace stace trace of the page allocation diff --git a/Documentation/vm/page_table_check.rst b/Documentation/vm/page_table_check.rst index 81f521ff7ea7..1a09472f10a3 100644 --- a/Documentation/vm/page_table_check.rst +++ b/Documentation/vm/page_table_check.rst @@ -9,7 +9,7 @@ Page Table Check Introduction ============ -Page table check allows to hardern the kernel by ensuring that some types of +Page table check allows to harden the kernel by ensuring that some types of the memory corruptions are prevented. Page table check performs extra verifications at the time when new pages become diff --git a/Documentation/vm/unevictable-lru.rst b/Documentation/vm/unevictable-lru.rst index eae3af17f2d9..b280367d6a44 100644 --- a/Documentation/vm/unevictable-lru.rst +++ b/Documentation/vm/unevictable-lru.rst @@ -52,8 +52,13 @@ The infrastructure may also be able to handle other conditions that make pages unevictable, either by definition or by circumstance, in the future. -The Unevictable Page List -------------------------- +The Unevictable LRU Page List +----------------------------- + +The Unevictable LRU page list is a lie. It was never an LRU-ordered list, but a +companion to the LRU-ordered anonymous and file, active and inactive page lists; +and now it is not even a page list. But following familiar convention, here in +this document and in the source, we often imagine it as a fifth LRU page list. The Unevictable LRU infrastructure consists of an additional, per-node, LRU list called the "unevictable" list and an associated page flag, PG_unevictable, to @@ -63,8 +68,8 @@ The PG_unevictable flag is analogous to, and mutually exclusive with, the PG_active flag in that it indicates on which LRU list a page resides when PG_lru is set. -The Unevictable LRU infrastructure maintains unevictable pages on an additional -LRU list for a few reasons: +The Unevictable LRU infrastructure maintains unevictable pages as if they were +on an additional LRU list for a few reasons: (1) We get to "treat unevictable pages just like we treat other pages in the system - which means we get to use the same code to manipulate them, the @@ -72,13 +77,11 @@ LRU list for a few reasons: of the statistics, etc..." [Rik van Riel] (2) We want to be able to migrate unevictable pages between nodes for memory - defragmentation, workload management and memory hotplug. The linux kernel + defragmentation, workload management and memory hotplug. The Linux kernel can only migrate pages that it can successfully isolate from the LRU - lists. If we were to maintain pages elsewhere than on an LRU-like list, - where they can be found by isolate_lru_page(), we would prevent their - migration, unless we reworked migration code to find the unevictable pages - itself. - + lists (or "Movable" pages: outside of consideration here). If we were to + maintain pages elsewhere than on an LRU-like list, where they can be + detected by isolate_lru_page(), we would prevent their migration. The unevictable list does not differentiate between file-backed and anonymous, swap-backed pages. This differentiation is only important while the pages are, @@ -92,8 +95,8 @@ Memory Control Group Interaction -------------------------------- The unevictable LRU facility interacts with the memory control group [aka -memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by extending the -lru_list enum. +memory controller; see Documentation/admin-guide/cgroup-v1/memory.rst] by +extending the lru_list enum. The memory controller data structure automatically gets a per-node unevictable list as a result of the "arrayification" of the per-node LRU lists (one per @@ -143,7 +146,6 @@ These are currently used in three places in the kernel: and this mark remains for the life of the inode. (2) By SYSV SHM to mark SHM_LOCK'd address spaces until SHM_UNLOCK is called. - Note that SHM_LOCK is not required to page in the locked pages if they're swapped out; the application must touch the pages manually if it wants to ensure they're in memory. @@ -156,19 +158,19 @@ These are currently used in three places in the kernel: Detecting Unevictable Pages --------------------------- -The function page_evictable() in vmscan.c determines whether a page is +The function page_evictable() in mm/internal.h determines whether a page is evictable or not using the query function outlined above [see section :ref:`Marking address spaces unevictable <mark_addr_space_unevict>`] to check the AS_UNEVICTABLE flag. For address spaces that are so marked after being populated (as SHM regions -might be), the lock action (eg: SHM_LOCK) can be lazy, and need not populate +might be), the lock action (e.g. SHM_LOCK) can be lazy, and need not populate the page tables for the region as does, for example, mlock(), nor need it make any special effort to push any pages in the SHM_LOCK'd area to the unevictable list. Instead, vmscan will do this if and when it encounters the pages during a reclamation scan. -On an unlock action (such as SHM_UNLOCK), the unlocker (eg: shmctl()) must scan +On an unlock action (such as SHM_UNLOCK), the unlocker (e.g. shmctl()) must scan the pages in the region and "rescue" them from the unevictable list if no other condition is keeping them unevictable. If an unevictable region is destroyed, the pages are also "rescued" from the unevictable list in the process of @@ -176,7 +178,7 @@ freeing them. page_evictable() also checks for mlocked pages by testing an additional page flag, PG_mlocked (as wrapped by PageMlocked()), which is set when a page is -faulted into a VM_LOCKED vma, or found in a vma being VM_LOCKED. +faulted into a VM_LOCKED VMA, or found in a VMA being VM_LOCKED. Vmscan's Handling of Unevictable Pages @@ -186,28 +188,23 @@ If unevictable pages are culled in the fault path, or moved to the unevictable list at mlock() or mmap() time, vmscan will not encounter the pages until they have become evictable again (via munlock() for example) and have been "rescued" from the unevictable list. However, there may be situations where we decide, -for the sake of expediency, to leave a unevictable page on one of the regular +for the sake of expediency, to leave an unevictable page on one of the regular active/inactive LRU lists for vmscan to deal with. vmscan checks for such pages in all of the shrink_{active|inactive|page}_list() functions and will "cull" such pages that it encounters: that is, it diverts those pages to the -unevictable list for the node being scanned. +unevictable list for the memory cgroup and node being scanned. There may be situations where a page is mapped into a VM_LOCKED VMA, but the page is not marked as PG_mlocked. Such pages will make it all the way to -shrink_page_list() where they will be detected when vmscan walks the reverse -map in try_to_unmap(). If try_to_unmap() returns SWAP_MLOCK, -shrink_page_list() will cull the page at that point. +shrink_active_list() or shrink_page_list() where they will be detected when +vmscan walks the reverse map in page_referenced() or try_to_unmap(). The page +is culled to the unevictable list when it is released by the shrinker. To "cull" an unevictable page, vmscan simply puts the page back on the LRU list using putback_lru_page() - the inverse operation to isolate_lru_page() - after dropping the page lock. Because the condition which makes the page unevictable -may change once the page is unlocked, putback_lru_page() will recheck the -unevictable state of a page that it places on the unevictable list. If the -page has become unevictable, putback_lru_page() removes it from the list and -retries, including the page_unevictable() test. Because such a race is a rare -event and movement of pages onto the unevictable list should be rare, these -extra evictabilty checks should not occur in the majority of calls to -putback_lru_page(). +may change once the page is unlocked, __pagevec_lru_add_fn() will recheck the +unevictable state of a page before placing it on the unevictable list. MLOCKED Pages @@ -227,16 +224,25 @@ Nick posted his patch as an alternative to a patch posted by Christoph Lameter to achieve the same objective: hiding mlocked pages from vmscan. In Nick's patch, he used one of the struct page LRU list link fields as a count -of VM_LOCKED VMAs that map the page. This use of the link field for a count -prevented the management of the pages on an LRU list, and thus mlocked pages -were not migratable as isolate_lru_page() could not find them, and the LRU list -link field was not available to the migration subsystem. +of VM_LOCKED VMAs that map the page (Rik van Riel had the same idea three years +earlier). But this use of the link field for a count prevented the management +of the pages on an LRU list, and thus mlocked pages were not migratable as +isolate_lru_page() could not detect them, and the LRU list link field was not +available to the migration subsystem. -Nick resolved this by putting mlocked pages back on the lru list before +Nick resolved this by putting mlocked pages back on the LRU list before attempting to isolate them, thus abandoning the count of VM_LOCKED VMAs. When Nick's patch was integrated with the Unevictable LRU work, the count was -replaced by walking the reverse map to determine whether any VM_LOCKED VMAs -mapped the page. More on this below. +replaced by walking the reverse map when munlocking, to determine whether any +other VM_LOCKED VMAs still mapped the page. + +However, walking the reverse map for each page when munlocking was ugly and +inefficient, and could lead to catastrophic contention on a file's rmap lock, +when many processes which had it mlocked were trying to exit. In 5.18, the +idea of keeping mlock_count in Unevictable LRU list link field was revived and +put to work, without preventing the migration of mlocked pages. This is why +the "Unevictable LRU list" cannot be a linked list of pages now; but there was +no use for that linked list anyway - though its size is maintained for meminfo. Basic Management @@ -250,22 +256,18 @@ PageMlocked() functions. A PG_mlocked page will be placed on the unevictable list when it is added to the LRU. Such pages can be "noticed" by memory management in several places: - (1) in the mlock()/mlockall() system call handlers; + (1) in the mlock()/mlock2()/mlockall() system call handlers; (2) in the mmap() system call handler when mmapping a region with the MAP_LOCKED flag; (3) mmapping a region in a task that has called mlockall() with the MCL_FUTURE - flag + flag; - (4) in the fault path, if mlocked pages are "culled" in the fault path, - and when a VM_LOCKED stack segment is expanded; or + (4) in the fault path and when a VM_LOCKED stack segment is expanded; or (5) as mentioned above, in vmscan:shrink_page_list() when attempting to - reclaim a page in a VM_LOCKED VMA via try_to_unmap() - -all of which result in the VM_LOCKED flag being set for the VMA if it doesn't -already have it set. + reclaim a page in a VM_LOCKED VMA by page_referenced() or try_to_unmap(). mlocked pages become unlocked and rescued from the unevictable list when: @@ -280,51 +282,53 @@ mlocked pages become unlocked and rescued from the unevictable list when: (4) before a page is COW'd in a VM_LOCKED VMA. -mlock()/mlockall() System Call Handling ---------------------------------------- +mlock()/mlock2()/mlockall() System Call Handling +------------------------------------------------ -Both [do\_]mlock() and [do\_]mlockall() system call handlers call mlock_fixup() +mlock(), mlock2() and mlockall() system call handlers proceed to mlock_fixup() for each VMA in the range specified by the call. In the case of mlockall(), this is the entire active address space of the task. Note that mlock_fixup() is used for both mlocking and munlocking a range of memory. A call to mlock() -an already VM_LOCKED VMA, or to munlock() a VMA that is not VM_LOCKED is -treated as a no-op, and mlock_fixup() simply returns. +an already VM_LOCKED VMA, or to munlock() a VMA that is not VM_LOCKED, is +treated as a no-op and mlock_fixup() simply returns. -If the VMA passes some filtering as described in "Filtering Special Vmas" +If the VMA passes some filtering as described in "Filtering Special VMAs" below, mlock_fixup() will attempt to merge the VMA with its neighbors or split -off a subset of the VMA if the range does not cover the entire VMA. Once the -VMA has been merged or split or neither, mlock_fixup() will call -populate_vma_page_range() to fault in the pages via get_user_pages() and to -mark the pages as mlocked via mlock_vma_page(). +off a subset of the VMA if the range does not cover the entire VMA. Any pages +already present in the VMA are then marked as mlocked by mlock_page() via +mlock_pte_range() via walk_page_range() via mlock_vma_pages_range(). + +Before returning from the system call, do_mlock() or mlockall() will call +__mm_populate() to fault in the remaining pages via get_user_pages() and to +mark those pages as mlocked as they are faulted. Note that the VMA being mlocked might be mapped with PROT_NONE. In this case, get_user_pages() will be unable to fault in the pages. That's okay. If pages -do end up getting faulted into this VM_LOCKED VMA, we'll handle them in the -fault path or in vmscan. - -Also note that a page returned by get_user_pages() could be truncated or -migrated out from under us, while we're trying to mlock it. To detect this, -populate_vma_page_range() checks page_mapping() after acquiring the page lock. -If the page is still associated with its mapping, we'll go ahead and call -mlock_vma_page(). If the mapping is gone, we just unlock the page and move on. -In the worst case, this will result in a page mapped in a VM_LOCKED VMA -remaining on a normal LRU list without being PageMlocked(). Again, vmscan will -detect and cull such pages. - -mlock_vma_page() will call TestSetPageMlocked() for each page returned by -get_user_pages(). We use TestSetPageMlocked() because the page might already -be mlocked by another task/VMA and we don't want to do extra work. We -especially do not want to count an mlocked page more than once in the -statistics. If the page was already mlocked, mlock_vma_page() need do nothing -more. - -If the page was NOT already mlocked, mlock_vma_page() attempts to isolate the -page from the LRU, as it is likely on the appropriate active or inactive list -at that time. If the isolate_lru_page() succeeds, mlock_vma_page() will put -back the page - by calling putback_lru_page() - which will notice that the page -is now mlocked and divert the page to the node's unevictable list. If -mlock_vma_page() is unable to isolate the page from the LRU, vmscan will handle -it later if and when it attempts to reclaim the page. +do end up getting faulted into this VM_LOCKED VMA, they will be handled in the +fault path - which is also how mlock2()'s MLOCK_ONFAULT areas are handled. + +For each PTE (or PMD) being faulted into a VMA, the page add rmap function +calls mlock_vma_page(), which calls mlock_page() when the VMA is VM_LOCKED +(unless it is a PTE mapping of a part of a transparent huge page). Or when +it is a newly allocated anonymous page, lru_cache_add_inactive_or_unevictable() +calls mlock_new_page() instead: similar to mlock_page(), but can make better +judgments, since this page is held exclusively and known not to be on LRU yet. + +mlock_page() sets PageMlocked immediately, then places the page on the CPU's +mlock pagevec, to batch up the rest of the work to be done under lru_lock by +__mlock_page(). __mlock_page() sets PageUnevictable, initializes mlock_count +and moves the page to unevictable state ("the unevictable LRU", but with +mlock_count in place of LRU threading). Or if the page was already PageLRU +and PageUnevictable and PageMlocked, it simply increments the mlock_count. + +But in practice that may not work ideally: the page may not yet be on an LRU, or +it may have been temporarily isolated from LRU. In such cases the mlock_count +field cannot be touched, but will be set to 0 later when __pagevec_lru_add_fn() +returns the page to "LRU". Races prohibit mlock_count from being set to 1 then: +rather than risk stranding a page indefinitely as unevictable, always err with +mlock_count on the low side, so that when munlocked the page will be rescued to +an evictable LRU, then perhaps be mlocked again later if vmscan finds it in a +VM_LOCKED VMA. Filtering Special VMAs @@ -339,68 +343,48 @@ mlock_fixup() filters several classes of "special" VMAs: so there is no sense in attempting to visit them. 2) VMAs mapping hugetlbfs page are already effectively pinned into memory. We - neither need nor want to mlock() these pages. However, to preserve the - prior behavior of mlock() - before the unevictable/mlock changes - - mlock_fixup() will call make_pages_present() in the hugetlbfs VMA range to - allocate the huge pages and populate the ptes. + neither need nor want to mlock() these pages. But __mm_populate() includes + hugetlbfs ranges, allocating the huge pages and populating the PTEs. 3) VMAs with VM_DONTEXPAND are generally userspace mappings of kernel pages, - such as the VDSO page, relay channel pages, etc. These pages - are inherently unevictable and are not managed on the LRU lists. - mlock_fixup() treats these VMAs the same as hugetlbfs VMAs. It calls - make_pages_present() to populate the ptes. + such as the VDSO page, relay channel pages, etc. These pages are inherently + unevictable and are not managed on the LRU lists. __mm_populate() includes + these ranges, populating the PTEs if not already populated. + +4) VMAs with VM_MIXEDMAP set are not marked VM_LOCKED, but __mm_populate() + includes these ranges, populating the PTEs if not already populated. Note that for all of these special VMAs, mlock_fixup() does not set the VM_LOCKED flag. Therefore, we won't have to deal with them later during munlock(), munmap() or task exit. Neither does mlock_fixup() account these VMAs against the task's "locked_vm". -.. _munlock_munlockall_handling: munlock()/munlockall() System Call Handling ------------------------------------------- -The munlock() and munlockall() system calls are handled by the same functions - -do_mlock[all]() - as the mlock() and mlockall() system calls with the unlock vs -lock operation indicated by an argument. So, these system calls are also -handled by mlock_fixup(). Again, if called for an already munlocked VMA, -mlock_fixup() simply returns. Because of the VMA filtering discussed above, -VM_LOCKED will not be set in any "special" VMAs. So, these VMAs will be -ignored for munlock. +The munlock() and munlockall() system calls are handled by the same +mlock_fixup() function as mlock(), mlock2() and mlockall() system calls are. +If called to munlock an already munlocked VMA, mlock_fixup() simply returns. +Because of the VMA filtering discussed above, VM_LOCKED will not be set in +any "special" VMAs. So, those VMAs will be ignored for munlock. If the VMA is VM_LOCKED, mlock_fixup() again attempts to merge or split off the -specified range. The range is then munlocked via the function -populate_vma_page_range() - the same function used to mlock a VMA range - -passing a flag to indicate that munlock() is being performed. - -Because the VMA access protections could have been changed to PROT_NONE after -faulting in and mlocking pages, get_user_pages() was unreliable for visiting -these pages for munlocking. Because we don't want to leave pages mlocked, -get_user_pages() was enhanced to accept a flag to ignore the permissions when -fetching the pages - all of which should be resident as a result of previous -mlocking. - -For munlock(), populate_vma_page_range() unlocks individual pages by calling -munlock_vma_page(). munlock_vma_page() unconditionally clears the PG_mlocked -flag using TestClearPageMlocked(). As with mlock_vma_page(), -munlock_vma_page() use the Test*PageMlocked() function to handle the case where -the page might have already been unlocked by another task. If the page was -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 page_mlock(), the function that walks the reverse map to -check for other VM_LOCKED VMAs, without first isolating the page from the LRU. -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 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 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 -the page. This should be relatively rare. +specified range. All pages in the VMA are then munlocked by munlock_page() via +mlock_pte_range() via walk_page_range() via mlock_vma_pages_range() - the same +function used when mlocking a VMA range, with new flags for the VMA indicating +that it is munlock() being performed. + +munlock_page() uses the mlock pagevec to batch up work to be done under +lru_lock by __munlock_page(). __munlock_page() decrements the page's +mlock_count, and when that reaches 0 it clears PageMlocked and clears +PageUnevictable, moving the page from unevictable state to inactive LRU. + +But in practice that may not work ideally: the page may not yet have reached +"the unevictable LRU", or it may have been temporarily isolated from it. In +those cases its mlock_count field is unusable and must be assumed to be 0: so +that the page will be rescued to an evictable LRU, then perhaps be mlocked +again later if vmscan finds it in a VM_LOCKED VMA. Migrating MLOCKED Pages @@ -410,33 +394,38 @@ A page that is being migrated has been isolated from the LRU lists and is held locked across unmapping of the page, updating the page's address space entry and copying the contents and state, until the page table entry has been replaced with an entry that refers to the new page. Linux supports migration -of mlocked pages and other unevictable pages. This involves simply moving the -PG_mlocked and PG_unevictable states from the old page to the new page. +of mlocked pages and other unevictable pages. PG_mlocked is cleared from the +the old page when it is unmapped from the last VM_LOCKED VMA, and set when the +new page is mapped in place of migration entry in a VM_LOCKED VMA. If the page +was unevictable because mlocked, PG_unevictable follows PG_mlocked; but if the +page was unevictable for other reasons, PG_unevictable is copied explicitly. Note that page migration can race with mlocking or munlocking of the same page. -This has been discussed from the mlock/munlock perspective in the respective -sections above. Both processes (migration and m[un]locking) hold the page -locked. This provides the first level of synchronization. Page migration -zeros out the page_mapping of the old page before unlocking it, so m[un]lock -can skip these pages by testing the page mapping under page lock. +There is mostly no problem since page migration requires unmapping all PTEs of +the old page (including munlock where VM_LOCKED), then mapping in the new page +(including mlock where VM_LOCKED). The page table locks provide sufficient +synchronization. -To complete page migration, we place the new and old pages back onto the LRU -after dropping the page lock. The "unneeded" page - old page on success, new -page on failure - will be freed when the reference count held by the migration -process is released. To ensure that we don't strand pages on the unevictable -list because of a race between munlock and migration, page migration uses the -putback_lru_page() function to add migrated pages back to the LRU. +However, since mlock_vma_pages_range() starts by setting VM_LOCKED on a VMA, +before mlocking any pages already present, if one of those pages were migrated +before mlock_pte_range() reached it, it would get counted twice in mlock_count. +To prevent that, mlock_vma_pages_range() temporarily marks the VMA as VM_IO, +so that mlock_vma_page() will skip it. + +To complete page migration, we place the old and new pages back onto the LRU +afterwards. The "unneeded" page - old page on success, new page on failure - +is freed when the reference count held by the migration process is released. Compacting MLOCKED Pages ------------------------ -The unevictable LRU can be scanned for compactable regions and the default -behavior is to do so. /proc/sys/vm/compact_unevictable_allowed controls -this behavior (see Documentation/admin-guide/sysctl/vm.rst). Once scanning of the -unevictable LRU is enabled, the work of compaction is mostly handled by -the page migration code and the same work flow as described in MIGRATING -MLOCKED PAGES will apply. +The memory map can be scanned for compactable regions and the default behavior +is to let unevictable pages be moved. /proc/sys/vm/compact_unevictable_allowed +controls this behavior (see Documentation/admin-guide/sysctl/vm.rst). The work +of compaction is mostly handled by the page migration code and the same work +flow as described in Migrating MLOCKED Pages will apply. + MLOCKING Transparent Huge Pages ------------------------------- @@ -445,51 +434,44 @@ A transparent huge page is represented by a single entry on an LRU list. Therefore, we can only make unevictable an entire compound page, not individual subpages. -If a user tries to mlock() part of a huge page, we want the rest of the -page to be reclaimable. +If a user tries to mlock() part of a huge page, and no user mlock()s the +whole of the huge page, we want the rest of the page to be reclaimable. We cannot just split the page on partial mlock() as split_huge_page() can -fail and new intermittent failure mode for the syscall is undesirable. +fail and a new intermittent failure mode for the syscall is undesirable. -We handle this by keeping PTE-mapped huge pages on normal LRU lists: the -PMD on border of VM_LOCKED VMA will be split into PTE table. +We handle this by keeping PTE-mlocked huge pages on evictable LRU lists: +the PMD on the border of a VM_LOCKED VMA will be split into a PTE table. -This way the huge page is accessible for vmscan. Under memory pressure the +This way the huge page is accessible for vmscan. Under memory pressure the page will be split, subpages which belong to VM_LOCKED VMAs will be moved -to unevictable LRU and the rest can be reclaimed. +to the unevictable LRU and the rest can be reclaimed. + +/proc/meminfo's Unevictable and Mlocked amounts do not include those parts +of a transparent huge page which are mapped only by PTEs in VM_LOCKED VMAs. -See also comment in follow_trans_huge_pmd(). mmap(MAP_LOCKED) System Call Handling ------------------------------------- -In addition the mlock()/mlockall() system calls, an application can request -that a region of memory be mlocked supplying the MAP_LOCKED flag to the mmap() -call. There is one important and subtle difference here, though. mmap() + mlock() -will fail if the range cannot be faulted in (e.g. because mm_populate fails) -and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. The mmaped -area will still have properties of the locked area - aka. pages will not get -swapped out - but major page faults to fault memory in might still happen. +In addition to the mlock(), mlock2() and mlockall() system calls, an application +can request that a region of memory be mlocked by supplying the MAP_LOCKED flag +to the mmap() call. There is one important and subtle difference here, though. +mmap() + mlock() will fail if the range cannot be faulted in (e.g. because +mm_populate fails) and returns with ENOMEM while mmap(MAP_LOCKED) will not fail. +The mmaped area will still have properties of the locked area - pages will not +get swapped out - but major page faults to fault memory in might still happen. -Furthermore, any mmap() call or brk() call that expands the heap by a -task that has previously called mlockall() with the MCL_FUTURE flag will result +Furthermore, any mmap() call or brk() call that expands the heap by a task +that has previously called mlockall() with the MCL_FUTURE flag will result in the newly mapped memory being mlocked. Before the unevictable/mlock -changes, the kernel simply called make_pages_present() to allocate pages and -populate the page table. +changes, the kernel simply called make_pages_present() to allocate pages +and populate the page table. -To mlock a range of memory under the unevictable/mlock infrastructure, the -mmap() handler and task address space expansion functions call +To mlock a range of memory under the unevictable/mlock infrastructure, +the mmap() handler and task address space expansion functions call populate_vma_page_range() specifying the vma and the address range to mlock. -The callers of populate_vma_page_range() will have already added the memory range -to be mlocked to the task's "locked_vm". To account for filtered VMAs, -populate_vma_page_range() returns the number of pages NOT mlocked. All of the -callers then subtract a non-negative return value from the task's locked_vm. A -negative return value represent an error - for example, from get_user_pages() -attempting to fault in a VMA with PROT_NONE access. In this case, we leave the -memory range accounted as locked_vm, as the protections could be changed later -and pages allocated into that region. - munmap()/exit()/exec() System Call Handling ------------------------------------------- @@ -500,81 +482,53 @@ munlock the pages if we're removing the last VM_LOCKED VMA that maps the pages. Before the unevictable/mlock changes, mlocking did not mark the pages in any way, so unmapping them required no processing. -To munlock a range of memory under the unevictable/mlock infrastructure, the -munmap() handler and task address space call tear down function -munlock_vma_pages_all(). The name reflects the observation that one always -specifies the entire VMA range when munlock()ing during unmap of a region. -Because of the VMA filtering when mlocking() regions, only "normal" VMAs that -actually contain mlocked pages will be passed to munlock_vma_pages_all(). - -munlock_vma_pages_all() clears the VM_LOCKED VMA flag and, like mlock_fixup() -for the munlock case, calls __munlock_vma_pages_range() to walk the page table -for the VMA's memory range and munlock_vma_page() each resident page mapped by -the VMA. This effectively munlocks the page, only if this is the last -VM_LOCKED VMA that maps the page. - - -try_to_unmap() --------------- - -Pages can, of course, be mapped into multiple VMAs. Some of these VMAs may -have VM_LOCKED flag set. It is possible for a page mapped into one or more -VM_LOCKED VMAs not to have the PG_mlocked flag set and therefore reside on one -of the active or inactive LRU lists. This could happen if, for example, a task -in the process of munlocking the page could not isolate the page from the LRU. -As a result, vmscan/shrink_page_list() might encounter such a page as described -in section "vmscan's handling of unevictable pages". To handle this situation, -try_to_unmap() checks for VM_LOCKED VMAs while it is walking a page's reverse -map. - -try_to_unmap() is always called, by either vmscan for reclaim or for page -migration, with the argument page locked and isolated from the LRU. Separate -functions handle anonymous and mapped file and KSM pages, as these types of -pages have different reverse map lookup mechanisms, with different locking. -In each case, whether rmap_walk_anon() or rmap_walk_file() or rmap_walk_ksm(), -it will call try_to_unmap_one() for every VMA which might contain the page. - -When trying to reclaim, if try_to_unmap_one() finds the page in a VM_LOCKED -VMA, it will then mlock the page via mlock_vma_page() instead of unmapping it, -and return SWAP_MLOCK to indicate that the page is unevictable: and the scan -stops there. - -mlock_vma_page() is called while holding the page table's lock (in addition -to the page lock, and the rmap lock): to serialize against concurrent mlock or -munlock or munmap system calls, mm teardown (munlock_vma_pages_all), reclaim, -holepunching, and truncation of file pages and their anonymous COWed pages. - - -page_mlock() Reverse Map Scan ---------------------------------- - -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 page_mlock(). - -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 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 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. +For each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls +munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED +(unless it was a PTE mapping of a part of a transparent huge page). + +munlock_page() uses the mlock pagevec to batch up work to be done under +lru_lock by __munlock_page(). __munlock_page() decrements the page's +mlock_count, and when that reaches 0 it clears PageMlocked and clears +PageUnevictable, moving the page from unevictable state to inactive LRU. + +But in practice that may not work ideally: the page may not yet have reached +"the unevictable LRU", or it may have been temporarily isolated from it. In +those cases its mlock_count field is unusable and must be assumed to be 0: so +that the page will be rescued to an evictable LRU, then perhaps be mlocked +again later if vmscan finds it in a VM_LOCKED VMA. + + +Truncating MLOCKED Pages +------------------------ + +File truncation or hole punching forcibly unmaps the deleted pages from +userspace; truncation even unmaps and deletes any private anonymous pages +which had been Copied-On-Write from the file pages now being truncated. + +Mlocked pages can be munlocked and deleted in this way: like with munmap(), +for each PTE (or PMD) being unmapped from a VMA, page_remove_rmap() calls +munlock_vma_page(), which calls munlock_page() when the VMA is VM_LOCKED +(unless it was a PTE mapping of a part of a transparent huge page). + +However, if there is a racing munlock(), since mlock_vma_pages_range() starts +munlocking by clearing VM_LOCKED from a VMA, before munlocking all the pages +present, if one of those pages were unmapped by truncation or hole punch before +mlock_pte_range() reached it, it would not be recognized as mlocked by this VMA, +and would not be counted out of mlock_count. In this rare case, a page may +still appear as PageMlocked after it has been fully unmapped: and it is left to +release_pages() (or __page_cache_release()) to clear it and update statistics +before freeing (this event is counted in /proc/vmstat unevictable_pgs_cleared, +which is usually 0). Page Reclaim in shrink_*_list() ------------------------------- -shrink_active_list() culls any obviously unevictable pages - i.e. -!page_evictable(page) - diverting these to the unevictable list. +vmscan's shrink_active_list() culls any obviously unevictable pages - +i.e. !page_evictable(page) pages - diverting those to the unevictable list. However, shrink_active_list() only sees unevictable pages that made it onto the -active/inactive lru lists. Note that these pages do not have PageUnevictable -set - otherwise they would be on the unevictable list and shrink_active_list +active/inactive LRU lists. Note that these pages do not have PageUnevictable +set - otherwise they would be on the unevictable list and shrink_active_list() would never see them. Some examples of these unevictable pages on the LRU lists are: @@ -586,20 +540,15 @@ Some examples of these unevictable pages on the LRU lists are: when an application accesses the page the first time after SHM_LOCK'ing the segment. - (3) mlocked pages that could not be isolated from the LRU and moved to the - unevictable list in mlock_vma_page(). - -shrink_inactive_list() also diverts any unevictable pages that it finds on the -inactive lists to the appropriate node's unevictable list. + (3) pages still mapped into VM_LOCKED VMAs, which should be marked mlocked, + but events left mlock_count too low, so they were munlocked too early. -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 page_mlock(). shrink_inactive_list() won't notice the latter, -but will pass on to shrink_page_list(). +vmscan's shrink_inactive_list() and shrink_page_list() also divert obviously +unevictable pages found on the inactive lists to the appropriate memory cgroup +and node unevictable list. -shrink_page_list() again culls obviously unevictable pages that it could -encounter for similar reason to shrink_inactive_list(). Pages mapped into -VM_LOCKED VMAs but without PG_mlocked set will make it all the way to -try_to_unmap(). shrink_page_list() will divert them to the unevictable list -when try_to_unmap() returns SWAP_MLOCK, as discussed above. +rmap's page_referenced_one(), called via vmscan's shrink_active_list() or +shrink_page_list(), and rmap's try_to_unmap_one() called via shrink_page_list(), +check for (3) pages still mapped into VM_LOCKED VMAs, and call mlock_vma_page() +to correct them. Such pages are culled to the unevictable list when released +by the shrinker. diff --git a/Documentation/x86/amd_hsmp.rst b/Documentation/x86/amd_hsmp.rst new file mode 100644 index 000000000000..440e4b645a1c --- /dev/null +++ b/Documentation/x86/amd_hsmp.rst @@ -0,0 +1,86 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================ +AMD HSMP interface +============================================ + +Newer Fam19h EPYC server line of processors from AMD support system +management functionality via HSMP (Host System Management Port). + +The Host System Management Port (HSMP) is an interface to provide +OS-level software with access to system management functions via a +set of mailbox registers. + +More details on the interface can be found in chapter +"7 Host System Management Port (HSMP)" of the family/model PPR +Eg: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip + +HSMP interface is supported on EPYC server CPU models only. + + +HSMP device +============================================ + +amd_hsmp driver under the drivers/platforms/x86/ creates miscdevice +/dev/hsmp to let user space programs run hsmp mailbox commands. + +$ ls -al /dev/hsmp +crw-r--r-- 1 root root 10, 123 Jan 21 21:41 /dev/hsmp + +Characteristics of the dev node: + * Write mode is used for running set/configure commands + * Read mode is used for running get/status monitor commands + +Access restrictions: + * Only root user is allowed to open the file in write mode. + * The file can be opened in read mode by all the users. + +In-kernel integration: + * Other subsystems in the kernel can use the exported transport + function hsmp_send_message(). + * Locking across callers is taken care by the driver. + + +An example +========== + +To access hsmp device from a C program. +First, you need to include the headers:: + + #include <linux/amd_hsmp.h> + +Which defines the supported messages/message IDs. + +Next thing, open the device file, as follows:: + + int file; + + file = open("/dev/hsmp", O_RDWR); + if (file < 0) { + /* ERROR HANDLING; you can check errno to see what went wrong */ + exit(1); + } + +The following IOCTL is defined: + +``ioctl(file, HSMP_IOCTL_CMD, struct hsmp_message *msg)`` + The argument is a pointer to a:: + + struct hsmp_message { + __u32 msg_id; /* Message ID */ + __u16 num_args; /* Number of input argument words in message */ + __u16 response_sz; /* Number of expected output/response words */ + __u32 args[HSMP_MAX_MSG_LEN]; /* argument/response buffer */ + __u16 sock_ind; /* socket number */ + }; + +The ioctl would return a non-zero on failure; you can read errno to see +what happened. The transaction returns 0 on success. + +More details on the interface and message definitions can be found in chapter +"7 Host System Management Port (HSMP)" of the respective family/model PPR +eg: https://www.amd.com/system/files/TechDocs/55898_B1_pub_0.50.zip + +User space C-APIs are made available by linking against the esmi library, +which is provided by the E-SMS project https://developer.amd.com/e-sms/. +See: https://github.com/amd/esmi_ib_library diff --git a/Documentation/x86/index.rst b/Documentation/x86/index.rst index f498f1d36cd3..91b2fa456618 100644 --- a/Documentation/x86/index.rst +++ b/Documentation/x86/index.rst @@ -21,9 +21,11 @@ x86-specific Documentation tlb mtrr pat + intel-hfi intel-iommu intel_txt amd-memory-encryption + amd_hsmp pti mds microcode diff --git a/Documentation/x86/intel-hfi.rst b/Documentation/x86/intel-hfi.rst new file mode 100644 index 000000000000..49dea58ea4fb --- /dev/null +++ b/Documentation/x86/intel-hfi.rst @@ -0,0 +1,72 @@ +.. SPDX-License-Identifier: GPL-2.0 + +============================================================ +Hardware-Feedback Interface for scheduling on Intel Hardware +============================================================ + +Overview +-------- + +Intel has described the Hardware Feedback Interface (HFI) in the Intel 64 and +IA-32 Architectures Software Developer's Manual (Intel SDM) Volume 3 Section +14.6 [1]_. + +The HFI gives the operating system a performance and energy efficiency +capability data for each CPU in the system. Linux can use the information from +the HFI to influence task placement decisions. + +The Hardware Feedback Interface +------------------------------- + +The Hardware Feedback Interface provides to the operating system information +about the performance and energy efficiency of each CPU in the system. Each +capability is given as a unit-less quantity in the range [0-255]. Higher values +indicate higher capability. Energy efficiency and performance are reported in +separate capabilities. Even though on some systems these two metrics may be +related, they are specified as independent capabilities in the Intel SDM. + +These capabilities may change at runtime as a result of changes in the +operating conditions of the system or the action of external factors. The rate +at which these capabilities are updated is specific to each processor model. On +some models, capabilities are set at boot time and never change. On others, +capabilities may change every tens of milliseconds. For instance, a remote +mechanism may be used to lower Thermal Design Power. Such change can be +reflected in the HFI. Likewise, if the system needs to be throttled due to +excessive heat, the HFI may reflect reduced performance on specific CPUs. + +The kernel or a userspace policy daemon can use these capabilities to modify +task placement decisions. For instance, if either the performance or energy +capabilities of a given logical processor becomes zero, it is an indication that +the hardware recommends to the operating system to not schedule any tasks on +that processor for performance or energy efficiency reasons, respectively. + +Implementation details for Linux +-------------------------------- + +The infrastructure to handle thermal event interrupts has two parts. In the +Local Vector Table of a CPU's local APIC, there exists a register for the +Thermal Monitor Register. This register controls how interrupts are delivered +to a CPU when the thermal monitor generates and interrupt. Further details +can be found in the Intel SDM Vol. 3 Section 10.5 [1]_. + +The thermal monitor may generate interrupts per CPU or per package. The HFI +generates package-level interrupts. This monitor is configured and initialized +via a set of machine-specific registers. Specifically, the HFI interrupt and +status are controlled via designated bits in the IA32_PACKAGE_THERM_INTERRUPT +and IA32_PACKAGE_THERM_STATUS registers, respectively. There exists one HFI +table per package. Further details can be found in the Intel SDM Vol. 3 +Section 14.9 [1]_. + +The hardware issues an HFI interrupt after updating the HFI table and is ready +for the operating system to consume it. CPUs receive such interrupt via the +thermal entry in the Local APIC's Local Vector Table. + +When servicing such interrupt, the HFI driver parses the updated table and +relays the update to userspace using the thermal notification framework. Given +that there may be many HFI updates every second, the updates relayed to +userspace are throttled at a rate of CONFIG_HZ jiffies. + +References +---------- + +.. [1] https://www.intel.com/sdm diff --git a/Documentation/x86/sva.rst b/Documentation/x86/sva.rst index 076efd51ef1f..2e9b8b0f9a0f 100644 --- a/Documentation/x86/sva.rst +++ b/Documentation/x86/sva.rst @@ -104,18 +104,47 @@ The MSR must be configured on each logical CPU before any application thread can interact with a device. Threads that belong to the same process share the same page tables, thus the same MSR value. -PASID is cleared when a process is created. The PASID allocation and MSR -programming may occur long after a process and its threads have been created. -One thread must call iommu_sva_bind_device() to allocate the PASID for the -process. If a thread uses ENQCMD without the MSR first being populated, a #GP -will be raised. The kernel will update the PASID MSR with the PASID for all -threads in the process. A single process PASID can be used simultaneously -with multiple devices since they all share the same address space. - -One thread can call iommu_sva_unbind_device() to free the allocated PASID. -The kernel will clear the PASID MSR for all threads belonging to the process. - -New threads inherit the MSR value from the parent. +PASID Life Cycle Management +=========================== + +PASID is initialized as INVALID_IOASID (-1) when a process is created. + +Only processes that access SVA-capable devices need to have a PASID +allocated. This allocation happens when a process opens/binds an SVA-capable +device but finds no PASID for this process. Subsequent binds of the same, or +other devices will share the same PASID. + +Although the PASID is allocated to the process by opening a device, +it is not active in any of the threads of that process. It's loaded to the +IA32_PASID MSR lazily when a thread tries to submit a work descriptor +to a device using the ENQCMD. + +That first access will trigger a #GP fault because the IA32_PASID MSR +has not been initialized with the PASID value assigned to the process +when the device was opened. The Linux #GP handler notes that a PASID has +been allocated for the process, and so initializes the IA32_PASID MSR +and returns so that the ENQCMD instruction is re-executed. + +On fork(2) or exec(2) the PASID is removed from the process as it no +longer has the same address space that it had when the device was opened. + +On clone(2) the new task shares the same address space, so will be +able to use the PASID allocated to the process. The IA32_PASID is not +preemptively initialized as the PASID value might not be allocated yet or +the kernel does not know whether this thread is going to access the device +and the cleared IA32_PASID MSR reduces context switch overhead by xstate +init optimization. Since #GP faults have to be handled on any threads that +were created before the PASID was assigned to the mm of the process, newly +created threads might as well be treated in a consistent way. + +Due to complexity of freeing the PASID and clearing all IA32_PASID MSRs in +all threads in unbind, free the PASID lazily only on mm exit. + +If a process does a close(2) of the device file descriptor and munmap(2) +of the device MMIO portal, then the driver will unbind the device. The +PASID is still marked VALID in the PASID_MSR for any threads in the +process that accessed the device. But this is harmless as without the +MMIO portal they cannot submit new work to the device. Relationships ============= diff --git a/Documentation/x86/x86_64/boot-options.rst b/Documentation/x86/x86_64/boot-options.rst index ccb7e86bf8d9..07aa0007f346 100644 --- a/Documentation/x86/x86_64/boot-options.rst +++ b/Documentation/x86/x86_64/boot-options.rst @@ -47,14 +47,7 @@ Please see Documentation/x86/x86_64/machinecheck.rst for sysfs runtime tunables. in a reboot. On Intel systems it is enabled by default. mce=nobootlog Disable boot machine check logging. - mce=tolerancelevel[,monarchtimeout] (number,number) - tolerance levels: - 0: always panic on uncorrected errors, log corrected errors - 1: panic or SIGBUS on uncorrected errors, log corrected errors - 2: SIGBUS or log uncorrected errors, log corrected errors - 3: never panic or SIGBUS, log all errors (for testing only) - Default is 1 - Can be also set using sysfs which is preferable. + mce=monarchtimeout (number) monarchtimeout: Sets the time in us to wait for other CPUs on machine checks. 0 to disable. |