mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-12-29 17:25:38 +00:00
Merge branch 'for-5.16-vsprintf-pgp' into for-linus
This commit is contained in:
commit
40e64a88da
@ -128,6 +128,8 @@ Date: Aug 28, 2020
|
||||
KernelVersion: 5.10.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: The last executed device administrative command's status/error.
|
||||
Also last configuration error overloaded.
|
||||
Writing to it will clear the status.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/block_on_fault
|
||||
Date: Oct 27, 2020
|
||||
@ -211,6 +213,13 @@ Contact: dmaengine@vger.kernel.org
|
||||
Description: Indicate whether ATS disable is turned on for the workqueue.
|
||||
0 indicates ATS is on, and 1 indicates ATS is off for the workqueue.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/occupancy
|
||||
Date May 25, 2021
|
||||
KernelVersion: 5.14.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Show the current number of entries in this WQ if WQ Occupancy
|
||||
Support bit WQ capabilities is 1.
|
||||
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
|
@ -215,6 +215,17 @@ Description: Sets the skip reset on timeout option for the device. Value of
|
||||
"0" means device will be reset in case some CS has timed out,
|
||||
otherwise it will not be reset.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/state_dump
|
||||
Date: Oct 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: ynudelman@habana.ai
|
||||
Description: Gets the state dump occurring on a CS timeout or failure.
|
||||
State dump is used for debug and is created each time in case of
|
||||
a problem in a CS execution, before reset.
|
||||
Reading from the node returns the newest state dump available.
|
||||
Writing an integer X discards X state dumps, so that the
|
||||
next read would return X+1-st newest state dump.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/stop_on_err
|
||||
Date: Mar 2020
|
||||
KernelVersion: 5.6
|
||||
@ -230,6 +241,14 @@ Description: Displays a list with information about the currently user
|
||||
pointers (user virtual addresses) that are pinned and mapped
|
||||
to DMA addresses
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/userptr_lookup
|
||||
Date: Aug 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: ogabbay@kernel.org
|
||||
Description: Allows to search for specific user pointers (user virtual
|
||||
addresses) that are pinned and mapped to DMA addresses, and see
|
||||
their resolution to the specific dma address.
|
||||
|
||||
What: /sys/kernel/debug/habanalabs/hl<n>/vm
|
||||
Date: Jan 2019
|
||||
KernelVersion: 5.1
|
||||
|
@ -1,7 +1,7 @@
|
||||
What: /dev/wmi/dell-smbios
|
||||
Date: November 2017
|
||||
KernelVersion: 4.15
|
||||
Contact: "Mario Limonciello" <mario.limonciello@dell.com>
|
||||
Contact: Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
Perform SMBIOS calls on supported Dell machines.
|
||||
through the Dell ACPI-WMI interface.
|
||||
|
@ -27,12 +27,13 @@ Description:
|
||||
lsm: [[subj_user=] [subj_role=] [subj_type=]
|
||||
[obj_user=] [obj_role=] [obj_type=]]
|
||||
option: [[appraise_type=]] [template=] [permit_directio]
|
||||
[appraise_flag=] [keyrings=]
|
||||
[appraise_flag=] [appraise_algos=] [keyrings=]
|
||||
base:
|
||||
func:= [BPRM_CHECK][MMAP_CHECK][CREDS_CHECK][FILE_CHECK][MODULE_CHECK]
|
||||
[FIRMWARE_CHECK]
|
||||
[FIRMWARE_CHECK]
|
||||
[KEXEC_KERNEL_CHECK] [KEXEC_INITRAMFS_CHECK]
|
||||
[KEXEC_CMDLINE] [KEY_CHECK] [CRITICAL_DATA]
|
||||
[SETXATTR_CHECK]
|
||||
mask:= [[^]MAY_READ] [[^]MAY_WRITE] [[^]MAY_APPEND]
|
||||
[[^]MAY_EXEC]
|
||||
fsmagic:= hex value
|
||||
@ -55,6 +56,10 @@ Description:
|
||||
label:= [selinux]|[kernel_info]|[data_label]
|
||||
data_label:= a unique string used for grouping and limiting critical data.
|
||||
For example, "selinux" to measure critical data for SELinux.
|
||||
appraise_algos:= comma-separated list of hash algorithms
|
||||
For example, "sha256,sha512" to only accept to appraise
|
||||
files where the security.ima xattr was hashed with one
|
||||
of these two algorithms.
|
||||
|
||||
default policy:
|
||||
# PROC_SUPER_MAGIC
|
||||
@ -134,3 +139,9 @@ Description:
|
||||
keys added to .builtin_trusted_keys or .ima keyring:
|
||||
|
||||
measure func=KEY_CHECK keyrings=.builtin_trusted_keys|.ima
|
||||
|
||||
Example of the special SETXATTR_CHECK appraise rule, that
|
||||
restricts the hash algorithms allowed when writing to the
|
||||
security.ima xattr of a file:
|
||||
|
||||
appraise func=SETXATTR_CHECK appraise_algos=sha256,sha384,sha512
|
||||
|
@ -121,6 +121,23 @@ Description:
|
||||
child buses, and re-discover devices removed earlier
|
||||
from this part of the device tree.
|
||||
|
||||
What: /sys/bus/pci/devices/.../reset_method
|
||||
Date: August 2021
|
||||
Contact: Amey Narkhede <ameynarkhede03@gmail.com>
|
||||
Description:
|
||||
Some devices allow an individual function to be reset
|
||||
without affecting other functions in the same slot.
|
||||
|
||||
For devices that have this support, a file named
|
||||
reset_method is present in sysfs. Reading this file
|
||||
gives names of the supported and enabled reset methods and
|
||||
their ordering. Writing a space-separated list of names of
|
||||
reset methods sets the reset methods and ordering to be
|
||||
used when resetting the device. Writing an empty string
|
||||
disables the ability to reset the device. Writing
|
||||
"default" enables all supported reset methods in the
|
||||
default ordering.
|
||||
|
||||
What: /sys/bus/pci/devices/.../reset
|
||||
Date: July 2009
|
||||
Contact: Michael S. Tsirkin <mst@redhat.com>
|
||||
|
@ -232,7 +232,7 @@ Description: When new NVM image is written to the non-active NVM
|
||||
What: /sys/bus/thunderbolt/devices/.../nvm_authenticate_on_disconnect
|
||||
Date: Oct 2020
|
||||
KernelVersion: v5.9
|
||||
Contact: Mario Limonciello <mario.limonciello@dell.com>
|
||||
Contact: Mario Limonciello <mario.limonciello@outlook.com>
|
||||
Description: For supported devices, automatically authenticate the new Thunderbolt
|
||||
image when the device is disconnected from the host system.
|
||||
|
||||
|
@ -2,8 +2,8 @@ What: /sys/class/firmware-attributes/*/attributes/*/
|
||||
Date: February 2021
|
||||
KernelVersion: 5.11
|
||||
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
|
||||
Mario Limonciello <mario.limonciello@dell.com>,
|
||||
Prasanth KSR <prasanth.ksr@dell.com>
|
||||
Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
A sysfs interface for systems management software to enable
|
||||
configuration capability on supported systems. This directory
|
||||
@ -130,8 +130,8 @@ What: /sys/class/firmware-attributes/*/authentication/
|
||||
Date: February 2021
|
||||
KernelVersion: 5.11
|
||||
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
|
||||
Mario Limonciello <mario.limonciello@dell.com>,
|
||||
Prasanth KSR <prasanth.ksr@dell.com>
|
||||
Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
Devices support various authentication mechanisms which can be exposed
|
||||
as a separate configuration object.
|
||||
@ -220,8 +220,8 @@ What: /sys/class/firmware-attributes/*/attributes/pending_reboot
|
||||
Date: February 2021
|
||||
KernelVersion: 5.11
|
||||
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
|
||||
Mario Limonciello <mario.limonciello@dell.com>,
|
||||
Prasanth KSR <prasanth.ksr@dell.com>
|
||||
Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
A read-only attribute reads 1 if a reboot is necessary to apply
|
||||
pending BIOS attribute changes. Also, an uevent_KOBJ_CHANGE is
|
||||
@ -249,8 +249,8 @@ What: /sys/class/firmware-attributes/*/attributes/reset_bios
|
||||
Date: February 2021
|
||||
KernelVersion: 5.11
|
||||
Contact: Divya Bharathi <Divya.Bharathi@Dell.com>,
|
||||
Mario Limonciello <mario.limonciello@dell.com>,
|
||||
Prasanth KSR <prasanth.ksr@dell.com>
|
||||
Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
This attribute can be used to reset the BIOS Configuration.
|
||||
Specifically, it tells which type of reset BIOS configuration is being
|
||||
@ -272,3 +272,14 @@ Description:
|
||||
|
||||
Note that any changes to this attribute requires a reboot
|
||||
for changes to take effect.
|
||||
|
||||
What: /sys/class/firmware-attributes/*/attributes/debug_cmd
|
||||
Date: July 2021
|
||||
KernelVersion: 5.14
|
||||
Contact: Mark Pearson <markpearson@lenovo.com>
|
||||
Description:
|
||||
This write only attribute can be used to send debug commands to the BIOS.
|
||||
This should only be used when recommended by the BIOS vendor. Vendors may
|
||||
use it to enable extra debug attributes or BIOS features for testing purposes.
|
||||
|
||||
Note that any changes to this attribute requires a reboot for changes to take effect.
|
||||
|
54
Documentation/ABI/testing/sysfs-driver-intc_sar
Normal file
54
Documentation/ABI/testing/sysfs-driver-intc_sar
Normal file
@ -0,0 +1,54 @@
|
||||
What: /sys/bus/platform/devices/INTC1092:00/intc_reg
|
||||
Date: August 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Shravan S <s.shravan@intel.com>,
|
||||
An Sudhakar <sudhakar.an@intel.com>
|
||||
Description:
|
||||
Specific Absorption Rate (SAR) regulatory mode is typically
|
||||
derived based on information like mcc (Mobile Country Code) and
|
||||
mnc (Mobile Network Code) that is available for the currently
|
||||
attached LTE network. A userspace application is required to set
|
||||
the current SAR regulatory mode on the Dynamic SAR driver using
|
||||
this sysfs node. Such an application can also read back using
|
||||
this sysfs node, the currently configured regulatory mode value
|
||||
from the Dynamic SAR driver.
|
||||
|
||||
Acceptable regulatory modes are:
|
||||
== ====
|
||||
0 FCC
|
||||
1 CE
|
||||
2 ISED
|
||||
== ====
|
||||
|
||||
- The regulatory mode value has one of the above values.
|
||||
- The default regulatory mode used in the driver is 0.
|
||||
|
||||
What: /sys/bus/platform/devices/INTC1092:00/intc_data
|
||||
Date: August 2021
|
||||
KernelVersion: 5.15
|
||||
Contact: Shravan S <s.shravan@intel.com>,
|
||||
An Sudhakar <sudhakar.an@intel.com>
|
||||
Description:
|
||||
This sysfs entry is used to retrieve Dynamic SAR information
|
||||
emitted/maintained by a BIOS that supports Dynamic SAR.
|
||||
|
||||
The retrieved information is in the order given below:
|
||||
- device_mode
|
||||
- bandtable_index
|
||||
- antennatable_index
|
||||
- sartable_index
|
||||
|
||||
The above information is sent as integer values separated
|
||||
by a single space. This information can then be pushed to a
|
||||
WWAN modem that uses this to control the transmit signal
|
||||
level using the Band/Antenna/SAR table index information.
|
||||
These parameters are derived/decided by aggregating
|
||||
device-mode like laptop/tablet/clamshell etc. and the
|
||||
proximity-sensor data available to the embedded controller on
|
||||
given host. The regulatory mode configured on Dynamic SAR
|
||||
driver also influences these values.
|
||||
|
||||
The userspace applications can poll for changes to this file
|
||||
using POLLPRI event on file-descriptor (fd) obtained by opening
|
||||
this sysfs entry. Application can then read this information from
|
||||
the sysfs node and consume the given information.
|
@ -1298,3 +1298,239 @@ Description: This node is used to set or display whether UFS WriteBooster is
|
||||
(if the platform supports UFSHCD_CAP_CLK_SCALING). For a
|
||||
platform that doesn't support UFSHCD_CAP_CLK_SCALING, we can
|
||||
disable/enable WriteBooster through this sysfs node.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_version
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the HPB specification version.
|
||||
The full information about the descriptor can be found in the UFS
|
||||
HPB (Host Performance Booster) Extension specifications.
|
||||
Example: version 1.2.3 = 0123h
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/device_descriptor/hpb_control
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows an indication of the HPB control mode.
|
||||
00h: Host control mode
|
||||
01h: Device control mode
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_region_size
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the bHPBRegionSize which can be calculated
|
||||
as in the following (in bytes):
|
||||
HPB Region size = 512B * 2^bHPBRegionSize
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_number_lu
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the maximum number of HPB LU supported by
|
||||
the device.
|
||||
00h: HPB is not supported by the device.
|
||||
01h ~ 20h: Maximum number of HPB LU supported by the device
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_subregion_size
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the bHPBSubRegionSize, which can be
|
||||
calculated as in the following (in bytes) and shall be a multiple of
|
||||
logical block size:
|
||||
HPB Sub-Region size = 512B x 2^bHPBSubRegionSize
|
||||
bHPBSubRegionSize shall not exceed bHPBRegionSize.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/geometry_descriptor/hpb_max_active_regions
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the maximum number of active HPB regions that
|
||||
is supported by the device.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_lu_max_active_regions
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the maximum number of HPB regions assigned to
|
||||
the HPB logical unit.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_pinned_region_start_offset
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the start offset of HPB pinned region.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/unit_descriptor/hpb_number_pinned_regions
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of HPB pinned regions assigned to
|
||||
the HPB logical unit.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/hit_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of reads that changed to HPB read.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/miss_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of reads that cannot be changed to
|
||||
HPB read.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_noti_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of response UPIUs that has
|
||||
recommendations for activating sub-regions and/or inactivating region.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_active_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of active sub-regions recommended by
|
||||
response UPIUs.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/rb_inactive_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of inactive regions recommended by
|
||||
response UPIUs.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_stats/map_req_cnt
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the number of read buffer commands for
|
||||
activating sub-regions recommended by response UPIUs.
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_params/requeue_timeout_ms
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the requeue timeout threshold for write buffer
|
||||
command in ms. The value can be changed by writing an integer to
|
||||
this entry.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/attributes/max_data_size_hpb_single_cmd
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the maximum HPB data size for using a single HPB
|
||||
command.
|
||||
|
||||
=== ========
|
||||
00h 4KB
|
||||
01h 8KB
|
||||
02h 12KB
|
||||
...
|
||||
FFh 1024KB
|
||||
=== ========
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/bus/platform/drivers/ufshcd/*/flags/hpb_enable
|
||||
Date: June 2021
|
||||
Contact: Daejun Park <daejun7.park@samsung.com>
|
||||
Description: This entry shows the status of HPB.
|
||||
|
||||
== ============================
|
||||
0 HPB is not enabled.
|
||||
1 HPB is enabled
|
||||
== ============================
|
||||
|
||||
The file is read only.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/activation_thld
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: In host control mode, reads are the major source of activation
|
||||
trials. Once this threshold hs met, the region is added to the
|
||||
"to-be-activated" list. Since we reset the read counter upon
|
||||
write, this include sending a rb command updating the region
|
||||
ppn as well.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/normalization_factor
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: In host control mode, we think of the regions as "buckets".
|
||||
Those buckets are being filled with reads, and emptied on write.
|
||||
We use entries_per_srgn - the amount of blocks in a subregion as
|
||||
our bucket size. This applies because HPB1.0 only handles
|
||||
single-block reads. Once the bucket size is crossed, we trigger
|
||||
a normalization work - not only to avoid overflow, but mainly
|
||||
because we want to keep those counters normalized, as we are
|
||||
using those reads as a comparative score, to make various decisions.
|
||||
The normalization is dividing (shift right) the read counter by
|
||||
the normalization_factor. If during consecutive normalizations
|
||||
an active region has exhausted its reads - inactivate it.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_enter
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: Region deactivation is often due to the fact that eviction took
|
||||
place: A region becomes active at the expense of another. This is
|
||||
happening when the max-active-regions limit has been crossed.
|
||||
In host mode, eviction is considered an extreme measure. We
|
||||
want to verify that the entering region has enough reads, and
|
||||
the exiting region has much fewer reads. eviction_thld_enter is
|
||||
the min reads that a region must have in order to be considered
|
||||
a candidate for evicting another region.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/eviction_thld_exit
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: Same as above for the exiting region. A region is considered to
|
||||
be a candidate for eviction only if it has fewer reads than
|
||||
eviction_thld_exit.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_ms
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: In order not to hang on to "cold" regions, we inactivate
|
||||
a region that has no READ access for a predefined amount of
|
||||
time - read_timeout_ms. If read_timeout_ms has expired, and the
|
||||
region is dirty, it is less likely that we can make any use of
|
||||
HPB reading it so we inactivate it. Still, deactivation has
|
||||
its overhead, and we may still benefit from HPB reading this
|
||||
region if it is clean - see read_timeout_expiries.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/read_timeout_expiries
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: If the region read timeout has expired, but the region is clean,
|
||||
just re-wind its timer for another spin. Do that as long as it
|
||||
is clean and did not exhaust its read_timeout_expiries threshold.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/timeout_polling_interval_ms
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: The frequency with which the delayed worker that checks the
|
||||
read_timeouts is awakened.
|
||||
|
||||
What: /sys/class/scsi_device/*/device/hpb_param_sysfs/inflight_map_req
|
||||
Date: February 2021
|
||||
Contact: Avri Altman <avri.altman@wdc.com>
|
||||
Description: In host control mode the host is the originator of map requests.
|
||||
To avoid flooding the device with map requests, use a simple throttling
|
||||
mechanism that limits the number of inflight map requests.
|
||||
|
@ -41,8 +41,7 @@ Description: This parameter controls the number of prefree segments to be
|
||||
What: /sys/fs/f2fs/<disk>/main_blkaddr
|
||||
Date: November 2019
|
||||
Contact: "Ramon Pantin" <pantin@google.com>
|
||||
Description:
|
||||
Shows first block address of MAIN area.
|
||||
Description: Shows first block address of MAIN area.
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/ipu_policy
|
||||
Date: November 2013
|
||||
@ -493,3 +492,23 @@ Contact: "Chao Yu" <yuchao0@huawei.com>
|
||||
Description: When ATGC is on, it controls age threshold to bypass GCing young
|
||||
candidates whose age is not beyond the threshold, by default it was
|
||||
initialized as 604800 seconds (equals to 7 days).
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_reclaimed_segments
|
||||
Date: July 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: Show how many segments have been reclaimed by GC during a specific
|
||||
GC mode (0: GC normal, 1: GC idle CB, 2: GC idle greedy,
|
||||
3: GC idle AT, 4: GC urgent high, 5: GC urgent low)
|
||||
You can re-initialize this value to "0".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/gc_segment_mode
|
||||
Date: July 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: You can control for which gc mode the "gc_reclaimed_segments" node shows.
|
||||
Refer to the description of the modes in "gc_reclaimed_segments".
|
||||
|
||||
What: /sys/fs/f2fs/<disk>/seq_file_ra_mul
|
||||
Date: July 2021
|
||||
Contact: "Daeho Jeong" <daehojeong@google.com>
|
||||
Description: You can control the multiplier value of bdi device readahead window size
|
||||
between 2 (default) and 256 for POSIX_FADV_SEQUENTIAL advise option.
|
||||
|
@ -42,8 +42,12 @@ Description: /sys/kernel/iommu_groups/<grp_id>/type shows the type of default
|
||||
======== ======================================================
|
||||
DMA All the DMA transactions from the device in this group
|
||||
are translated by the iommu.
|
||||
DMA-FQ As above, but using batched invalidation to lazily
|
||||
remove translations after use. This may offer reduced
|
||||
overhead at the cost of reduced memory protection.
|
||||
identity All the DMA transactions from the device in this group
|
||||
are not translated by the iommu.
|
||||
are not translated by the iommu. Maximum performance
|
||||
but zero protection.
|
||||
auto Change to the type the device was booted with.
|
||||
======== ======================================================
|
||||
|
||||
|
24
Documentation/ABI/testing/sysfs-kernel-mm-numa
Normal file
24
Documentation/ABI/testing/sysfs-kernel-mm-numa
Normal file
@ -0,0 +1,24 @@
|
||||
What: /sys/kernel/mm/numa/
|
||||
Date: June 2021
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Interface for NUMA
|
||||
|
||||
What: /sys/kernel/mm/numa/demotion_enabled
|
||||
Date: June 2021
|
||||
Contact: Linux memory management mailing list <linux-mm@kvack.org>
|
||||
Description: Enable/disable demoting pages during reclaim
|
||||
|
||||
Page migration during reclaim is intended for systems
|
||||
with tiered memory configurations. These systems have
|
||||
multiple types of memory with varied performance
|
||||
characteristics instead of plain NUMA systems where
|
||||
the same kind of memory is found at varied distances.
|
||||
Allowing page migration during reclaim enables these
|
||||
systems to migrate pages from fast tiers to slow tiers
|
||||
when the fast tier is under pressure. This migration
|
||||
is performed before swap. It may move data to a NUMA
|
||||
node that does not fall into the cpuset of the
|
||||
allocating process which might be construed to violate
|
||||
the guarantees of cpusets. This should not be enabled
|
||||
on systems which need strict cpuset location
|
||||
guarantees.
|
@ -1,7 +1,7 @@
|
||||
What: /sys/devices/platform/<platform>/tokens/*
|
||||
Date: November 2017
|
||||
KernelVersion: 4.15
|
||||
Contact: "Mario Limonciello" <mario.limonciello@dell.com>
|
||||
Contact: Dell.Client.Kernel@dell.com
|
||||
Description:
|
||||
A read-only description of Dell platform tokens
|
||||
available on the machine.
|
||||
|
@ -1,7 +1,7 @@
|
||||
What: /sys/devices/platform/<platform>/force_power
|
||||
Date: September 2017
|
||||
KernelVersion: 4.15
|
||||
Contact: "Mario Limonciello" <mario.limonciello@dell.com>
|
||||
Contact: "Mario Limonciello" <mario.limonciello@outlook.com>
|
||||
Description:
|
||||
Modify the platform force power state, influencing
|
||||
Thunderbolt controllers to turn on or off when no
|
||||
|
@ -295,7 +295,7 @@ Description:
|
||||
|
||||
What: /sys/power/resume_offset
|
||||
Date: April 2018
|
||||
Contact: Mario Limonciello <mario.limonciello@dell.com>
|
||||
Contact: Mario Limonciello <mario.limonciello@outlook.com>
|
||||
Description:
|
||||
This file is used for telling the kernel an offset into a disk
|
||||
to use when hibernating the system such as with a swap file.
|
||||
|
@ -43,6 +43,7 @@ entries corresponding to EPF driver will be created by the EPF core.
|
||||
.. <EPF Driver1>/
|
||||
... <EPF Device 11>/
|
||||
... <EPF Device 21>/
|
||||
... <EPF Device 31>/
|
||||
.. <EPF Driver2>/
|
||||
... <EPF Device 12>/
|
||||
... <EPF Device 22>/
|
||||
@ -68,6 +69,7 @@ created)
|
||||
... subsys_vendor_id
|
||||
... subsys_id
|
||||
... interrupt_pin
|
||||
... <Symlink EPF Device 31>/
|
||||
... primary/
|
||||
... <Symlink EPC Device1>/
|
||||
... secondary/
|
||||
@ -79,6 +81,13 @@ interface should be added in 'primary' directory and symlink of endpoint
|
||||
controller connected to secondary interface should be added in 'secondary'
|
||||
directory.
|
||||
|
||||
The <EPF Device> directory can have a list of symbolic links
|
||||
(<Symlink EPF Device 31>) to other <EPF Device>. These symbolic links should
|
||||
be created by the user to represent the virtual functions that are bound to
|
||||
the physical function. In the above directory structure <EPF Device 11> is a
|
||||
physical function and <EPF Device 31> is a virtual function. An EPF device once
|
||||
it's linked to another EPF device, cannot be linked to a EPC device.
|
||||
|
||||
EPC Device
|
||||
==========
|
||||
|
||||
@ -98,7 +107,8 @@ entries corresponding to EPC device will be created by the EPC core.
|
||||
|
||||
The <EPC Device> directory will have a list of symbolic links to
|
||||
<EPF Device>. These symbolic links should be created by the user to
|
||||
represent the functions present in the endpoint device.
|
||||
represent the functions present in the endpoint device. Only <EPF Device>
|
||||
that represents a physical function can be linked to a EPC device.
|
||||
|
||||
The <EPC Device> directory will also have a *start* field. Once
|
||||
"1" is written to this field, the endpoint device will be ready to
|
||||
|
@ -103,6 +103,7 @@ need pass only as many optional fields as necessary:
|
||||
- subvendor and subdevice fields default to PCI_ANY_ID (FFFFFFFF)
|
||||
- class and classmask fields default to 0
|
||||
- driver_data defaults to 0UL.
|
||||
- override_only field defaults to 0.
|
||||
|
||||
Note that driver_data must match the value used by any of the pci_device_id
|
||||
entries defined in the driver. This makes the driver_data field mandatory
|
||||
|
@ -30,22 +30,21 @@ following ASL code can be used::
|
||||
{
|
||||
Device (STAC)
|
||||
{
|
||||
Name (_ADR, Zero)
|
||||
Name (_HID, "BMA222E")
|
||||
Name (RBUF, ResourceTemplate ()
|
||||
{
|
||||
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
|
||||
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
|
||||
ResourceConsumer, ,)
|
||||
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
|
||||
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
|
||||
{ // Pin list
|
||||
0
|
||||
}
|
||||
})
|
||||
|
||||
Method (_CRS, 0, Serialized)
|
||||
{
|
||||
Name (RBUF, ResourceTemplate ()
|
||||
{
|
||||
I2cSerialBus (0x0018, ControllerInitiated, 0x00061A80,
|
||||
AddressingMode7Bit, "\\_SB.I2C6", 0x00,
|
||||
ResourceConsumer, ,)
|
||||
GpioInt (Edge, ActiveHigh, Exclusive, PullDown, 0x0000,
|
||||
"\\_SB.GPO2", 0x00, ResourceConsumer, , )
|
||||
{ // Pin list
|
||||
0
|
||||
}
|
||||
})
|
||||
Return (RBUF)
|
||||
}
|
||||
}
|
||||
@ -75,7 +74,7 @@ This option allows loading of user defined SSDTs from initrd and it is useful
|
||||
when the system does not support EFI or when there is not enough EFI storage.
|
||||
|
||||
It works in a similar way with initrd based ACPI tables override/upgrade: SSDT
|
||||
aml code must be placed in the first, uncompressed, initrd under the
|
||||
AML code must be placed in the first, uncompressed, initrd under the
|
||||
"kernel/firmware/acpi" path. Multiple files can be used and this will translate
|
||||
in loading multiple tables. Only SSDT and OEM tables are allowed. See
|
||||
initrd_table_override.txt for more details.
|
||||
@ -103,12 +102,14 @@ This is the preferred method, when EFI is supported on the platform, because it
|
||||
allows a persistent, OS independent way of storing the user defined SSDTs. There
|
||||
is also work underway to implement EFI support for loading user defined SSDTs
|
||||
and using this method will make it easier to convert to the EFI loading
|
||||
mechanism when that will arrive.
|
||||
mechanism when that will arrive. To enable it, the
|
||||
CONFIG_EFI_CUSTOM_SSDT_OVERLAYS shoyld be chosen to y.
|
||||
|
||||
In order to load SSDTs from an EFI variable the efivar_ssdt kernel command line
|
||||
parameter can be used. The argument for the option is the variable name to
|
||||
use. If there are multiple variables with the same name but with different
|
||||
vendor GUIDs, all of them will be loaded.
|
||||
In order to load SSDTs from an EFI variable the ``"efivar_ssdt=..."`` kernel
|
||||
command line parameter can be used (the name has a limitation of 16 characters).
|
||||
The argument for the option is the variable name to use. If there are multiple
|
||||
variables with the same name but with different vendor GUIDs, all of them will
|
||||
be loaded.
|
||||
|
||||
In order to store the AML code in an EFI variable the efivarfs filesystem can be
|
||||
used. It is enabled and mounted by default in /sys/firmware/efi/efivars in all
|
||||
@ -127,7 +128,7 @@ variable with the content from a given file::
|
||||
|
||||
#!/bin/sh -e
|
||||
|
||||
while ! [ -z "$1" ]; do
|
||||
while [ -n "$1" ]; do
|
||||
case "$1" in
|
||||
"-f") filename="$2"; shift;;
|
||||
"-g") guid="$2"; shift;;
|
||||
@ -167,14 +168,14 @@ variable with the content from a given file::
|
||||
Loading ACPI SSDTs from configfs
|
||||
================================
|
||||
|
||||
This option allows loading of user defined SSDTs from userspace via the configfs
|
||||
This option allows loading of user defined SSDTs from user space via the configfs
|
||||
interface. The CONFIG_ACPI_CONFIGFS option must be select and configfs must be
|
||||
mounted. In the following examples, we assume that configfs has been mounted in
|
||||
/config.
|
||||
/sys/kernel/config.
|
||||
|
||||
New tables can be loading by creating new directories in /config/acpi/table/ and
|
||||
writing the SSDT aml code in the aml attribute::
|
||||
New tables can be loading by creating new directories in /sys/kernel/config/acpi/table
|
||||
and writing the SSDT AML code in the aml attribute::
|
||||
|
||||
cd /config/acpi/table
|
||||
cd /sys/kernel/config/acpi/table
|
||||
mkdir my_ssdt
|
||||
cat ~/ssdt.aml > my_ssdt/aml
|
||||
|
@ -178,7 +178,7 @@ update the boot loader and the kernel image itself as long as the boot
|
||||
loader passes the correct initrd file size. If by any chance, the boot
|
||||
loader passes a longer size, the kernel fails to find the bootconfig data.
|
||||
|
||||
To do this operation, Linux kernel provides "bootconfig" command under
|
||||
To do this operation, Linux kernel provides ``bootconfig`` command under
|
||||
tools/bootconfig, which allows admin to apply or delete the config file
|
||||
to/from initrd image. You can build it by the following command::
|
||||
|
||||
@ -196,6 +196,43 @@ To remove the config from the image, you can use -d option as below::
|
||||
Then add "bootconfig" on the normal kernel command line to tell the
|
||||
kernel to look for the bootconfig at the end of the initrd file.
|
||||
|
||||
|
||||
Kernel parameters via Boot Config
|
||||
=================================
|
||||
|
||||
In addition to the kernel command line, the boot config can be used for
|
||||
passing the kernel parameters. All the key-value pairs under ``kernel``
|
||||
key will be passed to kernel cmdline directly. Moreover, the key-value
|
||||
pairs under ``init`` will be passed to init process via the cmdline.
|
||||
The parameters are concatinated with user-given kernel cmdline string
|
||||
as the following order, so that the command line parameter can override
|
||||
bootconfig parameters (this depends on how the subsystem handles parameters
|
||||
but in general, earlier parameter will be overwritten by later one.)::
|
||||
|
||||
[bootconfig params][cmdline params] -- [bootconfig init params][cmdline init params]
|
||||
|
||||
Here is an example of the bootconfig file for kernel/init parameters.::
|
||||
|
||||
kernel {
|
||||
root = 01234567-89ab-cdef-0123-456789abcd
|
||||
}
|
||||
init {
|
||||
splash
|
||||
}
|
||||
|
||||
This will be copied into the kernel cmdline string as the following::
|
||||
|
||||
root="01234567-89ab-cdef-0123-456789abcd" -- splash
|
||||
|
||||
If user gives some other command line like,::
|
||||
|
||||
ro bootconfig -- quiet
|
||||
|
||||
The final kernel cmdline will be the following::
|
||||
|
||||
root="01234567-89ab-cdef-0123-456789abcd" ro bootconfig -- splash quiet
|
||||
|
||||
|
||||
Config File Limitation
|
||||
======================
|
||||
|
||||
|
@ -58,9 +58,9 @@ source for the output is in brackets ("[]").
|
||||
[NR_CPUS-1]
|
||||
|
||||
offline: CPUs that are not online because they have been
|
||||
HOTPLUGGED off (see cpu-hotplug.txt) or exceed the limit
|
||||
of CPUs allowed by the kernel configuration (kernel_max
|
||||
above). [~cpu_online_mask + cpus >= NR_CPUS]
|
||||
HOTPLUGGED off or exceed the limit of CPUs allowed by the
|
||||
kernel configuration (kernel_max above).
|
||||
[~cpu_online_mask + cpus >= NR_CPUS]
|
||||
|
||||
online: CPUs that are online and being scheduled [cpu_online_mask]
|
||||
|
||||
@ -96,5 +96,5 @@ online.)::
|
||||
possible: 0-127
|
||||
present: 0-3
|
||||
|
||||
See cpu-hotplug.txt for the possible_cpus=NUM kernel start parameter
|
||||
as well as more information on the various cpumasks.
|
||||
See Documentation/core-api/cpu_hotplug.rst for the possible_cpus=NUM
|
||||
kernel start parameter as well as more information on the various cpumasks.
|
||||
|
@ -2993,10 +2993,10 @@
|
||||
65 = /dev/infiniband/issm1 Second InfiniBand IsSM device
|
||||
...
|
||||
127 = /dev/infiniband/issm63 63rd InfiniBand IsSM device
|
||||
128 = /dev/infiniband/uverbs0 First InfiniBand verbs device
|
||||
129 = /dev/infiniband/uverbs1 Second InfiniBand verbs device
|
||||
192 = /dev/infiniband/uverbs0 First InfiniBand verbs device
|
||||
193 = /dev/infiniband/uverbs1 Second InfiniBand verbs device
|
||||
...
|
||||
159 = /dev/infiniband/uverbs31 31st InfiniBand verbs device
|
||||
223 = /dev/infiniband/uverbs31 31st InfiniBand verbs device
|
||||
|
||||
232 char Biometric Devices
|
||||
0 = /dev/biometric/sensor0/fingerprint first fingerprint sensor on first device
|
||||
|
@ -181,10 +181,12 @@ Open cross-HT issues that core scheduling does not solve
|
||||
--------------------------------------------------------
|
||||
1. For MDS
|
||||
~~~~~~~~~~
|
||||
Core scheduling cannot protect against MDS attacks between an HT running in
|
||||
user mode and another running in kernel mode. Even though both HTs run tasks
|
||||
which trust each other, kernel memory is still considered untrusted. Such
|
||||
attacks are possible for any combination of sibling CPU modes (host or guest mode).
|
||||
Core scheduling cannot protect against MDS attacks between the siblings
|
||||
running in user mode and the others running in kernel mode. Even though all
|
||||
siblings run tasks which trust each other, when the kernel is executing
|
||||
code on behalf of a task, it cannot trust the code running in the
|
||||
sibling. Such attacks are possible for any combination of sibling CPU modes
|
||||
(host or guest mode).
|
||||
|
||||
2. For L1TF
|
||||
~~~~~~~~~~~
|
||||
|
@ -301,10 +301,7 @@
|
||||
amd_iommu= [HW,X86-64]
|
||||
Pass parameters to the AMD IOMMU driver in the system.
|
||||
Possible values are:
|
||||
fullflush - enable flushing of IO/TLB entries when
|
||||
they are unmapped. Otherwise they are
|
||||
flushed before they will be reused, which
|
||||
is a lot of faster
|
||||
fullflush - Deprecated, equivalent to iommu.strict=1
|
||||
off - do not initialize any AMD IOMMU found in
|
||||
the system
|
||||
force_isolation - Force device isolation for all
|
||||
@ -1761,6 +1758,11 @@
|
||||
support for the idxd driver. By default it is set to
|
||||
true (1).
|
||||
|
||||
idxd.tc_override= [HW]
|
||||
Format: <bool>
|
||||
Allow override of default traffic class configuration
|
||||
for the device. By default it is set to false (0).
|
||||
|
||||
ieee754= [MIPS] Select IEEE Std 754 conformance mode
|
||||
Format: { strict | legacy | 2008 | relaxed }
|
||||
Default: strict
|
||||
@ -1958,18 +1960,17 @@
|
||||
this case, gfx device will use physical address for
|
||||
DMA.
|
||||
strict [Default Off]
|
||||
With this option on every unmap_single operation will
|
||||
result in a hardware IOTLB flush operation as opposed
|
||||
to batching them for performance.
|
||||
Deprecated, equivalent to iommu.strict=1.
|
||||
sp_off [Default Off]
|
||||
By default, super page will be supported if Intel IOMMU
|
||||
has the capability. With this option, super page will
|
||||
not be supported.
|
||||
sm_on [Default Off]
|
||||
By default, scalable mode will be disabled even if the
|
||||
hardware advertises that it has support for the scalable
|
||||
mode translation. With this option set, scalable mode
|
||||
will be used on hardware which claims to support it.
|
||||
sm_on
|
||||
Enable the Intel IOMMU scalable mode if the hardware
|
||||
advertises that it has support for the scalable mode
|
||||
translation.
|
||||
sm_off
|
||||
Disallow use of the Intel IOMMU scalable mode.
|
||||
tboot_noforce [Default Off]
|
||||
Do not force the Intel IOMMU enabled under tboot.
|
||||
By default, tboot will force Intel IOMMU on, which
|
||||
@ -2061,13 +2062,12 @@
|
||||
throughput at the cost of reduced device isolation.
|
||||
Will fall back to strict mode if not supported by
|
||||
the relevant IOMMU driver.
|
||||
1 - Strict mode (default).
|
||||
1 - Strict mode.
|
||||
DMA unmap operations invalidate IOMMU hardware TLBs
|
||||
synchronously.
|
||||
Note: on x86, the default behaviour depends on the
|
||||
equivalent driver-specific parameters, but a strict
|
||||
mode explicitly specified by either method takes
|
||||
precedence.
|
||||
unset - Use value of CONFIG_IOMMU_DEFAULT_DMA_{LAZY,STRICT}.
|
||||
Note: on x86, strict mode specified via one of the
|
||||
legacy driver-specific options takes precedence.
|
||||
|
||||
iommu.passthrough=
|
||||
[ARM64, X86] Configure DMA to bypass the IOMMU by default.
|
||||
|
@ -13,10 +13,8 @@ Hotkeys
|
||||
The following FN keys are ignored by the kernel without this driver:
|
||||
|
||||
- FN-F1 (LG control panel) - Generates F15
|
||||
- FN-F5 (Touchpad toggle) - Generates F13
|
||||
- FN-F5 (Touchpad toggle) - Generates F21
|
||||
- FN-F6 (Airplane mode) - Generates RFKILL
|
||||
- FN-F8 (Keyboard backlight) - Generates F16.
|
||||
This key also changes keyboard backlight mode.
|
||||
- FN-F9 (Reader mode) - Generates F14
|
||||
|
||||
The rest of the FN keys work without a need for a special driver.
|
||||
|
15
Documentation/admin-guide/mm/damon/index.rst
Normal file
15
Documentation/admin-guide/mm/damon/index.rst
Normal file
@ -0,0 +1,15 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
========================
|
||||
Monitoring Data Accesses
|
||||
========================
|
||||
|
||||
:doc:`DAMON </vm/damon/index>` allows light-weight data access monitoring.
|
||||
Using DAMON, users can analyze the memory access patterns of their systems and
|
||||
optimize those.
|
||||
|
||||
.. toctree::
|
||||
:maxdepth: 2
|
||||
|
||||
start
|
||||
usage
|
114
Documentation/admin-guide/mm/damon/start.rst
Normal file
114
Documentation/admin-guide/mm/damon/start.rst
Normal file
@ -0,0 +1,114 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============
|
||||
Getting Started
|
||||
===============
|
||||
|
||||
This document briefly describes how you can use DAMON by demonstrating its
|
||||
default user space tool. Please note that this document describes only a part
|
||||
of its features for brevity. Please refer to :doc:`usage` for more details.
|
||||
|
||||
|
||||
TL; DR
|
||||
======
|
||||
|
||||
Follow the commands below to monitor and visualize the memory access pattern of
|
||||
your workload. ::
|
||||
|
||||
# # build the kernel with CONFIG_DAMON_*=y, install it, and reboot
|
||||
# mount -t debugfs none /sys/kernel/debug/
|
||||
# git clone https://github.com/awslabs/damo
|
||||
# ./damo/damo record $(pidof <your workload>)
|
||||
# ./damo/damo report heat --plot_ascii
|
||||
|
||||
The final command draws the access heatmap of ``<your workload>``. The heatmap
|
||||
shows which memory region (x-axis) is accessed when (y-axis) and how frequently
|
||||
(number; the higher the more accesses have been observed). ::
|
||||
|
||||
111111111111111111111111111111111111111111111111111111110000
|
||||
111121111111111111111111111111211111111111111111111111110000
|
||||
000000000000000000000000000000000000000000000000001555552000
|
||||
000000000000000000000000000000000000000000000222223555552000
|
||||
000000000000000000000000000000000000000011111677775000000000
|
||||
000000000000000000000000000000000000000488888000000000000000
|
||||
000000000000000000000000000000000177888400000000000000000000
|
||||
000000000000000000000000000046666522222100000000000000000000
|
||||
000000000000000000000014444344444300000000000000000000000000
|
||||
000000000000000002222245555510000000000000000000000000000000
|
||||
# access_frequency: 0 1 2 3 4 5 6 7 8 9
|
||||
# x-axis: space (140286319947776-140286426374096: 101.496 MiB)
|
||||
# y-axis: time (605442256436361-605479951866441: 37.695430s)
|
||||
# resolution: 60x10 (1.692 MiB and 3.770s for each character)
|
||||
|
||||
|
||||
Prerequisites
|
||||
=============
|
||||
|
||||
Kernel
|
||||
------
|
||||
|
||||
You should first ensure your system is running on a kernel built with
|
||||
``CONFIG_DAMON_*=y``.
|
||||
|
||||
|
||||
User Space Tool
|
||||
---------------
|
||||
|
||||
For the demonstration, we will use the default user space tool for DAMON,
|
||||
called DAMON Operator (DAMO). It is available at
|
||||
https://github.com/awslabs/damo. The examples below assume that ``damo`` is on
|
||||
your ``$PATH``. It's not mandatory, though.
|
||||
|
||||
Because DAMO is using the debugfs interface (refer to :doc:`usage` for the
|
||||
detail) of DAMON, you should ensure debugfs is mounted. Mount it manually as
|
||||
below::
|
||||
|
||||
# mount -t debugfs none /sys/kernel/debug/
|
||||
|
||||
or append the following line to your ``/etc/fstab`` file so that your system
|
||||
can automatically mount debugfs upon booting::
|
||||
|
||||
debugfs /sys/kernel/debug debugfs defaults 0 0
|
||||
|
||||
|
||||
Recording Data Access Patterns
|
||||
==============================
|
||||
|
||||
The commands below record the memory access patterns of a program and save the
|
||||
monitoring results to a file. ::
|
||||
|
||||
$ git clone https://github.com/sjp38/masim
|
||||
$ cd masim; make; ./masim ./configs/zigzag.cfg &
|
||||
$ sudo damo record -o damon.data $(pidof masim)
|
||||
|
||||
The first two lines of the commands download an artificial memory access
|
||||
generator program and run it in the background. The generator will repeatedly
|
||||
access two 100 MiB sized memory regions one by one. You can substitute this
|
||||
with your real workload. The last line asks ``damo`` to record the access
|
||||
pattern in the ``damon.data`` file.
|
||||
|
||||
|
||||
Visualizing Recorded Patterns
|
||||
=============================
|
||||
|
||||
The following three commands visualize the recorded access patterns and save
|
||||
the results as separate image files. ::
|
||||
|
||||
$ damo report heats --heatmap access_pattern_heatmap.png
|
||||
$ damo report wss --range 0 101 1 --plot wss_dist.png
|
||||
$ damo report wss --range 0 101 1 --sortby time --plot wss_chron_change.png
|
||||
|
||||
- ``access_pattern_heatmap.png`` will visualize the data access pattern in a
|
||||
heatmap, showing which memory region (y-axis) got accessed when (x-axis)
|
||||
and how frequently (color).
|
||||
- ``wss_dist.png`` will show the distribution of the working set size.
|
||||
- ``wss_chron_change.png`` will show how the working set size has
|
||||
chronologically changed.
|
||||
|
||||
You can view the visualizations of this example workload at [1]_.
|
||||
Visualizations of other realistic workloads are available at [2]_ [3]_ [4]_.
|
||||
|
||||
.. [1] https://damonitor.github.io/doc/html/v17/admin-guide/mm/damon/start.html#visualizing-recorded-patterns
|
||||
.. [2] https://damonitor.github.io/test/result/visual/latest/rec.heatmap.1.png.html
|
||||
.. [3] https://damonitor.github.io/test/result/visual/latest/rec.wss_sz.png.html
|
||||
.. [4] https://damonitor.github.io/test/result/visual/latest/rec.wss_time.png.html
|
112
Documentation/admin-guide/mm/damon/usage.rst
Normal file
112
Documentation/admin-guide/mm/damon/usage.rst
Normal file
@ -0,0 +1,112 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
===============
|
||||
Detailed Usages
|
||||
===============
|
||||
|
||||
DAMON provides below three interfaces for different users.
|
||||
|
||||
- *DAMON user space tool.*
|
||||
This is for privileged people such as system administrators who want a
|
||||
just-working human-friendly interface. Using this, users can use the DAMON’s
|
||||
major features in a human-friendly way. It may not be highly tuned for
|
||||
special cases, though. It supports only virtual address spaces monitoring.
|
||||
- *debugfs interface.*
|
||||
This is for privileged user space programmers who want more optimized use of
|
||||
DAMON. Using this, users can use DAMON’s major features by reading
|
||||
from and writing to special debugfs files. Therefore, you can write and use
|
||||
your personalized DAMON debugfs wrapper programs that reads/writes the
|
||||
debugfs files instead of you. The DAMON user space tool is also a reference
|
||||
implementation of such programs. It supports only virtual address spaces
|
||||
monitoring.
|
||||
- *Kernel Space Programming Interface.*
|
||||
This is for kernel space programmers. Using this, users can utilize every
|
||||
feature of DAMON most flexibly and efficiently by writing kernel space
|
||||
DAMON application programs for you. You can even extend DAMON for various
|
||||
address spaces.
|
||||
|
||||
Nevertheless, you could write your own user space tool using the debugfs
|
||||
interface. A reference implementation is available at
|
||||
https://github.com/awslabs/damo. If you are a kernel programmer, you could
|
||||
refer to :doc:`/vm/damon/api` for the kernel space programming interface. For
|
||||
the reason, this document describes only the debugfs interface
|
||||
|
||||
debugfs Interface
|
||||
=================
|
||||
|
||||
DAMON exports three files, ``attrs``, ``target_ids``, and ``monitor_on`` under
|
||||
its debugfs directory, ``<debugfs>/damon/``.
|
||||
|
||||
|
||||
Attributes
|
||||
----------
|
||||
|
||||
Users can get and set the ``sampling interval``, ``aggregation interval``,
|
||||
``regions update interval``, and min/max number of monitoring target regions by
|
||||
reading from and writing to the ``attrs`` file. To know about the monitoring
|
||||
attributes in detail, please refer to the :doc:`/vm/damon/design`. For
|
||||
example, below commands set those values to 5 ms, 100 ms, 1,000 ms, 10 and
|
||||
1000, and then check it again::
|
||||
|
||||
# cd <debugfs>/damon
|
||||
# echo 5000 100000 1000000 10 1000 > attrs
|
||||
# cat attrs
|
||||
5000 100000 1000000 10 1000
|
||||
|
||||
|
||||
Target IDs
|
||||
----------
|
||||
|
||||
Some types of address spaces supports multiple monitoring target. For example,
|
||||
the virtual memory address spaces monitoring can have multiple processes as the
|
||||
monitoring targets. Users can set the targets by writing relevant id values of
|
||||
the targets to, and get the ids of the current targets by reading from the
|
||||
``target_ids`` file. In case of the virtual address spaces monitoring, the
|
||||
values should be pids of the monitoring target processes. For example, below
|
||||
commands set processes having pids 42 and 4242 as the monitoring targets and
|
||||
check it again::
|
||||
|
||||
# cd <debugfs>/damon
|
||||
# echo 42 4242 > target_ids
|
||||
# cat target_ids
|
||||
42 4242
|
||||
|
||||
Note that setting the target ids doesn't start the monitoring.
|
||||
|
||||
|
||||
Turning On/Off
|
||||
--------------
|
||||
|
||||
Setting the files as described above doesn't incur effect unless you explicitly
|
||||
start the monitoring. You can start, stop, and check the current status of the
|
||||
monitoring by writing to and reading from the ``monitor_on`` file. Writing
|
||||
``on`` to the file starts the monitoring of the targets with the attributes.
|
||||
Writing ``off`` to the file stops those. DAMON also stops if every target
|
||||
process is terminated. Below example commands turn on, off, and check the
|
||||
status of DAMON::
|
||||
|
||||
# cd <debugfs>/damon
|
||||
# echo on > monitor_on
|
||||
# echo off > monitor_on
|
||||
# cat monitor_on
|
||||
off
|
||||
|
||||
Please note that you cannot write to the above-mentioned debugfs files while
|
||||
the monitoring is turned on. If you write to the files while DAMON is running,
|
||||
an error code such as ``-EBUSY`` will be returned.
|
||||
|
||||
|
||||
Tracepoint for Monitoring Results
|
||||
=================================
|
||||
|
||||
DAMON provides the monitoring results via a tracepoint,
|
||||
``damon:damon_aggregated``. While the monitoring is turned on, you could
|
||||
record the tracepoint events and show results using tracepoint supporting tools
|
||||
like ``perf``. For example::
|
||||
|
||||
# echo on > monitor_on
|
||||
# perf record -e damon:damon_aggregated &
|
||||
# sleep 5
|
||||
# kill 9 $(pidof perf)
|
||||
# echo off > monitor_on
|
||||
# perf script
|
@ -27,6 +27,7 @@ the Linux memory management.
|
||||
|
||||
concepts
|
||||
cma_debugfs
|
||||
damon/index
|
||||
hugetlbpage
|
||||
idle_page_tracking
|
||||
ksm
|
||||
|
@ -1,466 +1,576 @@
|
||||
.. _admin_guide_memory_hotplug:
|
||||
|
||||
==============
|
||||
Memory Hotplug
|
||||
==============
|
||||
==================
|
||||
Memory Hot(Un)Plug
|
||||
==================
|
||||
|
||||
:Created: Jul 28 2007
|
||||
:Updated: Add some details about locking internals: Aug 20 2018
|
||||
|
||||
This document is about memory hotplug including how-to-use and current status.
|
||||
Because Memory Hotplug is still under development, contents of this text will
|
||||
be changed often.
|
||||
This document describes generic Linux support for memory hot(un)plug with
|
||||
a focus on System RAM, including ZONE_MOVABLE support.
|
||||
|
||||
.. contents:: :local:
|
||||
|
||||
.. note::
|
||||
|
||||
(1) x86_64's has special implementation for memory hotplug.
|
||||
This text does not describe it.
|
||||
(2) This text assumes that sysfs is mounted at ``/sys``.
|
||||
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
Purpose of memory hotplug
|
||||
-------------------------
|
||||
Memory hot(un)plug allows for increasing and decreasing the size of physical
|
||||
memory available to a machine at runtime. In the simplest case, it consists of
|
||||
physically plugging or unplugging a DIMM at runtime, coordinated with the
|
||||
operating system.
|
||||
|
||||
Memory Hotplug allows users to increase/decrease the amount of memory.
|
||||
Generally, there are two purposes.
|
||||
Memory hot(un)plug is used for various purposes:
|
||||
|
||||
(A) For changing the amount of memory.
|
||||
This is to allow a feature like capacity on demand.
|
||||
(B) For installing/removing DIMMs or NUMA-nodes physically.
|
||||
This is to exchange DIMMs/NUMA-nodes, reduce power consumption, etc.
|
||||
- The physical memory available to a machine can be adjusted at runtime, up- or
|
||||
downgrading the memory capacity. This dynamic memory resizing, sometimes
|
||||
referred to as "capacity on demand", is frequently used with virtual machines
|
||||
and logical partitions.
|
||||
|
||||
(A) is required by highly virtualized environments and (B) is required by
|
||||
hardware which supports memory power management.
|
||||
- Replacing hardware, such as DIMMs or whole NUMA nodes, without downtime. One
|
||||
example is replacing failing memory modules.
|
||||
|
||||
Linux memory hotplug is designed for both purpose.
|
||||
- Reducing energy consumption either by physically unplugging memory modules or
|
||||
by logically unplugging (parts of) memory modules from Linux.
|
||||
|
||||
Phases of memory hotplug
|
||||
------------------------
|
||||
Further, the basic memory hot(un)plug infrastructure in Linux is nowadays also
|
||||
used to expose persistent memory, other performance-differentiated memory and
|
||||
reserved memory regions as ordinary system RAM to Linux.
|
||||
|
||||
There are 2 phases in Memory Hotplug:
|
||||
Linux only supports memory hot(un)plug on selected 64 bit architectures, such as
|
||||
x86_64, arm64, ppc64, s390x and ia64.
|
||||
|
||||
1) Physical Memory Hotplug phase
|
||||
2) Logical Memory Hotplug phase.
|
||||
Memory Hot(Un)Plug Granularity
|
||||
------------------------------
|
||||
|
||||
The First phase is to communicate hardware/firmware and make/erase
|
||||
environment for hotplugged memory. Basically, this phase is necessary
|
||||
for the purpose (B), but this is good phase for communication between
|
||||
highly virtualized environments too.
|
||||
|
||||
When memory is hotplugged, the kernel recognizes new memory, makes new memory
|
||||
management tables, and makes sysfs files for new memory's operation.
|
||||
|
||||
If firmware supports notification of connection of new memory to OS,
|
||||
this phase is triggered automatically. ACPI can notify this event. If not,
|
||||
"probe" operation by system administration is used instead.
|
||||
(see :ref:`memory_hotplug_physical_mem`).
|
||||
|
||||
Logical Memory Hotplug phase is to change memory state into
|
||||
available/unavailable for users. Amount of memory from user's view is
|
||||
changed by this phase. The kernel makes all memory in it as free pages
|
||||
when a memory range is available.
|
||||
|
||||
In this document, this phase is described as online/offline.
|
||||
|
||||
Logical Memory Hotplug phase is triggered by write of sysfs file by system
|
||||
administrator. For the hot-add case, it must be executed after Physical Hotplug
|
||||
phase by hand.
|
||||
(However, if you writes udev's hotplug scripts for memory hotplug, these
|
||||
phases can be execute in seamless way.)
|
||||
|
||||
Unit of Memory online/offline operation
|
||||
---------------------------------------
|
||||
|
||||
Memory hotplug uses SPARSEMEM memory model which allows memory to be divided
|
||||
into chunks of the same size. These chunks are called "sections". The size of
|
||||
a memory section is architecture dependent. For example, power uses 16MiB, ia64
|
||||
uses 1GiB.
|
||||
Memory hot(un)plug in Linux uses the SPARSEMEM memory model, which divides the
|
||||
physical memory address space into chunks of the same size: memory sections. The
|
||||
size of a memory section is architecture dependent. For example, x86_64 uses
|
||||
128 MiB and ppc64 uses 16 MiB.
|
||||
|
||||
Memory sections are combined into chunks referred to as "memory blocks". The
|
||||
size of a memory block is architecture dependent and represents the logical
|
||||
unit upon which memory online/offline operations are to be performed. The
|
||||
default size of a memory block is the same as memory section size unless an
|
||||
architecture specifies otherwise. (see :ref:`memory_hotplug_sysfs_files`.)
|
||||
size of a memory block is architecture dependent and corresponds to the smallest
|
||||
granularity that can be hot(un)plugged. The default size of a memory block is
|
||||
the same as memory section size, unless an architecture specifies otherwise.
|
||||
|
||||
To determine the size (in bytes) of a memory block please read this file::
|
||||
All memory blocks have the same size.
|
||||
|
||||
/sys/devices/system/memory/block_size_bytes
|
||||
Phases of Memory Hotplug
|
||||
------------------------
|
||||
|
||||
Kernel Configuration
|
||||
====================
|
||||
Memory hotplug consists of two phases:
|
||||
|
||||
To use memory hotplug feature, kernel must be compiled with following
|
||||
config options.
|
||||
(1) Adding the memory to Linux
|
||||
(2) Onlining memory blocks
|
||||
|
||||
- For all memory hotplug:
|
||||
- Memory model -> Sparse Memory (``CONFIG_SPARSEMEM``)
|
||||
- Allow for memory hot-add (``CONFIG_MEMORY_HOTPLUG``)
|
||||
In the first phase, metadata, such as the memory map ("memmap") and page tables
|
||||
for the direct mapping, is allocated and initialized, and memory blocks are
|
||||
created; the latter also creates sysfs files for managing newly created memory
|
||||
blocks.
|
||||
|
||||
- To enable memory removal, the following are also necessary:
|
||||
- Allow for memory hot remove (``CONFIG_MEMORY_HOTREMOVE``)
|
||||
- Page Migration (``CONFIG_MIGRATION``)
|
||||
In the second phase, added memory is exposed to the page allocator. After this
|
||||
phase, the memory is visible in memory statistics, such as free and total
|
||||
memory, of the system.
|
||||
|
||||
- For ACPI memory hotplug, the following are also necessary:
|
||||
- Memory hotplug (under ACPI Support menu) (``CONFIG_ACPI_HOTPLUG_MEMORY``)
|
||||
- This option can be kernel module.
|
||||
Phases of Memory Hotunplug
|
||||
--------------------------
|
||||
|
||||
- As a related configuration, if your box has a feature of NUMA-node hotplug
|
||||
via ACPI, then this option is necessary too.
|
||||
Memory hotunplug consists of two phases:
|
||||
|
||||
- ACPI0004,PNP0A05 and PNP0A06 Container Driver (under ACPI Support menu)
|
||||
(``CONFIG_ACPI_CONTAINER``).
|
||||
(1) Offlining memory blocks
|
||||
(2) Removing the memory from Linux
|
||||
|
||||
This option can be kernel module too.
|
||||
In the fist phase, memory is "hidden" from the page allocator again, for
|
||||
example, by migrating busy memory to other memory locations and removing all
|
||||
relevant free pages from the page allocator After this phase, the memory is no
|
||||
longer visible in memory statistics of the system.
|
||||
|
||||
In the second phase, the memory blocks are removed and metadata is freed.
|
||||
|
||||
.. _memory_hotplug_sysfs_files:
|
||||
Memory Hotplug Notifications
|
||||
============================
|
||||
|
||||
sysfs files for memory hotplug
|
||||
There are various ways how Linux is notified about memory hotplug events such
|
||||
that it can start adding hotplugged memory. This description is limited to
|
||||
systems that support ACPI; mechanisms specific to other firmware interfaces or
|
||||
virtual machines are not described.
|
||||
|
||||
ACPI Notifications
|
||||
------------------
|
||||
|
||||
Platforms that support ACPI, such as x86_64, can support memory hotplug
|
||||
notifications via ACPI.
|
||||
|
||||
In general, a firmware supporting memory hotplug defines a memory class object
|
||||
HID "PNP0C80". When notified about hotplug of a new memory device, the ACPI
|
||||
driver will hotplug the memory to Linux.
|
||||
|
||||
If the firmware supports hotplug of NUMA nodes, it defines an object _HID
|
||||
"ACPI0004", "PNP0A05", or "PNP0A06". When notified about an hotplug event, all
|
||||
assigned memory devices are added to Linux by the ACPI driver.
|
||||
|
||||
Similarly, Linux can be notified about requests to hotunplug a memory device or
|
||||
a NUMA node via ACPI. The ACPI driver will try offlining all relevant memory
|
||||
blocks, and, if successful, hotunplug the memory from Linux.
|
||||
|
||||
Manual Probing
|
||||
--------------
|
||||
|
||||
On some architectures, the firmware may not be able to notify the operating
|
||||
system about a memory hotplug event. Instead, the memory has to be manually
|
||||
probed from user space.
|
||||
|
||||
The probe interface is located at::
|
||||
|
||||
/sys/devices/system/memory/probe
|
||||
|
||||
Only complete memory blocks can be probed. Individual memory blocks are probed
|
||||
by providing the physical start address of the memory block::
|
||||
|
||||
% echo addr > /sys/devices/system/memory/probe
|
||||
|
||||
Which results in a memory block for the range [addr, addr + memory_block_size)
|
||||
being created.
|
||||
|
||||
.. note::
|
||||
|
||||
Using the probe interface is discouraged as it is easy to crash the kernel,
|
||||
because Linux cannot validate user input; this interface might be removed in
|
||||
the future.
|
||||
|
||||
Onlining and Offlining Memory Blocks
|
||||
====================================
|
||||
|
||||
After a memory block has been created, Linux has to be instructed to actually
|
||||
make use of that memory: the memory block has to be "online".
|
||||
|
||||
Before a memory block can be removed, Linux has to stop using any memory part of
|
||||
the memory block: the memory block has to be "offlined".
|
||||
|
||||
The Linux kernel can be configured to automatically online added memory blocks
|
||||
and drivers automatically trigger offlining of memory blocks when trying
|
||||
hotunplug of memory. Memory blocks can only be removed once offlining succeeded
|
||||
and drivers may trigger offlining of memory blocks when attempting hotunplug of
|
||||
memory.
|
||||
|
||||
Onlining Memory Blocks Manually
|
||||
-------------------------------
|
||||
|
||||
If auto-onlining of memory blocks isn't enabled, user-space has to manually
|
||||
trigger onlining of memory blocks. Often, udev rules are used to automate this
|
||||
task in user space.
|
||||
|
||||
Onlining of a memory block can be triggered via::
|
||||
|
||||
% echo online > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
Or alternatively::
|
||||
|
||||
% echo 1 > /sys/devices/system/memory/memoryXXX/online
|
||||
|
||||
The kernel will select the target zone automatically, usually defaulting to
|
||||
``ZONE_NORMAL`` unless ``movablecore=1`` has been specified on the kernel
|
||||
command line or if the memory block would intersect the ZONE_MOVABLE already.
|
||||
|
||||
One can explicitly request to associate an offline memory block with
|
||||
ZONE_MOVABLE by::
|
||||
|
||||
% echo online_movable > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
Or one can explicitly request a kernel zone (usually ZONE_NORMAL) by::
|
||||
|
||||
% echo online_kernel > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
In any case, if onlining succeeds, the state of the memory block is changed to
|
||||
be "online". If it fails, the state of the memory block will remain unchanged
|
||||
and the above commands will fail.
|
||||
|
||||
Onlining Memory Blocks Automatically
|
||||
------------------------------------
|
||||
|
||||
The kernel can be configured to try auto-onlining of newly added memory blocks.
|
||||
If this feature is disabled, the memory blocks will stay offline until
|
||||
explicitly onlined from user space.
|
||||
|
||||
The configured auto-online behavior can be observed via::
|
||||
|
||||
% cat /sys/devices/system/memory/auto_online_blocks
|
||||
|
||||
Auto-onlining can be enabled by writing ``online``, ``online_kernel`` or
|
||||
``online_movable`` to that file, like::
|
||||
|
||||
% echo online > /sys/devices/system/memory/auto_online_blocks
|
||||
|
||||
Modifying the auto-online behavior will only affect all subsequently added
|
||||
memory blocks only.
|
||||
|
||||
.. note::
|
||||
|
||||
In corner cases, auto-onlining can fail. The kernel won't retry. Note that
|
||||
auto-onlining is not expected to fail in default configurations.
|
||||
|
||||
.. note::
|
||||
|
||||
DLPAR on ppc64 ignores the ``offline`` setting and will still online added
|
||||
memory blocks; if onlining fails, memory blocks are removed again.
|
||||
|
||||
Offlining Memory Blocks
|
||||
-----------------------
|
||||
|
||||
In the current implementation, Linux's memory offlining will try migrating all
|
||||
movable pages off the affected memory block. As most kernel allocations, such as
|
||||
page tables, are unmovable, page migration can fail and, therefore, inhibit
|
||||
memory offlining from succeeding.
|
||||
|
||||
Having the memory provided by memory block managed by ZONE_MOVABLE significantly
|
||||
increases memory offlining reliability; still, memory offlining can fail in
|
||||
some corner cases.
|
||||
|
||||
Further, memory offlining might retry for a long time (or even forever), until
|
||||
aborted by the user.
|
||||
|
||||
Offlining of a memory block can be triggered via::
|
||||
|
||||
% echo offline > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
Or alternatively::
|
||||
|
||||
% echo 0 > /sys/devices/system/memory/memoryXXX/online
|
||||
|
||||
If offlining succeeds, the state of the memory block is changed to be "offline".
|
||||
If it fails, the state of the memory block will remain unchanged and the above
|
||||
commands will fail, for example, via::
|
||||
|
||||
bash: echo: write error: Device or resource busy
|
||||
|
||||
or via::
|
||||
|
||||
bash: echo: write error: Invalid argument
|
||||
|
||||
Observing the State of Memory Blocks
|
||||
------------------------------------
|
||||
|
||||
The state (online/offline/going-offline) of a memory block can be observed
|
||||
either via::
|
||||
|
||||
% cat /sys/device/system/memory/memoryXXX/state
|
||||
|
||||
Or alternatively (1/0) via::
|
||||
|
||||
% cat /sys/device/system/memory/memoryXXX/online
|
||||
|
||||
For an online memory block, the managing zone can be observed via::
|
||||
|
||||
% cat /sys/device/system/memory/memoryXXX/valid_zones
|
||||
|
||||
Configuring Memory Hot(Un)Plug
|
||||
==============================
|
||||
|
||||
All memory blocks have their device information in sysfs. Each memory block
|
||||
is described under ``/sys/devices/system/memory`` as::
|
||||
There are various ways how system administrators can configure memory
|
||||
hot(un)plug and interact with memory blocks, especially, to online them.
|
||||
|
||||
Memory Hot(Un)Plug Configuration via Sysfs
|
||||
------------------------------------------
|
||||
|
||||
Some memory hot(un)plug properties can be configured or inspected via sysfs in::
|
||||
|
||||
/sys/devices/system/memory/
|
||||
|
||||
The following files are currently defined:
|
||||
|
||||
====================== =========================================================
|
||||
``auto_online_blocks`` read-write: set or get the default state of new memory
|
||||
blocks; configure auto-onlining.
|
||||
|
||||
The default value depends on the
|
||||
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel configuration
|
||||
option.
|
||||
|
||||
See the ``state`` property of memory blocks for details.
|
||||
``block_size_bytes`` read-only: the size in bytes of a memory block.
|
||||
``probe`` write-only: add (probe) selected memory blocks manually
|
||||
from user space by supplying the physical start address.
|
||||
|
||||
Availability depends on the CONFIG_ARCH_MEMORY_PROBE
|
||||
kernel configuration option.
|
||||
``uevent`` read-write: generic udev file for device subsystems.
|
||||
====================== =========================================================
|
||||
|
||||
.. note::
|
||||
|
||||
When the CONFIG_MEMORY_FAILURE kernel configuration option is enabled, two
|
||||
additional files ``hard_offline_page`` and ``soft_offline_page`` are available
|
||||
to trigger hwpoisoning of pages, for example, for testing purposes. Note that
|
||||
this functionality is not really related to memory hot(un)plug or actual
|
||||
offlining of memory blocks.
|
||||
|
||||
Memory Block Configuration via Sysfs
|
||||
------------------------------------
|
||||
|
||||
Each memory block is represented as a memory block device that can be
|
||||
onlined or offlined. All memory blocks have their device information located in
|
||||
sysfs. Each present memory block is listed under
|
||||
``/sys/devices/system/memory`` as::
|
||||
|
||||
/sys/devices/system/memory/memoryXXX
|
||||
|
||||
where XXX is the memory block id.
|
||||
where XXX is the memory block id; the number of digits is variable.
|
||||
|
||||
For the memory block covered by the sysfs directory. It is expected that all
|
||||
memory sections in this range are present and no memory holes exist in the
|
||||
range. Currently there is no way to determine if there is a memory hole, but
|
||||
the existence of one should not affect the hotplug capabilities of the memory
|
||||
block.
|
||||
A present memory block indicates that some memory in the range is present;
|
||||
however, a memory block might span memory holes. A memory block spanning memory
|
||||
holes cannot be offlined.
|
||||
|
||||
For example, assume 1GiB memory block size. A device for a memory starting at
|
||||
For example, assume 1 GiB memory block size. A device for a memory starting at
|
||||
0x100000000 is ``/sys/device/system/memory/memory4``::
|
||||
|
||||
(0x100000000 / 1Gib = 4)
|
||||
|
||||
This device covers address range [0x100000000 ... 0x140000000)
|
||||
|
||||
Under each memory block, you can see 5 files:
|
||||
|
||||
- ``/sys/devices/system/memory/memoryXXX/phys_index``
|
||||
- ``/sys/devices/system/memory/memoryXXX/phys_device``
|
||||
- ``/sys/devices/system/memory/memoryXXX/state``
|
||||
- ``/sys/devices/system/memory/memoryXXX/removable``
|
||||
- ``/sys/devices/system/memory/memoryXXX/valid_zones``
|
||||
The following files are currently defined:
|
||||
|
||||
=================== ============================================================
|
||||
``phys_index`` read-only and contains memory block id, same as XXX.
|
||||
``state`` read-write
|
||||
|
||||
- at read: contains online/offline state of memory.
|
||||
- at write: user can specify "online_kernel",
|
||||
|
||||
"online_movable", "online", "offline" command
|
||||
which will be performed on all sections in the block.
|
||||
``online`` read-write: simplified interface to trigger onlining /
|
||||
offlining and to observe the state of a memory block.
|
||||
When onlining, the zone is selected automatically.
|
||||
``phys_device`` read-only: legacy interface only ever used on s390x to
|
||||
expose the covered storage increment.
|
||||
``phys_index`` read-only: the memory block id (XXX).
|
||||
``removable`` read-only: legacy interface that indicated whether a memory
|
||||
block was likely to be offlineable or not. Newer kernel
|
||||
versions return "1" if and only if the kernel supports
|
||||
memory offlining.
|
||||
``valid_zones`` read-only: designed to show by which zone memory provided by
|
||||
a memory block is managed, and to show by which zone memory
|
||||
provided by an offline memory block could be managed when
|
||||
onlining.
|
||||
block was likely to be offlineable or not. Nowadays, the
|
||||
kernel return ``1`` if and only if it supports memory
|
||||
offlining.
|
||||
``state`` read-write: advanced interface to trigger onlining /
|
||||
offlining and to observe the state of a memory block.
|
||||
|
||||
The first column shows it`s default zone.
|
||||
When writing, ``online``, ``offline``, ``online_kernel`` and
|
||||
``online_movable`` are supported.
|
||||
|
||||
"memory6/valid_zones: Normal Movable" shows this memoryblock
|
||||
can be onlined to ZONE_NORMAL by default and to ZONE_MOVABLE
|
||||
by online_movable.
|
||||
``online_movable`` specifies onlining to ZONE_MOVABLE.
|
||||
``online_kernel`` specifies onlining to the default kernel
|
||||
zone for the memory block, such as ZONE_NORMAL.
|
||||
``online`` let's the kernel select the zone automatically.
|
||||
|
||||
"memory7/valid_zones: Movable Normal" shows this memoryblock
|
||||
can be onlined to ZONE_MOVABLE by default and to ZONE_NORMAL
|
||||
by online_kernel.
|
||||
When reading, ``online``, ``offline`` and ``going-offline``
|
||||
may be returned.
|
||||
``uevent`` read-write: generic uevent file for devices.
|
||||
``valid_zones`` read-only: when a block is online, shows the zone it
|
||||
belongs to; when a block is offline, shows what zone will
|
||||
manage it when the block will be onlined.
|
||||
|
||||
For online memory blocks, ``DMA``, ``DMA32``, ``Normal``,
|
||||
``Movable`` and ``none`` may be returned. ``none`` indicates
|
||||
that memory provided by a memory block is managed by
|
||||
multiple zones or spans multiple nodes; such memory blocks
|
||||
cannot be offlined. ``Movable`` indicates ZONE_MOVABLE.
|
||||
Other values indicate a kernel zone.
|
||||
|
||||
For offline memory blocks, the first column shows the
|
||||
zone the kernel would select when onlining the memory block
|
||||
right now without further specifying a zone.
|
||||
|
||||
Availability depends on the CONFIG_MEMORY_HOTREMOVE
|
||||
kernel configuration option.
|
||||
=================== ============================================================
|
||||
|
||||
.. note::
|
||||
|
||||
These directories/files appear after physical memory hotplug phase.
|
||||
If the CONFIG_NUMA kernel configuration option is enabled, the memoryXXX/
|
||||
directories can also be accessed via symbolic links located in the
|
||||
``/sys/devices/system/node/node*`` directories.
|
||||
|
||||
If CONFIG_NUMA is enabled the memoryXXX/ directories can also be accessed
|
||||
via symbolic links located in the ``/sys/devices/system/node/node*`` directories.
|
||||
|
||||
For example::
|
||||
For example::
|
||||
|
||||
/sys/devices/system/node/node0/memory9 -> ../../memory/memory9
|
||||
|
||||
A backlink will also be created::
|
||||
A backlink will also be created::
|
||||
|
||||
/sys/devices/system/memory/memory9/node0 -> ../../node/node0
|
||||
|
||||
.. _memory_hotplug_physical_mem:
|
||||
Command Line Parameters
|
||||
-----------------------
|
||||
|
||||
Physical memory hot-add phase
|
||||
=============================
|
||||
Some command line parameters affect memory hot(un)plug handling. The following
|
||||
command line parameters are relevant:
|
||||
|
||||
Hardware(Firmware) Support
|
||||
--------------------------
|
||||
======================== =======================================================
|
||||
``memhp_default_state`` configure auto-onlining by essentially setting
|
||||
``/sys/devices/system/memory/auto_online_blocks``.
|
||||
``movablecore`` configure automatic zone selection of the kernel. When
|
||||
set, the kernel will default to ZONE_MOVABLE, unless
|
||||
other zones can be kept contiguous.
|
||||
======================== =======================================================
|
||||
|
||||
On x86_64/ia64 platform, memory hotplug by ACPI is supported.
|
||||
Module Parameters
|
||||
------------------
|
||||
|
||||
In general, the firmware (ACPI) which supports memory hotplug defines
|
||||
memory class object of _HID "PNP0C80". When a notify is asserted to PNP0C80,
|
||||
Linux's ACPI handler does hot-add memory to the system and calls a hotplug udev
|
||||
script. This will be done automatically.
|
||||
Instead of additional command line parameters or sysfs files, the
|
||||
``memory_hotplug`` subsystem now provides a dedicated namespace for module
|
||||
parameters. Module parameters can be set via the command line by predicating
|
||||
them with ``memory_hotplug.`` such as::
|
||||
|
||||
But scripts for memory hotplug are not contained in generic udev package(now).
|
||||
You may have to write it by yourself or online/offline memory by hand.
|
||||
Please see :ref:`memory_hotplug_how_to_online_memory` and
|
||||
:ref:`memory_hotplug_how_to_offline_memory`.
|
||||
memory_hotplug.memmap_on_memory=1
|
||||
|
||||
If firmware supports NUMA-node hotplug, and defines an object _HID "ACPI0004",
|
||||
"PNP0A05", or "PNP0A06", notification is asserted to it, and ACPI handler
|
||||
calls hotplug code for all of objects which are defined in it.
|
||||
If memory device is found, memory hotplug code will be called.
|
||||
and they can be observed (and some even modified at runtime) via::
|
||||
|
||||
Notify memory hot-add event by hand
|
||||
-----------------------------------
|
||||
/sys/modules/memory_hotplug/parameters/
|
||||
|
||||
On some architectures, the firmware may not notify the kernel of a memory
|
||||
hotplug event. Therefore, the memory "probe" interface is supported to
|
||||
explicitly notify the kernel. This interface depends on
|
||||
CONFIG_ARCH_MEMORY_PROBE and can be configured on powerpc, sh, and x86
|
||||
if hotplug is supported, although for x86 this should be handled by ACPI
|
||||
notification.
|
||||
The following module parameters are currently defined:
|
||||
|
||||
Probe interface is located at::
|
||||
======================== =======================================================
|
||||
``memmap_on_memory`` read-write: Allocate memory for the memmap from the
|
||||
added memory block itself. Even if enabled, actual
|
||||
support depends on various other system properties and
|
||||
should only be regarded as a hint whether the behavior
|
||||
would be desired.
|
||||
|
||||
/sys/devices/system/memory/probe
|
||||
While allocating the memmap from the memory block
|
||||
itself makes memory hotplug less likely to fail and
|
||||
keeps the memmap on the same NUMA node in any case, it
|
||||
can fragment physical memory in a way that huge pages
|
||||
in bigger granularity cannot be formed on hotplugged
|
||||
memory.
|
||||
======================== =======================================================
|
||||
|
||||
You can tell the physical address of new memory to the kernel by::
|
||||
ZONE_MOVABLE
|
||||
============
|
||||
|
||||
% echo start_address_of_new_memory > /sys/devices/system/memory/probe
|
||||
ZONE_MOVABLE is an important mechanism for more reliable memory offlining.
|
||||
Further, having system RAM managed by ZONE_MOVABLE instead of one of the
|
||||
kernel zones can increase the number of possible transparent huge pages and
|
||||
dynamically allocated huge pages.
|
||||
|
||||
Then, [start_address_of_new_memory, start_address_of_new_memory +
|
||||
memory_block_size] memory range is hot-added. In this case, hotplug script is
|
||||
not called (in current implementation). You'll have to online memory by
|
||||
yourself. Please see :ref:`memory_hotplug_how_to_online_memory`.
|
||||
Most kernel allocations are unmovable. Important examples include the memory
|
||||
map (usually 1/64ths of memory), page tables, and kmalloc(). Such allocations
|
||||
can only be served from the kernel zones.
|
||||
|
||||
Logical Memory hot-add phase
|
||||
============================
|
||||
Most user space pages, such as anonymous memory, and page cache pages are
|
||||
movable. Such allocations can be served from ZONE_MOVABLE and the kernel zones.
|
||||
|
||||
State of memory
|
||||
Only movable allocations are served from ZONE_MOVABLE, resulting in unmovable
|
||||
allocations being limited to the kernel zones. Without ZONE_MOVABLE, there is
|
||||
absolutely no guarantee whether a memory block can be offlined successfully.
|
||||
|
||||
Zone Imbalances
|
||||
---------------
|
||||
|
||||
To see (online/offline) state of a memory block, read 'state' file::
|
||||
Having too much system RAM managed by ZONE_MOVABLE is called a zone imbalance,
|
||||
which can harm the system or degrade performance. As one example, the kernel
|
||||
might crash because it runs out of free memory for unmovable allocations,
|
||||
although there is still plenty of free memory left in ZONE_MOVABLE.
|
||||
|
||||
% cat /sys/device/system/memory/memoryXXX/state
|
||||
Usually, MOVABLE:KERNEL ratios of up to 3:1 or even 4:1 are fine. Ratios of 63:1
|
||||
are definitely impossible due to the overhead for the memory map.
|
||||
|
||||
|
||||
- If the memory block is online, you'll read "online".
|
||||
- If the memory block is offline, you'll read "offline".
|
||||
|
||||
|
||||
.. _memory_hotplug_how_to_online_memory:
|
||||
|
||||
How to online memory
|
||||
--------------------
|
||||
|
||||
When the memory is hot-added, the kernel decides whether or not to "online"
|
||||
it according to the policy which can be read from "auto_online_blocks" file::
|
||||
|
||||
% cat /sys/devices/system/memory/auto_online_blocks
|
||||
|
||||
The default depends on the CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE kernel config
|
||||
option. If it is disabled the default is "offline" which means the newly added
|
||||
memory is not in a ready-to-use state and you have to "online" the newly added
|
||||
memory blocks manually. Automatic onlining can be requested by writing "online"
|
||||
to "auto_online_blocks" file::
|
||||
|
||||
% echo online > /sys/devices/system/memory/auto_online_blocks
|
||||
|
||||
This sets a global policy and impacts all memory blocks that will subsequently
|
||||
be hotplugged. Currently offline blocks keep their state. It is possible, under
|
||||
certain circumstances, that some memory blocks will be added but will fail to
|
||||
online. User space tools can check their "state" files
|
||||
(``/sys/devices/system/memory/memoryXXX/state``) and try to online them manually.
|
||||
|
||||
If the automatic onlining wasn't requested, failed, or some memory block was
|
||||
offlined it is possible to change the individual block's state by writing to the
|
||||
"state" file::
|
||||
|
||||
% echo online > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
This onlining will not change the ZONE type of the target memory block,
|
||||
If the memory block doesn't belong to any zone an appropriate kernel zone
|
||||
(usually ZONE_NORMAL) will be used unless movable_node kernel command line
|
||||
option is specified when ZONE_MOVABLE will be used.
|
||||
|
||||
You can explicitly request to associate it with ZONE_MOVABLE by::
|
||||
|
||||
% echo online_movable > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
.. note:: current limit: this memory block must be adjacent to ZONE_MOVABLE
|
||||
|
||||
Or you can explicitly request a kernel zone (usually ZONE_NORMAL) by::
|
||||
|
||||
% echo online_kernel > /sys/devices/system/memory/memoryXXX/state
|
||||
|
||||
.. note:: current limit: this memory block must be adjacent to ZONE_NORMAL
|
||||
|
||||
An explicit zone onlining can fail (e.g. when the range is already within
|
||||
and existing and incompatible zone already).
|
||||
|
||||
After this, memory block XXX's state will be 'online' and the amount of
|
||||
available memory will be increased.
|
||||
|
||||
This may be changed in future.
|
||||
|
||||
Logical memory remove
|
||||
=====================
|
||||
|
||||
Memory offline and ZONE_MOVABLE
|
||||
-------------------------------
|
||||
|
||||
Memory offlining is more complicated than memory online. Because memory offline
|
||||
has to make the whole memory block be unused, memory offline can fail if
|
||||
the memory block includes memory which cannot be freed.
|
||||
|
||||
In general, memory offline can use 2 techniques.
|
||||
|
||||
(1) reclaim and free all memory in the memory block.
|
||||
(2) migrate all pages in the memory block.
|
||||
|
||||
In the current implementation, Linux's memory offline uses method (2), freeing
|
||||
all pages in the memory block by page migration. But not all pages are
|
||||
migratable. Under current Linux, migratable pages are anonymous pages and
|
||||
page caches. For offlining a memory block by migration, the kernel has to
|
||||
guarantee that the memory block contains only migratable pages.
|
||||
|
||||
Now, a boot option for making a memory block which consists of migratable pages
|
||||
is supported. By specifying "kernelcore=" or "movablecore=" boot option, you can
|
||||
create ZONE_MOVABLE...a zone which is just used for movable pages.
|
||||
(See also Documentation/admin-guide/kernel-parameters.rst)
|
||||
|
||||
Assume the system has "TOTAL" amount of memory at boot time, this boot option
|
||||
creates ZONE_MOVABLE as following.
|
||||
|
||||
1) When kernelcore=YYYY boot option is used,
|
||||
Size of memory not for movable pages (not for offline) is YYYY.
|
||||
Size of memory for movable pages (for offline) is TOTAL-YYYY.
|
||||
|
||||
2) When movablecore=ZZZZ boot option is used,
|
||||
Size of memory not for movable pages (not for offline) is TOTAL - ZZZZ.
|
||||
Size of memory for movable pages (for offline) is ZZZZ.
|
||||
Actual safe zone ratios depend on the workload. Extreme cases, like excessive
|
||||
long-term pinning of pages, might not be able to deal with ZONE_MOVABLE at all.
|
||||
|
||||
.. note::
|
||||
|
||||
Unfortunately, there is no information to show which memory block belongs
|
||||
to ZONE_MOVABLE. This is TBD.
|
||||
CMA memory part of a kernel zone essentially behaves like memory in
|
||||
ZONE_MOVABLE and similar considerations apply, especially when combining
|
||||
CMA with ZONE_MOVABLE.
|
||||
|
||||
Memory offlining can fail when dissolving a free huge page on ZONE_MOVABLE
|
||||
and the feature of freeing unused vmemmap pages associated with each hugetlb
|
||||
page is enabled.
|
||||
ZONE_MOVABLE Sizing Considerations
|
||||
----------------------------------
|
||||
|
||||
This can happen when we have plenty of ZONE_MOVABLE memory, but not enough
|
||||
kernel memory to allocate vmemmmap pages. We may even be able to migrate
|
||||
huge page contents, but will not be able to dissolve the source huge page.
|
||||
This will prevent an offline operation and is unfortunate as memory offlining
|
||||
is expected to succeed on movable zones. Users that depend on memory hotplug
|
||||
to succeed for movable zones should carefully consider whether the memory
|
||||
savings gained from this feature are worth the risk of possibly not being
|
||||
able to offline memory in certain situations.
|
||||
We usually expect that a large portion of available system RAM will actually
|
||||
be consumed by user space, either directly or indirectly via the page cache. In
|
||||
the normal case, ZONE_MOVABLE can be used when allocating such pages just fine.
|
||||
|
||||
.. note::
|
||||
Techniques that rely on long-term pinnings of memory (especially, RDMA and
|
||||
vfio) are fundamentally problematic with ZONE_MOVABLE and, therefore, memory
|
||||
hot remove. Pinned pages cannot reside on ZONE_MOVABLE, to guarantee that
|
||||
memory can still get hot removed - be aware that pinning can fail even if
|
||||
there is plenty of free memory in ZONE_MOVABLE. In addition, using
|
||||
ZONE_MOVABLE might make page pinning more expensive, because pages have to be
|
||||
migrated off that zone first.
|
||||
With that in mind, it makes sense that we can have a big portion of system RAM
|
||||
managed by ZONE_MOVABLE. However, there are some things to consider when using
|
||||
ZONE_MOVABLE, especially when fine-tuning zone ratios:
|
||||
|
||||
.. _memory_hotplug_how_to_offline_memory:
|
||||
- Having a lot of offline memory blocks. Even offline memory blocks consume
|
||||
memory for metadata and page tables in the direct map; having a lot of offline
|
||||
memory blocks is not a typical case, though.
|
||||
|
||||
How to offline memory
|
||||
---------------------
|
||||
- Memory ballooning without balloon compaction is incompatible with
|
||||
ZONE_MOVABLE. Only some implementations, such as virtio-balloon and
|
||||
pseries CMM, fully support balloon compaction.
|
||||
|
||||
You can offline a memory block by using the same sysfs interface that was used
|
||||
in memory onlining::
|
||||
Further, the CONFIG_BALLOON_COMPACTION kernel configuration option might be
|
||||
disabled. In that case, balloon inflation will only perform unmovable
|
||||
allocations and silently create a zone imbalance, usually triggered by
|
||||
inflation requests from the hypervisor.
|
||||
|
||||
% echo offline > /sys/devices/system/memory/memoryXXX/state
|
||||
- Gigantic pages are unmovable, resulting in user space consuming a
|
||||
lot of unmovable memory.
|
||||
|
||||
If offline succeeds, the state of the memory block is changed to be "offline".
|
||||
If it fails, some error core (like -EBUSY) will be returned by the kernel.
|
||||
Even if a memory block does not belong to ZONE_MOVABLE, you can try to offline
|
||||
it. If it doesn't contain 'unmovable' memory, you'll get success.
|
||||
- Huge pages are unmovable when an architectures does not support huge
|
||||
page migration, resulting in a similar issue as with gigantic pages.
|
||||
|
||||
A memory block under ZONE_MOVABLE is considered to be able to be offlined
|
||||
easily. But under some busy state, it may return -EBUSY. Even if a memory
|
||||
block cannot be offlined due to -EBUSY, you can retry offlining it and may be
|
||||
able to offline it (or not). (For example, a page is referred to by some kernel
|
||||
internal call and released soon.)
|
||||
- Page tables are unmovable. Excessive swapping, mapping extremely large
|
||||
files or ZONE_DEVICE memory can be problematic, although only really relevant
|
||||
in corner cases. When we manage a lot of user space memory that has been
|
||||
swapped out or is served from a file/persistent memory/... we still need a lot
|
||||
of page tables to manage that memory once user space accessed that memory.
|
||||
|
||||
Consideration:
|
||||
Memory hotplug's design direction is to make the possibility of memory
|
||||
offlining higher and to guarantee unplugging memory under any situation. But
|
||||
it needs more work. Returning -EBUSY under some situation may be good because
|
||||
the user can decide to retry more or not by himself. Currently, memory
|
||||
offlining code does some amount of retry with 120 seconds timeout.
|
||||
- In certain DAX configurations the memory map for the device memory will be
|
||||
allocated from the kernel zones.
|
||||
|
||||
Physical memory remove
|
||||
======================
|
||||
- KASAN can have a significant memory overhead, for example, consuming 1/8th of
|
||||
the total system memory size as (unmovable) tracking metadata.
|
||||
|
||||
Need more implementation yet....
|
||||
- Notification completion of remove works by OS to firmware.
|
||||
- Guard from remove if not yet.
|
||||
- Long-term pinning of pages. Techniques that rely on long-term pinnings
|
||||
(especially, RDMA and vfio/mdev) are fundamentally problematic with
|
||||
ZONE_MOVABLE, and therefore, memory offlining. Pinned pages cannot reside
|
||||
on ZONE_MOVABLE as that would turn these pages unmovable. Therefore, they
|
||||
have to be migrated off that zone while pinning. Pinning a page can fail
|
||||
even if there is plenty of free memory in ZONE_MOVABLE.
|
||||
|
||||
In addition, using ZONE_MOVABLE might make page pinning more expensive,
|
||||
because of the page migration overhead.
|
||||
|
||||
Locking Internals
|
||||
=================
|
||||
By default, all the memory configured at boot time is managed by the kernel
|
||||
zones and ZONE_MOVABLE is not used.
|
||||
|
||||
When adding/removing memory that uses memory block devices (i.e. ordinary RAM),
|
||||
the device_hotplug_lock should be held to:
|
||||
To enable ZONE_MOVABLE to include the memory present at boot and to control the
|
||||
ratio between movable and kernel zones there are two command line options:
|
||||
``kernelcore=`` and ``movablecore=``. See
|
||||
Documentation/admin-guide/kernel-parameters.rst for their description.
|
||||
|
||||
- synchronize against online/offline requests (e.g. via sysfs). This way, memory
|
||||
block devices can only be accessed (.online/.state attributes) by user
|
||||
space once memory has been fully added. And when removing memory, we
|
||||
know nobody is in critical sections.
|
||||
- synchronize against CPU hotplug and similar (e.g. relevant for ACPI and PPC)
|
||||
Memory Offlining and ZONE_MOVABLE
|
||||
---------------------------------
|
||||
|
||||
Especially, there is a possible lock inversion that is avoided using
|
||||
device_hotplug_lock when adding memory and user space tries to online that
|
||||
memory faster than expected:
|
||||
Even with ZONE_MOVABLE, there are some corner cases where offlining a memory
|
||||
block might fail:
|
||||
|
||||
- device_online() will first take the device_lock(), followed by
|
||||
mem_hotplug_lock
|
||||
- add_memory_resource() will first take the mem_hotplug_lock, followed by
|
||||
the device_lock() (while creating the devices, during bus_add_device()).
|
||||
- Memory blocks with memory holes; this applies to memory blocks present during
|
||||
boot and can apply to memory blocks hotplugged via the XEN balloon and the
|
||||
Hyper-V balloon.
|
||||
|
||||
As the device is visible to user space before taking the device_lock(), this
|
||||
can result in a lock inversion.
|
||||
- Mixed NUMA nodes and mixed zones within a single memory block prevent memory
|
||||
offlining; this applies to memory blocks present during boot only.
|
||||
|
||||
onlining/offlining of memory should be done via device_online()/
|
||||
device_offline() - to make sure it is properly synchronized to actions
|
||||
via sysfs. Holding device_hotplug_lock is advised (to e.g. protect online_type)
|
||||
- Special memory blocks prevented by the system from getting offlined. Examples
|
||||
include any memory available during boot on arm64 or memory blocks spanning
|
||||
the crashkernel area on s390x; this usually applies to memory blocks present
|
||||
during boot only.
|
||||
|
||||
When adding/removing/onlining/offlining memory or adding/removing
|
||||
heterogeneous/device memory, we should always hold the mem_hotplug_lock in
|
||||
write mode to serialise memory hotplug (e.g. access to global/zone
|
||||
variables).
|
||||
- Memory blocks overlapping with CMA areas cannot be offlined, this applies to
|
||||
memory blocks present during boot only.
|
||||
|
||||
In addition, mem_hotplug_lock (in contrast to device_hotplug_lock) in read
|
||||
mode allows for a quite efficient get_online_mems/put_online_mems
|
||||
implementation, so code accessing memory can protect from that memory
|
||||
vanishing.
|
||||
- Concurrent activity that operates on the same physical memory area, such as
|
||||
allocating gigantic pages, can result in temporary offlining failures.
|
||||
|
||||
- Out of memory when dissolving huge pages, especially when freeing unused
|
||||
vmemmap pages associated with each hugetlb page is enabled.
|
||||
|
||||
Future Work
|
||||
===========
|
||||
Offlining code may be able to migrate huge page contents, but may not be able
|
||||
to dissolve the source huge page because it fails allocating (unmovable) pages
|
||||
for the vmemmap, because the system might not have free memory in the kernel
|
||||
zones left.
|
||||
|
||||
- allowing memory hot-add to ZONE_MOVABLE. maybe we need some switch like
|
||||
sysctl or new control file.
|
||||
- showing memory block and physical device relationship.
|
||||
- test and make it better memory offlining.
|
||||
- support HugeTLB page migration and offlining.
|
||||
- memmap removing at memory offline.
|
||||
- physical remove memory.
|
||||
Users that depend on memory offlining to succeed for movable zones should
|
||||
carefully consider whether the memory savings gained from this feature are
|
||||
worth the risk of possibly not being able to offline memory in certain
|
||||
situations.
|
||||
|
||||
Further, when running into out of memory situations while migrating pages, or
|
||||
when still encountering permanently unmovable pages within ZONE_MOVABLE
|
||||
(-> BUG), memory offlining will keep retrying until it eventually succeeds.
|
||||
|
||||
When offlining is triggered from user space, the offlining context can be
|
||||
terminated by sending a fatal signal. A timeout based offlining can easily be
|
||||
implemented via::
|
||||
|
||||
% timeout $TIMEOUT offline_block | failure_handling
|
||||
|
@ -245,6 +245,13 @@ MPOL_INTERLEAVED
|
||||
address range or file. During system boot up, the temporary
|
||||
interleaved system default policy works in this mode.
|
||||
|
||||
MPOL_PREFERRED_MANY
|
||||
This mode specifices that the allocation should be preferrably
|
||||
satisfied from the nodemask specified in the policy. If there is
|
||||
a memory pressure on all nodes in the nodemask, the allocation
|
||||
can fall back to all existing numa nodes. This is effectively
|
||||
MPOL_PREFERRED allowed for a mask rather than a single node.
|
||||
|
||||
NUMA memory policy supports the following optional mode flags:
|
||||
|
||||
MPOL_F_STATIC_NODES
|
||||
@ -253,10 +260,10 @@ MPOL_F_STATIC_NODES
|
||||
nodes changes after the memory policy has been defined.
|
||||
|
||||
Without this flag, any time a mempolicy is rebound because of a
|
||||
change in the set of allowed nodes, the node (Preferred) or
|
||||
nodemask (Bind, Interleave) is remapped to the new set of
|
||||
allowed nodes. This may result in nodes being used that were
|
||||
previously undesired.
|
||||
change in the set of allowed nodes, the preferred nodemask (Preferred
|
||||
Many), preferred node (Preferred) or nodemask (Bind, Interleave) is
|
||||
remapped to the new set of allowed nodes. This may result in nodes
|
||||
being used that were previously undesired.
|
||||
|
||||
With this flag, if the user-specified nodes overlap with the
|
||||
nodes allowed by the task's cpuset, then the memory policy is
|
||||
|
@ -118,7 +118,8 @@ compaction_proactiveness
|
||||
|
||||
This tunable takes a value in the range [0, 100] with a default value of
|
||||
20. This tunable determines how aggressively compaction is done in the
|
||||
background. Setting it to 0 disables proactive compaction.
|
||||
background. Write of a non zero value to this tunable will immediately
|
||||
trigger the proactive compaction. Setting it to 0 disables proactive compaction.
|
||||
|
||||
Note that compaction has a non-trivial system-wide impact as pages
|
||||
belonging to different processes are moved around, which could also lead
|
||||
|
@ -72,7 +72,7 @@ On PowerPC
|
||||
|
||||
On other
|
||||
If you know of the key combos for other architectures, please
|
||||
let me know so I can add them to this section.
|
||||
submit a patch to be included in this section.
|
||||
|
||||
On all
|
||||
Write a character to /proc/sysrq-trigger. e.g.::
|
||||
@ -205,10 +205,12 @@ frozen (probably root) filesystem via the FIFREEZE ioctl.
|
||||
Sometimes SysRq seems to get 'stuck' after using it, what can I do?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
||||
That happens to me, also. I've found that tapping shift, alt, and control
|
||||
on both sides of the keyboard, and hitting an invalid sysrq sequence again
|
||||
will fix the problem. (i.e., something like :kbd:`alt-sysrq-z`). Switching to
|
||||
another virtual console (:kbd:`ALT+Fn`) and then back again should also help.
|
||||
When this happens, try tapping shift, alt and control on both sides of the
|
||||
keyboard, and hitting an invalid sysrq sequence again. (i.e., something like
|
||||
:kbd:`alt-sysrq-z`).
|
||||
|
||||
Switching to another virtual console (:kbd:`ALT+Fn`) and then back again
|
||||
should also help.
|
||||
|
||||
I hit SysRq, but nothing seems to happen, what's wrong?
|
||||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||
|
@ -58,11 +58,19 @@ Kirkwood family
|
||||
- Product Brief : https://web.archive.org/web/20120616201621/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6180-003_ver1.pdf
|
||||
- Hardware Spec : https://web.archive.org/web/20130730091654/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6180_OpenSource.pdf
|
||||
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
- 88F6280
|
||||
|
||||
- Product Brief : https://web.archive.org/web/20130730091058/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6280_SoC_PB-001.pdf
|
||||
- 88F6281
|
||||
|
||||
- Product Brief : https://web.archive.org/web/20120131133709/http://www.marvell.com/embedded-processors/kirkwood/assets/88F6281-004_ver1.pdf
|
||||
- Hardware Spec : https://web.archive.org/web/20120620073511/http://www.marvell.com/embedded-processors/kirkwood/assets/HW_88F6281_OpenSource.pdf
|
||||
- Functional Spec: https://web.archive.org/web/20130730091033/http://www.marvell.com/embedded-processors/kirkwood/assets/FS_88F6180_9x_6281_OpenSource.pdf
|
||||
- 88F6321
|
||||
- 88F6322
|
||||
- 88F6323
|
||||
|
||||
- Product Brief : https://web.archive.org/web/20120616201639/http://www.marvell.com/embedded-processors/kirkwood/assets/88f632x_pb.pdf
|
||||
Homepage:
|
||||
https://web.archive.org/web/20160513194943/http://www.marvell.com/embedded-processors/kirkwood/
|
||||
Core:
|
||||
@ -89,6 +97,10 @@ Discovery family
|
||||
|
||||
- MV76100
|
||||
|
||||
- Product Brief : https://web.archive.org/web/20140722064429/http://www.marvell.com/embedded-processors/discovery-innovation/assets/MV76100-002_WEB.pdf
|
||||
- Hardware Spec : https://web.archive.org/web/20140722064425/http://www.marvell.com/embedded-processors/discovery-innovation/assets/HW_MV76100_OpenSource.pdf
|
||||
- Functional Spec: https://web.archive.org/web/20111110081125/http://www.marvell.com/embedded-processors/discovery-innovation/assets/FS_MV76100_78100_78200_OpenSource.pdf
|
||||
|
||||
Not supported by the Linux kernel.
|
||||
|
||||
Core:
|
||||
@ -124,17 +136,24 @@ EBU Armada family
|
||||
|
||||
Armada 38x Flavors:
|
||||
- 88F6810 Armada 380
|
||||
- 88F6811 Armada 381
|
||||
- 88F6821 Armada 382
|
||||
- 88F6W21 Armada 383
|
||||
- 88F6820 Armada 385
|
||||
- 88F6825
|
||||
- 88F6828 Armada 388
|
||||
|
||||
- Product infos: https://web.archive.org/web/20181006144616/http://www.marvell.com/embedded-processors/armada-38x/
|
||||
- Functional Spec: https://web.archive.org/web/20200420191927/https://www.marvell.com/content/dam/marvell/en/public-collateral/embedded-processors/marvell-embedded-processors-armada-38x-functional-specifications-2015-11.pdf
|
||||
- Hardware Spec: https://web.archive.org/web/20180713105318/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-specifications-2017-03.pdf
|
||||
- Design guide: https://web.archive.org/web/20180712231737/https://www.marvell.com/docs/embedded-processors/assets/marvell-embedded-processors-armada-38x-hardware-design-guide-2017-08.pdf
|
||||
|
||||
Core:
|
||||
ARM Cortex-A9
|
||||
|
||||
Armada 39x Flavors:
|
||||
- 88F6920 Armada 390
|
||||
- 88F6925 Armada 395
|
||||
- 88F6928 Armada 398
|
||||
|
||||
- Product infos: https://web.archive.org/web/20181020222559/http://www.marvell.com/embedded-processors/armada-39x/
|
||||
|
@ -54,7 +54,7 @@ layer or if we want to try to merge requests. In both cases, requests will be
|
||||
sent to the software queue.
|
||||
|
||||
Then, after the requests are processed by software queues, they will be placed
|
||||
at the hardware queue, a second stage queue were the hardware has direct access
|
||||
at the hardware queue, a second stage queue where the hardware has direct access
|
||||
to process those requests. However, if the hardware does not have enough
|
||||
resources to accept more requests, blk-mq will places requests on a temporary
|
||||
queue, to be sent in the future, when the hardware is able.
|
||||
|
@ -16,8 +16,6 @@ import sys
|
||||
import os
|
||||
import sphinx
|
||||
|
||||
from subprocess import check_output
|
||||
|
||||
# Get Sphinx version
|
||||
major, minor, patch = sphinx.version_info[:3]
|
||||
|
||||
@ -343,6 +341,9 @@ latex_elements = {
|
||||
verbatimhintsturnover=false,
|
||||
''',
|
||||
|
||||
# For CJK One-half spacing, need to be in front of hyperref
|
||||
'extrapackages': r'\usepackage{setspace}',
|
||||
|
||||
# Additional stuff for the LaTeX preamble.
|
||||
'preamble': '''
|
||||
% Prevent column squeezing of tabulary.
|
||||
@ -355,29 +356,117 @@ latex_elements = {
|
||||
''',
|
||||
}
|
||||
|
||||
# At least one book (translations) may have Asian characters
|
||||
# with are only displayed if xeCJK is used
|
||||
# Translations have Asian (CJK) characters which are only displayed if
|
||||
# xeCJK is used
|
||||
|
||||
cjk_cmd = check_output(['fc-list', '--format="%{family[0]}\n"']).decode('utf-8', 'ignore')
|
||||
if cjk_cmd.find("Noto Sans CJK SC") >= 0:
|
||||
latex_elements['preamble'] += '''
|
||||
latex_elements['preamble'] += '''
|
||||
\\IfFontExistsTF{Noto Sans CJK SC}{
|
||||
% This is needed for translations
|
||||
\\usepackage{xeCJK}
|
||||
\\setCJKmainfont{Noto Sans CJK SC}
|
||||
\\usepackage{xeCJK}
|
||||
\\IfFontExistsTF{Noto Serif CJK SC}{
|
||||
\\setCJKmainfont{Noto Serif CJK SC}[AutoFakeSlant]
|
||||
}{
|
||||
\\setCJKmainfont{Noto Sans CJK SC}[AutoFakeSlant]
|
||||
}
|
||||
\\setCJKsansfont{Noto Sans CJK SC}[AutoFakeSlant]
|
||||
\\setCJKmonofont{Noto Sans Mono CJK SC}[AutoFakeSlant]
|
||||
% CJK Language-specific font choices
|
||||
\\IfFontExistsTF{Noto Serif CJK SC}{
|
||||
\\newCJKfontfamily[SCmain]\\scmain{Noto Serif CJK SC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[SCserif]\\scserif{Noto Serif CJK SC}[AutoFakeSlant]
|
||||
}{
|
||||
\\newCJKfontfamily[SCmain]\\scmain{Noto Sans CJK SC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[SCserif]\\scserif{Noto Sans CJK SC}[AutoFakeSlant]
|
||||
}
|
||||
\\newCJKfontfamily[SCsans]\\scsans{Noto Sans CJK SC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[SCmono]\\scmono{Noto Sans Mono CJK SC}[AutoFakeSlant]
|
||||
\\IfFontExistsTF{Noto Serif CJK TC}{
|
||||
\\newCJKfontfamily[TCmain]\\tcmain{Noto Serif CJK TC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[TCserif]\\tcserif{Noto Serif CJK TC}[AutoFakeSlant]
|
||||
}{
|
||||
\\newCJKfontfamily[TCmain]\\tcmain{Noto Sans CJK TC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[TCserif]\\tcserif{Noto Sans CJK TC}[AutoFakeSlant]
|
||||
}
|
||||
\\newCJKfontfamily[TCsans]\\tcsans{Noto Sans CJK TC}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[TCmono]\\tcmono{Noto Sans Mono CJK TC}[AutoFakeSlant]
|
||||
\\IfFontExistsTF{Noto Serif CJK KR}{
|
||||
\\newCJKfontfamily[KRmain]\\krmain{Noto Serif CJK KR}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[KRserif]\\krserif{Noto Serif CJK KR}[AutoFakeSlant]
|
||||
}{
|
||||
\\newCJKfontfamily[KRmain]\\krmain{Noto Sans CJK KR}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[KRserif]\\krserif{Noto Sans CJK KR}[AutoFakeSlant]
|
||||
}
|
||||
\\newCJKfontfamily[KRsans]\\krsans{Noto Sans CJK KR}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[KRmono]\\krmono{Noto Sans Mono CJK KR}[AutoFakeSlant]
|
||||
\\IfFontExistsTF{Noto Serif CJK JP}{
|
||||
\\newCJKfontfamily[JPmain]\\jpmain{Noto Serif CJK JP}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[JPserif]\\jpserif{Noto Serif CJK JP}[AutoFakeSlant]
|
||||
}{
|
||||
\\newCJKfontfamily[JPmain]\\jpmain{Noto Sans CJK JP}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[JPserif]\\jpserif{Noto Sans CJK JP}[AutoFakeSlant]
|
||||
}
|
||||
\\newCJKfontfamily[JPsans]\\jpsans{Noto Sans CJK JP}[AutoFakeSlant]
|
||||
\\newCJKfontfamily[JPmono]\\jpmono{Noto Sans Mono CJK JP}[AutoFakeSlant]
|
||||
% Dummy commands for Sphinx < 2.3 (no 'extrapackages' support)
|
||||
\\providecommand{\\onehalfspacing}{}
|
||||
\\providecommand{\\singlespacing}{}
|
||||
% Define custom macros to on/off CJK
|
||||
\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive}
|
||||
\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive}
|
||||
% To customize \sphinxtableofcontents
|
||||
\\newcommand{\\kerneldocCJKon}{\\makexeCJKactive\\onehalfspacing}
|
||||
\\newcommand{\\kerneldocCJKoff}{\\makexeCJKinactive\\singlespacing}
|
||||
\\newcommand{\\kerneldocBeginSC}{%
|
||||
\\begingroup%
|
||||
\\scmain%
|
||||
}
|
||||
\\newcommand{\\kerneldocEndSC}{\\endgroup}
|
||||
\\newcommand{\\kerneldocBeginTC}{%
|
||||
\\begingroup%
|
||||
\\tcmain%
|
||||
\\renewcommand{\\CJKrmdefault}{TCserif}%
|
||||
\\renewcommand{\\CJKsfdefault}{TCsans}%
|
||||
\\renewcommand{\\CJKttdefault}{TCmono}%
|
||||
}
|
||||
\\newcommand{\\kerneldocEndTC}{\\endgroup}
|
||||
\\newcommand{\\kerneldocBeginKR}{%
|
||||
\\begingroup%
|
||||
\\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}%
|
||||
\\xeCJKDeclareCharClass{HalfRight}{`”,`’}%
|
||||
\\krmain%
|
||||
\\renewcommand{\\CJKrmdefault}{KRserif}%
|
||||
\\renewcommand{\\CJKsfdefault}{KRsans}%
|
||||
\\renewcommand{\\CJKttdefault}{KRmono}%
|
||||
\\xeCJKsetup{CJKspace = true} % For inter-phrase space
|
||||
}
|
||||
\\newcommand{\\kerneldocEndKR}{\\endgroup}
|
||||
\\newcommand{\\kerneldocBeginJP}{%
|
||||
\\begingroup%
|
||||
\\xeCJKDeclareCharClass{HalfLeft}{`“,`‘}%
|
||||
\\xeCJKDeclareCharClass{HalfRight}{`”,`’}%
|
||||
\\jpmain%
|
||||
\\renewcommand{\\CJKrmdefault}{JPserif}%
|
||||
\\renewcommand{\\CJKsfdefault}{JPsans}%
|
||||
\\renewcommand{\\CJKttdefault}{JPmono}%
|
||||
}
|
||||
\\newcommand{\\kerneldocEndJP}{\\endgroup}
|
||||
% Single spacing in literal blocks
|
||||
\\fvset{baselinestretch=1}
|
||||
% To customize \\sphinxtableofcontents
|
||||
\\usepackage{etoolbox}
|
||||
% Inactivate CJK after tableofcontents
|
||||
\\apptocmd{\\sphinxtableofcontents}{\\kerneldocCJKoff}{}{}
|
||||
'''
|
||||
else:
|
||||
latex_elements['preamble'] += '''
|
||||
}{ % No CJK font found
|
||||
% Custom macros to on/off CJK (Dummy)
|
||||
\\newcommand{\\kerneldocCJKon}{}
|
||||
\\newcommand{\\kerneldocCJKoff}{}
|
||||
'''
|
||||
\\newcommand{\\kerneldocBeginSC}{}
|
||||
\\newcommand{\\kerneldocEndSC}{}
|
||||
\\newcommand{\\kerneldocBeginTC}{}
|
||||
\\newcommand{\\kerneldocEndTC}{}
|
||||
\\newcommand{\\kerneldocBeginKR}{}
|
||||
\\newcommand{\\kerneldocEndKR}{}
|
||||
\\newcommand{\\kerneldocBeginJP}{}
|
||||
\\newcommand{\\kerneldocEndJP}{}
|
||||
}
|
||||
'''
|
||||
|
||||
# Fix reference escape troubles with Sphinx 1.4.x
|
||||
if major == 1:
|
||||
|
@ -271,10 +271,15 @@ maps this page at its virtual address.
|
||||
|
||||
``void flush_dcache_page(struct page *page)``
|
||||
|
||||
Any time the kernel writes to a page cache page, _OR_
|
||||
the kernel is about to read from a page cache page and
|
||||
user space shared/writable mappings of this page potentially
|
||||
exist, this routine is called.
|
||||
This routines must be called when:
|
||||
|
||||
a) the kernel did write to a page that is in the page cache page
|
||||
and / or in high memory
|
||||
b) the kernel is about to read from a page cache page and user space
|
||||
shared/writable mappings of this page potentially exist. Note
|
||||
that {get,pin}_user_pages{_fast} already call flush_dcache_page
|
||||
on any page found in the user address space and thus driver
|
||||
code rarely needs to take this into account.
|
||||
|
||||
.. note::
|
||||
|
||||
@ -284,38 +289,34 @@ maps this page at its virtual address.
|
||||
handling vfs symlinks in the page cache need not call
|
||||
this interface at all.
|
||||
|
||||
The phrase "kernel writes to a page cache page" means,
|
||||
specifically, that the kernel executes store instructions
|
||||
that dirty data in that page at the page->virtual mapping
|
||||
of that page. It is important to flush here to handle
|
||||
D-cache aliasing, to make sure these kernel stores are
|
||||
visible to user space mappings of that page.
|
||||
The phrase "kernel writes to a page cache page" means, specifically,
|
||||
that the kernel executes store instructions that dirty data in that
|
||||
page at the page->virtual mapping of that page. It is important to
|
||||
flush here to handle D-cache aliasing, to make sure these kernel stores
|
||||
are visible to user space mappings of that page.
|
||||
|
||||
The corollary case is just as important, if there are users
|
||||
which have shared+writable mappings of this file, we must make
|
||||
sure that kernel reads of these pages will see the most recent
|
||||
stores done by the user.
|
||||
The corollary case is just as important, if there are users which have
|
||||
shared+writable mappings of this file, we must make sure that kernel
|
||||
reads of these pages will see the most recent stores done by the user.
|
||||
|
||||
If D-cache aliasing is not an issue, this routine may
|
||||
simply be defined as a nop on that architecture.
|
||||
If D-cache aliasing is not an issue, this routine may simply be defined
|
||||
as a nop on that architecture.
|
||||
|
||||
There is a bit set aside in page->flags (PG_arch_1) as
|
||||
"architecture private". The kernel guarantees that,
|
||||
for pagecache pages, it will clear this bit when such
|
||||
a page first enters the pagecache.
|
||||
There is a bit set aside in page->flags (PG_arch_1) as "architecture
|
||||
private". The kernel guarantees that, for pagecache pages, it will
|
||||
clear this bit when such a page first enters the pagecache.
|
||||
|
||||
This allows these interfaces to be implemented much more
|
||||
efficiently. It allows one to "defer" (perhaps indefinitely)
|
||||
the actual flush if there are currently no user processes
|
||||
mapping this page. See sparc64's flush_dcache_page and
|
||||
update_mmu_cache implementations for an example of how to go
|
||||
about doing this.
|
||||
This allows these interfaces to be implemented much more efficiently.
|
||||
It allows one to "defer" (perhaps indefinitely) the actual flush if
|
||||
there are currently no user processes mapping this page. See sparc64's
|
||||
flush_dcache_page and update_mmu_cache implementations for an example
|
||||
of how to go about doing this.
|
||||
|
||||
The idea is, first at flush_dcache_page() time, if
|
||||
page->mapping->i_mmap is an empty tree, just mark the architecture
|
||||
private page flag bit. Later, in update_mmu_cache(), a check is
|
||||
made of this flag bit, and if set the flush is done and the flag
|
||||
bit is cleared.
|
||||
The idea is, first at flush_dcache_page() time, if page_file_mapping()
|
||||
returns a mapping, and mapping_mapped on that mapping returns %false,
|
||||
just mark the architecture private page flag bit. Later, in
|
||||
update_mmu_cache(), a check is made of this flag bit, and if set the
|
||||
flush is done and the flag bit is cleared.
|
||||
|
||||
.. important::
|
||||
|
||||
@ -351,19 +352,6 @@ maps this page at its virtual address.
|
||||
architectures). For incoherent architectures, it should flush
|
||||
the cache of the page at vmaddr.
|
||||
|
||||
``void flush_kernel_dcache_page(struct page *page)``
|
||||
|
||||
When the kernel needs to modify a user page is has obtained
|
||||
with kmap, it calls this function after all modifications are
|
||||
complete (but before kunmapping it) to bring the underlying
|
||||
page up to date. It is assumed here that the user has no
|
||||
incoherent cached copies (i.e. the original page was obtained
|
||||
from a mechanism like get_user_pages()). The default
|
||||
implementation is a nop and should remain so on all coherent
|
||||
architectures. On incoherent architectures, this should flush
|
||||
the kernel cache for page (using page_address(page)).
|
||||
|
||||
|
||||
``void flush_icache_range(unsigned long start, unsigned long end)``
|
||||
|
||||
When the kernel stores into addresses that it will execute
|
||||
|
@ -2,12 +2,13 @@
|
||||
CPU hotplug in the Kernel
|
||||
=========================
|
||||
|
||||
:Date: December, 2016
|
||||
:Date: September, 2021
|
||||
:Author: Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
|
||||
Rusty Russell <rusty@rustcorp.com.au>,
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
|
||||
Ashok Raj <ashok.raj@intel.com>,
|
||||
Joel Schopp <jschopp@austin.ibm.com>
|
||||
Rusty Russell <rusty@rustcorp.com.au>,
|
||||
Srivatsa Vaddagiri <vatsa@in.ibm.com>,
|
||||
Ashok Raj <ashok.raj@intel.com>,
|
||||
Joel Schopp <jschopp@austin.ibm.com>,
|
||||
Thomas Gleixner <tglx@linutronix.de>
|
||||
|
||||
Introduction
|
||||
============
|
||||
@ -91,9 +92,10 @@ Never use anything other than ``cpumask_t`` to represent bitmap of CPUs.
|
||||
|
||||
Using CPU hotplug
|
||||
=================
|
||||
|
||||
The kernel option *CONFIG_HOTPLUG_CPU* needs to be enabled. It is currently
|
||||
available on multiple architectures including ARM, MIPS, PowerPC and X86. The
|
||||
configuration is done via the sysfs interface: ::
|
||||
configuration is done via the sysfs interface::
|
||||
|
||||
$ ls -lh /sys/devices/system/cpu
|
||||
total 0
|
||||
@ -113,14 +115,14 @@ configuration is done via the sysfs interface: ::
|
||||
|
||||
The files *offline*, *online*, *possible*, *present* represent the CPU masks.
|
||||
Each CPU folder contains an *online* file which controls the logical on (1) and
|
||||
off (0) state. To logically shutdown CPU4: ::
|
||||
off (0) state. To logically shutdown CPU4::
|
||||
|
||||
$ echo 0 > /sys/devices/system/cpu/cpu4/online
|
||||
smpboot: CPU 4 is now offline
|
||||
|
||||
Once the CPU is shutdown, it will be removed from */proc/interrupts*,
|
||||
*/proc/cpuinfo* and should also not be shown visible by the *top* command. To
|
||||
bring CPU4 back online: ::
|
||||
bring CPU4 back online::
|
||||
|
||||
$ echo 1 > /sys/devices/system/cpu/cpu4/online
|
||||
smpboot: Booting Node 0 Processor 4 APIC 0x1
|
||||
@ -142,6 +144,7 @@ The CPU hotplug coordination
|
||||
|
||||
The offline case
|
||||
----------------
|
||||
|
||||
Once a CPU has been logically shutdown the teardown callbacks of registered
|
||||
hotplug states will be invoked, starting with ``CPUHP_ONLINE`` and terminating
|
||||
at state ``CPUHP_OFFLINE``. This includes:
|
||||
@ -156,105 +159,491 @@ at state ``CPUHP_OFFLINE``. This includes:
|
||||
* Once all services are migrated, kernel calls an arch specific routine
|
||||
``__cpu_disable()`` to perform arch specific cleanup.
|
||||
|
||||
Using the hotplug API
|
||||
---------------------
|
||||
It is possible to receive notifications once a CPU is offline or onlined. This
|
||||
might be important to certain drivers which need to perform some kind of setup
|
||||
or clean up functions based on the number of available CPUs: ::
|
||||
|
||||
#include <linux/cpuhotplug.h>
|
||||
The CPU hotplug API
|
||||
===================
|
||||
|
||||
ret = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "X/Y:online",
|
||||
Y_online, Y_prepare_down);
|
||||
CPU hotplug state machine
|
||||
-------------------------
|
||||
|
||||
*X* is the subsystem and *Y* the particular driver. The *Y_online* callback
|
||||
will be invoked during registration on all online CPUs. If an error
|
||||
occurs during the online callback the *Y_prepare_down* callback will be
|
||||
invoked on all CPUs on which the online callback was previously invoked.
|
||||
After registration completed, the *Y_online* callback will be invoked
|
||||
once a CPU is brought online and *Y_prepare_down* will be invoked when a
|
||||
CPU is shutdown. All resources which were previously allocated in
|
||||
*Y_online* should be released in *Y_prepare_down*.
|
||||
The return value *ret* is negative if an error occurred during the
|
||||
registration process. Otherwise a positive value is returned which
|
||||
contains the allocated hotplug for dynamically allocated states
|
||||
(*CPUHP_AP_ONLINE_DYN*). It will return zero for predefined states.
|
||||
CPU hotplug uses a trivial state machine with a linear state space from
|
||||
CPUHP_OFFLINE to CPUHP_ONLINE. Each state has a startup and a teardown
|
||||
callback.
|
||||
|
||||
The callback can be remove by invoking ``cpuhp_remove_state()``. In case of a
|
||||
dynamically allocated state (*CPUHP_AP_ONLINE_DYN*) use the returned state.
|
||||
During the removal of a hotplug state the teardown callback will be invoked.
|
||||
When a CPU is onlined, the startup callbacks are invoked sequentially until
|
||||
the state CPUHP_ONLINE is reached. They can also be invoked when the
|
||||
callbacks of a state are set up or an instance is added to a multi-instance
|
||||
state.
|
||||
|
||||
Multiple instances
|
||||
~~~~~~~~~~~~~~~~~~
|
||||
If a driver has multiple instances and each instance needs to perform the
|
||||
callback independently then it is likely that a ''multi-state'' should be used.
|
||||
First a multi-state state needs to be registered: ::
|
||||
When a CPU is offlined the teardown callbacks are invoked in the reverse
|
||||
order sequentially until the state CPUHP_OFFLINE is reached. They can also
|
||||
be invoked when the callbacks of a state are removed or an instance is
|
||||
removed from a multi-instance state.
|
||||
|
||||
ret = cpuhp_setup_state_multi(CPUHP_AP_ONLINE_DYN, "X/Y:online,
|
||||
Y_online, Y_prepare_down);
|
||||
Y_hp_online = ret;
|
||||
If a usage site requires only a callback in one direction of the hotplug
|
||||
operations (CPU online or CPU offline) then the other not-required callback
|
||||
can be set to NULL when the state is set up.
|
||||
|
||||
The ``cpuhp_setup_state_multi()`` behaves similar to ``cpuhp_setup_state()``
|
||||
except it prepares the callbacks for a multi state and does not invoke
|
||||
the callbacks. This is a one time setup.
|
||||
Once a new instance is allocated, you need to register this new instance: ::
|
||||
The state space is divided into three sections:
|
||||
|
||||
ret = cpuhp_state_add_instance(Y_hp_online, &d->node);
|
||||
* The PREPARE section
|
||||
|
||||
This function will add this instance to your previously allocated
|
||||
*Y_hp_online* state and invoke the previously registered callback
|
||||
(*Y_online*) on all online CPUs. The *node* element is a ``struct
|
||||
hlist_node`` member of your per-instance data structure.
|
||||
The PREPARE section covers the state space from CPUHP_OFFLINE to
|
||||
CPUHP_BRINGUP_CPU.
|
||||
|
||||
On removal of the instance: ::
|
||||
cpuhp_state_remove_instance(Y_hp_online, &d->node)
|
||||
The startup callbacks in this section are invoked before the CPU is
|
||||
started during a CPU online operation. The teardown callbacks are invoked
|
||||
after the CPU has become dysfunctional during a CPU offline operation.
|
||||
|
||||
should be invoked which will invoke the teardown callback on all online
|
||||
CPUs.
|
||||
The callbacks are invoked on a control CPU as they can't obviously run on
|
||||
the hotplugged CPU which is either not yet started or has become
|
||||
dysfunctional already.
|
||||
|
||||
Manual setup
|
||||
~~~~~~~~~~~~
|
||||
Usually it is handy to invoke setup and teardown callbacks on registration or
|
||||
removal of a state because usually the operation needs to performed once a CPU
|
||||
goes online (offline) and during initial setup (shutdown) of the driver. However
|
||||
each registration and removal function is also available with a ``_nocalls``
|
||||
suffix which does not invoke the provided callbacks if the invocation of the
|
||||
callbacks is not desired. During the manual setup (or teardown) the functions
|
||||
``cpus_read_lock()`` and ``cpus_read_unlock()`` should be used to inhibit CPU
|
||||
hotplug operations.
|
||||
The startup callbacks are used to setup resources which are required to
|
||||
bring a CPU successfully online. The teardown callbacks are used to free
|
||||
resources or to move pending work to an online CPU after the hotplugged
|
||||
CPU became dysfunctional.
|
||||
|
||||
The startup callbacks are allowed to fail. If a callback fails, the CPU
|
||||
online operation is aborted and the CPU is brought down to the previous
|
||||
state (usually CPUHP_OFFLINE) again.
|
||||
|
||||
The ordering of the events
|
||||
--------------------------
|
||||
The hotplug states are defined in ``include/linux/cpuhotplug.h``:
|
||||
The teardown callbacks in this section are not allowed to fail.
|
||||
|
||||
* The states *CPUHP_OFFLINE* … *CPUHP_AP_OFFLINE* are invoked before the
|
||||
CPU is up.
|
||||
* The states *CPUHP_AP_OFFLINE* … *CPUHP_AP_ONLINE* are invoked
|
||||
just the after the CPU has been brought up. The interrupts are off and
|
||||
the scheduler is not yet active on this CPU. Starting with *CPUHP_AP_OFFLINE*
|
||||
the callbacks are invoked on the target CPU.
|
||||
* The states between *CPUHP_AP_ONLINE_DYN* and *CPUHP_AP_ONLINE_DYN_END* are
|
||||
reserved for the dynamic allocation.
|
||||
* The states are invoked in the reverse order on CPU shutdown starting with
|
||||
*CPUHP_ONLINE* and stopping at *CPUHP_OFFLINE*. Here the callbacks are
|
||||
invoked on the CPU that will be shutdown until *CPUHP_AP_OFFLINE*.
|
||||
* The STARTING section
|
||||
|
||||
The STARTING section covers the state space between CPUHP_BRINGUP_CPU + 1
|
||||
and CPUHP_AP_ONLINE.
|
||||
|
||||
The startup callbacks in this section are invoked on the hotplugged CPU
|
||||
with interrupts disabled during a CPU online operation in the early CPU
|
||||
setup code. The teardown callbacks are invoked with interrupts disabled
|
||||
on the hotplugged CPU during a CPU offline operation shortly before the
|
||||
CPU is completely shut down.
|
||||
|
||||
The callbacks in this section are not allowed to fail.
|
||||
|
||||
The callbacks are used for low level hardware initialization/shutdown and
|
||||
for core subsystems.
|
||||
|
||||
* The ONLINE section
|
||||
|
||||
The ONLINE section covers the state space between CPUHP_AP_ONLINE + 1 and
|
||||
CPUHP_ONLINE.
|
||||
|
||||
The startup callbacks in this section are invoked on the hotplugged CPU
|
||||
during a CPU online operation. The teardown callbacks are invoked on the
|
||||
hotplugged CPU during a CPU offline operation.
|
||||
|
||||
The callbacks are invoked in the context of the per CPU hotplug thread,
|
||||
which is pinned on the hotplugged CPU. The callbacks are invoked with
|
||||
interrupts and preemption enabled.
|
||||
|
||||
The callbacks are allowed to fail. When a callback fails the hotplug
|
||||
operation is aborted and the CPU is brought back to the previous state.
|
||||
|
||||
CPU online/offline operations
|
||||
-----------------------------
|
||||
|
||||
A successful online operation looks like this::
|
||||
|
||||
[CPUHP_OFFLINE]
|
||||
[CPUHP_OFFLINE + 1]->startup() -> success
|
||||
[CPUHP_OFFLINE + 2]->startup() -> success
|
||||
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
|
||||
...
|
||||
[CPUHP_BRINGUP_CPU]->startup() -> success
|
||||
=== End of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE]->startup() -> success
|
||||
=== End of STARTUP section
|
||||
[CPUHP_AP_ONLINE + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - 1]->startup() -> success
|
||||
[CPUHP_ONLINE]
|
||||
|
||||
A successful offline operation looks like this::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE + 1]->teardown() -> success
|
||||
=== Start of STARTUP section
|
||||
[CPUHP_AP_ONLINE]->teardown() -> success
|
||||
...
|
||||
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
|
||||
...
|
||||
=== Start of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU]->teardown()
|
||||
[CPUHP_OFFLINE + 3]->teardown()
|
||||
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
|
||||
[CPUHP_OFFLINE + 1]->teardown()
|
||||
[CPUHP_OFFLINE]
|
||||
|
||||
A failed online operation looks like this::
|
||||
|
||||
[CPUHP_OFFLINE]
|
||||
[CPUHP_OFFLINE + 1]->startup() -> success
|
||||
[CPUHP_OFFLINE + 2]->startup() -> success
|
||||
[CPUHP_OFFLINE + 3] -> skipped because startup == NULL
|
||||
...
|
||||
[CPUHP_BRINGUP_CPU]->startup() -> success
|
||||
=== End of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU + 1]->startup() -> success
|
||||
...
|
||||
[CPUHP_AP_ONLINE]->startup() -> success
|
||||
=== End of STARTUP section
|
||||
[CPUHP_AP_ONLINE + 1]->startup() -> success
|
||||
---
|
||||
[CPUHP_AP_ONLINE + N]->startup() -> fail
|
||||
[CPUHP_AP_ONLINE + (N - 1)]->teardown()
|
||||
...
|
||||
[CPUHP_AP_ONLINE + 1]->teardown()
|
||||
=== Start of STARTUP section
|
||||
[CPUHP_AP_ONLINE]->teardown()
|
||||
...
|
||||
[CPUHP_BRINGUP_ONLINE - 1]->teardown()
|
||||
...
|
||||
=== Start of PREPARE section
|
||||
[CPUHP_BRINGUP_CPU]->teardown()
|
||||
[CPUHP_OFFLINE + 3]->teardown()
|
||||
[CPUHP_OFFLINE + 2] -> skipped because teardown == NULL
|
||||
[CPUHP_OFFLINE + 1]->teardown()
|
||||
[CPUHP_OFFLINE]
|
||||
|
||||
A failed offline operation looks like this::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup()
|
||||
...
|
||||
[CPUHP_ONLINE - 1]->startup()
|
||||
[CPUHP_ONLINE]
|
||||
|
||||
Recursive failures cannot be handled sensibly. Look at the following
|
||||
example of a recursive fail due to a failed offline operation: ::
|
||||
|
||||
[CPUHP_ONLINE]
|
||||
[CPUHP_ONLINE - 1]->teardown() -> success
|
||||
...
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup() -> success
|
||||
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
|
||||
|
||||
The CPU hotplug state machine stops right here and does not try to go back
|
||||
down again because that would likely result in an endless loop::
|
||||
|
||||
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->startup() -> success
|
||||
[CPUHP_ONLINE - (N - 2)]->startup() -> fail
|
||||
[CPUHP_ONLINE - (N - 1)]->teardown() -> success
|
||||
[CPUHP_ONLINE - N]->teardown() -> fail
|
||||
|
||||
Lather, rinse and repeat. In this case the CPU left in state::
|
||||
|
||||
[CPUHP_ONLINE - (N - 1)]
|
||||
|
||||
which at least lets the system make progress and gives the user a chance to
|
||||
debug or even resolve the situation.
|
||||
|
||||
Allocating a state
|
||||
------------------
|
||||
|
||||
There are two ways to allocate a CPU hotplug state:
|
||||
|
||||
* Static allocation
|
||||
|
||||
Static allocation has to be used when the subsystem or driver has
|
||||
ordering requirements versus other CPU hotplug states. E.g. the PERF core
|
||||
startup callback has to be invoked before the PERF driver startup
|
||||
callbacks during a CPU online operation. During a CPU offline operation
|
||||
the driver teardown callbacks have to be invoked before the core teardown
|
||||
callback. The statically allocated states are described by constants in
|
||||
the cpuhp_state enum which can be found in include/linux/cpuhotplug.h.
|
||||
|
||||
Insert the state into the enum at the proper place so the ordering
|
||||
requirements are fulfilled. The state constant has to be used for state
|
||||
setup and removal.
|
||||
|
||||
Static allocation is also required when the state callbacks are not set
|
||||
up at runtime and are part of the initializer of the CPU hotplug state
|
||||
array in kernel/cpu.c.
|
||||
|
||||
* Dynamic allocation
|
||||
|
||||
When there are no ordering requirements for the state callbacks then
|
||||
dynamic allocation is the preferred method. The state number is allocated
|
||||
by the setup function and returned to the caller on success.
|
||||
|
||||
Only the PREPARE and ONLINE sections provide a dynamic allocation
|
||||
range. The STARTING section does not as most of the callbacks in that
|
||||
section have explicit ordering requirements.
|
||||
|
||||
Setup of a CPU hotplug state
|
||||
----------------------------
|
||||
|
||||
The core code provides the following functions to setup a state:
|
||||
|
||||
* cpuhp_setup_state(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_nocalls(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_cpuslocked(state, name, startup, teardown)
|
||||
* cpuhp_setup_state_nocalls_cpuslocked(state, name, startup, teardown)
|
||||
|
||||
For cases where a driver or a subsystem has multiple instances and the same
|
||||
CPU hotplug state callbacks need to be invoked for each instance, the CPU
|
||||
hotplug core provides multi-instance support. The advantage over driver
|
||||
specific instance lists is that the instance related functions are fully
|
||||
serialized against CPU hotplug operations and provide the automatic
|
||||
invocations of the state callbacks on add and removal. To set up such a
|
||||
multi-instance state the following function is available:
|
||||
|
||||
* cpuhp_setup_state_multi(state, name, startup, teardown)
|
||||
|
||||
The @state argument is either a statically allocated state or one of the
|
||||
constants for dynamically allocated states - CPUHP_PREPARE_DYN,
|
||||
CPUHP_ONLINE_DYN - depending on the state section (PREPARE, ONLINE) for
|
||||
which a dynamic state should be allocated.
|
||||
|
||||
The @name argument is used for sysfs output and for instrumentation. The
|
||||
naming convention is "subsys:mode" or "subsys/driver:mode",
|
||||
e.g. "perf:mode" or "perf/x86:mode". The common mode names are:
|
||||
|
||||
======== =======================================================
|
||||
prepare For states in the PREPARE section
|
||||
|
||||
dead For states in the PREPARE section which do not provide
|
||||
a startup callback
|
||||
|
||||
starting For states in the STARTING section
|
||||
|
||||
dying For states in the STARTING section which do not provide
|
||||
a startup callback
|
||||
|
||||
online For states in the ONLINE section
|
||||
|
||||
offline For states in the ONLINE section which do not provide
|
||||
a startup callback
|
||||
======== =======================================================
|
||||
|
||||
As the @name argument is only used for sysfs and instrumentation other mode
|
||||
descriptors can be used as well if they describe the nature of the state
|
||||
better than the common ones.
|
||||
|
||||
Examples for @name arguments: "perf/online", "perf/x86:prepare",
|
||||
"RCU/tree:dying", "sched/waitempty"
|
||||
|
||||
The @startup argument is a function pointer to the callback which should be
|
||||
invoked during a CPU online operation. If the usage site does not require a
|
||||
startup callback set the pointer to NULL.
|
||||
|
||||
The @teardown argument is a function pointer to the callback which should
|
||||
be invoked during a CPU offline operation. If the usage site does not
|
||||
require a teardown callback set the pointer to NULL.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_setup_state_nocalls(), cpuhp_setup_state_nocalls_cpuslocked()
|
||||
and cpuhp_setup_state_multi() only install the callbacks
|
||||
|
||||
* cpuhp_setup_state() and cpuhp_setup_state_cpuslocked() install the
|
||||
callbacks and invoke the @startup callback (if not NULL) for all online
|
||||
CPUs which have currently a state greater than the newly installed
|
||||
state. Depending on the state section the callback is either invoked on
|
||||
the current CPU (PREPARE section) or on each online CPU (ONLINE
|
||||
section) in the context of the CPU's hotplug thread.
|
||||
|
||||
If a callback fails for CPU N then the teardown callback for CPU
|
||||
0 .. N-1 is invoked to rollback the operation. The state setup fails,
|
||||
the callbacks for the state are not installed and in case of dynamic
|
||||
allocation the allocated state is freed.
|
||||
|
||||
The state setup and the callback invocations are serialized against CPU
|
||||
hotplug operations. If the setup function has to be called from a CPU
|
||||
hotplug read locked region, then the _cpuslocked() variants have to be
|
||||
used. These functions cannot be used from within CPU hotplug callbacks.
|
||||
|
||||
The function return values:
|
||||
======== ===================================================================
|
||||
0 Statically allocated state was successfully set up
|
||||
|
||||
>0 Dynamically allocated state was successfully set up.
|
||||
|
||||
The returned number is the state number which was allocated. If
|
||||
the state callbacks have to be removed later, e.g. module
|
||||
removal, then this number has to be saved by the caller and used
|
||||
as @state argument for the state remove function. For
|
||||
multi-instance states the dynamically allocated state number is
|
||||
also required as @state argument for the instance add/remove
|
||||
operations.
|
||||
|
||||
<0 Operation failed
|
||||
======== ===================================================================
|
||||
|
||||
Removal of a CPU hotplug state
|
||||
------------------------------
|
||||
|
||||
To remove a previously set up state, the following functions are provided:
|
||||
|
||||
* cpuhp_remove_state(state)
|
||||
* cpuhp_remove_state_nocalls(state)
|
||||
* cpuhp_remove_state_nocalls_cpuslocked(state)
|
||||
* cpuhp_remove_multi_state(state)
|
||||
|
||||
The @state argument is either a statically allocated state or the state
|
||||
number which was allocated in the dynamic range by cpuhp_setup_state*(). If
|
||||
the state is in the dynamic range, then the state number is freed and
|
||||
available for dynamic allocation again.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_remove_state_nocalls(), cpuhp_remove_state_nocalls_cpuslocked()
|
||||
and cpuhp_remove_multi_state() only remove the callbacks.
|
||||
|
||||
* cpuhp_remove_state() removes the callbacks and invokes the teardown
|
||||
callback (if not NULL) for all online CPUs which have currently a state
|
||||
greater than the removed state. Depending on the state section the
|
||||
callback is either invoked on the current CPU (PREPARE section) or on
|
||||
each online CPU (ONLINE section) in the context of the CPU's hotplug
|
||||
thread.
|
||||
|
||||
In order to complete the removal, the teardown callback should not fail.
|
||||
|
||||
The state removal and the callback invocations are serialized against CPU
|
||||
hotplug operations. If the remove function has to be called from a CPU
|
||||
hotplug read locked region, then the _cpuslocked() variants have to be
|
||||
used. These functions cannot be used from within CPU hotplug callbacks.
|
||||
|
||||
If a multi-instance state is removed then the caller has to remove all
|
||||
instances first.
|
||||
|
||||
Multi-Instance state instance management
|
||||
----------------------------------------
|
||||
|
||||
Once the multi-instance state is set up, instances can be added to the
|
||||
state:
|
||||
|
||||
* cpuhp_state_add_instance(state, node)
|
||||
* cpuhp_state_add_instance_nocalls(state, node)
|
||||
|
||||
The @state argument is either a statically allocated state or the state
|
||||
number which was allocated in the dynamic range by cpuhp_setup_state_multi().
|
||||
|
||||
The @node argument is a pointer to an hlist_node which is embedded in the
|
||||
instance's data structure. The pointer is handed to the multi-instance
|
||||
state callbacks and can be used by the callback to retrieve the instance
|
||||
via container_of().
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_state_add_instance_nocalls() and only adds the instance to the
|
||||
multi-instance state's node list.
|
||||
|
||||
* cpuhp_state_add_instance() adds the instance and invokes the startup
|
||||
callback (if not NULL) associated with @state for all online CPUs which
|
||||
have currently a state greater than @state. The callback is only
|
||||
invoked for the to be added instance. Depending on the state section
|
||||
the callback is either invoked on the current CPU (PREPARE section) or
|
||||
on each online CPU (ONLINE section) in the context of the CPU's hotplug
|
||||
thread.
|
||||
|
||||
If a callback fails for CPU N then the teardown callback for CPU
|
||||
0 .. N-1 is invoked to rollback the operation, the function fails and
|
||||
the instance is not added to the node list of the multi-instance state.
|
||||
|
||||
To remove an instance from the state's node list these functions are
|
||||
available:
|
||||
|
||||
* cpuhp_state_remove_instance(state, node)
|
||||
* cpuhp_state_remove_instance_nocalls(state, node)
|
||||
|
||||
The arguments are the same as for the the cpuhp_state_add_instance*()
|
||||
variants above.
|
||||
|
||||
The functions differ in the way how the installed callbacks are treated:
|
||||
|
||||
* cpuhp_state_remove_instance_nocalls() only removes the instance from the
|
||||
state's node list.
|
||||
|
||||
* cpuhp_state_remove_instance() removes the instance and invokes the
|
||||
teardown callback (if not NULL) associated with @state for all online
|
||||
CPUs which have currently a state greater than @state. The callback is
|
||||
only invoked for the to be removed instance. Depending on the state
|
||||
section the callback is either invoked on the current CPU (PREPARE
|
||||
section) or on each online CPU (ONLINE section) in the context of the
|
||||
CPU's hotplug thread.
|
||||
|
||||
In order to complete the removal, the teardown callback should not fail.
|
||||
|
||||
The node list add/remove operations and the callback invocations are
|
||||
serialized against CPU hotplug operations. These functions cannot be used
|
||||
from within CPU hotplug callbacks and CPU hotplug read locked regions.
|
||||
|
||||
Examples
|
||||
--------
|
||||
|
||||
Setup and teardown a statically allocated state in the STARTING section for
|
||||
notifications on online and offline operations::
|
||||
|
||||
ret = cpuhp_setup_state(CPUHP_SUBSYS_STARTING, "subsys:starting", subsys_cpu_starting, subsys_cpu_dying);
|
||||
if (ret < 0)
|
||||
return ret;
|
||||
....
|
||||
cpuhp_remove_state(CPUHP_SUBSYS_STARTING);
|
||||
|
||||
Setup and teardown a dynamically allocated state in the ONLINE section
|
||||
for notifications on offline operations::
|
||||
|
||||
state = cpuhp_setup_state(CPUHP_ONLINE_DYN, "subsys:offline", NULL, subsys_cpu_offline);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
cpuhp_remove_state(state);
|
||||
|
||||
Setup and teardown a dynamically allocated state in the ONLINE section
|
||||
for notifications on online operations without invoking the callbacks::
|
||||
|
||||
state = cpuhp_setup_state_nocalls(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, NULL);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
cpuhp_remove_state_nocalls(state);
|
||||
|
||||
Setup, use and teardown a dynamically allocated multi-instance state in the
|
||||
ONLINE section for notifications on online and offline operation::
|
||||
|
||||
state = cpuhp_setup_state_multi(CPUHP_ONLINE_DYN, "subsys:online", subsys_cpu_online, subsys_cpu_offline);
|
||||
if (state < 0)
|
||||
return state;
|
||||
....
|
||||
ret = cpuhp_state_add_instance(state, &inst1->node);
|
||||
if (ret)
|
||||
return ret;
|
||||
....
|
||||
ret = cpuhp_state_add_instance(state, &inst2->node);
|
||||
if (ret)
|
||||
return ret;
|
||||
....
|
||||
cpuhp_remove_instance(state, &inst1->node);
|
||||
....
|
||||
cpuhp_remove_instance(state, &inst2->node);
|
||||
....
|
||||
remove_multi_state(state);
|
||||
|
||||
A dynamically allocated state via *CPUHP_AP_ONLINE_DYN* is often enough.
|
||||
However if an earlier invocation during the bring up or shutdown is required
|
||||
then an explicit state should be acquired. An explicit state might also be
|
||||
required if the hotplug event requires specific ordering in respect to
|
||||
another hotplug event.
|
||||
|
||||
Testing of hotplug states
|
||||
=========================
|
||||
|
||||
One way to verify whether a custom state is working as expected or not is to
|
||||
shutdown a CPU and then put it online again. It is also possible to put the CPU
|
||||
to certain state (for instance *CPUHP_AP_ONLINE*) and then go back to
|
||||
*CPUHP_ONLINE*. This would simulate an error one state after *CPUHP_AP_ONLINE*
|
||||
which would lead to rollback to the online state.
|
||||
|
||||
All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states``: ::
|
||||
All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states`` ::
|
||||
|
||||
$ tail /sys/devices/system/cpu/hotplug/states
|
||||
138: mm/vmscan:online
|
||||
@ -268,7 +657,7 @@ All registered states are enumerated in ``/sys/devices/system/cpu/hotplug/states
|
||||
168: sched:active
|
||||
169: online
|
||||
|
||||
To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue: ::
|
||||
To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue::
|
||||
|
||||
$ cat /sys/devices/system/cpu/cpu4/hotplug/state
|
||||
169
|
||||
@ -276,14 +665,14 @@ To rollback CPU4 to ``lib/percpu_cnt:online`` and back online just issue: ::
|
||||
$ cat /sys/devices/system/cpu/cpu4/hotplug/state
|
||||
140
|
||||
|
||||
It is important to note that the teardown callbac of state 140 have been
|
||||
invoked. And now get back online: ::
|
||||
It is important to note that the teardown callback of state 140 have been
|
||||
invoked. And now get back online::
|
||||
|
||||
$ echo 169 > /sys/devices/system/cpu/cpu4/hotplug/target
|
||||
$ cat /sys/devices/system/cpu/cpu4/hotplug/state
|
||||
169
|
||||
|
||||
With trace events enabled, the individual steps are visible, too: ::
|
||||
With trace events enabled, the individual steps are visible, too::
|
||||
|
||||
# TASK-PID CPU# TIMESTAMP FUNCTION
|
||||
# | | | | |
|
||||
@ -318,6 +707,7 @@ trace.
|
||||
|
||||
Architecture's requirements
|
||||
===========================
|
||||
|
||||
The following functions and configurations are required:
|
||||
|
||||
``CONFIG_HOTPLUG_CPU``
|
||||
@ -339,11 +729,12 @@ The following functions and configurations are required:
|
||||
|
||||
User Space Notification
|
||||
=======================
|
||||
After CPU successfully onlined or offline udev events are sent. A udev rule like: ::
|
||||
|
||||
After CPU successfully onlined or offline udev events are sent. A udev rule like::
|
||||
|
||||
SUBSYSTEM=="cpu", DRIVERS=="processor", DEVPATH=="/devices/system/cpu/*", RUN+="the_hotplug_receiver.sh"
|
||||
|
||||
will receive all events. A script like: ::
|
||||
will receive all events. A script like::
|
||||
|
||||
#!/bin/sh
|
||||
|
||||
|
@ -315,6 +315,9 @@ Block Devices
|
||||
.. kernel-doc:: block/genhd.c
|
||||
:export:
|
||||
|
||||
.. kernel-doc:: block/bdev.c
|
||||
:export:
|
||||
|
||||
Char devices
|
||||
============
|
||||
|
||||
|
@ -130,6 +130,7 @@ printed after the symbol name with an extra ``b`` appended to the end of the
|
||||
specifier.
|
||||
|
||||
::
|
||||
|
||||
%pS versatile_init+0x0/0x110 [module_name]
|
||||
%pSb versatile_init+0x0/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e]
|
||||
%pSRb versatile_init+0x9/0x110 [module_name ed5019fdf5e53be37cb1ba7899292d7e143b259e]
|
||||
@ -579,7 +580,7 @@ Flags bitfields such as page flags, gfp_flags
|
||||
|
||||
::
|
||||
|
||||
%pGp referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff
|
||||
%pGp 0x17ffffc0002036(referenced|uptodate|lru|active|private|node=0|zone=2|lastcpupid=0x1fffff)
|
||||
%pGg GFP_USER|GFP_DMA32|GFP_NOWARN
|
||||
%pGv read|exec|mayread|maywrite|mayexec|denywrite
|
||||
|
||||
|
@ -75,9 +75,6 @@ And optionally
|
||||
.resume - A pointer to a per-policy resume function which is called
|
||||
with interrupts disabled and _before_ the governor is started again.
|
||||
|
||||
.ready - A pointer to a per-policy ready function which is called after
|
||||
the policy is fully initialized.
|
||||
|
||||
.attr - A pointer to a NULL-terminated list of "struct freq_attr" which
|
||||
allow to export values to sysfs.
|
||||
|
||||
|
@ -181,9 +181,16 @@ By default, KASAN prints a bug report only for the first invalid memory access.
|
||||
With ``kasan_multi_shot``, KASAN prints a report on every invalid access. This
|
||||
effectively disables ``panic_on_warn`` for KASAN reports.
|
||||
|
||||
Alternatively, independent of ``panic_on_warn`` the ``kasan.fault=`` boot
|
||||
parameter can be used to control panic and reporting behaviour:
|
||||
|
||||
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
|
||||
report or also panic the kernel (default: ``report``). The panic happens even
|
||||
if ``kasan_multi_shot`` is enabled.
|
||||
|
||||
Hardware tag-based KASAN mode (see the section about various modes below) is
|
||||
intended for use in production as a security mitigation. Therefore, it supports
|
||||
boot parameters that allow disabling KASAN or controlling its features.
|
||||
additional boot parameters that allow disabling KASAN or controlling features:
|
||||
|
||||
- ``kasan=off`` or ``=on`` controls whether KASAN is enabled (default: ``on``).
|
||||
|
||||
@ -199,10 +206,6 @@ boot parameters that allow disabling KASAN or controlling its features.
|
||||
- ``kasan.stacktrace=off`` or ``=on`` disables or enables alloc and free stack
|
||||
traces collection (default: ``on``).
|
||||
|
||||
- ``kasan.fault=report`` or ``=panic`` controls whether to only print a KASAN
|
||||
report or also panic the kernel (default: ``report``). The panic happens even
|
||||
if ``kasan_multi_shot`` is enabled.
|
||||
|
||||
Implementation details
|
||||
----------------------
|
||||
|
||||
|
@ -127,6 +127,18 @@ Kconfig options:
|
||||
causes KCSAN to not report data races due to conflicts where the only plain
|
||||
accesses are aligned writes up to word size.
|
||||
|
||||
* ``CONFIG_KCSAN_PERMISSIVE``: Enable additional permissive rules to ignore
|
||||
certain classes of common data races. Unlike the above, the rules are more
|
||||
complex involving value-change patterns, access type, and address. This
|
||||
option depends on ``CONFIG_KCSAN_REPORT_VALUE_CHANGE_ONLY=y``. For details
|
||||
please see the ``kernel/kcsan/permissive.h``. Testers and maintainers that
|
||||
only focus on reports from specific subsystems and not the whole kernel are
|
||||
recommended to disable this option.
|
||||
|
||||
To use the strictest possible rules, select ``CONFIG_KCSAN_STRICT=y``, which
|
||||
configures KCSAN to follow the Linux-kernel memory consistency model (LKMM) as
|
||||
closely as possible.
|
||||
|
||||
DebugFS interface
|
||||
~~~~~~~~~~~~~~~~~
|
||||
|
||||
|
@ -65,25 +65,27 @@ Error reports
|
||||
A typical out-of-bounds access looks like this::
|
||||
|
||||
==================================================================
|
||||
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa3/0x22b
|
||||
BUG: KFENCE: out-of-bounds read in test_out_of_bounds_read+0xa6/0x234
|
||||
|
||||
Out-of-bounds read at 0xffffffffb672efff (1B left of kfence-#17):
|
||||
test_out_of_bounds_read+0xa3/0x22b
|
||||
kunit_try_run_case+0x51/0x85
|
||||
Out-of-bounds read at 0xffff8c3f2e291fff (1B left of kfence-#72):
|
||||
test_out_of_bounds_read+0xa6/0x234
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#17 [0xffffffffb672f000-0xffffffffb672f01f, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
test_out_of_bounds_read+0x98/0x22b
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kfence-#72: 0xffff8c3f2e292000-0xffff8c3f2e29201f, size=32, cache=kmalloc-32
|
||||
|
||||
allocated by task 484 on cpu 0 at 32.919330s:
|
||||
test_alloc+0xfe/0x738
|
||||
test_out_of_bounds_read+0x9b/0x234
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 107 Comm: kunit_try_catch Not tainted 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
CPU: 0 PID: 484 Comm: kunit_try_catch Not tainted 5.13.0-rc3+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
||||
==================================================================
|
||||
|
||||
The header of the report provides a short summary of the function involved in
|
||||
@ -96,30 +98,32 @@ Use-after-free accesses are reported as::
|
||||
==================================================================
|
||||
BUG: KFENCE: use-after-free read in test_use_after_free_read+0xb3/0x143
|
||||
|
||||
Use-after-free read at 0xffffffffb673dfe0 (in kfence-#24):
|
||||
Use-after-free read at 0xffff8c3f2e2a0000 (in kfence-#79):
|
||||
test_use_after_free_read+0xb3/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#24 [0xffffffffb673dfe0-0xffffffffb673dfff, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
kfence-#79: 0xffff8c3f2e2a0000-0xffff8c3f2e2a001f, size=32, cache=kmalloc-32
|
||||
|
||||
allocated by task 488 on cpu 2 at 33.871326s:
|
||||
test_alloc+0xfe/0x738
|
||||
test_use_after_free_read+0x76/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
freed by task 507:
|
||||
freed by task 488 on cpu 2 at 33.871358s:
|
||||
test_use_after_free_read+0xa8/0x143
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 109 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
CPU: 2 PID: 488 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
||||
==================================================================
|
||||
|
||||
KFENCE also reports on invalid frees, such as double-frees::
|
||||
@ -127,30 +131,32 @@ KFENCE also reports on invalid frees, such as double-frees::
|
||||
==================================================================
|
||||
BUG: KFENCE: invalid free in test_double_free+0xdc/0x171
|
||||
|
||||
Invalid free of 0xffffffffb6741000:
|
||||
Invalid free of 0xffff8c3f2e2a4000 (in kfence-#81):
|
||||
test_double_free+0xdc/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#26 [0xffffffffb6741000-0xffffffffb674101f, size=32, cache=kmalloc-32] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
kfence-#81: 0xffff8c3f2e2a4000-0xffff8c3f2e2a401f, size=32, cache=kmalloc-32
|
||||
|
||||
allocated by task 490 on cpu 1 at 34.175321s:
|
||||
test_alloc+0xfe/0x738
|
||||
test_double_free+0x76/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
freed by task 507:
|
||||
freed by task 490 on cpu 1 at 34.175348s:
|
||||
test_double_free+0xa8/0x171
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 111 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
CPU: 1 PID: 490 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
||||
==================================================================
|
||||
|
||||
KFENCE also uses pattern-based redzones on the other side of an object's guard
|
||||
@ -160,23 +166,25 @@ These are reported on frees::
|
||||
==================================================================
|
||||
BUG: KFENCE: memory corruption in test_kmalloc_aligned_oob_write+0xef/0x184
|
||||
|
||||
Corrupted memory at 0xffffffffb6797ff9 [ 0xac . . . . . . ] (in kfence-#69):
|
||||
Corrupted memory at 0xffff8c3f2e33aff9 [ 0xac . . . . . . ] (in kfence-#156):
|
||||
test_kmalloc_aligned_oob_write+0xef/0x184
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
kfence-#69 [0xffffffffb6797fb0-0xffffffffb6797ff8, size=73, cache=kmalloc-96] allocated by task 507:
|
||||
test_alloc+0xf3/0x25b
|
||||
kfence-#156: 0xffff8c3f2e33afb0-0xffff8c3f2e33aff8, size=73, cache=kmalloc-96
|
||||
|
||||
allocated by task 502 on cpu 7 at 42.159302s:
|
||||
test_alloc+0xfe/0x738
|
||||
test_kmalloc_aligned_oob_write+0x57/0x184
|
||||
kunit_try_run_case+0x51/0x85
|
||||
kunit_try_run_case+0x61/0xa0
|
||||
kunit_generic_run_threadfn_adapter+0x16/0x30
|
||||
kthread+0x137/0x160
|
||||
kthread+0x176/0x1b0
|
||||
ret_from_fork+0x22/0x30
|
||||
|
||||
CPU: 4 PID: 120 Comm: kunit_try_catch Tainted: G W 5.8.0-rc6+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1 04/01/2014
|
||||
CPU: 7 PID: 502 Comm: kunit_try_catch Tainted: G B 5.13.0-rc3+ #7
|
||||
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-2 04/01/2014
|
||||
==================================================================
|
||||
|
||||
For such errors, the address where the corruption occurred as well as the
|
||||
|
@ -114,9 +114,12 @@ results in TAP format, you can pass the ``--raw_output`` argument.
|
||||
|
||||
./tools/testing/kunit/kunit.py run --raw_output
|
||||
|
||||
.. note::
|
||||
The raw output from test runs may contain other, non-KUnit kernel log
|
||||
lines.
|
||||
The raw output from test runs may contain other, non-KUnit kernel log
|
||||
lines. You can see just KUnit output with ``--raw_output=kunit``:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
./tools/testing/kunit/kunit.py run --raw_output=kunit
|
||||
|
||||
If you have KUnit results in their raw TAP format, you can parse them and print
|
||||
the human-readable summary with the ``parse`` command for kunit_tool. This
|
||||
|
@ -80,6 +80,16 @@ file ``.kunitconfig``, you can just pass in the dir, e.g.
|
||||
automagically, but tests could theoretically depend on incompatible
|
||||
options, so handling that would be tricky.
|
||||
|
||||
Setting kernel commandline parameters
|
||||
-------------------------------------
|
||||
|
||||
You can use ``--kernel_args`` to pass arbitrary kernel arguments, e.g.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ./tools/testing/kunit/kunit.py run --kernel_args=param=42 --kernel_args=param2=false
|
||||
|
||||
|
||||
Generating code coverage reports under UML
|
||||
------------------------------------------
|
||||
|
||||
|
@ -13,6 +13,7 @@ Required Properties:
|
||||
- "mediatek,mt7623-audsys", "mediatek,mt2701-audsys", "syscon"
|
||||
- "mediatek,mt8167-audiosys", "syscon"
|
||||
- "mediatek,mt8183-audiosys", "syscon"
|
||||
- "mediatek,mt8192-audsys", "syscon"
|
||||
- "mediatek,mt8516-audsys", "syscon"
|
||||
- #clock-cells: Must be 1
|
||||
|
||||
|
@ -29,6 +29,7 @@ properties:
|
||||
- mediatek,mt8167-mmsys
|
||||
- mediatek,mt8173-mmsys
|
||||
- mediatek,mt8183-mmsys
|
||||
- mediatek,mt8192-mmsys
|
||||
- mediatek,mt8365-mmsys
|
||||
- const: syscon
|
||||
- items:
|
||||
|
@ -0,0 +1,199 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: MediaTek Functional Clock Controller for MT8192
|
||||
|
||||
maintainers:
|
||||
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
|
||||
|
||||
description:
|
||||
The Mediatek functional clock controller provides various clocks on MT8192.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- mediatek,mt8192-scp_adsp
|
||||
- mediatek,mt8192-imp_iic_wrap_c
|
||||
- mediatek,mt8192-imp_iic_wrap_e
|
||||
- mediatek,mt8192-imp_iic_wrap_s
|
||||
- mediatek,mt8192-imp_iic_wrap_ws
|
||||
- mediatek,mt8192-imp_iic_wrap_w
|
||||
- mediatek,mt8192-imp_iic_wrap_n
|
||||
- mediatek,mt8192-msdc_top
|
||||
- mediatek,mt8192-msdc
|
||||
- mediatek,mt8192-mfgcfg
|
||||
- mediatek,mt8192-imgsys
|
||||
- mediatek,mt8192-imgsys2
|
||||
- mediatek,mt8192-vdecsys_soc
|
||||
- mediatek,mt8192-vdecsys
|
||||
- mediatek,mt8192-vencsys
|
||||
- mediatek,mt8192-camsys
|
||||
- mediatek,mt8192-camsys_rawa
|
||||
- mediatek,mt8192-camsys_rawb
|
||||
- mediatek,mt8192-camsys_rawc
|
||||
- mediatek,mt8192-ipesys
|
||||
- mediatek,mt8192-mdpsys
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
scp_adsp: clock-controller@10720000 {
|
||||
compatible = "mediatek,mt8192-scp_adsp";
|
||||
reg = <0x10720000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_c: clock-controller@11007000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_c";
|
||||
reg = <0x11007000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_e: clock-controller@11cb1000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_e";
|
||||
reg = <0x11cb1000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_s: clock-controller@11d03000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_s";
|
||||
reg = <0x11d03000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_ws: clock-controller@11d23000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_ws";
|
||||
reg = <0x11d23000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_w: clock-controller@11e01000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_w";
|
||||
reg = <0x11e01000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imp_iic_wrap_n: clock-controller@11f02000 {
|
||||
compatible = "mediatek,mt8192-imp_iic_wrap_n";
|
||||
reg = <0x11f02000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
msdc_top: clock-controller@11f10000 {
|
||||
compatible = "mediatek,mt8192-msdc_top";
|
||||
reg = <0x11f10000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
msdc: clock-controller@11f60000 {
|
||||
compatible = "mediatek,mt8192-msdc";
|
||||
reg = <0x11f60000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
mfgcfg: clock-controller@13fbf000 {
|
||||
compatible = "mediatek,mt8192-mfgcfg";
|
||||
reg = <0x13fbf000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imgsys: clock-controller@15020000 {
|
||||
compatible = "mediatek,mt8192-imgsys";
|
||||
reg = <0x15020000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
imgsys2: clock-controller@15820000 {
|
||||
compatible = "mediatek,mt8192-imgsys2";
|
||||
reg = <0x15820000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
vdecsys_soc: clock-controller@1600f000 {
|
||||
compatible = "mediatek,mt8192-vdecsys_soc";
|
||||
reg = <0x1600f000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
vdecsys: clock-controller@1602f000 {
|
||||
compatible = "mediatek,mt8192-vdecsys";
|
||||
reg = <0x1602f000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
vencsys: clock-controller@17000000 {
|
||||
compatible = "mediatek,mt8192-vencsys";
|
||||
reg = <0x17000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
camsys: clock-controller@1a000000 {
|
||||
compatible = "mediatek,mt8192-camsys";
|
||||
reg = <0x1a000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
camsys_rawa: clock-controller@1a04f000 {
|
||||
compatible = "mediatek,mt8192-camsys_rawa";
|
||||
reg = <0x1a04f000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
camsys_rawb: clock-controller@1a06f000 {
|
||||
compatible = "mediatek,mt8192-camsys_rawb";
|
||||
reg = <0x1a06f000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
camsys_rawc: clock-controller@1a08f000 {
|
||||
compatible = "mediatek,mt8192-camsys_rawc";
|
||||
reg = <0x1a08f000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
ipesys: clock-controller@1b000000 {
|
||||
compatible = "mediatek,mt8192-ipesys";
|
||||
reg = <0x1b000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
mdpsys: clock-controller@1f000000 {
|
||||
compatible = "mediatek,mt8192-mdpsys";
|
||||
reg = <0x1f000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
@ -0,0 +1,65 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/arm/mediatek/mediatek,mt8192-sys-clock.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: MediaTek System Clock Controller for MT8192
|
||||
|
||||
maintainers:
|
||||
- Chun-Jie Chen <chun-jie.chen@mediatek.com>
|
||||
|
||||
description:
|
||||
The Mediatek system clock controller provides various clocks and system configuration
|
||||
like reset and bus protection on MT8192.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- mediatek,mt8192-topckgen
|
||||
- mediatek,mt8192-infracfg
|
||||
- mediatek,mt8192-pericfg
|
||||
- mediatek,mt8192-apmixedsys
|
||||
- const: syscon
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
topckgen: syscon@10000000 {
|
||||
compatible = "mediatek,mt8192-topckgen", "syscon";
|
||||
reg = <0x10000000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
infracfg: syscon@10001000 {
|
||||
compatible = "mediatek,mt8192-infracfg", "syscon";
|
||||
reg = <0x10001000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
pericfg: syscon@10003000 {
|
||||
compatible = "mediatek,mt8192-pericfg", "syscon";
|
||||
reg = <0x10003000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
- |
|
||||
apmixedsys: syscon@1000c000 {
|
||||
compatible = "mediatek,mt8192-apmixedsys", "syscon";
|
||||
reg = <0x1000c000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
@ -12,7 +12,10 @@ maintainers:
|
||||
description:
|
||||
The Hitachi HD44780 Character LCD Controller is commonly used on character
|
||||
LCDs that can display one or more lines of text. It exposes an M6800 bus
|
||||
interface, which can be used in either 4-bit or 8-bit mode.
|
||||
interface, which can be used in either 4-bit or 8-bit mode. By using a
|
||||
GPIO expander it is possible to use the driver with one of the popular I2C
|
||||
expander boards based on the PCF8574 available for these displays. For
|
||||
an example see below.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
@ -94,3 +97,29 @@ examples:
|
||||
display-height-chars = <2>;
|
||||
display-width-chars = <16>;
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
pcf8574: pcf8574@27 {
|
||||
compatible = "nxp,pcf8574";
|
||||
reg = <0x27>;
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
};
|
||||
};
|
||||
hd44780 {
|
||||
compatible = "hit,hd44780";
|
||||
display-height-chars = <2>;
|
||||
display-width-chars = <16>;
|
||||
data-gpios = <&pcf8574 4 0>,
|
||||
<&pcf8574 5 0>,
|
||||
<&pcf8574 6 0>,
|
||||
<&pcf8574 7 0>;
|
||||
enable-gpios = <&pcf8574 2 0>;
|
||||
rs-gpios = <&pcf8574 0 0>;
|
||||
rw-gpios = <&pcf8574 1 0>;
|
||||
backlight-gpios = <&pcf8574 3 0>;
|
||||
};
|
||||
|
@ -61,13 +61,30 @@ properties:
|
||||
maxItems: 1
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
true
|
||||
|
||||
clock-output-names:
|
||||
minItems: 1
|
||||
maxItems: 45
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- brcm,cygnus-armpll
|
||||
- brcm,nsp-armpll
|
||||
then:
|
||||
properties:
|
||||
'#clock-cells':
|
||||
const: 0
|
||||
else:
|
||||
properties:
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
required:
|
||||
- clock-output-names
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
@ -358,7 +375,6 @@ required:
|
||||
- reg
|
||||
- clocks
|
||||
- '#clock-cells'
|
||||
- clock-output-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
@ -392,3 +408,10 @@ examples:
|
||||
clocks = <&osc2>;
|
||||
clock-output-names = "keypad", "adc/touch", "pwm";
|
||||
};
|
||||
- |
|
||||
arm_clk@0 {
|
||||
#clock-cells = <0>;
|
||||
compatible = "brcm,nsp-armpll";
|
||||
clocks = <&osc>;
|
||||
reg = <0x0 0x1000>;
|
||||
};
|
||||
|
@ -1,103 +0,0 @@
|
||||
* Samsung Audio Subsystem Clock Controller
|
||||
|
||||
The Samsung Audio Subsystem clock controller generates and supplies clocks
|
||||
to Audio Subsystem block available in the S5PV210 and Exynos SoCs. The clock
|
||||
binding described here is applicable to all SoCs in Exynos family.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following:
|
||||
- "samsung,exynos4210-audss-clock" - controller compatible with all Exynos4 SoCs.
|
||||
- "samsung,exynos5250-audss-clock" - controller compatible with Exynos5250
|
||||
SoCs.
|
||||
- "samsung,exynos5410-audss-clock" - controller compatible with Exynos5410
|
||||
SoCs.
|
||||
- "samsung,exynos5420-audss-clock" - controller compatible with Exynos5420
|
||||
SoCs.
|
||||
- reg: physical base address and length of the controller's register set.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
- clocks:
|
||||
- pll_ref: Fixed rate PLL reference clock, parent of mout_audss. "fin_pll"
|
||||
is used if not specified.
|
||||
- pll_in: Input PLL to the AudioSS block, parent of mout_audss. "fout_epll"
|
||||
is used if not specified.
|
||||
- cdclk: External i2s clock, parent of mout_i2s. "cdclk0" is used if not
|
||||
specified.
|
||||
- sclk_audio: Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if
|
||||
not specified.
|
||||
- sclk_pcm_in: PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not
|
||||
specified.
|
||||
|
||||
- clock-names: Aliases for the above clocks. They should be "pll_ref",
|
||||
"pll_in", "cdclk", "sclk_audio", and "sclk_pcm_in" respectively.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- power-domains: a phandle to respective power domain node as described by
|
||||
generic PM domain bindings (see power/power_domain.txt for more
|
||||
information).
|
||||
|
||||
The following is the list of clocks generated by the controller. Each clock is
|
||||
assigned an identifier and client nodes use this identifier to specify the
|
||||
clock which they consume. Some of the clocks are available only on a particular
|
||||
Exynos4 SoC and this is specified where applicable.
|
||||
|
||||
Provided clocks:
|
||||
|
||||
Clock ID SoC (if specific)
|
||||
-----------------------------------------------
|
||||
|
||||
mout_audss 0
|
||||
mout_i2s 1
|
||||
dout_srp 2
|
||||
dout_aud_bus 3
|
||||
dout_i2s 4
|
||||
srp_clk 5
|
||||
i2s_bus 6
|
||||
sclk_i2s 7
|
||||
pcm_bus 8
|
||||
sclk_pcm 9
|
||||
adma 10 Exynos5420
|
||||
|
||||
Example 1: An example of a clock controller node using the default input
|
||||
clock names is listed below.
|
||||
|
||||
clock_audss: audss-clock-controller@3810000 {
|
||||
compatible = "samsung,exynos5250-audss-clock";
|
||||
reg = <0x03810000 0x0C>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: An example of a clock controller node with the input clocks
|
||||
specified.
|
||||
|
||||
clock_audss: audss-clock-controller@3810000 {
|
||||
compatible = "samsung,exynos5250-audss-clock";
|
||||
reg = <0x03810000 0x0C>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>,
|
||||
<&ext_i2s_clk>;
|
||||
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
|
||||
};
|
||||
|
||||
Example 3: I2S controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
i2s0: i2s@3830000 {
|
||||
compatible = "samsung,i2s-v5";
|
||||
reg = <0x03830000 0x100>;
|
||||
dmas = <&pdma0 10
|
||||
&pdma0 9
|
||||
&pdma0 8>;
|
||||
dma-names = "tx", "rx", "tx-sec";
|
||||
clocks = <&clock_audss EXYNOS_I2S_BUS>,
|
||||
<&clock_audss EXYNOS_I2S_BUS>,
|
||||
<&clock_audss EXYNOS_SCLK_I2S>,
|
||||
<&clock_audss EXYNOS_MOUT_AUDSS>,
|
||||
<&clock_audss EXYNOS_MOUT_I2S>;
|
||||
clock-names = "iis", "i2s_opclk0", "i2s_opclk1",
|
||||
"mout_audss", "mout_i2s";
|
||||
};
|
@ -1,53 +0,0 @@
|
||||
* Samsung Audio Subsystem Clock Controller
|
||||
|
||||
The Samsung Audio Subsystem clock controller generates and supplies clocks
|
||||
to Audio Subsystem block available in the S5PV210 and compatible SoCs.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "samsung,s5pv210-audss-clock".
|
||||
- reg: physical base address and length of the controller's register set.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
- clocks:
|
||||
- hclk: AHB bus clock of the Audio Subsystem.
|
||||
- xxti: Optional fixed rate PLL reference clock, parent of mout_audss. If
|
||||
not specified (i.e. xusbxti is used for PLL reference), it is fixed to
|
||||
a clock named "xxti".
|
||||
- fout_epll: Input PLL to the AudioSS block, parent of mout_audss.
|
||||
- iiscdclk0: Optional external i2s clock, parent of mout_i2s. If not
|
||||
specified, it is fixed to a clock named "iiscdclk0".
|
||||
- sclk_audio0: Audio bus clock, parent of mout_i2s.
|
||||
|
||||
- clock-names: Aliases for the above clocks. They should be "hclk",
|
||||
"xxti", "fout_epll", "iiscdclk0", and "sclk_audio0" respectively.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/s5pv210-audss-clk.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example: Clock controller node.
|
||||
|
||||
clk_audss: clock-controller@c0900000 {
|
||||
compatible = "samsung,s5pv210-audss-clock";
|
||||
reg = <0xc0900000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
clock-names = "hclk", "xxti",
|
||||
"fout_epll", "sclk_audio0";
|
||||
clocks = <&clocks DOUT_HCLKP>, <&xxti>,
|
||||
<&clocks FOUT_EPLL>, <&clocks SCLK_AUDIO0>;
|
||||
};
|
||||
|
||||
Example: I2S controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
i2s0: i2s@3830000 {
|
||||
/* ... */
|
||||
clock-names = "iis", "i2s_opclk0",
|
||||
"i2s_opclk1";
|
||||
clocks = <&clk_audss CLK_I2S>, <&clk_audss CLK_I2S>,
|
||||
<&clk_audss CLK_DOUT_AUD_BUS>;
|
||||
/* ... */
|
||||
};
|
@ -1,57 +0,0 @@
|
||||
* Samsung Exynos3250 Clock Controller
|
||||
|
||||
The Exynos3250 clock controller generates and supplies clock to various
|
||||
controllers within the Exynos3250 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "samsung,exynos3250-cmu" - controller compatible with Exynos3250 SoC.
|
||||
- "samsung,exynos3250-cmu-dmc" - controller compatible with
|
||||
Exynos3250 SoC for Dynamic Memory Controller domain.
|
||||
- "samsung,exynos3250-cmu-isp" - ISP block clock controller compatible
|
||||
with Exynos3250 SOC
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/exynos3250.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example 1: Examples of clock controller nodes are listed below.
|
||||
|
||||
cmu: clock-controller@10030000 {
|
||||
compatible = "samsung,exynos3250-cmu";
|
||||
reg = <0x10030000 0x20000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_dmc: clock-controller@105c0000 {
|
||||
compatible = "samsung,exynos3250-cmu-dmc";
|
||||
reg = <0x105C0000 0x2000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
cmu_isp: clock-controller@10048000 {
|
||||
compatible = "samsung,exynos3250-cmu-isp";
|
||||
reg = <0x10048000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: UART controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
serial@13800000 {
|
||||
compatible = "samsung,exynos4210-uart";
|
||||
reg = <0x13800000 0x100>;
|
||||
interrupts = <0 109 0>;
|
||||
clocks = <&cmu CLK_UART0>, <&cmu CLK_SCLK_UART0>;
|
||||
clock-names = "uart", "clk_uart_baud0";
|
||||
};
|
@ -1,86 +0,0 @@
|
||||
* Samsung Exynos4 Clock Controller
|
||||
|
||||
The Exynos4 clock controller generates and supplies clock to various controllers
|
||||
within the Exynos4 SoC. The clock binding described here is applicable to all
|
||||
SoC's in the Exynos4 family.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "samsung,exynos4210-clock" - controller compatible with Exynos4210 SoC.
|
||||
- "samsung,exynos4412-clock" - controller compatible with Exynos4412 SoC.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/exynos4.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example 1: An example of a clock controller node is listed below.
|
||||
|
||||
clock: clock-controller@10030000 {
|
||||
compatible = "samsung,exynos4210-clock";
|
||||
reg = <0x10030000 0x20000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: UART controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
serial@13820000 {
|
||||
compatible = "samsung,exynos4210-uart";
|
||||
reg = <0x13820000 0x100>;
|
||||
interrupts = <0 54 0>;
|
||||
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
|
||||
clock-names = "uart", "clk_uart_baud0";
|
||||
};
|
||||
|
||||
Exynos4412 SoC contains some additional clocks for FIMC-ISP (Camera ISP)
|
||||
subsystem. Registers for those clocks are located in the ISP power domain.
|
||||
Because those registers are also located in a different memory region than
|
||||
the main clock controller, a separate clock controller has to be defined for
|
||||
handling them.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be "samsung,exynos4412-isp-clock".
|
||||
|
||||
- reg: physical base address of the ISP clock controller and length of memory
|
||||
mapped region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
- clocks: list of the clock controller input clock identifiers,
|
||||
from common clock bindings, should point to CLK_ACLK200 and
|
||||
CLK_ACLK400_MCUISP clocks from the main clock controller.
|
||||
|
||||
- clock-names: list of the clock controller input clock names,
|
||||
as described in clock-bindings.txt, should be "aclk200" and
|
||||
"aclk400_mcuisp".
|
||||
|
||||
- power-domains: a phandle to ISP power domain node as described by
|
||||
generic PM domain bindings.
|
||||
|
||||
Example 3: The clock controllers bindings for Exynos4412 SoCs.
|
||||
|
||||
clock: clock-controller@10030000 {
|
||||
compatible = "samsung,exynos4412-clock";
|
||||
reg = <0x10030000 0x18000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
isp_clock: clock-controller@10048000 {
|
||||
compatible = "samsung,exynos4412-isp-clock";
|
||||
reg = <0x10048000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
power-domains = <&pd_isp>;
|
||||
clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>;
|
||||
clock-names = "aclk200", "aclk400_mcuisp";
|
||||
};
|
@ -1,41 +0,0 @@
|
||||
* Samsung Exynos5250 Clock Controller
|
||||
|
||||
The Exynos5250 clock controller generates and supplies clock to various
|
||||
controllers within the Exynos5250 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "samsung,exynos5250-clock" - controller compatible with Exynos5250 SoC.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/exynos5250.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example 1: An example of a clock controller node is listed below.
|
||||
|
||||
clock: clock-controller@10010000 {
|
||||
compatible = "samsung,exynos5250-clock";
|
||||
reg = <0x10010000 0x30000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: UART controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
serial@13820000 {
|
||||
compatible = "samsung,exynos4210-uart";
|
||||
reg = <0x13820000 0x100>;
|
||||
interrupts = <0 54 0>;
|
||||
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
|
||||
clock-names = "uart", "clk_uart_baud0";
|
||||
};
|
@ -1,42 +0,0 @@
|
||||
* Samsung Exynos5420 Clock Controller
|
||||
|
||||
The Exynos5420 clock controller generates and supplies clock to various
|
||||
controllers within the Exynos5420 SoC and for the Exynos5800 SoC.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: should be one of the following.
|
||||
- "samsung,exynos5420-clock" - controller compatible with Exynos5420 SoC.
|
||||
- "samsung,exynos5800-clock" - controller compatible with Exynos5800 SoC.
|
||||
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
|
||||
- #clock-cells: should be 1.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume.
|
||||
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/exynos5420.h header and can be used in device
|
||||
tree sources.
|
||||
|
||||
Example 1: An example of a clock controller node is listed below.
|
||||
|
||||
clock: clock-controller@10010000 {
|
||||
compatible = "samsung,exynos5420-clock";
|
||||
reg = <0x10010000 0x30000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
||||
|
||||
Example 2: UART controller node that consumes the clock generated by the clock
|
||||
controller. Refer to the standard clock bindings for information
|
||||
about 'clocks' and 'clock-names' property.
|
||||
|
||||
serial@13820000 {
|
||||
compatible = "samsung,exynos4210-uart";
|
||||
reg = <0x13820000 0x100>;
|
||||
interrupts = <0 54 0>;
|
||||
clocks = <&clock CLK_UART2>, <&clock CLK_SCLK_UART2>;
|
||||
clock-names = "uart", "clk_uart_baud0";
|
||||
};
|
@ -30,6 +30,20 @@ description: |
|
||||
3 -- OUT3
|
||||
4 -- OUT4
|
||||
|
||||
The idt,shutdown and idt,output-enable-active properties control the
|
||||
SH (en_global_shutdown) and SP bits of the Primary Source and Shutdown
|
||||
Register, respectively. Their behavior is summarized by the following
|
||||
table:
|
||||
|
||||
SH SP Output when the SD/OE pin is Low/High
|
||||
== == =====================================
|
||||
0 0 Active/Inactive
|
||||
0 1 Inactive/Active
|
||||
1 0 Active/Shutdown
|
||||
1 1 Inactive/Shutdown
|
||||
|
||||
The case where SH and SP are both 1 is likely not very interesting.
|
||||
|
||||
maintainers:
|
||||
- Luca Ceresoli <luca@lucaceresoli.net>
|
||||
|
||||
@ -64,6 +78,26 @@ properties:
|
||||
maximum: 22760
|
||||
description: Optional load capacitor for XTAL1 and XTAL2
|
||||
|
||||
idt,shutdown:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1]
|
||||
description: |
|
||||
If 1, this enables the shutdown functionality: the chip will be
|
||||
shut down if the SD/OE pin is driven high. If 0, this disables the
|
||||
shutdown functionality: the chip will never be shut down based on
|
||||
the value of the SD/OE pin. This property corresponds to the SH
|
||||
bit of the Primary Source and Shutdown Register.
|
||||
|
||||
idt,output-enable-active:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [0, 1]
|
||||
description: |
|
||||
If 1, this enables output when the SD/OE pin is high, and disables
|
||||
output when the SD/OE pin is low. If 0, this disables output when
|
||||
the SD/OE pin is high, and enables output when the SD/OE pin is
|
||||
low. This corresponds to the SP bit of the Primary Source and
|
||||
Shutdown Register.
|
||||
|
||||
patternProperties:
|
||||
"^OUT[1-4]$":
|
||||
type: object
|
||||
@ -90,6 +124,8 @@ required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- idt,shutdown
|
||||
- idt,output-enable-active
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
@ -139,6 +175,10 @@ examples:
|
||||
clocks = <&ref25m>;
|
||||
clock-names = "xin";
|
||||
|
||||
/* Set the SD/OE pin's settings */
|
||||
idt,shutdown = <0>;
|
||||
idt,output-enable-active = <0>;
|
||||
|
||||
OUT1 {
|
||||
idt,mode = <VC5_CMOSD>;
|
||||
idt,voltage-microvolt = <1800000>;
|
||||
|
@ -18,6 +18,7 @@ properties:
|
||||
enum:
|
||||
- qcom,ipq6018-a53pll
|
||||
- qcom,msm8916-a53pll
|
||||
- qcom,msm8939-a53pll
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -33,6 +34,8 @@ properties:
|
||||
items:
|
||||
- const: xo
|
||||
|
||||
operating-points-v2: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
72
Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml
Normal file
72
Documentation/devicetree/bindings/clock/qcom,gcc-sm6115.yaml
Normal file
@ -0,0 +1,72 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6115.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller Binding for SM6115 and SM4250
|
||||
|
||||
maintainers:
|
||||
- Iskren Chernev <iskren.chernev@gmail.com>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module which supports the clocks, resets and
|
||||
power domains on SM4250/6115.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,gcc-sm6115.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-sm6115
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Sleep clock source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: sleep_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
protected-clocks:
|
||||
description:
|
||||
Protected clock specifier list as per common clock binding.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
clock-controller@1400000 {
|
||||
compatible = "qcom,gcc-sm6115";
|
||||
reg = <0x01400000 0x1f0000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
clock-names = "bi_tcxo", "sleep_clk";
|
||||
clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>, <&sleep_clk>;
|
||||
};
|
||||
...
|
76
Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml
Normal file
76
Documentation/devicetree/bindings/clock/qcom,gcc-sm6350.yaml
Normal file
@ -0,0 +1,76 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gcc-sm6350.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Global Clock & Reset Controller Binding for SM6350
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konrad.dybcio@somainline.org>
|
||||
|
||||
description: |
|
||||
Qualcomm global clock control module which supports the clocks, resets and
|
||||
power domains on SM6350.
|
||||
|
||||
See also:
|
||||
- dt-bindings/clock/qcom,gcc-sm6350.h
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,gcc-sm6350
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: Board active XO source
|
||||
- description: Sleep clock source
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: bi_tcxo_ao
|
||||
- const: sleep_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
protected-clocks:
|
||||
description:
|
||||
Protected clock specifier list as per common clock binding.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- reg
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@100000 {
|
||||
compatible = "qcom,gcc-sm6350";
|
||||
reg = <0x00100000 0x1f0000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&rpmhcc RPMH_CXO_CLK_A>,
|
||||
<&sleep_clk>;
|
||||
clock-names = "bi_tcxo", "bi_tcxo_ao", "sleep_clk";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
@ -23,6 +23,7 @@ description: |
|
||||
- dt-bindings/clock/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
|
||||
- dt-bindings/reset/qcom,gcc-ipq806x.h (qcom,gcc-ipq8064)
|
||||
- dt-bindings/clock/qcom,gcc-msm8939.h
|
||||
- dt-bindings/clock/qcom,gcc-msm8953.h
|
||||
- dt-bindings/reset/qcom,gcc-msm8939.h
|
||||
- dt-bindings/clock/qcom,gcc-msm8660.h
|
||||
- dt-bindings/reset/qcom,gcc-msm8660.h
|
||||
@ -46,6 +47,7 @@ properties:
|
||||
- qcom,gcc-msm8660
|
||||
- qcom,gcc-msm8916
|
||||
- qcom,gcc-msm8939
|
||||
- qcom,gcc-msm8953
|
||||
- qcom,gcc-msm8960
|
||||
- qcom,gcc-msm8974
|
||||
- qcom,gcc-msm8974pro
|
||||
|
@ -1,4 +1,4 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,gpucc.yaml#
|
||||
@ -11,11 +11,12 @@ maintainers:
|
||||
|
||||
description: |
|
||||
Qualcomm graphics clock control module which supports the clocks, resets and
|
||||
power domains on SDM845/SC7180/SM8150/SM8250.
|
||||
power domains on Qualcomm SoCs.
|
||||
|
||||
See also:
|
||||
dt-bindings/clock/qcom,gpucc-sdm845.h
|
||||
dt-bindings/clock/qcom,gpucc-sc7180.h
|
||||
dt-bindings/clock/qcom,gpucc-sc7280.h
|
||||
dt-bindings/clock/qcom,gpucc-sm8150.h
|
||||
dt-bindings/clock/qcom,gpucc-sm8250.h
|
||||
|
||||
@ -24,6 +25,8 @@ properties:
|
||||
enum:
|
||||
- qcom,sdm845-gpucc
|
||||
- qcom,sc7180-gpucc
|
||||
- qcom,sc7280-gpucc
|
||||
- qcom,sc8180x-gpucc
|
||||
- qcom,sm8150-gpucc
|
||||
- qcom,sm8250-gpucc
|
||||
|
||||
|
@ -22,6 +22,8 @@ properties:
|
||||
- qcom,mmcc-msm8660
|
||||
- qcom,mmcc-msm8960
|
||||
- qcom,mmcc-msm8974
|
||||
- qcom,mmcc-msm8992
|
||||
- qcom,mmcc-msm8994
|
||||
- qcom,mmcc-msm8996
|
||||
- qcom,mmcc-msm8998
|
||||
- qcom,mmcc-sdm630
|
||||
|
@ -10,11 +10,13 @@ Required properties :
|
||||
- compatible : shall contain only one of the following. The generic
|
||||
compatible "qcom,rpmcc" should be also included.
|
||||
|
||||
"qcom,rpmcc-mdm9607", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8660", "qcom,rpmcc"
|
||||
"qcom,rpmcc-apq8060", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8226", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8916", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8936", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8953", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8974", "qcom,rpmcc"
|
||||
"qcom,rpmcc-msm8976", "qcom,rpmcc"
|
||||
"qcom,rpmcc-apq8064", "qcom,rpmcc"
|
||||
@ -25,6 +27,8 @@ Required properties :
|
||||
"qcom,rpmcc-msm8998", "qcom,rpmcc"
|
||||
"qcom,rpmcc-qcs404", "qcom,rpmcc"
|
||||
"qcom,rpmcc-sdm660", "qcom,rpmcc"
|
||||
"qcom,rpmcc-sm6115", "qcom,rpmcc"
|
||||
"qcom,rpmcc-sm6125", "qcom,rpmcc"
|
||||
|
||||
- #clock-cells : shall contain 1
|
||||
|
||||
|
@ -22,6 +22,7 @@ properties:
|
||||
- qcom,sc8180x-rpmh-clk
|
||||
- qcom,sdm845-rpmh-clk
|
||||
- qcom,sdx55-rpmh-clk
|
||||
- qcom,sm6350-rpmh-clk
|
||||
- qcom,sm8150-rpmh-clk
|
||||
- qcom,sm8250-rpmh-clk
|
||||
- qcom,sm8350-rpmh-clk
|
||||
|
@ -0,0 +1,94 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,sc7280-dispcc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm Display Clock & Reset Controller Binding for SC7280
|
||||
|
||||
maintainers:
|
||||
- Taniya Das <tdas@codeaurora.org>
|
||||
|
||||
description: |
|
||||
Qualcomm display clock control module which supports the clocks, resets and
|
||||
power domains on SC7280.
|
||||
|
||||
See also dt-bindings/clock/qcom,dispcc-sc7280.h.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sc7280-dispcc
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Board XO source
|
||||
- description: GPLL0 source from GCC
|
||||
- description: Byte clock from DSI PHY
|
||||
- description: Pixel clock from DSI PHY
|
||||
- description: Link clock from DP PHY
|
||||
- description: VCO DIV clock from DP PHY
|
||||
- description: Link clock from EDP PHY
|
||||
- description: VCO DIV clock from EDP PHY
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bi_tcxo
|
||||
- const: gcc_disp_gpll0_clk
|
||||
- const: dsi0_phy_pll_out_byteclk
|
||||
- const: dsi0_phy_pll_out_dsiclk
|
||||
- const: dp_phy_pll_link_clk
|
||||
- const: dp_phy_pll_vco_div_clk
|
||||
- const: edp_phy_pll_link_clk
|
||||
- const: edp_phy_pll_vco_div_clk
|
||||
|
||||
'#clock-cells':
|
||||
const: 1
|
||||
|
||||
'#reset-cells':
|
||||
const: 1
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
- '#clock-cells'
|
||||
- '#reset-cells'
|
||||
- '#power-domain-cells'
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-sc7280.h>
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
clock-controller@af00000 {
|
||||
compatible = "qcom,sc7280-dispcc";
|
||||
reg = <0x0af00000 0x200000>;
|
||||
clocks = <&rpmhcc RPMH_CXO_CLK>,
|
||||
<&gcc GCC_DISP_GPLL0_CLK_SRC>,
|
||||
<&dsi_phy 0>,
|
||||
<&dsi_phy 1>,
|
||||
<&dp_phy 0>,
|
||||
<&dp_phy 1>,
|
||||
<&edp_phy 0>,
|
||||
<&edp_phy 1>;
|
||||
clock-names = "bi_tcxo",
|
||||
"gcc_disp_gpll0_clk",
|
||||
"dsi0_phy_pll_out_byteclk",
|
||||
"dsi0_phy_pll_out_dsiclk",
|
||||
"dp_phy_pll_link_clk",
|
||||
"dp_phy_pll_vco_div_clk",
|
||||
"edp_phy_pll_link_clk",
|
||||
"edp_phy_pll_vco_div_clk";
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
#power-domain-cells = <1>;
|
||||
};
|
||||
...
|
@ -1,4 +1,4 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/qcom,videocc.yaml#
|
||||
@ -11,10 +11,11 @@ maintainers:
|
||||
|
||||
description: |
|
||||
Qualcomm video clock control module which supports the clocks, resets and
|
||||
power domains on SDM845/SC7180/SM8150/SM8250.
|
||||
power domains on Qualcomm SoCs.
|
||||
|
||||
See also:
|
||||
dt-bindings/clock/qcom,videocc-sc7180.h
|
||||
dt-bindings/clock/qcom,videocc-sc7280.h
|
||||
dt-bindings/clock/qcom,videocc-sdm845.h
|
||||
dt-bindings/clock/qcom,videocc-sm8150.h
|
||||
dt-bindings/clock/qcom,videocc-sm8250.h
|
||||
@ -23,6 +24,7 @@ properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sc7180-videocc
|
||||
- qcom,sc7280-videocc
|
||||
- qcom,sdm845-videocc
|
||||
- qcom,sm8150-videocc
|
||||
- qcom,sm8250-videocc
|
||||
|
@ -1,68 +0,0 @@
|
||||
* Rockchip RK3399 Clock and Reset Unit
|
||||
|
||||
The RK3399 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
|
||||
Required Properties:
|
||||
|
||||
- compatible: PMU for CRU should be "rockchip,rk3399-pmucru"
|
||||
- compatible: CRU should be "rockchip,rk3399-cru"
|
||||
- reg: physical base address of the controller and length of memory mapped
|
||||
region.
|
||||
- #clock-cells: should be 1.
|
||||
- #reset-cells: should be 1.
|
||||
|
||||
Optional Properties:
|
||||
|
||||
- rockchip,grf: phandle to the syscon managing the "general register files".
|
||||
It is used for GRF muxes, if missing any muxes present in the GRF will not
|
||||
be available.
|
||||
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All available clocks are defined as
|
||||
preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
|
||||
External clocks:
|
||||
|
||||
There are several clocks that are generated outside the SoC. It is expected
|
||||
that they are defined using standard clock bindings with following
|
||||
clock-output-names:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "clkin_gmac" - external GMAC clock - optional,
|
||||
- "clkin_i2s" - external I2S clock - optional,
|
||||
- "pclkin_cif" - external ISP clock - optional,
|
||||
- "clk_usbphy0_480m" - output clock of the pll in the usbphy0
|
||||
- "clk_usbphy1_480m" - output clock of the pll in the usbphy1
|
||||
|
||||
Example: Clock controller node:
|
||||
|
||||
pmucru: pmu-clock-controller@ff750000 {
|
||||
compatible = "rockchip,rk3399-pmucru";
|
||||
reg = <0x0 0xff750000 0x0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
cru: clock-controller@ff760000 {
|
||||
compatible = "rockchip,rk3399-cru";
|
||||
reg = <0x0 0xff760000 0x0 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
|
||||
Example: UART controller node that consumes the clock generated by the clock
|
||||
controller:
|
||||
|
||||
uart0: serial@ff1a0000 {
|
||||
compatible = "rockchip,rk3399-uart", "snps,dw-apb-uart";
|
||||
reg = <0x0 0xff180000 0x0 0x100>;
|
||||
clocks = <&cru SCLK_UART0>, <&cru PCLK_UART0>;
|
||||
clock-names = "baudclk", "apb_pclk";
|
||||
interrupts = <GIC_SPI 99 IRQ_TYPE_LEVEL_HIGH>;
|
||||
reg-shift = <2>;
|
||||
reg-io-width = <4>;
|
||||
};
|
@ -0,0 +1,92 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/rockchip,rk3399-cru.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Rockchip RK3399 Clock and Reset Unit
|
||||
|
||||
maintainers:
|
||||
- Xing Zheng <zhengxing@rock-chips.com>
|
||||
- Heiko Stuebner <heiko@sntech.de>
|
||||
|
||||
description: |
|
||||
The RK3399 clock controller generates and supplies clock to various
|
||||
controllers within the SoC and also implements a reset controller for SoC
|
||||
peripherals.
|
||||
Each clock is assigned an identifier and client nodes can use this identifier
|
||||
to specify the clock which they consume. All available clocks are defined as
|
||||
preprocessor macros in the dt-bindings/clock/rk3399-cru.h headers and can be
|
||||
used in device tree sources. Similar macros exist for the reset sources in
|
||||
these files.
|
||||
There are several clocks that are generated outside the SoC. It is expected
|
||||
that they are defined using standard clock bindings with following
|
||||
clock-output-names:
|
||||
- "xin24m" - crystal input - required,
|
||||
- "xin32k" - rtc clock - optional,
|
||||
- "clkin_gmac" - external GMAC clock - optional,
|
||||
- "clkin_i2s" - external I2S clock - optional,
|
||||
- "pclkin_cif" - external ISP clock - optional,
|
||||
- "clk_usbphy0_480m" - output clock of the pll in the usbphy0
|
||||
- "clk_usbphy1_480m" - output clock of the pll in the usbphy1
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- rockchip,rk3399-pmucru
|
||||
- rockchip,rk3399-cru
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
"#reset-cells":
|
||||
const: 1
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
|
||||
assigned-clocks:
|
||||
minItems: 1
|
||||
maxItems: 64
|
||||
|
||||
assigned-clock-parents:
|
||||
minItems: 1
|
||||
maxItems: 64
|
||||
|
||||
assigned-clock-rates:
|
||||
minItems: 1
|
||||
maxItems: 64
|
||||
|
||||
rockchip,grf:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle
|
||||
description: >
|
||||
phandle to the syscon managing the "general register files". It is used
|
||||
for GRF muxes, if missing any muxes present in the GRF will not be
|
||||
available.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#clock-cells"
|
||||
- "#reset-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
pmucru: pmu-clock-controller@ff750000 {
|
||||
compatible = "rockchip,rk3399-pmucru";
|
||||
reg = <0xff750000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
||||
- |
|
||||
cru: clock-controller@ff760000 {
|
||||
compatible = "rockchip,rk3399-cru";
|
||||
reg = <0xff760000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
#reset-cells = <1>;
|
||||
};
|
@ -0,0 +1,80 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,exynos-audss-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung Exynos SoC Audio SubSystem clock controller
|
||||
|
||||
maintainers:
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
- Tomasz Figa <tomasz.figa@gmail.com>
|
||||
|
||||
description: |
|
||||
All available clocks are defined as preprocessor macros in
|
||||
include/dt-bindings/clock/exynos-audss-clk.h header.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,exynos4210-audss-clock
|
||||
- samsung,exynos5250-audss-clock
|
||||
- samsung,exynos5410-audss-clock
|
||||
- samsung,exynos5420-audss-clock
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
items:
|
||||
- description:
|
||||
Fixed rate PLL reference clock, parent of mout_audss. "fin_pll" is
|
||||
used if not specified.
|
||||
- description:
|
||||
Input PLL to the AudioSS block, parent of mout_audss. "fout_epll" is
|
||||
used if not specified.
|
||||
- description:
|
||||
Audio bus clock, parent of mout_i2s. "sclk_audio0" is used if not
|
||||
specified.
|
||||
- description:
|
||||
PCM clock, parent of sclk_pcm. "sclk_pcm0" is used if not specified.
|
||||
- description:
|
||||
External i2s clock, parent of mout_i2s. "cdclk0" is used if not
|
||||
specified.
|
||||
|
||||
clock-names:
|
||||
minItems: 2
|
||||
items:
|
||||
- const: pll_ref
|
||||
- const: pll_in
|
||||
- const: sclk_audio
|
||||
- const: sclk_pcm_in
|
||||
- const: cdclk
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- "#clock-cells"
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
clock-controller@3810000 {
|
||||
compatible = "samsung,exynos5250-audss-clock";
|
||||
reg = <0x03810000 0x0c>;
|
||||
#clock-cells = <1>;
|
||||
clocks = <&clock 1>, <&clock 7>, <&clock 138>, <&clock 160>, <&ext_i2s_clk>;
|
||||
clock-names = "pll_ref", "pll_in", "sclk_audio", "sclk_pcm_in", "cdclk";
|
||||
};
|
@ -0,0 +1,59 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,exynos-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung Exynos SoC clock controller
|
||||
|
||||
maintainers:
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
- Tomasz Figa <tomasz.figa@gmail.com>
|
||||
|
||||
description: |
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/ headers.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- enum:
|
||||
- samsung,exynos3250-cmu
|
||||
- samsung,exynos3250-cmu-dmc
|
||||
- samsung,exynos3250-cmu-isp
|
||||
- samsung,exynos4210-clock
|
||||
- samsung,exynos4412-clock
|
||||
- samsung,exynos5250-clock
|
||||
- items:
|
||||
- enum:
|
||||
- samsung,exynos5420-clock
|
||||
- samsung,exynos5800-clock
|
||||
- const: syscon
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 4
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/exynos5250.h>
|
||||
clock: clock-controller@10010000 {
|
||||
compatible = "samsung,exynos5250-clock";
|
||||
reg = <0x10010000 0x30000>;
|
||||
#clock-cells = <1>;
|
||||
};
|
@ -0,0 +1,46 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,exynos-ext-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung SoC external/osc/XXTI/XusbXTI clock
|
||||
|
||||
maintainers:
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
- Tomasz Figa <tomasz.figa@gmail.com>
|
||||
|
||||
description: |
|
||||
Samsung SoCs require an external clock supplied through XXTI or XusbXTI pins.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- samsung,clock-xxti
|
||||
- samsung,clock-xusbxti
|
||||
- samsung,exynos5420-oscclk
|
||||
|
||||
"#clock-cells":
|
||||
const: 0
|
||||
|
||||
clock-frequency: true
|
||||
|
||||
clock-output-names:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clock-frequency
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
fixed-rate-clocks {
|
||||
clock {
|
||||
compatible = "samsung,clock-xxti";
|
||||
clock-frequency = <24000000>;
|
||||
};
|
||||
};
|
@ -0,0 +1,64 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,exynos4412-isp-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung Exynos4412 SoC ISP clock controller
|
||||
|
||||
maintainers:
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
- Tomasz Figa <tomasz.figa@gmail.com>
|
||||
|
||||
description: |
|
||||
Clock controller for Samsung Exynos4412 SoC FIMC-ISP (Camera ISP)
|
||||
All available clocks are defined as preprocessor macros in
|
||||
dt-bindings/clock/ headers.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: samsung,exynos4412-isp-clock
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: CLK_ACLK200 from the main clock controller
|
||||
- description: CLK_ACLK400_MCUISP from the main clock controller
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: aclk200
|
||||
- const: aclk400_mcuisp
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- "#clock-cells"
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/exynos4.h>
|
||||
clock-controller@10048000 {
|
||||
compatible = "samsung,exynos4412-isp-clock";
|
||||
reg = <0x10048000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
power-domains = <&pd_isp>;
|
||||
clocks = <&clock CLK_ACLK200>, <&clock CLK_ACLK400_MCUISP>;
|
||||
clock-names = "aclk200", "aclk400_mcuisp";
|
||||
};
|
||||
|
@ -0,0 +1,78 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/clock/samsung,s5pv210-audss-clock.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Samsung S5Pv210 SoC Audio SubSystem clock controller
|
||||
|
||||
maintainers:
|
||||
- Chanwoo Choi <cw00.choi@samsung.com>
|
||||
- Krzysztof Kozlowski <krzysztof.kozlowski@canonical.com>
|
||||
- Sylwester Nawrocki <s.nawrocki@samsung.com>
|
||||
- Tomasz Figa <tomasz.figa@gmail.com>
|
||||
|
||||
description: |
|
||||
All available clocks are defined as preprocessor macros in
|
||||
include/dt-bindings/clock/s5pv210-audss.h header.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: samsung,s5pv210-audss-clock
|
||||
|
||||
clocks:
|
||||
minItems: 4
|
||||
items:
|
||||
- description:
|
||||
AHB bus clock of the Audio Subsystem.
|
||||
- description:
|
||||
Optional fixed rate PLL reference clock, parent of mout_audss. If not
|
||||
specified (i.e. xusbxti is used for PLL reference), it is fixed to a
|
||||
clock named "xxti".
|
||||
- description:
|
||||
Input PLL to the AudioSS block, parent of mout_audss.
|
||||
- description:
|
||||
Audio bus clock, parent of mout_i2s.
|
||||
- description:
|
||||
Optional external i2s clock, parent of mout_i2s. If not specified, it
|
||||
is fixed to a clock named "iiscdclk0".
|
||||
|
||||
clock-names:
|
||||
minItems: 4
|
||||
items:
|
||||
- const: hclk
|
||||
- const: xxti
|
||||
- const: fout_epll
|
||||
- const: sclk_audio0
|
||||
- const: iiscdclk0
|
||||
|
||||
"#clock-cells":
|
||||
const: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- clocks
|
||||
- clock-names
|
||||
- "#clock-cells"
|
||||
- reg
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/s5pv210.h>
|
||||
|
||||
clock-controller@c0900000 {
|
||||
compatible = "samsung,s5pv210-audss-clock";
|
||||
reg = <0xc0900000 0x1000>;
|
||||
#clock-cells = <1>;
|
||||
clock-names = "hclk", "xxti", "fout_epll", "sclk_audio0";
|
||||
clocks = <&clocks DOUT_HCLKP>, <&xxti>, <&clocks FOUT_EPLL>,
|
||||
<&clocks SCLK_AUDIO0>;
|
||||
};
|
@ -11,7 +11,7 @@ Required properties:
|
||||
- None
|
||||
|
||||
Optional properties:
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp.txt for
|
||||
- operating-points: Refer to Documentation/devicetree/bindings/opp/opp-v1.yaml for
|
||||
details. OPPs *must* be supplied either via DT, i.e. this property, or
|
||||
populated at runtime.
|
||||
- clock-latency: Specify the possible maximum transition latency for clock,
|
||||
|
@ -0,0 +1,70 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/cpufreq/cpufreq-mediatek-hw.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MediaTek's CPUFREQ Bindings
|
||||
|
||||
maintainers:
|
||||
- Hector Yuan <hector.yuan@mediatek.com>
|
||||
|
||||
description:
|
||||
CPUFREQ HW is a hardware engine used by MediaTek SoCs to
|
||||
manage frequency in hardware. It is capable of controlling
|
||||
frequency for multiple clusters.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mediatek,cpufreq-hw
|
||||
|
||||
reg:
|
||||
minItems: 1
|
||||
maxItems: 2
|
||||
description:
|
||||
Addresses and sizes for the memory of the HW bases in
|
||||
each frequency domain. Each entry corresponds to
|
||||
a register bank for each frequency domain present.
|
||||
|
||||
"#performance-domain-cells":
|
||||
description:
|
||||
Number of cells in a performance domain specifier.
|
||||
Set const to 1 here for nodes providing multiple
|
||||
performance domains.
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- "#performance-domain-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
cpus {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
cpu0: cpu@0 {
|
||||
device_type = "cpu";
|
||||
compatible = "arm,cortex-a55";
|
||||
enable-method = "psci";
|
||||
performance-domains = <&performance 0>;
|
||||
reg = <0x000>;
|
||||
};
|
||||
};
|
||||
|
||||
/* ... */
|
||||
|
||||
soc {
|
||||
#address-cells = <2>;
|
||||
#size-cells = <2>;
|
||||
|
||||
performance: performance-controller@11bc00 {
|
||||
compatible = "mediatek,cpufreq-hw";
|
||||
reg = <0 0x0011bc10 0 0x120>, <0 0x0011bd30 0 0x120>;
|
||||
|
||||
#performance-domain-cells = <1>;
|
||||
};
|
||||
};
|
@ -10,7 +10,7 @@ Required properties:
|
||||
transition and not stable yet.
|
||||
Please refer to Documentation/devicetree/bindings/clock/clock-bindings.txt for
|
||||
generic clock consumer properties.
|
||||
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
- operating-points-v2: Please refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
|
||||
for detail.
|
||||
- proc-supply: Regulator for Vproc of CPU cluster.
|
||||
|
||||
|
@ -6,8 +6,6 @@ from the SoC, then supplies the OPP framework with 'prop' and 'supported
|
||||
hardware' information respectively. The framework is then able to read
|
||||
the DT and operate in the usual way.
|
||||
|
||||
For more information about the expected DT format [See: ../opp/opp.txt].
|
||||
|
||||
Frequency Scaling only
|
||||
----------------------
|
||||
|
||||
@ -15,7 +13,7 @@ No vendor specific driver required for this.
|
||||
|
||||
Located in CPU's node:
|
||||
|
||||
- operating-points : [See: ../power/opp.txt]
|
||||
- operating-points : [See: ../power/opp-v1.yaml]
|
||||
|
||||
Example [safe]
|
||||
--------------
|
||||
@ -37,7 +35,7 @@ This requires the ST CPUFreq driver to supply 'process' and 'version' info.
|
||||
|
||||
Located in CPU's node:
|
||||
|
||||
- operating-points-v2 : [See ../power/opp.txt]
|
||||
- operating-points-v2 : [See ../power/opp-v2.yaml]
|
||||
|
||||
Example [unsafe]
|
||||
----------------
|
||||
|
@ -4,7 +4,7 @@ Binding for NVIDIA Tegra20 CPUFreq
|
||||
Required properties:
|
||||
- clocks: Must contain an entry for the CPU clock.
|
||||
See ../clocks/clock-bindings.txt for details.
|
||||
- operating-points-v2: See ../bindings/opp/opp.txt for details.
|
||||
- operating-points-v2: See ../bindings/opp/opp-v2.yaml for details.
|
||||
- #cooling-cells: Should be 2. See ../thermal/thermal-cooling-devices.yaml for details.
|
||||
|
||||
For each opp entry in 'operating-points-v2' table:
|
||||
|
@ -8,7 +8,7 @@ Required properties:
|
||||
- clocks: Phandles for clock specified in "clock-names" property
|
||||
- clock-names : The name of clock used by the DFI, must be
|
||||
"pclk_ddr_mon";
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp.txt
|
||||
- operating-points-v2: Refer to Documentation/devicetree/bindings/opp/opp-v2.yaml
|
||||
for details.
|
||||
- center-supply: DMC supply node.
|
||||
- status: Marks the node enabled/disabled.
|
||||
|
@ -14,10 +14,10 @@ allOf:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- const: qcom,dsi-phy-7nm
|
||||
- const: qcom,dsi-phy-7nm-8150
|
||||
- const: qcom,sc7280-dsi-phy-7nm
|
||||
enum:
|
||||
- qcom,dsi-phy-7nm
|
||||
- qcom,dsi-phy-7nm-8150
|
||||
- qcom,sc7280-dsi-phy-7nm
|
||||
|
||||
reg:
|
||||
items:
|
||||
|
@ -24,13 +24,15 @@ properties:
|
||||
items:
|
||||
- description: Control and Status Register Slave Port
|
||||
- description: Descriptor Slave Port
|
||||
- description: Response Slave Port
|
||||
- description: Response Slave Port (Optional)
|
||||
minItems: 2
|
||||
|
||||
reg-names:
|
||||
items:
|
||||
- const: csr
|
||||
- const: desc
|
||||
- const: resp
|
||||
minItems: 2
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
130
Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
Normal file
130
Documentation/devicetree/bindings/dma/renesas,rz-dmac.yaml
Normal file
@ -0,0 +1,130 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/dma/renesas,rz-dmac.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas RZ/G2L DMA Controller
|
||||
|
||||
maintainers:
|
||||
- Biju Das <biju.das.jz@bp.renesas.com>
|
||||
|
||||
allOf:
|
||||
- $ref: "dma-controller.yaml#"
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- renesas,r9a07g044-dmac # RZ/G2{L,LC}
|
||||
- const: renesas,rz-dmac
|
||||
|
||||
reg:
|
||||
items:
|
||||
- description: Control and channel register block
|
||||
- description: DMA extended resource selector block
|
||||
|
||||
interrupts:
|
||||
maxItems: 17
|
||||
|
||||
interrupt-names:
|
||||
items:
|
||||
- const: error
|
||||
- const: ch0
|
||||
- const: ch1
|
||||
- const: ch2
|
||||
- const: ch3
|
||||
- const: ch4
|
||||
- const: ch5
|
||||
- const: ch6
|
||||
- const: ch7
|
||||
- const: ch8
|
||||
- const: ch9
|
||||
- const: ch10
|
||||
- const: ch11
|
||||
- const: ch12
|
||||
- const: ch13
|
||||
- const: ch14
|
||||
- const: ch15
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: DMA main clock
|
||||
- description: DMA register access clock
|
||||
|
||||
'#dma-cells':
|
||||
const: 1
|
||||
description:
|
||||
The cell specifies the encoded MID/RID values of the DMAC port
|
||||
connected to the DMA client and the slave channel configuration
|
||||
parameters.
|
||||
bits[0:9] - Specifies MID/RID value
|
||||
bit[10] - Specifies DMA request high enable (HIEN)
|
||||
bit[11] - Specifies DMA request detection type (LVL)
|
||||
bits[12:14] - Specifies DMAACK output mode (AM)
|
||||
bit[15] - Specifies Transfer Mode (TM)
|
||||
|
||||
dma-channels:
|
||||
const: 16
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
resets:
|
||||
items:
|
||||
- description: Reset for DMA ARESETN reset terminal
|
||||
- description: Reset for DMA RST_ASYNC reset terminal
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- interrupt-names
|
||||
- clocks
|
||||
- '#dma-cells'
|
||||
- dma-channels
|
||||
- power-domains
|
||||
- resets
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
#include <dt-bindings/clock/r9a07g044-cpg.h>
|
||||
|
||||
dmac: dma-controller@11820000 {
|
||||
compatible = "renesas,r9a07g044-dmac",
|
||||
"renesas,rz-dmac";
|
||||
reg = <0x11820000 0x10000>,
|
||||
<0x11830000 0x10000>;
|
||||
interrupts = <GIC_SPI 141 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 125 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 126 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 127 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 128 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 129 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 130 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 131 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 132 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 133 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 134 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 135 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 136 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 137 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 138 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 139 IRQ_TYPE_EDGE_RISING>,
|
||||
<GIC_SPI 140 IRQ_TYPE_EDGE_RISING>;
|
||||
interrupt-names = "error",
|
||||
"ch0", "ch1", "ch2", "ch3",
|
||||
"ch4", "ch5", "ch6", "ch7",
|
||||
"ch8", "ch9", "ch10", "ch11",
|
||||
"ch12", "ch13", "ch14", "ch15";
|
||||
clocks = <&cpg CPG_MOD R9A07G044_DMAC_ACLK>,
|
||||
<&cpg CPG_MOD R9A07G044_DMAC_PCLK>;
|
||||
power-domains = <&cpg>;
|
||||
resets = <&cpg R9A07G044_DMAC_ARESETN>,
|
||||
<&cpg R9A07G044_DMAC_RST_ASYNC>;
|
||||
#dma-cells = <1>;
|
||||
dma-channels = <16>;
|
||||
};
|
@ -40,6 +40,13 @@ description: |
|
||||
0x0: FIFO mode with threshold selectable with bit 0-1
|
||||
0x1: Direct mode: each DMA request immediately initiates a transfer
|
||||
from/to the memory, FIFO is bypassed.
|
||||
-bit 4: alternative DMA request/acknowledge protocol
|
||||
0x0: Use standard DMA ACK management, where ACK signal is maintained
|
||||
up to the removal of request and transfer completion
|
||||
0x1: Use alternative DMA ACK management, where ACK de-assertion does
|
||||
not wait for the de-assertion of the REQuest, ACK is only managed
|
||||
by transfer completion. This must only be used on channels
|
||||
managing transfers for STM32 USART/UART.
|
||||
|
||||
|
||||
maintainers:
|
||||
|
59
Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Normal file
59
Documentation/devicetree/bindings/gpio/gpio-virtio.yaml
Normal file
@ -0,0 +1,59 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/gpio/gpio-virtio.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtio GPIO controller
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/virtio/virtio-device.yaml#
|
||||
|
||||
description:
|
||||
Virtio GPIO controller, see /schemas/virtio/virtio-device.yaml for more
|
||||
details.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: gpio
|
||||
|
||||
compatible:
|
||||
const: virtio,device29
|
||||
|
||||
gpio-controller: true
|
||||
|
||||
"#gpio-cells":
|
||||
const: 2
|
||||
|
||||
interrupt-controller: true
|
||||
|
||||
"#interrupt-cells":
|
||||
const: 2
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- gpio-controller
|
||||
- "#gpio-cells"
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
virtio@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <41>;
|
||||
|
||||
gpio {
|
||||
compatible = "virtio,device29";
|
||||
gpio-controller;
|
||||
#gpio-cells = <2>;
|
||||
interrupt-controller;
|
||||
#interrupt-cells = <2>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
@ -137,7 +137,7 @@ examples:
|
||||
resets = <&reset 0>, <&reset 1>;
|
||||
};
|
||||
|
||||
gpu_opp_table: opp_table0 {
|
||||
gpu_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-533000000 {
|
||||
|
@ -160,7 +160,7 @@ examples:
|
||||
#cooling-cells = <2>;
|
||||
};
|
||||
|
||||
gpu_opp_table: opp_table0 {
|
||||
gpu_opp_table: opp-table {
|
||||
compatible = "operating-points-v2";
|
||||
|
||||
opp-533000000 {
|
||||
|
51
Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Normal file
51
Documentation/devicetree/bindings/i2c/i2c-virtio.yaml
Normal file
@ -0,0 +1,51 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/i2c-virtio.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Virtio I2C Adapter
|
||||
|
||||
maintainers:
|
||||
- Viresh Kumar <viresh.kumar@linaro.org>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
- $ref: /schemas/virtio/virtio-device.yaml#
|
||||
|
||||
description:
|
||||
Virtio I2C device, see /schemas/virtio/virtio-device.yaml for more details.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: i2c
|
||||
|
||||
compatible:
|
||||
const: virtio,device22
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
virtio@3000 {
|
||||
compatible = "virtio,mmio";
|
||||
reg = <0x3000 0x100>;
|
||||
interrupts = <41>;
|
||||
|
||||
i2c {
|
||||
compatible = "virtio,device22";
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
light-sensor@20 {
|
||||
compatible = "dynaimage,al3320a";
|
||||
reg = <0x20>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
...
|
@ -29,6 +29,8 @@ properties:
|
||||
description:
|
||||
Regulator for the LRADC reference voltage
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
patternProperties:
|
||||
"^button-[0-9]+$":
|
||||
type: object
|
||||
|
@ -1,55 +0,0 @@
|
||||
Qualcomm PM8941 PMIC Power Key
|
||||
|
||||
PROPERTIES
|
||||
|
||||
- compatible:
|
||||
Usage: required
|
||||
Value type: <string>
|
||||
Definition: must be one of:
|
||||
"qcom,pm8941-pwrkey"
|
||||
"qcom,pm8941-resin"
|
||||
"qcom,pmk8350-pwrkey"
|
||||
"qcom,pmk8350-resin"
|
||||
|
||||
- reg:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: base address of registers for block
|
||||
|
||||
- interrupts:
|
||||
Usage: required
|
||||
Value type: <prop-encoded-array>
|
||||
Definition: key change interrupt; The format of the specifier is
|
||||
defined by the binding document describing the node's
|
||||
interrupt parent.
|
||||
|
||||
- debounce:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: time in microseconds that key must be pressed or released
|
||||
for state change interrupt to trigger.
|
||||
|
||||
- bias-pull-up:
|
||||
Usage: optional
|
||||
Value type: <empty>
|
||||
Definition: presence of this property indicates that the KPDPWR_N pin
|
||||
should be configured for pull up.
|
||||
|
||||
- linux,code:
|
||||
Usage: optional
|
||||
Value type: <u32>
|
||||
Definition: The input key-code associated with the power key.
|
||||
Use the linux event codes defined in
|
||||
include/dt-bindings/input/linux-event-codes.h
|
||||
When property is omitted KEY_POWER is assumed.
|
||||
|
||||
EXAMPLE
|
||||
|
||||
pwrkey@800 {
|
||||
compatible = "qcom,pm8941-pwrkey";
|
||||
reg = <0x800>;
|
||||
interrupts = <0x0 0x8 0 IRQ_TYPE_EDGE_BOTH>;
|
||||
debounce = <15625>;
|
||||
bias-pull-up;
|
||||
linux,code = <KEY_POWER>;
|
||||
};
|
@ -0,0 +1,51 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/qcom,pm8941-pwrkey.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm PM8941 PMIC Power Key
|
||||
|
||||
maintainers:
|
||||
- Courtney Cavin <courtney.cavin@sonymobile.com>
|
||||
- Vinod Koul <vkoul@kernel.org>
|
||||
|
||||
allOf:
|
||||
- $ref: input.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,pm8941-pwrkey
|
||||
- qcom,pm8941-resin
|
||||
- qcom,pmk8350-pwrkey
|
||||
- qcom,pmk8350-resin
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
debounce:
|
||||
description: |
|
||||
Time in microseconds that key must be pressed or
|
||||
released for state change interrupt to trigger.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
bias-pull-up:
|
||||
description: |
|
||||
Presence of this property indicates that the KPDPWR_N
|
||||
pin should be configured for pull up.
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
||||
linux,code:
|
||||
description: |
|
||||
The input key-code associated with the power key.
|
||||
Use the linux event codes defined in
|
||||
include/dt-bindings/input/linux-event-codes.h
|
||||
When property is omitted KEY_POWER is assumed.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
|
||||
unevaluatedProperties: false
|
||||
...
|
@ -1,21 +0,0 @@
|
||||
* Regulator Haptic Device Tree Bindings
|
||||
|
||||
Required Properties:
|
||||
- compatible : Should be "regulator-haptic"
|
||||
- haptic-supply : Power supply to the haptic motor.
|
||||
[*] refer Documentation/devicetree/bindings/regulator/regulator.txt
|
||||
|
||||
- max-microvolt : The maximum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
- min-microvolt : The minimum voltage value supplied to the haptic motor.
|
||||
[The unit of the voltage is a micro]
|
||||
|
||||
Example:
|
||||
|
||||
haptics {
|
||||
compatible = "regulator-haptic";
|
||||
haptic-supply = <&motor_regulator>;
|
||||
max-microvolt = <2700000>;
|
||||
min-microvolt = <1100000>;
|
||||
};
|
@ -0,0 +1,43 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: "http://devicetree.org/schemas/input/regulator-haptic.yaml#"
|
||||
$schema: "http://devicetree.org/meta-schemas/core.yaml#"
|
||||
|
||||
title: Regulator Haptic Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Jaewon Kim <jaewon02.kim@samsung.com>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: regulator-haptic
|
||||
|
||||
haptic-supply:
|
||||
description: >
|
||||
Power supply to the haptic motor
|
||||
|
||||
max-microvolt:
|
||||
description: >
|
||||
The maximum voltage value supplied to the haptic motor
|
||||
|
||||
min-microvolt:
|
||||
description: >
|
||||
The minimum voltage value supplied to the haptic motor
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- haptic-supply
|
||||
- max-microvolt
|
||||
- min-microvolt
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
haptics {
|
||||
compatible = "regulator-haptic";
|
||||
haptic-supply = <&motor_regulator>;
|
||||
max-microvolt = <2700000>;
|
||||
min-microvolt = <1100000>;
|
||||
};
|
@ -0,0 +1,62 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/chipone,icn8318.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ChipOne ICN8318 Touchscreen Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: chipone,icn8318
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
wake-gpios:
|
||||
maxItems: 1
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- wake-gpios
|
||||
- touchscreen-size-x
|
||||
- touchscreen-size-y
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
touchscreen@40 {
|
||||
compatible = "chipone,icn8318";
|
||||
reg = <0x40>;
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ts_wake_pin_p66>;
|
||||
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <480>;
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-swapped-x-y;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
@ -1,44 +0,0 @@
|
||||
* ChipOne icn8318 I2C touchscreen controller
|
||||
|
||||
Required properties:
|
||||
- compatible : "chipone,icn8318"
|
||||
- reg : I2C slave address of the chip (0x40)
|
||||
- interrupts : interrupt specification for the icn8318 interrupt
|
||||
- wake-gpios : GPIO specification for the WAKE input
|
||||
- touchscreen-size-x : horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y : vertical resolution of touchscreen (in pixels)
|
||||
|
||||
Optional properties:
|
||||
- pinctrl-names : should be "default"
|
||||
- pinctrl-0: : a phandle pointing to the pin settings for the
|
||||
control gpios
|
||||
- touchscreen-fuzz-x : horizontal noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-fuzz-y : vertical noise value of the absolute input
|
||||
device (in pixels)
|
||||
- touchscreen-inverted-x : X axis is inverted (boolean)
|
||||
- touchscreen-inverted-y : Y axis is inverted (boolean)
|
||||
- touchscreen-swapped-x-y : X and Y axis are swapped (boolean)
|
||||
Swapping is done after inverting the axis
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
chipone_icn8318@40 {
|
||||
compatible = "chipone,icn8318";
|
||||
reg = <0x40>;
|
||||
interrupt-parent = <&pio>;
|
||||
interrupts = <9 IRQ_TYPE_EDGE_FALLING>; /* EINT9 (PG9) */
|
||||
pinctrl-names = "default";
|
||||
pinctrl-0 = <&ts_wake_pin_p66>;
|
||||
wake-gpios = <&pio 1 3 GPIO_ACTIVE_HIGH>; /* PB3 */
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <480>;
|
||||
touchscreen-inverted-x;
|
||||
touchscreen-swapped-x-y;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
@ -0,0 +1,68 @@
|
||||
# SPDX-License-Identifier: GPL-2.0
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/pixcir,pixcir_ts.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Pixcir Touchscreen Controller Device Tree Bindings
|
||||
|
||||
maintainers:
|
||||
- Dmitry Torokhov <dmitry.torokhov@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- pixcir,pixcir_ts
|
||||
- pixcir,pixcir_tangoc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
attb-gpio:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
maxItems: 1
|
||||
|
||||
wake-gpios:
|
||||
maxItems: 1
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- attb-gpio
|
||||
- touchscreen-size-x
|
||||
- touchscreen-size-y
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
touchscreen@5c {
|
||||
compatible = "pixcir,pixcir_ts";
|
||||
reg = <0x5c>;
|
||||
interrupts = <2 0>;
|
||||
attb-gpio = <&gpf 2 0 2>;
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <600>;
|
||||
};
|
||||
};
|
||||
|
||||
...
|
@ -1,31 +0,0 @@
|
||||
* Pixcir I2C touchscreen controllers
|
||||
|
||||
Required properties:
|
||||
- compatible: must be "pixcir,pixcir_ts" or "pixcir,pixcir_tangoc"
|
||||
- reg: I2C address of the chip
|
||||
- interrupts: interrupt to which the chip is connected
|
||||
- attb-gpio: GPIO connected to the ATTB line of the chip
|
||||
- touchscreen-size-x: horizontal resolution of touchscreen (in pixels)
|
||||
- touchscreen-size-y: vertical resolution of touchscreen (in pixels)
|
||||
|
||||
Optional properties:
|
||||
- reset-gpios: GPIO connected to the RESET line of the chip
|
||||
- enable-gpios: GPIO connected to the ENABLE line of the chip
|
||||
- wake-gpios: GPIO connected to the WAKE line of the chip
|
||||
|
||||
Example:
|
||||
|
||||
i2c@00000000 {
|
||||
/* ... */
|
||||
|
||||
pixcir_ts@5c {
|
||||
compatible = "pixcir,pixcir_ts";
|
||||
reg = <0x5c>;
|
||||
interrupts = <2 0>;
|
||||
attb-gpio = <&gpf 2 0 2>;
|
||||
touchscreen-size-x = <800>;
|
||||
touchscreen-size-y = <600>;
|
||||
};
|
||||
|
||||
/* ... */
|
||||
};
|
@ -0,0 +1,128 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/input/touchscreen/ti,tsc2005.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Texas Instruments TSC2004 and TSC2005 touchscreen controller bindings
|
||||
|
||||
maintainers:
|
||||
- Marek Vasut <marex@denx.de>
|
||||
- Michael Welling <mwelling@ieee.org>
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
pattern: "^touchscreen(@.*)?$"
|
||||
|
||||
compatible:
|
||||
enum:
|
||||
- ti,tsc2004
|
||||
- ti,tsc2005
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
description: |
|
||||
I2C address when used on the I2C bus, or the SPI chip select index
|
||||
when used on the SPI bus
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
description: GPIO specifier for the controller reset line
|
||||
|
||||
spi-max-frequency:
|
||||
description: TSC2005 SPI bus clock frequency.
|
||||
maximum: 25000000
|
||||
|
||||
ti,x-plate-ohms:
|
||||
description: resistance of the touchscreen's X plates in ohm (defaults to 280)
|
||||
|
||||
ti,esd-recovery-timeout-ms:
|
||||
description: |
|
||||
if the touchscreen does not respond after the configured time
|
||||
(in milli seconds), the driver will reset it. This is disabled
|
||||
by default.
|
||||
|
||||
vio-supply:
|
||||
description: Regulator specifier
|
||||
|
||||
touchscreen-fuzz-pressure: true
|
||||
touchscreen-fuzz-x: true
|
||||
touchscreen-fuzz-y: true
|
||||
touchscreen-max-pressure: true
|
||||
touchscreen-size-x: true
|
||||
touchscreen-size-y: true
|
||||
|
||||
allOf:
|
||||
- $ref: touchscreen.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: ti,tsc2004
|
||||
then:
|
||||
properties:
|
||||
spi-max-frequency: false
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
touchscreen@48 {
|
||||
compatible = "ti,tsc2004";
|
||||
reg = <0x48>;
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
|
||||
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
};
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
touchscreen@0 {
|
||||
compatible = "ti,tsc2005";
|
||||
spi-max-frequency = <6000000>;
|
||||
reg = <0>;
|
||||
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
|
||||
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
};
|
@ -1,64 +0,0 @@
|
||||
* Texas Instruments tsc2004 and tsc2005 touchscreen controllers
|
||||
|
||||
Required properties:
|
||||
- compatible : "ti,tsc2004" or "ti,tsc2005"
|
||||
- reg : Device address
|
||||
- interrupts : IRQ specifier
|
||||
- spi-max-frequency : Maximum SPI clocking speed of the device
|
||||
(for tsc2005)
|
||||
|
||||
Optional properties:
|
||||
- vio-supply : Regulator specifier
|
||||
- reset-gpios : GPIO specifier for the controller reset line
|
||||
- ti,x-plate-ohms : integer, resistance of the touchscreen's X plates
|
||||
in ohm (defaults to 280)
|
||||
- ti,esd-recovery-timeout-ms : integer, if the touchscreen does not respond after
|
||||
the configured time (in milli seconds), the driver
|
||||
will reset it. This is disabled by default.
|
||||
- properties defined in touchscreen.txt
|
||||
|
||||
Example:
|
||||
|
||||
&i2c3 {
|
||||
tsc2004@48 {
|
||||
compatible = "ti,tsc2004";
|
||||
reg = <0x48>;
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>;
|
||||
interrupts-extended = <&gpio1 27 IRQ_TYPE_EDGE_RISING>;
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
}
|
||||
|
||||
&mcspi1 {
|
||||
tsc2005@0 {
|
||||
compatible = "ti,tsc2005";
|
||||
spi-max-frequency = <6000000>;
|
||||
reg = <0>;
|
||||
|
||||
vio-supply = <&vio>;
|
||||
|
||||
reset-gpios = <&gpio4 8 GPIO_ACTIVE_HIGH>; /* 104 */
|
||||
interrupts-extended = <&gpio4 4 IRQ_TYPE_EDGE_RISING>; /* 100 */
|
||||
|
||||
touchscreen-fuzz-x = <4>;
|
||||
touchscreen-fuzz-y = <7>;
|
||||
touchscreen-fuzz-pressure = <2>;
|
||||
touchscreen-size-x = <4096>;
|
||||
touchscreen-size-y = <4096>;
|
||||
touchscreen-max-pressure = <2048>;
|
||||
|
||||
ti,x-plate-ohms = <280>;
|
||||
ti,esd-recovery-timeout-ms = <8000>;
|
||||
};
|
||||
}
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue
Block a user