Merge branch 'for-6.8/amd-sfh' into for-linus
- addition of new interfaces to export User presence information and Ambient light from amd-sfh to other drivers within the kernel (Basavaraj Natikar)
This commit is contained in:
commit
6b93f350e5
1
.gitignore
vendored
1
.gitignore
vendored
@ -74,7 +74,6 @@ modules.order
|
||||
#
|
||||
# RPM spec file (make rpm-pkg)
|
||||
#
|
||||
/kernel.spec
|
||||
/rpmbuild/
|
||||
|
||||
#
|
||||
|
4
.mailmap
4
.mailmap
@ -95,6 +95,7 @@ Ben M Cahill <ben.m.cahill@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben@bwidawsk.net>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <ben.widawsky@intel.com>
|
||||
Ben Widawsky <bwidawsk@kernel.org> <benjamin.widawsky@intel.com>
|
||||
Benjamin Poirier <benjamin.poirier@gmail.com> <bpoirier@suse.de>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn@kryo.se>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@linaro.org>
|
||||
Bjorn Andersson <andersson@kernel.org> <bjorn.andersson@sonymobile.com>
|
||||
@ -116,6 +117,7 @@ Changbin Du <changbin.du@intel.com> <changbin.du@gmail.com>
|
||||
Changbin Du <changbin.du@intel.com> <changbin.du@intel.com>
|
||||
Chao Yu <chao@kernel.org> <chao2.yu@samsung.com>
|
||||
Chao Yu <chao@kernel.org> <yuchao0@huawei.com>
|
||||
Chester Lin <chester62515@gmail.com> <clin@suse.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessm.com>
|
||||
Chris Chiu <chris.chiu@canonical.com> <chiu@endlessos.org>
|
||||
Chris Lew <quic_clew@quicinc.com> <clew@codeaurora.org>
|
||||
@ -128,6 +130,7 @@ Christian Brauner <brauner@kernel.org> <christian.brauner@ubuntu.com>
|
||||
Christian Marangi <ansuelsmth@gmail.com>
|
||||
Christophe Ricard <christophe.ricard@gmail.com>
|
||||
Christoph Hellwig <hch@lst.de>
|
||||
Claudiu Beznea <claudiu.beznea@tuxon.dev> <claudiu.beznea@microchip.com>
|
||||
Colin Ian King <colin.i.king@gmail.com> <colin.king@canonical.com>
|
||||
Corey Minyard <minyard@acm.org>
|
||||
Damian Hobson-Garcia <dhobsong@igel.co.jp>
|
||||
@ -571,6 +574,7 @@ Takashi YOSHII <takashi.yoshii.zj@renesas.com>
|
||||
Tamizh Chelvam Raja <quic_tamizhr@quicinc.com> <tamizhr@codeaurora.org>
|
||||
Taniya Das <quic_tdas@quicinc.com> <tdas@codeaurora.org>
|
||||
Tejun Heo <htejun@gmail.com>
|
||||
Tomeu Vizoso <tomeu@tomeuvizoso.net> <tomeu.vizoso@collabora.com>
|
||||
Thomas Graf <tgraf@suug.ch>
|
||||
Thomas Körper <socketcan@esd.eu> <thomas.koerper@esd.eu>
|
||||
Thomas Pedersen <twp@codeaurora.org>
|
||||
|
8
CREDITS
8
CREDITS
@ -2944,6 +2944,14 @@ D: IPX development and support
|
||||
N: Venkatesh Pallipadi (Venki)
|
||||
D: x86/HPET
|
||||
|
||||
N: Antti Palosaari
|
||||
E: crope@iki.fi
|
||||
D: Various DVB drivers
|
||||
W: https://palosaari.fi/linux/
|
||||
S: Yliopistokatu 1 D 513
|
||||
S: FI-90570 Oulu
|
||||
S: FINLAND
|
||||
|
||||
N: Kyungmin Park
|
||||
E: kyungmin.park@samsung.com
|
||||
D: Samsung S5Pv210 and Exynos4210 mobile platforms
|
||||
|
@ -270,6 +270,12 @@ Description: Shows the operation capability bits displayed in bitmap format
|
||||
correlates to the operations allowed. It's visible only
|
||||
on platforms that support the capability.
|
||||
|
||||
What: /sys/bus/dsa/devices/wq<m>.<n>/driver_name
|
||||
Date: Sept 8, 2023
|
||||
KernelVersion: 6.7.0
|
||||
Contact: dmaengine@vger.kernel.org
|
||||
Description: Name of driver to be bounded to the wq.
|
||||
|
||||
What: /sys/bus/dsa/devices/engine<m>.<n>/group_id
|
||||
Date: Oct 25, 2019
|
||||
KernelVersion: 5.6.0
|
||||
|
82
Documentation/ABI/testing/configfs-tsm
Normal file
82
Documentation/ABI/testing/configfs-tsm
Normal file
@ -0,0 +1,82 @@
|
||||
What: /sys/kernel/config/tsm/report/$name/inblob
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Up to 64 bytes of user specified binary data. For replay
|
||||
protection this should include a nonce, but the kernel does not
|
||||
place any restrictions on the content.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/outblob
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) Binary attestation report generated from @inblob and other
|
||||
options The format of the report is implementation specific
|
||||
where the implementation is conveyed via the @provider
|
||||
attribute.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/auxblob
|
||||
Date: October, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) Optional supplemental data that a TSM may emit, visibility
|
||||
of this attribute depends on TSM, and may be empty if no
|
||||
auxiliary data is available.
|
||||
|
||||
When @provider is "sev_guest" this file contains the
|
||||
"cert_table" from SEV-ES Guest-Hypervisor Communication Block
|
||||
Standardization v2.03 Section 4.1.8.1 MSG_REPORT_REQ.
|
||||
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56421.pdf
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/provider
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) A name for the format-specification of @outblob like
|
||||
"sev_guest" [1] or "tdx_guest" [2] in the near term, or a
|
||||
common standard format in the future.
|
||||
|
||||
[1]: SEV Secure Nested Paging Firmware ABI Specification
|
||||
Revision 1.55 Table 22
|
||||
https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/specifications/56860.pdf
|
||||
|
||||
[2]: Intel® Trust Domain Extensions Data Center Attestation
|
||||
Primitives : Quote Generation Library and Quote Verification
|
||||
Library Revision 0.8 Appendix 4,5
|
||||
https://download.01.org/intel-sgx/latest/dcap-latest/linux/docs/Intel_TDX_DCAP_Quoting_Library_API.pdf
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/generation
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) The value in this attribute increments each time @inblob or
|
||||
any option is written. Userspace can detect conflicts by
|
||||
checking generation before writing to any attribute and making
|
||||
sure the number of writes matches expectations after reading
|
||||
@outblob, or it can prevent conflicts by creating a report
|
||||
instance per requesting context.
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/privlevel
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(WO) Attribute is visible if a TSM implementation provider
|
||||
supports the concept of attestation reports for TVMs running at
|
||||
different privilege levels, like SEV-SNP "VMPL", specify the
|
||||
privilege level via this attribute. The minimum acceptable
|
||||
value is conveyed via @privlevel_floor and the maximum
|
||||
acceptable value is TSM_PRIVLEVEL_MAX (3).
|
||||
|
||||
What: /sys/kernel/config/tsm/report/$name/privlevel_floor
|
||||
Date: September, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-coco@lists.linux.dev
|
||||
Description:
|
||||
(RO) Indicates the minimum permissible value that can be written
|
||||
to @privlevel.
|
@ -35,4 +35,6 @@ Description:
|
||||
req_number the number of pre-allocated requests
|
||||
for both capture and playback
|
||||
function_name name of the interface
|
||||
c_terminal_type code of the capture terminal type
|
||||
p_terminal_type code of the playback terminal type
|
||||
===================== =======================================
|
||||
|
@ -1,4 +1,4 @@
|
||||
What: /sys/kernel/debug/qat_<device>_<BDF>/qat/fw_counters
|
||||
What: /sys/kernel/debug/qat_<device>_<BDF>/fw_counters
|
||||
Date: November 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: qat-linux@intel.com
|
||||
@ -59,3 +59,25 @@ Description: (RO) Read returns the device health status.
|
||||
|
||||
The driver does not monitor for Heartbeat. It is left for a user
|
||||
to poll the status periodically.
|
||||
|
||||
What: /sys/kernel/debug/qat_<device>_<BDF>/pm_status
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RO) Read returns power management information specific to the
|
||||
QAT device.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/kernel/debug/qat_<device>_<BDF>/cnv_errors
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RO) Read returns, for each Acceleration Engine (AE), the number
|
||||
of errors and the type of the last error detected by the device
|
||||
when performing verified compression.
|
||||
Reported counters::
|
||||
|
||||
<N>: Number of Compress and Verify (CnV) errors and type
|
||||
of the last CnV error detected by Acceleration
|
||||
Engine N.
|
||||
|
@ -28,14 +28,57 @@ Description:
|
||||
of a device manufacturer.
|
||||
Combination of Vendor ID and Device ID identifies a device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../subsystem_vendor
|
||||
Date: July 2023
|
||||
Contact: puneet.gupta@amd.com
|
||||
Description:
|
||||
Subsystem Vendor ID for this CDX device, in hexadecimal.
|
||||
Subsystem Vendor ID is 16 bit identifier specific to the
|
||||
card manufacturer.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../subsystem_device
|
||||
Date: July 2023
|
||||
Contact: puneet.gupta@amd.com
|
||||
Description:
|
||||
Subsystem Device ID for this CDX device, in hexadecimal
|
||||
Subsystem Device ID is 16 bit identifier specific to the
|
||||
card manufacturer.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../class
|
||||
Date: July 2023
|
||||
Contact: puneet.gupta@amd.com
|
||||
Description:
|
||||
This file contains the class of the CDX device, in hexadecimal.
|
||||
Class is 24 bit identifier specifies the functionality of the device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../revision
|
||||
Date: July 2023
|
||||
Contact: puneet.gupta@amd.com
|
||||
Description:
|
||||
This file contains the revision field of the CDX device, in hexadecimal.
|
||||
Revision is 8 bit revision identifier of the device.
|
||||
|
||||
What: /sys/bus/cdx/devices/.../enable
|
||||
Date: October 2023
|
||||
Contact: abhijit.gangurde@amd.com
|
||||
Description:
|
||||
CDX bus should be disabled before updating the devices in FPGA.
|
||||
Writing n/0/off will attempt to disable the CDX bus and.
|
||||
writing y/1/on will attempt to enable the CDX bus. Reading this file
|
||||
gives the current state of the bus, 1 for enabled and 0 for disabled.
|
||||
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/.../enable
|
||||
|
||||
What: /sys/bus/cdx/devices/.../reset
|
||||
Date: March 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
Writing y/1/on to this file resets the CDX device.
|
||||
On resetting the device, the corresponding driver is notified
|
||||
twice, once before the device is being reset, and again after
|
||||
the reset has been complete.
|
||||
Writing y/1/on to this file resets the CDX device or all devices
|
||||
on the bus. On resetting the device, the corresponding driver is
|
||||
notified twice, once before the device is being reset, and again
|
||||
after the reset has been complete.
|
||||
|
||||
For example::
|
||||
|
||||
@ -54,3 +97,18 @@ Description:
|
||||
For example::
|
||||
|
||||
# echo 1 > /sys/bus/cdx/devices/.../remove
|
||||
|
||||
What: /sys/bus/cdx/devices/.../modalias
|
||||
Date: July 2023
|
||||
Contact: nipun.gupta@amd.com
|
||||
Description:
|
||||
This attribute indicates the CDX ID of the device.
|
||||
That is in the format:
|
||||
cdx:vXXXXdXXXXsvXXXXsdXXXXcXXXXXX,
|
||||
where:
|
||||
|
||||
- vXXXX contains the vendor ID;
|
||||
- dXXXX contains the device ID;
|
||||
- svXXXX contains the subsystem vendor ID;
|
||||
- sdXXXX contains the subsystem device ID;
|
||||
- cXXXXXX contains the device class.
|
||||
|
@ -178,6 +178,21 @@ Description:
|
||||
hardware decoder target list.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/portX/decoders_committed
|
||||
Date: October, 2023
|
||||
KernelVersion: v6.7
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) A memory device is considered active when any of its
|
||||
decoders are in the "committed" state (See CXL 3.0 8.2.4.19.7
|
||||
CXL HDM Decoder n Control Register). Hotplug and destructive
|
||||
operations like "sanitize" are blocked while device is actively
|
||||
decoding a Host Physical Address range. Note that this number
|
||||
may be elevated without any regionX objects active or even
|
||||
enumerated, as this may be due to decoders established by
|
||||
platform firwmare or a previous kernel (kexec).
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y
|
||||
Date: June, 2021
|
||||
KernelVersion: v5.14
|
||||
@ -369,6 +384,21 @@ Description:
|
||||
provided it is currently idle / not bound to a driver.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/decoderX.Y/qos_class
|
||||
Date: May, 2023
|
||||
KernelVersion: v6.5
|
||||
Contact: linux-cxl@vger.kernel.org
|
||||
Description:
|
||||
(RO) For CXL host platforms that support "QoS Telemmetry" this
|
||||
root-decoder-only attribute conveys a platform specific cookie
|
||||
that identifies a QoS performance class for the CXL Window.
|
||||
This class-id can be compared against a similar "qos_class"
|
||||
published for each memory-type that an endpoint supports. While
|
||||
it is not required that endpoints map their local memory-class
|
||||
to a matching platform class, mismatches are not recommended and
|
||||
there are platform specific side-effects that may result.
|
||||
|
||||
|
||||
What: /sys/bus/cxl/devices/regionZ/uuid
|
||||
Date: May, 2022
|
||||
KernelVersion: v6.0
|
||||
|
@ -67,7 +67,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/pid
|
||||
KernelVersion: 5.0
|
||||
Contact: linux-i3c@vger.kernel.org
|
||||
Description:
|
||||
PID stands for Provisional ID and is used to uniquely identify
|
||||
PID stands for Provisioned ID and is used to uniquely identify
|
||||
a device on a bus. This PID contains information about the
|
||||
vendor, the part and an instance ID so that several devices of
|
||||
the same type can be connected on the same bus.
|
||||
@ -123,7 +123,7 @@ What: /sys/bus/i3c/devices/i3c-<bus-id>/<bus-id>-<device-pid>/pid
|
||||
KernelVersion: 5.0
|
||||
Contact: linux-i3c@vger.kernel.org
|
||||
Description:
|
||||
PID stands for Provisional ID and is used to uniquely identify
|
||||
PID stands for Provisioned ID and is used to uniquely identify
|
||||
a device on a bus. This PID contains information about the
|
||||
vendor, the part and an instance ID so that several devices of
|
||||
the same type can be connected on the same bus.
|
||||
|
@ -279,6 +279,35 @@ Description:
|
||||
but should match other such assignments on device).
|
||||
Units after application of scale and offset are m/s^2.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_y_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_z_raw
|
||||
KernelVersion: 6.5
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Angular displacement between two consecutive samples on x, y or
|
||||
z (may be arbitrarily assigned but should match other such
|
||||
assignments on device).
|
||||
In order to compute the total angular displacement during a
|
||||
desired period of time, the application should sum-up the delta
|
||||
angle samples acquired during that time.
|
||||
Units after application of scale and offset are radians.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_y_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_z_raw
|
||||
KernelVersion: 6.5
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The linear velocity change between two consecutive samples on x,
|
||||
y or z (may be arbitrarily assigned but should match other such
|
||||
assignments on device).
|
||||
In order to compute the total linear velocity change during a
|
||||
desired period of time, the application should sum-up the delta
|
||||
velocity samples acquired during that time.
|
||||
Units after application of scale and offset are meters per
|
||||
second.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_angl_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_anglY_raw
|
||||
KernelVersion: 4.17
|
||||
@ -461,6 +490,8 @@ What: /sys/bus/iio/devices/iio:deviceX/in_humidityrelative_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_velocity_sqrt(x^2+y^2+z^2)_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_illuminance_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_countY_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltaangl_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_deltavelocity_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_angl_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_x_scale
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_intensity_y_scale
|
||||
@ -1332,6 +1363,12 @@ Description:
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_x_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_y_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_z_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_en
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_en
|
||||
@ -1362,6 +1399,8 @@ Description:
|
||||
Scan element control for triggered data capture.
|
||||
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_type
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_type
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_type
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_type
|
||||
What: /sys/.../iio:deviceX/bufferY/in_magn_type
|
||||
What: /sys/.../iio:deviceX/bufferY/in_incli_type
|
||||
@ -1416,6 +1455,12 @@ What: /sys/.../iio:deviceX/bufferY/in_voltage_q_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_x_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_y_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_accel_z_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_x_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_y_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltaangl_z_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_x_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_y_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_deltavelocity_z_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_x_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_y_index
|
||||
What: /sys/.../iio:deviceX/bufferY/in_anglvel_z_index
|
||||
@ -2179,3 +2224,33 @@ Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Number of conditions that must occur, during a running
|
||||
period, before an event is generated.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_colortemp_raw
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Represents light color temperature, which measures light color
|
||||
temperature in Kelvin.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_x_raw
|
||||
What: /sys/bus/iio/devices/iio:deviceX/in_chromaticity_y_raw
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
The x and y light color coordinate on the CIE 1931 chromaticity
|
||||
diagram.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_either_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_mag_rising_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_falling_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltageY_thresh_rising_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglvelY_mag_rising_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_anglY_thresh_rising_label
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_phaseY_mag_rising_label
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Optional symbolic label to a device channel event.
|
||||
If a label is defined for this event add that to the event
|
||||
specific attributes. This is useful for userspace to be able to
|
||||
better identify an individual event.
|
||||
|
53
Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564
Normal file
53
Documentation/ABI/testing/sysfs-bus-iio-adc-mcp3564
Normal file
@ -0,0 +1,53 @@
|
||||
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to set the gain of the biasing current
|
||||
circuit of the Delta-Sigma modulator. The different BOOST
|
||||
settings are applied to the entire modulator circuit, including
|
||||
the voltage reference buffers.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/boost_current_gain_available
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading returns a list with the possible gain values for
|
||||
the current biasing circuit of the Delta-Sigma modulator.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_mux_enable
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to enable the analog input multiplexer
|
||||
auto-zeroing algorithm (the input multiplexer and the ADC
|
||||
include an offset cancellation algorithm that cancels the offset
|
||||
contribution of the ADC). When the offset cancellation algorithm
|
||||
is enabled, ADC takes two conversions, one with the differential
|
||||
input as VIN+/VIN-, one with VIN+/VIN- inverted. In this case the
|
||||
conversion time is multiplied by two compared to the default
|
||||
case where the algorithm is disabled. This technique allows the
|
||||
cancellation of the ADC offset error and the achievement of
|
||||
ultra-low offset without any digital calibration. The resulting
|
||||
offset is the residue of the difference between the two
|
||||
conversions, which is on the order of magnitude of the noise
|
||||
floor. This offset is effectively canceled at every conversion,
|
||||
so the residual offset error temperature drift is extremely low.
|
||||
Write '1' to enable it, write '0' to disable it.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/auto_zeroing_ref_enable
|
||||
KernelVersion: 6.4
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
This attribute is used to enable the chopping algorithm for the
|
||||
internal voltage reference buffer. This setting has no effect
|
||||
when external voltage reference is selected.
|
||||
Internal voltage reference buffer injects a certain quantity of
|
||||
1/f noise into the system that can be modulated with the
|
||||
incoming input signals and can limit the SNR performance at
|
||||
higher Oversampling Ratio values (over 256). To overcome this
|
||||
limitation, the buffer includes an auto-zeroing algorithm that
|
||||
greatly reduces (cancels out) the 1/f noise and cancels the
|
||||
offset value of the reference buffer. As a result, the SNR of
|
||||
the system is not affected by this 1/f noise component of the
|
||||
reference buffer, even at maximum oversampling ratio values.
|
||||
Write '1' to enable it, write '0' to disable it.
|
27
Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210
Normal file
27
Documentation/ABI/testing/sysfs-bus-iio-resolver-ad2s1210
Normal file
@ -0,0 +1,27 @@
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading returns the current Degradation of Signal Reset Maximum
|
||||
Threshold value in millivolts. Writing sets the value.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_max_available
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading returns the allowable voltage range for
|
||||
in_altvoltage0_mag_rising_reset_max.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading returns the current Degradation of Signal Reset Minimum
|
||||
Threshold value in millivolts. Writing sets the value.
|
||||
|
||||
What: /sys/bus/iio/devices/iio:deviceX/events/in_altvoltage0_mag_rising_reset_min_available
|
||||
KernelVersion: 6.7
|
||||
Contact: linux-iio@vger.kernel.org
|
||||
Description:
|
||||
Reading returns the allowable voltage range for
|
||||
in_altvoltage0_mag_rising_reset_min.
|
@ -6,3 +6,12 @@ Description:
|
||||
OP-TEE bus provides reference to registered drivers under this directory. The <uuid>
|
||||
matches Trusted Application (TA) driver and corresponding TA in secure OS. Drivers
|
||||
are free to create needed API under optee-ta-<uuid> directory.
|
||||
|
||||
What: /sys/bus/tee/devices/optee-ta-<uuid>/need_supplicant
|
||||
Date: November 2023
|
||||
KernelVersion: 6.7
|
||||
Contact: op-tee@lists.trustedfirmware.org
|
||||
Description:
|
||||
Allows to distinguish whether an OP-TEE based TA/device requires user-space
|
||||
tee-supplicant to function properly or not. This attribute will be present for
|
||||
devices which depend on tee-supplicant to be running.
|
||||
|
@ -313,6 +313,15 @@ Description:
|
||||
Inter-Chip SSIC devices support asymmetric lanes up to 4 lanes per
|
||||
direction. Devices before USB 3.2 are single lane (tx_lanes = 1)
|
||||
|
||||
What: /sys/bus/usb/devices/.../typec
|
||||
Date: November 2023
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
Symlink to the USB Type-C partner device. USB Type-C partner
|
||||
represents the component that communicates over the
|
||||
Configuration Channel (CC signal on USB Type-C connectors and
|
||||
cables) with the local port.
|
||||
|
||||
What: /sys/bus/usb/devices/usbX/bAlternateSetting
|
||||
Description:
|
||||
The current interface alternate setting number, in decimal.
|
||||
|
@ -1,4 +1,4 @@
|
||||
What: /sys/bus/vdpa/driver_autoprobe
|
||||
What: /sys/bus/vdpa/drivers_autoprobe
|
||||
Date: March 2020
|
||||
Contact: virtualization@lists.linux-foundation.org
|
||||
Description:
|
||||
@ -17,7 +17,7 @@ Description:
|
||||
Writing a device name to this file will cause the kernel binds
|
||||
devices to a compatible driver.
|
||||
|
||||
This can be useful when /sys/bus/vdpa/driver_autoprobe is
|
||||
This can be useful when /sys/bus/vdpa/drivers_autoprobe is
|
||||
disabled.
|
||||
|
||||
What: /sys/bus/vdpa/drivers/.../bind
|
||||
|
@ -59,15 +59,6 @@ Description:
|
||||
brightness. Reading this file when no hw brightness change
|
||||
event has happened will return an ENODATA error.
|
||||
|
||||
What: /sys/class/leds/<led>/color
|
||||
Date: June 2023
|
||||
KernelVersion: 6.5
|
||||
Description:
|
||||
Color of the LED.
|
||||
|
||||
This is a read-only file. Reading this file returns the color
|
||||
of the LED as a string (e.g: "red", "green", "multicolor").
|
||||
|
||||
What: /sys/class/leds/<led>/trigger
|
||||
Date: March 2006
|
||||
KernelVersion: 2.6.17
|
||||
|
@ -12,3 +12,17 @@ Description: (RW) On the front panel of the Turris Omnia router there is also
|
||||
able to change this setting from software.
|
||||
|
||||
Format: %i
|
||||
|
||||
What: /sys/class/leds/<led>/device/gamma_correction
|
||||
Date: August 2023
|
||||
KernelVersion: 6.6
|
||||
Contact: Marek Behún <kabel@kernel.org>
|
||||
Description: (RW) Newer versions of the microcontroller firmware of the
|
||||
Turris Omnia router support gamma correction for the RGB LEDs.
|
||||
This feature can be enabled/disabled by writing to this file.
|
||||
|
||||
If the feature is not supported because the MCU firmware is too
|
||||
old, the file always reads as 0, and writing to the file results
|
||||
in the EOPNOTSUPP error.
|
||||
|
||||
Format: %i
|
||||
|
@ -124,6 +124,13 @@ Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
The voltage the supply supports in millivolts.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/peak_current
|
||||
Date: October 2023
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
Description:
|
||||
This file shows the value of the Fixed Power Source Peak Current
|
||||
Capability field.
|
||||
|
||||
What: /sys/class/usb_power_delivery/.../source-capabilities/<position>:fixed_supply/maximum_current
|
||||
Date: May 2022
|
||||
Contact: Heikki Krogerus <heikki.krogerus@linux.intel.com>
|
||||
|
@ -17,7 +17,7 @@ Description: Read only. Returns the firmware version of Intel MAX10
|
||||
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_address
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Contact: Peter Colberg <peter.colberg@intel.com>
|
||||
Description: Read only. Returns the first MAC address in a block
|
||||
of sequential MAC addresses assigned to the board
|
||||
that is managed by the Intel MAX10 BMC. It is stored in
|
||||
@ -28,7 +28,7 @@ Description: Read only. Returns the first MAC address in a block
|
||||
What: /sys/bus/.../drivers/intel-m10-bmc/.../mac_count
|
||||
Date: January 2021
|
||||
KernelVersion: 5.12
|
||||
Contact: Russ Weight <russell.h.weight@intel.com>
|
||||
Contact: Peter Colberg <peter.colberg@intel.com>
|
||||
Description: Read only. Returns the number of sequential MAC
|
||||
addresses assigned to the board managed by the Intel
|
||||
MAX10 BMC. This value is stored in FLASH and is mirrored
|
||||
|
@ -29,6 +29,8 @@ Description: (RW) Reports the current configuration of the QAT device.
|
||||
services
|
||||
* asym;sym: identical to sym;asym
|
||||
* dc: the device is configured for running compression services
|
||||
* dcc: identical to dc but enables the dc chaining feature,
|
||||
hash then compression. If this is not required chose dc
|
||||
* sym: the device is configured for running symmetric crypto
|
||||
services
|
||||
* asym: the device is configured for running asymmetric crypto
|
||||
@ -93,3 +95,49 @@ Description: (RW) This configuration option provides a way to force the device i
|
||||
0
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/rp2srv
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) This attribute provides a way for a user to query a
|
||||
specific ring pair for the type of service that it is currently
|
||||
configured for.
|
||||
|
||||
When written to, the value is cached and used to perform the
|
||||
read operation. Allowed values are in the range 0 to N-1, where
|
||||
N is the max number of ring pairs supported by a device. This
|
||||
can be queried using the attribute qat/num_rps.
|
||||
|
||||
A read returns the service associated to the ring pair queried.
|
||||
|
||||
The values are:
|
||||
|
||||
* dc: the ring pair is configured for running compression services
|
||||
* sym: the ring pair is configured for running symmetric crypto
|
||||
services
|
||||
* asym: the ring pair is configured for running asymmetric crypto
|
||||
services
|
||||
|
||||
Example usage::
|
||||
|
||||
# echo 1 > /sys/bus/pci/devices/<BDF>/qat/rp2srv
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/rp2srv
|
||||
sym
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat/num_rps
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RO) Returns the number of ring pairs that a single device has.
|
||||
|
||||
Example usage::
|
||||
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat/num_rps
|
||||
64
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
41
Documentation/ABI/testing/sysfs-driver-qat_ras
Normal file
41
Documentation/ABI/testing/sysfs-driver-qat_ras
Normal file
@ -0,0 +1,41 @@
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RO) Reports the number of correctable errors detected by the device.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RO) Reports the number of non fatal errors detected by the device.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (RO) Reports the number of fatal errors detected by the device.
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description: (WO) Write to resets all error counters of a device.
|
||||
|
||||
The following example reports how to reset the counters::
|
||||
|
||||
# echo 1 > /sys/bus/pci/devices/<BDF>/qat_ras/reset_error_counters
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_correctable
|
||||
0
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_nonfatal
|
||||
0
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_ras/errors_fatal
|
||||
0
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
226
Documentation/ABI/testing/sysfs-driver-qat_rl
Normal file
226
Documentation/ABI/testing/sysfs-driver-qat_rl
Normal file
@ -0,0 +1,226 @@
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(WO) This attribute is used to perform an operation on an SLA.
|
||||
The supported operations are: add, update, rm, rm_all, and get.
|
||||
|
||||
Input values must be filled through the associated attribute in
|
||||
this group before a write to this file.
|
||||
If the operation completes successfully, the associated
|
||||
attributes will be updated.
|
||||
The associated attributes are: cir, pir, srv, rp, and id.
|
||||
|
||||
Supported operations:
|
||||
|
||||
* add: Creates a new SLA with the provided inputs from user.
|
||||
* Inputs: cir, pir, srv, and rp
|
||||
* Output: id
|
||||
|
||||
* get: Returns the configuration of the specified SLA in id attribute
|
||||
* Inputs: id
|
||||
* Outputs: cir, pir, srv, and rp
|
||||
|
||||
* update: Updates the SLA with new values set in the following attributes
|
||||
* Inputs: id, cir, and pir
|
||||
|
||||
* rm: Removes the specified SLA in the id attribute.
|
||||
* Inputs: id
|
||||
|
||||
* rm_all: Removes all the configured SLAs.
|
||||
* Inputs: None
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/rp
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) When read, reports the current assigned ring pairs for the
|
||||
queried SLA.
|
||||
When wrote to, configures the ring pairs associated to a new SLA.
|
||||
|
||||
The value is a 64-bit bit mask and is written/displayed in hex.
|
||||
Each bit of this mask represents a single ring pair i.e.,
|
||||
bit 1 == ring pair id 0; bit 3 == ring pair id 2.
|
||||
|
||||
Selected ring pairs must to be assigned to a single service,
|
||||
i.e. the one provided with the srv attribute. The service
|
||||
assigned to a certain ring pair can be checked by querying
|
||||
the attribute qat/rp2srv.
|
||||
|
||||
The maximum number of ring pairs is 4 per SLA.
|
||||
|
||||
Applicability in sla_op:
|
||||
|
||||
* WRITE: add operation
|
||||
* READ: get operation
|
||||
|
||||
Example usage::
|
||||
|
||||
## Read
|
||||
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
|
||||
0x5
|
||||
|
||||
## Write
|
||||
# echo 0x5 > /sys/bus/pci/devices/<BDF>/qat_rl/rp
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) If written to, the value is used to retrieve a particular
|
||||
SLA and operate on it.
|
||||
This is valid only for the following operations: update, rm,
|
||||
and get.
|
||||
A read of this attribute is only guaranteed to have correct data
|
||||
after creation of an SLA.
|
||||
|
||||
Applicability in sla_op:
|
||||
|
||||
* WRITE: rm and update operations
|
||||
* READ: add and get operations
|
||||
|
||||
Example usage::
|
||||
|
||||
## Read
|
||||
## Set attributes e.g. cir, pir, srv, etc
|
||||
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
4
|
||||
|
||||
## Write
|
||||
# echo 7 > /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/rp
|
||||
0x5 ## ring pair ID 0 and ring pair ID 2
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/cir
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) Committed information rate (CIR). Rate guaranteed to be
|
||||
achieved by a particular SLA. The value is expressed in
|
||||
permille scale, i.e. 1000 refers to the maximum device
|
||||
throughput for a selected service.
|
||||
|
||||
After sending a "get" to sla_op, this will be populated with the
|
||||
CIR for that queried SLA.
|
||||
Write to this file before sending an "add/update" sla_op, to set
|
||||
the SLA to the specified value.
|
||||
|
||||
Applicability in sla_op:
|
||||
|
||||
* WRITE: add and update operations
|
||||
* READ: get operation
|
||||
|
||||
Example usage::
|
||||
|
||||
## Write
|
||||
# echo 500 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
|
||||
# echo "add" /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
|
||||
## Read
|
||||
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cir
|
||||
500
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/pir
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) Peak information rate (PIR). The maximum rate that can be
|
||||
achieved by that particular SLA. An SLA can reach a value
|
||||
between CIR and PIR when the device is not fully utilized by
|
||||
requests from other users (assigned to different SLAs).
|
||||
|
||||
After sending a "get" to sla_op, this will be populated with the
|
||||
PIR for that queried SLA.
|
||||
Write to this file before sending an "add/update" sla_op, to set
|
||||
the SLA to the specified value.
|
||||
|
||||
Applicability in sla_op:
|
||||
|
||||
* WRITE: add and update operations
|
||||
* READ: get operation
|
||||
|
||||
Example usage::
|
||||
|
||||
## Write
|
||||
# echo 750 > /sys/bus/pci/devices/<BDF>/qat_rl/pir
|
||||
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
|
||||
## Read
|
||||
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/pir
|
||||
750
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/srv
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) Service (SRV). Represents the service (sym, asym, dc)
|
||||
associated to an SLA.
|
||||
Can be written to or queried to set/show the SRV type for an SLA.
|
||||
The SRV attribute is used to specify the SRV type before adding
|
||||
an SLA. After an SLA is configured, reports the service
|
||||
associated to that SLA.
|
||||
|
||||
Applicability in sla_op:
|
||||
|
||||
* WRITE: add and update operations
|
||||
* READ: get operation
|
||||
|
||||
Example usage::
|
||||
|
||||
## Write
|
||||
# echo "dc" > /sys/bus/pci/devices/<BDF>/qat_rl/srv
|
||||
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
4
|
||||
|
||||
## Read
|
||||
# echo 4 > /sys/bus/pci/devices/<BDF>/qat_rl/id
|
||||
# echo "get" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/srv
|
||||
dc
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
||||
|
||||
What: /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
|
||||
Date: January 2024
|
||||
KernelVersion: 6.7
|
||||
Contact: qat-linux@intel.com
|
||||
Description:
|
||||
(RW) This file will return the remaining capability for a
|
||||
particular service/sla. This is the remaining value that a new
|
||||
SLA can be set to or a current SLA can be increased with.
|
||||
|
||||
Example usage::
|
||||
|
||||
# echo "asym" > /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
|
||||
250
|
||||
# echo 250 > /sys/bus/pci/devices/<BDF>/qat_rl/cir
|
||||
# echo "add" > /sys/bus/pci/devices/<BDF>/qat_rl/sla_op
|
||||
# cat /sys/bus/pci/devices/<BDF>/qat_rl/cap_rem
|
||||
0
|
||||
|
||||
This attribute is only available for qat_4xxx devices.
|
@ -151,6 +151,13 @@ Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Writing to and reading from this file sets and gets the action
|
||||
of the scheme.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/apply_interval_us
|
||||
Date: Sep 2023
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
Description: Writing a value to this file sets the action apply interval of
|
||||
the scheme in microseconds. Reading this file returns the
|
||||
value.
|
||||
|
||||
What: /sys/kernel/mm/damon/admin/kdamonds/<K>/contexts/<C>/schemes/<S>/access_pattern/sz/min
|
||||
Date: Mar 2022
|
||||
Contact: SeongJae Park <sj@kernel.org>
|
||||
|
@ -87,19 +87,22 @@ What: /sys/class/tty/ttyS<x>/close_delay
|
||||
Date: October 2012
|
||||
Contact: Alan Cox <alan@linux.intel.com>
|
||||
Description:
|
||||
Show the closing delay time for this port in ms.
|
||||
Show the closing delay time for this port in centiseconds.
|
||||
|
||||
These sysfs values expose the TIOCGSERIAL interface via
|
||||
sysfs rather than via ioctls.
|
||||
These sysfs values expose the TIOCGSERIAL interface via
|
||||
sysfs rather than via ioctls.
|
||||
|
||||
What: /sys/class/tty/ttyS<x>/closing_wait
|
||||
Date: October 2012
|
||||
Contact: Alan Cox <alan@linux.intel.com>
|
||||
Description:
|
||||
Show the close wait time for this port in ms.
|
||||
Show the close wait time for this port in centiseconds.
|
||||
|
||||
These sysfs values expose the TIOCGSERIAL interface via
|
||||
sysfs rather than via ioctls.
|
||||
Waiting forever is represented as 0. If waiting on close is
|
||||
disabled then the value is 65535.
|
||||
|
||||
These sysfs values expose the TIOCGSERIAL interface via
|
||||
sysfs rather than via ioctls.
|
||||
|
||||
What: /sys/class/tty/ttyS<x>/custom_divisor
|
||||
Date: October 2012
|
||||
|
@ -551,6 +551,7 @@ memory.stat file includes following statistics:
|
||||
event happens each time a page is unaccounted from the
|
||||
cgroup.
|
||||
swap # of bytes of swap usage
|
||||
swapcached # of bytes of swap cached in memory
|
||||
dirty # of bytes that are waiting to get written back to the disk.
|
||||
writeback # of bytes of file/anon cache that are queued for syncing to
|
||||
disk.
|
||||
|
@ -210,6 +210,35 @@ cgroup v2 currently supports the following mount options.
|
||||
relying on the original semantics (e.g. specifying bogusly
|
||||
high 'bypass' protection values at higher tree levels).
|
||||
|
||||
memory_hugetlb_accounting
|
||||
Count HugeTLB memory usage towards the cgroup's overall
|
||||
memory usage for the memory controller (for the purpose of
|
||||
statistics reporting and memory protetion). This is a new
|
||||
behavior that could regress existing setups, so it must be
|
||||
explicitly opted in with this mount option.
|
||||
|
||||
A few caveats to keep in mind:
|
||||
|
||||
* There is no HugeTLB pool management involved in the memory
|
||||
controller. The pre-allocated pool does not belong to anyone.
|
||||
Specifically, when a new HugeTLB folio is allocated to
|
||||
the pool, it is not accounted for from the perspective of the
|
||||
memory controller. It is only charged to a cgroup when it is
|
||||
actually used (for e.g at page fault time). Host memory
|
||||
overcommit management has to consider this when configuring
|
||||
hard limits. In general, HugeTLB pool management should be
|
||||
done via other mechanisms (such as the HugeTLB controller).
|
||||
* Failure to charge a HugeTLB folio to the memory controller
|
||||
results in SIGBUS. This could happen even if the HugeTLB pool
|
||||
still has pages available (but the cgroup limit is hit and
|
||||
reclaim attempt fails).
|
||||
* Charging HugeTLB memory towards the memory controller affects
|
||||
memory protection and reclaim dynamics. Any userspace tuning
|
||||
(of low, min limits for e.g) needs to take this into account.
|
||||
* HugeTLB pages utilized while this option is not selected
|
||||
will not be tracked by the memory controller (even if cgroup
|
||||
v2 is remounted later on).
|
||||
|
||||
|
||||
Organizing Processes and Threads
|
||||
--------------------------------
|
||||
@ -1539,6 +1568,15 @@ PAGE_SIZE multiple when read back.
|
||||
collapsing an existing range of pages. This counter is not
|
||||
present when CONFIG_TRANSPARENT_HUGEPAGE is not set.
|
||||
|
||||
thp_swpout (npn)
|
||||
Number of transparent hugepages which are swapout in one piece
|
||||
without splitting.
|
||||
|
||||
thp_swpout_fallback (npn)
|
||||
Number of transparent hugepages which were split before swapout.
|
||||
Usually because failed to allocate some continuous swap space
|
||||
for the huge page.
|
||||
|
||||
memory.numa_stat
|
||||
A read-only nested-keyed file which exists on non-root cgroups.
|
||||
|
||||
|
@ -1335,6 +1335,7 @@
|
||||
earlyprintk=dbgp[debugController#]
|
||||
earlyprintk=pciserial[,force],bus:device.function[,baudrate]
|
||||
earlyprintk=xdbc[xhciController#]
|
||||
earlyprintk=bios
|
||||
|
||||
earlyprintk is useful when the kernel crashes before
|
||||
the normal console is initialized. It is not enabled by
|
||||
@ -1365,6 +1366,8 @@
|
||||
|
||||
The sclp output can only be used on s390.
|
||||
|
||||
The bios output can only be used on SuperH.
|
||||
|
||||
The optional "force" to "pciserial" enables use of a
|
||||
PCI device even when its classcode is not of the
|
||||
UART class.
|
||||
@ -2224,7 +2227,7 @@
|
||||
forcing Dual Address Cycle for PCI cards supporting
|
||||
greater than 32-bit addressing.
|
||||
|
||||
iommu.strict= [ARM64, X86] Configure TLB invalidation behaviour
|
||||
iommu.strict= [ARM64, X86, S390] Configure TLB invalidation behaviour
|
||||
Format: { "0" | "1" }
|
||||
0 - Lazy mode.
|
||||
Request that DMA unmap operations use deferred
|
||||
@ -3330,6 +3333,11 @@
|
||||
|
||||
mga= [HW,DRM]
|
||||
|
||||
microcode.force_minrev= [X86]
|
||||
Format: <bool>
|
||||
Enable or disable the microcode minimal revision
|
||||
enforcement for the runtime microcode loader.
|
||||
|
||||
min_addr=nn[KMG] [KNL,BOOT,IA-64] All physical memory below this
|
||||
physical address is ignored.
|
||||
|
||||
@ -3588,6 +3596,13 @@
|
||||
[NFS] set the TCP port on which the NFSv4 callback
|
||||
channel should listen.
|
||||
|
||||
nfs.delay_retrans=
|
||||
[NFS] specifies the number of times the NFSv4 client
|
||||
retries the request before returning an EAGAIN error,
|
||||
after a reply of NFS4ERR_DELAY from the server.
|
||||
Only applies if the softerr mount option is enabled,
|
||||
and the specified value is >= 0.
|
||||
|
||||
nfs.enable_ino64=
|
||||
[NFS] enable 64-bit inode numbers.
|
||||
If zero, the NFS client will fake up a 32-bit inode
|
||||
@ -5679,9 +5694,10 @@
|
||||
s390_iommu= [HW,S390]
|
||||
Set s390 IOTLB flushing mode
|
||||
strict
|
||||
With strict flushing every unmap operation will result in
|
||||
an IOTLB flush. Default is lazy flushing before reuse,
|
||||
which is faster.
|
||||
With strict flushing every unmap operation will result
|
||||
in an IOTLB flush. Default is lazy flushing before
|
||||
reuse, which is faster. Deprecated, equivalent to
|
||||
iommu.strict=1.
|
||||
|
||||
s390_iommu_aperture= [KNL,S390]
|
||||
Specifies the size of the per device DMA address space
|
||||
|
374
Documentation/admin-guide/media/mgb4.rst
Normal file
374
Documentation/admin-guide/media/mgb4.rst
Normal file
@ -0,0 +1,374 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====================
|
||||
mgb4 sysfs interface
|
||||
====================
|
||||
|
||||
The mgb4 driver provides a sysfs interface, that is used to configure video
|
||||
stream related parameters (some of them must be set properly before the v4l2
|
||||
device can be opened) and obtain the video device/stream status.
|
||||
|
||||
There are two types of parameters - global / PCI card related, found under
|
||||
``/sys/class/video4linux/videoX/device`` and module specific found under
|
||||
``/sys/class/video4linux/videoX``.
|
||||
|
||||
|
||||
Global (PCI card) parameters
|
||||
============================
|
||||
|
||||
**module_type** (R):
|
||||
Module type.
|
||||
|
||||
| 0 - No module present
|
||||
| 1 - FPDL3
|
||||
| 2 - GMSL
|
||||
|
||||
**module_version** (R):
|
||||
Module version number. Zero in case of a missing module.
|
||||
|
||||
**fw_type** (R):
|
||||
Firmware type.
|
||||
|
||||
| 1 - FPDL3
|
||||
| 2 - GMSL
|
||||
|
||||
**fw_version** (R):
|
||||
Firmware version number.
|
||||
|
||||
**serial_number** (R):
|
||||
Card serial number. The format is::
|
||||
|
||||
PRODUCT-REVISION-SERIES-SERIAL
|
||||
|
||||
where each component is a 8b number.
|
||||
|
||||
|
||||
Common FPDL3/GMSL input parameters
|
||||
==================================
|
||||
|
||||
**input_id** (R):
|
||||
Input number ID, zero based.
|
||||
|
||||
**oldi_lane_width** (RW):
|
||||
Number of deserializer output lanes.
|
||||
|
||||
| 0 - single
|
||||
| 1 - dual (default)
|
||||
|
||||
**color_mapping** (RW):
|
||||
Mapping of the incoming bits in the signal to the colour bits of the pixels.
|
||||
|
||||
| 0 - OLDI/JEIDA
|
||||
| 1 - SPWG/VESA (default)
|
||||
|
||||
**link_status** (R):
|
||||
Video link status. If the link is locked, chips are properly connected and
|
||||
communicating at the same speed and protocol. The link can be locked without
|
||||
an active video stream.
|
||||
|
||||
A value of 0 is equivalent to the V4L2_IN_ST_NO_SYNC flag of the V4L2
|
||||
VIDIOC_ENUMINPUT status bits.
|
||||
|
||||
| 0 - unlocked
|
||||
| 1 - locked
|
||||
|
||||
**stream_status** (R):
|
||||
Video stream status. A stream is detected if the link is locked, the input
|
||||
pixel clock is running and the DE signal is moving.
|
||||
|
||||
A value of 0 is equivalent to the V4L2_IN_ST_NO_SIGNAL flag of the V4L2
|
||||
VIDIOC_ENUMINPUT status bits.
|
||||
|
||||
| 0 - not detected
|
||||
| 1 - detected
|
||||
|
||||
**video_width** (R):
|
||||
Video stream width. This is the actual width as detected by the HW.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the width
|
||||
field of the v4l2_bt_timings struct.
|
||||
|
||||
**video_height** (R):
|
||||
Video stream height. This is the actual height as detected by the HW.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in the height
|
||||
field of the v4l2_bt_timings struct.
|
||||
|
||||
**vsync_status** (R):
|
||||
The type of VSYNC pulses as detected by the video format detector.
|
||||
|
||||
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
|
||||
the polarities field of the v4l2_bt_timings struct.
|
||||
|
||||
| 0 - active low
|
||||
| 1 - active high
|
||||
| 2 - not available
|
||||
|
||||
**hsync_status** (R):
|
||||
The type of HSYNC pulses as detected by the video format detector.
|
||||
|
||||
The value is equivalent to the flags returned by VIDIOC_QUERY_DV_TIMINGS in
|
||||
the polarities field of the v4l2_bt_timings struct.
|
||||
|
||||
| 0 - active low
|
||||
| 1 - active high
|
||||
| 2 - not available
|
||||
|
||||
**vsync_gap_length** (RW):
|
||||
If the incoming video signal does not contain synchronization VSYNC and
|
||||
HSYNC pulses, these must be generated internally in the FPGA to achieve
|
||||
the correct frame ordering. This value indicates, how many "empty" pixels
|
||||
(pixels with deasserted Data Enable signal) are necessary to generate the
|
||||
internal VSYNC pulse.
|
||||
|
||||
**hsync_gap_length** (RW):
|
||||
If the incoming video signal does not contain synchronization VSYNC and
|
||||
HSYNC pulses, these must be generated internally in the FPGA to achieve
|
||||
the correct frame ordering. This value indicates, how many "empty" pixels
|
||||
(pixels with deasserted Data Enable signal) are necessary to generate the
|
||||
internal HSYNC pulse. The value must be greater than 1 and smaller than
|
||||
vsync_gap_length.
|
||||
|
||||
**pclk_frequency** (R):
|
||||
Input pixel clock frequency in kHz.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the pixelclock field of the v4l2_bt_timings struct.
|
||||
|
||||
*Note: The frequency_range parameter must be set properly first to get
|
||||
a valid frequency here.*
|
||||
|
||||
**hsync_width** (R):
|
||||
Width of the HSYNC signal in PCLK clock ticks.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the hsync field of the v4l2_bt_timings struct.
|
||||
|
||||
**vsync_width** (R):
|
||||
Width of the VSYNC signal in PCLK clock ticks.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the vsync field of the v4l2_bt_timings struct.
|
||||
|
||||
**hback_porch** (R):
|
||||
Number of PCLK pulses between deassertion of the HSYNC signal and the first
|
||||
valid pixel in the video line (marked by DE=1).
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the hbackporch field of the v4l2_bt_timings struct.
|
||||
|
||||
**hfront_porch** (R):
|
||||
Number of PCLK pulses between the end of the last valid pixel in the video
|
||||
line (marked by DE=1) and assertion of the HSYNC signal.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the hfrontporch field of the v4l2_bt_timings struct.
|
||||
|
||||
**vback_porch** (R):
|
||||
Number of video lines between deassertion of the VSYNC signal and the video
|
||||
line with the first valid pixel (marked by DE=1).
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the vbackporch field of the v4l2_bt_timings struct.
|
||||
|
||||
**vfront_porch** (R):
|
||||
Number of video lines between the end of the last valid pixel line (marked
|
||||
by DE=1) and assertion of the VSYNC signal.
|
||||
|
||||
The value is identical to what VIDIOC_QUERY_DV_TIMINGS returns in
|
||||
the vfrontporch field of the v4l2_bt_timings struct.
|
||||
|
||||
**frequency_range** (RW)
|
||||
PLL frequency range of the OLDI input clock generator. The PLL frequency is
|
||||
derived from the Pixel Clock Frequency (PCLK) and is equal to PCLK if
|
||||
oldi_lane_width is set to "single" and PCLK/2 if oldi_lane_width is set to
|
||||
"dual".
|
||||
|
||||
| 0 - PLL < 50MHz (default)
|
||||
| 1 - PLL >= 50MHz
|
||||
|
||||
*Note: This parameter can not be changed while the input v4l2 device is
|
||||
open.*
|
||||
|
||||
|
||||
Common FPDL3/GMSL output parameters
|
||||
===================================
|
||||
|
||||
**output_id** (R):
|
||||
Output number ID, zero based.
|
||||
|
||||
**video_source** (RW):
|
||||
Output video source. If set to 0 or 1, the source is the corresponding card
|
||||
input and the v4l2 output devices are disabled. If set to 2 or 3, the source
|
||||
is the corresponding v4l2 video output device. The default is
|
||||
the corresponding v4l2 output, i.e. 2 for OUT1 and 3 for OUT2.
|
||||
|
||||
| 0 - input 0
|
||||
| 1 - input 1
|
||||
| 2 - v4l2 output 0
|
||||
| 3 - v4l2 output 1
|
||||
|
||||
*Note: This parameter can not be changed while ANY of the input/output v4l2
|
||||
devices is open.*
|
||||
|
||||
**display_width** (RW):
|
||||
Display width. There is no autodetection of the connected display, so the
|
||||
proper value must be set before the start of streaming. The default width
|
||||
is 1280.
|
||||
|
||||
*Note: This parameter can not be changed while the output v4l2 device is
|
||||
open.*
|
||||
|
||||
**display_height** (RW):
|
||||
Display height. There is no autodetection of the connected display, so the
|
||||
proper value must be set before the start of streaming. The default height
|
||||
is 640.
|
||||
|
||||
*Note: This parameter can not be changed while the output v4l2 device is
|
||||
open.*
|
||||
|
||||
**frame_rate** (RW):
|
||||
Output video frame rate in frames per second. The default frame rate is
|
||||
60Hz.
|
||||
|
||||
**hsync_polarity** (RW):
|
||||
HSYNC signal polarity.
|
||||
|
||||
| 0 - active low (default)
|
||||
| 1 - active high
|
||||
|
||||
**vsync_polarity** (RW):
|
||||
VSYNC signal polarity.
|
||||
|
||||
| 0 - active low (default)
|
||||
| 1 - active high
|
||||
|
||||
**de_polarity** (RW):
|
||||
DE signal polarity.
|
||||
|
||||
| 0 - active low
|
||||
| 1 - active high (default)
|
||||
|
||||
**pclk_frequency** (RW):
|
||||
Output pixel clock frequency. Allowed values are between 25000-190000(kHz)
|
||||
and there is a non-linear stepping between two consecutive allowed
|
||||
frequencies. The driver finds the nearest allowed frequency to the given
|
||||
value and sets it. When reading this property, you get the exact
|
||||
frequency set by the driver. The default frequency is 70000kHz.
|
||||
|
||||
*Note: This parameter can not be changed while the output v4l2 device is
|
||||
open.*
|
||||
|
||||
**hsync_width** (RW):
|
||||
Width of the HSYNC signal in pixels. The default value is 16.
|
||||
|
||||
**vsync_width** (RW):
|
||||
Width of the VSYNC signal in video lines. The default value is 2.
|
||||
|
||||
**hback_porch** (RW):
|
||||
Number of PCLK pulses between deassertion of the HSYNC signal and the first
|
||||
valid pixel in the video line (marked by DE=1). The default value is 32.
|
||||
|
||||
**hfront_porch** (RW):
|
||||
Number of PCLK pulses between the end of the last valid pixel in the video
|
||||
line (marked by DE=1) and assertion of the HSYNC signal. The default value
|
||||
is 32.
|
||||
|
||||
**vback_porch** (RW):
|
||||
Number of video lines between deassertion of the VSYNC signal and the video
|
||||
line with the first valid pixel (marked by DE=1). The default value is 2.
|
||||
|
||||
**vfront_porch** (RW):
|
||||
Number of video lines between the end of the last valid pixel line (marked
|
||||
by DE=1) and assertion of the VSYNC signal. The default value is 2.
|
||||
|
||||
|
||||
FPDL3 specific input parameters
|
||||
===============================
|
||||
|
||||
**fpdl3_input_width** (RW):
|
||||
Number of deserializer input lines.
|
||||
|
||||
| 0 - auto (default)
|
||||
| 1 - single
|
||||
| 2 - dual
|
||||
|
||||
FPDL3 specific output parameters
|
||||
================================
|
||||
|
||||
**fpdl3_output_width** (RW):
|
||||
Number of serializer output lines.
|
||||
|
||||
| 0 - auto (default)
|
||||
| 1 - single
|
||||
| 2 - dual
|
||||
|
||||
GMSL specific input parameters
|
||||
==============================
|
||||
|
||||
**gmsl_mode** (RW):
|
||||
GMSL speed mode.
|
||||
|
||||
| 0 - 12Gb/s (default)
|
||||
| 1 - 6Gb/s
|
||||
| 2 - 3Gb/s
|
||||
| 3 - 1.5Gb/s
|
||||
|
||||
**gmsl_stream_id** (RW):
|
||||
The GMSL multi-stream contains up to four video streams. This parameter
|
||||
selects which stream is captured by the video input. The value is the
|
||||
zero-based index of the stream. The default stream id is 0.
|
||||
|
||||
*Note: This parameter can not be changed while the input v4l2 device is
|
||||
open.*
|
||||
|
||||
**gmsl_fec** (RW):
|
||||
GMSL Forward Error Correction (FEC).
|
||||
|
||||
| 0 - disabled
|
||||
| 1 - enabled (default)
|
||||
|
||||
|
||||
====================
|
||||
mgb4 mtd partitions
|
||||
====================
|
||||
|
||||
The mgb4 driver creates a MTD device with two partitions:
|
||||
- mgb4-fw.X - FPGA firmware.
|
||||
- mgb4-data.X - Factory settings, e.g. card serial number.
|
||||
|
||||
The *mgb4-fw* partition is writable and is used for FW updates, *mgb4-data* is
|
||||
read-only. The *X* attached to the partition name represents the card number.
|
||||
Depending on the CONFIG_MTD_PARTITIONED_MASTER kernel configuration, you may
|
||||
also have a third partition named *mgb4-flash* available in the system. This
|
||||
partition represents the whole, unpartitioned, card's FLASH memory and one should
|
||||
not fiddle with it...
|
||||
|
||||
====================
|
||||
mgb4 iio (triggers)
|
||||
====================
|
||||
|
||||
The mgb4 driver creates an Industrial I/O (IIO) device that provides trigger and
|
||||
signal level status capability. The following scan elements are available:
|
||||
|
||||
**activity**:
|
||||
The trigger levels and pending status.
|
||||
|
||||
| bit 1 - trigger 1 pending
|
||||
| bit 2 - trigger 2 pending
|
||||
| bit 5 - trigger 1 level
|
||||
| bit 6 - trigger 2 level
|
||||
|
||||
**timestamp**:
|
||||
The trigger event timestamp.
|
||||
|
||||
The iio device can operate either in "raw" mode where you can fetch the signal
|
||||
levels (activity bits 5 and 6) using sysfs access or in triggered buffer mode.
|
||||
In the triggered buffer mode you can follow the signal level changes (activity
|
||||
bits 1 and 2) using the iio device in /dev. If you enable the timestamps, you
|
||||
will also get the exact trigger event time that can be matched to a video frame
|
||||
(every mgb4 video frame has a timestamp with the same clock source).
|
||||
|
||||
*Note: although the activity sample always contains all the status bits, it makes
|
||||
no sense to get the pending bits in raw mode or the level bits in the triggered
|
||||
buffer mode - the values do not represent valid data in such case.*
|
@ -77,6 +77,7 @@ ipu3-cio2 Intel ipu3-cio2 driver
|
||||
ivtv Conexant cx23416/cx23415 MPEG encoder/decoder
|
||||
ivtvfb Conexant cx23415 framebuffer
|
||||
mantis MANTIS based cards
|
||||
mgb4 Digiteq Automotive MGB4 frame grabber
|
||||
mxb Siemens-Nixdorf 'Multimedia eXtension Board'
|
||||
netup-unidvb NetUP Universal DVB card
|
||||
ngene Micronas nGene
|
||||
|
@ -17,6 +17,7 @@ Video4Linux (V4L) driver-specific documentation
|
||||
imx7
|
||||
ipu3
|
||||
ivtv
|
||||
mgb4
|
||||
omap3isp
|
||||
omap4_camera
|
||||
philips
|
||||
|
@ -78,7 +78,7 @@ The trace events are defined on a per-codec basis, e.g.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ ls /sys/kernel/debug/tracing/events/ | grep visl
|
||||
$ ls /sys/kernel/tracing/events/ | grep visl
|
||||
visl_fwht_controls
|
||||
visl_h264_controls
|
||||
visl_hevc_controls
|
||||
@ -90,13 +90,13 @@ For example, in order to dump HEVC SPS data:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ echo 1 > /sys/kernel/debug/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
|
||||
$ echo 1 > /sys/kernel/tracing/events/visl_hevc_controls/v4l2_ctrl_hevc_sps/enable
|
||||
|
||||
The SPS data will be dumped to the trace buffer, i.e.:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
$ cat /sys/kernel/debug/tracing/trace
|
||||
$ cat /sys/kernel/tracing/trace
|
||||
video_parameter_set_id 0
|
||||
seq_parameter_set_id 0
|
||||
pic_width_in_luma_samples 1920
|
||||
|
@ -20,18 +20,18 @@ DAMON provides below interfaces for different users.
|
||||
you can write and use your personalized DAMON sysfs wrapper programs that
|
||||
reads/writes the sysfs files instead of you. The `DAMON user space tool
|
||||
<https://github.com/awslabs/damo>`_ is one example of such programs.
|
||||
- *debugfs interface. (DEPRECATED!)*
|
||||
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
|
||||
<sysfs_interface>`. This is deprecated, so users should move to the
|
||||
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
|
||||
move, please report your usecase to damon@lists.linux.dev and
|
||||
linux-mm@kvack.org.
|
||||
- *Kernel Space Programming Interface.*
|
||||
:doc:`This </mm/damon/api>` 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. For detail, please refer to the interface
|
||||
:doc:`document </mm/damon/api>`.
|
||||
- *debugfs interface. (DEPRECATED!)*
|
||||
:ref:`This <debugfs_interface>` is almost identical to :ref:`sysfs interface
|
||||
<sysfs_interface>`. This is deprecated, so users should move to the
|
||||
:ref:`sysfs interface <sysfs_interface>`. If you depend on this and cannot
|
||||
move, please report your usecase to damon@lists.linux.dev and
|
||||
linux-mm@kvack.org.
|
||||
|
||||
.. _sysfs_interface:
|
||||
|
||||
@ -76,7 +76,7 @@ comma (","). ::
|
||||
│ │ │ │ │ │ │ │ ...
|
||||
│ │ │ │ │ │ ...
|
||||
│ │ │ │ │ schemes/nr_schemes
|
||||
│ │ │ │ │ │ 0/action
|
||||
│ │ │ │ │ │ 0/action,apply_interval_us
|
||||
│ │ │ │ │ │ │ access_pattern/
|
||||
│ │ │ │ │ │ │ │ sz/min,max
|
||||
│ │ │ │ │ │ │ │ nr_accesses/min,max
|
||||
@ -105,14 +105,12 @@ having the root permission could use this directory.
|
||||
kdamonds/
|
||||
---------
|
||||
|
||||
The monitoring-related information including request specifications and results
|
||||
are called DAMON context. DAMON executes each context with a kernel thread
|
||||
called kdamond, and multiple kdamonds could run in parallel.
|
||||
|
||||
Under the ``admin`` directory, one directory, ``kdamonds``, which has files for
|
||||
controlling the kdamonds exist. In the beginning, this directory has only one
|
||||
file, ``nr_kdamonds``. Writing a number (``N``) to the file creates the number
|
||||
of child directories named ``0`` to ``N-1``. Each directory represents each
|
||||
controlling the kdamonds (refer to
|
||||
:ref:`design <damon_design_execution_model_and_data_structures>` for more
|
||||
details) exists. In the beginning, this directory has only one file,
|
||||
``nr_kdamonds``. Writing a number (``N``) to the file creates the number of
|
||||
child directories named ``0`` to ``N-1``. Each directory represents each
|
||||
kdamond.
|
||||
|
||||
kdamonds/<N>/
|
||||
@ -150,9 +148,10 @@ kdamonds/<N>/contexts/
|
||||
|
||||
In the beginning, this directory has only one file, ``nr_contexts``. Writing a
|
||||
number (``N``) to the file creates the number of child directories named as
|
||||
``0`` to ``N-1``. Each directory represents each monitoring context. At the
|
||||
moment, only one context per kdamond is supported, so only ``0`` or ``1`` can
|
||||
be written to the file.
|
||||
``0`` to ``N-1``. Each directory represents each monitoring context (refer to
|
||||
:ref:`design <damon_design_execution_model_and_data_structures>` for more
|
||||
details). At the moment, only one context per kdamond is supported, so only
|
||||
``0`` or ``1`` can be written to the file.
|
||||
|
||||
.. _sysfs_contexts:
|
||||
|
||||
@ -270,8 +269,8 @@ schemes/<N>/
|
||||
------------
|
||||
|
||||
In each scheme directory, five directories (``access_pattern``, ``quotas``,
|
||||
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and one file
|
||||
(``action``) exist.
|
||||
``watermarks``, ``filters``, ``stats``, and ``tried_regions``) and two files
|
||||
(``action`` and ``apply_interval``) exist.
|
||||
|
||||
The ``action`` file is for setting and getting the scheme's :ref:`action
|
||||
<damon_design_damos_action>`. The keywords that can be written to and read
|
||||
@ -297,6 +296,9 @@ Note that support of each action depends on the running DAMON operations set
|
||||
- ``stat``: Do nothing but count the statistics.
|
||||
Supported by all operations sets.
|
||||
|
||||
The ``apply_interval_us`` file is for setting and getting the scheme's
|
||||
:ref:`apply_interval <damon_design_damos>` in microseconds.
|
||||
|
||||
schemes/<N>/access_pattern/
|
||||
---------------------------
|
||||
|
||||
@ -392,7 +394,7 @@ pages of all memory cgroups except ``/having_care_already``.::
|
||||
echo N > 1/matching
|
||||
|
||||
Note that ``anon`` and ``memcg`` filters are currently supported only when
|
||||
``paddr`` `implementation <sysfs_contexts>` is being used.
|
||||
``paddr`` :ref:`implementation <sysfs_contexts>` is being used.
|
||||
|
||||
Also, memory regions that are filtered out by ``addr`` or ``target`` filters
|
||||
are not counted as the scheme has tried to those, while regions that filtered
|
||||
@ -430,9 +432,9 @@ that reading it returns the total size of the scheme tried regions, and creates
|
||||
directories named integer starting from ``0`` under this directory. Each
|
||||
directory contains files exposing detailed information about each of the memory
|
||||
region that the corresponding scheme's ``action`` has tried to be applied under
|
||||
this directory, during next :ref:`aggregation interval
|
||||
<sysfs_monitoring_attrs>`. The information includes address range,
|
||||
``nr_accesses``, and ``age`` of the region.
|
||||
this directory, during next :ref:`apply interval <damon_design_damos>` of the
|
||||
corresponding scheme. The information includes address range, ``nr_accesses``,
|
||||
and ``age`` of the region.
|
||||
|
||||
Writing ``update_schemes_tried_bytes`` to the relevant ``kdamonds/<N>/state``
|
||||
file will only update the ``total_bytes`` file, and will not create the
|
||||
@ -495,6 +497,62 @@ Please note that it's highly recommended to use user space tools like `damo
|
||||
<https://github.com/awslabs/damo>`_ rather than manually reading and writing
|
||||
the files as above. Above is only for an example.
|
||||
|
||||
.. _tracepoint:
|
||||
|
||||
Tracepoints for Monitoring Results
|
||||
==================================
|
||||
|
||||
Users can get the monitoring results via the :ref:`tried_regions
|
||||
<sysfs_schemes_tried_regions>`. The interface is useful for getting a
|
||||
snapshot, but it could be inefficient for fully recording all the monitoring
|
||||
results. For the purpose, two trace points, namely ``damon:damon_aggregated``
|
||||
and ``damon:damos_before_apply``, are provided. ``damon:damon_aggregated``
|
||||
provides the whole monitoring results, while ``damon:damos_before_apply``
|
||||
provides the monitoring results for regions that each DAMON-based Operation
|
||||
Scheme (:ref:`DAMOS <damon_design_damos>`) is gonna be applied. Hence,
|
||||
``damon:damos_before_apply`` is more useful for recording internal behavior of
|
||||
DAMOS, or DAMOS target access
|
||||
:ref:`pattern <damon_design_damos_access_pattern>` based query-like efficient
|
||||
monitoring results recording.
|
||||
|
||||
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
|
||||
kdamond.0 46568 [027] 79357.842179: damon:damon_aggregated: target_id=0 nr_regions=11 122509119488-135708762112: 0 864
|
||||
[...]
|
||||
|
||||
Each line of the perf script output represents each monitoring region. The
|
||||
first five fields are as usual other tracepoint outputs. The sixth field
|
||||
(``target_id=X``) shows the ide of the monitoring target of the region. The
|
||||
seventh field (``nr_regions=X``) shows the total number of monitoring regions
|
||||
for the target. The eighth field (``X-Y:``) shows the start (``X``) and end
|
||||
(``Y``) addresses of the region in bytes. The ninth field (``X``) shows the
|
||||
``nr_accesses`` of the region (refer to
|
||||
:ref:`design <damon_design_region_based_sampling>` for more details of the
|
||||
counter). Finally the tenth field (``X``) shows the ``age`` of the region
|
||||
(refer to :ref:`design <damon_design_age_tracking>` for more details of the
|
||||
counter).
|
||||
|
||||
If the event was ``damon:damos_beofre_apply``, the ``perf script`` output would
|
||||
be somewhat like below::
|
||||
|
||||
kdamond.0 47293 [000] 80801.060214: damon:damos_before_apply: ctx_idx=0 scheme_idx=0 target_idx=0 nr_regions=11 121932607488-135128711168: 0 136
|
||||
[...]
|
||||
|
||||
Each line of the output represents each monitoring region that each DAMON-based
|
||||
Operation Scheme was about to be applied at the traced time. The first five
|
||||
fields are as usual. It shows the index of the DAMON context (``ctx_idx=X``)
|
||||
of the scheme in the list of the contexts of the context's kdamond, the index
|
||||
of the scheme (``scheme_idx=X``) in the list of the schemes of the context, in
|
||||
addition to the output of ``damon_aggregated`` tracepoint.
|
||||
|
||||
|
||||
.. _debugfs_interface:
|
||||
|
||||
debugfs Interface (DEPRECATED!)
|
||||
@ -790,23 +848,3 @@ directory by putting the name of the context to the ``rm_contexts`` file. ::
|
||||
|
||||
Note that ``mk_contexts``, ``rm_contexts``, and ``monitor_on`` files are in the
|
||||
root directory only.
|
||||
|
||||
|
||||
.. _tracepoint:
|
||||
|
||||
Tracepoint for Monitoring Results
|
||||
=================================
|
||||
|
||||
Users can get the monitoring results via the :ref:`tried_regions
|
||||
<sysfs_schemes_tried_regions>` or a tracepoint, ``damon:damon_aggregated``.
|
||||
While the tried regions directory is useful for getting a snapshot, the
|
||||
tracepoint is useful for getting a full record of the results. 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
|
||||
|
@ -155,6 +155,15 @@ stable_node_chains_prune_millisecs
|
||||
scan. It's a noop if not a single KSM page hit the
|
||||
``max_page_sharing`` yet.
|
||||
|
||||
smart_scan
|
||||
Historically KSM checked every candidate page for each scan. It did
|
||||
not take into account historic information. When smart scan is
|
||||
enabled, pages that have previously not been de-duplicated get
|
||||
skipped. How often these pages are skipped depends on how often
|
||||
de-duplication has already been tried and failed. By default this
|
||||
optimization is enabled. The ``pages_skipped`` metric shows how
|
||||
effective the setting is.
|
||||
|
||||
The effectiveness of KSM and MADV_MERGEABLE is shown in ``/sys/kernel/mm/ksm/``:
|
||||
|
||||
general_profit
|
||||
@ -169,6 +178,8 @@ pages_unshared
|
||||
how many pages unique but repeatedly checked for merging
|
||||
pages_volatile
|
||||
how many pages changing too fast to be placed in a tree
|
||||
pages_skipped
|
||||
how many pages did the "smart" page scanning algorithm skip
|
||||
full_scans
|
||||
how many times all mergeable areas have been scanned
|
||||
stable_node_chains
|
||||
|
@ -227,3 +227,92 @@ Before Linux 3.11 pagemap bits 55-60 were used for "page-shift" (which is
|
||||
always 12 at most architectures). Since Linux 3.11 their meaning changes
|
||||
after first clear of soft-dirty bits. Since Linux 4.2 they are used for
|
||||
flags unconditionally.
|
||||
|
||||
Pagemap Scan IOCTL
|
||||
==================
|
||||
|
||||
The ``PAGEMAP_SCAN`` IOCTL on the pagemap file can be used to get or optionally
|
||||
clear the info about page table entries. The following operations are supported
|
||||
in this IOCTL:
|
||||
|
||||
- Scan the address range and get the memory ranges matching the provided criteria.
|
||||
This is performed when the output buffer is specified.
|
||||
- Write-protect the pages. The ``PM_SCAN_WP_MATCHING`` is used to write-protect
|
||||
the pages of interest. The ``PM_SCAN_CHECK_WPASYNC`` aborts the operation if
|
||||
non-Async Write Protected pages are found. The ``PM_SCAN_WP_MATCHING`` can be
|
||||
used with or without ``PM_SCAN_CHECK_WPASYNC``.
|
||||
- Both of those operations can be combined into one atomic operation where we can
|
||||
get and write protect the pages as well.
|
||||
|
||||
Following flags about pages are currently supported:
|
||||
|
||||
- ``PAGE_IS_WPALLOWED`` - Page has async-write-protection enabled
|
||||
- ``PAGE_IS_WRITTEN`` - Page has been written to from the time it was write protected
|
||||
- ``PAGE_IS_FILE`` - Page is file backed
|
||||
- ``PAGE_IS_PRESENT`` - Page is present in the memory
|
||||
- ``PAGE_IS_SWAPPED`` - Page is in swapped
|
||||
- ``PAGE_IS_PFNZERO`` - Page has zero PFN
|
||||
- ``PAGE_IS_HUGE`` - Page is THP or Hugetlb backed
|
||||
|
||||
The ``struct pm_scan_arg`` is used as the argument of the IOCTL.
|
||||
|
||||
1. The size of the ``struct pm_scan_arg`` must be specified in the ``size``
|
||||
field. This field will be helpful in recognizing the structure if extensions
|
||||
are done later.
|
||||
2. The flags can be specified in the ``flags`` field. The ``PM_SCAN_WP_MATCHING``
|
||||
and ``PM_SCAN_CHECK_WPASYNC`` are the only added flags at this time. The get
|
||||
operation is optionally performed depending upon if the output buffer is
|
||||
provided or not.
|
||||
3. The range is specified through ``start`` and ``end``.
|
||||
4. The walk can abort before visiting the complete range such as the user buffer
|
||||
can get full etc. The walk ending address is specified in``end_walk``.
|
||||
5. The output buffer of ``struct page_region`` array and size is specified in
|
||||
``vec`` and ``vec_len``.
|
||||
6. The optional maximum requested pages are specified in the ``max_pages``.
|
||||
7. The masks are specified in ``category_mask``, ``category_anyof_mask``,
|
||||
``category_inverted`` and ``return_mask``.
|
||||
|
||||
Find pages which have been written and WP them as well::
|
||||
|
||||
struct pm_scan_arg arg = {
|
||||
.size = sizeof(arg),
|
||||
.flags = PM_SCAN_CHECK_WPASYNC | PM_SCAN_CHECK_WPASYNC,
|
||||
..
|
||||
.category_mask = PAGE_IS_WRITTEN,
|
||||
.return_mask = PAGE_IS_WRITTEN,
|
||||
};
|
||||
|
||||
Find pages which have been written, are file backed, not swapped and either
|
||||
present or huge::
|
||||
|
||||
struct pm_scan_arg arg = {
|
||||
.size = sizeof(arg),
|
||||
.flags = 0,
|
||||
..
|
||||
.category_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED,
|
||||
.category_inverted = PAGE_IS_SWAPPED,
|
||||
.category_anyof_mask = PAGE_IS_PRESENT | PAGE_IS_HUGE,
|
||||
.return_mask = PAGE_IS_WRITTEN | PAGE_IS_SWAPPED |
|
||||
PAGE_IS_PRESENT | PAGE_IS_HUGE,
|
||||
};
|
||||
|
||||
The ``PAGE_IS_WRITTEN`` flag can be considered as a better-performing alternative
|
||||
of soft-dirty flag. It doesn't get affected by VMA merging of the kernel and hence
|
||||
the user can find the true soft-dirty pages in case of normal pages. (There may
|
||||
still be extra dirty pages reported for THP or Hugetlb pages.)
|
||||
|
||||
"PAGE_IS_WRITTEN" category is used with uffd write protect-enabled ranges to
|
||||
implement memory dirty tracking in userspace:
|
||||
|
||||
1. The userfaultfd file descriptor is created with ``userfaultfd`` syscall.
|
||||
2. The ``UFFD_FEATURE_WP_UNPOPULATED`` and ``UFFD_FEATURE_WP_ASYNC`` features
|
||||
are set by ``UFFDIO_API`` IOCTL.
|
||||
3. The memory range is registered with ``UFFDIO_REGISTER_MODE_WP`` mode
|
||||
through ``UFFDIO_REGISTER`` IOCTL.
|
||||
4. Then any part of the registered memory or the whole memory region must
|
||||
be write protected using ``PAGEMAP_SCAN`` IOCTL with flag ``PM_SCAN_WP_MATCHING``
|
||||
or the ``UFFDIO_WRITEPROTECT`` IOCTL can be used. Both of these perform the
|
||||
same operation. The former is better in terms of performance.
|
||||
5. Now the ``PAGEMAP_SCAN`` IOCTL can be used to either just find pages which
|
||||
have been written to since they were last marked and/or optionally write protect
|
||||
the pages as well.
|
||||
|
@ -244,6 +244,41 @@ write-protected (so future writes will also result in a WP fault). These ioctls
|
||||
support a mode flag (``UFFDIO_COPY_MODE_WP`` or ``UFFDIO_CONTINUE_MODE_WP``
|
||||
respectively) to configure the mapping this way.
|
||||
|
||||
If the userfaultfd context has ``UFFD_FEATURE_WP_ASYNC`` feature bit set,
|
||||
any vma registered with write-protection will work in async mode rather
|
||||
than the default sync mode.
|
||||
|
||||
In async mode, there will be no message generated when a write operation
|
||||
happens, meanwhile the write-protection will be resolved automatically by
|
||||
the kernel. It can be seen as a more accurate version of soft-dirty
|
||||
tracking and it can be different in a few ways:
|
||||
|
||||
- The dirty result will not be affected by vma changes (e.g. vma
|
||||
merging) because the dirty is only tracked by the pte.
|
||||
|
||||
- It supports range operations by default, so one can enable tracking on
|
||||
any range of memory as long as page aligned.
|
||||
|
||||
- Dirty information will not get lost if the pte was zapped due to
|
||||
various reasons (e.g. during split of a shmem transparent huge page).
|
||||
|
||||
- Due to a reverted meaning of soft-dirty (page clean when uffd-wp bit
|
||||
set; dirty when uffd-wp bit cleared), it has different semantics on
|
||||
some of the memory operations. For example: ``MADV_DONTNEED`` on
|
||||
anonymous (or ``MADV_REMOVE`` on a file mapping) will be treated as
|
||||
dirtying of memory by dropping uffd-wp bit during the procedure.
|
||||
|
||||
The user app can collect the "written/dirty" status by looking up the
|
||||
uffd-wp bit for the pages being interested in /proc/pagemap.
|
||||
|
||||
The page will not be under track of uffd-wp async mode until the page is
|
||||
explicitly write-protected by ``ioctl(UFFDIO_WRITEPROTECT)`` with the mode
|
||||
flag ``UFFDIO_WRITEPROTECT_MODE_WP`` set. Trying to resolve a page fault
|
||||
that was tracked by async mode userfaultfd-wp is invalid.
|
||||
|
||||
When userfaultfd-wp async mode is used alone, it can be applied to all
|
||||
kinds of memory.
|
||||
|
||||
Memory Poisioning Emulation
|
||||
---------------------------
|
||||
|
||||
|
@ -28,10 +28,10 @@ trusted userspace bits.
|
||||
|
||||
This facility uses X.509 ITU-T standard certificates to encode the public keys
|
||||
involved. The signatures are not themselves encoded in any industrial standard
|
||||
type. The facility currently only supports the RSA public key encryption
|
||||
standard (though it is pluggable and permits others to be used). The possible
|
||||
hash algorithms that can be used are SHA-1, SHA-224, SHA-256, SHA-384, and
|
||||
SHA-512 (the algorithm is selected by data in the signature).
|
||||
type. The built-in facility currently only supports the RSA & NIST P-384 ECDSA
|
||||
public key signing standard (though it is pluggable and permits others to be
|
||||
used). The possible hash algorithms that can be used are SHA-2 and SHA-3 of
|
||||
sizes 256, 384, and 512 (the algorithm is selected by data in the signature).
|
||||
|
||||
|
||||
==========================
|
||||
@ -81,11 +81,12 @@ This has a number of options available:
|
||||
sign the modules with:
|
||||
|
||||
=============================== ==========================================
|
||||
``CONFIG_MODULE_SIG_SHA1`` :menuselection:`Sign modules with SHA-1`
|
||||
``CONFIG_MODULE_SIG_SHA224`` :menuselection:`Sign modules with SHA-224`
|
||||
``CONFIG_MODULE_SIG_SHA256`` :menuselection:`Sign modules with SHA-256`
|
||||
``CONFIG_MODULE_SIG_SHA384`` :menuselection:`Sign modules with SHA-384`
|
||||
``CONFIG_MODULE_SIG_SHA512`` :menuselection:`Sign modules with SHA-512`
|
||||
``CONFIG_MODULE_SIG_SHA3_256`` :menuselection:`Sign modules with SHA3-256`
|
||||
``CONFIG_MODULE_SIG_SHA3_384`` :menuselection:`Sign modules with SHA3-384`
|
||||
``CONFIG_MODULE_SIG_SHA3_512`` :menuselection:`Sign modules with SHA3-512`
|
||||
=============================== ==========================================
|
||||
|
||||
The algorithm selected here will also be built into the kernel (rather
|
||||
@ -145,6 +146,10 @@ into vmlinux) using parameters in the::
|
||||
|
||||
file (which is also generated if it does not already exist).
|
||||
|
||||
One can select between RSA (``MODULE_SIG_KEY_TYPE_RSA``) and ECDSA
|
||||
(``MODULE_SIG_KEY_TYPE_ECDSA``) to generate either RSA 4k or NIST
|
||||
P-384 keypair.
|
||||
|
||||
It is strongly recommended that you provide your own x509.genkey file.
|
||||
|
||||
Most notably, in the x509.genkey file, the req_distinguished_name section
|
||||
|
@ -174,7 +174,7 @@ HWCAP2_DCPODP
|
||||
Functionality implied by ID_AA64ISAR1_EL1.DPB == 0b0010.
|
||||
|
||||
HWCAP2_SVE2
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SVEVer == 0b0001.
|
||||
Functionality implied by ID_AA64ZFR0_EL1.SVEver == 0b0001.
|
||||
|
||||
HWCAP2_SVEAES
|
||||
Functionality implied by ID_AA64ZFR0_EL1.AES == 0b0001.
|
||||
@ -222,7 +222,7 @@ HWCAP2_RNG
|
||||
Functionality implied by ID_AA64ISAR0_EL1.RNDR == 0b0001.
|
||||
|
||||
HWCAP2_BTI
|
||||
Functionality implied by ID_AA64PFR0_EL1.BT == 0b0001.
|
||||
Functionality implied by ID_AA64PFR1_EL1.BT == 0b0001.
|
||||
|
||||
HWCAP2_MTE
|
||||
Functionality implied by ID_AA64PFR1_EL1.MTE == 0b0010, as described
|
||||
@ -232,7 +232,7 @@ HWCAP2_ECV
|
||||
Functionality implied by ID_AA64MMFR0_EL1.ECV == 0b0001.
|
||||
|
||||
HWCAP2_AFP
|
||||
Functionality implied by ID_AA64MFR1_EL1.AFP == 0b0001.
|
||||
Functionality implied by ID_AA64MMFR1_EL1.AFP == 0b0001.
|
||||
|
||||
HWCAP2_RPRES
|
||||
Functionality implied by ID_AA64ISAR2_EL1.RPRES == 0b0001.
|
||||
|
@ -375,9 +375,9 @@ Developer web site of Loongson and LoongArch (Software and Documentation):
|
||||
|
||||
Documentation of LoongArch ISA:
|
||||
|
||||
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-CN.pdf (in Chinese)
|
||||
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-CN.pdf (in Chinese)
|
||||
|
||||
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.02-EN.pdf (in English)
|
||||
https://github.com/loongson/LoongArch-Documentation/releases/latest/download/LoongArch-Vol1-v1.10-EN.pdf (in English)
|
||||
|
||||
Documentation of LoongArch ELF psABI:
|
||||
|
||||
|
@ -26,6 +26,7 @@ powerpc
|
||||
isa-versions
|
||||
kaslr-booke32
|
||||
mpc52xx
|
||||
kvm-nested
|
||||
papr_hcalls
|
||||
pci_iov_resource_on_powernv
|
||||
pmu-ebb
|
||||
|
634
Documentation/arch/powerpc/kvm-nested.rst
Normal file
634
Documentation/arch/powerpc/kvm-nested.rst
Normal file
@ -0,0 +1,634 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
====================================
|
||||
Nested KVM on POWER
|
||||
====================================
|
||||
|
||||
Introduction
|
||||
============
|
||||
|
||||
This document explains how a guest operating system can act as a
|
||||
hypervisor and run nested guests through the use of hypercalls, if the
|
||||
hypervisor has implemented them. The terms L0, L1, and L2 are used to
|
||||
refer to different software entities. L0 is the hypervisor mode entity
|
||||
that would normally be called the "host" or "hypervisor". L1 is a
|
||||
guest virtual machine that is directly run under L0 and is initiated
|
||||
and controlled by L0. L2 is a guest virtual machine that is initiated
|
||||
and controlled by L1 acting as a hypervisor.
|
||||
|
||||
Existing API
|
||||
============
|
||||
|
||||
Linux/KVM has had support for Nesting as an L0 or L1 since 2018
|
||||
|
||||
The L0 code was added::
|
||||
|
||||
commit 8e3f5fc1045dc49fd175b978c5457f5f51e7a2ce
|
||||
Author: Paul Mackerras <paulus@ozlabs.org>
|
||||
Date: Mon Oct 8 16:31:03 2018 +1100
|
||||
KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization
|
||||
|
||||
The L1 code was added::
|
||||
|
||||
commit 360cae313702cdd0b90f82c261a8302fecef030a
|
||||
Author: Paul Mackerras <paulus@ozlabs.org>
|
||||
Date: Mon Oct 8 16:31:04 2018 +1100
|
||||
KVM: PPC: Book3S HV: Nested guest entry via hypercall
|
||||
|
||||
This API works primarily using a single hcall h_enter_nested(). This
|
||||
call made by the L1 to tell the L0 to start an L2 vCPU with the given
|
||||
state. The L0 then starts this L2 and runs until an L2 exit condition
|
||||
is reached. Once the L2 exits, the state of the L2 is given back to
|
||||
the L1 by the L0. The full L2 vCPU state is always transferred from
|
||||
and to L1 when the L2 is run. The L0 doesn't keep any state on the L2
|
||||
vCPU (except in the short sequence in the L0 on L1 -> L2 entry and L2
|
||||
-> L1 exit).
|
||||
|
||||
The only state kept by the L0 is the partition table. The L1 registers
|
||||
it's partition table using the h_set_partition_table() hcall. All
|
||||
other state held by the L0 about the L2s is cached state (such as
|
||||
shadow page tables).
|
||||
|
||||
The L1 may run any L2 or vCPU without first informing the L0. It
|
||||
simply starts the vCPU using h_enter_nested(). The creation of L2s and
|
||||
vCPUs is done implicitly whenever h_enter_nested() is called.
|
||||
|
||||
In this document, we call this existing API the v1 API.
|
||||
|
||||
New PAPR API
|
||||
===============
|
||||
|
||||
The new PAPR API changes from the v1 API such that the creating L2 and
|
||||
associated vCPUs is explicit. In this document, we call this the v2
|
||||
API.
|
||||
|
||||
h_enter_nested() is replaced with H_GUEST_VCPU_RUN(). Before this can
|
||||
be called the L1 must explicitly create the L2 using h_guest_create()
|
||||
and any associated vCPUs() created with h_guest_create_vCPU(). Getting
|
||||
and setting vCPU state can also be performed using h_guest_{g|s}et
|
||||
hcall.
|
||||
|
||||
The basic execution flow is for an L1 to create an L2, run it, and
|
||||
delete it is:
|
||||
|
||||
- L1 and L0 negotiate capabilities with H_GUEST_{G,S}ET_CAPABILITIES()
|
||||
(normally at L1 boot time).
|
||||
|
||||
- L1 requests the L0 create an L2 with H_GUEST_CREATE() and receives a token
|
||||
|
||||
- L1 requests the L0 create an L2 vCPU with H_GUEST_CREATE_VCPU()
|
||||
|
||||
- L1 and L0 communicate the vCPU state using the H_GUEST_{G,S}ET() hcall
|
||||
|
||||
- L1 requests the L0 runs the vCPU running H_GUEST_VCPU_RUN() hcall
|
||||
|
||||
- L1 deletes L2 with H_GUEST_DELETE()
|
||||
|
||||
More details of the individual hcalls follows:
|
||||
|
||||
HCALL Details
|
||||
=============
|
||||
|
||||
This documentation is provided to give an overall understating of the
|
||||
API. It doesn't aim to provide all the details required to implement
|
||||
an L1 or L0. Latest version of PAPR can be referred to for more details.
|
||||
|
||||
All these HCALLs are made by the L1 to the L0.
|
||||
|
||||
H_GUEST_GET_CAPABILITIES()
|
||||
--------------------------
|
||||
|
||||
This is called to get the capabilities of the L0 nested
|
||||
hypervisor. This includes capabilities such the CPU versions (eg
|
||||
POWER9, POWER10) that are supported as L2s::
|
||||
|
||||
H_GUEST_GET_CAPABILITIES(uint64 flags)
|
||||
|
||||
Parameters:
|
||||
Input:
|
||||
flags: Reserved
|
||||
Output:
|
||||
R3: Return code
|
||||
R4: Hypervisor Supported Capabilities bitmap 1
|
||||
|
||||
H_GUEST_SET_CAPABILITIES()
|
||||
--------------------------
|
||||
|
||||
This is called to inform the L0 of the capabilities of the L1
|
||||
hypervisor. The set of flags passed here are the same as
|
||||
H_GUEST_GET_CAPABILITIES()
|
||||
|
||||
Typically, GET will be called first and then SET will be called with a
|
||||
subset of the flags returned from GET. This process allows the L0 and
|
||||
L1 to negotiate an agreed set of capabilities::
|
||||
|
||||
H_GUEST_SET_CAPABILITIES(uint64 flags,
|
||||
uint64 capabilitiesBitmap1)
|
||||
Parameters:
|
||||
Input:
|
||||
flags: Reserved
|
||||
capabilitiesBitmap1: Only capabilities advertised through
|
||||
H_GUEST_GET_CAPABILITIES
|
||||
Output:
|
||||
R3: Return code
|
||||
R4: If R3 = H_P2: The number of invalid bitmaps
|
||||
R5: If R3 = H_P2: The index of first invalid bitmap
|
||||
|
||||
H_GUEST_CREATE()
|
||||
----------------
|
||||
|
||||
This is called to create an L2. A unique ID of the L2 created
|
||||
(similar to an LPID) is returned, which can be used on subsequent HCALLs to
|
||||
identify the L2::
|
||||
|
||||
H_GUEST_CREATE(uint64 flags,
|
||||
uint64 continueToken);
|
||||
Parameters:
|
||||
Input:
|
||||
flags: Reserved
|
||||
continueToken: Initial call set to -1. Subsequent calls,
|
||||
after H_Busy or H_LongBusyOrder has been
|
||||
returned, value that was returned in R4.
|
||||
Output:
|
||||
R3: Return code. Notable:
|
||||
H_Not_Enough_Resources: Unable to create Guest VCPU due to not
|
||||
enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
|
||||
takeOwnershipOfVcpuState)
|
||||
R4: If R3 = H_Busy or_H_LongBusyOrder -> continueToken
|
||||
|
||||
H_GUEST_CREATE_VCPU()
|
||||
---------------------
|
||||
|
||||
This is called to create a vCPU associated with an L2. The L2 id
|
||||
(returned from H_GUEST_CREATE()) should be passed it. Also passed in
|
||||
is a unique (for this L2) vCPUid. This vCPUid is allocated by the
|
||||
L1::
|
||||
|
||||
H_GUEST_CREATE_VCPU(uint64 flags,
|
||||
uint64 guestId,
|
||||
uint64 vcpuId);
|
||||
Parameters:
|
||||
Input:
|
||||
flags: Reserved
|
||||
guestId: ID obtained from H_GUEST_CREATE
|
||||
vcpuId: ID of the vCPU to be created. This must be within the
|
||||
range of 0 to 2047
|
||||
Output:
|
||||
R3: Return code. Notable:
|
||||
H_Not_Enough_Resources: Unable to create Guest VCPU due to not
|
||||
enough Hypervisor memory. See H_GUEST_CREATE_GET_STATE(flags =
|
||||
takeOwnershipOfVcpuState)
|
||||
|
||||
H_GUEST_GET_STATE()
|
||||
-------------------
|
||||
|
||||
This is called to get state associated with an L2 (Guest-wide or vCPU specific).
|
||||
This info is passed via the Guest State Buffer (GSB), a standard format as
|
||||
explained later in this doc, necessary details below:
|
||||
|
||||
This can get either L2 wide or vcpu specific information. Examples of
|
||||
L2 wide is the timebase offset or process scoped page table
|
||||
info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
|
||||
parameter specifies if this call is L2 wide or vCPU specific and the
|
||||
IDs in the GSB must match this.
|
||||
|
||||
The L1 provides a pointer to the GSB as a parameter to this call. Also
|
||||
provided is the L2 and vCPU IDs associated with the state to set.
|
||||
|
||||
The L1 writes only the IDs and sizes in the GSB. L0 writes the
|
||||
associated values for each ID in the GSB::
|
||||
|
||||
H_GUEST_GET_STATE(uint64 flags,
|
||||
uint64 guestId,
|
||||
uint64 vcpuId,
|
||||
uint64 dataBuffer,
|
||||
uint64 dataBufferSizeInBytes);
|
||||
Parameters:
|
||||
Input:
|
||||
flags:
|
||||
Bit 0: getGuestWideState: Request state of the Guest instead
|
||||
of an individual VCPU.
|
||||
Bit 1: takeOwnershipOfVcpuState Indicate the L1 is taking
|
||||
over ownership of the VCPU state and that the L0 can free
|
||||
the storage holding the state. The VCPU state will need to
|
||||
be returned to the Hypervisor via H_GUEST_SET_STATE prior
|
||||
to H_GUEST_RUN_VCPU being called for this VCPU. The data
|
||||
returned in the dataBuffer is in a Hypervisor internal
|
||||
format.
|
||||
Bits 2-63: Reserved
|
||||
guestId: ID obtained from H_GUEST_CREATE
|
||||
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
|
||||
dataBuffer: A L1 real address of the GSB.
|
||||
If takeOwnershipOfVcpuState, size must be at least the size
|
||||
returned by ID=0x0001
|
||||
dataBufferSizeInBytes: Size of dataBuffer
|
||||
Output:
|
||||
R3: Return code
|
||||
R4: If R3 = H_Invalid_Element_Id: The array index of the bad
|
||||
element ID.
|
||||
If R3 = H_Invalid_Element_Size: The array index of the bad
|
||||
element size.
|
||||
If R3 = H_Invalid_Element_Value: The array index of the bad
|
||||
element value.
|
||||
|
||||
H_GUEST_SET_STATE()
|
||||
-------------------
|
||||
|
||||
This is called to set L2 wide or vCPU specific L2 state. This info is
|
||||
passed via the Guest State Buffer (GSB), necessary details below:
|
||||
|
||||
This can set either L2 wide or vcpu specific information. Examples of
|
||||
L2 wide is the timebase offset or process scoped page table
|
||||
info. Examples of vCPU specific are GPRs or VSRs. A bit in the flags
|
||||
parameter specifies if this call is L2 wide or vCPU specific and the
|
||||
IDs in the GSB must match this.
|
||||
|
||||
The L1 provides a pointer to the GSB as a parameter to this call. Also
|
||||
provided is the L2 and vCPU IDs associated with the state to set.
|
||||
|
||||
The L1 writes all values in the GSB and the L0 only reads the GSB for
|
||||
this call::
|
||||
|
||||
H_GUEST_SET_STATE(uint64 flags,
|
||||
uint64 guestId,
|
||||
uint64 vcpuId,
|
||||
uint64 dataBuffer,
|
||||
uint64 dataBufferSizeInBytes);
|
||||
Parameters:
|
||||
Input:
|
||||
flags:
|
||||
Bit 0: getGuestWideState: Request state of the Guest instead
|
||||
of an individual VCPU.
|
||||
Bit 1: returnOwnershipOfVcpuState Return Guest VCPU state. See
|
||||
GET_STATE takeOwnershipOfVcpuState
|
||||
Bits 2-63: Reserved
|
||||
guestId: ID obtained from H_GUEST_CREATE
|
||||
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
|
||||
dataBuffer: A L1 real address of the GSB.
|
||||
If takeOwnershipOfVcpuState, size must be at least the size
|
||||
returned by ID=0x0001
|
||||
dataBufferSizeInBytes: Size of dataBuffer
|
||||
Output:
|
||||
R3: Return code
|
||||
R4: If R3 = H_Invalid_Element_Id: The array index of the bad
|
||||
element ID.
|
||||
If R3 = H_Invalid_Element_Size: The array index of the bad
|
||||
element size.
|
||||
If R3 = H_Invalid_Element_Value: The array index of the bad
|
||||
element value.
|
||||
|
||||
H_GUEST_RUN_VCPU()
|
||||
------------------
|
||||
|
||||
This is called to run an L2 vCPU. The L2 and vCPU IDs are passed in as
|
||||
parameters. The vCPU runs with the state set previously using
|
||||
H_GUEST_SET_STATE(). When the L2 exits, the L1 will resume from this
|
||||
hcall.
|
||||
|
||||
This hcall also has associated input and output GSBs. Unlike
|
||||
H_GUEST_{S,G}ET_STATE(), these GSB pointers are not passed in as
|
||||
parameters to the hcall (This was done in the interest of
|
||||
performance). The locations of these GSBs must be preregistered using
|
||||
the H_GUEST_SET_STATE() call with ID 0x0c00 and 0x0c01 (see table
|
||||
below).
|
||||
|
||||
The input GSB may contain only VCPU specific elements to be set. This
|
||||
GSB may also contain zero elements (ie 0 in the first 4 bytes of the
|
||||
GSB) if nothing needs to be set.
|
||||
|
||||
On exit from the hcall, the output buffer is filled with elements
|
||||
determined by the L0. The reason for the exit is contained in GPR4 (ie
|
||||
NIP is put in GPR4). The elements returned depend on the exit
|
||||
type. For example, if the exit reason is the L2 doing a hcall (GPR4 =
|
||||
0xc00), then GPR3-12 are provided in the output GSB as this is the
|
||||
state likely needed to service the hcall. If additional state is
|
||||
needed, H_GUEST_GET_STATE() may be called by the L1.
|
||||
|
||||
To synthesize interrupts in the L2, when calling H_GUEST_RUN_VCPU()
|
||||
the L1 may set a flag (as a hcall parameter) and the L0 will
|
||||
synthesize the interrupt in the L2. Alternatively, the L1 may
|
||||
synthesize the interrupt itself using H_GUEST_SET_STATE() or the
|
||||
H_GUEST_RUN_VCPU() input GSB to set the state appropriately::
|
||||
|
||||
H_GUEST_RUN_VCPU(uint64 flags,
|
||||
uint64 guestId,
|
||||
uint64 vcpuId,
|
||||
uint64 dataBuffer,
|
||||
uint64 dataBufferSizeInBytes);
|
||||
Parameters:
|
||||
Input:
|
||||
flags:
|
||||
Bit 0: generateExternalInterrupt: Generate an external interrupt
|
||||
Bit 1: generatePrivilegedDoorbell: Generate a Privileged Doorbell
|
||||
Bit 2: sendToSystemReset”: Generate a System Reset Interrupt
|
||||
Bits 3-63: Reserved
|
||||
guestId: ID obtained from H_GUEST_CREATE
|
||||
vcpuId: ID of the vCPU pass to H_GUEST_CREATE_VCPU
|
||||
Output:
|
||||
R3: Return code
|
||||
R4: If R3 = H_Success: The reason L1 VCPU exited (ie. NIA)
|
||||
0x000: The VCPU stopped running for an unspecified reason. An
|
||||
example of this is the Hypervisor stopping a VCPU running
|
||||
due to an outstanding interrupt for the Host Partition.
|
||||
0x980: HDEC
|
||||
0xC00: HCALL
|
||||
0xE00: HDSI
|
||||
0xE20: HISI
|
||||
0xE40: HEA
|
||||
0xF80: HV Fac Unavail
|
||||
If R3 = H_Invalid_Element_Id, H_Invalid_Element_Size, or
|
||||
H_Invalid_Element_Value: R4 is offset of the invalid element
|
||||
in the input buffer.
|
||||
|
||||
H_GUEST_DELETE()
|
||||
----------------
|
||||
|
||||
This is called to delete an L2. All associated vCPUs are also
|
||||
deleted. No specific vCPU delete call is provided.
|
||||
|
||||
A flag may be provided to delete all guests. This is used to reset the
|
||||
L0 in the case of kdump/kexec::
|
||||
|
||||
H_GUEST_DELETE(uint64 flags,
|
||||
uint64 guestId)
|
||||
Parameters:
|
||||
Input:
|
||||
flags:
|
||||
Bit 0: deleteAllGuests: deletes all guests
|
||||
Bits 1-63: Reserved
|
||||
guestId: ID obtained from H_GUEST_CREATE
|
||||
Output:
|
||||
R3: Return code
|
||||
|
||||
Guest State Buffer
|
||||
==================
|
||||
|
||||
The Guest State Buffer (GSB) is the main method of communicating state
|
||||
about the L2 between the L1 and L0 via H_GUEST_{G,S}ET() and
|
||||
H_GUEST_VCPU_RUN() calls.
|
||||
|
||||
State may be associated with a whole L2 (eg timebase offset) or a
|
||||
specific L2 vCPU (eg. GPR state). Only L2 VCPU state maybe be set by
|
||||
H_GUEST_VCPU_RUN().
|
||||
|
||||
All data in the GSB is big endian (as is standard in PAPR)
|
||||
|
||||
The Guest state buffer has a header which gives the number of
|
||||
elements, followed by the GSB elements themselves.
|
||||
|
||||
GSB header:
|
||||
|
||||
+----------+----------+-------------------------------------------+
|
||||
| Offset | Size | Purpose |
|
||||
| Bytes | Bytes | |
|
||||
+==========+==========+===========================================+
|
||||
| 0 | 4 | Number of elements |
|
||||
+----------+----------+-------------------------------------------+
|
||||
| 4 | | Guest state buffer elements |
|
||||
+----------+----------+-------------------------------------------+
|
||||
|
||||
GSB element:
|
||||
|
||||
+----------+----------+-------------------------------------------+
|
||||
| Offset | Size | Purpose |
|
||||
| Bytes | Bytes | |
|
||||
+==========+==========+===========================================+
|
||||
| 0 | 2 | ID |
|
||||
+----------+----------+-------------------------------------------+
|
||||
| 2 | 2 | Size of Value |
|
||||
+----------+----------+-------------------------------------------+
|
||||
| 4 | As above | Value |
|
||||
+----------+----------+-------------------------------------------+
|
||||
|
||||
The ID in the GSB element specifies what is to be set. This includes
|
||||
archtected state like GPRs, VSRs, SPRs, plus also some meta data about
|
||||
the partition like the timebase offset and partition scoped page
|
||||
table information.
|
||||
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| ID | Size | RW | Thread | Details |
|
||||
| | Bytes | | Guest | |
|
||||
| | | | Scope | |
|
||||
+========+=======+====+========+==================================+
|
||||
| 0x0000 | | RW | TG | NOP element |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0001 | 0x08 | R | G | Size of L0 vCPU state. See: |
|
||||
| | | | | H_GUEST_GET_STATE: |
|
||||
| | | | | flags = takeOwnershipOfVcpuState |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0002 | 0x08 | R | G | Size Run vCPU out buffer |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0003 | 0x04 | RW | G | Logical PVR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0004 | 0x08 | RW | G | TB Offset (L1 relative) |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0005 | 0x18 | RW | G |Partition scoped page tbl info: |
|
||||
| | | | | |
|
||||
| | | | |- 0x00 Addr part scope table |
|
||||
| | | | |- 0x08 Num addr bits |
|
||||
| | | | |- 0x10 Size root dir |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0006 | 0x10 | RW | G |Process Table Information: |
|
||||
| | | | | |
|
||||
| | | | |- 0x0 Addr proc scope table |
|
||||
| | | | |- 0x8 Table size. |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0007-| | | | Reserved |
|
||||
| 0x0BFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0C00 | 0x10 | RW | T |Run vCPU Input Buffer: |
|
||||
| | | | | |
|
||||
| | | | |- 0x0 Addr of buffer |
|
||||
| | | | |- 0x8 Buffer Size. |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0C01 | 0x10 | RW | T |Run vCPU Output Buffer: |
|
||||
| | | | | |
|
||||
| | | | |- 0x0 Addr of buffer |
|
||||
| | | | |- 0x8 Buffer Size. |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0C02 | 0x08 | RW | T | vCPU VPA Address |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x0C03-| | | | Reserved |
|
||||
| 0x0FFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1000-| 0x08 | RW | T | GPR 0-31 |
|
||||
| 0x101F | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1020 | 0x08 | T | T | HDEC expiry TB |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1021 | 0x08 | RW | T | NIA |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1022 | 0x08 | RW | T | MSR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1023 | 0x08 | RW | T | LR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1024 | 0x08 | RW | T | XER |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1025 | 0x08 | RW | T | CTR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1026 | 0x08 | RW | T | CFAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1027 | 0x08 | RW | T | SRR0 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1028 | 0x08 | RW | T | SRR1 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1029 | 0x08 | RW | T | DAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102A | 0x08 | RW | T | DEC expiry TB |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102B | 0x08 | RW | T | VTB |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102C | 0x08 | RW | T | LPCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102D | 0x08 | RW | T | HFSCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102E | 0x08 | RW | T | FSCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x102F | 0x08 | RW | T | FPSCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1030 | 0x08 | RW | T | DAWR0 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1031 | 0x08 | RW | T | DAWR1 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1032 | 0x08 | RW | T | CIABR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1033 | 0x08 | RW | T | PURR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1034 | 0x08 | RW | T | SPURR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1035 | 0x08 | RW | T | IC |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1036-| 0x08 | RW | T | SPRG 0-3 |
|
||||
| 0x1039 | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x103A | 0x08 | W | T | PPR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x103B | 0x08 | RW | T | MMCR 0-3 |
|
||||
| 0x103E | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x103F | 0x08 | RW | T | MMCRA |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1040 | 0x08 | RW | T | SIER |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1041 | 0x08 | RW | T | SIER 2 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1042 | 0x08 | RW | T | SIER 3 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1043 | 0x08 | RW | T | BESCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1044 | 0x08 | RW | T | EBBHR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1045 | 0x08 | RW | T | EBBRR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1046 | 0x08 | RW | T | AMR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1047 | 0x08 | RW | T | IAMR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1048 | 0x08 | RW | T | AMOR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1049 | 0x08 | RW | T | UAMOR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104A | 0x08 | RW | T | SDAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104B | 0x08 | RW | T | SIAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104C | 0x08 | RW | T | DSCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104D | 0x08 | RW | T | TAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104E | 0x08 | RW | T | DEXCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x104F | 0x08 | RW | T | HDEXCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1050 | 0x08 | RW | T | HASHKEYR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1051 | 0x08 | RW | T | HASHPKEYR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1052 | 0x08 | RW | T | CTRL |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x1053-| | | | Reserved |
|
||||
| 0x1FFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2000 | 0x04 | RW | T | CR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2001 | 0x04 | RW | T | PIDR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2002 | 0x04 | RW | T | DSISR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2003 | 0x04 | RW | T | VSCR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2004 | 0x04 | RW | T | VRSAVE |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2005 | 0x04 | RW | T | DAWRX0 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2006 | 0x04 | RW | T | DAWRX1 |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x2007-| 0x04 | RW | T | PMC 1-6 |
|
||||
| 0x200c | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x200D | 0x04 | RW | T | WORT |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x200E | 0x04 | RW | T | PSPB |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x200F-| | | | Reserved |
|
||||
| 0x2FFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x3000-| 0x10 | RW | T | VSR 0-63 |
|
||||
| 0x303F | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0x3040-| | | | Reserved |
|
||||
| 0xEFFF | | | | |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0xF000 | 0x08 | R | T | HDAR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0xF001 | 0x04 | R | T | HDSISR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0xF002 | 0x04 | R | T | HEIR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
| 0xF003 | 0x08 | R | T | ASDR |
|
||||
+--------+-------+----+--------+----------------------------------+
|
||||
|
||||
|
||||
Miscellaneous info
|
||||
==================
|
||||
|
||||
State not in ptregs/hvregs
|
||||
--------------------------
|
||||
|
||||
In the v1 API, some state is not in the ptregs/hvstate. This includes
|
||||
the vector register and some SPRs. For the L1 to set this state for
|
||||
the L2, the L1 loads up these hardware registers before the
|
||||
h_enter_nested() call and the L0 ensures they end up as the L2 state
|
||||
(by not touching them).
|
||||
|
||||
The v2 API removes this and explicitly sets this state via the GSB.
|
||||
|
||||
L1 Implementation details: Caching state
|
||||
----------------------------------------
|
||||
|
||||
In the v1 API, all state is sent from the L1 to the L0 and vice versa
|
||||
on every h_enter_nested() hcall. If the L0 is not currently running
|
||||
any L2s, the L0 has no state information about them. The only
|
||||
exception to this is the location of the partition table, registered
|
||||
via h_set_partition_table().
|
||||
|
||||
The v2 API changes this so that the L0 retains the L2 state even when
|
||||
it's vCPUs are no longer running. This means that the L1 only needs to
|
||||
communicate with the L0 about L2 state when it needs to modify the L2
|
||||
state, or when it's value is out of date. This provides an opportunity
|
||||
for performance optimisation.
|
||||
|
||||
When a vCPU exits from a H_GUEST_RUN_VCPU() call, the L1 internally
|
||||
marks all L2 state as invalid. This means that if the L1 wants to know
|
||||
the L2 state (say via a kvm_get_one_reg() call), it needs call
|
||||
H_GUEST_GET_STATE() to get that state. Once it's read, it's marked as
|
||||
valid in L1 until the L2 is run again.
|
||||
|
||||
Also, when an L1 modifies L2 vcpu state, it doesn't need to write it
|
||||
to the L0 until that L2 vcpu runs again. Hence when the L1 updates
|
||||
state (say via a kvm_set_one_reg() call), it writes to an internal L1
|
||||
copy and only flushes this copy to the L0 when the L2 runs again via
|
||||
the H_GUEST_VCPU_RUN() input buffer.
|
||||
|
||||
This lazy updating of state by the L1 avoids unnecessary
|
||||
H_GUEST_{G|S}ET_STATE() calls.
|
@ -77,6 +77,9 @@ The following keys are defined:
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZBS`: The Zbs extension is supported, as defined
|
||||
in version 1.0 of the Bit-Manipulation ISA extensions.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_EXT_ZICBOZ`: The Zicboz extension is supported, as
|
||||
ratified in commit 3dd606f ("Create cmobase-v1.0.pdf") of riscv-CMOs.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_CPUPERF_0`: A bitmask that contains performance
|
||||
information about the selected set of processors.
|
||||
|
||||
@ -96,3 +99,6 @@ The following keys are defined:
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_MISALIGNED_UNSUPPORTED`: Misaligned accesses are
|
||||
not supported at all and will generate a misaligned address fault.
|
||||
|
||||
* :c:macro:`RISCV_HWPROBE_KEY_ZICBOZ_BLOCK_SIZE`: An unsigned int which
|
||||
represents the size of the Zicboz block in bytes.
|
||||
|
@ -42,6 +42,26 @@ An example string following the order is::
|
||||
|
||||
rv64imadc_zifoo_zigoo_zafoo_sbar_scar_zxmbaz_xqux_xrux
|
||||
|
||||
"isa" and "hart isa" lines in /proc/cpuinfo
|
||||
-------------------------------------------
|
||||
|
||||
The "isa" line in /proc/cpuinfo describes the lowest common denominator of
|
||||
RISC-V ISA extensions recognized by the kernel and implemented on all harts. The
|
||||
"hart isa" line, in contrast, describes the set of extensions recognized by the
|
||||
kernel on the particular hart being described, even if those extensions may not
|
||||
be present on all harts in the system.
|
||||
|
||||
In both lines, the presence of an extension guarantees only that the hardware
|
||||
has the described capability. Additional kernel support or policy changes may be
|
||||
required before an extension's capability is fully usable by userspace programs.
|
||||
Similarly, for S-mode extensions, presence in one of these lines does not
|
||||
guarantee that the kernel is taking advantage of the extension, or that the
|
||||
feature will be visible in guest VMs managed by this kernel.
|
||||
|
||||
Inversely, the absence of an extension in these lines does not necessarily mean
|
||||
the hardware does not support that feature. The running kernel may not recognize
|
||||
the extension, or may have deliberately removed it from the listing.
|
||||
|
||||
Misaligned accesses
|
||||
-------------------
|
||||
|
||||
|
@ -43,12 +43,6 @@ mach-x3proto
|
||||
Busses
|
||||
======
|
||||
|
||||
SuperHyway
|
||||
----------
|
||||
|
||||
.. kernel-doc:: drivers/sh/superhyway/superhyway.c
|
||||
:export:
|
||||
|
||||
Maple
|
||||
-----
|
||||
|
||||
|
@ -77,7 +77,7 @@ Protocol 2.14 BURNT BY INCORRECT COMMIT
|
||||
Protocol 2.15 (Kernel 5.5) Added the kernel_info and kernel_info.setup_type_max.
|
||||
============= ============================================================
|
||||
|
||||
.. note::
|
||||
.. note::
|
||||
The protocol version number should be changed only if the setup header
|
||||
is changed. There is no need to update the version number if boot_params
|
||||
or kernel_info are changed. Additionally, it is recommended to use
|
||||
|
@ -37,16 +37,14 @@ prototype in a header for the wrapper kfunc.
|
||||
An example is given below::
|
||||
|
||||
/* Disables missing prototype warnings */
|
||||
__diag_push();
|
||||
__diag_ignore_all("-Wmissing-prototypes",
|
||||
"Global kfuncs as their definitions will be in BTF");
|
||||
__bpf_kfunc_start_defs();
|
||||
|
||||
__bpf_kfunc struct task_struct *bpf_find_get_task_by_vpid(pid_t nr)
|
||||
{
|
||||
return find_get_task_by_vpid(nr);
|
||||
}
|
||||
|
||||
__diag_pop();
|
||||
__bpf_kfunc_end_defs();
|
||||
|
||||
A wrapper kfunc is often needed when we need to annotate parameters of the
|
||||
kfunc. Otherwise one may directly make the kfunc visible to the BPF program by
|
||||
|
@ -175,7 +175,7 @@ will return the previous entry which occurs before the entry at index.
|
||||
mas_find() will find the first entry which exists at or above index on
|
||||
the first call, and the next entry from every subsequent calls.
|
||||
|
||||
mas_find_rev() will find the fist entry which exists at or below the last on
|
||||
mas_find_rev() will find the first entry which exists at or below the last on
|
||||
the first call, and the previous entry from every subsequent calls.
|
||||
|
||||
If the user needs to yield the lock during an operation, then the maple state
|
||||
|
@ -235,6 +235,4 @@ Specifics Of Asynchronous HASH Transformation
|
||||
|
||||
Some of the drivers will want to use the Generic ScatterWalk in case the
|
||||
implementation needs to be fed separate chunks of the scatterlist which
|
||||
contains the input data. The buffer containing the resulting hash will
|
||||
always be properly aligned to .cra_alignmask so there is no need to
|
||||
worry about this.
|
||||
contains the input data.
|
||||
|
@ -1,5 +1,8 @@
|
||||
The Kernel Address Sanitizer (KASAN)
|
||||
====================================
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. Copyright (C) 2023, Google LLC.
|
||||
|
||||
Kernel Address Sanitizer (KASAN)
|
||||
================================
|
||||
|
||||
Overview
|
||||
--------
|
||||
|
@ -1,8 +1,8 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. Copyright (C) 2019, Google LLC.
|
||||
|
||||
The Kernel Concurrency Sanitizer (KCSAN)
|
||||
========================================
|
||||
Kernel Concurrency Sanitizer (KCSAN)
|
||||
====================================
|
||||
|
||||
The Kernel Concurrency Sanitizer (KCSAN) is a dynamic race detector, which
|
||||
relies on compile-time instrumentation, and uses a watchpoint-based sampling
|
||||
|
@ -1,9 +1,9 @@
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
.. Copyright (C) 2022, Google LLC.
|
||||
|
||||
===================================
|
||||
The Kernel Memory Sanitizer (KMSAN)
|
||||
===================================
|
||||
===============================
|
||||
Kernel Memory Sanitizer (KMSAN)
|
||||
===============================
|
||||
|
||||
KMSAN is a dynamic error detector aimed at finding uses of uninitialized
|
||||
values. It is based on compiler instrumentation, and is quite similar to the
|
||||
|
@ -1,5 +1,7 @@
|
||||
The Undefined Behavior Sanitizer - UBSAN
|
||||
========================================
|
||||
.. SPDX-License-Identifier: GPL-2.0
|
||||
|
||||
Undefined Behavior Sanitizer - UBSAN
|
||||
====================================
|
||||
|
||||
UBSAN is a runtime undefined behaviour checker.
|
||||
|
||||
|
@ -40,45 +40,6 @@ properties:
|
||||
items:
|
||||
- const: arm,integrator-sp
|
||||
|
||||
core-module@10000000:
|
||||
type: object
|
||||
description: the root node in the Integrator platforms must contain
|
||||
a core module child node. They are always at physical address
|
||||
0x10000000 in all the Integrator variants.
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: arm,core-module-integrator
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
"^syscon@[0-9a-f]+$":
|
||||
description: All Integrator boards must provide a system controller as a
|
||||
node in the root of the device tree.
|
||||
type: object
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- arm,integrator-ap-syscon
|
||||
- arm,integrator-cp-syscon
|
||||
- arm,integrator-sp-syscon
|
||||
- const: syscon
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- core-module@10000000
|
||||
|
@ -75,43 +75,6 @@ properties:
|
||||
type: object
|
||||
description: All RealView boards must provide a syscon system controller
|
||||
node inside the soc node.
|
||||
properties:
|
||||
compatible:
|
||||
oneOf:
|
||||
- items:
|
||||
- const: arm,realview-eb11mp-revb-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-eb11mp-revc-syscon
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-eb-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pb1176-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pb11mp-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pba8-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
- items:
|
||||
- const: arm,realview-pbx-syscon
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
@ -14,6 +14,14 @@ description: |+
|
||||
with various pluggable interface boards, in essence the Versatile PB version
|
||||
is a superset of the Versatile AB version.
|
||||
|
||||
The root node in the Versatile platforms must contain a core module child
|
||||
node. They are always at physical address 0x10000000 in all the Versatile
|
||||
variants.
|
||||
|
||||
When fitted with the IB2 Interface Board, the Versatile AB will present an
|
||||
optional system controller node which controls the extra peripherals on the
|
||||
interface board.
|
||||
|
||||
properties:
|
||||
$nodename:
|
||||
const: '/'
|
||||
@ -32,38 +40,6 @@ properties:
|
||||
items:
|
||||
- const: arm,versatile-pb
|
||||
|
||||
core-module@10000000:
|
||||
type: object
|
||||
description: the root node in the Versatile platforms must contain
|
||||
a core module child node. They are always at physical address
|
||||
0x10000000 in all the Versatile variants.
|
||||
properties:
|
||||
compatible:
|
||||
items:
|
||||
- const: arm,core-module-versatile
|
||||
- const: syscon
|
||||
- const: simple-mfd
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
patternProperties:
|
||||
"^syscon@[0-9a-f]+$":
|
||||
type: object
|
||||
description: When fitted with the IB2 Interface Board, the Versatile
|
||||
AB will present an optional system controller node which controls the
|
||||
extra peripherals on the interface board.
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: arm,versatile-ib2-syscon
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- core-module@10000000
|
||||
|
@ -4,7 +4,7 @@
|
||||
$id: http://devicetree.org/schemas/crypto/fsl-imx-sahara.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Freescale SAHARA Cryptographic Accelerator included in some i.MX chips
|
||||
title: Freescale SAHARA Cryptographic Accelerator
|
||||
|
||||
maintainers:
|
||||
- Steffen Trumtrar <s.trumtrar@pengutronix.de>
|
||||
@ -19,19 +19,56 @@ properties:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
items:
|
||||
- description: SAHARA Interrupt for Host 0
|
||||
- description: SAHARA Interrupt for Host 1
|
||||
minItems: 1
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Sahara IPG clock
|
||||
- description: Sahara AHB clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ipg
|
||||
- const: ahb
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx53-sahara
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/imx27-clock.h>
|
||||
|
||||
crypto@10025000 {
|
||||
compatible = "fsl,imx27-sahara";
|
||||
reg = < 0x10025000 0x800>;
|
||||
reg = <0x10025000 0x800>;
|
||||
interrupts = <75>;
|
||||
clocks = <&clks IMX27_CLK_SAHARA_IPG_GATE>,
|
||||
<&clks IMX27_CLK_SAHARA_AHB_GATE>;
|
||||
clock-names = "ipg", "ahb";
|
||||
};
|
||||
|
@ -13,6 +13,7 @@ properties:
|
||||
compatible:
|
||||
items:
|
||||
- enum:
|
||||
- qcom,sa8775p-inline-crypto-engine
|
||||
- qcom,sm8450-inline-crypto-engine
|
||||
- qcom,sm8550-inline-crypto-engine
|
||||
- const: qcom,inline-crypto-engine
|
||||
|
@ -11,9 +11,17 @@ maintainers:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,prng # 8916 etc.
|
||||
- qcom,prng-ee # 8996 and later using EE
|
||||
oneOf:
|
||||
- enum:
|
||||
- qcom,prng # 8916 etc.
|
||||
- qcom,prng-ee # 8996 and later using EE
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sa8775p-trng
|
||||
- qcom,sc7280-trng
|
||||
- qcom,sm8450-trng
|
||||
- qcom,sm8550-trng
|
||||
- const: qcom,trng
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -28,8 +36,18 @@ properties:
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: qcom,trng
|
||||
then:
|
||||
required:
|
||||
- clocks
|
||||
- clock-names
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
|
@ -9,6 +9,9 @@ title: Analog Devices ADV7533/35 HDMI Encoders
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/sound/dai-common.yaml#
|
||||
|
||||
description: |
|
||||
The ADV7533 and ADV7535 are HDMI audio and video transmitters
|
||||
compatible with HDMI 1.4 and DVI 1.0. They support color space
|
||||
@ -89,6 +92,9 @@ properties:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
enum: [ 1, 2, 3, 4 ]
|
||||
|
||||
"#sound-dai-cells":
|
||||
const: 0
|
||||
|
||||
ports:
|
||||
description:
|
||||
The ADV7533/35 has two video ports and one audio port.
|
||||
|
@ -51,7 +51,10 @@ properties:
|
||||
minItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
items:
|
||||
- description: LCDIF DMA interrupt
|
||||
- description: LCDIF Error interrupt
|
||||
minItems: 1
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
@ -131,6 +134,21 @@ allOf:
|
||||
then:
|
||||
required:
|
||||
- power-domains
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- fsl,imx23-lcdif
|
||||
then:
|
||||
properties:
|
||||
interrupts:
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
else:
|
||||
properties:
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
@ -10,7 +10,6 @@ maintainers:
|
||||
- Chun-Kuang Hu <chunkuang.hu@kernel.org>
|
||||
- Philipp Zabel <p.zabel@pengutronix.de>
|
||||
- Jitao Shi <jitao.shi@mediatek.com>
|
||||
- Xinlei Lee <xinlei.lee@mediatek.com>
|
||||
|
||||
description: |
|
||||
The MediaTek DSI function block is a sink of the display subsystem and can
|
||||
|
@ -42,6 +42,8 @@ properties:
|
||||
- lg,acx467akm-7
|
||||
# LG Corporation 7" WXGA TFT LCD panel
|
||||
- lg,ld070wx3-sl01
|
||||
# LG Corporation 5" HD TFT LCD panel
|
||||
- lg,lh500wx1-sd03
|
||||
# One Stop Displays OSD101T2587-53TS 10.1" 1920x1200 panel
|
||||
- osddisplays,osd101t2587-53ts
|
||||
# Panasonic 10" WUXGA TFT LCD panel
|
||||
|
@ -208,8 +208,6 @@ properties:
|
||||
- lemaker,bl035-rgb-002
|
||||
# LG 7" (800x480 pixels) TFT LCD panel
|
||||
- lg,lb070wv8
|
||||
# LG Corporation 5" HD TFT LCD panel
|
||||
- lg,lh500wx1-sd03
|
||||
# LG LP079QX1-SP0V 7.9" (1536x2048 pixels) TFT LCD panel
|
||||
- lg,lp079qx1-sp0v
|
||||
# LG 9.7" (2048x1536 pixels) TFT LCD panel
|
||||
|
@ -0,0 +1,130 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/display/renesas,shmobile-lcdc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Renesas SH-Mobile LCD Controller (LCDC)
|
||||
|
||||
maintainers:
|
||||
- Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com>
|
||||
- Geert Uytterhoeven <geert+renesas@glider.be>
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- renesas,r8a7740-lcdc # R-Mobile A1
|
||||
- renesas,sh73a0-lcdc # SH-Mobile AG5
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
description:
|
||||
Only the functional clock is mandatory.
|
||||
Some of the optional clocks are model-dependent (e.g. "video" (a.k.a.
|
||||
"vou" or "dv_clk") is available on R-Mobile A1 only).
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
items:
|
||||
- const: fck
|
||||
- enum: [ media, lclk, hdmi, video ]
|
||||
- enum: [ media, lclk, hdmi, video ]
|
||||
- enum: [ media, lclk, hdmi, video ]
|
||||
- enum: [ media, lclk, hdmi, video ]
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
ports:
|
||||
$ref: /schemas/graph.yaml#/properties/ports
|
||||
|
||||
properties:
|
||||
port@0:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: LCD port (R-Mobile A1 and SH-Mobile AG5)
|
||||
unevaluatedProperties: false
|
||||
|
||||
port@1:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: HDMI port (R-Mobile A1 LCDC1 and SH-Mobile AG5)
|
||||
unevaluatedProperties: false
|
||||
|
||||
port@2:
|
||||
$ref: /schemas/graph.yaml#/properties/port
|
||||
description: MIPI-DSI port (SH-Mobile AG5)
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- port@0
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- interrupts
|
||||
- clocks
|
||||
- clock-names
|
||||
- power-domains
|
||||
- ports
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: renesas,r8a7740-lcdc
|
||||
then:
|
||||
properties:
|
||||
ports:
|
||||
properties:
|
||||
port@2: false
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
const: renesas,sh73a0-lcdc
|
||||
then:
|
||||
properties:
|
||||
ports:
|
||||
required:
|
||||
- port@1
|
||||
- port@2
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/r8a7740-clock.h>
|
||||
#include <dt-bindings/interrupt-controller/arm-gic.h>
|
||||
|
||||
lcd-controller@fe940000 {
|
||||
compatible = "renesas,r8a7740-lcdc";
|
||||
reg = <0xfe940000 0x4000>;
|
||||
interrupts = <GIC_SPI 177 IRQ_TYPE_LEVEL_HIGH>;
|
||||
clocks = <&mstp1_clks R8A7740_CLK_LCDC0>,
|
||||
<&cpg_clocks R8A7740_CLK_M3>, <&lcdlclk0_clk>,
|
||||
<&vou_clk>;
|
||||
clock-names = "fck", "media", "lclk", "video";
|
||||
power-domains = <&pd_a4lc>;
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
|
||||
lcdc0_rgb: endpoint {
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
@ -11,10 +11,10 @@ maintainers:
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
- enum:
|
||||
- solomon,ssd1322
|
||||
- solomon,ssd1325
|
||||
- solomon,ssd1327
|
||||
enum:
|
||||
- solomon,ssd1322
|
||||
- solomon,ssd1325
|
||||
- solomon,ssd1327
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
@ -69,6 +69,8 @@ properties:
|
||||
dma-channel-mask:
|
||||
maxItems: 1
|
||||
|
||||
dma-coherent: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
@ -12,6 +12,7 @@ maintainers:
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/nvmem/nvmem.yaml
|
||||
- $ref: /schemas/nvmem/nvmem-deprecated-cells.yaml
|
||||
|
||||
select:
|
||||
properties:
|
||||
@ -67,10 +68,14 @@ properties:
|
||||
pattern: cs16$
|
||||
- items:
|
||||
pattern: c32$
|
||||
- items:
|
||||
pattern: c32d-wl$
|
||||
- items:
|
||||
pattern: cs32$
|
||||
- items:
|
||||
pattern: c64$
|
||||
- items:
|
||||
pattern: c64d-wl$
|
||||
- items:
|
||||
pattern: cs64$
|
||||
- items:
|
||||
|
@ -1,135 +0,0 @@
|
||||
Pinctrl-based I2C Bus DeMux
|
||||
|
||||
This binding describes an I2C bus demultiplexer that uses pin multiplexing to
|
||||
route the I2C signals, and represents the pin multiplexing configuration using
|
||||
the pinctrl device tree bindings. This may be used to select one I2C IP core at
|
||||
runtime which may have a better feature set for a given task than another I2C
|
||||
IP core on the SoC. The most simple example is to fall back to GPIO bitbanging
|
||||
if your current runtime configuration hits an errata of the internal IP core.
|
||||
|
||||
+-------------------------------+
|
||||
| SoC |
|
||||
| | +-----+ +-----+
|
||||
| +------------+ | | dev | | dev |
|
||||
| |I2C IP Core1|--\ | +-----+ +-----+
|
||||
| +------------+ \-------+ | | |
|
||||
| |Pinctrl|--|------+--------+
|
||||
| +------------+ +-------+ |
|
||||
| |I2C IP Core2|--/ |
|
||||
| +------------+ |
|
||||
| |
|
||||
+-------------------------------+
|
||||
|
||||
Required properties:
|
||||
- compatible: "i2c-demux-pinctrl"
|
||||
- i2c-parent: List of phandles of I2C masters available for selection. The first
|
||||
one will be used as default.
|
||||
- i2c-bus-name: The name of this bus. Also needed as pinctrl-name for the I2C
|
||||
parents.
|
||||
|
||||
Furthermore, I2C mux properties and child nodes. See i2c-mux.yaml in this
|
||||
directory.
|
||||
|
||||
Example:
|
||||
|
||||
Here is a snipplet for a bus to be demuxed. It contains various i2c clients for
|
||||
HDMI, so the bus is named "i2c-hdmi":
|
||||
|
||||
i2chdmi: i2c@8 {
|
||||
|
||||
compatible = "i2c-demux-pinctrl";
|
||||
i2c-parent = <&gpioi2c>, <&iic2>, <&i2c2>;
|
||||
i2c-bus-name = "i2c-hdmi";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ak4643: sound-codec@12 {
|
||||
compatible = "asahi-kasei,ak4643";
|
||||
|
||||
#sound-dai-cells = <0>;
|
||||
reg = <0x12>;
|
||||
};
|
||||
|
||||
composite-in@20 {
|
||||
compatible = "adi,adv7180";
|
||||
reg = <0x20>;
|
||||
remote = <&vin1>;
|
||||
|
||||
port {
|
||||
adv7180: endpoint {
|
||||
bus-width = <8>;
|
||||
remote-endpoint = <&vin1ep0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hdmi@39 {
|
||||
compatible = "adi,adv7511w";
|
||||
reg = <0x39>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
adi,input-depth = <8>;
|
||||
adi,input-colorspace = "rgb";
|
||||
adi,input-clock = "1x";
|
||||
adi,input-style = <1>;
|
||||
adi,input-justification = "evenly";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
adv7511_in: endpoint {
|
||||
remote-endpoint = <&du_out_lvds0>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
adv7511_out: endpoint {
|
||||
remote-endpoint = <&hdmi_con>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
And for clarification, here are the snipplets for the i2c-parents:
|
||||
|
||||
gpioi2c: i2c@9 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "i2c-gpio";
|
||||
gpios = <&gpio5 6 GPIO_ACTIVE_HIGH /* sda */
|
||||
&gpio5 5 GPIO_ACTIVE_HIGH /* scl */
|
||||
>;
|
||||
i2c-gpio,delay-us = <5>;
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
&i2c2 {
|
||||
pinctrl-0 = <&i2c2_pins>;
|
||||
pinctrl-names = "i2c-hdmi";
|
||||
|
||||
clock-frequency = <100000>;
|
||||
};
|
||||
|
||||
...
|
||||
|
||||
&iic2 {
|
||||
pinctrl-0 = <&iic2_pins>;
|
||||
pinctrl-names = "i2c-hdmi";
|
||||
|
||||
clock-frequency = <100000>;
|
||||
};
|
||||
|
||||
Please note:
|
||||
|
||||
- pinctrl properties for the parent I2C controllers need a pinctrl state
|
||||
with the same name as i2c-bus-name, not "default"!
|
||||
|
||||
- the i2c masters must have their status "disabled". This driver will
|
||||
enable them at runtime when needed.
|
172
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
Normal file
172
Documentation/devicetree/bindings/i2c/i2c-demux-pinctrl.yaml
Normal file
@ -0,0 +1,172 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/i2c/i2c-demux-pinctrl.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Pinctrl-based I2C Bus Demultiplexer
|
||||
|
||||
maintainers:
|
||||
- Wolfram Sang <wsa+renesas@sang-engineering.com>
|
||||
|
||||
description: |
|
||||
This binding describes an I2C bus demultiplexer that uses pin multiplexing to
|
||||
route the I2C signals, and represents the pin multiplexing configuration
|
||||
using the pinctrl device tree bindings. This may be used to select one I2C
|
||||
IP core at runtime which may have a better feature set for a given task than
|
||||
another I2C IP core on the SoC. The most simple example is to fall back to
|
||||
GPIO bitbanging if your current runtime configuration hits an errata of the
|
||||
internal IP core.
|
||||
|
||||
+-------------------------------+
|
||||
| SoC |
|
||||
| | +-----+ +-----+
|
||||
| +------------+ | | dev | | dev |
|
||||
| |I2C IP Core1|--\ | +-----+ +-----+
|
||||
| +------------+ \-------+ | | |
|
||||
| |Pinctrl|--|------+--------+
|
||||
| +------------+ +-------+ |
|
||||
| |I2C IP Core2|--/ |
|
||||
| +------------+ |
|
||||
| |
|
||||
+-------------------------------+
|
||||
|
||||
allOf:
|
||||
- $ref: i2c-mux.yaml
|
||||
- $ref: /schemas/i2c/i2c-controller.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: i2c-demux-pinctrl
|
||||
|
||||
i2c-parent:
|
||||
$ref: /schemas/types.yaml#/definitions/phandle-array
|
||||
description:
|
||||
List of phandles of I2C masters available for selection. The first one
|
||||
will be used as default.
|
||||
|
||||
i2c-bus-name:
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
description:
|
||||
The name of this bus. Also needed as pinctrl-name for the I2C parents.
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- i2c-parent
|
||||
- i2c-bus-name
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
|
||||
gpioi2c2: i2c-9 {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
compatible = "i2c-gpio";
|
||||
scl-gpios = <&gpio5 5 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
|
||||
sda-gpios = <&gpio5 6 (GPIO_ACTIVE_HIGH | GPIO_OPEN_DRAIN)>;
|
||||
i2c-gpio,delay-us = <5>;
|
||||
|
||||
// The I2C controller must have its status "disabled". The I2C bus
|
||||
// demultiplexer will enable it at runtime when needed.
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
iic2: i2c@e6520000 {
|
||||
reg = <0xe6520000 0x425>;
|
||||
pinctrl-0 = <&iic2_pins>;
|
||||
// The pinctrl property for the parent I2C controller needs a pinctrl
|
||||
// state with the same name as i2c-bus-name in the I2C bus demultiplexer
|
||||
// node, not "default"!
|
||||
pinctrl-names = "i2c-hdmi";
|
||||
|
||||
clock-frequency = <100000>;
|
||||
|
||||
// The I2C controller must have its status "disabled". The I2C bus
|
||||
// demultiplexer will enable it at runtime when needed.
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
i2c2: i2c@e6530000 {
|
||||
reg = <0 0xe6530000 0 0x40>;
|
||||
pinctrl-0 = <&i2c2_pins>;
|
||||
// The pinctrl property for the parent I2C controller needs a pinctrl
|
||||
// state with the same name as i2c-bus-name in the I2C bus demultiplexer
|
||||
// node, not "default"!
|
||||
pinctrl-names = "i2c-hdmi";
|
||||
|
||||
clock-frequency = <100000>;
|
||||
|
||||
// The I2C controller must have its status "disabled". The I2C bus
|
||||
// demultiplexer will enable it at runtime when needed.
|
||||
status = "disabled";
|
||||
};
|
||||
|
||||
// Example for a bus to be demuxed. It contains various I2C clients for
|
||||
// HDMI, so the bus is named "i2c-hdmi":
|
||||
i2chdmi: i2c-mux3 {
|
||||
compatible = "i2c-demux-pinctrl";
|
||||
i2c-parent = <&iic2>, <&i2c2>, <&gpioi2c2>;
|
||||
i2c-bus-name = "i2c-hdmi";
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
ak4643: codec@12 {
|
||||
compatible = "asahi-kasei,ak4643";
|
||||
#sound-dai-cells = <0>;
|
||||
reg = <0x12>;
|
||||
};
|
||||
|
||||
composite-in@20 {
|
||||
compatible = "adi,adv7180";
|
||||
reg = <0x20>;
|
||||
|
||||
port {
|
||||
adv7180: endpoint {
|
||||
bus-width = <8>;
|
||||
remote-endpoint = <&vin1ep0>;
|
||||
};
|
||||
};
|
||||
};
|
||||
|
||||
hdmi@39 {
|
||||
compatible = "adi,adv7511w";
|
||||
reg = <0x39>;
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <15 IRQ_TYPE_LEVEL_LOW>;
|
||||
clocks = <&cec_clock>;
|
||||
clock-names = "cec";
|
||||
|
||||
avdd-supply = <&fixedregulator1v8>;
|
||||
dvdd-supply = <&fixedregulator1v8>;
|
||||
pvdd-supply = <&fixedregulator1v8>;
|
||||
dvdd-3v-supply = <&fixedregulator3v3>;
|
||||
bgvdd-supply = <&fixedregulator1v8>;
|
||||
|
||||
adi,input-depth = <8>;
|
||||
adi,input-colorspace = "rgb";
|
||||
adi,input-clock = "1x";
|
||||
|
||||
ports {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
port@0 {
|
||||
reg = <0>;
|
||||
adv7511_in: endpoint {
|
||||
remote-endpoint = <&lvds0_out>;
|
||||
};
|
||||
};
|
||||
|
||||
port@1 {
|
||||
reg = <1>;
|
||||
adv7511_out: endpoint {
|
||||
remote-endpoint = <&hdmi_con_out>;
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
||||
};
|
@ -25,6 +25,7 @@ properties:
|
||||
|
||||
- items:
|
||||
- enum:
|
||||
- qcom,sc7280-cci
|
||||
- qcom,sdm845-cci
|
||||
- qcom,sm6350-cci
|
||||
- qcom,sm8250-cci
|
||||
@ -159,6 +160,7 @@ allOf:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sc7280-cci
|
||||
- qcom,sm8250-cci
|
||||
- qcom,sm8450-cci
|
||||
then:
|
||||
|
@ -125,12 +125,12 @@ patternProperties:
|
||||
minimum: 0
|
||||
maximum: 0x7f
|
||||
- description: |
|
||||
First half of the Provisional ID (following the PID
|
||||
First half of the Provisioned ID (following the PID
|
||||
definition provided by the I3C specification).
|
||||
|
||||
Contains the manufacturer ID left-shifted by 1.
|
||||
- description: |
|
||||
Second half of the Provisional ID (following the PID
|
||||
Second half of the Provisioned ID (following the PID
|
||||
definition provided by the I3C specification).
|
||||
|
||||
Contains the ORing of the part ID left-shifted by 16,
|
||||
|
@ -4,19 +4,23 @@
|
||||
$id: http://devicetree.org/schemas/iio/accel/kionix,kx022a.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ROHM/Kionix KX022A Accelerometer
|
||||
title: ROHM/Kionix KX022A, KX132-1211 and KX132ACR-LBZ Accelerometers
|
||||
|
||||
maintainers:
|
||||
- Matti Vaittinen <mazziesaccount@gmail.com>
|
||||
|
||||
description: |
|
||||
KX022A is a 3-axis accelerometer supporting +/- 2G, 4G, 8G and 16G ranges,
|
||||
output data-rates from 0.78Hz to 1600Hz and a hardware-fifo buffering.
|
||||
KX022A can be accessed either via I2C or SPI.
|
||||
KX022A, KX132ACR-LBZ and KX132-1211 are 3-axis accelerometers supporting
|
||||
+/- 2G, 4G, 8G and 16G ranges, variable output data-rates and a
|
||||
hardware-fifo buffering. These accelerometers can be accessed either
|
||||
via I2C or SPI.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: kionix,kx022a
|
||||
enum:
|
||||
- kionix,kx022a
|
||||
- kionix,kx132-1211
|
||||
- rohm,kx132acr-lbz
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
@ -4,21 +4,31 @@
|
||||
$id: http://devicetree.org/schemas/iio/adc/lltc,ltc2497.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Linear Technology / Analog Devices LTC2497 ADC
|
||||
title: Linear Technology / Analog Devices LTC2497 and LTC2309 ADC
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
- Liam Beguin <liambeguin@gmail.com>
|
||||
|
||||
description: |
|
||||
16bit ADC supporting up to 16 single ended or 8 differential inputs.
|
||||
I2C interface.
|
||||
LTC2309:
|
||||
low noise, low power, 8-channel, 12-bit successive approximation ADC with an
|
||||
I2C compatible serial interface.
|
||||
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2309fd.pdf
|
||||
|
||||
LTC2497:
|
||||
LTC2499:
|
||||
16bit ADC supporting up to 16 single ended or 8 differential inputs.
|
||||
I2C interface.
|
||||
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2497fb.pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/2499fe.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- lltc,ltc2309
|
||||
- lltc,ltc2497
|
||||
- lltc,ltc2499
|
||||
|
||||
|
205
Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
Normal file
205
Documentation/devicetree/bindings/iio/adc/microchip,mcp3564.yaml
Normal file
@ -0,0 +1,205 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/microchip,mcp3564.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Microchip MCP346X and MCP356X ADC Family
|
||||
|
||||
maintainers:
|
||||
- Marius Cristea <marius.cristea@microchip.com>
|
||||
|
||||
description: |
|
||||
Bindings for the Microchip family of 153.6 ksps, Low-Noise 16/24-Bit
|
||||
Delta-Sigma ADCs with an SPI interface. Datasheet can be found here:
|
||||
Datasheet for MCP3561, MCP3562, MCP3564 can be found here:
|
||||
https://ww1.microchip.com/downloads/aemDocuments/documents/MSLD/ProductDocuments/DataSheets/MCP3561-2-4-Family-Data-Sheet-DS20006181C.pdf
|
||||
Datasheet for MCP3561R, MCP3562R, MCP3564R can be found here:
|
||||
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3561_2_4R-Data-Sheet-DS200006391C.pdf
|
||||
Datasheet for MCP3461, MCP3462, MCP3464 can be found here:
|
||||
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4-Two-Four-Eight-Channel-153.6-ksps-Low-Noise-16-Bit-Delta-Sigma-ADC-Data-Sheet-20006180D.pdf
|
||||
Datasheet for MCP3461R, MCP3462R, MCP3464R can be found here:
|
||||
https://ww1.microchip.com/downloads/aemDocuments/documents/APID/ProductDocuments/DataSheets/MCP3461-2-4R-Family-Data-Sheet-DS20006404C.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- microchip,mcp3461
|
||||
- microchip,mcp3462
|
||||
- microchip,mcp3464
|
||||
- microchip,mcp3461r
|
||||
- microchip,mcp3462r
|
||||
- microchip,mcp3464r
|
||||
- microchip,mcp3561
|
||||
- microchip,mcp3562
|
||||
- microchip,mcp3564
|
||||
- microchip,mcp3561r
|
||||
- microchip,mcp3562r
|
||||
- microchip,mcp3564r
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
spi-max-frequency:
|
||||
maximum: 20000000
|
||||
|
||||
spi-cpha: true
|
||||
|
||||
spi-cpol: true
|
||||
|
||||
vdd-supply: true
|
||||
|
||||
avdd-supply: true
|
||||
|
||||
clocks:
|
||||
description:
|
||||
Phandle and clock identifier for external sampling clock.
|
||||
If not specified, the internal crystal oscillator will be used.
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
description: IRQ line of the ADC
|
||||
maxItems: 1
|
||||
|
||||
drive-open-drain:
|
||||
description:
|
||||
Whether to drive the IRQ signal as push-pull (default) or open-drain. Note
|
||||
that the device requires this pin to become "high", otherwise it will stop
|
||||
converting.
|
||||
type: boolean
|
||||
|
||||
vref-supply:
|
||||
description:
|
||||
Some devices have a specific reference voltage supplied on a different
|
||||
pin to the other supplies. Needed to be able to establish channel scaling
|
||||
unless there is also an internal reference available (e.g. mcp3564r). In
|
||||
case of "r" devices (e. g. mcp3564r), if it does not exists the internal
|
||||
reference will be used.
|
||||
|
||||
microchip,hw-device-address:
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
minimum: 0
|
||||
maximum: 3
|
||||
description:
|
||||
The address is set on a per-device basis by fuses in the factory,
|
||||
configured on request. If not requested, the fuses are set for 0x1.
|
||||
The device address is part of the device markings to avoid
|
||||
potential confusion. This address is coded on two bits, so four possible
|
||||
addresses are available when multiple devices are present on the same
|
||||
SPI bus with only one Chip Select line for all devices.
|
||||
Each device communication starts by a CS falling edge, followed by the
|
||||
clocking of the device address (BITS[7:6] - top two bits of COMMAND BYTE
|
||||
which is first one on the wire).
|
||||
|
||||
"#io-channel-cells":
|
||||
const: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
"#size-cells":
|
||||
const: 0
|
||||
|
||||
patternProperties:
|
||||
"^channel@([0-9]|([1-7][0-9]))$":
|
||||
$ref: adc.yaml
|
||||
type: object
|
||||
unevaluatedProperties: false
|
||||
description: Represents the external channels which are connected to the ADC.
|
||||
|
||||
properties:
|
||||
reg:
|
||||
description: The channel number in single-ended and differential mode.
|
||||
minimum: 0
|
||||
maximum: 79
|
||||
|
||||
required:
|
||||
- reg
|
||||
|
||||
dependencies:
|
||||
spi-cpol: [ spi-cpha ]
|
||||
spi-cpha: [ spi-cpol ]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- microchip,hw-device-address
|
||||
- spi-max-frequency
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
- # External vref, no internal reference
|
||||
if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- microchip,mcp3461
|
||||
- microchip,mcp3462
|
||||
- microchip,mcp3464
|
||||
- microchip,mcp3561
|
||||
- microchip,mcp3562
|
||||
- microchip,mcp3564
|
||||
then:
|
||||
required:
|
||||
- vref-supply
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
adc@0 {
|
||||
compatible = "microchip,mcp3564r";
|
||||
reg = <0>;
|
||||
vref-supply = <&vref_reg>;
|
||||
spi-cpha;
|
||||
spi-cpol;
|
||||
spi-max-frequency = <10000000>;
|
||||
microchip,hw-device-address = <1>;
|
||||
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
channel@0 {
|
||||
/* CH0 to AGND */
|
||||
reg = <0>;
|
||||
label = "CH0";
|
||||
};
|
||||
|
||||
channel@1 {
|
||||
/* CH1 to AGND */
|
||||
reg = <1>;
|
||||
label = "CH1";
|
||||
};
|
||||
|
||||
/* diff-channels */
|
||||
channel@11 {
|
||||
reg = <11>;
|
||||
|
||||
/* CN0, CN1 */
|
||||
diff-channels = <0 1>;
|
||||
label = "CH0_CH1";
|
||||
};
|
||||
|
||||
channel@22 {
|
||||
reg = <0x22>;
|
||||
|
||||
/* CN1, CN2 */
|
||||
diff-channels = <1 2>;
|
||||
label = "CH1_CH3";
|
||||
};
|
||||
|
||||
channel@23 {
|
||||
reg = <0x23>;
|
||||
|
||||
/* CN1, CN3 */
|
||||
diff-channels = <1 3>;
|
||||
label = "CH1_CH3";
|
||||
};
|
||||
};
|
||||
};
|
||||
...
|
@ -18,7 +18,13 @@ description: |
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- microchip,mcp3910
|
||||
- microchip,mcp3911
|
||||
- microchip,mcp3912
|
||||
- microchip,mcp3913
|
||||
- microchip,mcp3914
|
||||
- microchip,mcp3918
|
||||
- microchip,mcp3919
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
@ -23,6 +23,9 @@ properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
"#address-cells":
|
||||
const: 1
|
||||
|
||||
|
@ -0,0 +1,43 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/adc/ti,twl6030-gpadc.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: GPADC subsystem in the TWL6030 power module
|
||||
|
||||
maintainers:
|
||||
- Andreas Kemnade <andreas@kemnade.info>
|
||||
|
||||
description:
|
||||
The GPADC subsystem in the TWL603X consists of a 10-bit ADC
|
||||
combined with a 15-input analog multiplexer in the TWL6030 resp. a
|
||||
19-input analog muliplexer in the TWL6032.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- ti,twl6030-gpadc
|
||||
- ti,twl6032-gpadc
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
"#io-channel-cells":
|
||||
const: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- interrupts
|
||||
- "#io-channel-cells"
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
gpadc {
|
||||
compatible = "ti,twl6030-gpadc";
|
||||
interrupts = <3>;
|
||||
#io-channel-cells = <1>;
|
||||
};
|
||||
...
|
@ -4,20 +4,26 @@
|
||||
$id: http://devicetree.org/schemas/iio/amplifiers/adi,hmc425a.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: HMC425A 6-bit Digital Step Attenuator
|
||||
title: Analog Devices HMC425A and similar Digital Step Attenuators
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
|
||||
description: |
|
||||
Digital Step Attenuator IIO device with gpio interface.
|
||||
Digital Step Attenuator IIO devices with gpio interface.
|
||||
Offer various frequency and attenuation ranges.
|
||||
HMC425A 0.5 dB LSB GaAs MMIC 6-BIT DIGITAL POSITIVE CONTROL ATTENUATOR, 2.2 - 8.0 GHz
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc425A.pdf
|
||||
|
||||
HMC540S 1 dB LSB Silicon MMIC 4-Bit Digital Positive Control Attenuator, 0.1 - 8 GHz
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/hmc540s.pdf
|
||||
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- adi,hmc425a
|
||||
- adi,hmc540s
|
||||
|
||||
vcc-supply: true
|
||||
|
||||
|
@ -48,6 +48,11 @@ properties:
|
||||
|
||||
mount-matrix: true
|
||||
|
||||
invensense,level-shifter:
|
||||
type: boolean
|
||||
description: |
|
||||
From ancient platform data struct: false: VLogic, true: VDD
|
||||
|
||||
i2c-gate:
|
||||
$ref: /schemas/i2c/i2c-controller.yaml
|
||||
unevaluatedProperties: false
|
||||
|
@ -93,6 +93,9 @@ properties:
|
||||
wakeup-source:
|
||||
$ref: /schemas/types.yaml#/definitions/flag
|
||||
|
||||
mount-matrix:
|
||||
description: an optional 3x3 mounting rotation matrix
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
@ -0,0 +1,52 @@
|
||||
# SPDX-License-Identifier: GPL-2.0-only OR BSD-2-Clause
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/pressure/rohm,bm1390.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: ROHM BM1390 pressure sensor
|
||||
|
||||
maintainers:
|
||||
- Matti Vaittinen <mazziesaccount@gmail.com>
|
||||
|
||||
description:
|
||||
BM1390GLV-Z is a pressure sensor which performs internal temperature
|
||||
compensation for the MEMS. Pressure range is from 300 hPa to 1300 hPa
|
||||
and sample averaging and IIR filtering is built in. Temperature
|
||||
measurement is also supported.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: rohm,bm1390glv-z
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
interrupts:
|
||||
maxItems: 1
|
||||
|
||||
vdd-supply: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- vdd-supply
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/interrupt-controller/irq.h>
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
pressure-sensor@5d {
|
||||
compatible = "rohm,bm1390glv-z";
|
||||
reg = <0x5d>;
|
||||
|
||||
interrupt-parent = <&gpio1>;
|
||||
interrupts = <29 IRQ_TYPE_LEVEL_LOW>;
|
||||
|
||||
vdd-supply = <&vdd>;
|
||||
};
|
||||
};
|
177
Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml
Normal file
177
Documentation/devicetree/bindings/iio/resolver/adi,ad2s1210.yaml
Normal file
@ -0,0 +1,177 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/iio/resolver/adi,ad2s1210.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Analog Devices AD2S1210 Resolver-to-Digital Converter
|
||||
|
||||
maintainers:
|
||||
- Michael Hennerich <michael.hennerich@analog.com>
|
||||
|
||||
description: |
|
||||
The AD2S1210 is a complete 10-bit to 16-bit resolution tracking
|
||||
resolver-to-digital converter, integrating an on-board programmable
|
||||
sinusoidal oscillator that provides sine wave excitation for
|
||||
resolvers.
|
||||
|
||||
The AD2S1210 allows the user to read the angular position or the
|
||||
angular velocity data directly from the parallel outputs or through
|
||||
the serial interface.
|
||||
|
||||
The mode of operation of the communication channel (parallel or serial) is
|
||||
selected by the A0 and A1 input pins. In normal mode, data is latched by
|
||||
toggling the SAMPLE line and can then be read directly. In configuration mode,
|
||||
data is read or written using a register access scheme (address byte with
|
||||
read/write flag and data byte).
|
||||
|
||||
A1 A0 Result
|
||||
0 0 Normal mode - position output
|
||||
0 1 Normal mode - velocity output
|
||||
1 0 Reserved
|
||||
1 1 Configuration mode
|
||||
|
||||
In normal mode, the resolution of the digital output is selected using
|
||||
the RES0 and RES1 input pins. In configuration mode, the resolution is
|
||||
selected by setting the RES0 and RES1 bits in the control register.
|
||||
|
||||
RES1 RES0 Resolution (Bits)
|
||||
0 0 10
|
||||
0 1 12
|
||||
1 0 14
|
||||
1 1 16
|
||||
|
||||
Note on SPI connections: The CS line on the AD2S1210 should hard-wired to
|
||||
logic low and the WR/FSYNC line on the AD2S1210 should be connected to the
|
||||
SPI CSn output of the SPI controller.
|
||||
|
||||
Datasheet:
|
||||
https://www.analog.com/media/en/technical-documentation/data-sheets/ad2s1210.pdf
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: adi,ad2s1210
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
spi-max-frequency:
|
||||
maximum: 25000000
|
||||
|
||||
spi-cpha: true
|
||||
|
||||
avdd-supply:
|
||||
description:
|
||||
A 4.75 to 5.25 V regulator that powers the Analog Supply Voltage (AVDD)
|
||||
pin.
|
||||
|
||||
dvdd-supply:
|
||||
description:
|
||||
A 4.75 to 5.25 V regulator that powers the Digital Supply Voltage (DVDD)
|
||||
pin.
|
||||
|
||||
vdrive-supply:
|
||||
description:
|
||||
A 2.3 to 5.25 V regulator that powers the Logic Power Supply Input
|
||||
(VDrive) pin.
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
description: External oscillator clock (CLKIN).
|
||||
|
||||
reset-gpios:
|
||||
description:
|
||||
GPIO connected to the /RESET pin. As the line needs to be low for the
|
||||
reset to be active, it should be configured as GPIO_ACTIVE_LOW.
|
||||
maxItems: 1
|
||||
|
||||
sample-gpios:
|
||||
description:
|
||||
GPIO connected to the /SAMPLE pin. As the line needs to be low to trigger
|
||||
a sample, it should be configured as GPIO_ACTIVE_LOW.
|
||||
maxItems: 1
|
||||
|
||||
mode-gpios:
|
||||
description:
|
||||
GPIO lines connected to the A0 and A1 pins. These pins select the data
|
||||
transfer mode.
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
resolution-gpios:
|
||||
description:
|
||||
GPIO lines connected to the RES0 and RES1 pins. These pins select the
|
||||
resolution of the digital output. If omitted, it is assumed that the
|
||||
RES0 and RES1 pins are hard-wired to match the assigned-resolution-bits
|
||||
property.
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
fault-gpios:
|
||||
description:
|
||||
GPIO lines connected to the LOT and DOS pins. These pins combined indicate
|
||||
the type of fault present, if any. As these pins a pulled low to indicate
|
||||
a fault condition, they should be configured as GPIO_ACTIVE_LOW.
|
||||
minItems: 2
|
||||
maxItems: 2
|
||||
|
||||
adi,fixed-mode:
|
||||
description:
|
||||
This is used to indicate the selected mode if A0 and A1 are hard-wired
|
||||
instead of connected to GPIOS (i.e. mode-gpios is omitted).
|
||||
$ref: /schemas/types.yaml#/definitions/string
|
||||
enum: [config, velocity, position]
|
||||
|
||||
assigned-resolution-bits:
|
||||
description:
|
||||
Resolution of the digital output required by the application. This
|
||||
determines the precision of the angle and/or the maximum speed that can
|
||||
be measured. If resolution-gpios is omitted, it is assumed that RES0 and
|
||||
RES1 are hard-wired to match this value.
|
||||
enum: [10, 12, 14, 16]
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- spi-cpha
|
||||
- avdd-supply
|
||||
- dvdd-supply
|
||||
- vdrive-supply
|
||||
- clocks
|
||||
- sample-gpios
|
||||
- assigned-resolution-bits
|
||||
|
||||
oneOf:
|
||||
- required:
|
||||
- mode-gpios
|
||||
- required:
|
||||
- adi,fixed-mode
|
||||
|
||||
allOf:
|
||||
- $ref: /schemas/spi/spi-peripheral-props.yaml#
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/gpio/gpio.h>
|
||||
|
||||
spi {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
resolver@0 {
|
||||
compatible = "adi,ad2s1210";
|
||||
reg = <0>;
|
||||
spi-max-frequency = <20000000>;
|
||||
spi-cpha;
|
||||
avdd-supply = <&avdd_regulator>;
|
||||
dvdd-supply = <&dvdd_regulator>;
|
||||
vdrive-supply = <&vdrive_regulator>;
|
||||
clocks = <&ext_osc>;
|
||||
sample-gpios = <&gpio0 90 GPIO_ACTIVE_LOW>;
|
||||
mode-gpios = <&gpio0 86 0>, <&gpio0 87 0>;
|
||||
resolution-gpios = <&gpio0 88 0>, <&gpio0 89 0>;
|
||||
assigned-resolution-bits = <16>;
|
||||
};
|
||||
};
|
@ -24,6 +24,8 @@ properties:
|
||||
linux,keycodes:
|
||||
maxItems: 1
|
||||
|
||||
wakeup-source: true
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- linux,keycodes
|
||||
|
@ -34,6 +34,9 @@ properties:
|
||||
vdd-supply:
|
||||
description: Regulator for voltage.
|
||||
|
||||
vddio-supply:
|
||||
description: Optional Regulator for I/O voltage.
|
||||
|
||||
reset-gpios:
|
||||
maxItems: 1
|
||||
|
||||
|
@ -1,7 +1,7 @@
|
||||
Texas Instruments TWL family (twl4030) pwrbutton module
|
||||
|
||||
This module is part of the TWL4030. For more details about the whole
|
||||
chip see Documentation/devicetree/bindings/mfd/twl-family.txt.
|
||||
chip see Documentation/devicetree/bindings/mfd/ti,twl.yaml.
|
||||
|
||||
This module provides a simple power button event via an Interrupt.
|
||||
|
||||
|
@ -0,0 +1,74 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interconnect/qcom,msm8939.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm MSM8939 Network-On-Chip interconnect
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Qualcomm MSM8939 interconnect providers support adjusting the
|
||||
bandwidth requirements between the various NoC fabrics.
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,msm8939-bimc
|
||||
- qcom,msm8939-pcnoc
|
||||
- qcom,msm8939-snoc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
patternProperties:
|
||||
'^interconnect-[a-z0-9\-]+$':
|
||||
type: object
|
||||
$ref: qcom,rpm-common.yaml#
|
||||
description:
|
||||
The interconnect providers do not have a separate QoS register space,
|
||||
but share parent's space.
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8939-snoc-mm
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
|
||||
snoc: interconnect@580000 {
|
||||
compatible = "qcom,msm8939-snoc";
|
||||
reg = <0x00580000 0x14000>;
|
||||
#interconnect-cells = <1>;
|
||||
};
|
||||
|
||||
bimc: interconnect@400000 {
|
||||
compatible = "qcom,msm8939-bimc";
|
||||
reg = <0x00400000 0x62000>;
|
||||
#interconnect-cells = <1>;
|
||||
|
||||
snoc_mm: interconnect-snoc {
|
||||
compatible = "qcom,msm8939-snoc-mm";
|
||||
#interconnect-cells = <1>;
|
||||
};
|
||||
};
|
126
Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml
Normal file
126
Documentation/devicetree/bindings/interconnect/qcom,msm8996.yaml
Normal file
@ -0,0 +1,126 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interconnect/qcom,msm8996.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm MSM8996 Network-On-Chip interconnect
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Qualcomm MSM8996 interconnect providers support adjusting the
|
||||
bandwidth requirements between the various NoC fabrics.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,msm8996-a0noc
|
||||
- qcom,msm8996-a1noc
|
||||
- qcom,msm8996-a2noc
|
||||
- qcom,msm8996-bimc
|
||||
- qcom,msm8996-cnoc
|
||||
- qcom,msm8996-mnoc
|
||||
- qcom,msm8996-pnoc
|
||||
- qcom,msm8996-snoc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 3
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8996-a0noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: Aggregate0 System NoC AXI Clock.
|
||||
- description: Aggregate0 Config NoC AHB Clock.
|
||||
- description: Aggregate0 NoC MPU Clock.
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: aggre0_snoc_axi
|
||||
- const: aggre0_cnoc_ahb
|
||||
- const: aggre0_noc_mpu_cfg
|
||||
|
||||
required:
|
||||
- power-domains
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8996-mnoc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: CPU-NoC High-performance Bus Clock.
|
||||
|
||||
clock-names:
|
||||
const: iface
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,msm8996-a2noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: Aggregate2 NoC UFS AXI Clock
|
||||
- description: UFS AXI Clock
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: aggre2_ufs_axi
|
||||
- const: ufs_axi
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-msm8996.h>
|
||||
#include <dt-bindings/clock/qcom,mmcc-msm8996.h>
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
|
||||
bimc: interconnect@408000 {
|
||||
compatible = "qcom,msm8996-bimc";
|
||||
reg = <0x00408000 0x5a000>;
|
||||
#interconnect-cells = <1>;
|
||||
};
|
||||
|
||||
a0noc: interconnect@543000 {
|
||||
compatible = "qcom,msm8996-a0noc";
|
||||
reg = <0x00543000 0x6000>;
|
||||
#interconnect-cells = <1>;
|
||||
clocks = <&gcc GCC_AGGRE0_SNOC_AXI_CLK>,
|
||||
<&gcc GCC_AGGRE0_CNOC_AHB_CLK>,
|
||||
<&gcc GCC_AGGRE0_NOC_MPU_CFG_AHB_CLK>;
|
||||
clock-names = "aggre0_snoc_axi",
|
||||
"aggre0_cnoc_ahb",
|
||||
"aggre0_noc_mpu_cfg";
|
||||
power-domains = <&gcc AGGRE0_NOC_GDSC>;
|
||||
};
|
@ -13,6 +13,9 @@ description: |
|
||||
The Qualcomm QCM2290 interconnect providers support adjusting the
|
||||
bandwidth requirements between the various NoC fabrics.
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -23,19 +26,6 @@ properties:
|
||||
- qcom,qcm2290-cnoc
|
||||
- qcom,qcm2290-snoc
|
||||
|
||||
'#interconnect-cells':
|
||||
const: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
|
||||
# Child node's properties
|
||||
patternProperties:
|
||||
'^interconnect-[a-z0-9]+$':
|
||||
@ -44,6 +34,9 @@ patternProperties:
|
||||
The interconnect providers do not have a separate QoS register space,
|
||||
but share parent's space.
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
@ -51,35 +44,16 @@ patternProperties:
|
||||
- qcom,qcm2290-mmrt-virt
|
||||
- qcom,qcm2290-mmnrt-virt
|
||||
|
||||
'#interconnect-cells':
|
||||
const: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- '#interconnect-cells'
|
||||
- clock-names
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#interconnect-cells'
|
||||
- clock-names
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
@ -89,32 +63,20 @@ examples:
|
||||
compatible = "qcom,qcm2290-snoc";
|
||||
reg = <0x01880000 0x60200>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
|
||||
<&rpmcc RPM_SMD_SNOC_A_CLK>;
|
||||
|
||||
qup_virt: interconnect-qup {
|
||||
compatible = "qcom,qcm2290-qup-virt";
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_QUP_CLK>,
|
||||
<&rpmcc RPM_SMD_QUP_A_CLK>;
|
||||
};
|
||||
|
||||
mmnrt_virt: interconnect-mmnrt {
|
||||
compatible = "qcom,qcm2290-mmnrt-virt";
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_MMNRT_CLK>,
|
||||
<&rpmcc RPM_SMD_MMNRT_A_CLK>;
|
||||
};
|
||||
|
||||
mmrt_virt: interconnect-mmrt {
|
||||
compatible = "qcom,qcm2290-mmrt-virt";
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_MMRT_CLK>,
|
||||
<&rpmcc RPM_SMD_MMRT_A_CLK>;
|
||||
};
|
||||
};
|
||||
|
||||
@ -122,16 +84,10 @@ examples:
|
||||
compatible = "qcom,qcm2290-cnoc";
|
||||
reg = <0x01900000 0x8200>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_CNOC_CLK>,
|
||||
<&rpmcc RPM_SMD_CNOC_A_CLK>;
|
||||
};
|
||||
|
||||
bimc: interconnect@4480000 {
|
||||
compatible = "qcom,qcm2290-bimc";
|
||||
reg = <0x04480000 0x80000>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
|
||||
<&rpmcc RPM_SMD_BIMC_A_CLK>;
|
||||
};
|
||||
|
@ -0,0 +1,28 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interconnect/qcom,rpm-common.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm RPMh Network-On-Chip Interconnect
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description:
|
||||
RPM interconnect providers support for managing system bandwidth requirements
|
||||
through manual requests based on either predefined values or as indicated by
|
||||
the bus monitor hardware. Each provider node represents a NoC bus master,
|
||||
driven by a dedicated clock source.
|
||||
|
||||
properties:
|
||||
'#interconnect-cells':
|
||||
oneOf:
|
||||
- const: 2
|
||||
- const: 1
|
||||
deprecated: true
|
||||
|
||||
required:
|
||||
- '#interconnect-cells'
|
||||
|
||||
additionalProperties: true
|
@ -7,13 +7,16 @@ $schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
title: Qualcomm RPM Network-On-Chip Interconnect
|
||||
|
||||
maintainers:
|
||||
- Georgi Djakov <georgi.djakov@linaro.org>
|
||||
- Georgi Djakov <djakov@kernel.org>
|
||||
|
||||
description: |
|
||||
RPM interconnect providers support system bandwidth requirements through
|
||||
RPM processor. The provider is able to communicate with the RPM through
|
||||
the RPM shared memory device.
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
|
||||
properties:
|
||||
reg:
|
||||
maxItems: 1
|
||||
@ -23,259 +26,22 @@ properties:
|
||||
- qcom,msm8916-bimc
|
||||
- qcom,msm8916-pcnoc
|
||||
- qcom,msm8916-snoc
|
||||
- qcom,msm8939-bimc
|
||||
- qcom,msm8939-pcnoc
|
||||
- qcom,msm8939-snoc
|
||||
- qcom,msm8996-a0noc
|
||||
- qcom,msm8996-a1noc
|
||||
- qcom,msm8996-a2noc
|
||||
- qcom,msm8996-bimc
|
||||
- qcom,msm8996-cnoc
|
||||
- qcom,msm8996-mnoc
|
||||
- qcom,msm8996-pnoc
|
||||
- qcom,msm8996-snoc
|
||||
- qcom,qcs404-bimc
|
||||
- qcom,qcs404-pcnoc
|
||||
- qcom,qcs404-snoc
|
||||
- qcom,sdm660-a2noc
|
||||
- qcom,sdm660-bimc
|
||||
- qcom,sdm660-cnoc
|
||||
- qcom,sdm660-gnoc
|
||||
- qcom,sdm660-mnoc
|
||||
- qcom,sdm660-snoc
|
||||
|
||||
'#interconnect-cells':
|
||||
description: |
|
||||
Value: <1> is one cell in an interconnect specifier for the
|
||||
interconnect node id, <2> requires the interconnect node id and an
|
||||
extra path tag.
|
||||
enum: [ 1, 2 ]
|
||||
|
||||
clocks:
|
||||
minItems: 2
|
||||
maxItems: 7
|
||||
|
||||
clock-names:
|
||||
minItems: 2
|
||||
maxItems: 7
|
||||
|
||||
power-domains:
|
||||
maxItems: 1
|
||||
|
||||
# Child node's properties
|
||||
patternProperties:
|
||||
'^interconnect-[a-z0-9]+$':
|
||||
type: object
|
||||
additionalProperties: false
|
||||
description:
|
||||
snoc-mm is a child of snoc, sharing snoc's register address space.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,msm8939-snoc-mm
|
||||
|
||||
'#interconnect-cells':
|
||||
const: 1
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- '#interconnect-cells'
|
||||
- clock-names
|
||||
- clocks
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- '#interconnect-cells'
|
||||
- clock-names
|
||||
- clocks
|
||||
|
||||
additionalProperties: false
|
||||
|
||||
allOf:
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8916-bimc
|
||||
- qcom,msm8916-pcnoc
|
||||
- qcom,msm8916-snoc
|
||||
- qcom,msm8939-bimc
|
||||
- qcom,msm8939-pcnoc
|
||||
- qcom,msm8939-snoc
|
||||
- qcom,msm8996-a1noc
|
||||
- qcom,msm8996-bimc
|
||||
- qcom,msm8996-cnoc
|
||||
- qcom,msm8996-pnoc
|
||||
- qcom,msm8996-snoc
|
||||
- qcom,qcs404-bimc
|
||||
- qcom,qcs404-pcnoc
|
||||
- qcom,qcs404-snoc
|
||||
- qcom,sdm660-bimc
|
||||
- qcom,sdm660-cnoc
|
||||
- qcom,sdm660-gnoc
|
||||
- qcom,sdm660-snoc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8996-mnoc
|
||||
- qcom,sdm660-mnoc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
- const: iface
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock.
|
||||
- description: Bus A Clock.
|
||||
- description: CPU-NoC High-performance Bus Clock.
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8996-a0noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: aggre0_snoc_axi
|
||||
- const: aggre0_cnoc_ahb
|
||||
- const: aggre0_noc_mpu_cfg
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Aggregate0 System NoC AXI Clock.
|
||||
- description: Aggregate0 Config NoC AHB Clock.
|
||||
- description: Aggregate0 NoC MPU Clock.
|
||||
|
||||
required:
|
||||
- power-domains
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8996-a2noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
- const: aggre2_ufs_axi
|
||||
- const: ufs_axi
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock
|
||||
- description: Bus A Clock
|
||||
- description: Aggregate2 NoC UFS AXI Clock
|
||||
- description: UFS AXI Clock
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sdm660-a2noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clock-names:
|
||||
items:
|
||||
- const: bus
|
||||
- const: bus_a
|
||||
- const: ipa
|
||||
- const: ufs_axi
|
||||
- const: aggre2_ufs_axi
|
||||
- const: aggre2_usb3_axi
|
||||
- const: cfg_noc_usb2_axi
|
||||
|
||||
clocks:
|
||||
items:
|
||||
- description: Bus Clock.
|
||||
- description: Bus A Clock.
|
||||
- description: IPA Clock.
|
||||
- description: UFS AXI Clock.
|
||||
- description: Aggregate2 UFS AXI Clock.
|
||||
- description: Aggregate2 USB3 AXI Clock.
|
||||
- description: Config NoC USB2 AXI Clock.
|
||||
|
||||
- if:
|
||||
not:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,msm8939-snoc
|
||||
then:
|
||||
patternProperties:
|
||||
'^interconnect-[a-z0-9]+$': false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
|
||||
bimc: interconnect@400000 {
|
||||
compatible = "qcom,msm8916-bimc";
|
||||
reg = <0x00400000 0x62000>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_BIMC_CLK>,
|
||||
<&rpmcc RPM_SMD_BIMC_A_CLK>;
|
||||
};
|
||||
|
||||
pcnoc: interconnect@500000 {
|
||||
compatible = "qcom,msm8916-pcnoc";
|
||||
reg = <0x00500000 0x11000>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_PCNOC_CLK>,
|
||||
<&rpmcc RPM_SMD_PCNOC_A_CLK>;
|
||||
};
|
||||
|
||||
snoc: interconnect@580000 {
|
||||
compatible = "qcom,msm8916-snoc";
|
||||
reg = <0x00580000 0x14000>;
|
||||
#interconnect-cells = <1>;
|
||||
clock-names = "bus", "bus_a";
|
||||
clocks = <&rpmcc RPM_SMD_SNOC_CLK>,
|
||||
<&rpmcc RPM_SMD_SNOC_A_CLK>;
|
||||
compatible = "qcom,msm8916-bimc";
|
||||
reg = <0x00400000 0x62000>;
|
||||
#interconnect-cells = <1>;
|
||||
};
|
||||
|
@ -113,6 +113,7 @@ allOf:
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdx65-mc-virt
|
||||
- qcom,sm8250-qup-virt
|
||||
then:
|
||||
required:
|
||||
|
108
Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
Normal file
108
Documentation/devicetree/bindings/interconnect/qcom,sdm660.yaml
Normal file
@ -0,0 +1,108 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interconnect/qcom,sdm660.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm SDM660 Network-On-Chip interconnect
|
||||
|
||||
maintainers:
|
||||
- Konrad Dybcio <konradybcio@kernel.org>
|
||||
|
||||
description: |
|
||||
The Qualcomm SDM660 interconnect providers support adjusting the
|
||||
bandwidth requirements between the various NoC fabrics.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdm660-a2noc
|
||||
- qcom,sdm660-bimc
|
||||
- qcom,sdm660-cnoc
|
||||
- qcom,sdm660-gnoc
|
||||
- qcom,sdm660-mnoc
|
||||
- qcom,sdm660-snoc
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clock-names:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
|
||||
clocks:
|
||||
minItems: 1
|
||||
maxItems: 5
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpm-common.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sdm660-mnoc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: CPU-NoC High-performance Bus Clock.
|
||||
|
||||
clock-names:
|
||||
const: iface
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
const: qcom,sdm660-a2noc
|
||||
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: IPA Clock.
|
||||
- description: UFS AXI Clock.
|
||||
- description: Aggregate2 UFS AXI Clock.
|
||||
- description: Aggregate2 USB3 AXI Clock.
|
||||
- description: Config NoC USB2 AXI Clock.
|
||||
|
||||
clock-names:
|
||||
items:
|
||||
- const: ipa
|
||||
- const: ufs_axi
|
||||
- const: aggre2_ufs_axi
|
||||
- const: aggre2_usb3_axi
|
||||
- const: cfg_noc_usb2_axi
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,gcc-sdm660.h>
|
||||
#include <dt-bindings/clock/qcom,mmcc-sdm660.h>
|
||||
#include <dt-bindings/clock/qcom,rpmcc.h>
|
||||
|
||||
bimc: interconnect@1008000 {
|
||||
compatible = "qcom,sdm660-bimc";
|
||||
reg = <0x01008000 0x78000>;
|
||||
#interconnect-cells = <1>;
|
||||
};
|
||||
|
||||
a2noc: interconnect@1704000 {
|
||||
compatible = "qcom,sdm660-a2noc";
|
||||
reg = <0x01704000 0xc100>;
|
||||
#interconnect-cells = <1>;
|
||||
clocks = <&rpmcc RPM_SMD_IPA_CLK>,
|
||||
<&gcc GCC_UFS_AXI_CLK>,
|
||||
<&gcc GCC_AGGRE2_UFS_AXI_CLK>,
|
||||
<&gcc GCC_AGGRE2_USB3_AXI_CLK>,
|
||||
<&gcc GCC_CFG_NOC_USB2_AXI_CLK>;
|
||||
clock-names = "ipa",
|
||||
"ufs_axi",
|
||||
"aggre2_ufs_axi",
|
||||
"aggre2_usb3_axi",
|
||||
"cfg_noc_usb2_axi";
|
||||
};
|
@ -0,0 +1,92 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/interconnect/qcom,sdx75-rpmh.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: Qualcomm RPMh Network-On-Chip Interconnect on SDX75
|
||||
|
||||
maintainers:
|
||||
- Rohit Agarwal <quic_rohiagar@quicinc.com>
|
||||
|
||||
description:
|
||||
RPMh interconnect providers support system bandwidth requirements through
|
||||
RPMh hardware accelerators known as Bus Clock Manager (BCM). The provider is
|
||||
able to communicate with the BCM through the Resource State Coordinator (RSC)
|
||||
associated with each execution environment. Provider nodes must point to at
|
||||
least one RPMh device child node pertaining to their RSC and each provider
|
||||
can map to multiple RPMh resources.
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
enum:
|
||||
- qcom,sdx75-clk-virt
|
||||
- qcom,sdx75-dc-noc
|
||||
- qcom,sdx75-gem-noc
|
||||
- qcom,sdx75-mc-virt
|
||||
- qcom,sdx75-pcie-anoc
|
||||
- qcom,sdx75-system-noc
|
||||
|
||||
'#interconnect-cells': true
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
clocks:
|
||||
maxItems: 1
|
||||
|
||||
required:
|
||||
- compatible
|
||||
|
||||
allOf:
|
||||
- $ref: qcom,rpmh-common.yaml#
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sdx75-clk-virt
|
||||
- qcom,sdx75-mc-virt
|
||||
then:
|
||||
properties:
|
||||
reg: false
|
||||
else:
|
||||
required:
|
||||
- reg
|
||||
|
||||
- if:
|
||||
properties:
|
||||
compatible:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sdx75-clk-virt
|
||||
then:
|
||||
properties:
|
||||
clocks:
|
||||
items:
|
||||
- description: RPMH CC QPIC Clock
|
||||
required:
|
||||
- clocks
|
||||
else:
|
||||
properties:
|
||||
clocks: false
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
#include <dt-bindings/clock/qcom,rpmh.h>
|
||||
|
||||
clk_virt: interconnect-0 {
|
||||
compatible = "qcom,sdx75-clk-virt";
|
||||
#interconnect-cells = <2>;
|
||||
qcom,bcm-voters = <&apps_bcm_voter>;
|
||||
clocks = <&rpmhcc RPMH_QPIC_CLK>;
|
||||
};
|
||||
|
||||
system_noc: interconnect@1640000 {
|
||||
compatible = "qcom,sdx75-system-noc";
|
||||
reg = <0x1640000 0x4b400>;
|
||||
#interconnect-cells = <2>;
|
||||
qcom,bcm-voters = <&apps_bcm_voter>;
|
||||
};
|
@ -62,6 +62,9 @@ properties:
|
||||
- description: MPM pin number
|
||||
- description: GIC SPI number for the MPM pin
|
||||
|
||||
'#power-domain-cells':
|
||||
const: 0
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
@ -93,4 +96,5 @@ examples:
|
||||
<86 183>,
|
||||
<90 260>,
|
||||
<91 260>;
|
||||
#power-domain-cells = <0>;
|
||||
};
|
||||
|
@ -110,6 +110,7 @@ properties:
|
||||
- qcom,sdm630-smmu-v2
|
||||
- qcom,sdm845-smmu-v2
|
||||
- qcom,sm6350-smmu-v2
|
||||
- qcom,sm7150-smmu-v2
|
||||
- const: qcom,adreno-smmu
|
||||
- const: qcom,smmu-v2
|
||||
- description: Qcom Adreno GPUs on Google Cheza platform
|
||||
@ -409,6 +410,7 @@ allOf:
|
||||
contains:
|
||||
enum:
|
||||
- qcom,sm6350-smmu-v2
|
||||
- qcom,sm7150-smmu-v2
|
||||
- qcom,sm8150-smmu-500
|
||||
- qcom,sm8250-smmu-500
|
||||
then:
|
||||
|
@ -33,4 +33,21 @@ properties:
|
||||
due to restrictions in a specific system, such as mounting conditions.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
brightness-levels:
|
||||
description:
|
||||
Array of distinct brightness levels. The levels must be in the range
|
||||
accepted by the underlying LED device. Typically these are in the range
|
||||
from 0 to 255, but any range starting at 0 will do, as long as they are
|
||||
accepted by the LED.
|
||||
The 0 value means a 0% of brightness (darkest/off), while the last value
|
||||
in the array represents a full 100% brightness (brightest).
|
||||
If this array is not provided, the driver default mapping is used.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
default-brightness-level:
|
||||
description:
|
||||
The default brightness level (index into the array defined by the
|
||||
"brightness-levels" property).
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
additionalProperties: true
|
||||
|
@ -16,6 +16,9 @@ description:
|
||||
can also be used to describe a backlight device controlled by the output of
|
||||
a LED driver.
|
||||
|
||||
allOf:
|
||||
- $ref: common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: led-backlight
|
||||
@ -26,25 +29,11 @@ properties:
|
||||
items:
|
||||
maxItems: 1
|
||||
|
||||
brightness-levels:
|
||||
description:
|
||||
Array of distinct brightness levels. The levels must be in the range
|
||||
accepted by the underlying LED devices. This is used to translate a
|
||||
backlight brightness level into a LED brightness level. If it is not
|
||||
provided, the identity mapping is used.
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
default-brightness-level:
|
||||
description:
|
||||
The default brightness level (index into the array defined by the
|
||||
"brightness-levels" property).
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- leds
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
@ -1,10 +0,0 @@
|
||||
88pm860x-backlight bindings
|
||||
|
||||
Optional properties:
|
||||
- maxim,max8925-dual-string: whether support dual string
|
||||
|
||||
Example:
|
||||
|
||||
backlights {
|
||||
maxim,max8925-dual-string = <0>;
|
||||
};
|
@ -0,0 +1,73 @@
|
||||
# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
|
||||
%YAML 1.2
|
||||
---
|
||||
$id: http://devicetree.org/schemas/leds/backlight/mps,mp3309c.yaml#
|
||||
$schema: http://devicetree.org/meta-schemas/core.yaml#
|
||||
|
||||
title: MPS MP3309C backlight
|
||||
|
||||
maintainers:
|
||||
- Flavio Suligoi <f.suligoi@asem.it>
|
||||
|
||||
description: |
|
||||
The Monolithic Power (MPS) MP3309C is a WLED step-up converter, featuring a
|
||||
programmable switching frequency to optimize efficiency.
|
||||
It supports two different dimming modes:
|
||||
|
||||
- analog mode, via I2C commands (default)
|
||||
- PWM controlled mode.
|
||||
|
||||
The datasheet is available at:
|
||||
https://www.monolithicpower.com/en/mp3309c.html
|
||||
|
||||
allOf:
|
||||
- $ref: common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: mps,mp3309c
|
||||
|
||||
reg:
|
||||
maxItems: 1
|
||||
|
||||
pwms:
|
||||
description: if present, the backlight is controlled in PWM mode.
|
||||
maxItems: 1
|
||||
|
||||
enable-gpios:
|
||||
description: GPIO used to enable the backlight in "analog-i2c" dimming mode.
|
||||
maxItems: 1
|
||||
|
||||
mps,overvoltage-protection-microvolt:
|
||||
description: Overvoltage protection (13.5V, 24V or 35.5V).
|
||||
enum: [ 13500000, 24000000, 35500000 ]
|
||||
default: 35500000
|
||||
|
||||
mps,no-sync-mode:
|
||||
description: disable synchronous rectification mode
|
||||
type: boolean
|
||||
|
||||
required:
|
||||
- compatible
|
||||
- reg
|
||||
- max-brightness
|
||||
- default-brightness
|
||||
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
i2c {
|
||||
#address-cells = <1>;
|
||||
#size-cells = <0>;
|
||||
|
||||
/* Backlight with PWM control */
|
||||
backlight_pwm: backlight@17 {
|
||||
compatible = "mps,mp3309c";
|
||||
reg = <0x17>;
|
||||
pwms = <&pwm1 0 3333333 0>; /* 300 Hz --> (1/f) * 1*10^9 */
|
||||
max-brightness = <100>;
|
||||
default-brightness = <80>;
|
||||
mps,overvoltage-protection-microvolt = <24000000>;
|
||||
};
|
||||
};
|
@ -11,6 +11,9 @@ maintainers:
|
||||
- Daniel Thompson <daniel.thompson@linaro.org>
|
||||
- Jingoo Han <jingoohan1@gmail.com>
|
||||
|
||||
allOf:
|
||||
- $ref: common.yaml#
|
||||
|
||||
properties:
|
||||
compatible:
|
||||
const: pwm-backlight
|
||||
@ -39,21 +42,6 @@ properties:
|
||||
Delay in ms between disabling the backlight using GPIO and setting PWM
|
||||
value to 0.
|
||||
|
||||
brightness-levels:
|
||||
description:
|
||||
Array of distinct brightness levels. Typically these are in the range
|
||||
from 0 to 255, but any range starting at 0 will do. The actual brightness
|
||||
level (PWM duty cycle) will be interpolated from these values. 0 means a
|
||||
0% duty cycle (darkest/off), while the last value in the array represents
|
||||
a 100% duty cycle (brightest).
|
||||
$ref: /schemas/types.yaml#/definitions/uint32-array
|
||||
|
||||
default-brightness-level:
|
||||
description:
|
||||
The default brightness level (index into the array defined by the
|
||||
"brightness-levels" property).
|
||||
$ref: /schemas/types.yaml#/definitions/uint32
|
||||
|
||||
num-interpolated-steps:
|
||||
description:
|
||||
Number of interpolated steps between each value of brightness-levels
|
||||
@ -69,7 +57,7 @@ required:
|
||||
- compatible
|
||||
- pwms
|
||||
|
||||
additionalProperties: false
|
||||
unevaluatedProperties: false
|
||||
|
||||
examples:
|
||||
- |
|
||||
|
Some files were not shown because too many files have changed in this diff Show More
Loading…
x
Reference in New Issue
Block a user