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

Merge tag 'v6.10-rc1' into android-mainline

Browse Source 
Linux 6.10-rc1

Change-Id: Idb352b80ec4035982950ab2aec3bf3fbf4323ec3
Signed-off-by: Matthias Maennich <maennich@google.com>
Signed-off-by: Will McVicker <willmcvicker@google.com>
This commit is contained in:
Will McVicker committed 2024-08-05 09:42:59 -07:00
2 parents 947bacdf1f 1613e604df
commit 4cf63363a7
8598 files changed
+337134 -177365
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

.mailmap
+1 -1
View File
@@ -572,7 +572,7 @@ Sarangdhar Joshi <spjoshi@codeaurora.org>
Sascha Hauer <s.hauer@pengutronix.de>
Sahitya Tummala <quic_stummala@quicinc.com> <stummala@codeaurora.org>
Sathishkumar Muruganandam <quic_murugana@quicinc.com> <murugana@codeaurora.org>
Satya Priya <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
Satya Priya <quic_skakitap@quicinc.com> <quic_c_skakit@quicinc.com> <skakit@codeaurora.org>
S.Çağlar Onur <caglar@pardus.org.tr>
Sayali Lokhande <quic_sayalil@quicinc.com> <sayalil@codeaurora.org>
Sean Christopherson <seanjc@google.com> <sean.j.christopherson@intel.com>
Documentation/ABI/stable/sysfs-bus-mhi
+13
View File
@@ -29,3 +29,16 @@ Description: Initiates a SoC reset on the MHI controller. A SoC reset is
This can be useful as a method of recovery if the device is
non-responsive, or as a means of loading new firmware as a
system administration task.
What: /sys/bus/mhi/devices/.../trigger_edl
Date: April 2024
KernelVersion: 6.10
Contact: mhi@lists.linux.dev
Description: Writing a non-zero value to this file will force devices to
enter EDL (Emergency Download) mode. This entry only exists for
devices capable of entering the EDL mode using the standard EDL
triggering mechanism defined in the MHI spec v1.2. Once in EDL
mode, the flash programmer image can be downloaded to the
device to enter the flash programmer execution environment.
This can be useful if user wants to use QDL (Qualcomm Download,
which is used to download firmware over EDL) to update firmware.
Documentation/ABI/testing/debugfs-msi-wmi-platform
+14
View File
@@ -0,0 +1,14 @@
What: /sys/kernel/debug/msi-wmi-platform-<wmi_device_name>/*
Date: April 2024
KernelVersion: 6.10
Contact: Armin Wolf <W_Armin@gmx.de>
Description:
This file allows to execute the associated WMI method with the same name.
To start the execution, write a buffer containing the method arguments
at file offset 0. Partial writes or writes at a different offset are not
supported.
The buffer returned by the WMI method can then be read from the file.
See Documentation/wmi/devices/msi-wmi-platform.rst for details.
Documentation/ABI/testing/sysfs-bus-coresight-devices-etm3x
+1 -1
View File
@@ -22,7 +22,7 @@ Contact: Mathieu Poirier <mathieu.poirier@linaro.org>
Description: (RW) Used in conjunction with @addr_idx. Specifies
characteristics about the address comparator being configure,
for example the access type, the kind of instruction to trace,
processor contect ID to trigger on, etc. Individual fields in
processor context ID to trigger on, etc. Individual fields in
the access type register may vary on the version of the trace
entity.
Documentation/ABI/testing/sysfs-bus-coresight-devices-tmc
+1 -1
View File
@@ -97,7 +97,7 @@ Date: August 2023
KernelVersion: 6.7
Contact: Anshuman Khandual <anshuman.khandual@arm.com>
Description: (Read) Shows all supported Coresight TMC-ETR buffer modes available
for the users to configure explicitly. This file is avaialble only
for the users to configure explicitly. This file is available only
for TMC ETR devices.
What: /sys/bus/coresight/devices/<memory_map>.tmc/buf_mode_preferred
Documentation/ABI/testing/sysfs-bus-coresight-devices-tpdm
+1 -1
View File
@@ -244,7 +244,7 @@ KernelVersion 6.9
Contact: Jinlong Mao (QUIC) <quic_jinlmao@quicinc.com>, Tao Zhang (QUIC) <quic_taozha@quicinc.com>
Description:
(RW) Read or write the status of timestamp upon all interface.
Only value 0 and 1 can be written to this node. Set this node to 1 to requeset
Only value 0 and 1 can be written to this node. Set this node to 1 to request
timestamp to all trace packet.
Accepts only one of the 2 values - 0 or 1.
0 : Disable the timestamp of all trace packets.
Documentation/ABI/testing/sysfs-bus-event_source-devices-events
+6
View File
@@ -37,6 +37,12 @@ Description: Per-pmu performance monitoring events specific to the running syste
performance monitoring event supported by the <pmu>. The name
of the file is the name of the event.
As performance monitoring event names are case
insensitive in the perf tool, the perf tool only looks
for lower or upper case event names in sysfs to avoid
scanning the directory. It is therefore required the
name of the event here is either lower or upper case.
File contents:
<term>[=<value>][,<term>[=<value>]]...
Documentation/ABI/testing/sysfs-devices-hisi_ptt → Documentation/ABI/testing/sysfs-bus-event_source-devices-hisi_ptt
+6 -6
View File
@@ -1,4 +1,4 @@
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
@@ -8,7 +8,7 @@ Description: This directory contains files for tuning the PCIe link
See Documentation/trace/hisi-ptt.rst for more information.
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_cpl
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
@@ -18,7 +18,7 @@ Description: (RW) Controls the weight of Tx completion TLPs, which influence
will return an error, and out of range values will be converted
to 2. The value indicates a probable level of the event.
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_np
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
@@ -28,7 +28,7 @@ Description: (RW) Controls the weight of Tx non-posted TLPs, which influence
will return an error, and out of range values will be converted
to 2. The value indicates a probable level of the event.
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/qos_tx_p
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
@@ -38,7 +38,7 @@ Description: (RW) Controls the weight of Tx posted TLPs, which influence the
will return an error, and out of range values will be converted
to 2. The value indicates a probable level of the event.
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/rx_alloc_buf_level
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
@@ -49,7 +49,7 @@ Description: (RW) Control the allocated buffer watermark for inbound packets.
will return an error, and out of range values will be converted
to 2. The value indicates a probable level of the event.
What: /sys/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
What: /sys/bus/event_source/devices/hisi_ptt<sicl_id>_<core_id>/tune/tx_alloc_buf_level
Date: October 2022
KernelVersion: 6.1
Contact: Yicong Yang <yangyicong@hisilicon.com>
Documentation/ABI/testing/sysfs-bus-iio
+2 -1
View File
@@ -243,7 +243,8 @@ Description:
less measurements. Units after application of scale and offset
are milli degrees Celsius.
What: /sys/bus/iio/devices/iio:deviceX/in_tempX_input
What: /sys/bus/iio/devices/iio:deviceX/in_tempY_input
What: /sys/bus/iio/devices/iio:deviceX/in_temp_input
KernelVersion: 2.6.38
Contact: linux-iio@vger.kernel.org
Description:
Documentation/ABI/testing/sysfs-bus-iio-ad9739a
+19
View File
@@ -0,0 +1,19 @@
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_operating_mode
KernelVersion: 6.9
Contact: linux-iio@vger.kernel.org
Description:
DAC operating mode. One of the following modes can be selected:
* normal: This is DAC normal mode.
* mixed-mode: In this mode the output is effectively chopped at
the DAC sample rate. This has the effect of
reducing the power of the fundamental signal while
increasing the power of the images centered around
the DAC sample rate, thus improving the output
power of these images.
What: /sys/bus/iio/devices/iio:deviceX/out_voltageY_operating_mode_available
KernelVersion: 6.9
Contact: linux-iio@vger.kernel.org
Description:
Available operating modes.
Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-hub → Documentation/ABI/testing/sysfs-bus-platform-onboard-usb-dev
+2 -1
View File
@@ -5,4 +5,5 @@ Contact: Matthias Kaehlcke <matthias@kaehlcke.net>
linux-usb@vger.kernel.org
Description:
(RW) Controls whether the USB hub remains always powered
during system suspend or not.
during system suspend or not. This attribute is not
available for non-hub devices.
Documentation/ABI/testing/sysfs-class-led-trigger-pattern
+10
View File
@@ -12,6 +12,16 @@ Description:
The exact format is described in:
Documentation/devicetree/bindings/leds/leds-trigger-pattern.txt
What: /sys/class/leds/<led>/hr_pattern
Date: April 2024
Description:
Specify a software pattern for the LED, that supports altering
the brightness for the specified duration with one software
timer. It can do gradual dimming and step change of brightness.
Unlike the /sys/class/leds/<led>/pattern, this attribute runs
a pattern on high-resolution timer (hrtimer).
What: /sys/class/leds/<led>/hw_pattern
Date: September 2018
KernelVersion: 4.20
Documentation/ABI/testing/sysfs-devices-system-cpu
+7 -7
View File
@@ -423,7 +423,7 @@ What: /sys/devices/system/cpu/cpuX/cpufreq/throttle_stats
/sys/devices/system/cpu/cpuX/cpufreq/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
@@ -473,7 +473,7 @@ What: /sys/devices/system/cpu/cpufreq/policyX/throttle_stats
/sys/devices/system/cpu/cpufreq/policyX/throttle_stats/occ_reset
Date: March 2016
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: POWERNV CPUFreq driver's frequency throttle stats directory and
attributes
@@ -608,7 +608,7 @@ Description: Umwait control
What: /sys/devices/system/cpu/svm
Date: August 2019
Contact: Linux kernel mailing list <linux-kernel@vger.kernel.org>
Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Secure Virtual Machine
If 1, it means the system is using the Protected Execution
@@ -617,7 +617,7 @@ Description: Secure Virtual Machine
What: /sys/devices/system/cpu/cpuX/purr
Date: Apr 2005
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PURR ticks for this CPU since the system boot.
The Processor Utilization Resources Register (PURR) is
@@ -628,7 +628,7 @@ Description: PURR ticks for this CPU since the system boot.
What: /sys/devices/system/cpu/cpuX/spurr
Date: Dec 2006
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: SPURR ticks for this CPU since the system boot.
The Scaled Processor Utilization Resources Register
@@ -640,7 +640,7 @@ Description: SPURR ticks for this CPU since the system boot.
What: /sys/devices/system/cpu/cpuX/idle_purr
Date: Apr 2020
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of PURR ticks
@@ -648,7 +648,7 @@ Description: PURR ticks for cpuX when it was idle.
What: /sys/devices/system/cpu/cpuX/idle_spurr
Date: Apr 2020
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: SPURR ticks for cpuX when it was idle.
This sysfs interface exposes the number of SPURR ticks
Documentation/ABI/testing/sysfs-driver-intel-xe-hwmon
+77 -37
View File
@@ -10,7 +10,7 @@ Description: RW. Card reactive sustained (PL1) power limit in microwatts.
power limit is disabled, writing 0 disables the
limit. Writing values > 0 and <= TDP will enable the power limit.
Only supported for particular Intel xe graphics platforms.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_rated_max
Date: September 2023
@@ -18,53 +18,93 @@ KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Card default power limit (default TDP setting).
Only supported for particular Intel xe graphics platforms.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_crit
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RW. Card reactive critical (I1) power limit in microwatts.
Card reactive critical (I1) power limit in microwatts is exposed
for client products. The power controller will throttle the
operating frequency if the power averaged over a window exceeds
this limit.
Only supported for particular Intel xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/curr1_crit
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RW. Card reactive critical (I1) power limit in milliamperes.
Card reactive critical (I1) power limit in milliamperes is
exposed for server products. The power controller will throttle
the operating frequency if the power averaged over a window
exceeds this limit.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/in0_input
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Current Voltage in millivolt.
Only supported for particular Intel xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy1_input
Date: September 2023
KernelVersion: 6.5
Contact: intel-xe@lists.freedesktop.org
Description: RO. Energy input of device in microjoules.
Description: RO. Card energy input of device in microjoules.
Only supported for particular Intel xe graphics platforms.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power1_max_interval
Date: October 2023
KernelVersion: 6.6
Contact: intel-xe@lists.freedesktop.org
Description: RW. Sustained power limit interval (Tau in PL1/Tau) in
Description: RW. Card sustained power limit interval (Tau in PL1/Tau) in
milliseconds over which sustained power is averaged.
Only supported for particular Intel xe graphics platforms.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RW. Package reactive sustained (PL1) power limit in microwatts.
The power controller will throttle the operating frequency
if the power averaged over a window (typically seconds)
exceeds this limit. A read value of 0 means that the PL1
power limit is disabled, writing 0 disables the
limit. Writing values > 0 and <= TDP will enable the power limit.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_rated_max
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RO. Package default power limit (default TDP setting).
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_crit
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RW. Package reactive critical (I1) power limit in microwatts.
Package reactive critical (I1) power limit in microwatts is exposed
for client products. The power controller will throttle the
operating frequency if the power averaged over a window exceeds
this limit.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/curr2_crit
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RW. Package reactive critical (I1) power limit in milliamperes.
Package reactive critical (I1) power limit in milliamperes is
exposed for server products. The power controller will throttle
the operating frequency if the power averaged over a window
exceeds this limit.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/energy2_input
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RO. Package energy input of device in microjoules.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/power2_max_interval
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RW. Package sustained power limit interval (Tau in PL1/Tau) in
milliseconds over which sustained power is averaged.
Only supported for particular Intel Xe graphics platforms.
What: /sys/bus/pci/drivers/xe/.../hwmon/hwmon<i>/in1_input
Date: February 2024
KernelVersion: 6.8
Contact: intel-xe@lists.freedesktop.org
Description: RO. Package current voltage in millivolt.
Only supported for particular Intel Xe graphics platforms.
Documentation/ABI/testing/sysfs-driver-panfrost-profiling
+10
View File
@@ -0,0 +1,10 @@
What: /sys/bus/platform/drivers/panfrost/.../profiling
Date: February 2024
KernelVersion: 6.8.0
Contact: Adrian Larumbe <adrian.larumbe@collabora.com>
Description:
Get/set drm fdinfo's engine and cycles profiling status.
Valid values are:
0: Don't enable fdinfo job profiling sources.
1: Enable fdinfo job profiling sources, this enables both the GPU's
timestamp and cycle counter registers.
Documentation/ABI/testing/sysfs-firmware-opal-powercap
+2 -2
View File
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/powercap
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Powercap directory for Powernv (P8, P9) servers
Each folder in this directory contains a
@@ -11,7 +11,7 @@ What: /sys/firmware/opal/powercap/system-powercap
/sys/firmware/opal/powercap/system-powercap/powercap-max
/sys/firmware/opal/powercap/system-powercap/powercap-current
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: System powercap directory and attributes applicable for
Powernv (P8, P9) servers
Documentation/ABI/testing/sysfs-firmware-opal-psr
+2 -2
View File
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/psr
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Power-Shift-Ratio directory for Powernv P9 servers
Power-Shift-Ratio allows to provide hints the firmware
@@ -10,7 +10,7 @@ Description: Power-Shift-Ratio directory for Powernv P9 servers
What: /sys/firmware/opal/psr/cpu_to_gpu_X
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: PSR sysfs attributes for Powernv P9 servers
Power-Shift-Ratio between CPU and GPU for a given chip
Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups
+2 -2
View File
@@ -1,6 +1,6 @@
What: /sys/firmware/opal/sensor_groups
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Sensor groups directory for POWER9 powernv servers
Each folder in this directory contains a sensor group
@@ -11,7 +11,7 @@ Description: Sensor groups directory for POWER9 powernv servers
What: /sys/firmware/opal/sensor_groups/<sensor_group_name>/clear
Date: August 2017
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Sysfs file to clear the min-max of all the sensors
belonging to the group.
Documentation/ABI/testing/sysfs-firmware-papr-energy-scale-info
+5 -5
View File
@@ -1,6 +1,6 @@
What: /sys/firmware/papr/energy_scale_info
Date: February 2022
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: Directory hosting a set of platform attributes like
energy/frequency on Linux running as a PAPR guest.
@@ -10,20 +10,20 @@ Description: Directory hosting a set of platform attributes like
What: /sys/firmware/papr/energy_scale_info/<id>
Date: February 2022
Contact: Linux for PowerPC mailing list <linuxppc-dev@ozlabs.org>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.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>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.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>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.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>
Contact: Linux for PowerPC mailing list <linuxppc-dev@lists.ozlabs.org>
Description: String value of the energy attribute of <id>
Documentation/ABI/testing/sysfs-fs-f2fs
+1 -1
View File
@@ -331,7 +331,7 @@ Date: January 2018
Contact: Jaegeuk Kim <jaegeuk@kernel.org>
Description: This indicates how many GC can be failed for the pinned
file. If it exceeds this, F2FS doesn't guarantee its pinning
state. 2048 trials is set by default.
state. 2048 trials is set by default, and 65535 as maximum.
What: /sys/fs/f2fs/<disk>/extension_list
Date: February 2018
Documentation/ABI/testing/sysfs-kernel-fadump
+18
View File
@@ -38,3 +38,21 @@ Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Provide information about the amount of memory reserved by
FADump to save the crash dump in bytes.
What: /sys/kernel/fadump/hotplug_ready
Date: Apr 2024
Contact: linuxppc-dev@lists.ozlabs.org
Description: read only
Kdump udev rule re-registers fadump on memory add/remove events,
primarily to update the elfcorehdr. This sysfs indicates the
kdump udev rule that fadump re-registration is not required on
memory add/remove events because elfcorehdr is now prepared in
the second/fadump kernel.
User: kexec-tools
What: /sys/kernel/fadump/bootargs_append
Date: May 2024
Contact: linuxppc-dev@lists.ozlabs.org
Description: read/write
This is a special sysfs file available to setup additional
parameters to be passed to capture kernel.
Documentation/ABI/testing/sysfs-kernel-mm-damon
+3 -3
View File
@@ -314,9 +314,9 @@ Date: Dec 2022
Contact: SeongJae Park <sj@kernel.org>
Description: Writing to and reading from this file sets and gets the type of
the memory of the interest. 'anon' for anonymous pages,
'memcg' for specific memory cgroup, 'addr' for address range
(an open-ended interval), or 'target' for DAMON monitoring
target can be written and read.
'memcg' for specific memory cgroup, 'young' for young pages,
'addr' for address range (an open-ended interval), or 'target'
for DAMON monitoring target can be written and read.
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/filters/<F>/memcg_path
Date: Dec 2022
Documentation/ABI/testing/sysfs-kernel-mm-transparent-hugepage
+18
View File
@@ -0,0 +1,18 @@
What: /sys/kernel/mm/transparent_hugepage/
Date: April 2024
Contact: Linux memory management mailing list <linux-mm@kvack.org>
Description:
/sys/kernel/mm/transparent_hugepage/ contains a number of files and
subdirectories,
- defrag
- enabled
- hpage_pmd_size
- khugepaged
- shmem_enabled
- use_zero_page
- subdirectories of the form hugepages-<size>kB, where <size>
is the page size of the hugepages supported by the kernel/CPU
combination.
See Documentation/admin-guide/mm/transhuge.rst for details.
Documentation/ABI/testing/sysfs-platform-asus-wmi
+26
View File
@@ -126,6 +126,14 @@ Description:
Change the mini-LED mode:
* 0 - Single-zone,
* 1 - Multi-zone
* 2 - Multi-zone strong (available on newer generation mini-led)
What: /sys/devices/platform/<platform>/available_mini_led_mode
Date: Apr 2024
KernelVersion: 6.10
Contact: "Luke Jones" <luke@ljones.dev>
Description:
List the available mini-led modes.
What: /sys/devices/platform/<platform>/ppt_pl1_spl
Date: Jun 2023
@@ -186,3 +194,21 @@ Contact: "Luke Jones" <luke@ljones.dev>
Description:
Set the target temperature limit of the Nvidia dGPU:
* min=75, max=87
What: /sys/devices/platform/<platform>/boot_sound
Date: Apr 2024
KernelVersion: 6.10
Contact: "Luke Jones" <luke@ljones.dev>
Description:
Set if the BIOS POST sound is played on boot.
* 0 - False,
* 1 - True
What: /sys/devices/platform/<platform>/mcu_powersave
Date: Apr 2024
KernelVersion: 6.10
Contact: "Luke Jones" <luke@ljones.dev>
Description:
Set if the MCU can go in to low-power mode on system sleep
* 0 - False,
* 1 - True
Documentation/Makefile
+4 -4
View File
@@ -80,22 +80,22 @@ loop_cmd = $(echo-cmd) $(cmd_$(1)) || exit;
# * dest folder relative to $(BUILDDIR) and
# * cache folder relative to $(BUILDDIR)/.doctrees
# $4 dest subfolder e.g. "man" for man pages at userspace-api/media/man
# $5 reST source folder relative to $(srctree)/$(src),
# $5 reST source folder relative to $(src),
# e.g. "userspace-api/media" for the linux-tv book-set at ./Documentation/userspace-api/media
quiet_cmd_sphinx = SPHINX $@ --> file://$(abspath $(BUILDDIR)/$3/$4)
cmd_sphinx = $(MAKE) BUILDDIR=$(abspath $(BUILDDIR)) $(build)=Documentation/userspace-api/media $2 && \
PYTHONDONTWRITEBYTECODE=1 \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(srctree)/$(src)/$5/$(SPHINX_CONF)) \
BUILDDIR=$(abspath $(BUILDDIR)) SPHINX_CONF=$(abspath $(src)/$5/$(SPHINX_CONF)) \
$(PYTHON3) $(srctree)/scripts/jobserver-exec \
$(CONFIG_SHELL) $(srctree)/Documentation/sphinx/parallel-wrapper.sh \
$(SPHINXBUILD) \
-b $2 \
-c $(abspath $(srctree)/$(src)) \
-c $(abspath $(src)) \
-d $(abspath $(BUILDDIR)/.doctrees/$3) \
-D version=$(KERNELVERSION) -D release=$(KERNELRELEASE) \
$(ALLSPHINXOPTS) \
$(abspath $(srctree)/$(src)/$5) \
$(abspath $(src)/$5) \
$(abspath $(BUILDDIR)/$3/$4) && \
if [ "x$(DOCS_CSS)" != "x" ]; then \
cp $(if $(patsubst /%,,$(DOCS_CSS)),$(abspath $(srctree)/$(DOCS_CSS)),$(DOCS_CSS)) $(BUILDDIR)/$3/_static/; \
Documentation/PCI/msi-howto.rst
+1 -1
View File
@@ -103,7 +103,7 @@ min_vecs argument set to this limit, and the PCI core will return -ENOSPC
if it can't meet the minimum number of vectors.
The flags argument is used to specify which type of interrupt can be used
by the device and the driver (PCI_IRQ_LEGACY, PCI_IRQ_MSI, PCI_IRQ_MSIX).
by the device and the driver (PCI_IRQ_INTX, PCI_IRQ_MSI, PCI_IRQ_MSIX).
A convenient short-hand (PCI_IRQ_ALL_TYPES) is also available to ask for
any possible kind of interrupt. If the PCI_IRQ_AFFINITY flag is set,
pci_alloc_irq_vectors() will spread the interrupts around the available CPUs.
Documentation/PCI/pci.rst
+1 -1
View File
@@ -335,7 +335,7 @@ causes the PCI support to program CPU vector data into the PCI device
capability registers. Many architectures, chip-sets, or BIOSes do NOT
support MSI or MSI-X and a call to pci_alloc_irq_vectors with just
the PCI_IRQ_MSI and PCI_IRQ_MSIX flags will fail, so try to always
specify PCI_IRQ_LEGACY as well.
specify PCI_IRQ_INTX as well.
Drivers that have different interrupt handlers for MSI/MSI-X and
legacy INTx should chose the right one based on the msi_enabled
Documentation/PCI/pcieaer-howto.rst
+1 -1
View File
@@ -241,7 +241,7 @@ After reboot with new kernel or insert the module, a device file named
Then, you need a user space tool named aer-inject, which can be gotten
from:
https://git.kernel.org/cgit/linux/kernel/git/gong.chen/aer-inject.git/
https://github.com/intel/aer-inject.git
More information about aer-inject can be found in the document in
its source code.
Documentation/admin-guide/blockdev/zram.rst
+5
View File
@@ -466,6 +466,11 @@ of equal or greater size:::
#recompress idle pages larger than 2000 bytes
echo "type=idle threshold=2000" > /sys/block/zramX/recompress
It is also possible to limit the number of pages zram re-compression will
attempt to recompress:::
echo "type=huge_idle max_pages=42" > /sys/block/zramX/recompress
Recompression of idle pages requires memory tracking.
During re-compression for every page, that matches re-compression criteria,
Documentation/admin-guide/cgroup-v1/cgroups.rst
+1 -1
View File
@@ -570,7 +570,7 @@ visible to cgroup_for_each_child/descendant_*() iterators. The
subsystem may choose to fail creation by returning -errno. This
callback can be used to implement reliable state sharing and
propagation along the hierarchy. See the comment on
cgroup_for_each_descendant_pre() for details.
cgroup_for_each_live_descendant_pre() for details.
``void css_offline(struct cgroup *cgrp);``
(cgroup_mutex held by caller)
Documentation/admin-guide/cgroup-v1/cpusets.rst
+6 -1
View File
@@ -568,7 +568,7 @@ on the next tick. For some applications in special situation, waiting
The 'cpuset.sched_relax_domain_level' file allows you to request changing
this searching range as you like. This file takes int value which
indicates size of searching range in levels ideally as follows,
indicates size of searching range in levels approximately as follows,
otherwise initial value -1 that indicates the cpuset has no request.
====== ===========================================================
@@ -581,6 +581,11 @@ otherwise initial value -1 that indicates the cpuset has no request.
5 search system wide [on NUMA system]
====== ===========================================================
Not all levels can be present and values can change depending on the
system architecture and kernel configuration. Check
/sys/kernel/debug/sched/domains/cpu*/domain*/ for system-specific
details.
The system default is architecture dependent. The system default
can be changed using the relax_domain_level= boot parameter.
Documentation/admin-guide/cgroup-v1/memcg_test.rst
+1 -1
View File
@@ -102,7 +102,7 @@ Under below explanation, we assume CONFIG_SWAP=y.
The logic is very clear. (About migration, see below)
Note:
__remove_from_page_cache() is called by remove_from_page_cache()
__filemap_remove_folio() is called by filemap_remove_folio()
and __remove_mapping().
6. Shmem(tmpfs) Page Cache
Documentation/admin-guide/cgroup-v1/memory.rst
+4 -4
View File
@@ -300,14 +300,14 @@ When oom event notifier is registered, event will be delivered.
Lock order is as follows::
Page lock (PG_locked bit of page->flags)
folio_lock
mm->page_table_lock or split pte_lock
folio_memcg_lock (memcg->move_lock)
mapping->i_pages lock
lruvec->lru_lock.
Per-node-per-memcgroup LRU (cgroup's private LRU) is guarded by
lruvec->lru_lock; PG_lru bit of page->flags is cleared before
lruvec->lru_lock; the folio LRU flag is cleared before
isolating a page from its LRU under lruvec->lru_lock.
.. _cgroup-v1-memory-kernel-extension:
@@ -802,8 +802,8 @@ a page or a swap can be moved only when it is charged to the task's current
| | anonymous pages, file pages (and swaps) in the range mmapped by the task |
| | will be moved even if the task hasn't done page fault, i.e. they might |
| | not be the task's "RSS", but other task's "RSS" that maps the same file. |
| | And mapcount of the page is ignored (the page can be moved even if |
| | page_mapcount(page) > 1). You must enable Swap Extension (see 2.4) to |
| | The mapcount of the page is ignored (the page can be moved independent |
| | of the mapcount). You must enable Swap Extension (see 2.4) to |
| | enable move of swap charges. |
+---+--------------------------------------------------------------------------+
Documentation/admin-guide/cgroup-v2.rst
+25 -8
View File
@@ -1058,12 +1058,15 @@ cpufreq governor about the minimum desired frequency which should always be
provided by a CPU, as well as the maximum desired frequency, which should not
be exceeded by a CPU.
WARNING: cgroup2 doesn't yet support control of realtime processes and
the cpu controller can only be enabled when all RT processes are in
the root cgroup. Be aware that system management software may already
have placed RT processes into nonroot cgroups during the system boot
process, and these processes may need to be moved to the root cgroup
before the cpu controller can be enabled.
WARNING: cgroup2 doesn't yet support control of realtime processes. For
a kernel built with the CONFIG_RT_GROUP_SCHED option enabled for group
scheduling of realtime processes, the cpu controller can only be enabled
when all RT processes are in the root cgroup. This limitation does
not apply if CONFIG_RT_GROUP_SCHED is disabled. Be aware that system
management software may already have placed RT processes into nonroot
cgroups during the system boot process, and these processes may need
to be moved to the root cgroup before the cpu controller can be enabled
with a CONFIG_RT_GROUP_SCHED enabled kernel.
CPU Interface Files
@@ -1432,7 +1435,7 @@ PAGE_SIZE multiple when read back.
sec_pagetables
Amount of memory allocated for secondary page tables,
this currently includes KVM mmu allocations on x86
and arm64.
and arm64 and IOMMU page tables.
percpu (npn)
Amount of memory used for storing per-cpu kernel
@@ -2190,11 +2193,25 @@ PID Interface Files
Hard limit of number of processes.
pids.current
A read-only single value file which exists on all cgroups.
A read-only single value file which exists on non-root cgroups.
The number of processes currently in the cgroup and its
descendants.
pids.peak
A read-only single value file which exists on non-root cgroups.
The maximum value that the number of processes in the cgroup and its
descendants has ever reached.
pids.events
A read-only flat-keyed file which exists on non-root cgroups. The
following entries are defined. Unless specified otherwise, a value
change in this file generates a file modified event.
max
Number of times fork failed because limit was hit.
Organisational operations are not blocked by cgroup policies, so it is
possible to have pids.current > pids.max. This can be done by either
setting the limit to be smaller than pids.current, or attaching enough
Documentation/admin-guide/kdump/kdump.rst
+4 -4
View File
@@ -136,10 +136,6 @@ System kernel config options
CONFIG_KEXEC_CORE=y
Subsequently, CRASH_CORE is selected by KEXEC_CORE::
CONFIG_CRASH_CORE=y
2) Enable "sysfs file system support" in "Filesystem" -> "Pseudo
filesystems." This is usually enabled by default::
@@ -168,6 +164,10 @@ Dump-capture kernel config options (Arch Independent)
CONFIG_CRASH_DUMP=y
And this will select VMCORE_INFO and CRASH_RESERVE::
CONFIG_VMCORE_INFO=y
CONFIG_CRASH_RESERVE=y
2) Enable "/proc/vmcore support" under "Filesystems" -> "Pseudo filesystems"::
CONFIG_PROC_VMCORE=y
Documentation/admin-guide/kernel-parameters.txt
+28 -2
View File
@@ -788,6 +788,25 @@
Documentation/networking/netconsole.rst for an
alternative.
<DEVNAME>:<n>.<n>[,options]
Use the specified serial port on the serial core bus.
The addressing uses DEVNAME of the physical serial port
device, followed by the serial core controller instance,
and the serial port instance. The options are the same
as documented for the ttyS addressing above.
The mapping of the serial ports to the tty instances
can be viewed with:
$ ls -d /sys/bus/serial-base/devices/*:*.*/tty/*
/sys/bus/serial-base/devices/00:04:0.0/tty/ttyS0
In the above example, the console can be addressed with
console=00:04:0.0. Note that a console addressed this
way will only get added when the related device driver
is ready. The use of an earlycon parameter in addition to
the console may be desired for console output early on.
uart[8250],io,<addr>[,options]
uart[8250],mmio,<addr>[,options]
uart[8250],mmio16,<addr>[,options]
@@ -2155,6 +2174,12 @@
Format: 0 | 1
Default set by CONFIG_INIT_ON_FREE_DEFAULT_ON.
init_mlocked_on_free= [MM] Fill freed userspace memory with zeroes if
it was mlock'ed and not explicitly munlock'ed
afterwards.
Format: 0 | 1
Default set by CONFIG_INIT_MLOCKED_ON_FREE_DEFAULT_ON
init_pkru= [X86] Specify the default memory protection keys rights
register contents for all processes. 0x55555554 by
default (disallow access to all but pkey 0). Can
@@ -3785,10 +3810,12 @@
Format: [state][,regs][,debounce][,die]
nmi_watchdog= [KNL,BUGS=X86] Debugging features for SMP kernels
Format: [panic,][nopanic,][num]
Format: [panic,][nopanic,][rNNN,][num]
Valid num: 0 or 1
0 - turn hardlockup detector in nmi_watchdog off
1 - turn hardlockup detector in nmi_watchdog on
rNNN - configure the watchdog with raw perf event 0xNNN
When panic is specified, panic when an NMI watchdog
timeout occurs (or 'nopanic' to not panic on an NMI
watchdog, if CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is set)
@@ -7520,4 +7547,3 @@
memory, and other data can't be written using
xmon commands.
off xmon is disabled.
Documentation/admin-guide/media/ipu6-isys.rst
+161
View File
@@ -0,0 +1,161 @@
.. SPDX-License-Identifier: GPL-2.0
.. include:: <isonum.txt>
========================================================
Intel Image Processing Unit 6 (IPU6) Input System driver
========================================================
Copyright |copy| 2023--2024 Intel Corporation
Introduction
============
This file documents the Intel IPU6 (6th generation Image Processing Unit)
Input System (MIPI CSI2 receiver) drivers located under
drivers/media/pci/intel/ipu6.
The Intel IPU6 can be found in certain Intel SoCs but not in all SKUs:
* Tiger Lake
* Jasper Lake
* Alder Lake
* Raptor Lake
* Meteor Lake
Intel IPU6 is made up of two components - Input System (ISYS) and Processing
System (PSYS).
The Input System mainly works as MIPI CSI-2 receiver which receives and
processes the image data from the sensors and outputs the frames to memory.
There are 2 driver modules - intel-ipu6 and intel-ipu6-isys. intel-ipu6 is an
IPU6 common driver which does PCI configuration, firmware loading and parsing,
firmware authentication, DMA mapping and IPU-MMU (internal Memory mapping Unit)
configuration. intel_ipu6_isys implements V4L2, Media Controller and V4L2
sub-device interfaces. The IPU6 ISYS driver supports camera sensors connected
to the IPU6 ISYS through V4L2 sub-device sensor drivers.
.. Note:: See Documentation/driver-api/media/drivers/ipu6.rst for more
information about the IPU6 hardware.
Input system driver
===================
The Input System driver mainly configures CSI-2 D-PHY, constructs the firmware
stream configuration, sends commands to firmware, gets response from hardware
and firmware and then returns buffers to user. The ISYS is represented as
several V4L2 sub-devices as well as video nodes.
.. kernel-figure:: ipu6_isys_graph.svg
:alt: ipu6 isys media graph with multiple streams support
IPU6 ISYS media graph with multiple streams support
The graph has been produced using the following command:
.. code-block:: none
fdp -Gsplines=true -Tsvg < dot > dot.svg
Capturing frames with IPU6 ISYS
-------------------------------
IPU6 ISYS is used to capture frames from the camera sensors connected to the
CSI2 ports. The supported input formats of ISYS are listed in table below:
.. tabularcolumns:: |p{0.8cm}|p{4.0cm}|p{4.0cm}|
.. flat-table::
:header-rows: 1
* - IPU6 ISYS supported input formats
* - RGB565, RGB888
* - UYVY8, YUYV8
* - RAW8, RAW10, RAW12
.. _ipu6_isys_capture_examples:
Examples
~~~~~~~~
Here is an example of IPU6 ISYS raw capture on Dell XPS 9315 laptop. On this
machine, ov01a10 sensor is connected to IPU ISYS CSI-2 port 2, which can
generate images at sBGGR10 with resolution 1280x800.
Using the media controller APIs, we can configure ov01a10 sensor by
media-ctl [#f1]_ and yavta [#f2]_ to transmit frames to IPU6 ISYS.
.. code-block:: none
# Example 1 capture frame from ov01a10 camera sensor
# This example assumes /dev/media0 as the IPU ISYS media device
export MDEV=/dev/media0
# Establish the link for the media devices using media-ctl
media-ctl -d $MDEV -l "\"ov01a10 3-0036\":0 -> \"Intel IPU6 CSI2 2\":0[1]"
# Set the format for the media devices
media-ctl -d $MDEV -V "ov01a10:0 [fmt:SBGGR10/1280x800]"
media-ctl -d $MDEV -V "Intel IPU6 CSI2 2:0 [fmt:SBGGR10/1280x800]"
media-ctl -d $MDEV -V "Intel IPU6 CSI2 2:1 [fmt:SBGGR10/1280x800]"
Once the media pipeline is configured, desired sensor specific settings
(such as exposure and gain settings) can be set, using the yavta tool.
e.g
.. code-block:: none
# and that ov01a10 sensor is connected to i2c bus 3 with address 0x36
export SDEV=$(media-ctl -d $MDEV -e "ov01a10 3-0036")
yavta -w 0x009e0903 400 $SDEV
yavta -w 0x009e0913 1000 $SDEV
yavta -w 0x009e0911 2000 $SDEV
Once the desired sensor settings are set, frame captures can be done as below.
e.g
.. code-block:: none
yavta --data-prefix -u -c10 -n5 -I -s 1280x800 --file=/tmp/frame-#.bin \
-f SBGGR10 $(media-ctl -d $MDEV -e "Intel IPU6 ISYS Capture 0")
With the above command, 10 frames are captured at 1280x800 resolution with
sBGGR10 format. The captured frames are available as /tmp/frame-#.bin files.
Here is another example of IPU6 ISYS RAW and metadata capture from camera
sensor ov2740 on Lenovo X1 Yoga laptop.
.. code-block:: none
media-ctl -l "\"ov2740 14-0036\":0 -> \"Intel IPU6 CSI2 1\":0[1]"
media-ctl -l "\"Intel IPU6 CSI2 1\":1 -> \"Intel IPU6 ISYS Capture 0\":0[5]"
media-ctl -l "\"Intel IPU6 CSI2 1\":2 -> \"Intel IPU6 ISYS Capture 1\":0[5]"
# set routing
media-ctl -v -R "\"Intel IPU6 CSI2 1\" [0/0->1/0[1],0/1->2/1[1]]"
media-ctl -v "\"Intel IPU6 CSI2 1\":0/0 [fmt:SGRBG10/1932x1092]"
media-ctl -v "\"Intel IPU6 CSI2 1\":0/1 [fmt:GENERIC_8/97x1]"
media-ctl -v "\"Intel IPU6 CSI2 1\":1/0 [fmt:SGRBG10/1932x1092]"
media-ctl -v "\"Intel IPU6 CSI2 1\":2/1 [fmt:GENERIC_8/97x1]"
CAPTURE_DEV=$(media-ctl -e "Intel IPU6 ISYS Capture 0")
./yavta --data-prefix -c100 -n5 -I -s1932x1092 --file=/tmp/frame-#.bin \
-f SGRBG10 ${CAPTURE_DEV}
CAPTURE_META=$(media-ctl -e "Intel IPU6 ISYS Capture 1")
./yavta --data-prefix -c100 -n5 -I -s97x1 -B meta-capture \
--file=/tmp/meta-#.bin -f GENERIC_8 ${CAPTURE_META}
References
==========
.. [#f1] https://git.ideasonboard.org/media-ctl.git
.. [#f2] https://git.ideasonboard.org/yavta.git
Documentation/admin-guide/media/ipu6_isys_graph.svg
+548
View File
@@ -0,0 +1,548 @@
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN"
"http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Generated by graphviz version 2.43.0 (0)
-->
<!-- Title: board Pages: 1 -->
<svg width="1703pt" height="1473pt"
viewBox="0.00 0.00 1703.00 1473.00" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink">
<g id="graph0" class="graph" transform="scale(1 1) rotate(0) translate(4 1469)">
<title>board</title>
<polygon fill="white" stroke="transparent" points="-4,4 -4,-1469 1699,-1469 1699,4 -4,4"/>
<!-- n00000001 -->
<g id="node1" class="node">
<title>n00000001</title>
<polygon fill="yellow" stroke="black" points="832.99,-750.08 629.99,-750.08 629.99,-712.08 832.99,-712.08 832.99,-750.08"/>
<text text-anchor="middle" x="731.49" y="-734.88" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 0</text>
<text text-anchor="middle" x="731.49" y="-719.88" font-family="Times,serif" font-size="14.00">/dev/video0</text>
</g>
<!-- n00000005 -->
<g id="node2" class="node">
<title>n00000005</title>
<polygon fill="yellow" stroke="black" points="1396.59,-771.88 1193.59,-771.88 1193.59,-733.88 1396.59,-733.88 1396.59,-771.88"/>
<text text-anchor="middle" x="1295.09" y="-756.68" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 1</text>
<text text-anchor="middle" x="1295.09" y="-741.68" font-family="Times,serif" font-size="14.00">/dev/video1</text>
</g>
<!-- n00000009 -->
<g id="node3" class="node">
<title>n00000009</title>
<polygon fill="yellow" stroke="black" points="1118.52,-690.47 915.52,-690.47 915.52,-652.47 1118.52,-652.47 1118.52,-690.47"/>
<text text-anchor="middle" x="1017.02" y="-675.27" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 2</text>
<text text-anchor="middle" x="1017.02" y="-660.27" font-family="Times,serif" font-size="14.00">/dev/video2</text>
</g>
<!-- n0000000d -->
<g id="node4" class="node">
<title>n0000000d</title>
<polygon fill="yellow" stroke="black" points="1105.89,-838.84 902.89,-838.84 902.89,-800.84 1105.89,-800.84 1105.89,-838.84"/>
<text text-anchor="middle" x="1004.39" y="-823.64" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 3</text>
<text text-anchor="middle" x="1004.39" y="-808.64" font-family="Times,serif" font-size="14.00">/dev/video3</text>
</g>
<!-- n00000011 -->
<g id="node5" class="node">
<title>n00000011</title>
<polygon fill="yellow" stroke="black" points="1279.22,-992.95 1076.22,-992.95 1076.22,-954.95 1279.22,-954.95 1279.22,-992.95"/>
<text text-anchor="middle" x="1177.72" y="-977.75" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 4</text>
<text text-anchor="middle" x="1177.72" y="-962.75" font-family="Times,serif" font-size="14.00">/dev/video4</text>
</g>
<!-- n00000015 -->
<g id="node6" class="node">
<title>n00000015</title>
<polygon fill="yellow" stroke="black" points="939.18,-984.91 736.18,-984.91 736.18,-946.91 939.18,-946.91 939.18,-984.91"/>
<text text-anchor="middle" x="837.68" y="-969.71" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 5</text>
<text text-anchor="middle" x="837.68" y="-954.71" font-family="Times,serif" font-size="14.00">/dev/video5</text>
</g>
<!-- n00000019 -->
<g id="node7" class="node">
<title>n00000019</title>
<polygon fill="yellow" stroke="black" points="957.87,-527.99 754.87,-527.99 754.87,-489.99 957.87,-489.99 957.87,-527.99"/>
<text text-anchor="middle" x="856.37" y="-512.79" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 6</text>
<text text-anchor="middle" x="856.37" y="-497.79" font-family="Times,serif" font-size="14.00">/dev/video6</text>
</g>
<!-- n0000001d -->
<g id="node8" class="node">
<title>n0000001d</title>
<polygon fill="yellow" stroke="black" points="1291.02,-542.15 1088.02,-542.15 1088.02,-504.15 1291.02,-504.15 1291.02,-542.15"/>
<text text-anchor="middle" x="1189.52" y="-526.95" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 7</text>
<text text-anchor="middle" x="1189.52" y="-511.95" font-family="Times,serif" font-size="14.00">/dev/video7</text>
</g>
<!-- n00000021 -->
<g id="node9" class="node">
<title>n00000021</title>
<polygon fill="yellow" stroke="black" points="202.74,-611.46 -0.26,-611.46 -0.26,-573.46 202.74,-573.46 202.74,-611.46"/>
<text text-anchor="middle" x="101.24" y="-596.26" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 8</text>
<text text-anchor="middle" x="101.24" y="-581.26" font-family="Times,serif" font-size="14.00">/dev/video8</text>
</g>
<!-- n00000025 -->
<g id="node10" class="node">
<title>n00000025</title>
<polygon fill="yellow" stroke="black" points="764.86,-637.89 561.86,-637.89 561.86,-599.89 764.86,-599.89 764.86,-637.89"/>
<text text-anchor="middle" x="663.36" y="-622.69" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 9</text>
<text text-anchor="middle" x="663.36" y="-607.69" font-family="Times,serif" font-size="14.00">/dev/video9</text>
</g>
<!-- n00000029 -->
<g id="node11" class="node">
<title>n00000029</title>
<polygon fill="yellow" stroke="black" points="358.62,-519.5 146.62,-519.5 146.62,-481.5 358.62,-481.5 358.62,-519.5"/>
<text text-anchor="middle" x="252.62" y="-504.3" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 10</text>
<text text-anchor="middle" x="252.62" y="-489.3" font-family="Times,serif" font-size="14.00">/dev/video10</text>
</g>
<!-- n0000002d -->
<g id="node12" class="node">
<title>n0000002d</title>
<polygon fill="yellow" stroke="black" points="481.4,-662.59 269.4,-662.59 269.4,-624.59 481.4,-624.59 481.4,-662.59"/>
<text text-anchor="middle" x="375.4" y="-647.39" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 11</text>
<text text-anchor="middle" x="375.4" y="-632.39" font-family="Times,serif" font-size="14.00">/dev/video11</text>
</g>
<!-- n00000031 -->
<g id="node13" class="node">
<title>n00000031</title>
<polygon fill="yellow" stroke="black" points="637.17,-837.47 425.17,-837.47 425.17,-799.47 637.17,-799.47 637.17,-837.47"/>
<text text-anchor="middle" x="531.17" y="-822.27" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 12</text>
<text text-anchor="middle" x="531.17" y="-807.27" font-family="Times,serif" font-size="14.00">/dev/video12</text>
</g>
<!-- n00000035 -->
<g id="node14" class="node">
<title>n00000035</title>
<polygon fill="yellow" stroke="black" points="337.75,-833.67 125.75,-833.67 125.75,-795.67 337.75,-795.67 337.75,-833.67"/>
<text text-anchor="middle" x="231.75" y="-818.47" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 13</text>
<text text-anchor="middle" x="231.75" y="-803.47" font-family="Times,serif" font-size="14.00">/dev/video13</text>
</g>
<!-- n00000039 -->
<g id="node15" class="node">
<title>n00000039</title>
<polygon fill="yellow" stroke="black" points="393.07,-317.96 181.07,-317.96 181.07,-279.96 393.07,-279.96 393.07,-317.96"/>
<text text-anchor="middle" x="287.07" y="-302.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 14</text>
<text text-anchor="middle" x="287.07" y="-287.76" font-family="Times,serif" font-size="14.00">/dev/video14</text>
</g>
<!-- n0000003d -->
<g id="node16" class="node">
<title>n0000003d</title>
<polygon fill="yellow" stroke="black" points="701.46,-391.04 489.46,-391.04 489.46,-353.04 701.46,-353.04 701.46,-391.04"/>
<text text-anchor="middle" x="595.46" y="-375.84" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 15</text>
<text text-anchor="middle" x="595.46" y="-360.84" font-family="Times,serif" font-size="14.00">/dev/video15</text>
</g>
<!-- n00000041 -->
<g id="node17" class="node">
<title>n00000041</title>
<polygon fill="yellow" stroke="black" points="212.45,-1228.8 0.45,-1228.8 0.45,-1190.8 212.45,-1190.8 212.45,-1228.8"/>
<text text-anchor="middle" x="106.45" y="-1213.6" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 16</text>
<text text-anchor="middle" x="106.45" y="-1198.6" font-family="Times,serif" font-size="14.00">/dev/video16</text>
</g>
<!-- n00000045 -->
<g id="node18" class="node">
<title>n00000045</title>
<polygon fill="yellow" stroke="black" points="784.86,-1252.38 572.86,-1252.38 572.86,-1214.38 784.86,-1214.38 784.86,-1252.38"/>
<text text-anchor="middle" x="678.86" y="-1237.18" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 17</text>
<text text-anchor="middle" x="678.86" y="-1222.18" font-family="Times,serif" font-size="14.00">/dev/video17</text>
</g>
<!-- n00000049 -->
<g id="node19" class="node">
<title>n00000049</title>
<polygon fill="yellow" stroke="black" points="503.14,-1169.96 291.14,-1169.96 291.14,-1131.96 503.14,-1131.96 503.14,-1169.96"/>
<text text-anchor="middle" x="397.14" y="-1154.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 18</text>
<text text-anchor="middle" x="397.14" y="-1139.76" font-family="Times,serif" font-size="14.00">/dev/video18</text>
</g>
<!-- n0000004d -->
<g id="node20" class="node">
<title>n0000004d</title>
<polygon fill="yellow" stroke="black" points="492.62,-1319.4 280.62,-1319.4 280.62,-1281.4 492.62,-1281.4 492.62,-1319.4"/>
<text text-anchor="middle" x="386.62" y="-1304.2" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 19</text>
<text text-anchor="middle" x="386.62" y="-1289.2" font-family="Times,serif" font-size="14.00">/dev/video19</text>
</g>
<!-- n00000051 -->
<g id="node21" class="node">
<title>n00000051</title>
<polygon fill="yellow" stroke="black" points="680.74,-1464.66 468.74,-1464.66 468.74,-1426.66 680.74,-1426.66 680.74,-1464.66"/>
<text text-anchor="middle" x="574.74" y="-1449.46" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 20</text>
<text text-anchor="middle" x="574.74" y="-1434.46" font-family="Times,serif" font-size="14.00">/dev/video20</text>
</g>
<!-- n00000055 -->
<g id="node22" class="node">
<title>n00000055</title>
<polygon fill="yellow" stroke="black" points="302.42,-1452.56 90.42,-1452.56 90.42,-1414.56 302.42,-1414.56 302.42,-1452.56"/>
<text text-anchor="middle" x="196.42" y="-1437.36" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 21</text>
<text text-anchor="middle" x="196.42" y="-1422.36" font-family="Times,serif" font-size="14.00">/dev/video21</text>
</g>
<!-- n00000059 -->
<g id="node23" class="node">
<title>n00000059</title>
<polygon fill="yellow" stroke="black" points="319.89,-1018.32 107.89,-1018.32 107.89,-980.32 319.89,-980.32 319.89,-1018.32"/>
<text text-anchor="middle" x="213.89" y="-1003.12" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 22</text>
<text text-anchor="middle" x="213.89" y="-988.12" font-family="Times,serif" font-size="14.00">/dev/video22</text>
</g>
<!-- n0000005d -->
<g id="node24" class="node">
<title>n0000005d</title>
<polygon fill="yellow" stroke="black" points="692.62,-1031.39 480.62,-1031.39 480.62,-993.39 692.62,-993.39 692.62,-1031.39"/>
<text text-anchor="middle" x="586.62" y="-1016.19" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 23</text>
<text text-anchor="middle" x="586.62" y="-1001.19" font-family="Times,serif" font-size="14.00">/dev/video23</text>
</g>
<!-- n00000061 -->
<g id="node25" class="node">
<title>n00000061</title>
<polygon fill="yellow" stroke="black" points="1122.45,-248.8 910.45,-248.8 910.45,-210.8 1122.45,-210.8 1122.45,-248.8"/>
<text text-anchor="middle" x="1016.45" y="-233.6" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 24</text>
<text text-anchor="middle" x="1016.45" y="-218.6" font-family="Times,serif" font-size="14.00">/dev/video24</text>
</g>
<!-- n00000065 -->
<g id="node26" class="node">
<title>n00000065</title>
<polygon fill="yellow" stroke="black" points="1694.86,-272.38 1482.86,-272.38 1482.86,-234.38 1694.86,-234.38 1694.86,-272.38"/>
<text text-anchor="middle" x="1588.86" y="-257.18" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 25</text>
<text text-anchor="middle" x="1588.86" y="-242.18" font-family="Times,serif" font-size="14.00">/dev/video25</text>
</g>
<!-- n00000069 -->
<g id="node27" class="node">
<title>n00000069</title>
<polygon fill="yellow" stroke="black" points="1413.14,-189.96 1201.14,-189.96 1201.14,-151.96 1413.14,-151.96 1413.14,-189.96"/>
<text text-anchor="middle" x="1307.14" y="-174.76" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 26</text>
<text text-anchor="middle" x="1307.14" y="-159.76" font-family="Times,serif" font-size="14.00">/dev/video26</text>
</g>
<!-- n0000006d -->
<g id="node28" class="node">
<title>n0000006d</title>
<polygon fill="yellow" stroke="black" points="1402.62,-339.4 1190.62,-339.4 1190.62,-301.4 1402.62,-301.4 1402.62,-339.4"/>
<text text-anchor="middle" x="1296.62" y="-324.2" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 27</text>
<text text-anchor="middle" x="1296.62" y="-309.2" font-family="Times,serif" font-size="14.00">/dev/video27</text>
</g>
<!-- n00000071 -->
<g id="node29" class="node">
<title>n00000071</title>
<polygon fill="yellow" stroke="black" points="1590.74,-484.66 1378.74,-484.66 1378.74,-446.66 1590.74,-446.66 1590.74,-484.66"/>
<text text-anchor="middle" x="1484.74" y="-469.46" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 28</text>
<text text-anchor="middle" x="1484.74" y="-454.46" font-family="Times,serif" font-size="14.00">/dev/video28</text>
</g>
<!-- n00000075 -->
<g id="node30" class="node">
<title>n00000075</title>
<polygon fill="yellow" stroke="black" points="1212.42,-472.56 1000.42,-472.56 1000.42,-434.56 1212.42,-434.56 1212.42,-472.56"/>
<text text-anchor="middle" x="1106.42" y="-457.36" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 29</text>
<text text-anchor="middle" x="1106.42" y="-442.36" font-family="Times,serif" font-size="14.00">/dev/video29</text>
</g>
<!-- n00000079 -->
<g id="node31" class="node">
<title>n00000079</title>
<polygon fill="yellow" stroke="black" points="1229.89,-38.32 1017.89,-38.32 1017.89,-0.32 1229.89,-0.32 1229.89,-38.32"/>
<text text-anchor="middle" x="1123.89" y="-23.12" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 30</text>
<text text-anchor="middle" x="1123.89" y="-8.12" font-family="Times,serif" font-size="14.00">/dev/video30</text>
</g>
<!-- n0000007d -->
<g id="node32" class="node">
<title>n0000007d</title>
<polygon fill="yellow" stroke="black" points="1602.62,-51.39 1390.62,-51.39 1390.62,-13.39 1602.62,-13.39 1602.62,-51.39"/>
<text text-anchor="middle" x="1496.62" y="-36.19" font-family="Times,serif" font-size="14.00">Intel IPU6 ISYS Capture 31</text>
<text text-anchor="middle" x="1496.62" y="-21.19" font-family="Times,serif" font-size="14.00">/dev/video31</text>
</g>
<!-- n00000081 -->
<g id="node33" class="node">
<title>n00000081</title>
<path fill="green" stroke="black" d="M924.28,-700.28C924.28,-700.28 1108.28,-700.28 1108.28,-700.28 1114.28,-700.28 1120.28,-706.28 1120.28,-712.28 1120.28,-712.28 1120.28,-772.28 1120.28,-772.28 1120.28,-778.28 1114.28,-784.28 1108.28,-784.28 1108.28,-784.28 924.28,-784.28 924.28,-784.28 918.28,-784.28 912.28,-778.28 912.28,-772.28 912.28,-772.28 912.28,-712.28 912.28,-712.28 912.28,-706.28 918.28,-700.28 924.28,-700.28"/>
<text text-anchor="middle" x="1016.28" y="-769.08" font-family="Times,serif" font-size="14.00">0</text>
<polyline fill="none" stroke="black" points="912.28,-761.28 1120.28,-761.28 "/>
<text text-anchor="middle" x="1016.28" y="-746.08" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 0</text>
<text text-anchor="middle" x="1016.28" y="-731.08" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev0</text>
<polyline fill="none" stroke="black" points="912.28,-723.28 1120.28,-723.28 "/>
<text text-anchor="middle" x="925.28" y="-708.08" font-family="Times,serif" font-size="14.00">1</text>
<polyline fill="none" stroke="black" points="938.28,-700.28 938.28,-723.28 "/>
<text text-anchor="middle" x="951.28" y="-708.08" font-family="Times,serif" font-size="14.00">2</text>
<polyline fill="none" stroke="black" points="964.28,-700.28 964.28,-723.28 "/>
<text text-anchor="middle" x="977.28" y="-708.08" font-family="Times,serif" font-size="14.00">3</text>
<polyline fill="none" stroke="black" points="990.28,-700.28 990.28,-723.28 "/>
<text text-anchor="middle" x="1003.28" y="-708.08" font-family="Times,serif" font-size="14.00">4</text>
<polyline fill="none" stroke="black" points="1016.28,-700.28 1016.28,-723.28 "/>
<text text-anchor="middle" x="1029.28" y="-708.08" font-family="Times,serif" font-size="14.00">5</text>
<polyline fill="none" stroke="black" points="1042.28,-700.28 1042.28,-723.28 "/>
<text text-anchor="middle" x="1055.28" y="-708.08" font-family="Times,serif" font-size="14.00">6</text>
<polyline fill="none" stroke="black" points="1068.28,-700.28 1068.28,-723.28 "/>
<text text-anchor="middle" x="1081.28" y="-708.08" font-family="Times,serif" font-size="14.00">7</text>
<polyline fill="none" stroke="black" points="1094.28,-700.28 1094.28,-723.28 "/>
<text text-anchor="middle" x="1107.28" y="-708.08" font-family="Times,serif" font-size="14.00">8</text>
</g>
<!-- n00000081&#45;&gt;n00000001 -->
<g id="edge1" class="edge">
<title>n00000081:port1&#45;&gt;n00000001</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M912.28,-711.28C912.28,-711.28 880.33,-714.78 843.28,-718.84"/>
<polygon fill="black" stroke="black" points="842.81,-715.37 833.25,-719.94 843.57,-722.33 842.81,-715.37"/>
</g>
<!-- n00000081&#45;&gt;n00000005 -->
<g id="edge2" class="edge">
<title>n00000081:port2&#45;&gt;n00000005</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M951.38,-700.28C951.38,-700.28 1086.18,-688.61 1123.48,-697.08 1155.93,-704.45 1158.99,-719.67 1190.39,-730.68 1190.49,-730.71 1190.59,-730.75 1190.69,-730.78"/>
<polygon fill="black" stroke="black" points="1189.45,-734.06 1200.05,-733.86 1191.64,-727.41 1189.45,-734.06"/>
</g>
<!-- n00000081&#45;&gt;n00000009 -->
<g id="edge3" class="edge">
<title>n00000081:port3&#45;&gt;n00000009</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M977.28,-700.28C977.28,-700.28 979.31,-698.81 982.45,-696.54"/>
<polygon fill="black" stroke="black" points="984.7,-699.23 990.74,-690.53 980.59,-693.56 984.7,-699.23"/>
</g>
<!-- n00000081&#45;&gt;n0000000d -->
<g id="edge4" class="edge">
<title>n00000081:port4&#45;&gt;n0000000d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1003.38,-700.26C1003.38,-700.26 916.62,-689.8 909.08,-697.08 880.2,-725.01 885.68,-754.82 909.08,-787.48 910.88,-789.99 918.96,-793.59 929.7,-797.47"/>
<polygon fill="black" stroke="black" points="928.69,-800.82 939.28,-800.79 930.98,-794.21 928.69,-800.82"/>
</g>
<!-- n00000081&#45;&gt;n00000011 -->
<g id="edge5" class="edge">
<title>n00000081:port5&#45;&gt;n00000011</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1029.19,-700.26C1029.19,-700.26 1115.28,-690.56 1123.48,-697.08 1198.37,-756.64 1190.55,-886.51 1182.64,-944.71"/>
<polygon fill="black" stroke="black" points="1179.16,-944.31 1181.18,-954.71 1186.09,-945.32 1179.16,-944.31"/>
</g>
<!-- n00000081&#45;&gt;n00000015 -->
<g id="edge6" class="edge">
<title>n00000081:port6&#45;&gt;n00000015</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1055.18,-700.28C1055.18,-700.28 915.57,-692.2 909.08,-697.08 834.02,-753.51 831.79,-879.34 835.06,-936.56"/>
<polygon fill="black" stroke="black" points="831.58,-936.99 835.74,-946.73 838.56,-936.52 831.58,-936.99"/>
</g>
<!-- n00000081&#45;&gt;n00000019 -->
<g id="edge7" class="edge">
<title>n00000081:port7&#45;&gt;n00000019</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1081.28,-700.28C1081.28,-700.28 916.04,-696.54 912.32,-693.67 864.52,-656.73 856.3,-580.22 855.62,-538.2"/>
<polygon fill="black" stroke="black" points="859.11,-538.05 855.59,-528.06 852.11,-538.07 859.11,-538.05"/>
</g>
<!-- n00000081&#45;&gt;n0000001d -->
<g id="edge8" class="edge">
<title>n00000081:port8&#45;&gt;n0000001d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1107.28,-700.28C1107.28,-700.28 1119.29,-696.23 1121.72,-693.67 1159.76,-653.62 1177.38,-589.6 1184.78,-552.46"/>
<polygon fill="black" stroke="black" points="1188.29,-552.76 1186.69,-542.29 1181.41,-551.47 1188.29,-552.76"/>
</g>
<!-- n0000008b -->
<g id="node34" class="node">
<title>n0000008b</title>
<path fill="green" stroke="black" d="M293.1,-532.08C293.1,-532.08 477.1,-532.08 477.1,-532.08 483.1,-532.08 489.1,-538.08 489.1,-544.08 489.1,-544.08 489.1,-604.08 489.1,-604.08 489.1,-610.08 483.1,-616.08 477.1,-616.08 477.1,-616.08 293.1,-616.08 293.1,-616.08 287.1,-616.08 281.1,-610.08 281.1,-604.08 281.1,-604.08 281.1,-544.08 281.1,-544.08 281.1,-538.08 287.1,-532.08 293.1,-532.08"/>
<text text-anchor="middle" x="385.1" y="-600.88" font-family="Times,serif" font-size="14.00">0</text>
<polyline fill="none" stroke="black" points="281.1,-593.08 489.1,-593.08 "/>
<text text-anchor="middle" x="385.1" y="-577.88" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 1</text>
<text text-anchor="middle" x="385.1" y="-562.88" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev1</text>
<polyline fill="none" stroke="black" points="281.1,-555.08 489.1,-555.08 "/>
<text text-anchor="middle" x="294.1" y="-539.88" font-family="Times,serif" font-size="14.00">1</text>
<polyline fill="none" stroke="black" points="307.1,-532.08 307.1,-555.08 "/>
<text text-anchor="middle" x="320.1" y="-539.88" font-family="Times,serif" font-size="14.00">2</text>
<polyline fill="none" stroke="black" points="333.1,-532.08 333.1,-555.08 "/>
<text text-anchor="middle" x="346.1" y="-539.88" font-family="Times,serif" font-size="14.00">3</text>
<polyline fill="none" stroke="black" points="359.1,-532.08 359.1,-555.08 "/>
<text text-anchor="middle" x="372.1" y="-539.88" font-family="Times,serif" font-size="14.00">4</text>
<polyline fill="none" stroke="black" points="385.1,-532.08 385.1,-555.08 "/>
<text text-anchor="middle" x="398.1" y="-539.88" font-family="Times,serif" font-size="14.00">5</text>
<polyline fill="none" stroke="black" points="411.1,-532.08 411.1,-555.08 "/>
<text text-anchor="middle" x="424.1" y="-539.88" font-family="Times,serif" font-size="14.00">6</text>
<polyline fill="none" stroke="black" points="437.1,-532.08 437.1,-555.08 "/>
<text text-anchor="middle" x="450.1" y="-539.88" font-family="Times,serif" font-size="14.00">7</text>
<polyline fill="none" stroke="black" points="463.1,-532.08 463.1,-555.08 "/>
<text text-anchor="middle" x="476.1" y="-539.88" font-family="Times,serif" font-size="14.00">8</text>
</g>
<!-- n0000008b&#45;&gt;n00000021 -->
<g id="edge9" class="edge">
<title>n0000008b:port1&#45;&gt;n00000021</title>
<path fill="none" stroke="black" d="M281.1,-543.08C281.1,-543.08 240.1,-560.51 205.94,-570.26 205.35,-570.43 204.77,-570.59 204.18,-570.76"/>
<polygon fill="black" stroke="black" points="203.2,-567.39 194.47,-573.39 205.03,-574.15 203.2,-567.39"/>
</g>
<!-- n0000008b&#45;&gt;n00000025 -->
<g id="edge10" class="edge">
<title>n0000008b:port2&#45;&gt;n00000025</title>
<path fill="none" stroke="black" d="M320.2,-532.07C320.2,-532.07 456.9,-514.37 492.3,-528.88 528.42,-543.68 522.86,-571.78 556.11,-594.53"/>
<polygon fill="black" stroke="black" points="554.54,-597.67 564.9,-599.88 558.18,-591.69 554.54,-597.67"/>
</g>
<!-- n0000008b&#45;&gt;n00000029 -->
<g id="edge11" class="edge">
<title>n0000008b:port3&#45;&gt;n00000029</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M346.1,-532.08C346.1,-532.08 333.93,-527.96 318.37,-522.71"/>
<polygon fill="black" stroke="black" points="319.48,-519.39 308.88,-519.5 317.24,-526.02 319.48,-519.39"/>
</g>
<!-- n0000008b&#45;&gt;n0000002d -->
<g id="edge12" class="edge">
<title>n0000008b:port4&#45;&gt;n0000002d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M372.19,-532.05C372.19,-532.05 292.97,-514.3 277.9,-528.88 249.01,-556.8 253.16,-587.62 277.9,-619.28 278.34,-619.85 280.33,-620.69 283.45,-621.71"/>
<polygon fill="black" stroke="black" points="282.71,-625.14 293.29,-624.58 284.67,-618.42 282.71,-625.14"/>
</g>
<!-- n0000008b&#45;&gt;n00000031 -->
<g id="edge13" class="edge">
<title>n0000008b:port5&#45;&gt;n00000031</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M398,-532.05C398,-532.05 476.28,-515.34 492.3,-528.88 568.49,-593.29 550.55,-729.67 538.14,-789.41"/>
<polygon fill="black" stroke="black" points="534.69,-788.79 535.99,-799.31 541.53,-790.28 534.69,-788.79"/>
</g>
<!-- n0000008b&#45;&gt;n00000035 -->
<g id="edge14" class="edge">
<title>n0000008b:port6&#45;&gt;n00000035</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M424,-532.07C424,-532.07 290.37,-518.48 277.9,-528.88 202.27,-591.86 215.34,-725.69 225.66,-785.15"/>
<polygon fill="black" stroke="black" points="222.29,-786.14 227.54,-795.35 229.17,-784.88 222.29,-786.14"/>
</g>
<!-- n0000008b&#45;&gt;n00000039 -->
<g id="edge15" class="edge">
<title>n0000008b:port7&#45;&gt;n00000039</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M450.1,-532.08C450.1,-532.08 395.22,-528.13 383.45,-518.65 375.46,-512.21 322.64,-385.46 298.76,-327.47"/>
<polygon fill="black" stroke="black" points="301.96,-326.05 294.92,-318.14 295.49,-328.72 301.96,-326.05"/>
</g>
<!-- n0000008b&#45;&gt;n0000003d -->
<g id="edge16" class="edge">
<title>n0000008b:port8&#45;&gt;n0000003d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M476.1,-532.08C476.1,-532.08 522.37,-522.39 526.85,-518.65 563.15,-488.33 581.38,-434.52 589.6,-401.2"/>
<polygon fill="black" stroke="black" points="593.08,-401.69 591.93,-391.16 586.26,-400.11 593.08,-401.69"/>
</g>
<!-- n00000095 -->
<g id="node35" class="node">
<title>n00000095</title>
<path fill="green" stroke="black" d="M301.38,-1180.11C301.38,-1180.11 485.38,-1180.11 485.38,-1180.11 491.38,-1180.11 497.38,-1186.11 497.38,-1192.11 497.38,-1192.11 497.38,-1252.11 497.38,-1252.11 497.38,-1258.11 491.38,-1264.11 485.38,-1264.11 485.38,-1264.11 301.38,-1264.11 301.38,-1264.11 295.38,-1264.11 289.38,-1258.11 289.38,-1252.11 289.38,-1252.11 289.38,-1192.11 289.38,-1192.11 289.38,-1186.11 295.38,-1180.11 301.38,-1180.11"/>
<text text-anchor="middle" x="393.38" y="-1248.91" font-family="Times,serif" font-size="14.00">0</text>
<polyline fill="none" stroke="black" points="289.38,-1241.11 497.38,-1241.11 "/>
<text text-anchor="middle" x="393.38" y="-1225.91" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 2</text>
<text text-anchor="middle" x="393.38" y="-1210.91" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev2</text>
<polyline fill="none" stroke="black" points="289.38,-1203.11 497.38,-1203.11 "/>
<text text-anchor="middle" x="302.38" y="-1187.91" font-family="Times,serif" font-size="14.00">1</text>
<polyline fill="none" stroke="black" points="315.38,-1180.11 315.38,-1203.11 "/>
<text text-anchor="middle" x="328.38" y="-1187.91" font-family="Times,serif" font-size="14.00">2</text>
<polyline fill="none" stroke="black" points="341.38,-1180.11 341.38,-1203.11 "/>
<text text-anchor="middle" x="354.38" y="-1187.91" font-family="Times,serif" font-size="14.00">3</text>
<polyline fill="none" stroke="black" points="367.38,-1180.11 367.38,-1203.11 "/>
<text text-anchor="middle" x="380.38" y="-1187.91" font-family="Times,serif" font-size="14.00">4</text>
<polyline fill="none" stroke="black" points="393.38,-1180.11 393.38,-1203.11 "/>
<text text-anchor="middle" x="406.38" y="-1187.91" font-family="Times,serif" font-size="14.00">5</text>
<polyline fill="none" stroke="black" points="419.38,-1180.11 419.38,-1203.11 "/>
<text text-anchor="middle" x="432.38" y="-1187.91" font-family="Times,serif" font-size="14.00">6</text>
<polyline fill="none" stroke="black" points="445.38,-1180.11 445.38,-1203.11 "/>
<text text-anchor="middle" x="458.38" y="-1187.91" font-family="Times,serif" font-size="14.00">7</text>
<polyline fill="none" stroke="black" points="471.38,-1180.11 471.38,-1203.11 "/>
<text text-anchor="middle" x="484.38" y="-1187.91" font-family="Times,serif" font-size="14.00">8</text>
</g>
<!-- n00000095&#45;&gt;n00000041 -->
<g id="edge17" class="edge">
<title>n00000095:port1&#45;&gt;n00000041</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M289.38,-1191.11C289.38,-1191.11 258.94,-1194.22 222.89,-1197.91"/>
<polygon fill="black" stroke="black" points="222.19,-1194.46 212.6,-1198.96 222.9,-1201.42 222.19,-1194.46"/>
</g>
<!-- n00000095&#45;&gt;n00000045 -->
<g id="edge18" class="edge">
<title>n00000095:port2&#45;&gt;n00000045</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M328.48,-1180.11C328.48,-1180.11 463.26,-1168.53 500.58,-1176.91 534.02,-1184.43 537.24,-1200.06 569.66,-1211.18 569.76,-1211.22 569.86,-1211.25 569.96,-1211.29"/>
<polygon fill="black" stroke="black" points="568.86,-1214.61 579.45,-1214.34 571,-1207.95 568.86,-1214.61"/>
</g>
<!-- n00000095&#45;&gt;n00000049 -->
<g id="edge19" class="edge">
<title>n00000095:port3&#45;&gt;n00000049</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M354.38,-1180.11C354.38,-1180.11 356.8,-1178.46 360.49,-1175.94"/>
<polygon fill="black" stroke="black" points="362.56,-1178.77 368.86,-1170.24 358.62,-1172.98 362.56,-1178.77"/>
</g>
<!-- n00000095&#45;&gt;n0000004d -->
<g id="edge20" class="edge">
<title>n00000095:port4&#45;&gt;n0000004d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M380.47,-1180.09C380.47,-1180.09 293.71,-1169.63 286.18,-1176.91 257.29,-1204.84 262.63,-1234.76 286.18,-1267.31 288.16,-1270.05 297.33,-1273.96 309.38,-1278.13"/>
<polygon fill="black" stroke="black" points="308.49,-1281.53 319.09,-1281.36 310.7,-1274.88 308.49,-1281.53"/>
</g>
<!-- n00000095&#45;&gt;n00000051 -->
<g id="edge21" class="edge">
<title>n00000095:port5&#45;&gt;n00000051</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M406.28,-1180.09C406.28,-1180.09 492.13,-1170.7 500.58,-1176.91 576.41,-1232.66 579.83,-1358.79 577.09,-1416.2"/>
<polygon fill="black" stroke="black" points="573.59,-1416.23 576.51,-1426.41 580.58,-1416.63 573.59,-1416.23"/>
</g>
<!-- n00000095&#45;&gt;n00000055 -->
<g id="edge22" class="edge">
<title>n00000095:port6&#45;&gt;n00000055</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M432.28,-1180.11C432.28,-1180.11 292.85,-1172.29 286.18,-1176.91 211.26,-1228.86 198.3,-1348.49 196.45,-1404.12"/>
<polygon fill="black" stroke="black" points="192.94,-1404.28 196.21,-1414.36 199.94,-1404.44 192.94,-1404.28"/>
</g>
<!-- n00000095&#45;&gt;n00000059 -->
<g id="edge23" class="edge">
<title>n00000095:port7&#45;&gt;n00000059</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M458.38,-1180.11C458.38,-1180.11 291.84,-1175.85 287.94,-1173.16 239.87,-1139.96 222.85,-1068.83 216.94,-1028.6"/>
<polygon fill="black" stroke="black" points="220.39,-1028.06 215.6,-1018.61 213.46,-1028.98 220.39,-1028.06"/>
</g>
<!-- n00000095&#45;&gt;n0000005d -->
<g id="edge24" class="edge">
<title>n00000095:port8&#45;&gt;n0000005d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M484.38,-1180.11C484.38,-1180.11 502.45,-1176.49 506.34,-1173.16 547.25,-1138.2 569.47,-1077.38 579.62,-1041.41"/>
<polygon fill="black" stroke="black" points="583.06,-1042.09 582.28,-1031.53 576.3,-1040.27 583.06,-1042.09"/>
</g>
<!-- n0000009f -->
<g id="node36" class="node">
<title>n0000009f</title>
<path fill="green" stroke="black" d="M1211.38,-200.11C1211.38,-200.11 1395.38,-200.11 1395.38,-200.11 1401.38,-200.11 1407.38,-206.11 1407.38,-212.11 1407.38,-212.11 1407.38,-272.11 1407.38,-272.11 1407.38,-278.11 1401.38,-284.11 1395.38,-284.11 1395.38,-284.11 1211.38,-284.11 1211.38,-284.11 1205.38,-284.11 1199.38,-278.11 1199.38,-272.11 1199.38,-272.11 1199.38,-212.11 1199.38,-212.11 1199.38,-206.11 1205.38,-200.11 1211.38,-200.11"/>
<text text-anchor="middle" x="1303.38" y="-268.91" font-family="Times,serif" font-size="14.00">0</text>
<polyline fill="none" stroke="black" points="1199.38,-261.11 1407.38,-261.11 "/>
<text text-anchor="middle" x="1303.38" y="-245.91" font-family="Times,serif" font-size="14.00">Intel IPU6 CSI2 3</text>
<text text-anchor="middle" x="1303.38" y="-230.91" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev3</text>
<polyline fill="none" stroke="black" points="1199.38,-223.11 1407.38,-223.11 "/>
<text text-anchor="middle" x="1212.38" y="-207.91" font-family="Times,serif" font-size="14.00">1</text>
<polyline fill="none" stroke="black" points="1225.38,-200.11 1225.38,-223.11 "/>
<text text-anchor="middle" x="1238.38" y="-207.91" font-family="Times,serif" font-size="14.00">2</text>
<polyline fill="none" stroke="black" points="1251.38,-200.11 1251.38,-223.11 "/>
<text text-anchor="middle" x="1264.38" y="-207.91" font-family="Times,serif" font-size="14.00">3</text>
<polyline fill="none" stroke="black" points="1277.38,-200.11 1277.38,-223.11 "/>
<text text-anchor="middle" x="1290.38" y="-207.91" font-family="Times,serif" font-size="14.00">4</text>
<polyline fill="none" stroke="black" points="1303.38,-200.11 1303.38,-223.11 "/>
<text text-anchor="middle" x="1316.38" y="-207.91" font-family="Times,serif" font-size="14.00">5</text>
<polyline fill="none" stroke="black" points="1329.38,-200.11 1329.38,-223.11 "/>
<text text-anchor="middle" x="1342.38" y="-207.91" font-family="Times,serif" font-size="14.00">6</text>
<polyline fill="none" stroke="black" points="1355.38,-200.11 1355.38,-223.11 "/>
<text text-anchor="middle" x="1368.38" y="-207.91" font-family="Times,serif" font-size="14.00">7</text>
<polyline fill="none" stroke="black" points="1381.38,-200.11 1381.38,-223.11 "/>
<text text-anchor="middle" x="1394.38" y="-207.91" font-family="Times,serif" font-size="14.00">8</text>
</g>
<!-- n0000009f&#45;&gt;n00000061 -->
<g id="edge25" class="edge">
<title>n0000009f:port1&#45;&gt;n00000061</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1199.38,-211.11C1199.38,-211.11 1168.94,-214.22 1132.89,-217.91"/>
<polygon fill="black" stroke="black" points="1132.19,-214.46 1122.6,-218.96 1132.9,-221.42 1132.19,-214.46"/>
</g>
<!-- n0000009f&#45;&gt;n00000065 -->
<g id="edge26" class="edge">
<title>n0000009f:port2&#45;&gt;n00000065</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1238.48,-200.11C1238.48,-200.11 1373.26,-188.53 1410.58,-196.91 1444.02,-204.43 1447.24,-220.06 1479.66,-231.18 1479.76,-231.22 1479.86,-231.25 1479.96,-231.29"/>
<polygon fill="black" stroke="black" points="1478.86,-234.61 1489.45,-234.34 1481,-227.95 1478.86,-234.61"/>
</g>
<!-- n0000009f&#45;&gt;n00000069 -->
<g id="edge27" class="edge">
<title>n0000009f:port3&#45;&gt;n00000069</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1264.38,-200.11C1264.38,-200.11 1266.8,-198.46 1270.49,-195.94"/>
<polygon fill="black" stroke="black" points="1272.56,-198.77 1278.86,-190.24 1268.62,-192.98 1272.56,-198.77"/>
</g>
<!-- n0000009f&#45;&gt;n0000006d -->
<g id="edge28" class="edge">
<title>n0000009f:port4&#45;&gt;n0000006d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1290.47,-200.09C1290.47,-200.09 1203.71,-189.63 1196.18,-196.91 1167.29,-224.84 1172.63,-254.76 1196.18,-287.31 1198.16,-290.05 1207.33,-293.96 1219.38,-298.13"/>
<polygon fill="black" stroke="black" points="1218.49,-301.53 1229.09,-301.36 1220.7,-294.88 1218.49,-301.53"/>
</g>
<!-- n0000009f&#45;&gt;n00000071 -->
<g id="edge29" class="edge">
<title>n0000009f:port5&#45;&gt;n00000071</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1316.28,-200.09C1316.28,-200.09 1402.13,-190.7 1410.58,-196.91 1486.41,-252.66 1489.83,-378.79 1487.09,-436.2"/>
<polygon fill="black" stroke="black" points="1483.59,-436.23 1486.51,-446.41 1490.58,-436.63 1483.59,-436.23"/>
</g>
<!-- n0000009f&#45;&gt;n00000075 -->
<g id="edge30" class="edge">
<title>n0000009f:port6&#45;&gt;n00000075</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1342.28,-200.11C1342.28,-200.11 1202.85,-192.29 1196.18,-196.91 1121.26,-248.86 1108.3,-368.49 1106.45,-424.12"/>
<polygon fill="black" stroke="black" points="1102.94,-424.28 1106.21,-434.36 1109.94,-424.44 1102.94,-424.28"/>
</g>
<!-- n0000009f&#45;&gt;n00000079 -->
<g id="edge31" class="edge">
<title>n0000009f:port7&#45;&gt;n00000079</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1368.38,-200.11C1368.38,-200.11 1201.84,-195.85 1197.94,-193.16 1149.87,-159.96 1132.85,-88.83 1126.94,-48.6"/>
<polygon fill="black" stroke="black" points="1130.39,-48.06 1125.6,-38.61 1123.46,-48.98 1130.39,-48.06"/>
</g>
<!-- n0000009f&#45;&gt;n0000007d -->
<g id="edge32" class="edge">
<title>n0000009f:port8&#45;&gt;n0000007d</title>
<path fill="none" stroke="black" stroke-dasharray="5,2" d="M1394.38,-200.11C1394.38,-200.11 1412.45,-196.49 1416.34,-193.16 1457.25,-158.2 1479.47,-97.38 1489.62,-61.41"/>
<polygon fill="black" stroke="black" points="1493.06,-62.09 1492.28,-51.53 1486.3,-60.27 1493.06,-62.09"/>
</g>
<!-- n000000e9 -->
<g id="node37" class="node">
<title>n000000e9</title>
<path fill="green" stroke="black" d="M398.65,-431.45C398.65,-431.45 511.65,-431.45 511.65,-431.45 517.65,-431.45 523.65,-437.45 523.65,-443.45 523.65,-443.45 523.65,-503.45 523.65,-503.45 523.65,-509.45 517.65,-515.45 511.65,-515.45 511.65,-515.45 398.65,-515.45 398.65,-515.45 392.65,-515.45 386.65,-509.45 386.65,-503.45 386.65,-503.45 386.65,-443.45 386.65,-443.45 386.65,-437.45 392.65,-431.45 398.65,-431.45"/>
<text text-anchor="middle" x="420.65" y="-500.25" font-family="Times,serif" font-size="14.00">1</text>
<polyline fill="none" stroke="black" points="454.65,-492.45 454.65,-515.45 "/>
<text text-anchor="middle" x="489.15" y="-500.25" font-family="Times,serif" font-size="14.00">2</text>
<polyline fill="none" stroke="black" points="386.65,-492.45 523.65,-492.45 "/>
<text text-anchor="middle" x="455.15" y="-477.25" font-family="Times,serif" font-size="14.00">ov2740 4&#45;0036</text>
<text text-anchor="middle" x="455.15" y="-462.25" font-family="Times,serif" font-size="14.00">/dev/v4l&#45;subdev4</text>
<polyline fill="none" stroke="black" points="386.65,-454.45 523.65,-454.45 "/>
<text text-anchor="middle" x="455.15" y="-439.25" font-family="Times,serif" font-size="14.00">0</text>
</g>
<!-- n000000e9&#45;&gt;n0000008b -->
<g id="edge33" class="edge">
<title>n000000e9:port0&#45;&gt;n0000008b:port0</title>
<path fill="none" stroke="black" stroke-width="2" d="M386.14,-442.55C386.14,-442.55 361.11,-493.23 383.45,-518.65 391.47,-527.78 484.31,-519.72 492.3,-528.88 508.64,-547.6 499.26,-579.87 493.12,-595.68"/>
<polygon fill="black" stroke="black" stroke-width="2" points="489.86,-594.41 489.11,-604.98 496.29,-597.19 489.86,-594.41"/>
</g>
</g>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 38 KiB

Documentation/admin-guide/media/mgb4.rst
+15 -20
View File
@@ -1,8 +1,10 @@
.. SPDX-License-Identifier: GPL-2.0
====================
mgb4 sysfs interface
====================
The mgb4 driver
===============
sysfs interface
---------------
The mgb4 driver provides a sysfs interface, that is used to configure video
stream related parameters (some of them must be set properly before the v4l2
@@ -12,9 +14,8 @@ There are two types of parameters - global / PCI card related, found under
``/sys/class/video4linux/videoX/device`` and module specific found under
``/sys/class/video4linux/videoX``.
Global (PCI card) parameters
============================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**module_type** (R):
Module type.
@@ -42,9 +43,8 @@ Global (PCI card) parameters
where each component is a 8b number.
Common FPDL3/GMSL input parameters
==================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**input_id** (R):
Input number ID, zero based.
@@ -190,9 +190,8 @@ Common FPDL3/GMSL input parameters
*Note: This parameter can not be changed while the input v4l2 device is
open.*
Common FPDL3/GMSL output parameters
===================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**output_id** (R):
Output number ID, zero based.
@@ -282,9 +281,8 @@ Common FPDL3/GMSL output parameters
Number of video lines between the end of the last valid pixel line (marked
by DE=1) and assertion of the VSYNC signal. The default value is 2.
FPDL3 specific input parameters
===============================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**fpdl3_input_width** (RW):
Number of deserializer input lines.
@@ -294,7 +292,7 @@ FPDL3 specific input parameters
| 2 - dual
FPDL3 specific output parameters
================================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**fpdl3_output_width** (RW):
Number of serializer output lines.
@@ -304,7 +302,7 @@ FPDL3 specific output parameters
| 2 - dual
GMSL specific input parameters
==============================
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
**gmsl_mode** (RW):
GMSL speed mode.
@@ -328,10 +326,8 @@ GMSL specific input parameters
| 0 - disabled
| 1 - enabled (default)
====================
mgb4 mtd partitions
====================
MTD partitions
--------------
The mgb4 driver creates a MTD device with two partitions:
- mgb4-fw.X - FPGA firmware.
@@ -344,9 +340,8 @@ also have a third partition named *mgb4-flash* available in the system. This
partition represents the whole, unpartitioned, card's FLASH memory and one should
not fiddle with it...
====================
mgb4 iio (triggers)
====================
IIO (triggers)
--------------
The mgb4 driver creates an Industrial I/O (IIO) device that provides trigger and
signal level status capability. The following scan elements are available:
Documentation/admin-guide/media/v4l-drivers.rst
+1
View File
@@ -16,6 +16,7 @@ Video4Linux (V4L) driver-specific documentation
imx
imx7
ipu3
ipu6-isys
ivtv
mgb4
omap3isp
Documentation/admin-guide/mm/damon/usage.rst
+16 -16
View File
@@ -153,7 +153,7 @@ Users can write below commands for the kdamond to the ``state`` file.
- ``clear_schemes_tried_regions``: Clear the DAMON-based operating scheme
action tried regions directory for each DAMON-based operation scheme of the
kdamond.
- ``update_schemes_effective_bytes``: Update the contents of
- ``update_schemes_effective_quotas``: Update the contents of
``effective_bytes`` files for each DAMON-based operation scheme of the
kdamond. For more details, refer to :ref:`quotas directory <sysfs_quotas>`.
@@ -342,7 +342,7 @@ Based on the user-specified :ref:`goal <sysfs_schemes_quota_goals>`, the
effective size quota is further adjusted. Reading ``effective_bytes`` returns
the current effective size quota. The file is not updated in real time, so
users should ask DAMON sysfs interface to update the content of the file for
the stats by writing a special keyword, ``update_schemes_effective_bytes`` to
the stats by writing a special keyword, ``update_schemes_effective_quotas`` to
the relevant ``kdamonds/<N>/state`` file.
Under ``weights`` directory, three files (``sz_permil``,
@@ -410,19 +410,19 @@ in the numeric order.
Each filter directory contains six files, namely ``type``, ``matcing``,
``memcg_path``, ``addr_start``, ``addr_end``, and ``target_idx``. To ``type``
file, you can write one of four special keywords: ``anon`` for anonymous pages,
``memcg`` for specific memory cgroup, ``addr`` for specific address range (an
open-ended interval), or ``target`` for specific DAMON monitoring target
filtering. In case of the memory cgroup filtering, you can specify the memory
cgroup of the interest by writing the path of the memory cgroup from the
cgroups mount point to ``memcg_path`` file. In case of the address range
filtering, you can specify the start and end address of the range to
``addr_start`` and ``addr_end`` files, respectively. For the DAMON monitoring
target filtering, you can specify the index of the target between the list of
the DAMON context's monitoring targets list to ``target_idx`` file. You can
write ``Y`` or ``N`` to ``matching`` file to filter out pages that does or does
not match to the type, respectively. Then, the scheme's action will not be
applied to the pages that specified to be filtered out.
file, you can write one of five special keywords: ``anon`` for anonymous pages,
``memcg`` for specific memory cgroup, ``young`` for young pages, ``addr`` for
specific address range (an open-ended interval), or ``target`` for specific
DAMON monitoring target filtering. In case of the memory cgroup filtering, you
can specify the memory cgroup of the interest by writing the path of the memory
cgroup from the cgroups mount point to ``memcg_path`` file. In case of the
address range filtering, you can specify the start and end address of the range
to ``addr_start`` and ``addr_end`` files, respectively. For the DAMON
monitoring target filtering, you can specify the index of the target between
the list of the DAMON context's monitoring targets list to ``target_idx`` file.
You can write ``Y`` or ``N`` to ``matching`` file to filter out pages that does
or does not match to the type, respectively. Then, the scheme's action will
not be applied to the pages that specified to be filtered out.
For example, below restricts a DAMOS action to be applied to only non-anonymous
pages of all memory cgroups except ``/having_care_already``.::
@@ -434,7 +434,7 @@ pages of all memory cgroups except ``/having_care_already``.::
# # further filter out all cgroups except one at '/having_care_already'
echo memcg > 1/type
echo /having_care_already > 1/memcg_path
echo N > 1/matching
echo Y > 1/matching
Note that ``anon`` and ``memcg`` filters are currently supported only when
``paddr`` :ref:`implementation <sysfs_context>` is being used.
Documentation/admin-guide/mm/hugetlbpage.rst
+7
View File
@@ -376,6 +376,13 @@ Note that the number of overcommit and reserve pages remain global quantities,
as we don't know until fault time, when the faulting task's mempolicy is
applied, from which node the huge page allocation will be attempted.
The hugetlb may be migrated between the per-node hugepages pool in the following
scenarios: memory offline, memory failure, longterm pinning, syscalls(mbind,
migrate_pages and move_pages), alloc_contig_range() and alloc_contig_pages().
Now only memory offline, memory failure and syscalls allow fallbacking to allocate
a new hugetlb on a different node if the current node is unable to allocate during
hugetlb migration, that means these 3 cases can break the per-node hugepages pool.
.. _using_huge_pages:
Using Huge Pages
Documentation/admin-guide/mm/transhuge.rst
+32 -3
View File
@@ -278,7 +278,8 @@ collapsed, resulting fewer pages being collapsed into
THPs, and lower memory access performance.
``max_ptes_shared`` specifies how many pages can be shared across multiple
processes. Exceeding the number would block the collapse::
processes. khugepaged might treat pages of THPs as shared if any page of
that THP is shared. Exceeding the number would block the collapse::
/sys/kernel/mm/transparent_hugepage/khugepaged/max_ptes_shared
@@ -369,7 +370,7 @@ monitor how successfully the system is providing huge pages for use.
thp_fault_alloc
is incremented every time a huge page is successfully
allocated to handle a page fault.
allocated and charged to handle a page fault.
thp_collapse_alloc
is incremented by khugepaged when it has found
@@ -377,7 +378,7 @@ thp_collapse_alloc
successfully allocated a new huge page to store the data.
thp_fault_fallback
is incremented if a page fault fails to allocate
is incremented if a page fault fails to allocate or charge
a huge page and instead falls back to using small pages.
thp_fault_fallback_charge
@@ -447,6 +448,34 @@ thp_swpout_fallback
Usually because failed to allocate some continuous swap space
for the huge page.
In /sys/kernel/mm/transparent_hugepage/hugepages-<size>kB/stats, There are
also individual counters for each huge page size, which can be utilized to
monitor the system's effectiveness in providing huge pages for usage. Each
counter has its own corresponding file.
anon_fault_alloc
is incremented every time a huge page is successfully
allocated and charged to handle a page fault.
anon_fault_fallback
is incremented if a page fault fails to allocate or charge
a huge page and instead falls back to using huge pages with
lower orders or small pages.
anon_fault_fallback_charge
is incremented if a page fault fails to charge a huge page and
instead falls back to using huge pages with lower orders or
small pages even though the allocation was successful.
anon_swpout
is incremented every time a huge page is swapped out in one
piece without splitting.
anon_swpout_fallback
is incremented if a huge page has to be split before swapout.
Usually because failed to allocate some continuous swap space
for the huge page.
As the system ages, allocating huge pages may be expensive as the
system uses memory compaction to copy data around memory to free a
huge page for use. There are some counters in ``/proc/vmstat`` to help
Documentation/admin-guide/mm/zswap.rst
-29
View File
@@ -111,35 +111,6 @@ checked if it is a same-value filled page before compressing it. If true, the
compressed length of the page is set to zero and the pattern or same-filled
value is stored.
Same-value filled pages identification feature is enabled by default and can be
disabled at boot time by setting the ``same_filled_pages_enabled`` attribute
to 0, e.g. ``zswap.same_filled_pages_enabled=0``. It can also be enabled and
disabled at runtime using the sysfs ``same_filled_pages_enabled``
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.
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
without any real benefit but with a performance drop for the system), a
Documentation/admin-guide/sysctl/net.rst
+1
View File
@@ -72,6 +72,7 @@ two flavors of JITs, the newer eBPF JIT currently supported on:
- riscv64
- riscv32
- loongarch64
- arc
And the older cBPF JIT supported on the following archs:
Documentation/admin-guide/sysctl/vm.rst
+16
View File
@@ -43,6 +43,7 @@ Currently, these files are in /proc/sys/vm:
- legacy_va_layout
- lowmem_reserve_ratio
- max_map_count
- mem_profiling (only if CONFIG_MEM_ALLOC_PROFILING=y)
- memory_failure_early_kill
- memory_failure_recovery
- min_free_kbytes
@@ -425,6 +426,21 @@ e.g., up to one or two maps per allocation.
The default value is 65530.
mem_profiling
==============
Enable memory profiling (when CONFIG_MEM_ALLOC_PROFILING=y)
1: Enable memory profiling.
0: Disable memory profiling.
Enabling memory profiling introduces a small performance overhead for all
memory allocations.
The default value depends on CONFIG_MEM_ALLOC_PROFILING_ENABLED_BY_DEFAULT.
memory_failure_early_kill:
==========================
Documentation/admin-guide/sysrq.rst
+9
View File
@@ -161,6 +161,8 @@ Command Function
will be printed to your console. (``0``, for example would make
it so that only emergency messages like PANICs or OOPSes would
make it to your console.)
``R`` Replay the kernel log messages on consoles.
=========== ===================================================================
Okay, so what can I use them for?
@@ -211,6 +213,13 @@ processes.
"just thaw ``it(j)``" is useful if your system becomes unresponsive due to a
frozen (probably root) filesystem via the FIFREEZE ioctl.
``Replay logs(R)`` is useful to view the kernel log messages when system is hung
or you are not able to use dmesg command to view the messages in printk buffer.
User may have to press the key combination multiple times if console system is
busy. If it is completely locked up, then messages won't be printed. Output
messages depend on current console loglevel, which can be modified using
sysrq[0-9] (see above).
Sometimes SysRq seems to get 'stuck' after using it, what can I do?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Documentation/arch/arm64/silicon-errata.rst
+4
View File
@@ -140,6 +140,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X2 | #2224489 | ARM64_ERRATUM_2224489 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Cortex-X4 | #3194386 | ARM64_ERRATUM_3194386 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1188873,1418040| ARM64_ERRATUM_1418040 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-N1 | #1349291 | N/A |
@@ -156,6 +158,8 @@ stable kernels.
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V1 | #1619801 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | Neoverse-V3 | #3312417 | ARM64_ERRATUM_3312417 |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-500 | #841119,826419 | N/A |
+----------------+-----------------+-----------------+-----------------------------+
| ARM | MMU-600 | #1076982,1209401| N/A |
Documentation/arch/powerpc/dexcr.rst
+139 -2
View File
@@ -36,8 +36,145 @@ state for a process.
Configuration
=============
The DEXCR is currently unconfigurable. All threads are run with the
NPHIE aspect enabled.
prctl
-----
A process can control its own userspace DEXCR value using the
``PR_PPC_GET_DEXCR`` and ``PR_PPC_SET_DEXCR`` pair of
:manpage:`prctl(2)` commands. These calls have the form::
prctl(PR_PPC_GET_DEXCR, unsigned long which, 0, 0, 0);
prctl(PR_PPC_SET_DEXCR, unsigned long which, unsigned long ctrl, 0, 0);
The possible 'which' and 'ctrl' values are as follows. Note there is no relation
between the 'which' value and the DEXCR aspect's index.
.. flat-table::
:header-rows: 1
:widths: 2 7 1
* - ``prctl()`` which
- Aspect name
- Aspect index
* - ``PR_PPC_DEXCR_SBHE``
- Speculative Branch Hint Enable (SBHE)
- 0
* - ``PR_PPC_DEXCR_IBRTPD``
- Indirect Branch Recurrent Target Prediction Disable (IBRTPD)
- 3
* - ``PR_PPC_DEXCR_SRAPD``
- Subroutine Return Address Prediction Disable (SRAPD)
- 4
* - ``PR_PPC_DEXCR_NPHIE``
- Non-Privileged Hash Instruction Enable (NPHIE)
- 5
.. flat-table::
:header-rows: 1
:widths: 2 8
* - ``prctl()`` ctrl
- Meaning
* - ``PR_PPC_DEXCR_CTRL_EDITABLE``
- This aspect can be configured with PR_PPC_SET_DEXCR (get only)
* - ``PR_PPC_DEXCR_CTRL_SET``
- This aspect is set / set this aspect
* - ``PR_PPC_DEXCR_CTRL_CLEAR``
- This aspect is clear / clear this aspect
* - ``PR_PPC_DEXCR_CTRL_SET_ONEXEC``
- This aspect will be set after exec / set this aspect after exec
* - ``PR_PPC_DEXCR_CTRL_CLEAR_ONEXEC``
- This aspect will be clear after exec / clear this aspect after exec
Note that
* which is a plain value, not a bitmask. Aspects must be worked with individually.
* ctrl is a bitmask. ``PR_PPC_GET_DEXCR`` returns both the current and onexec
configuration. For example, ``PR_PPC_GET_DEXCR`` may return
``PR_PPC_DEXCR_CTRL_EDITABLE | PR_PPC_DEXCR_CTRL_SET |
PR_PPC_DEXCR_CTRL_CLEAR_ONEXEC``. This would indicate the aspect is currently
set, it will be cleared when you run exec, and you can change this with the
``PR_PPC_SET_DEXCR`` prctl.
* The set/clear terminology refers to setting/clearing the bit in the DEXCR.
For example::
prctl(PR_PPC_SET_DEXCR, PR_PPC_DEXCR_IBRTPD, PR_PPC_DEXCR_CTRL_SET, 0, 0);
will set the IBRTPD aspect bit in the DEXCR, causing indirect branch prediction
to be disabled.
* The status returned by ``PR_PPC_GET_DEXCR`` represents what value the process
would like applied. It does not include any alternative overrides, such as if
the hypervisor is enforcing the aspect be set. To see the true DEXCR state
software should read the appropriate SPRs directly.
* The aspect state when starting a process is copied from the parent's state on
:manpage:`fork(2)`. The state is reset to a fixed value on
:manpage:`execve(2)`. The PR_PPC_SET_DEXCR prctl() can control both of these
values.
* The ``*_ONEXEC`` controls do not change the current process's DEXCR.
Use ``PR_PPC_SET_DEXCR`` with one of ``PR_PPC_DEXCR_CTRL_SET`` or
``PR_PPC_DEXCR_CTRL_CLEAR`` to edit a given aspect.
Common error codes for both getting and setting the DEXCR are as follows:
.. flat-table::
:header-rows: 1
:widths: 2 8
* - Error
- Meaning
* - ``EINVAL``
- The DEXCR is not supported by the kernel.
* - ``ENODEV``
- The aspect is not recognised by the kernel or not supported by the
hardware.
``PR_PPC_SET_DEXCR`` may also report the following error codes:
.. flat-table::
:header-rows: 1
:widths: 2 8
* - Error
- Meaning
* - ``EINVAL``
- The ctrl value contains unrecognised flags.
* - ``EINVAL``
- The ctrl value contains mutually conflicting flags (e.g.,
``PR_PPC_DEXCR_CTRL_SET | PR_PPC_DEXCR_CTRL_CLEAR``)
* - ``EPERM``
- This aspect cannot be modified with prctl() (check for the
PR_PPC_DEXCR_CTRL_EDITABLE flag with PR_PPC_GET_DEXCR).
* - ``EPERM``
- The process does not have sufficient privilege to perform the operation.
For example, clearing NPHIE on exec is a privileged operation (a process
can still clear its own NPHIE aspect without privileges).
This interface allows a process to control its own DEXCR aspects, and also set
the initial DEXCR value for any children in its process tree (up to the next
child to use an ``*_ONEXEC`` control). This allows fine-grained control over the
default value of the DEXCR, for example allowing containers to run with different
default values.
coredump and ptrace
Documentation/arch/powerpc/firmware-assisted-dump.rst
+42 -49
View File
@@ -134,12 +134,12 @@ that are run. If there is dump data, then the
memory is held.
If there is no waiting dump data, then only the memory required to
hold CPU state, HPTE region, boot memory dump, FADump header and
elfcore header, is usually reserved at an offset greater than boot
memory size (see Fig. 1). This area is *not* released: this region
will be kept permanently reserved, so that it can act as a receptacle
for a copy of the boot memory content in addition to CPU state and
HPTE region, in the case a crash does occur.
hold CPU state, HPTE region, boot memory dump, and FADump header is
usually reserved at an offset greater than boot memory size (see Fig. 1).
This area is *not* released: this region will be kept permanently
reserved, so that it can act as a receptacle for a copy of the boot
memory content in addition to CPU state and HPTE region, in the case
a crash does occur.
Since this reserved memory area is used only after the system crash,
there is no point in blocking this significant chunk of memory from
@@ -153,22 +153,22 @@ that were present in CMA region::
o Memory Reservation during first kernel
Low memory Top of memory
0 boot memory size |<--- Reserved dump area --->| |
| | | Permanent Reservation | |
V V | | V
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
| | |///|////| DUMP | HDR | ELF |////| |
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
| ^ ^ ^ ^ ^
| | | | | |
\ CPU HPTE / | |
------------------------------ | |
Boot memory content gets transferred | |
to reserved area by firmware at the | |
time of crash. | |
FADump Header |
(meta area) |
Low memory Top of memory
0 boot memory size |<------ Reserved dump area ----->| |
| | | Permanent Reservation | |
V V | | V
+-----------+-----/ /---+---+----+-----------+-------+----+-----+
| | |///|////| DUMP | HDR |////| |
+-----------+-----/ /---+---+----+-----------+-------+----+-----+
| ^ ^ ^ ^ ^
| | | | | |
\ CPU HPTE / | |
-------------------------------- | |
Boot memory content gets transferred | |
to reserved area by firmware at the | |
time of crash. | |
FADump Header |
(meta area) |
|
|
Metadata: This area holds a metadata structure whose
@@ -186,13 +186,20 @@ that were present in CMA region::
0 boot memory size |
| |<------------ Crash preserved area ------------>|
V V |<--- Reserved dump area --->| |
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
| | |///|////| DUMP | HDR | ELF |////| |
+-----------+-----/ /---+---+----+-------+-----+-----+----+--+
| |
V V
Used by second /proc/vmcore
kernel to boot
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
| |ELF| | |///|////| DUMP | HDR |/////| |
+----+---+--+-----/ /---+---+----+-------+-----+-----+-------+
| | | | | |
----- ------------------------------ ---------------
\ | |
\ | |
\ | |
\ | ----------------------------
\ | /
\ | /
\ | /
/proc/vmcore
+---+
|///| -> Regions (CPU, HPTE & Metadata) marked like this in the above
@@ -200,6 +207,12 @@ that were present in CMA region::
does not have CPU & HPTE regions while Metadata region is
not supported on pSeries currently.
+---+
|ELF| -> elfcorehdr, it is created in second kernel after crash.
+---+
Note: Memory from 0 to the boot memory size is used by second kernel
Fig. 2
@@ -353,26 +366,6 @@ TODO:
- Need to come up with the better approach to find out more
accurate boot memory size that is required for a kernel to
boot successfully when booted with restricted memory.
- The FADump implementation introduces a FADump crash info structure
in the scratch area before the ELF core header. The idea of introducing
this structure is to pass some important crash info data to the second
kernel which will help second kernel to populate ELF core header with
correct data before it gets exported through /proc/vmcore. The current
design implementation does not address a possibility of introducing
additional fields (in future) to this structure without affecting
compatibility. Need to come up with the better approach to address this.
The possible approaches are:
1. Introduce version field for version tracking, bump up the version
whenever a new field is added to the structure in future. The version
field can be used to find out what fields are valid for the current
version of the structure.
2. Reserve the area of predefined size (say PAGE_SIZE) for this
structure and have unused area as reserved (initialized to zero)
for future field additions.
The advantage of approach 1 over 2 is we don't need to reserve extra space.
Author: Mahesh Salgaonkar <mahesh@linux.vnet.ibm.com>
Documentation/arch/riscv/cmodx.rst
+98
View File
@@ -0,0 +1,98 @@
.. SPDX-License-Identifier: GPL-2.0
==============================================================================
Concurrent Modification and Execution of Instructions (CMODX) for RISC-V Linux
==============================================================================
CMODX is a programming technique where a program executes instructions that were
modified by the program itself. Instruction storage and the instruction cache
(icache) are not guaranteed to be synchronized on RISC-V hardware. Therefore, the
program must enforce its own synchronization with the unprivileged fence.i
instruction.
However, the default Linux ABI prohibits the use of fence.i in userspace
applications. At any point the scheduler may migrate a task onto a new hart. If
migration occurs after the userspace synchronized the icache and instruction
storage with fence.i, the icache on the new hart will no longer be clean. This
is due to the behavior of fence.i only affecting the hart that it is called on.
Thus, the hart that the task has been migrated to may not have synchronized
instruction storage and icache.
There are two ways to solve this problem: use the riscv_flush_icache() syscall,
or use the ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` prctl() and emit fence.i in
userspace. The syscall performs a one-off icache flushing operation. The prctl
changes the Linux ABI to allow userspace to emit icache flushing operations.
As an aside, "deferred" icache flushes can sometimes be triggered in the kernel.
At the time of writing, this only occurs during the riscv_flush_icache() syscall
and when the kernel uses copy_to_user_page(). These deferred flushes happen only
when the memory map being used by a hart changes. If the prctl() context caused
an icache flush, this deferred icache flush will be skipped as it is redundant.
Therefore, there will be no additional flush when using the riscv_flush_icache()
syscall inside of the prctl() context.
prctl() Interface
---------------------
Call prctl() with ``PR_RISCV_SET_ICACHE_FLUSH_CTX`` as the first argument. The
remaining arguments will be delegated to the riscv_set_icache_flush_ctx
function detailed below.
.. kernel-doc:: arch/riscv/mm/cacheflush.c
:identifiers: riscv_set_icache_flush_ctx
Example usage:
The following files are meant to be compiled and linked with each other. The
modify_instruction() function replaces an add with 0 with an add with one,
causing the instruction sequence in get_value() to change from returning a zero
to returning a one.
cmodx.c::
#include <stdio.h>
#include <sys/prctl.h>
extern int get_value();
extern void modify_instruction();
int main()
{
int value = get_value();
printf("Value before cmodx: %d\n", value);
// Call prctl before first fence.i is called inside modify_instruction
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX_ON, PR_RISCV_CTX_SW_FENCEI, PR_RISCV_SCOPE_PER_PROCESS);
modify_instruction();
// Call prctl after final fence.i is called in process
prctl(PR_RISCV_SET_ICACHE_FLUSH_CTX_OFF, PR_RISCV_CTX_SW_FENCEI, PR_RISCV_SCOPE_PER_PROCESS);
value = get_value();
printf("Value after cmodx: %d\n", value);
return 0;
}
cmodx.S::
.option norvc
.text
.global modify_instruction
modify_instruction:
lw a0, new_insn
lui a5,%hi(old_insn)
sw a0,%lo(old_insn)(a5)
fence.i
ret
.section modifiable, "awx"
.global get_value
get_value:
li a0, 0
old_insn:
addi a0, a0, 0
ret
.data
new_insn:
addi a0, a0, 1
Documentation/arch/riscv/hwprobe.rst
+4
View File
@@ -188,6 +188,10 @@ The following keys are defined:
manual starting from commit 95cf1f9 ("Add changes requested by Ved
during signoff")
* :c:macro:`RISCV_HWPROBE_EXT_ZIHINTPAUSE`: The Zihintpause extension is
supported as defined in the RISC-V ISA manual starting from commit
d8ab5c78c207 ("Zihintpause is ratified").
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
information about the selected set of processors.
Documentation/arch/riscv/index.rst
+1
View File
@@ -13,6 +13,7 @@ RISC-V architecture
patch-acceptance
uabi
vector
cmodx
features
Documentation/bpf/standardization/instruction-set.rst
+65 -49
View File
@@ -5,7 +5,11 @@
BPF Instruction Set Architecture (ISA)
======================================
This document specifies the BPF instruction set architecture (ISA).
eBPF (which is no longer an acronym for anything), also commonly
referred to as BPF, is a technology with origins in the Linux kernel
that can run untrusted programs in a privileged context such as an
operating system kernel. This document specifies the BPF instruction
set architecture (ISA).
Documentation conventions
=========================
@@ -43,7 +47,7 @@ a type's signedness (`S`) and bit width (`N`), respectively.
===== =========
For example, `u32` is a type whose valid values are all the 32-bit unsigned
numbers and `s16` is a types whose valid values are all the 16-bit signed
numbers and `s16` is a type whose valid values are all the 16-bit signed
numbers.
Functions
@@ -108,7 +112,7 @@ conformance group means it must support all instructions in that conformance
group.
The use of named conformance groups enables interoperability between a runtime
that executes instructions, and tools as such compilers that generate
that executes instructions, and tools such as compilers that generate
instructions for the runtime. Thus, capability discovery in terms of
conformance groups might be done manually by users or automatically by tools.
@@ -181,10 +185,13 @@ A basic instruction is encoded as follows::
(`64-bit immediate instructions`_ reuse this field for other purposes)
**dst_reg**
destination register number (0-10)
destination register number (0-10), unless otherwise specified
(future instructions might reuse this field for other purposes)
**offset**
signed integer offset used with pointer arithmetic
signed integer offset used with pointer arithmetic, except where
otherwise specified (some arithmetic instructions reuse this field
for other purposes)
**imm**
signed integer immediate value
@@ -228,10 +235,12 @@ This is depicted in the following figure::
operation to perform, encoded as explained above
**regs**
The source and destination register numbers, encoded as explained above
The source and destination register numbers (unless otherwise
specified), encoded as explained above
**offset**
signed integer offset used with pointer arithmetic
signed integer offset used with pointer arithmetic, unless
otherwise specified
**imm**
signed integer immediate value
@@ -292,8 +301,9 @@ Arithmetic instructions
``ALU`` uses 32-bit wide operands while ``ALU64`` uses 64-bit wide operands for
otherwise identical operations. ``ALU64`` instructions belong to the
base64 conformance group unless noted otherwise.
The 'code' field encodes the operation as below, where 'src' and 'dst' refer
to the values of the source and destination registers, respectively.
The 'code' field encodes the operation as below, where 'src' refers to the
the source operand and 'dst' refers to the value of the destination
register.
===== ===== ======= ==========================================================
name code offset description
@@ -342,8 +352,8 @@ where '(u32)' indicates that the upper 32 bits are zeroed.
dst = dst ^ imm
Note that most instructions have instruction offset of 0. Only three instructions
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero offset.
Note that most arithmetic instructions have 'offset' set to 0. Only three instructions
(``SDIV``, ``SMOD``, ``MOVSX``) have a non-zero 'offset'.
Division, multiplication, and modulo operations for ``ALU`` are part
of the "divmul32" conformance group, and division, multiplication, and
@@ -365,15 +375,15 @@ Note that there are varying definitions of the signed modulo operation
when the dividend or divisor are negative, where implementations often
vary by language such that Python, Ruby, etc. differ from C, Go, Java,
etc. This specification requires that signed modulo use truncated division
(where -13 % 3 == -1) as implemented in C, Go, etc.:
(where -13 % 3 == -1) as implemented in C, Go, etc.::
a % n = a - n * trunc(a / n)
The ``MOVSX`` instruction does a move operation with sign extension.
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into 32
bit operands, and zeroes the remaining upper 32 bits.
``{MOVSX, X, ALU}`` :term:`sign extends<Sign Extend>` 8-bit and 16-bit operands into
32-bit operands, and zeroes the remaining upper 32 bits.
``{MOVSX, X, ALU64}`` :term:`sign extends<Sign Extend>` 8-bit, 16-bit, and 32-bit
operands into 64 bit operands. Unlike other arithmetic instructions,
operands into 64-bit operands. Unlike other arithmetic instructions,
``MOVSX`` is only defined for register source operands (``X``).
The ``NEG`` instruction is only defined when the source bit is clear
@@ -411,19 +421,19 @@ conformance group.
Examples:
``{END, TO_LE, ALU}`` with imm = 16/32/64 means::
``{END, TO_LE, ALU}`` with 'imm' = 16/32/64 means::
dst = htole16(dst)
dst = htole32(dst)
dst = htole64(dst)
``{END, TO_BE, ALU}`` with imm = 16/32/64 means::
``{END, TO_BE, ALU}`` with 'imm' = 16/32/64 means::
dst = htobe16(dst)
dst = htobe32(dst)
dst = htobe64(dst)
``{END, TO_LE, ALU64}`` with imm = 16/32/64 means::
``{END, TO_LE, ALU64}`` with 'imm' = 16/32/64 means::
dst = bswap16(dst)
dst = bswap32(dst)
@@ -438,27 +448,33 @@ otherwise identical operations, and indicates the base64 conformance
group unless otherwise specified.
The 'code' field encodes the operation as below:
======== ===== ======= =============================== ===================================================
code value src_reg description notes
======== ===== ======= =============================== ===================================================
JA 0x0 0x0 PC += offset {JA, K, JMP} only
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
======== ===== ======= ================================= ===================================================
code value src_reg description notes
======== ===== ======= ================================= ===================================================
JA 0x0 0x0 PC += offset {JA, K, JMP} only
JA 0x0 0x0 PC += imm {JA, K, JMP32} only
JEQ 0x1 any PC += offset if dst == src
JGT 0x2 any PC += offset if dst > src unsigned
JGE 0x3 any PC += offset if dst >= src unsigned
JGT 0x2 any PC += offset if dst > src unsigned
JGE 0x3 any PC += offset if dst >= src unsigned
JSET 0x4 any PC += offset if dst & src
JNE 0x5 any PC += offset if dst != src
JSGT 0x6 any PC += offset if dst > src signed
JSGE 0x7 any PC += offset if dst >= src signed
CALL 0x8 0x0 call helper function by address {CALL, K, JMP} only, see `Helper functions`_
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
EXIT 0x9 0x0 return {CALL, K, JMP} only
JLT 0xa any PC += offset if dst < src unsigned
JLE 0xb any PC += offset if dst <= src unsigned
JSLT 0xc any PC += offset if dst < src signed
JSLE 0xd any PC += offset if dst <= src signed
======== ===== ======= =============================== ===================================================
JSGT 0x6 any PC += offset if dst > src signed
JSGE 0x7 any PC += offset if dst >= src signed
CALL 0x8 0x0 call helper function by static ID {CALL, K, JMP} only, see `Helper functions`_
CALL 0x8 0x1 call PC += imm {CALL, K, JMP} only, see `Program-local functions`_
CALL 0x8 0x2 call helper function by BTF ID {CALL, K, JMP} only, see `Helper functions`_
EXIT 0x9 0x0 return {CALL, K, JMP} only
JLT 0xa any PC += offset if dst < src unsigned
JLE 0xb any PC += offset if dst <= src unsigned
JSLT 0xc any PC += offset if dst < src signed
JSLE 0xd any PC += offset if dst <= src signed
======== ===== ======= ================================= ===================================================
where 'PC' denotes the program counter, and the offset to increment by
is in units of 64-bit instructions relative to the instruction following
the jump instruction. Thus 'PC += 1' skips execution of the next
instruction if it's a basic instruction or results in undefined behavior
if the next instruction is a 128-bit wide instruction.
The BPF program needs to store the return value into register R0 before doing an
``EXIT``.
@@ -475,7 +491,7 @@ where 's>=' indicates a signed '>=' comparison.
gotol +imm
where 'imm' means the branch offset comes from insn 'imm' field.
where 'imm' means the branch offset comes from the 'imm' field.
Note that there are two flavors of ``JA`` instructions. The
``JMP`` class permits a 16-bit jump offset specified by the 'offset'
@@ -493,26 +509,26 @@ Helper functions
Helper functions are a concept whereby BPF programs can call into a
set of function calls exposed by the underlying platform.
Historically, each helper function was identified by an address
encoded in the imm field. The available helper functions may differ
for each program type, but address values are unique across all program types.
Historically, each helper function was identified by a static ID
encoded in the 'imm' field. The available helper functions may differ
for each program type, but static IDs are unique across all program types.
Platforms that support the BPF Type Format (BTF) support identifying
a helper function by a BTF ID encoded in the imm field, where the BTF ID
a helper function by a BTF ID encoded in the 'imm' field, where the BTF ID
identifies the helper name and type.
Program-local functions
~~~~~~~~~~~~~~~~~~~~~~~
Program-local functions are functions exposed by the same BPF program as the
caller, and are referenced by offset from the call instruction, similar to
``JA``. The offset is encoded in the imm field of the call instruction.
A ``EXIT`` within the program-local function will return to the caller.
``JA``. The offset is encoded in the 'imm' field of the call instruction.
An ``EXIT`` within the program-local function will return to the caller.
Load and store instructions
===========================
For load and store instructions (``LD``, ``LDX``, ``ST``, and ``STX``), the
8-bit 'opcode' field is divided as::
8-bit 'opcode' field is divided as follows::
+-+-+-+-+-+-+-+-+
|mode |sz |class|
@@ -580,7 +596,7 @@ instructions that transfer data between a register and memory.
dst = *(signed size *) (src + offset)
Where size is one of: ``B``, ``H``, or ``W``, and
Where '<size>' is one of: ``B``, ``H``, or ``W``, and
'signed size' is one of: s8, s16, or s32.
Atomic operations
@@ -662,11 +678,11 @@ src_reg pseudocode imm type dst type
======= ========================================= =========== ==============
0x0 dst = (next_imm << 32) | imm integer integer
0x1 dst = map_by_fd(imm) map fd map
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data pointer
0x3 dst = var_addr(imm) variable id data pointer
0x4 dst = code_addr(imm) integer code pointer
0x2 dst = map_val(map_by_fd(imm)) + next_imm map fd data address
0x3 dst = var_addr(imm) variable id data address
0x4 dst = code_addr(imm) integer code address
0x5 dst = map_by_idx(imm) map index map
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data pointer
0x6 dst = map_val(map_by_idx(imm)) + next_imm map index data address
======= ========================================= =========== ==============
where
Documentation/core-api/floating-point.rst
+78
View File
@@ -0,0 +1,78 @@
.. SPDX-License-Identifier: GPL-2.0+
Floating-point API
==================
Kernel code is normally prohibited from using floating-point (FP) registers or
instructions, including the C float and double data types. This rule reduces
system call overhead, because the kernel does not need to save and restore the
userspace floating-point register state.
However, occasionally drivers or library functions may need to include FP code.
This is supported by isolating the functions containing FP code to a separate
translation unit (a separate source file), and saving/restoring the FP register
state around calls to those functions. This creates "critical sections" of
floating-point usage.
The reason for this isolation is to prevent the compiler from generating code
touching the FP registers outside these critical sections. Compilers sometimes
use FP registers to optimize inlined ``memcpy`` or variable assignment, as
floating-point registers may be wider than general-purpose registers.
Usability of floating-point code within the kernel is architecture-specific.
Additionally, because a single kernel may be configured to support platforms
both with and without a floating-point unit, FPU availability must be checked
both at build time and at run time.
Several architectures implement the generic kernel floating-point API from
``linux/fpu.h``, as described below. Some other architectures implement their
own unique APIs, which are documented separately.
Build-time API
--------------
Floating-point code may be built if the option ``ARCH_HAS_KERNEL_FPU_SUPPORT``
is enabled. For C code, such code must be placed in a separate file, and that
file must have its compilation flags adjusted using the following pattern::
CFLAGS_foo.o += $(CC_FLAGS_FPU)
CFLAGS_REMOVE_foo.o += $(CC_FLAGS_NO_FPU)
Architectures are expected to define one or both of these variables in their
top-level Makefile as needed. For example::
CC_FLAGS_FPU := -mhard-float
or::
CC_FLAGS_NO_FPU := -msoft-float
Normal kernel code is assumed to use the equivalent of ``CC_FLAGS_NO_FPU``.
Runtime API
-----------
The runtime API is provided in ``linux/fpu.h``. This header cannot be included
from files implementing FP code (those with their compilation flags adjusted as
above). Instead, it must be included when defining the FP critical sections.
.. c:function:: bool kernel_fpu_available( void )
This function reports if floating-point code can be used on this CPU or
platform. The value returned by this function is not expected to change
at runtime, so it only needs to be called once, not before every
critical section.
.. c:function:: void kernel_fpu_begin( void )
void kernel_fpu_end( void )
These functions create a floating-point critical section. It is only
valid to call ``kernel_fpu_begin()`` after a previous call to
``kernel_fpu_available()`` returned ``true``. These functions are only
guaranteed to be callable from (preemptible or non-preemptible) process
context.
Preemption may be disabled inside critical sections, so their size
should be minimized. They are *not* required to be reentrant. If the
caller expects to nest critical sections, it must implement its own
reference counting.
Documentation/core-api/index.rst
+2
View File
@@ -48,6 +48,7 @@ Library functionality that is used throughout the kernel.
errseq
wrappers/atomic_t
wrappers/atomic_bitops
floating-point
Low level entry and exit
========================
@@ -102,6 +103,7 @@ more memory-management documentation in Documentation/mm/index.rst.
dma-api-howto
dma-attributes
dma-isa-lpc
swiotlb
mm-api
genalloc
pin_user_pages
Documentation/core-api/swiotlb.rst
+321
View File
@@ -0,0 +1,321 @@
.. SPDX-License-Identifier: GPL-2.0
===============
DMA and swiotlb
===============
swiotlb is a memory buffer allocator used by the Linux kernel DMA layer. It is
typically used when a device doing DMA can't directly access the target memory
buffer because of hardware limitations or other requirements. In such a case,
the DMA layer calls swiotlb to allocate a temporary memory buffer that conforms
to the limitations. The DMA is done to/from this temporary memory buffer, and
the CPU copies the data between the temporary buffer and the original target
memory buffer. This approach is generically called "bounce buffering", and the
temporary memory buffer is called a "bounce buffer".
Device drivers don't interact directly with swiotlb. Instead, drivers inform
the DMA layer of the DMA attributes of the devices they are managing, and use
the normal DMA map, unmap, and sync APIs when programming a device to do DMA.
These APIs use the device DMA attributes and kernel-wide settings to determine
if bounce buffering is necessary. If so, the DMA layer manages the allocation,
freeing, and sync'ing of bounce buffers. Since the DMA attributes are per
device, some devices in a system may use bounce buffering while others do not.
Because the CPU copies data between the bounce buffer and the original target
memory buffer, doing bounce buffering is slower than doing DMA directly to the
original memory buffer, and it consumes more CPU resources. So it is used only
when necessary for providing DMA functionality.
Usage Scenarios
---------------
swiotlb was originally created to handle DMA for devices with addressing
limitations. As physical memory sizes grew beyond 4 GiB, some devices could
only provide 32-bit DMA addresses. By allocating bounce buffer memory below
the 4 GiB line, these devices with addressing limitations could still work and
do DMA.
More recently, Confidential Computing (CoCo) VMs have the guest VM's memory
encrypted by default, and the memory is not accessible by the host hypervisor
and VMM. For the host to do I/O on behalf of the guest, the I/O must be
directed to guest memory that is unencrypted. CoCo VMs set a kernel-wide option
to force all DMA I/O to use bounce buffers, and the bounce buffer memory is set
up as unencrypted. The host does DMA I/O to/from the bounce buffer memory, and
the Linux kernel DMA layer does "sync" operations to cause the CPU to copy the
data to/from the original target memory buffer. The CPU copying bridges between
the unencrypted and the encrypted memory. This use of bounce buffers allows
device drivers to "just work" in a CoCo VM, with no modifications
needed to handle the memory encryption complexity.
Other edge case scenarios arise for bounce buffers. For example, when IOMMU
mappings are set up for a DMA operation to/from a device that is considered
"untrusted", the device should be given access only to the memory containing
the data being transferred. But if that memory occupies only part of an IOMMU
granule, other parts of the granule may contain unrelated kernel data. Since
IOMMU access control is per-granule, the untrusted device can gain access to
the unrelated kernel data. This problem is solved by bounce buffering the DMA
operation and ensuring that unused portions of the bounce buffers do not
contain any unrelated kernel data.
Core Functionality
------------------
The primary swiotlb APIs are swiotlb_tbl_map_single() and
swiotlb_tbl_unmap_single(). The "map" API allocates a bounce buffer of a
specified size in bytes and returns the physical address of the buffer. The
buffer memory is physically contiguous. The expectation is that the DMA layer
maps the physical memory address to a DMA address, and returns the DMA address
to the driver for programming into the device. If a DMA operation specifies
multiple memory buffer segments, a separate bounce buffer must be allocated for
each segment. swiotlb_tbl_map_single() always does a "sync" operation (i.e., a
CPU copy) to initialize the bounce buffer to match the contents of the original
buffer.
swiotlb_tbl_unmap_single() does the reverse. If the DMA operation might have
updated the bounce buffer memory and DMA_ATTR_SKIP_CPU_SYNC is not set, the
unmap does a "sync" operation to cause a CPU copy of the data from the bounce
buffer back to the original buffer. Then the bounce buffer memory is freed.
swiotlb also provides "sync" APIs that correspond to the dma_sync_*() APIs that
a driver may use when control of a buffer transitions between the CPU and the
device. The swiotlb "sync" APIs cause a CPU copy of the data between the
original buffer and the bounce buffer. Like the dma_sync_*() APIs, the swiotlb
"sync" APIs support doing a partial sync, where only a subset of the bounce
buffer is copied to/from the original buffer.
Core Functionality Constraints
------------------------------
The swiotlb map/unmap/sync APIs must operate without blocking, as they are
called by the corresponding DMA APIs which may run in contexts that cannot
block. Hence the default memory pool for swiotlb allocations must be
pre-allocated at boot time (but see Dynamic swiotlb below). Because swiotlb
allocations must be physically contiguous, the entire default memory pool is
allocated as a single contiguous block.
The need to pre-allocate the default swiotlb pool creates a boot-time tradeoff.
The pool should be large enough to ensure that bounce buffer requests can
always be satisfied, as the non-blocking requirement means requests can't wait
for space to become available. But a large pool potentially wastes memory, as
this pre-allocated memory is not available for other uses in the system. The
tradeoff is particularly acute in CoCo VMs that use bounce buffers for all DMA
I/O. These VMs use a heuristic to set the default pool size to ~6% of memory,
with a max of 1 GiB, which has the potential to be very wasteful of memory.
Conversely, the heuristic might produce a size that is insufficient, depending
on the I/O patterns of the workload in the VM. The dynamic swiotlb feature
described below can help, but has limitations. Better management of the swiotlb
default memory pool size remains an open issue.
A single allocation from swiotlb is limited to IO_TLB_SIZE * IO_TLB_SEGSIZE
bytes, which is 256 KiB with current definitions. When a device's DMA settings
are such that the device might use swiotlb, the maximum size of a DMA segment
must be limited to that 256 KiB. This value is communicated to higher-level
kernel code via dma_map_mapping_size() and swiotlb_max_mapping_size(). If the
higher-level code fails to account for this limit, it may make requests that
are too large for swiotlb, and get a "swiotlb full" error.
A key device DMA setting is "min_align_mask", which is a power of 2 minus 1
so that some number of low order bits are set, or it may be zero. swiotlb
allocations ensure these min_align_mask bits of the physical address of the
bounce buffer match the same bits in the address of the original buffer. When
min_align_mask is non-zero, it may produce an "alignment offset" in the address
of the bounce buffer that slightly reduces the maximum size of an allocation.
This potential alignment offset is reflected in the value returned by
swiotlb_max_mapping_size(), which can show up in places like
/sys/block/<device>/queue/max_sectors_kb. For example, if a device does not use
swiotlb, max_sectors_kb might be 512 KiB or larger. If a device might use
swiotlb, max_sectors_kb will be 256 KiB. When min_align_mask is non-zero,
max_sectors_kb might be even smaller, such as 252 KiB.
swiotlb_tbl_map_single() also takes an "alloc_align_mask" parameter. This
parameter specifies the allocation of bounce buffer space must start at a
physical address with the alloc_align_mask bits set to zero. But the actual
bounce buffer might start at a larger address if min_align_mask is non-zero.
Hence there may be pre-padding space that is allocated prior to the start of
the bounce buffer. Similarly, the end of the bounce buffer is rounded up to an
alloc_align_mask boundary, potentially resulting in post-padding space. Any
pre-padding or post-padding space is not initialized by swiotlb code. The
"alloc_align_mask" parameter is used by IOMMU code when mapping for untrusted
devices. It is set to the granule size - 1 so that the bounce buffer is
allocated entirely from granules that are not used for any other purpose.
Data structures concepts
------------------------
Memory used for swiotlb bounce buffers is allocated from overall system memory
as one or more "pools". The default pool is allocated during system boot with a
default size of 64 MiB. The default pool size may be modified with the
"swiotlb=" kernel boot line parameter. The default size may also be adjusted
due to other conditions, such as running in a CoCo VM, as described above. If
CONFIG_SWIOTLB_DYNAMIC is enabled, additional pools may be allocated later in
the life of the system. Each pool must be a contiguous range of physical
memory. The default pool is allocated below the 4 GiB physical address line so
it works for devices that can only address 32-bits of physical memory (unless
architecture-specific code provides the SWIOTLB_ANY flag). In a CoCo VM, the
pool memory must be decrypted before swiotlb is used.
Each pool is divided into "slots" of size IO_TLB_SIZE, which is 2 KiB with
current definitions. IO_TLB_SEGSIZE contiguous slots (128 slots) constitute
what might be called a "slot set". When a bounce buffer is allocated, it
occupies one or more contiguous slots. A slot is never shared by multiple
bounce buffers. Furthermore, a bounce buffer must be allocated from a single
slot set, which leads to the maximum bounce buffer size being IO_TLB_SIZE *
IO_TLB_SEGSIZE. Multiple smaller bounce buffers may co-exist in a single slot
set if the alignment and size constraints can be met.
Slots are also grouped into "areas", with the constraint that a slot set exists
entirely in a single area. Each area has its own spin lock that must be held to
manipulate the slots in that area. The division into areas avoids contending
for a single global spin lock when swiotlb is heavily used, such as in a CoCo
VM. The number of areas defaults to the number of CPUs in the system for
maximum parallelism, but since an area can't be smaller than IO_TLB_SEGSIZE
slots, it might be necessary to assign multiple CPUs to the same area. The
number of areas can also be set via the "swiotlb=" kernel boot parameter.
When allocating a bounce buffer, if the area associated with the calling CPU
does not have enough free space, areas associated with other CPUs are tried
sequentially. For each area tried, the area's spin lock must be obtained before
trying an allocation, so contention may occur if swiotlb is relatively busy
overall. But an allocation request does not fail unless all areas do not have
enough free space.
IO_TLB_SIZE, IO_TLB_SEGSIZE, and the number of areas must all be powers of 2 as
the code uses shifting and bit masking to do many of the calculations. The
number of areas is rounded up to a power of 2 if necessary to meet this
requirement.
The default pool is allocated with PAGE_SIZE alignment. If an alloc_align_mask
argument to swiotlb_tbl_map_single() specifies a larger alignment, one or more
initial slots in each slot set might not meet the alloc_align_mask criterium.
Because a bounce buffer allocation can't cross a slot set boundary, eliminating
those initial slots effectively reduces the max size of a bounce buffer.
Currently, there's no problem because alloc_align_mask is set based on IOMMU
granule size, and granules cannot be larger than PAGE_SIZE. But if that were to
change in the future, the initial pool allocation might need to be done with
alignment larger than PAGE_SIZE.
Dynamic swiotlb
---------------
When CONFIG_DYNAMIC_SWIOTLB is enabled, swiotlb can do on-demand expansion of
the amount of memory available for allocation as bounce buffers. If a bounce
buffer request fails due to lack of available space, an asynchronous background
task is kicked off to allocate memory from general system memory and turn it
into an swiotlb pool. Creating an additional pool must be done asynchronously
because the memory allocation may block, and as noted above, swiotlb requests
are not allowed to block. Once the background task is kicked off, the bounce
buffer request creates a "transient pool" to avoid returning an "swiotlb full"
error. A transient pool has the size of the bounce buffer request, and is
deleted when the bounce buffer is freed. Memory for this transient pool comes
from the general system memory atomic pool so that creation does not block.
Creating a transient pool has relatively high cost, particularly in a CoCo VM
where the memory must be decrypted, so it is done only as a stopgap until the
background task can add another non-transient pool.
Adding a dynamic pool has limitations. Like with the default pool, the memory
must be physically contiguous, so the size is limited to MAX_PAGE_ORDER pages
(e.g., 4 MiB on a typical x86 system). Due to memory fragmentation, a max size
allocation may not be available. The dynamic pool allocator tries smaller sizes
until it succeeds, but with a minimum size of 1 MiB. Given sufficient system
memory fragmentation, dynamically adding a pool might not succeed at all.
The number of areas in a dynamic pool may be different from the number of areas
in the default pool. Because the new pool size is typically a few MiB at most,
the number of areas will likely be smaller. For example, with a new pool size
of 4 MiB and the 256 KiB minimum area size, only 16 areas can be created. If
the system has more than 16 CPUs, multiple CPUs must share an area, creating
more lock contention.
New pools added via dynamic swiotlb are linked together in a linear list.
swiotlb code frequently must search for the pool containing a particular
swiotlb physical address, so that search is linear and not performant with a
large number of dynamic pools. The data structures could be improved for
faster searches.
Overall, dynamic swiotlb works best for small configurations with relatively
few CPUs. It allows the default swiotlb pool to be smaller so that memory is
not wasted, with dynamic pools making more space available if needed (as long
as fragmentation isn't an obstacle). It is less useful for large CoCo VMs.
Data Structure Details
----------------------
swiotlb is managed with four primary data structures: io_tlb_mem, io_tlb_pool,
io_tlb_area, and io_tlb_slot. io_tlb_mem describes a swiotlb memory allocator,
which includes the default memory pool and any dynamic or transient pools
linked to it. Limited statistics on swiotlb usage are kept per memory allocator
and are stored in this data structure. These statistics are available under
/sys/kernel/debug/swiotlb when CONFIG_DEBUG_FS is set.
io_tlb_pool describes a memory pool, either the default pool, a dynamic pool,
or a transient pool. The description includes the start and end addresses of
the memory in the pool, a pointer to an array of io_tlb_area structures, and a
pointer to an array of io_tlb_slot structures that are associated with the pool.
io_tlb_area describes an area. The primary field is the spin lock used to
serialize access to slots in the area. The io_tlb_area array for a pool has an
entry for each area, and is accessed using a 0-based area index derived from the
calling processor ID. Areas exist solely to allow parallel access to swiotlb
from multiple CPUs.
io_tlb_slot describes an individual memory slot in the pool, with size
IO_TLB_SIZE (2 KiB currently). The io_tlb_slot array is indexed by the slot
index computed from the bounce buffer address relative to the starting memory
address of the pool. The size of struct io_tlb_slot is 24 bytes, so the
overhead is about 1% of the slot size.
The io_tlb_slot array is designed to meet several requirements. First, the DMA
APIs and the corresponding swiotlb APIs use the bounce buffer address as the
identifier for a bounce buffer. This address is returned by
swiotlb_tbl_map_single(), and then passed as an argument to
swiotlb_tbl_unmap_single() and the swiotlb_sync_*() functions. The original
memory buffer address obviously must be passed as an argument to
swiotlb_tbl_map_single(), but it is not passed to the other APIs. Consequently,
swiotlb data structures must save the original memory buffer address so that it
can be used when doing sync operations. This original address is saved in the
io_tlb_slot array.
Second, the io_tlb_slot array must handle partial sync requests. In such cases,
the argument to swiotlb_sync_*() is not the address of the start of the bounce
buffer but an address somewhere in the middle of the bounce buffer, and the
address of the start of the bounce buffer isn't known to swiotlb code. But
swiotlb code must be able to calculate the corresponding original memory buffer
address to do the CPU copy dictated by the "sync". So an adjusted original
memory buffer address is populated into the struct io_tlb_slot for each slot
occupied by the bounce buffer. An adjusted "alloc_size" of the bounce buffer is
also recorded in each struct io_tlb_slot so a sanity check can be performed on
the size of the "sync" operation. The "alloc_size" field is not used except for
the sanity check.
Third, the io_tlb_slot array is used to track available slots. The "list" field
in struct io_tlb_slot records how many contiguous available slots exist starting
at that slot. A "0" indicates that the slot is occupied. A value of "1"
indicates only the current slot is available. A value of "2" indicates the
current slot and the next slot are available, etc. The maximum value is
IO_TLB_SEGSIZE, which can appear in the first slot in a slot set, and indicates
that the entire slot set is available. These values are used when searching for
available slots to use for a new bounce buffer. They are updated when allocating
a new bounce buffer and when freeing a bounce buffer. At pool creation time, the
"list" field is initialized to IO_TLB_SEGSIZE down to 1 for the slots in every
slot set.
Fourth, the io_tlb_slot array keeps track of any "padding slots" allocated to
meet alloc_align_mask requirements described above. When
swiotlb_tlb_map_single() allocates bounce buffer space to meet alloc_align_mask
requirements, it may allocate pre-padding space across zero or more slots. But
when swiotbl_tlb_unmap_single() is called with the bounce buffer address, the
alloc_align_mask value that governed the allocation, and therefore the
allocation of any padding slots, is not known. The "pad_slots" field records
the number of padding slots so that swiotlb_tbl_unmap_single() can free them.
The "pad_slots" value is recorded only in the first non-padding slot allocated
to the bounce buffer.
Restricted pools
----------------
The swiotlb machinery is also used for "restricted pools", which are pools of
memory separate from the default swiotlb pool, and that are dedicated for DMA
use by a particular device. Restricted pools provide a level of DMA memory
protection on systems with limited hardware protection capabilities, such as
those lacking an IOMMU. Such usage is specified by DeviceTree entries and
requires that CONFIG_DMA_RESTRICTED_POOL is set. Each restricted pool is based
on its own io_tlb_mem data structure that is independent of the main swiotlb
io_tlb_mem.
Restricted pools add swiotlb_alloc() and swiotlb_free() APIs, which are called
from the dma_alloc_*() and dma_free_*() APIs. The swiotlb_alloc/free() APIs
allocate/free slots from/to the restricted pool directly and do not go through
swiotlb_tbl_map/unmap_single().
Documentation/dev-tools/checkpatch.rst
+14
View File
@@ -906,6 +906,20 @@ Macros, Attributes and Symbols
See: https://lore.kernel.org/lkml/1399671106.2912.21.camel@joe-AO725/
**MACRO_ARG_UNUSED**
If function-like macros do not utilize a parameter, it might result
in a build warning. We advocate for utilizing static inline functions
to replace such macros.
For example, for a macro such as the one below::
#define test(a) do { } while (0)
there would be a warning like below::
WARNING: Argument 'a' is not used in function-like macro.
See: https://www.kernel.org/doc/html/latest/process/coding-style.html#macros-enums-and-rtl
**SINGLE_STATEMENT_DO_WHILE_MACRO**
For the multi-statement macros, it is necessary to use the do-while
loop to avoid unpredictable code paths. The do-while loop helps to
Documentation/devicetree/bindings/Makefile
+21 -15
View File
@@ -25,23 +25,25 @@ quiet_cmd_extract_ex = DTEX $@
$(obj)/%.example.dts: $(src)/%.yaml check_dtschema_version FORCE
$(call if_changed,extract_ex)
find_all_cmd = find $(srctree)/$(src) \( -name '*.yaml' ! \
find_all_cmd = find $(src) \( -name '*.yaml' ! \
-name 'processed-schema*' \)
find_cmd = $(find_all_cmd) | \
sed 's|^$(srctree)/||' | \
grep -F -e "$(subst :," -e ",$(DT_SCHEMA_FILES))" | \
sed 's|^|$(srctree)/|'
CHK_DT_DOCS := $(shell $(find_cmd))
CHK_DT_EXAMPLES := $(patsubst $(srctree)/%.yaml,%.example.dtb, $(shell $(find_cmd)))
quiet_cmd_yamllint = LINT $(src)
cmd_yamllint = ($(find_cmd) | \
xargs -n200 -P$$(nproc) \
$(DT_SCHEMA_LINT) -f parsable -c $(srctree)/$(src)/.yamllint >&2) || true
$(DT_SCHEMA_LINT) -f parsable -c $(src)/.yamllint >&2) \
&& touch $@ || true
quiet_cmd_chk_bindings = CHKDT $@
quiet_cmd_chk_bindings = CHKDT $(src)
cmd_chk_bindings = ($(find_cmd) | \
xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(srctree)/$(src)) || true
xargs -n200 -P$$(nproc) $(DT_DOC_CHECKER) -u $(src)) \
&& touch $@ || true
quiet_cmd_mk_schema = SCHEMA $@
cmd_mk_schema = f=$$(mktemp) ; \
@@ -49,12 +51,6 @@ quiet_cmd_mk_schema = SCHEMA $@
$(DT_MK_SCHEMA) -j $(DT_MK_SCHEMA_FLAGS) @$$f > $@ ; \
rm -f $$f
define rule_chkdt
$(if $(DT_SCHEMA_LINT),$(call cmd,yamllint),)
$(call cmd,chk_bindings)
$(call cmd,mk_schema)
endef
DT_DOCS = $(patsubst $(srctree)/%,%,$(shell $(find_all_cmd)))
override DTC_FLAGS := \
@@ -64,12 +60,19 @@ override DTC_FLAGS := \
-Wno-unique_unit_address \
-Wunique_unit_address_if_enabled
$(obj)/processed-schema.json: $(DT_DOCS) $(src)/.yamllint check_dtschema_version FORCE
$(call if_changed_rule,chkdt)
$(obj)/processed-schema.json: $(DT_DOCS) check_dtschema_version FORCE
$(call if_changed,mk_schema)
targets += .dt-binding.checked .yamllint.checked
$(obj)/.yamllint.checked: $(DT_DOCS) $(src)/.yamllint FORCE
$(if $(DT_SCHEMA_LINT),$(call if_changed,yamllint),)
$(obj)/.dt-binding.checked: $(DT_DOCS) FORCE
$(call if_changed,chk_bindings)
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))
targets += $(patsubst $(obj)/%,%, $(CHK_DT_EXAMPLES))
targets += $(patsubst $(obj)/%.dtb,%.dts, $(CHK_DT_EXAMPLES))
# Hack: avoid 'Argument list too long' error for 'make clean'. Remove most of
# build artifacts here before they are processed by scripts/Makefile.clean
@@ -78,3 +81,6 @@ clean-files = $(shell find $(obj) \( -name '*.example.dts' -o \
dt_compatible_check: $(obj)/processed-schema.json
$(Q)$(srctree)/scripts/dtc/dt-extract-compatibles $(srctree) | xargs dt-check-compatible -v -s $<
PHONY += dt_binding_check
dt_binding_check: $(obj)/.dt-binding.checked $(obj)/.yamllint.checked $(CHK_DT_EXAMPLES)
Documentation/devicetree/bindings/arm/altera/socfpga-sdram-controller.txt
-12
View File
@@ -1,12 +0,0 @@
Altera SOCFPGA SDRAM Controller
Required properties:
- compatible : Should contain "altr,sdr-ctl" and "syscon".
syscon is required by the Altera SOCFPGA SDRAM EDAC.
- reg : Should contain 1 register range (address and length)
Example:
sdr: sdr@ffc25000 {
compatible = "altr,sdr-ctl", "syscon";
reg = <0xffc25000 0x1000>;
};
Documentation/devicetree/bindings/arm/amlogic.yaml
+13
View File
@@ -157,6 +157,7 @@ properties:
items:
- enum:
- bananapi,bpi-cm4io
- mntre,reform2-cm4
- const: bananapi,bpi-cm4
- const: amlogic,a311d
- const: amlogic,g12b
@@ -201,6 +202,18 @@ properties:
- amlogic,ad402
- const: amlogic,a1
- description: Boards with the Amlogic A4 A113L2 SoC
items:
- enum:
- amlogic,ba400
- const: amlogic,a4
- description: Boards with the Amlogic A5 A113X2 SoC
items:
- enum:
- amlogic,av400
- const: amlogic,a5
- description: Boards with the Amlogic C3 C302X/C308L SoC
items:
- enum:
Documentation/devicetree/bindings/arm/apm/scu.txt
-17
View File
@@ -1,17 +0,0 @@
APM X-GENE SoC series SCU Registers
This system clock unit contain various register that control block resets,
clock enable/disables, clock divisors and other deepsleep registers.
Properties:
- compatible : should contain two values. First value must be:
- "apm,xgene-scu"
second value must be always "syscon".
- reg : offset and length of the register set.
Example :
scu: system-clk-controller@17000000 {
compatible = "apm,xgene-scu","syscon";
reg = <0x0 0x17000000 0x0 0x400>;
};
Documentation/devicetree/bindings/arm/aspeed/aspeed.yaml
+6
View File
@@ -35,7 +35,10 @@ properties:
- ampere,mtjade-bmc
- aspeed,ast2500-evb
- asrock,e3c246d4i-bmc
- asrock,e3c256d4i-bmc
- asrock,romed8hm3-bmc
- asrock,spc621d8hm3-bmc
- asrock,x570d4u-bmc
- bytedance,g220a-bmc
- facebook,cmm-bmc
- facebook,minipack-bmc
@@ -74,15 +77,18 @@ properties:
- ampere,mtmitchell-bmc
- aspeed,ast2600-evb
- aspeed,ast2600-evb-a1
- asus,x4tf-bmc
- facebook,bletchley-bmc
- facebook,cloudripper-bmc
- facebook,elbert-bmc
- facebook,fuji-bmc
- facebook,greatlakes-bmc
- facebook,harma-bmc
- facebook,minerva-cmc
- facebook,yosemite4-bmc
- ibm,everest-bmc
- ibm,rainier-bmc
- ibm,system1-bmc
- ibm,tacoma-bmc
- inventec,starscream-bmc
- inventec,transformer-bmc
Documentation/devicetree/bindings/arm/marvell/armada-37xx.txt
-32
View File
@@ -1,32 +0,0 @@
Power management
----------------
For power management (particularly DVFS and AVS), the North Bridge
Power Management component is needed:
Required properties:
- compatible : should contain "marvell,armada-3700-nb-pm", "syscon";
- reg : the register start and length for the North Bridge
Power Management
Example:
nb_pm: syscon@14000 {
compatible = "marvell,armada-3700-nb-pm", "syscon";
reg = <0x14000 0x60>;
}
AVS
---
For AVS an other component is needed:
Required properties:
- compatible : should contain "marvell,armada-3700-avs", "syscon";
- reg : the register start and length for the AVS
Example:
avs: avs@11500 {
compatible = "marvell,armada-3700-avs", "syscon";
reg = <0x11500 0x40>;
}
Documentation/devicetree/bindings/arm/qcom,coresight-tpda.yaml
+15 -19
View File
@@ -66,13 +66,11 @@ properties:
- const: apb_pclk
in-ports:
type: object
description: |
Input connections from TPDM to TPDA
$ref: /schemas/graph.yaml#/properties/ports
out-ports:
type: object
description: |
Output connections from the TPDA to legacy CoreSight trace bus.
$ref: /schemas/graph.yaml#/properties/ports
@@ -97,33 +95,31 @@ examples:
# minimum tpda definition.
- |
tpda@6004000 {
compatible = "qcom,coresight-tpda", "arm,primecell";
reg = <0x6004000 0x1000>;
compatible = "qcom,coresight-tpda", "arm,primecell";
reg = <0x6004000 0x1000>;
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
clocks = <&aoss_qmp>;
clock-names = "apb_pclk";
in-ports {
#address-cells = <1>;
#size-cells = <0>;
in-ports {
#address-cells = <1>;
#size-cells = <0>;
port@0 {
reg = <0>;
tpda_qdss_0_in_tpdm_dcc: endpoint {
remote-endpoint =
<&tpdm_dcc_out_tpda_qdss_0>;
};
remote-endpoint = <&tpdm_dcc_out_tpda_qdss_0>;
};
};
};
out-ports {
port {
tpda_qdss_out_funnel_in0: endpoint {
remote-endpoint =
<&funnel_in0_in_tpda_qdss>;
};
out-ports {
port {
tpda_qdss_out_funnel_in0: endpoint {
remote-endpoint = <&funnel_in0_in_tpda_qdss>;
};
};
};
};
};
...
Documentation/devicetree/bindings/clock/airoha,en7523-scu.yaml
+29 -2
View File
@@ -29,10 +29,13 @@ description: |
properties:
compatible:
items:
- const: airoha,en7523-scu
- enum:
- airoha,en7523-scu
- airoha,en7581-scu
reg:
maxItems: 2
minItems: 2
maxItems: 3
"#clock-cells":
description:
@@ -45,6 +48,30 @@ required:
- reg
- '#clock-cells'
allOf:
- if:
properties:
compatible:
const: airoha,en7523-scu
then:
properties:
reg:
items:
- description: scu base address
- description: misc scu base address
- if:
properties:
compatible:
const: airoha,en7581-scu
then:
properties:
reg:
items:
- description: scu base address
- description: misc scu base address
- description: pb scu base address
additionalProperties: false
examples:
Documentation/devicetree/bindings/clock/fixed-clock.yaml
+9
View File
@@ -11,6 +11,15 @@ maintainers:
- Stephen Boyd <sboyd@kernel.org>
properties:
$nodename:
anyOf:
- description:
Preferred name is 'clock-<freq>' with <freq> being the output
frequency as defined in the 'clock-frequency' property.
pattern: "^clock-([0-9]+|[a-z0-9-]+)$"
- description: Any name allowed
deprecated: true
compatible:
const: fixed-clock
Documentation/devicetree/bindings/clock/fixed-factor-clock.yaml
+9
View File
@@ -11,6 +11,15 @@ maintainers:
- Stephen Boyd <sboyd@kernel.org>
properties:
$nodename:
anyOf:
- description:
If the frequency is fixed, the preferred name is 'clock-<freq>' with
<freq> being the output frequency.
pattern: "^clock-([0-9]+|[0-9a-z-]+)$"
- description: Any name allowed
deprecated: true
compatible:
enum:
- fixed-factor-clock
Documentation/devicetree/bindings/clock/loongson,ls2k-clk.yaml
+3 -1
View File
@@ -16,7 +16,9 @@ description: |
properties:
compatible:
enum:
- loongson,ls2k-clk
- loongson,ls2k0500-clk
- loongson,ls2k-clk # This is for Loongson-2K1000
- loongson,ls2k2000-clk
reg:
maxItems: 1
Documentation/devicetree/bindings/clock/nxp,imx95-blk-ctl.yaml
+56
View File
@@ -0,0 +1,56 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/nxp,imx95-blk-ctl.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX95 Block Control
maintainers:
- Peng Fan <peng.fan@nxp.com>
properties:
compatible:
items:
- enum:
- nxp,imx95-lvds-csr
- nxp,imx95-display-csr
- nxp,imx95-camera-csr
- nxp,imx95-vpu-csr
- const: syscon
reg:
maxItems: 1
power-domains:
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/nxp,imx95-clock.h
required:
- compatible
- reg
- '#clock-cells'
- power-domains
- clocks
additionalProperties: false
examples:
- |
syscon@4c410000 {
compatible = "nxp,imx95-vpu-csr", "syscon";
reg = <0x4c410000 0x10000>;
#clock-cells = <1>;
clocks = <&scmi_clk 114>;
power-domains = <&scmi_devpd 21>;
};
...
Documentation/devicetree/bindings/clock/nxp,imx95-display-master-csr.yaml
+64
View File
@@ -0,0 +1,64 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/nxp,imx95-display-master-csr.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: NXP i.MX95 Display Master Block Control
maintainers:
- Peng Fan <peng.fan@nxp.com>
properties:
compatible:
items:
- const: nxp,imx95-display-master-csr
- const: syscon
reg:
maxItems: 1
power-domains:
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/nxp,imx95-clock.h
mux-controller:
type: object
$ref: /schemas/mux/reg-mux.yaml
required:
- compatible
- reg
- '#clock-cells'
- mux-controller
- power-domains
- clocks
additionalProperties: false
examples:
- |
syscon@4c410000 {
compatible = "nxp,imx95-display-master-csr", "syscon";
reg = <0x4c410000 0x10000>;
#clock-cells = <1>;
clocks = <&scmi_clk 62>;
power-domains = <&scmi_devpd 3>;
mux: mux-controller {
compatible = "mmio-mux";
#mux-control-cells = <1>;
mux-reg-masks = <0x4 0x00000001>; /* Pixel_link_sel */
idle-states = <0>;
};
};
...
Documentation/devicetree/bindings/clock/qcom,hfpll.txt
-63
View File
@@ -1,63 +0,0 @@
High-Frequency PLL (HFPLL)
PROPERTIES
- compatible:
Usage: required
Value type: <string>:
shall contain only one of the following. The generic
compatible "qcom,hfpll" should be also included.
"qcom,hfpll-ipq8064", "qcom,hfpll"
"qcom,hfpll-apq8064", "qcom,hfpll"
"qcom,hfpll-msm8974", "qcom,hfpll"
"qcom,hfpll-msm8960", "qcom,hfpll"
"qcom,msm8976-hfpll-a53", "qcom,hfpll"
"qcom,msm8976-hfpll-a72", "qcom,hfpll"
"qcom,msm8976-hfpll-cci", "qcom,hfpll"
- reg:
Usage: required
Value type: <prop-encoded-array>
Definition: address and size of HPLL registers. An optional second
element specifies the address and size of the alias
register region.
- clocks:
Usage: required
Value type: <prop-encoded-array>
Definition: reference to the xo clock.
- clock-names:
Usage: required
Value type: <stringlist>
Definition: must be "xo".
- clock-output-names:
Usage: required
Value type: <string>
Definition: Name of the PLL. Typically hfpllX where X is a CPU number
starting at 0. Otherwise hfpll_Y where Y is more specific
such as "l2".
Example:
1) An HFPLL for the L2 cache.
clock-controller@f9016000 {
compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
reg = <0xf9016000 0x30>;
clocks = <&xo_board>;
clock-names = "xo";
clock-output-names = "hfpll_l2";
};
2) An HFPLL for CPU0. This HFPLL has the alias register region.
clock-controller@f908a000 {
compatible = "qcom,hfpll-ipq8064", "qcom,hfpll";
reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
clocks = <&xo_board>;
clock-names = "xo";
clock-output-names = "hfpll0";
};
Documentation/devicetree/bindings/clock/qcom,hfpll.yaml
+69
View File
@@ -0,0 +1,69 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/qcom,hfpll.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Qualcomm High-Frequency PLL
maintainers:
- Bjorn Andersson <andersson@kernel.org>
description:
The HFPLL is used as CPU PLL on various Qualcomm SoCs.
properties:
compatible:
oneOf:
- enum:
- qcom,msm8974-hfpll
- qcom,msm8976-hfpll-a53
- qcom,msm8976-hfpll-a72
- qcom,msm8976-hfpll-cci
- qcom,qcs404-hfpll
- const: qcom,hfpll
deprecated: true
reg:
items:
- description: HFPLL registers
- description: Alias register region
minItems: 1
'#clock-cells':
const: 0
clocks:
items:
- description: board XO clock
clock-names:
items:
- const: xo
clock-output-names:
description:
Name of the PLL. Typically hfpllX where X is a CPU number starting at 0.
Otherwise hfpll_Y where Y is more specific such as "l2".
maxItems: 1
required:
- compatible
- reg
- '#clock-cells'
- clocks
- clock-names
- clock-output-names
additionalProperties: false
examples:
- |
clock-controller@f908a000 {
compatible = "qcom,msm8974-hfpll";
reg = <0xf908a000 0x30>, <0xf900a000 0x30>;
#clock-cells = <0>;
clock-output-names = "hfpll0";
clocks = <&xo_board>;
clock-names = "xo";
};
Documentation/devicetree/bindings/clock/renesas,rzg2l-cpg.yaml
+17 -1
View File
@@ -57,7 +57,8 @@ properties:
can be power-managed through Module Standby should refer to the CPG device
node in their "power-domains" property, as documented by the generic PM
Domain bindings in Documentation/devicetree/bindings/power/power-domain.yaml.
const: 0
The power domain specifiers defined in <dt-bindings/clock/r9a0*-cpg.h> could
be used to reference individual CPG power domains.
'#reset-cells':
description:
@@ -76,6 +77,21 @@ required:
additionalProperties: false
allOf:
- if:
properties:
compatible:
contains:
const: renesas,r9a08g045-cpg
then:
properties:
'#power-domain-cells':
const: 1
else:
properties:
'#power-domain-cells':
const: 0
examples:
- |
cpg: clock-controller@11010000 {
Documentation/devicetree/bindings/clock/samsung,s3c6400-clock.yaml
+57
View File
@@ -0,0 +1,57 @@
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
%YAML 1.2
---
$id: http://devicetree.org/schemas/clock/samsung,s3c6400-clock.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Samsung S3C6400 SoC clock controller
maintainers:
- Krzysztof Kozlowski <krzk@kernel.org>
description: |
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names and/or provided as clock inputs to this clock controller:
- "fin_pll" - PLL input clock (xtal/extclk) - required,
- "xusbxti" - USB xtal - required,
- "iiscdclk0" - I2S0 codec clock - optional,
- "iiscdclk1" - I2S1 codec clock - optional,
- "iiscdclk2" - I2S2 codec clock - optional,
- "pcmcdclk0" - PCM0 codec clock - optional,
- "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
All available clocks are defined as preprocessor macros in
include/dt-bindings/clock/samsung,s3c64xx-clock.h header.
properties:
compatible:
enum:
- samsung,s3c6400-clock
- samsung,s3c6410-clock
reg:
maxItems: 1
clocks:
maxItems: 1
"#clock-cells":
const: 1
required:
- compatible
- reg
- clocks
- "#clock-cells"
additionalProperties: false
examples:
- |
clock-controller@7e00f000 {
compatible = "samsung,s3c6410-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
clocks = <&fin_pll>;
};
Documentation/devicetree/bindings/clock/samsung,s3c64xx-clock.txt
-76
View File
@@ -1,76 +0,0 @@
* Samsung S3C64xx Clock Controller
The S3C64xx clock controller generates and supplies clock to various controllers
within the SoC. The clock binding described here is applicable to all SoCs in
the S3C64xx family.
Required Properties:
- compatible: should be one of the following.
- "samsung,s3c6400-clock" - controller compatible with S3C6400 SoC.
- "samsung,s3c6410-clock" - controller compatible with S3C6410 SoC.
- reg: physical base address of the controller and length of memory mapped
region.
- #clock-cells: should be 1.
Each clock is assigned an identifier and client nodes can use this identifier
to specify the clock which they consume. Some of the clocks are available only
on a particular S3C64xx SoC and this is specified where applicable.
All available clocks are defined as preprocessor macros in
dt-bindings/clock/samsung,s3c64xx-clock.h header and can be used in device
tree sources.
External clocks:
There are several clocks that are generated outside the SoC. It is expected
that they are defined using standard clock bindings with following
clock-output-names:
- "fin_pll" - PLL input clock (xtal/extclk) - required,
- "xusbxti" - USB xtal - required,
- "iiscdclk0" - I2S0 codec clock - optional,
- "iiscdclk1" - I2S1 codec clock - optional,
- "iiscdclk2" - I2S2 codec clock - optional,
- "pcmcdclk0" - PCM0 codec clock - optional,
- "pcmcdclk1" - PCM1 codec clock - optional, only S3C6410.
Example: Clock controller node:
clock: clock-controller@7e00f000 {
compatible = "samsung,s3c6410-clock";
reg = <0x7e00f000 0x1000>;
#clock-cells = <1>;
};
Example: Required external clocks:
fin_pll: clock-fin-pll {
compatible = "fixed-clock";
clock-output-names = "fin_pll";
clock-frequency = <12000000>;
#clock-cells = <0>;
};
xusbxti: clock-xusbxti {
compatible = "fixed-clock";
clock-output-names = "xusbxti";
clock-frequency = <48000000>;
#clock-cells = <0>;
};
Example: UART controller node that consumes the clock generated by the clock
controller (refer to the standard clock bindings for information about
"clocks" and "clock-names" properties):
uart0: serial@7f005000 {
compatible = "samsung,s3c6400-uart";
reg = <0x7f005000 0x100>;
interrupt-parent = <&vic1>;
interrupts = <5>;
clock-names = "uart", "clk_uart_baud2",
"clk_uart_baud3";
clocks = <&clock PCLK_UART0>, <&clocks PCLK_UART0>,
<&clock SCLK_UART>;
};
Documentation/devicetree/bindings/clock/sophgo,cv1800-clk.yaml
+2 -1
View File
@@ -4,7 +4,7 @@
$id: http://devicetree.org/schemas/clock/sophgo,cv1800-clk.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Sophgo CV1800 Series Clock Controller
title: Sophgo CV1800/SG2000 Series Clock Controller
maintainers:
- Inochi Amaoto <inochiama@outlook.com>
@@ -14,6 +14,7 @@ properties:
enum:
- sophgo,cv1800-clk
- sophgo,cv1810-clk
- sophgo,sg2000-clk
reg:
maxItems: 1
Documentation/devicetree/bindings/clock/st,stm32mp25-rcc.yaml
+158 -14
View File
@@ -38,14 +38,85 @@ properties:
- description: CK_SCMI_MSI Low Power Internal oscillator (~ 4 MHz or ~ 16 MHz)
- description: CK_SCMI_LSE Low Speed External oscillator (32 KHz)
- description: CK_SCMI_LSI Low Speed Internal oscillator (~ 32 KHz)
- description: CK_SCMI_HSE_DIV2 CK_SCMI_HSE divided by 2 (coud be gated)
- description: CK_SCMI_ICN_HS_MCU High Speed interconnect bus clock
- description: CK_SCMI_ICN_LS_MCU Low Speed interconnect bus clock
- description: CK_SCMI_ICN_SDMMC SDMMC interconnect bus clock
- description: CK_SCMI_ICN_DDR DDR interconnect bus clock
- description: CK_SCMI_ICN_DISPLAY Display interconnect bus clock
- description: CK_SCMI_ICN_HSL HSL interconnect bus clock
- description: CK_SCMI_ICN_NIC NIC interconnect bus clock
- description: CK_SCMI_ICN_VID Video interconnect bus clock
- description: CK_SCMI_FLEXGEN_07 flexgen clock 7
- description: CK_SCMI_FLEXGEN_08 flexgen clock 8
- description: CK_SCMI_FLEXGEN_09 flexgen clock 9
- description: CK_SCMI_FLEXGEN_10 flexgen clock 10
- description: CK_SCMI_FLEXGEN_11 flexgen clock 11
- description: CK_SCMI_FLEXGEN_12 flexgen clock 12
- description: CK_SCMI_FLEXGEN_13 flexgen clock 13
- description: CK_SCMI_FLEXGEN_14 flexgen clock 14
- description: CK_SCMI_FLEXGEN_15 flexgen clock 15
- description: CK_SCMI_FLEXGEN_16 flexgen clock 16
- description: CK_SCMI_FLEXGEN_17 flexgen clock 17
- description: CK_SCMI_FLEXGEN_18 flexgen clock 18
- description: CK_SCMI_FLEXGEN_19 flexgen clock 19
- description: CK_SCMI_FLEXGEN_20 flexgen clock 20
- description: CK_SCMI_FLEXGEN_21 flexgen clock 21
- description: CK_SCMI_FLEXGEN_22 flexgen clock 22
- description: CK_SCMI_FLEXGEN_23 flexgen clock 23
- description: CK_SCMI_FLEXGEN_24 flexgen clock 24
- description: CK_SCMI_FLEXGEN_25 flexgen clock 25
- description: CK_SCMI_FLEXGEN_26 flexgen clock 26
- description: CK_SCMI_FLEXGEN_27 flexgen clock 27
- description: CK_SCMI_FLEXGEN_28 flexgen clock 28
- description: CK_SCMI_FLEXGEN_29 flexgen clock 29
- description: CK_SCMI_FLEXGEN_30 flexgen clock 30
- description: CK_SCMI_FLEXGEN_31 flexgen clock 31
- description: CK_SCMI_FLEXGEN_32 flexgen clock 32
- description: CK_SCMI_FLEXGEN_33 flexgen clock 33
- description: CK_SCMI_FLEXGEN_34 flexgen clock 34
- description: CK_SCMI_FLEXGEN_35 flexgen clock 35
- description: CK_SCMI_FLEXGEN_36 flexgen clock 36
- description: CK_SCMI_FLEXGEN_37 flexgen clock 37
- description: CK_SCMI_FLEXGEN_38 flexgen clock 38
- description: CK_SCMI_FLEXGEN_39 flexgen clock 39
- description: CK_SCMI_FLEXGEN_40 flexgen clock 40
- description: CK_SCMI_FLEXGEN_41 flexgen clock 41
- description: CK_SCMI_FLEXGEN_42 flexgen clock 42
- description: CK_SCMI_FLEXGEN_43 flexgen clock 43
- description: CK_SCMI_FLEXGEN_44 flexgen clock 44
- description: CK_SCMI_FLEXGEN_45 flexgen clock 45
- description: CK_SCMI_FLEXGEN_46 flexgen clock 46
- description: CK_SCMI_FLEXGEN_47 flexgen clock 47
- description: CK_SCMI_FLEXGEN_48 flexgen clock 48
- description: CK_SCMI_FLEXGEN_49 flexgen clock 49
- description: CK_SCMI_FLEXGEN_50 flexgen clock 50
- description: CK_SCMI_FLEXGEN_51 flexgen clock 51
- description: CK_SCMI_FLEXGEN_52 flexgen clock 52
- description: CK_SCMI_FLEXGEN_53 flexgen clock 53
- description: CK_SCMI_FLEXGEN_54 flexgen clock 54
- description: CK_SCMI_FLEXGEN_55 flexgen clock 55
- description: CK_SCMI_FLEXGEN_56 flexgen clock 56
- description: CK_SCMI_FLEXGEN_57 flexgen clock 57
- description: CK_SCMI_FLEXGEN_58 flexgen clock 58
- description: CK_SCMI_FLEXGEN_59 flexgen clock 59
- description: CK_SCMI_FLEXGEN_60 flexgen clock 60
- description: CK_SCMI_FLEXGEN_61 flexgen clock 61
- description: CK_SCMI_FLEXGEN_62 flexgen clock 62
- description: CK_SCMI_FLEXGEN_63 flexgen clock 63
- description: CK_SCMI_ICN_APB1 Peripheral bridge 1
- description: CK_SCMI_ICN_APB2 Peripheral bridge 2
- description: CK_SCMI_ICN_APB3 Peripheral bridge 3
- description: CK_SCMI_ICN_APB4 Peripheral bridge 4
- description: CK_SCMI_ICN_APBDBG Peripheral bridge for degub
- description: CK_SCMI_TIMG1 Peripheral bridge for timer1
- description: CK_SCMI_TIMG2 Peripheral bridge for timer2
- description: CK_SCMI_PLL3 PLL3 clock
- description: clk_dsi_txbyte DSI byte clock
clock-names:
items:
- const: hse
- const: hsi
- const: msi
- const: lse
- const: lsi
access-controllers:
minItems: 1
maxItems: 2
required:
- compatible
@@ -53,7 +124,6 @@ required:
- '#clock-cells'
- '#reset-cells'
- clocks
- clock-names
additionalProperties: false
@@ -66,11 +136,85 @@ examples:
reg = <0x44200000 0x10000>;
#clock-cells = <1>;
#reset-cells = <1>;
clock-names = "hse", "hsi", "msi", "lse", "lsi";
clocks = <&scmi_clk CK_SCMI_HSE>,
<&scmi_clk CK_SCMI_HSI>,
<&scmi_clk CK_SCMI_MSI>,
<&scmi_clk CK_SCMI_LSE>,
<&scmi_clk CK_SCMI_LSI>;
clocks = <&scmi_clk CK_SCMI_HSE>,
<&scmi_clk CK_SCMI_HSI>,
<&scmi_clk CK_SCMI_MSI>,
<&scmi_clk CK_SCMI_LSE>,
<&scmi_clk CK_SCMI_LSI>,
<&scmi_clk CK_SCMI_HSE_DIV2>,
<&scmi_clk CK_SCMI_ICN_HS_MCU>,
<&scmi_clk CK_SCMI_ICN_LS_MCU>,
<&scmi_clk CK_SCMI_ICN_SDMMC>,
<&scmi_clk CK_SCMI_ICN_DDR>,
<&scmi_clk CK_SCMI_ICN_DISPLAY>,
<&scmi_clk CK_SCMI_ICN_HSL>,
<&scmi_clk CK_SCMI_ICN_NIC>,
<&scmi_clk CK_SCMI_ICN_VID>,
<&scmi_clk CK_SCMI_FLEXGEN_07>,
<&scmi_clk CK_SCMI_FLEXGEN_08>,
<&scmi_clk CK_SCMI_FLEXGEN_09>,
<&scmi_clk CK_SCMI_FLEXGEN_10>,
<&scmi_clk CK_SCMI_FLEXGEN_11>,
<&scmi_clk CK_SCMI_FLEXGEN_12>,
<&scmi_clk CK_SCMI_FLEXGEN_13>,
<&scmi_clk CK_SCMI_FLEXGEN_14>,
<&scmi_clk CK_SCMI_FLEXGEN_15>,
<&scmi_clk CK_SCMI_FLEXGEN_16>,
<&scmi_clk CK_SCMI_FLEXGEN_17>,
<&scmi_clk CK_SCMI_FLEXGEN_18>,
<&scmi_clk CK_SCMI_FLEXGEN_19>,
<&scmi_clk CK_SCMI_FLEXGEN_20>,
<&scmi_clk CK_SCMI_FLEXGEN_21>,
<&scmi_clk CK_SCMI_FLEXGEN_22>,
<&scmi_clk CK_SCMI_FLEXGEN_23>,
<&scmi_clk CK_SCMI_FLEXGEN_24>,
<&scmi_clk CK_SCMI_FLEXGEN_25>,
<&scmi_clk CK_SCMI_FLEXGEN_26>,
<&scmi_clk CK_SCMI_FLEXGEN_27>,
<&scmi_clk CK_SCMI_FLEXGEN_28>,
<&scmi_clk CK_SCMI_FLEXGEN_29>,
<&scmi_clk CK_SCMI_FLEXGEN_30>,
<&scmi_clk CK_SCMI_FLEXGEN_31>,
<&scmi_clk CK_SCMI_FLEXGEN_32>,
<&scmi_clk CK_SCMI_FLEXGEN_33>,
<&scmi_clk CK_SCMI_FLEXGEN_34>,
<&scmi_clk CK_SCMI_FLEXGEN_35>,
<&scmi_clk CK_SCMI_FLEXGEN_36>,
<&scmi_clk CK_SCMI_FLEXGEN_37>,
<&scmi_clk CK_SCMI_FLEXGEN_38>,
<&scmi_clk CK_SCMI_FLEXGEN_39>,
<&scmi_clk CK_SCMI_FLEXGEN_40>,
<&scmi_clk CK_SCMI_FLEXGEN_41>,
<&scmi_clk CK_SCMI_FLEXGEN_42>,
<&scmi_clk CK_SCMI_FLEXGEN_43>,
<&scmi_clk CK_SCMI_FLEXGEN_44>,
<&scmi_clk CK_SCMI_FLEXGEN_45>,
<&scmi_clk CK_SCMI_FLEXGEN_46>,
<&scmi_clk CK_SCMI_FLEXGEN_47>,
<&scmi_clk CK_SCMI_FLEXGEN_48>,
<&scmi_clk CK_SCMI_FLEXGEN_49>,
<&scmi_clk CK_SCMI_FLEXGEN_50>,
<&scmi_clk CK_SCMI_FLEXGEN_51>,
<&scmi_clk CK_SCMI_FLEXGEN_52>,
<&scmi_clk CK_SCMI_FLEXGEN_53>,
<&scmi_clk CK_SCMI_FLEXGEN_54>,
<&scmi_clk CK_SCMI_FLEXGEN_55>,
<&scmi_clk CK_SCMI_FLEXGEN_56>,
<&scmi_clk CK_SCMI_FLEXGEN_57>,
<&scmi_clk CK_SCMI_FLEXGEN_58>,
<&scmi_clk CK_SCMI_FLEXGEN_59>,
<&scmi_clk CK_SCMI_FLEXGEN_60>,
<&scmi_clk CK_SCMI_FLEXGEN_61>,
<&scmi_clk CK_SCMI_FLEXGEN_62>,
<&scmi_clk CK_SCMI_FLEXGEN_63>,
<&scmi_clk CK_SCMI_ICN_APB1>,
<&scmi_clk CK_SCMI_ICN_APB2>,
<&scmi_clk CK_SCMI_ICN_APB3>,
<&scmi_clk CK_SCMI_ICN_APB4>,
<&scmi_clk CK_SCMI_ICN_APBDBG>,
<&scmi_clk CK_SCMI_TIMG1>,
<&scmi_clk CK_SCMI_TIMG2>,
<&scmi_clk CK_SCMI_PLL3>,
<&clk_dsi_txbyte>;
};
...
Documentation/devicetree/bindings/display/atmel,lcdc-display.yaml
+103
View File
@@ -0,0 +1,103 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/atmel,lcdc-display.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip's LCDC Display
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Dharma Balasubiramani <dharma.b@microchip.com>
description:
The LCD Controller (LCDC) consists of logic for transferring LCD image data
from an external display buffer to a TFT LCD panel. The LCDC has one display
input buffer per layer that fetches pixels through the single bus host
interface and a look-up table to allow palletized display configurations. The
LCDC is programmable on a per layer basis, and supports different LCD
resolutions, window sizes, image formats and pixel depths.
# We need a select here since this schema is applicable only for nodes with the
# following properties
select:
anyOf:
- required: [ 'atmel,dmacon' ]
- required: [ 'atmel,lcdcon2' ]
- required: [ 'atmel,guard-time' ]
properties:
atmel,dmacon:
$ref: /schemas/types.yaml#/definitions/uint32
description: dma controller configuration
atmel,lcdcon2:
$ref: /schemas/types.yaml#/definitions/uint32
description: lcd controller configuration
atmel,guard-time:
$ref: /schemas/types.yaml#/definitions/uint32
description: lcd guard time (Delay in frame periods)
maximum: 127
bits-per-pixel:
$ref: /schemas/types.yaml#/definitions/uint32
description: lcd panel bit-depth.
enum: [1, 2, 4, 8, 16, 24, 32]
atmel,lcdcon-backlight:
$ref: /schemas/types.yaml#/definitions/flag
description: enable backlight
atmel,lcdcon-backlight-inverted:
$ref: /schemas/types.yaml#/definitions/flag
description: invert backlight PWM polarity
atmel,lcd-wiring-mode:
$ref: /schemas/types.yaml#/definitions/string
description: lcd wiring mode "RGB" or "BRG"
enum:
- RGB
- BRG
atmel,power-control-gpio:
description: gpio to power on or off the LCD (as many as needed)
maxItems: 1
display-timings:
$ref: panel/display-timings.yaml#
required:
- atmel,dmacon
- atmel,lcdcon2
- atmel,guard-time
- bits-per-pixel
additionalProperties: false
examples:
- |
display: panel {
bits-per-pixel = <32>;
atmel,lcdcon-backlight;
atmel,dmacon = <0x1>;
atmel,lcdcon2 = <0x80008002>;
atmel,guard-time = <9>;
atmel,lcd-wiring-mode = "RGB";
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <9000000>;
hactive = <480>;
vactive = <272>;
hback-porch = <1>;
hfront-porch = <1>;
vback-porch = <40>;
vfront-porch = <1>;
hsync-len = <45>;
vsync-len = <1>;
};
};
};
Documentation/devicetree/bindings/display/atmel,lcdc.txt
-87
View File
@@ -1,87 +0,0 @@
Atmel LCDC Framebuffer
-----------------------------------------------------
Required properties:
- compatible :
"atmel,at91sam9261-lcdc" ,
"atmel,at91sam9263-lcdc" ,
"atmel,at91sam9g10-lcdc" ,
"atmel,at91sam9g45-lcdc" ,
"atmel,at91sam9g45es-lcdc" ,
"atmel,at91sam9rl-lcdc" ,
- reg : Should contain 1 register ranges(address and length).
Can contain an additional register range(address and length)
for fixed framebuffer memory. Useful for dedicated memories.
- interrupts : framebuffer controller interrupt
- display: a phandle pointing to the display node
Required nodes:
- display: a display node is required to initialize the lcd panel
This should be in the board dts.
- default-mode: a videomode within the display with timing parameters
as specified below.
Optional properties:
- lcd-supply: Regulator for LCD supply voltage.
Example:
fb0: fb@00500000 {
compatible = "atmel,at91sam9g45-lcdc";
reg = <0x00500000 0x1000>;
interrupts = <23 3 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fb>;
display = <&display0>;
#address-cells = <1>;
#size-cells = <1>;
};
Example for fixed framebuffer memory:
fb0: fb@00500000 {
compatible = "atmel,at91sam9263-lcdc";
reg = <0x00700000 0x1000 0x70000000 0x200000>;
[...]
};
Atmel LCDC Display
-----------------------------------------------------
Required properties (as per of_videomode_helper):
- atmel,dmacon: dma controller configuration
- atmel,lcdcon2: lcd controller configuration
- atmel,guard-time: lcd guard time (Delay in frame periods)
- bits-per-pixel: lcd panel bit-depth.
Optional properties (as per of_videomode_helper):
- atmel,lcdcon-backlight: enable backlight
- atmel,lcdcon-backlight-inverted: invert backlight PWM polarity
- atmel,lcd-wiring-mode: lcd wiring mode "RGB" or "BRG"
- atmel,power-control-gpio: gpio to power on or off the LCD (as many as needed)
Example:
display0: display {
bits-per-pixel = <32>;
atmel,lcdcon-backlight;
atmel,dmacon = <0x1>;
atmel,lcdcon2 = <0x80008002>;
atmel,guard-time = <9>;
atmel,lcd-wiring-mode = <1>;
display-timings {
native-mode = <&timing0>;
timing0: timing0 {
clock-frequency = <9000000>;
hactive = <480>;
vactive = <272>;
hback-porch = <1>;
hfront-porch = <1>;
vback-porch = <40>;
vfront-porch = <1>;
hsync-len = <45>;
vsync-len = <1>;
};
};
};
Documentation/devicetree/bindings/display/atmel,lcdc.yaml
+70
View File
@@ -0,0 +1,70 @@
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/atmel,lcdc.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip's LCDC Framebuffer
maintainers:
- Nicolas Ferre <nicolas.ferre@microchip.com>
- Dharma Balasubiramani <dharma.b@microchip.com>
description:
The LCDC works with a framebuffer, which is a section of memory that contains
a complete frame of data representing pixel values for the display. The LCDC
reads the pixel data from the framebuffer and sends it to the LCD panel to
render the image.
properties:
compatible:
enum:
- atmel,at91sam9261-lcdc
- atmel,at91sam9263-lcdc
- atmel,at91sam9g10-lcdc
- atmel,at91sam9g45-lcdc
- atmel,at91sam9g45es-lcdc
- atmel,at91sam9rl-lcdc
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
maxItems: 2
clock-names:
items:
- const: hclk
- const: lcdc_clk
display:
$ref: /schemas/types.yaml#/definitions/phandle
description: A phandle pointing to the display node.
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
- display
additionalProperties: false
examples:
- |
#include <dt-bindings/clock/at91.h>
#include <dt-bindings/interrupt-controller/irq.h>
fb@500000 {
compatible = "atmel,at91sam9g45-lcdc";
reg = <0x00500000 0x1000>;
interrupts = <23 IRQ_TYPE_LEVEL_HIGH 0>;
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_fb>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 23>, <&pmc PMC_TYPE_PERIPHERAL 23>;
clock-names = "hclk", "lcdc_clk";
display = <&display>;
};
Documentation/devicetree/bindings/display/bridge/ite,it6505.yaml
+7 -1
View File
@@ -9,6 +9,9 @@ title: ITE it6505
maintainers:
- Allen Chen <allen.chen@ite.com.tw>
allOf:
- $ref: /schemas/sound/dai-common.yaml#
description: |
The IT6505 is a high-performance DisplayPort 1.1a transmitter,
fully compliant with DisplayPort 1.1a, HDCP 1.3 specifications.
@@ -52,6 +55,9 @@ properties:
maxItems: 1
description: extcon specifier for the Power Delivery
"#sound-dai-cells":
const: 0
ports:
$ref: /schemas/graph.yaml#/properties/ports
@@ -105,7 +111,7 @@ required:
- extcon
- ports
additionalProperties: false
unevaluatedProperties: false
examples:
- |
Documentation/devicetree/bindings/display/bridge/lvds-codec.yaml
+1
View File
@@ -41,6 +41,7 @@ properties:
- enum:
- ti,ds90cf364a # For the DS90CF364A FPD-Link LVDS Receiver
- ti,ds90cf384a # For the DS90CF384A FPD-Link LVDS Receiver
- ti,sn65lvds94 # For the SN65DS94 LVDS serdes
- const: lvds-decoder # Generic LVDS decoders compatible fallback
- enum:
- thine,thc63lvdm83d # For the THC63LVDM83D LVDS serializer
Documentation/devicetree/bindings/display/bridge/microchip,sam9x75-lvds.yaml
+55
View File
@@ -0,0 +1,55 @@
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
%YAML 1.2
---
$id: http://devicetree.org/schemas/display/bridge/microchip,sam9x75-lvds.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
title: Microchip SAM9X75 LVDS Controller
maintainers:
- Dharma Balasubiramani <dharma.b@microchip.com>
description:
The Low Voltage Differential Signaling Controller (LVDSC) manages data
format conversion from the LCD Controller internal DPI bus to OpenLDI
LVDS output signals. LVDSC functions include bit mapping, balanced mode
management, and serializer.
properties:
compatible:
const: microchip,sam9x75-lvds
reg:
maxItems: 1
interrupts:
maxItems: 1
clocks:
items:
- description: Peripheral Bus Clock
clock-names:
items:
- const: pclk
required:
- compatible
- reg
- interrupts
- clocks
- clock-names
additionalProperties: false
examples:
- |
#include <dt-bindings/interrupt-controller/irq.h>
#include <dt-bindings/clock/at91.h>
lvds-controller@f8060000 {
compatible = "microchip,sam9x75-lvds";
reg = <0xf8060000 0x100>;
interrupts = <56 IRQ_TYPE_LEVEL_HIGH 0>;
clocks = <&pmc PMC_TYPE_PERIPHERAL 56>;
clock-names = "pclk";
};
Documentation/devicetree/bindings/display/bridge/toshiba,tc358775.yaml
+33 -6
View File
@@ -10,7 +10,7 @@ maintainers:
- Vinay Simha BN <simhavcs@gmail.com>
description: |
This binding supports DSI to LVDS bridge TC358775
This binding supports DSI to LVDS bridges TC358765 and TC358775
MIPI DSI-RX Data 4-lane, CLK 1-lane with data rates up to 800 Mbps/lane.
Video frame size:
@@ -21,7 +21,9 @@ description: |
properties:
compatible:
const: toshiba,tc358775
enum:
- toshiba,tc358765
- toshiba,tc358775
reg:
maxItems: 1
@@ -46,11 +48,27 @@ properties:
properties:
port@0:
$ref: /schemas/graph.yaml#/properties/port
$ref: /schemas/graph.yaml#/$defs/port-base
unevaluatedProperties: false
description: |
DSI Input. The remote endpoint phandle should be a
reference to a valid mipi_dsi_host device node.
properties:
endpoint:
$ref: /schemas/media/video-interfaces.yaml#
unevaluatedProperties: false
properties:
data-lanes:
description: array of physical DSI data lane indexes.
minItems: 1
items:
- const: 1
- const: 2
- const: 3
- const: 4
port@1:
$ref: /schemas/graph.yaml#/properties/port
description: |
@@ -70,10 +88,19 @@ required:
- reg
- vdd-supply
- vddio-supply
- stby-gpios
- reset-gpios
- ports
allOf:
- if:
properties:
compatible:
contains:
const: toshiba,tc358765
then:
properties:
stby-gpios: false
additionalProperties: false
examples:
@@ -108,6 +135,7 @@ examples:
reg = <0>;
d2l_in_test: endpoint {
remote-endpoint = <&dsi0_out>;
data-lanes = <1 2 3 4>;
};
};
@@ -132,7 +160,6 @@ examples:
reg = <1>;
dsi0_out: endpoint {
remote-endpoint = <&d2l_in_test>;
data-lanes = <0 1 2 3>;
};
};
};
@@ -167,6 +194,7 @@ examples:
reg = <0>;
d2l_in_dual: endpoint {
remote-endpoint = <&dsi0_out_dual>;
data-lanes = <1 2 3 4>;
};
};
@@ -198,7 +226,6 @@ examples:
reg = <1>;
dsi0_out_dual: endpoint {
remote-endpoint = <&d2l_in_dual>;
data-lanes = <0 1 2 3>;
};
};
};
Documentation/devicetree/bindings/display/exynos/exynos_dp.txt
-112
View File
@@ -1,112 +0,0 @@
The Exynos display port interface should be configured based on
the type of panel connected to it.
We use two nodes:
-dp-controller node
-dptx-phy node(defined inside dp-controller node)
For the DP-PHY initialization, we use the dptx-phy node.
Required properties for dptx-phy: deprecated, use phys and phy-names
-reg: deprecated
Base address of DP PHY register.
-samsung,enable-mask: deprecated
The bit-mask used to enable/disable DP PHY.
For the Panel initialization, we read data from dp-controller node.
Required properties for dp-controller:
-compatible:
should be "samsung,exynos5-dp".
-reg:
physical base address of the controller and length
of memory mapped region.
-interrupts:
interrupt combiner values.
-clocks:
from common clock binding: handle to dp clock.
-clock-names:
from common clock binding: Shall be "dp".
-phys:
from general PHY binding: the phandle for the PHY device.
-phy-names:
from general PHY binding: Should be "dp".
Optional properties for dp-controller:
-interlaced:
interlace scan mode.
Progressive if defined, Interlaced if not defined
-vsync-active-high:
VSYNC polarity configuration.
High if defined, Low if not defined
-hsync-active-high:
HSYNC polarity configuration.
High if defined, Low if not defined
-samsung,hpd-gpio:
Hotplug detect GPIO.
Indicates which GPIO should be used for hotplug
detection
-video interfaces: Device node can contain video interface port
nodes according to [1].
- display-timings: timings for the connected panel as described by
Documentation/devicetree/bindings/display/panel/display-timing.txt
For the below properties, please refer to Analogix DP binding document:
* Documentation/devicetree/bindings/display/bridge/analogix,dp.yaml
-phys (required)
-phy-names (required)
-hpd-gpios (optional)
force-hpd (optional)
Deprecated properties for DisplayPort:
-interlaced: deprecated prop that can parsed from drm_display_mode.
-vsync-active-high: deprecated prop that can parsed from drm_display_mode.
-hsync-active-high: deprecated prop that can parsed from drm_display_mode.
-samsung,ycbcr-coeff: deprecated prop that can parsed from drm_display_mode.
-samsung,dynamic-range: deprecated prop that can parsed from drm_display_mode.
-samsung,color-space: deprecated prop that can parsed from drm_display_info.
-samsung,color-depth: deprecated prop that can parsed from drm_display_info.
-samsung,link-rate: deprecated prop that can reading from monitor by dpcd method.
-samsung,lane-count: deprecated prop that can reading from monitor by dpcd method.
-samsung,hpd-gpio: deprecated name for hpd-gpios.
-------------------------------------------------------------------------------
Example:
SOC specific portion:
dp-controller {
compatible = "samsung,exynos5-dp";
reg = <0x145b0000 0x10000>;
interrupts = <10 3>;
interrupt-parent = <&combiner>;
clocks = <&clock 342>;
clock-names = "dp";
phys = <&dp_phy>;
phy-names = "dp";
};
Board Specific portion:
dp-controller {
display-timings {
native-mode = <&lcd_timing>;
lcd_timing: 1366x768 {
clock-frequency = <70589280>;
hactive = <1366>;
vactive = <768>;
hfront-porch = <40>;
hback-porch = <40>;
hsync-len = <32>;
vback-porch = <10>;
vfront-porch = <12>;
vsync-len = <6>;
};
};
ports {
port@0 {
dp_out: endpoint {
remote-endpoint = <&bridge_in>;
};
};
};
};
Documentation/devicetree/bindings/display/mediatek/mediatek,gamma.yaml
+5
View File
@@ -24,6 +24,7 @@ properties:
- enum:
- mediatek,mt8173-disp-gamma
- mediatek,mt8183-disp-gamma
- mediatek,mt8195-disp-gamma
- items:
- enum:
- mediatek,mt6795-disp-gamma
@@ -35,6 +36,10 @@ properties:
- mediatek,mt8192-disp-gamma
- mediatek,mt8195-disp-gamma
- const: mediatek,mt8183-disp-gamma
- items:
- enum:
- mediatek,mt8188-disp-gamma
- const: mediatek,mt8195-disp-gamma
reg:
maxItems: 1
Documentation/devicetree/bindings/display/msm/dp-controller.yaml
+1
View File
@@ -29,6 +29,7 @@ properties:
- qcom,sm8650-dp
- items:
- enum:
- qcom,sm6350-dp
- qcom,sm8150-dp
- qcom,sm8250-dp
- qcom,sm8450-dp
Documentation/devicetree/bindings/display/msm/qcom,sm6350-mdss.yaml
+9
View File
@@ -53,6 +53,15 @@ patternProperties:
compatible:
const: qcom,sm6350-dpu
"^displayport-controller@[0-9a-f]+$":
type: object
additionalProperties: true
properties:
compatible:
contains:
const: qcom,sm6350-dp
"^dsi@[0-9a-f]+$":
type: object
additionalProperties: true
Documentation/devicetree/bindings/display/panel/abt,y030xx067a.yaml
+3 -1
View File
@@ -17,10 +17,12 @@ properties:
compatible:
const: abt,y030xx067a
reg:
maxItems: 1
backlight: true
port: true
power-supply: true
reg: true
reset-gpios: true
required:
Documentation/devicetree/bindings/display/panel/asus,z00t-tm5p5-nt35596.yaml
+4 -1
View File
@@ -21,7 +21,10 @@ allOf:
properties:
compatible:
const: asus,z00t-tm5p5-n35596
reg: true
reg:
maxItems: 1
reset-gpios: true
vdd-supply:
description: core voltage supply
Documentation/devicetree/bindings/display/panel/boe,bf060y8m-aj0.yaml
+3 -1
View File
@@ -26,6 +26,9 @@ properties:
compatible:
const: boe,bf060y8m-aj0
reg:
maxItems: 1
elvdd-supply:
description: EL Driving positive (VDD) supply (4.40-4.80V)
elvss-supply:
@@ -38,7 +41,6 @@ properties:
description: I/O voltage supply (1.62-1.98V)
port: true
reg: true
reset-gpios: true
required:
Documentation/devicetree/bindings/display/panel/boe,himax8279d.yaml
+3 -1
View File
@@ -18,9 +18,11 @@ properties:
- const: boe,himax8279d8p
- const: boe,himax8279d10p
reg:
maxItems: 1
backlight: true
enable-gpios: true
reg: true
pp33-gpios:
maxItems: 1
Documentation/devicetree/bindings/display/panel/boe,th101mb31ig002-28a.yaml
+3 -1
View File
@@ -18,7 +18,9 @@ properties:
# BOE TH101MB31IG002-28A 10.1" WXGA TFT LCD panel
- boe,th101mb31ig002-28a
reg: true
reg:
maxItems: 1
backlight: true
enable-gpios: true
power-supply: true
Documentation/devicetree/bindings/display/panel/boe,tv101wum-nl6.yaml
+1 -1
View File
@@ -38,7 +38,7 @@ properties:
- starry,ili9882t
reg:
description: the virtual channel number of a DSI peripheral
maxItems: 1
enable-gpios:
description: a GPIO spec for the enable pin
Documentation/devicetree/bindings/display/panel/elida,kd35t133.yaml
+4 -1
View File
@@ -15,7 +15,10 @@ allOf:
properties:
compatible:
const: elida,kd35t133
reg: true
reg:
maxItems: 1
backlight: true
port: true
reset-gpios: true
Documentation/devicetree/bindings/display/panel/fascontek,fs035vg158.yaml
+3
View File
@@ -17,6 +17,9 @@ properties:
compatible:
const: fascontek,fs035vg158
reg:
maxItems: 1
spi-3wire: true
required:
Documentation/devicetree/bindings/display/panel/feixin,k101-im2ba02.yaml
+4 -1
View File
@@ -15,7 +15,10 @@ allOf:
properties:
compatible:
const: feixin,k101-im2ba02
reg: true
reg:
maxItems: 1
backlight: true
reset-gpios: true
avdd-supply:
Documentation/devicetree/bindings/display/panel/himax,hx83112a.yaml
+3 -1
View File
@@ -21,6 +21,9 @@ properties:
contains:
const: djn,9a-3r063-1102b
reg:
maxItems: 1
vdd1-supply:
description: Digital voltage rail
@@ -30,7 +33,6 @@ properties:
vsp-supply:
description: Negative source voltage rail
reg: true
port: true
required:
Documentation/devicetree/bindings/display/panel/himax,hx8394.yaml
+2 -1
View File
@@ -26,7 +26,8 @@ properties:
- powkiddy,x55-panel
- const: himax,hx8394
reg: true
reg:
maxItems: 1
reset-gpios: true
Loaded 100 of 8598 files, more files were not shown because too many files have changed in this diff. Show more