mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
synced 2025-01-17 02:15:57 +00:00
Merge drm/drm-next into drm-misc-next
Let's start the new release cycle. Signed-off-by: Maxime Ripard <mripard@kernel.org>
This commit is contained in:
Maxime Ripard
commit
375c4d1583
13
.mailmap
13
.mailmap
@ -97,6 +97,11 @@ Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@linaro.org>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@spreadtrum.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang@unisoc.com>
|
||||
Baolin Wang <baolin.wang@linux.alibaba.com> <baolin.wang7@gmail.com>
|
||||
Barry Song <baohua@kernel.org> <21cnbao@gmail.com>
|
||||
Barry Song <baohua@kernel.org> <v-songbaohua@oppo.com>
|
||||
Barry Song <baohua@kernel.org> <song.bao.hua@hisilicon.com>
|
||||
Barry Song <baohua@kernel.org> <Baohua.Song@csr.com>
|
||||
Barry Song <baohua@kernel.org> <barry.song@analog.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@sandisk.com>
|
||||
Bart Van Assche <bvanassche@acm.org> <bart.vanassche@wdc.com>
|
||||
Bartosz Golaszewski <brgl@bgdev.pl> <bgolaszewski@baylibre.com>
|
||||
@ -128,6 +133,7 @@ Bryan Tan <bryan-bt.tan@broadcom.com> <bryantan@vmware.com>
|
||||
Cai Huoqing <cai.huoqing@linux.dev> <caihuoqing@baidu.com>
|
||||
Can Guo <quic_cang@quicinc.com> <cang@codeaurora.org>
|
||||
Carl Huang <quic_cjhuang@quicinc.com> <cjhuang@codeaurora.org>
|
||||
Carlos Bilbao <carlos.bilbao.osdev@gmail.com> <carlos.bilbao@amd.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
@ -304,6 +310,7 @@ Johan Hovold <johan@kernel.org> <jhovold@gmail.com>
|
||||
Johan Hovold <johan@kernel.org> <johan@hovoldconsulting.com>
|
||||
John Crispin <john@phrozen.org> <blogic@openwrt.org>
|
||||
John Fastabend <john.fastabend@gmail.com> <john.r.fastabend@intel.com>
|
||||
John Garry <john.g.garry@oracle.com> <john.garry@huawei.com>
|
||||
John Keeping <john@keeping.me.uk> <john@metanate.com>
|
||||
John Moon <john@jmoon.dev> <quic_johmoo@quicinc.com>
|
||||
John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
|
||||
@ -461,7 +468,8 @@ Nadia Yvette Chambers <nyc@holomorphy.com> William Lee Irwin III <wli@holomorphy
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <n-horiguchi@ah.jp.nec.com>
|
||||
Naoya Horiguchi <nao.horiguchi@gmail.com> <naoya.horiguchi@nec.com>
|
||||
Nathan Chancellor <nathan@kernel.org> <natechancellor@gmail.com>
|
||||
Neeraj Upadhyay <quic_neeraju@quicinc.com> <neeraju@codeaurora.org>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <quic_neeraju@quicinc.com>
|
||||
Neeraj Upadhyay <neeraj.upadhyay@kernel.org> <neeraju@codeaurora.org>
|
||||
Neil Armstrong <neil.armstrong@linaro.org> <narmstrong@baylibre.com>
|
||||
Nguyen Anh Quynh <aquynh@gmail.com>
|
||||
Nicholas Piggin <npiggin@gmail.com> <npiggen@suse.de>
|
||||
@ -512,6 +520,7 @@ Praveen BP <praveenbp@ti.com>
|
||||
Pradeep Kumar Chitrapu <quic_pradeepc@quicinc.com> <pradeepc@codeaurora.org>
|
||||
Prasad Sodagudi <quic_psodagud@quicinc.com> <psodagud@codeaurora.org>
|
||||
Punit Agrawal <punitagrawal@gmail.com> <punit.agrawal@arm.com>
|
||||
Puranjay Mohan <puranjay@kernel.org> <puranjay12@gmail.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@imgtec.com>
|
||||
Qais Yousef <qyousef@layalina.io> <qais.yousef@arm.com>
|
||||
Quentin Monnet <qmo@kernel.org> <quentin.monnet@netronome.com>
|
||||
@ -563,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>
|
||||
|
||||
12
Documentation/ABI/removed/sysfs-firmware-efi-vars
Normal file
12
Documentation/ABI/removed/sysfs-firmware-efi-vars
Normal file
@ -0,0 +1,12 @@
|
||||
What: /sys/firmware/efi/vars
|
||||
Date: April 2004, removed March 2023
|
||||
Description:
|
||||
This directory exposed interfaces for interacting with
|
||||
EFI variables. For more information on EFI variables,
|
||||
see 'Variable Services' in the UEFI specification
|
||||
(section 7.2 in specification version 2.3 Errata D).
|
||||
|
||||
The 'efivars' sysfs interface was removed in March of 2023,
|
||||
after being considered deprecated no later than September
|
||||
of 2020. Its functionality has been replaced by the
|
||||
'efivarfs' filesystem.
|
||||
@ -101,6 +101,16 @@ Description:
|
||||
devices that support receiving integrity metadata.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/partscan
|
||||
Date: May 2024
|
||||
Contact: Christoph Hellwig <hch@lst.de>
|
||||
Description:
|
||||
The /sys/block/<disk>/partscan files reports if partition
|
||||
scanning is enabled for the disk. It returns "1" if partition
|
||||
scanning is enabled, or "0" if not. The value type is a 32-bit
|
||||
unsigned integer, but only "0" and "1" are valid values.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/<partition>/alignment_offset
|
||||
Date: April 2009
|
||||
Contact: Martin K. Petersen <martin.petersen@oracle.com>
|
||||
@ -584,18 +594,6 @@ Description:
|
||||
the data. If no such restriction exists, this file will contain
|
||||
'0'. This file is writable for testing purposes.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/throttle_sample_time
|
||||
Date: March 2017
|
||||
Contact: linux-block@vger.kernel.org
|
||||
Description:
|
||||
[RW] This is the time window that blk-throttle samples data, in
|
||||
millisecond. blk-throttle makes decision based on the
|
||||
samplings. Lower time means cgroups have more smooth throughput,
|
||||
but higher CPU overhead. This exists only when
|
||||
CONFIG_BLK_DEV_THROTTLING_LOW is enabled.
|
||||
|
||||
|
||||
What: /sys/block/<disk>/queue/virt_boundary_mask
|
||||
Date: April 2021
|
||||
Contact: linux-block@vger.kernel.org
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -1,79 +0,0 @@
|
||||
What: /sys/firmware/efi/vars
|
||||
Date: April 2004
|
||||
Contact: Matt Domsch <Matt_Domsch@dell.com>
|
||||
Description:
|
||||
This directory exposes interfaces for interactive with
|
||||
EFI variables. For more information on EFI variables,
|
||||
see 'Variable Services' in the UEFI specification
|
||||
(section 7.2 in specification version 2.3 Errata D).
|
||||
|
||||
In summary, EFI variables are named, and are classified
|
||||
into separate namespaces through the use of a vendor
|
||||
GUID. They also have an arbitrary binary value
|
||||
associated with them.
|
||||
|
||||
The efivars module enumerates these variables and
|
||||
creates a separate directory for each one found. Each
|
||||
directory has a name of the form "<key>-<vendor guid>"
|
||||
and contains the following files:
|
||||
|
||||
=============== ========================================
|
||||
attributes: A read-only text file enumerating the
|
||||
EFI variable flags. Potential values
|
||||
include:
|
||||
|
||||
EFI_VARIABLE_NON_VOLATILE
|
||||
EFI_VARIABLE_BOOTSERVICE_ACCESS
|
||||
EFI_VARIABLE_RUNTIME_ACCESS
|
||||
EFI_VARIABLE_HARDWARE_ERROR_RECORD
|
||||
EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
|
||||
|
||||
See the EFI documentation for an
|
||||
explanation of each of these variables.
|
||||
|
||||
data: A read-only binary file that can be read
|
||||
to attain the value of the EFI variable
|
||||
|
||||
guid: The vendor GUID of the variable. This
|
||||
should always match the GUID in the
|
||||
variable's name.
|
||||
|
||||
raw_var: A binary file that can be read to obtain
|
||||
a structure that contains everything
|
||||
there is to know about the variable.
|
||||
For structure definition see "struct
|
||||
efi_variable" in the kernel sources.
|
||||
|
||||
This file can also be written to in
|
||||
order to update the value of a variable.
|
||||
For this to work however, all fields of
|
||||
the "struct efi_variable" passed must
|
||||
match byte for byte with the structure
|
||||
read out of the file, save for the value
|
||||
portion.
|
||||
|
||||
**Note** the efi_variable structure
|
||||
read/written with this file contains a
|
||||
'long' type that may change widths
|
||||
depending on your underlying
|
||||
architecture.
|
||||
|
||||
size: As ASCII representation of the size of
|
||||
the variable's value.
|
||||
=============== ========================================
|
||||
|
||||
|
||||
In addition, two other magic binary files are provided
|
||||
in the top-level directory and are used for adding and
|
||||
removing variables:
|
||||
|
||||
=============== ========================================
|
||||
new_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to create a
|
||||
new variable.
|
||||
|
||||
del_var: Takes a "struct efi_variable" and
|
||||
instructs the EFI firmware to remove any
|
||||
variable that has a matching vendor GUID
|
||||
and variable key name.
|
||||
=============== ========================================
|
||||
14
Documentation/ABI/testing/debugfs-msi-wmi-platform
Normal file
14
Documentation/ABI/testing/debugfs-msi-wmi-platform
Normal 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.
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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>]]...
|
||||
|
||||
@ -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>
|
||||
@ -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:
|
||||
|
||||
19
Documentation/ABI/testing/sysfs-bus-iio-ad9739a
Normal file
19
Documentation/ABI/testing/sysfs-bus-iio-ad9739a
Normal 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.
|
||||
@ -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.
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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>
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
@ -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
|
||||
|
||||
@ -28,6 +28,10 @@ BUILDDIR = $(obj)/output
|
||||
PDFLATEX = xelatex
|
||||
LATEXOPTS = -interaction=batchmode -no-shell-escape
|
||||
|
||||
# For denylisting "variable font" files
|
||||
# Can be overridden by setting as an env variable
|
||||
FONTS_CONF_DENY_VF ?= $(HOME)/deny-vf
|
||||
|
||||
ifeq ($(findstring 1, $(KBUILD_VERBOSE)),)
|
||||
SPHINXOPTS += "-q"
|
||||
endif
|
||||
@ -76,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/; \
|
||||
@ -151,10 +155,11 @@ pdfdocs:
|
||||
|
||||
else # HAVE_PDFLATEX
|
||||
|
||||
pdfdocs: DENY_VF = XDG_CONFIG_HOME=$(FONTS_CONF_DENY_VF)
|
||||
pdfdocs: latexdocs
|
||||
@$(srctree)/scripts/sphinx-pre-install --version-check
|
||||
$(foreach var,$(SPHINXDIRS), \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" -C $(BUILDDIR)/$(var)/latex || exit; \
|
||||
$(MAKE) PDFLATEX="$(PDFLATEX)" LATEXOPTS="$(LATEXOPTS)" $(DENY_VF) -C $(BUILDDIR)/$(var)/latex || sh $(srctree)/scripts/check-variable-fonts.sh || exit; \
|
||||
mkdir -p $(BUILDDIR)/$(var)/pdf; \
|
||||
mv $(subst .tex,.pdf,$(wildcard $(BUILDDIR)/$(var)/latex/*.tex)) $(BUILDDIR)/$(var)/pdf/; \
|
||||
)
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -427,7 +427,7 @@ their assorted primitives.
|
||||
|
||||
This section shows a simple use of the core RCU API to protect a
|
||||
global pointer to a dynamically allocated structure. More-typical
|
||||
uses of RCU may be found in listRCU.rst, arrayRCU.rst, and NMI-RCU.rst.
|
||||
uses of RCU may be found in listRCU.rst and NMI-RCU.rst.
|
||||
::
|
||||
|
||||
struct foo {
|
||||
@ -510,8 +510,8 @@ So, to sum up:
|
||||
data item.
|
||||
|
||||
See checklist.rst for additional rules to follow when using RCU.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst,
|
||||
arrayRCU.rst, and NMI-RCU.rst.
|
||||
And again, more-typical uses of RCU may be found in listRCU.rst
|
||||
and NMI-RCU.rst.
|
||||
|
||||
.. _4_whatisRCU:
|
||||
|
||||
|
||||
@ -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,
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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. |
|
||||
+---+--------------------------------------------------------------------------+
|
||||
|
||||
|
||||
@ -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
|
||||
@ -1572,6 +1575,15 @@ PAGE_SIZE multiple when read back.
|
||||
pglazyfreed (npn)
|
||||
Amount of reclaimed lazyfree pages
|
||||
|
||||
zswpin
|
||||
Number of pages moved in to memory from zswap.
|
||||
|
||||
zswpout
|
||||
Number of pages moved out of memory to zswap.
|
||||
|
||||
zswpwb
|
||||
Number of pages written from zswap to swap.
|
||||
|
||||
thp_fault_alloc (npn)
|
||||
Number of transparent hugepages which were allocated to satisfy
|
||||
a page fault. This counter is not present when CONFIG_TRANSPARENT_HUGEPAGE
|
||||
@ -2181,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
|
||||
|
||||
@ -113,6 +113,11 @@ same_cpu_crypt
|
||||
The default is to use an unbound workqueue so that encryption work
|
||||
is automatically balanced between available CPUs.
|
||||
|
||||
high_priority
|
||||
Set dm-crypt workqueues and the writer thread to high priority. This
|
||||
improves throughput and latency of dm-crypt while degrading general
|
||||
responsiveness of the system.
|
||||
|
||||
submit_from_crypt_cpus
|
||||
Disable offloading writes to a separate thread after encryption.
|
||||
There are some situations where offloading write bios from the
|
||||
|
||||
@ -67,8 +67,8 @@ arg4:
|
||||
will be performed for all tasks in the task group of ``pid``.
|
||||
|
||||
arg5:
|
||||
userspace pointer to an unsigned long for storing the cookie returned by
|
||||
``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
userspace pointer to an unsigned long long for storing the cookie returned
|
||||
by ``PR_SCHED_CORE_GET`` command. Should be 0 for all other commands.
|
||||
|
||||
In order for a process to push a cookie to, or pull a cookie from a process, it
|
||||
is required to have the ptrace access mode: `PTRACE_MODE_READ_REALCREDS` to the
|
||||
|
||||
@ -135,7 +135,7 @@ and does not want to suffer the performance impact, one can always
|
||||
disable the mitigation with spec_rstack_overflow=off.
|
||||
|
||||
Similarly, 'Mitigation: IBPB' is another full mitigation type employing
|
||||
an indrect branch prediction barrier after having applied the required
|
||||
an indirect branch prediction barrier after having applied the required
|
||||
microcode patch for one's system. This mitigation comes also at
|
||||
a performance cost.
|
||||
|
||||
|
||||
@ -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
|
||||
|
||||
@ -431,6 +431,9 @@
|
||||
arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards
|
||||
Format: <io>,<irq>,<nodeID>
|
||||
|
||||
arm64.no32bit_el0 [ARM64] Unconditionally disable the execution of
|
||||
32 bit applications.
|
||||
|
||||
arm64.nobti [ARM64] Unconditionally disable Branch Target
|
||||
Identification support
|
||||
|
||||
@ -785,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]
|
||||
@ -2148,6 +2170,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
|
||||
@ -2251,6 +2279,8 @@
|
||||
no_x2apic_optout
|
||||
BIOS x2APIC opt-out request will be ignored
|
||||
nopost disable Interrupt Posting
|
||||
posted_msi
|
||||
enable MSIs delivered as posted interrupts
|
||||
|
||||
iomem= Disable strict checking of access to MMIO memory
|
||||
strict regions from userspace.
|
||||
@ -3776,10 +3806,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)
|
||||
@ -4173,13 +4205,11 @@
|
||||
|
||||
page_alloc.shuffle=
|
||||
[KNL] Boolean flag to control whether the page allocator
|
||||
should randomize its free lists. The randomization may
|
||||
be automatically enabled if the kernel detects it is
|
||||
running on a platform with a direct-mapped memory-side
|
||||
cache, and this parameter can be used to
|
||||
override/disable that behavior. The state of the flag
|
||||
can be read from sysfs at:
|
||||
should randomize its free lists. This parameter can be
|
||||
used to enable/disable page randomization. The state of
|
||||
the flag can be read from sysfs at:
|
||||
/sys/module/page_alloc/parameters/shuffle.
|
||||
This parameter is only available if CONFIG_SHUFFLE_PAGE_ALLOCATOR=y.
|
||||
|
||||
page_owner= [KNL,EARLY] Boot-time page_owner enabling option.
|
||||
Storage of the information about who allocated
|
||||
@ -4594,9 +4624,10 @@
|
||||
norid [S390] ignore the RID field and force use of
|
||||
one PCI domain per PCI function
|
||||
|
||||
pcie_aspm= [PCIE] Forcibly enable or disable PCIe Active State Power
|
||||
pcie_aspm= [PCIE] Forcibly enable or ignore PCIe Active State Power
|
||||
Management.
|
||||
off Disable ASPM.
|
||||
off Don't touch ASPM configuration at all. Leave any
|
||||
configuration done by firmware unchanged.
|
||||
force Enable ASPM even on devices that claim not to support it.
|
||||
WARNING: Forcing ASPM on may cause system lockups.
|
||||
|
||||
@ -4784,7 +4815,9 @@
|
||||
|
||||
prot_virt= [S390] enable hosting protected virtual machines
|
||||
isolated from the hypervisor (if hardware supports
|
||||
that).
|
||||
that). If enabled, the default kernel base address
|
||||
might be overridden even when Kernel Address Space
|
||||
Layout Randomization is disabled.
|
||||
Format: <bool>
|
||||
|
||||
psi= [KNL] Enable or disable pressure stall information
|
||||
@ -5095,6 +5128,20 @@
|
||||
delay, memory pressure or callback list growing too
|
||||
big.
|
||||
|
||||
rcutree.rcu_normal_wake_from_gp= [KNL]
|
||||
Reduces a latency of synchronize_rcu() call. This approach
|
||||
maintains its own track of synchronize_rcu() callers, so it
|
||||
does not interact with regular callbacks because it does not
|
||||
use a call_rcu[_hurry]() path. Please note, this is for a
|
||||
normal grace period.
|
||||
|
||||
How to enable it:
|
||||
|
||||
echo 1 > /sys/module/rcutree/parameters/rcu_normal_wake_from_gp
|
||||
or pass a boot parameter "rcutree.rcu_normal_wake_from_gp=1"
|
||||
|
||||
Default is 0.
|
||||
|
||||
rcuscale.gp_async= [KNL]
|
||||
Measure performance of asynchronous
|
||||
grace-period primitives such as call_rcu().
|
||||
@ -5811,6 +5858,7 @@
|
||||
but is useful for debugging and performance tuning.
|
||||
|
||||
sched_thermal_decay_shift=
|
||||
[Deprecated]
|
||||
[KNL, SMP] Set a decay shift for scheduler thermal
|
||||
pressure signal. Thermal pressure signal follows the
|
||||
default decay period of other scheduler pelt
|
||||
@ -6748,6 +6796,7 @@
|
||||
- "tpm"
|
||||
- "tee"
|
||||
- "caam"
|
||||
- "dcp"
|
||||
If not specified then it defaults to iterating through
|
||||
the trust source list starting with TPM and assigns the
|
||||
first trust source as a backend which is initialized
|
||||
@ -6763,6 +6812,18 @@
|
||||
If not specified, "default" is used. In this case,
|
||||
the RNG's choice is left to each individual trust source.
|
||||
|
||||
trusted.dcp_use_otp_key
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will select the DCP OTP key
|
||||
instead of the DCP UNIQUE key blob encryption.
|
||||
|
||||
trusted.dcp_skip_zk_test
|
||||
This is intended to be used in combination with
|
||||
trusted.source=dcp and will disable the check if the
|
||||
blob key is all zeros. This is helpful for situations where
|
||||
having this key zero'ed is acceptable. E.g. in testing
|
||||
scenarios.
|
||||
|
||||
tsc= Disable clocksource stability checks for TSC.
|
||||
Format: <string>
|
||||
[x86] reliable: mark tsc clocksource as reliable, this
|
||||
@ -7323,7 +7384,7 @@
|
||||
This can be changed after boot by writing to the
|
||||
matching /sys/module/workqueue/parameters file. All
|
||||
workqueues with the "default" affinity scope will be
|
||||
updated accordignly.
|
||||
updated accordingly.
|
||||
|
||||
workqueue.debug_force_rr_cpu
|
||||
Workqueue used to implicitly guarantee that work
|
||||
@ -7467,4 +7528,3 @@
|
||||
memory, and other data can't be written using
|
||||
xmon commands.
|
||||
off xmon is disabled.
|
||||
|
||||
|
||||
161
Documentation/admin-guide/media/ipu6-isys.rst
Normal file
161
Documentation/admin-guide/media/ipu6-isys.rst
Normal 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
|
||||
548
Documentation/admin-guide/media/ipu6_isys_graph.svg
Normal file
548
Documentation/admin-guide/media/ipu6_isys_graph.svg
Normal 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-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->n00000001 -->
|
||||
<g id="edge1" class="edge">
|
||||
<title>n00000081:port1->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->n00000005 -->
|
||||
<g id="edge2" class="edge">
|
||||
<title>n00000081:port2->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->n00000009 -->
|
||||
<g id="edge3" class="edge">
|
||||
<title>n00000081:port3->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->n0000000d -->
|
||||
<g id="edge4" class="edge">
|
||||
<title>n00000081:port4->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->n00000011 -->
|
||||
<g id="edge5" class="edge">
|
||||
<title>n00000081:port5->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->n00000015 -->
|
||||
<g id="edge6" class="edge">
|
||||
<title>n00000081:port6->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->n00000019 -->
|
||||
<g id="edge7" class="edge">
|
||||
<title>n00000081:port7->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->n0000001d -->
|
||||
<g id="edge8" class="edge">
|
||||
<title>n00000081:port8->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-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->n00000021 -->
|
||||
<g id="edge9" class="edge">
|
||||
<title>n0000008b:port1->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->n00000025 -->
|
||||
<g id="edge10" class="edge">
|
||||
<title>n0000008b:port2->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->n00000029 -->
|
||||
<g id="edge11" class="edge">
|
||||
<title>n0000008b:port3->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->n0000002d -->
|
||||
<g id="edge12" class="edge">
|
||||
<title>n0000008b:port4->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->n00000031 -->
|
||||
<g id="edge13" class="edge">
|
||||
<title>n0000008b:port5->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->n00000035 -->
|
||||
<g id="edge14" class="edge">
|
||||
<title>n0000008b:port6->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->n00000039 -->
|
||||
<g id="edge15" class="edge">
|
||||
<title>n0000008b:port7->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->n0000003d -->
|
||||
<g id="edge16" class="edge">
|
||||
<title>n0000008b:port8->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-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->n00000041 -->
|
||||
<g id="edge17" class="edge">
|
||||
<title>n00000095:port1->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->n00000045 -->
|
||||
<g id="edge18" class="edge">
|
||||
<title>n00000095:port2->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->n00000049 -->
|
||||
<g id="edge19" class="edge">
|
||||
<title>n00000095:port3->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->n0000004d -->
|
||||
<g id="edge20" class="edge">
|
||||
<title>n00000095:port4->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->n00000051 -->
|
||||
<g id="edge21" class="edge">
|
||||
<title>n00000095:port5->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->n00000055 -->
|
||||
<g id="edge22" class="edge">
|
||||
<title>n00000095:port6->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->n00000059 -->
|
||||
<g id="edge23" class="edge">
|
||||
<title>n00000095:port7->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->n0000005d -->
|
||||
<g id="edge24" class="edge">
|
||||
<title>n00000095:port8->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-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->n00000061 -->
|
||||
<g id="edge25" class="edge">
|
||||
<title>n0000009f:port1->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->n00000065 -->
|
||||
<g id="edge26" class="edge">
|
||||
<title>n0000009f:port2->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->n00000069 -->
|
||||
<g id="edge27" class="edge">
|
||||
<title>n0000009f:port3->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->n0000006d -->
|
||||
<g id="edge28" class="edge">
|
||||
<title>n0000009f:port4->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->n00000071 -->
|
||||
<g id="edge29" class="edge">
|
||||
<title>n0000009f:port5->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->n00000075 -->
|
||||
<g id="edge30" class="edge">
|
||||
<title>n0000009f:port6->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->n00000079 -->
|
||||
<g id="edge31" class="edge">
|
||||
<title>n0000009f:port7->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->n0000007d -->
|
||||
<g id="edge32" class="edge">
|
||||
<title>n0000009f:port8->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-0036</text>
|
||||
<text text-anchor="middle" x="455.15" y="-462.25" font-family="Times,serif" font-size="14.00">/dev/v4l-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->n0000008b -->
|
||||
<g id="edge33" class="edge">
|
||||
<title>n000000e9:port0->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>
|
||||
|
After Width: | Height: | Size: 38 KiB |
@ -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:
|
||||
|
||||
@ -16,6 +16,7 @@ Video4Linux (V4L) driver-specific documentation
|
||||
imx
|
||||
imx7
|
||||
ipu3
|
||||
ipu6-isys
|
||||
ivtv
|
||||
mgb4
|
||||
omap3isp
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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
|
||||
|
||||
@ -308,7 +308,7 @@ limited by the ``advisor_max_cpu`` parameter. In addition there is also the
|
||||
``advisor_target_scan_time`` parameter. This parameter sets the target time to
|
||||
scan all the KSM candidate pages. The parameter ``advisor_target_scan_time``
|
||||
decides how aggressive the scan time advisor scans candidate pages. Lower
|
||||
values make the scan time advisor to scan more aggresively. This is the most
|
||||
values make the scan time advisor to scan more aggressively. This is the most
|
||||
important parameter for the configuration of the scan time advisor.
|
||||
|
||||
The initial value and the maximum value can be changed with
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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
|
||||
|
||||
@ -20,7 +20,6 @@ interrupt, and the PMU driver shall register perf PMU drivers like L3C,
|
||||
HHA and DDRC etc. The available events and configuration options shall
|
||||
be described in the sysfs, see:
|
||||
|
||||
/sys/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>/, or
|
||||
/sys/bus/event_source/devices/hisi_sccl{X}_<l3c{Y}/hha{Y}/ddrc{Y}>.
|
||||
The "perf list" command shall list the available events from sysfs.
|
||||
|
||||
|
||||
@ -16,7 +16,7 @@ HNS3 PMU driver
|
||||
|
||||
The HNS3 PMU driver registers a perf PMU with the name of its sicl id.::
|
||||
|
||||
/sys/devices/hns3_pmu_sicl_<sicl_id>
|
||||
/sys/bus/event_source/devices/hns3_pmu_sicl_<sicl_id>
|
||||
|
||||
PMU driver provides description of available events, filter modes, format,
|
||||
identifier and cpumask in sysfs.
|
||||
@ -40,9 +40,9 @@ device.
|
||||
|
||||
Example usage of checking event code and subevent code::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_time
|
||||
config=0x00204
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/events/dly_tx_normal_to_mac_packet_num
|
||||
config=0x10204
|
||||
|
||||
Each performance statistic has a pair of events to get two values to
|
||||
@ -60,7 +60,7 @@ computation to calculate real performance data is:::
|
||||
|
||||
Example usage of checking supported filter mode::
|
||||
|
||||
$# cat /sys/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
|
||||
$# cat /sys/bus/event_source/devices/hns3_pmu_sicl_0/filtermode/bw_ssu_rpu_byte_num
|
||||
filter mode supported: global/port/port-tc/func/func-queue/
|
||||
|
||||
Example usage of perf::
|
||||
|
||||
@ -10,7 +10,7 @@ There is one logical L2 PMU exposed, which aggregates the results from
|
||||
the physical PMUs.
|
||||
|
||||
The driver provides a description of its available events and configuration
|
||||
options in sysfs, see /sys/devices/l2cache_0.
|
||||
options in sysfs, see /sys/bus/event_source/devices/l2cache_0.
|
||||
|
||||
The "format" directory describes the format of the events.
|
||||
|
||||
|
||||
@ -9,7 +9,7 @@ PMU with device name l3cache_<socket>_<instance>. User space is responsible
|
||||
for aggregating across slices.
|
||||
|
||||
The driver provides a description of its available events and configuration
|
||||
options in sysfs, see /sys/devices/l3cache*. Given that these are uncore PMUs
|
||||
options in sysfs, see /sys/bus/event_source/devices/l3cache*. Given that these are uncore PMUs
|
||||
the driver also exposes a "cpumask" sysfs attribute which contains a mask
|
||||
consisting of one CPU per socket which will be used to handle all the PMU
|
||||
events on that socket.
|
||||
|
||||
@ -22,7 +22,7 @@ The thunderx2_pmu driver registers per-socket perf PMUs for the DMC and
|
||||
L3C devices. Each PMU can be used to count up to 4 (DMC/L3C) or up to 8
|
||||
(CCPI2) events simultaneously. The PMUs provide a description of their
|
||||
available events and configuration options under sysfs, see
|
||||
/sys/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
|
||||
/sys/bus/event_source/devices/uncore_<l3c_S/dmc_S/ccpi2_S/>; S is the socket id.
|
||||
|
||||
The driver does not support sampling, therefore "perf record" will not
|
||||
work. Per-task perf sessions are also not supported.
|
||||
|
||||
@ -13,7 +13,7 @@ PMU (perf) driver
|
||||
|
||||
The xgene-pmu driver registers several perf PMU drivers. Each of the perf
|
||||
driver provides description of its available events and configuration options
|
||||
in sysfs, see /sys/devices/<l3cX/iobX/mcbX/mcX>/.
|
||||
in sysfs, see /sys/bus/event_source/devices/<l3cX/iobX/mcbX/mcX>/.
|
||||
|
||||
The "format" directory describes format of the config (event ID),
|
||||
config1 (agent ID) fields of the perf_event_attr structure. The "events"
|
||||
|
||||
@ -42,12 +42,12 @@ The important basics
|
||||
--------------------
|
||||
|
||||
|
||||
What is a "regression" and what is the "no regressions rule"?
|
||||
What is a "regression" and what is the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
It's a regression if some application or practical use case running fine with
|
||||
one Linux kernel works worse or not at all with a newer version compiled using a
|
||||
similar configuration. The "no regressions rule" forbids this to take place; if
|
||||
similar configuration. The "no regressions" rule forbids this to take place; if
|
||||
it happens by accident, developers that caused it are expected to quickly fix
|
||||
the issue.
|
||||
|
||||
@ -173,7 +173,7 @@ Additional details about regressions
|
||||
------------------------------------
|
||||
|
||||
|
||||
What is the goal of the "no regressions rule"?
|
||||
What is the goal of the "no regressions" rule?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
Users should feel safe when updating kernel versions and not have to worry
|
||||
@ -199,8 +199,8 @@ Exceptions to this rule are extremely rare; in the past developers almost always
|
||||
turned out to be wrong when they assumed a particular situation was warranting
|
||||
an exception.
|
||||
|
||||
Who ensures the "no regressions" is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
Who ensures the "no regressions" rule is actually followed?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
The subsystem maintainers should take care of that, which are watched and
|
||||
supported by the tree maintainers -- e.g. Linus Torvalds for mainline and
|
||||
|
||||
@ -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:
|
||||
|
||||
|
||||
@ -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:
|
||||
==========================
|
||||
|
||||
|
||||
@ -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?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
||||
@ -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 |
|
||||
|
||||
@ -173,7 +173,7 @@ When accessing IDE registers with A6=1 (for example $84x),
|
||||
the timing will always be mode 0 8-bit compatible, no matter
|
||||
what you have selected in the speed register:
|
||||
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) aktive.
|
||||
781ns select, IOR/IOW after 4 clock cycles (=314ns) active.
|
||||
|
||||
All the timings with a very short select-signal (the 355ns
|
||||
fast accesses) depend on the accelerator card used in the
|
||||
|
||||
@ -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
|
||||
|
||||
@ -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>
|
||||
|
||||
|
||||
98
Documentation/arch/riscv/cmodx.rst
Normal file
98
Documentation/arch/riscv/cmodx.rst
Normal 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
|
||||
@ -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.
|
||||
|
||||
|
||||
@ -13,6 +13,7 @@ RISC-V architecture
|
||||
patch-acceptance
|
||||
uabi
|
||||
vector
|
||||
cmodx
|
||||
|
||||
features
|
||||
|
||||
|
||||
@ -8,6 +8,7 @@ s390 Architecture
|
||||
cds
|
||||
3270
|
||||
driver-model
|
||||
mm
|
||||
monreader
|
||||
qeth
|
||||
s390dbf
|
||||
|
||||
111
Documentation/arch/s390/mm.rst
Normal file
111
Documentation/arch/s390/mm.rst
Normal file
@ -0,0 +1,111 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
=================
|
||||
Memory Management
|
||||
=================
|
||||
|
||||
Virtual memory layout
|
||||
=====================
|
||||
|
||||
.. note::
|
||||
|
||||
- Some aspects of the virtual memory layout setup are not
|
||||
clarified (number of page levels, alignment, DMA memory).
|
||||
|
||||
- Unused gaps in the virtual memory layout could be present
|
||||
or not - depending on how partucular system is configured.
|
||||
No page tables are created for the unused gaps.
|
||||
|
||||
- The virtual memory regions are tracked or untracked by KASAN
|
||||
instrumentation, as well as the KASAN shadow memory itself is
|
||||
created only when CONFIG_KASAN configuration option is enabled.
|
||||
|
||||
::
|
||||
|
||||
=============================================================================
|
||||
| Physical | Virtual | VM area description
|
||||
=============================================================================
|
||||
+- 0 --------------+- 0 --------------+
|
||||
| | S390_lowcore | Low-address memory
|
||||
| +- 8 KB -----------+
|
||||
| | |
|
||||
| | |
|
||||
| | ... unused gap | KASAN untracked
|
||||
| | |
|
||||
+- AMODE31_START --+- AMODE31_START --+ .amode31 rand. phys/virt start
|
||||
|.amode31 text/data|.amode31 text/data| KASAN untracked
|
||||
+- AMODE31_END ----+- AMODE31_END ----+ .amode31 rand. phys/virt end (<2GB)
|
||||
| | |
|
||||
| | |
|
||||
+- __kaslr_offset_phys | kernel rand. phys start
|
||||
| | |
|
||||
| kernel text/data | |
|
||||
| | |
|
||||
+------------------+ | kernel phys end
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
+- ident_map_size -+ |
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+- __identity_base + identity mapping start (>= 2GB)
|
||||
| |
|
||||
| identity | phys == virt - __identity_base
|
||||
| mapping | virt == phys + __identity_base
|
||||
| |
|
||||
| | KASAN tracked
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
| |
|
||||
+---- vmemmap -----+ 'struct page' array start
|
||||
| |
|
||||
| virtually mapped |
|
||||
| memory map | KASAN untracked
|
||||
| |
|
||||
+- __abs_lowcore --+
|
||||
| |
|
||||
| Absolute Lowcore | KASAN untracked
|
||||
| |
|
||||
+- __memcpy_real_area
|
||||
| |
|
||||
| Real Memory Copy| KASAN untracked
|
||||
| |
|
||||
+- VMALLOC_START --+ vmalloc area start
|
||||
| | KASAN untracked or
|
||||
| vmalloc area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- MODULES_VADDR --+ modules area start
|
||||
| | KASAN allocated per module or
|
||||
| modules area | KASAN shallowly populated in case
|
||||
| | CONFIG_KASAN_VMALLOC=y
|
||||
+- __kaslr_offset -+ kernel rand. virt start
|
||||
| | KASAN tracked
|
||||
| kernel text/data | phys == (kvirt - __kaslr_offset) +
|
||||
| | __kaslr_offset_phys
|
||||
+- kernel .bss end + kernel rand. virt end
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+------------------+ UltraVisor Secure Storage limit
|
||||
| |
|
||||
| ... unused gap | KASAN untracked
|
||||
| |
|
||||
+KASAN_SHADOW_START+ KASAN shadow memory start
|
||||
| |
|
||||
| KASAN shadow | KASAN untracked
|
||||
| |
|
||||
+------------------+ ASCE limit
|
||||
@ -380,6 +380,36 @@ matrix device.
|
||||
control_domains:
|
||||
A read-only file for displaying the control domain numbers assigned to the
|
||||
vfio_ap mediated device.
|
||||
ap_config:
|
||||
A read/write file that, when written to, allows all three of the
|
||||
vfio_ap mediated device's ap matrix masks to be replaced in one shot.
|
||||
Three masks are given, one for adapters, one for domains, and one for
|
||||
control domains. If the given state cannot be set then no changes are
|
||||
made to the vfio-ap mediated device.
|
||||
|
||||
The format of the data written to ap_config is as follows:
|
||||
{amask},{dmask},{cmask}\n
|
||||
|
||||
\n is a newline character.
|
||||
|
||||
amask, dmask, and cmask are masks identifying which adapters, domains,
|
||||
and control domains should be assigned to the mediated device.
|
||||
|
||||
The format of a mask is as follows:
|
||||
0xNN..NN
|
||||
|
||||
Where NN..NN is 64 hexadecimal characters representing a 256-bit value.
|
||||
The leftmost (highest order) bit represents adapter/domain 0.
|
||||
|
||||
For an example set of masks that represent your mdev's current
|
||||
configuration, simply cat ap_config.
|
||||
|
||||
Setting an adapter or domain number greater than the maximum allowed for
|
||||
the system will result in an error.
|
||||
|
||||
This attribute is intended to be used by automation. End users would be
|
||||
better served using the respective assign/unassign attributes for
|
||||
adapters, domains, and control domains.
|
||||
|
||||
* functions:
|
||||
|
||||
@ -550,7 +580,7 @@ These are the steps:
|
||||
following Kconfig elements selected:
|
||||
* IOMMU_SUPPORT
|
||||
* S390
|
||||
* ZCRYPT
|
||||
* AP
|
||||
* VFIO
|
||||
* KVM
|
||||
|
||||
|
||||
@ -41,7 +41,7 @@ Chapter 36. Coprocessor services
|
||||
submissions until they succeed; waiting for an outstanding CCB to complete is not necessary, and would
|
||||
not be a guarantee that a future submission would succeed.
|
||||
|
||||
The availablility of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
The availability of DAX coprocessor command service is indicated by the presence of the DAX virtual
|
||||
device node in the guest MD (Section 8.24.17, “Database Analytics Accelerators (DAX) virtual-device
|
||||
node”).
|
||||
|
||||
|
||||
@ -446,6 +446,12 @@ during mkdir.
|
||||
max_threshold_occupancy is a user configurable value to determine the
|
||||
occupancy at which an RMID can be freed.
|
||||
|
||||
The mon_llc_occupancy_limbo tracepoint gives the precise occupancy in bytes
|
||||
for a subset of RMID that are not immediately available for allocation.
|
||||
This can't be relied on to produce output every second, it may be necessary
|
||||
to attempt to create an empty monitor group to force an update. Output may
|
||||
only be produced if creation of a control or monitor group fails.
|
||||
|
||||
Schemata files - general concepts
|
||||
---------------------------------
|
||||
Each line in the file describes one resource. The line starts with
|
||||
|
||||
@ -138,7 +138,7 @@ Note this example does not include the sigaltstack preparation.
|
||||
Dynamic features in signal frames
|
||||
---------------------------------
|
||||
|
||||
Dynamcally enabled features are not written to the signal frame upon signal
|
||||
Dynamically enabled features are not written to the signal frame upon signal
|
||||
entry if the feature is in its initial configuration. This differs from
|
||||
non-dynamic features which are always written regardless of their
|
||||
configuration. Signal handlers can examine the XSAVE buffer's XSTATE_BV
|
||||
|
||||
@ -171,14 +171,14 @@ The rule of thumb:
|
||||
- RMW operations that are conditional are unordered on FAILURE,
|
||||
otherwise the above rules apply.
|
||||
|
||||
Except of course when an operation has an explicit ordering like:
|
||||
Except of course when a successful operation has an explicit ordering like:
|
||||
|
||||
{}_relaxed: unordered
|
||||
{}_acquire: the R of the RMW (or atomic_read) is an ACQUIRE
|
||||
{}_release: the W of the RMW (or atomic_set) is a RELEASE
|
||||
|
||||
Where 'unordered' is against other memory locations. Address dependencies are
|
||||
not defeated.
|
||||
not defeated. Conditional operations are still unordered on FAILURE.
|
||||
|
||||
Fully ordered primitives are ordered against everything prior and everything
|
||||
subsequent. Therefore a fully ordered primitive is like having an smp_mb()
|
||||
|
||||
@ -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
|
||||
|
||||
@ -75,6 +75,8 @@ if major >= 3:
|
||||
"__rcu",
|
||||
"__user",
|
||||
"__force",
|
||||
"__counted_by_le",
|
||||
"__counted_by_be",
|
||||
|
||||
# include/linux/compiler_attributes.h:
|
||||
"__alias",
|
||||
|
||||
@ -203,13 +203,33 @@ setting the DMA mask fails. In this manner, if a user of your driver reports
|
||||
that performance is bad or that the device is not even detected, you can ask
|
||||
them for the kernel messages to find out exactly why.
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
The 24-bit addressing device would do something like this::
|
||||
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))) {
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(24))) {
|
||||
dev_warn(dev, "mydev: No suitable DMA available\n");
|
||||
goto ignore_this_device;
|
||||
}
|
||||
|
||||
The standard 64-bit addressing device would do something like this::
|
||||
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64))
|
||||
|
||||
dma_set_mask_and_coherent() never return fail when DMA_BIT_MASK(64). Typical
|
||||
error code like::
|
||||
|
||||
/* Wrong code */
|
||||
if (dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64)))
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32))
|
||||
|
||||
dma_set_mask_and_coherent() will never return failure when bigger than 32.
|
||||
So typical code like::
|
||||
|
||||
/* Recommended code */
|
||||
if (support_64bit)
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
|
||||
else
|
||||
dma_set_mask_and_coherent(dev, DMA_BIT_MASK(32));
|
||||
|
||||
If the device only supports 32-bit addressing for descriptors in the
|
||||
coherent allocations, but supports full 64-bits for streaming mappings
|
||||
it would look like this::
|
||||
|
||||
@ -18,7 +18,7 @@ exceptions`_, `NMI and NMI-like exceptions`_.
|
||||
Non-instrumentable code - noinstr
|
||||
---------------------------------
|
||||
|
||||
Most instrumentation facilities depend on RCU, so intrumentation is prohibited
|
||||
Most instrumentation facilities depend on RCU, so instrumentation is prohibited
|
||||
for entry code before RCU starts watching and exit code after RCU stops
|
||||
watching. In addition, many architectures must save and restore register state,
|
||||
which means that (for example) a breakpoint in the breakpoint entry code would
|
||||
|
||||
78
Documentation/core-api/floating-point.rst
Normal file
78
Documentation/core-api/floating-point.rst
Normal 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.
|
||||
@ -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
|
||||
|
||||
@ -4,7 +4,7 @@
|
||||
Printk Index
|
||||
============
|
||||
|
||||
There are many ways how to monitor the state of the system. One important
|
||||
There are many ways to monitor the state of the system. One important
|
||||
source of information is the system log. It provides a lot of information,
|
||||
including more or less important warnings and error messages.
|
||||
|
||||
@ -101,7 +101,7 @@ their own wrappers adding __printk_index_emit().
|
||||
|
||||
Only few subsystem specific wrappers have been updated so far,
|
||||
for example, dev_printk(). As a result, the printk formats from
|
||||
some subsystes can be missing in the printk index.
|
||||
some subsystems can be missing in the printk index.
|
||||
|
||||
|
||||
Subsystem specific prefix
|
||||
|
||||
321
Documentation/core-api/swiotlb.rst
Normal file
321
Documentation/core-api/swiotlb.rst
Normal 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().
|
||||
@ -671,7 +671,7 @@ configuration, worker pools and how workqueues map to the pools: ::
|
||||
events_unbound unbound 9 9 10 10 8
|
||||
events_freezable percpu 0 2 4 6
|
||||
events_power_efficient percpu 0 2 4 6
|
||||
events_freezable_power_ percpu 0 2 4 6
|
||||
events_freezable_pwr_ef percpu 0 2 4 6
|
||||
rcu_gp percpu 0 2 4 6
|
||||
rcu_par_gp percpu 0 2 4 6
|
||||
slub_flushwq percpu 0 2 4 6
|
||||
@ -694,7 +694,7 @@ Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
|
||||
events_unbound 38306 0 0.1 - 7 - -
|
||||
events_freezable 0 0 0.0 0 0 - -
|
||||
events_power_efficient 29598 0 0.2 0 0 - -
|
||||
events_freezable_power_ 10 0 0.0 0 0 - -
|
||||
events_freezable_pwr_ef 10 0 0.0 0 0 - -
|
||||
sock_diag_events 0 0 0.0 0 0 - -
|
||||
|
||||
total infl CPUtime CPUhog CMW/RPR mayday rescued
|
||||
@ -704,7 +704,7 @@ Use tools/workqueue/wq_monitor.py to monitor workqueue operations: ::
|
||||
events_unbound 38322 0 0.1 - 7 - -
|
||||
events_freezable 0 0 0.0 0 0 - -
|
||||
events_power_efficient 29603 0 0.2 0 0 - -
|
||||
events_freezable_power_ 10 0 0.0 0 0 - -
|
||||
events_freezable_pwr_ef 10 0 0.0 0 0 - -
|
||||
sock_diag_events 0 0 0.0 0 0 - -
|
||||
|
||||
...
|
||||
|
||||
@ -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
|
||||
|
||||
@ -91,6 +91,16 @@ the below options are available:
|
||||
behaviour when encountering a data race is deemed safe. Please see
|
||||
`"Marking Shared-Memory Accesses" in the LKMM`_ for more information.
|
||||
|
||||
* Similar to ``data_race(...)``, the type qualifier ``__data_racy`` can be used
|
||||
to document that all data races due to accesses to a variable are intended
|
||||
and should be ignored by KCSAN::
|
||||
|
||||
struct foo {
|
||||
...
|
||||
int __data_racy stats_counter;
|
||||
...
|
||||
};
|
||||
|
||||
* Disabling data race detection for entire functions can be accomplished by
|
||||
using the function attribute ``__no_kcsan``::
|
||||
|
||||
|
||||
@ -183,7 +183,7 @@ expected time it takes to run a test. If you have control over the systems
|
||||
which will run the tests you can configure a test runner on those systems to
|
||||
use a greater or lower timeout on the command line as with the `-o` or
|
||||
the `--override-timeout` argument. For example to use 165 seconds instead
|
||||
one would use:
|
||||
one would use::
|
||||
|
||||
$ ./run_kselftest.sh --override-timeout 165
|
||||
|
||||
|
||||
@ -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)
|
||||
|
||||
@ -0,0 +1,84 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/access-controllers/access-controllers.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Generic Domain Access Controllers
|
||||
|
||||
maintainers:
|
||||
- Oleksii Moisieiev <oleksii_moisieiev@epam.com>
|
||||
|
||||
description: |+
|
||||
Common access controllers properties
|
||||
|
||||
Access controllers are in charge of stating which of the hardware blocks under
|
||||
their responsibility (their domain) can be accesssed by which compartment. A
|
||||
compartment can be a cluster of CPUs (or coprocessors), a range of addresses
|
||||
or a group of hardware blocks. An access controller's domain is the set of
|
||||
resources covered by the access controller.
|
||||
|
||||
This device tree binding can be used to bind devices to their access
|
||||
controller provided by access-controllers property. In this case, the device
|
||||
is a consumer and the access controller is the provider.
|
||||
|
||||
An access controller can be represented by any node in the device tree and
|
||||
can provide one or more configuration parameters, needed to control parameters
|
||||
of the consumer device. A consumer node can refer to the provider by phandle
|
||||
and a set of phandle arguments, specified by '#access-controller-cells'
|
||||
property in the access controller node.
|
||||
|
||||
Access controllers are typically used to set/read the permissions of a
|
||||
hardware block and grant access to it. Any of which depends on the access
|
||||
controller. The capabilities of each access controller are defined by the
|
||||
binding of the access controller device.
|
||||
|
||||
Each node can be a consumer for the several access controllers.
|
||||
|
||||
# always select the core schema
|
||||
select: true
|
||||
|
||||
properties:
|
||||
"#access-controller-cells":
|
||||
description:
|
||||
Number of cells in an access-controllers specifier;
|
||||
Can be any value as specified by device tree binding documentation
|
||||
of a particular provider. The node is an access controller.
|
||||
|
||||
access-controller-names:
|
||||
$ref: /schemas/types.yaml#/definitions/string-array
|
||||
description:
|
||||
A list of access-controllers names, sorted in the same order as
|
||||
access-controllers entries. Consumer drivers will use
|
||||
access-controller-names to match with existing access-controllers entries.
|
||||
|
||||
access-controllers:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
A list of access controller specifiers, as defined by the
|
||||
bindings of the access-controllers provider.
|
||||
|
||||
additionalProperties: true
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock_controller: access-controllers@50000 {
|
||||
reg = <0x50000 0x400>;
|
||||
#access-controller-cells = <2>;
|
||||
};
|
||||
|
||||
bus_controller: bus@60000 {
|
||||
reg = <0x60000 0x10000>;
|
||||
#address-cells = <1>;
|
||||
#size-cells = <1>;
|
||||
ranges;
|
||||
#access-controller-cells = <3>;
|
||||
|
||||
uart4: serial@60100 {
|
||||
reg = <0x60100 0x400>;
|
||||
clocks = <&clk_serial>;
|
||||
access-controllers = <&clock_controller 1 2>,
|
||||
<&bus_controller 1 3 5>;
|
||||
access-controller-names = "clock", "bus";
|
||||
};
|
||||
};
|
||||
@ -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>;
|
||||
};
|
||||
@ -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:
|
||||
|
||||
@ -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>;
|
||||
};
|
||||
@ -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
|
||||
|
||||
@ -53,6 +53,7 @@ properties:
|
||||
- description: BCM4709 based boards
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3200
|
||||
- asus,rt-ac87u
|
||||
- buffalo,wxr-1900dhp
|
||||
- linksys,ea9200
|
||||
@ -67,6 +68,7 @@ properties:
|
||||
items:
|
||||
- enum:
|
||||
- asus,rt-ac3100
|
||||
- asus,rt-ac5300
|
||||
- asus,rt-ac88u
|
||||
- dlink,dir-885l
|
||||
- dlink,dir-890l
|
||||
|
||||
@ -46,6 +46,30 @@ properties:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
|
||||
gpio:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: raspberrypi,firmware-gpio
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
description:
|
||||
The first cell is the pin number, and the second cell is used to
|
||||
specify the gpio polarity (GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW).
|
||||
|
||||
gpio-line-names:
|
||||
minItems: 8
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpio-controller
|
||||
- "#gpio-cells"
|
||||
|
||||
reset:
|
||||
type: object
|
||||
additionalProperties: false
|
||||
@ -96,6 +120,12 @@ examples:
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
expgpio: gpio {
|
||||
compatible = "raspberrypi,firmware-gpio";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
|
||||
reset: reset {
|
||||
compatible = "raspberrypi,firmware-reset";
|
||||
#reset-cells = <1>;
|
||||
|
||||
@ -813,6 +813,14 @@ properties:
|
||||
- const: tq,imx6ull-tqma6ull2l # MCIMX6Y2, LGA SoM variant
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: Seeed Stuido i.MX6ULL SoM on dev boards
|
||||
items:
|
||||
- enum:
|
||||
- seeed,imx6ull-seeed-npi-emmc
|
||||
- seeed,imx6ull-seeed-npi-nand
|
||||
- const: seeed,imx6ull-seeed-npi
|
||||
- const: fsl,imx6ull
|
||||
|
||||
- description: i.MX6ULZ based Boards
|
||||
items:
|
||||
- enum:
|
||||
@ -1050,6 +1058,7 @@ properties:
|
||||
- enum:
|
||||
- beacon,imx8mp-beacon-kit # i.MX8MP Beacon Development Kit
|
||||
- dmo,imx8mp-data-modul-edm-sbc # i.MX8MP eDM SBC
|
||||
- emcraft,imx8mp-navqp # i.MX8MP Emcraft Systems NavQ+ Kit
|
||||
- fsl,imx8mp-evk # i.MX8MP EVK Board
|
||||
- gateworks,imx8mp-gw71xx-2x # i.MX8MP Gateworks Board
|
||||
- gateworks,imx8mp-gw72xx-2x # i.MX8MP Gateworks Board
|
||||
@ -1218,7 +1227,6 @@ properties:
|
||||
- enum:
|
||||
- einfochips,imx8qxp-ai_ml # i.MX8QXP AI_ML Board
|
||||
- fsl,imx8qxp-mek # i.MX8QXP MEK Board
|
||||
- toradex,colibri-imx8x # Colibri iMX8X Modules
|
||||
- const: fsl,imx8qxp
|
||||
|
||||
- description: i.MX8DXL based Boards
|
||||
@ -1227,7 +1235,7 @@ properties:
|
||||
- fsl,imx8dxl-evk # i.MX8DXL EVK Board
|
||||
- const: fsl,imx8dxl
|
||||
|
||||
- description: i.MX8QXP Boards with Toradex Colibri iMX8X Modules
|
||||
- description: i.MX8QXP/i.MX8DX Boards with Toradex Colibri iMX8X Modules
|
||||
items:
|
||||
- enum:
|
||||
- toradex,colibri-imx8x-aster # Colibri iMX8X Module on Aster Board
|
||||
@ -1235,7 +1243,9 @@ properties:
|
||||
- toradex,colibri-imx8x-iris # Colibri iMX8X Module on Iris Board
|
||||
- toradex,colibri-imx8x-iris-v2 # Colibri iMX8X Module on Iris Board V2
|
||||
- const: toradex,colibri-imx8x
|
||||
- const: fsl,imx8qxp
|
||||
- enum:
|
||||
- fsl,imx8qxp
|
||||
- fsl,imx8dx
|
||||
|
||||
- description:
|
||||
TQMa8Xx is a series of SOM featuring NXP i.MX8X system-on-chip
|
||||
@ -1536,6 +1546,12 @@ properties:
|
||||
- nxp,s32g274a-rdb2
|
||||
- const: nxp,s32g2
|
||||
|
||||
- description: S32G3 based Boards
|
||||
items:
|
||||
- enum:
|
||||
- nxp,s32g399a-rdb3
|
||||
- const: nxp,s32g3
|
||||
|
||||
- description: S32V234 based Boards
|
||||
items:
|
||||
- enum:
|
||||
|
||||
@ -61,10 +61,6 @@ properties:
|
||||
mboxes:
|
||||
minItems: 2
|
||||
|
||||
ti,system-reboot-controller:
|
||||
description: Determines If system reboot can be triggered by SoC reboot
|
||||
type: boolean
|
||||
|
||||
ti,host-id:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
description: |
|
||||
@ -94,7 +90,6 @@ examples:
|
||||
- |
|
||||
pmmc: system-controller@2921800 {
|
||||
compatible = "ti,k2g-sci";
|
||||
ti,system-reboot-controller;
|
||||
mbox-names = "rx", "tx";
|
||||
mboxes = <&msgmgr 5 2>,
|
||||
<&msgmgr 0 0>;
|
||||
|
||||
@ -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>;
|
||||
}
|
||||
@ -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>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
@ -137,6 +137,7 @@ properties:
|
||||
- microsoft,dempsey
|
||||
- microsoft,makepeace
|
||||
- microsoft,moneypenny
|
||||
- motorola,falcon
|
||||
- samsung,s3ve3g
|
||||
- const: qcom,msm8226
|
||||
|
||||
@ -184,13 +185,16 @@ properties:
|
||||
- oneplus,bacon
|
||||
- samsung,klte
|
||||
- sony,xperia-castor
|
||||
- sony,xperia-leo
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- const: qcom,msm8916-mtp
|
||||
- const: qcom,msm8916-mtp/1
|
||||
- const: qcom,msm8916
|
||||
- enum:
|
||||
- samsung,kltechn
|
||||
- const: samsung,klte
|
||||
- const: qcom,msm8974pro
|
||||
- const: qcom,msm8974
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
@ -200,6 +204,8 @@ properties:
|
||||
- gplus,fl8005a
|
||||
- huawei,g7
|
||||
- longcheer,l8910
|
||||
- longcheer,l8150
|
||||
- qcom,msm8916-mtp
|
||||
- samsung,a3u-eur
|
||||
- samsung,a5u-eur
|
||||
- samsung,e5
|
||||
@ -220,11 +226,6 @@ properties:
|
||||
- yiming,uz801-v3
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- const: longcheer,l8150
|
||||
- const: qcom,msm8916-v1-qrd/9-v1
|
||||
- const: qcom,msm8916
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- motorola,potter
|
||||
@ -1003,6 +1004,7 @@ properties:
|
||||
- qcom,sm8550-hdk
|
||||
- qcom,sm8550-mtp
|
||||
- qcom,sm8550-qrd
|
||||
- sony,pdx234
|
||||
- const: qcom,sm8550
|
||||
|
||||
- items:
|
||||
|
||||
@ -49,6 +49,11 @@ properties:
|
||||
- anbernic,rg-arc-s
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: ArmSoM Sige7 board
|
||||
items:
|
||||
- const: armsom,sige7
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Asus Tinker board
|
||||
items:
|
||||
- const: asus,rk3288-tinker
|
||||
@ -198,6 +203,13 @@ properties:
|
||||
- const: firefly,rk3568-roc-pc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Forlinx FET3588-C SoM
|
||||
items:
|
||||
- enum:
|
||||
- forlinx,ok3588-c
|
||||
- const: forlinx,fet3588-c
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: FriendlyElec NanoPi R2 series boards
|
||||
items:
|
||||
- enum:
|
||||
@ -236,6 +248,11 @@ properties:
|
||||
- const: friendlyarm,nanopc-t6
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: GameForce Chi
|
||||
items:
|
||||
- const: gameforce,chi
|
||||
- const: rockchip,rk3326
|
||||
|
||||
- description: GeekBuying GeekBox
|
||||
items:
|
||||
- const: geekbuying,geekbox
|
||||
@ -631,7 +648,7 @@ properties:
|
||||
- const: phytec,rk3288-phycore-som
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Pine64 PinebookPro
|
||||
- description: Pine64 Pinebook Pro
|
||||
items:
|
||||
- const: pine64,pinebook-pro
|
||||
- const: rockchip,rk3399
|
||||
@ -644,7 +661,7 @@ properties:
|
||||
- const: pine64,pinenote
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Pine64 PinePhonePro
|
||||
- description: Pine64 PinePhone Pro
|
||||
items:
|
||||
- const: pine64,pinephone-pro
|
||||
- const: rockchip,rk3399
|
||||
@ -682,7 +699,7 @@ properties:
|
||||
- const: pine64,quartzpro64
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: Pine64 SoQuartz SoM
|
||||
- description: Pine64 SOQuartz
|
||||
items:
|
||||
- enum:
|
||||
- pine64,soquartz-blade
|
||||
@ -700,12 +717,17 @@ properties:
|
||||
- powkiddy,x55
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Protonic MECSBC board
|
||||
items:
|
||||
- const: prt,mecsbc
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: QNAP TS-433-4G 4-Bay NAS
|
||||
items:
|
||||
- const: qnap,ts433
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa Compute Module 3(CM3)
|
||||
- description: Radxa Compute Module 3 (CM3)
|
||||
items:
|
||||
- enum:
|
||||
- radxa,cm3-io
|
||||
@ -767,22 +789,27 @@ properties:
|
||||
- const: radxa,rockpis
|
||||
- const: rockchip,rk3308
|
||||
|
||||
- description: Radxa Rock2 Square
|
||||
- description: Radxa Rock 2 Square
|
||||
items:
|
||||
- const: radxa,rock2-square
|
||||
- const: rockchip,rk3288
|
||||
|
||||
- description: Radxa ROCK3 Model A
|
||||
- description: Radxa ROCK 3A
|
||||
items:
|
||||
- const: radxa,rock3a
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Radxa ROCK 5 Model A
|
||||
- description: Radxa ROCK 3C
|
||||
items:
|
||||
- const: radxa,rock-3c
|
||||
- const: rockchip,rk3566
|
||||
|
||||
- description: Radxa ROCK 5A
|
||||
items:
|
||||
- const: radxa,rock-5a
|
||||
- const: rockchip,rk3588s
|
||||
|
||||
- description: Radxa ROCK 5 Model B
|
||||
- description: Radxa ROCK 5B
|
||||
items:
|
||||
- const: radxa,rock-5b
|
||||
- const: rockchip,rk3588
|
||||
@ -927,6 +954,11 @@ properties:
|
||||
- const: turing,rk1
|
||||
- const: rockchip,rk3588
|
||||
|
||||
- description: WolfVision PF5 mainboard
|
||||
items:
|
||||
- const: wolfvision,rk3568-pf5
|
||||
- const: rockchip,rk3568
|
||||
|
||||
- description: Xunlong Orange Pi 5 Plus
|
||||
items:
|
||||
- const: xunlong,orangepi-5-plus
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user